R 語言資料科學家/分析師在企業面臨的困境 (1) — 前言 & 原因
一、前言
近幾年，R 語言一直是資料分析領域頗受歡迎的語言，企業的數據團隊應該有不少比例的資料科學家/分析師學過 R，或是以 R 為主要的分析工具。
企業中，數據團隊的日常工作除了基礎維運工程、資料 ETL 之外，常見的專案工作不外乎透過程式進行資料處理、視覺化，或是開發出可預測複雜問題的機器學習模型。但是，必須讓程式於正式環境自動化執行 (例如自動每天產出分析結果)，或搭建為即時服務 (例如 API)，才算讓專案實際落地。
然而，即使在一個專業多樣性高的數據團隊，資料科學家/分析師仍常面臨的困境是，以 R 開發專案後，團隊中鮮少有能力及經驗將它部署 (deploy) 為企業的「正式服務」。即使團隊中有部署工程的人才，依然沒人會 (或沒人願意) 部署 R 的服務。
筆者在企業接過的專案多以 R 開發居多，但團隊無部署 R 專案的經驗，深受上述困境所苦。不過，為了讓服務上線，不得不逼自己學習 R 的部署工程、處處請教工程師高手們部署的眉角。尤其是在高度資安控管的產業/企業，要把 R 開發的專案實際落地確實困難重重。
再者，筆者在部署 R 服務時發現，網路上尚未有彙整性的文章，各種部署工程可能用到的工具/技術散落在四處，要花費了不少苦心才能蒐集完成。所以，我希望藉由此系列文章分享經驗，並提供大家彙整後的解決方法，也許不是最理想的方法，但希望讀者在 R 的部署 (Deployment) 少踩一點雷。
若你是 R 使用者、不懂 R 的資料工程師卻接到了 R 部署工作、數據團隊的管理者，此系列文章非常適合你閱讀。
此系列文章共分三篇：
- 第一篇（此篇）會分析困境背後的原因
- 第二篇會提供 R 部署的方法/技術
- 第三篇會分別以R 使用者/ 不懂 R 的資料工程師卻接到 R 部署工作/ 企業等面向提供建議
二、原因
首先，需說明專案要部署為企業的正式服務，可能包含但不限於以下條件：
- 服務的效能、模型效度需符合需求且有監控機制
- 程式執行的日誌 (Log) 需留存且符合規定
- 在程式開發完後，需經測試環境的測試/驗證後，才可於正式環境上線
- 若為高度資安控管的產業/企業，開源工具 (例如 R, Python, …) 的套件 (packages) 需有控管機制，不可恣意於企業使用
其實，上述條件 R 語言皆有相對應且開源的工具或套件可於企業內實現部署工作，這將會在下一篇文章說明，此篇還是著重在說明 R 使用者面臨困境的原因，所以讓我們回歸正題，我歸納了三個原因，分別說明如下。
原因一：專業背景
依筆者觀察，數據團隊中的 R 使用者多半是來自統計、數學以及社會科學等相關背景人才，大多以 R 作為分析工具，過去著重在資料清理、演算法理論、開發機器/深度學習模型等專業訓練，甚至打過不少數據競賽 (例如Kaggle)，礙於無受過資工、電腦科學相關的訓練，自然是缺乏工程面的知識，甚至看到黑黑畫面 (Terminal console) 就投降。
相對來說，企業中工程專業的人卻少有對 R 熟悉者，甚至認為 R 只能用來做資料分析，適合在學術界研究使用，較不適合在企業部署服務。
簡單來說，「懂 R 的人不懂工程，懂工程的人不懂 R」。
原因二：專業分工
以預測模型的開發專案為例，先撇開基礎工程、ETL 等資料工程不說 (假設資料已就定位)，大致可分為以下工作：
- 問題釐清：多由團隊中的商業分析師負責與企業的需求單位洽談(此模型案的業務出口)，釐清需求、定義問題後，回頭與團隊中的資料科學家、資料工程師確認解決方法以及部署工程的可行性
- 資料清理、特徵工程、模型訓練：多由資料科學家負責，嘗試不同的演算法，選擇最佳模型
- 效益試算：資料科學家或商業分析師會針對最佳模型試算模型效益，假設模型應用於企業後，公司的收益提升多少、業務效率被優化多少，藉此讓需求單位或老闆買單
- 部署工程：此時，業務情境、最佳模型都確定了，資料工程師需依照企業規定並符合前文的「正式服務」條件，將模型部署為正式服務。
問題來了，如果不是「懂 R 的工程師」或「懂工程的 R 使用者」，關於 R 部署的工作其實是相當困難的，以下為筆者聽過的實際案例：
工程師會問 ：
“ R有類似 Python Virtualenv 的功能嗎？ R 的服務可以包成 Docker 嗎？ R可以刻 API 嗎？”
“我不會 R 耶，我知道 Python 可以做到，R 可能有類似的功能，再麻煩懂 R 的人研究一下吧 ”
R 分析者會說：
“工程方面我比較不懂，可以麻煩資料工程師協助評估嗎？ ”
“心想：(工程不是我想發展的專業，我只想專攻分析和演算法就好，工程的事情還是讓工程師來吧…) ”
再者，規模較大的數據團隊，甚至會再切分為商業分析、資料科學、資料工程等團隊，專業分工之外，更多了「權責區分」的問題，當「部署」成為工程團隊的職責時，甚至會被工程團隊立下規範以利管理，以下亦為聽過的實際案例：
工程團隊會說：
“若要我們負責部署，請別用 R，那樣我們很難控制品質 ”
“我們有開發 Python 的部署架構，希望大家能遵循工程團隊的規範，改用 Python 開發 ”
若無法避免接到分析團隊的 R 程式… “ 心想：(天啊！分析團隊的程式毫無架構，專案沒有套件版本控管機制、沒寫 config、日誌也沒留… ) ”
分析團隊會說：
“分析團隊該負責 R 的部署嗎？但分析團隊職責是分析和建模，希望部署還是儘量遵循組織分工，讓專業的工程團隊負責吧 ”
(所以才會聽過工程師抱怨：“分析師常覺得做完分析之後就沒他們的事了...”)
然而，資料科學家/分析師永遠需要資料工程師，或者他自己就是那位資料工程師。在工程師不懂 R 的情況下，必須透過工程師與 R 使用者協作，或 R 使用者自己當那位資料工程師，才能順利完成部署。
(當然，市面上有企業級方案包含 R 的部署服務，缺點就是需外包，價格通常也不便宜，在此我們不列入討論)
原因三：誤會了！R 不是通用程式語言(General-purpose programming language)
R 不是為了設計成通用程式語言 (例如 C、C++、Python、...等)，而是著重在資料處理、資料分析、視覺化、統計/機器學習/深度學習模型等功能，擁有上萬個套件幫助資料科學家/分析師實現多種工作，當然也有套件或其他工具能實現部署工程。
不過，還是很多人習慣拿 R 跟通用程式語言比較，並希望資料科學家/分析師改用其他語言開發專案，我想說：「不能這樣比！」打個比方，「剪刀」可用來剪大部分的東西，但很多人有剪指甲的需求，所以「指甲剪」被發明了且很受歡迎，它用來剪指甲特別有效率、好上手，你當然還是可以用剪刀來剪指甲，如此只需學習一種多用途的工具就好，但不會拿剪刀來跟指甲剪比較，還說「指甲剪只能用來剪指甲，剪其他東西很難用。」(好像在繞口令)
所以實務上聽過工程師這麼說：
“別寫 R 了啦，R 可以做的事情不多 ”
“ R 不適合用來開發服務，別用 R開發吧！ ”
當然，若要架設網站或功能豐富的服務系統時，不會選擇用 R 開發；但要在網站或系統內提供資料視覺化或機器學習模型的預測功能時，則非常適合在網站內放入 R 的服務。
結語
最後，筆者想再次強調，其實 R 有非常多套件/工具可實現部署工程，跟其他語言也可以整合，所以別再誤會 R 了！下一篇文章會是偏向技術的分享，第三篇文章則會針對上述的困境給予建議。想了解實現部署的套件/工具？讓我們看下一篇吧！
(喜歡我的文章來點掌聲吧！歡迎分享文章連結，轉貼內文請載明出處)
