你可能很少聽過數據科學的這個方面：數據流的部署和生產力。每個人都談論著如何建模，但很少有人花時間談論實際運用這些模型的困難。因此這些生產力問題就成了許多企業難以從數據科學上的投資中發現價值的原因。
數據科學過程廣泛運用著網絡上的各種資源。一個數據科學家連接著數據，分離它們或者合併它們，清洗，發掘特征，構建模型，部署數據來觀測精確程度，重複這個過程直到科學家滿意為止。但這還不是故事的結尾。接下來，數據科學家需要將模型試用於真正的數據，讓其進入生產力的環境。
科學環境與生產力環境，與生俱來截然不同，因為後者是持續進行的，可能影響已存的內部系統或者外部系統。數據不斷流入，被處理並計算入KPI，然後經過頻繁再構的模型。多數時候這些系統還可能由不同於科學環境的計算機語言書寫。
為了更好地了解企業將數據科學從原型運用到生產力上的困難，Dataiku最近訪問了全球成千上萬的企業會如何面對這個挑戰。結果顯示企業的困難可以被歸類為以下4種類型：小型數據團隊、打包者（packagers）、工業化狂熱者、大數據實驗室。
小型數據團隊（23%）
小型數據團隊專注於快速創建小型項目：標準機器學習包（packages），一個獨有的服務器，和技術性環境，用於所有分析項目。
3/4不是做市場營銷就是做報表
61%報表有客製化的機器學習作為商業模型的一部分
83%使用SQL或者Enterprise Analytics(企業分析)數據庫
這些團隊，如他們的名字一樣，大部分使用少量數據，並擁有獨特的設計/生產力環境。他們部署小型的不斷的重複實驗，很少有無回卷策略（no rollback strategy）。他們通常不會重複調整模型，而是使用一次性的生產力部署和幾個包。商業團隊也會涉及數據項目的設計和部署。
平均部署難度值：6.4
打包者（packagers）（27%）
打包者集中構建框架（軟件開發的方法）：獨立團隊在對項目的整體理解上，構建他們自己的框架。
48%創立了高級報表
52%結合了存儲技術
63%使用SQL和開源技術
這些團隊對數據科學使用軟件開發的方法，通常是在混亂中構建了框架。他們開發專門的包，實行非正式的A/B測試。他們極多地使用Git來了解他們項目的全球性和他們的從屬性，他們對IT環境的連貫性特別關注。他們傾向於多語言環境，並與商業團隊有距離。
平均部署難度值：6.4
工業化狂熱者（18%）
工業化狂熱者集中於版本升級和審計：IT驅動的團隊根據頻繁的部署和不斷的記錄追蹤所有變化和從屬性。
61%有物流、安保、或者具體的行業實例
30%部署了高級報表（對比整體中的50%）
72%用NoSQL和雲技術
這些數據團隊大部分是IT驅動的，沒有特有的生產力環境。他們有複雜的自動化過程來幫助部署和維護。他們記錄所有數據存取、調整，有一套記錄一切的哲學。在這些初創公司裡，商業團隊顯然不干涉數據處理和監管的過程。
平均部署難度值：6.9
大數據實驗室（30%）
大數據實驗室致力於項目監管：成熟的團隊、全球性部署策略、回卷過程、將企業內的監管準則和團結擺在首位。
66%的公司準備有多種使用實例
50%做高級社交媒體分析（對比整體中的22%）
53%使用Hadoop，2/3的他們只使用Hadoop
這些團隊非常成熟，有複雜的使用實例和技術。他們用高級技術，例如PMML，多變量測試（或者至少是正式的A/B測試），有自動化流程來回溯測試（backtest），有完善的策略來審計IT環境的連貫性。在這些更大的，更有組織性的團隊裡，商業用戶會極大涉及數據產品的部署前後。
平均部署難度值：5.6
總的來說，幾乎每種團隊（整體的50%）都認為數據科學實踐中主要的障礙是數據質量和管道開發的問題。整體數據部署難度是6.18（/10），50%的參與者認為在1-10的範圍內，將數據產品用於實際生產的難度在6-10之間。
從結果來看，企業在構建能用於生產的數據科學產品時，需注意以下幾點：
- 萬事開頭難。做SQL數據庫的小型數據並不意味著更容易落實在實踐上。
- 多語言環境並不意味著更難維護，反而IT環境的連貫性更為重要。不要搞錯了方向！
- 實時評分和線上機器學習非常有可能讓實踐更複雜。要想清楚成本是否比得上收益。
- 和商業團隊一起設計機器學習項目，之後也一起監管它，是更高效的。合作很重要。
如果你對數據科學感興趣，對我們的團隊能為你的數據帶來什麼實際價值感到好奇，請發送郵件至info@bigdatarchitect.com