致謝：感謝 Kevin Turner 多次審查本文檔并提供寶貴意見。

數據科學家都傾向于使用一些臨時性方法。以創新方式非法侵入各種編程語言腳本的行為，在遍布于服務器和客戶端上的各種機器學習框架中隨處可見。我并不是要抱怨數據科學家的工作方式。我發現自己經常只有在創造力迸發的狀態下才會小有所成。

完全自由選擇編程語言、工具和框架的能力有助于改善創造性思維和加快思維演變進程。但最終，數據科學家必須將其資產完全打造成型，然后才能交付，否則可能會存在許多缺陷。接下來，我來介紹一下這些缺陷：

技術盲點

從數據科學家的角度來看，他們通常認為實際技術與 功能性取向沒有太大關聯，因為所使用的模型和算法是以數學方式定義的。因此，算法的數學定義是揭示真相的唯一途徑。但對于非功能性需求，這個觀點有些站不住腳。例如，編程語言和技術方面的專家的可用情況和成本存在很大的差異。在維護方面，所選擇的技術對于項目能否取得成功有很大影響。

數據科學家傾向于使用他們最擅長的編程語言和框架。首先，我來介紹一下 R 和 R-Studio 等開源技術，這些技術的程序包和庫數量龐大且難以管理，而且其語法松散且難以維護。隨后，我會介紹語法結構完善且經過精心組織的 Python 及相關框架(如 Pandas 和 Scikit-Learn)。另一類工具是“含少量代碼或無代碼”的完全可視化開源工具，如 Node-RED、KNIME、RapidMiner 和 Weka 以及諸如 SPSS Modeler 之類的商用產品。

“我最熟悉的技術”足以滿足概念驗證 (proof of concept, PoC)、黑客馬拉松或啟動式項目的需求。但對于行業和企業級規模的項目，必須提供有關技術使用的一些架構準則，無論此類技術有多淺顯易懂都應如此。

缺乏再現性和可復用性

鑒于上述問題，我們顯然無法容忍企業環境中數據科學資產不受控制的增長。在大型企業中，項目與人力資源可能出現大量流失，例如，僅為特定項目短期雇傭具備特定技能的外部咨詢人員。通常，當有人退出項目時，其擁有的知識技能也會隨之離去。因此，本質上，數據科學資產并不只是用各種編程語言編寫且分布在各個位置和環境中的腳本的集合。由于許多數據科學資產都是在非協作環境下開發的，因此這些資產的可復用性往往是有限的。臨時性的文檔記錄、代碼質量差、技術混用且過于復雜以及普遍缺乏專業知識是導致此類問題的主要推動因素。解決這些問題后，資產就會變為可復用并且其價值顯著增加。例如，如果未經協調，每位數據科學家都可能針對同一數據源重新創建 ETL(抽取 (Extract) - 變換 (Transform) - 裝入 (Load))、數據質量評估和特征工程管道，從而顯著增加開銷并降低質量。

缺乏協作

數據科學家都是偉大的思想家。常識告訴他們，腦容量是不變的。因此，數據科學家傾向于以自己的方式和步調獨立工作。當他們遇到棘手的難題時，像“stackexchange.com”這樣的 Web 站點就可能成為他們獲得幫助的***資源。也許是因為不知情或者只是缺少具有同等技能的伙伴，但技術***的數據科學家往往不擅長協作。從局外人的角度來看，因為他們秉著“哪管死后洪水滔天”的心態，所以沒有采用可復用的方式來共享和組織所創建的資產。文檔記錄欠佳，甚至沒有文檔記錄，而且組件分散，這些都導致難以回溯和復制以前的工作。因此，需要提供一個公共資產存儲庫并制定***的文檔記錄準則。

次優架構決策

數據科學家通常是具備線性代數技能和一定程度的業務理解能力的“黑客”。他們通常不是經過培訓的軟件工程師或架構設計師。如上所述，數據科學家傾向于使用他們最熟悉的編程語言和框架，并快速構建解決方案，而未必會考慮可擴展性、可維護性和人力資源可用性等非功能性需求 (Non-functional requirement, NFR)。因此，我要強調一點，在每個重大數據科學項目中都應設立解決方案架構設計師或***數據科學家角色，從而確保適當滿足 NFR。預定義的架構和流程框架非常適合為此類角色提供支持。但首先，我們來了解一下傳統企業架構如何適用于數據科學項目。

怎樣的架構和流程才適用于數據科學項目

在回答這個問題之前，我們首先來簡單回顧一下傳統企業架構，然后評估怎樣的架構方法和流程模型才適用于此類架構。 

站在金字塔頂端的是企業架構設計師。企業架構設計師負責定義在整個企業內行之有效的標準和準則。示例包括：

• 只要擁有許可證，就可以使用開源軟件
• REST 調用始終需要使用 HTTPS
• 使用非關系數據庫需要獲得來自企業架構委員會的特別核準

解決方案架構設計師在企業架構設計師定義的框架內開展工作。該角色負責定義適用于項目或用例的技術組件。示例包括：

• 必須在 Db2 關系數據庫管理系統 (Relational database management system, RDBMS) 中存儲歷史數據
• 對于實時構造的高吞吐量數據，必須使用 Apache Spark Streaming
• 對于低延遲的實時視頻流處理，必須使用 IBM Steams

然后，應用程序架構設計師負責在解決方案架構設計師的框架內定義應用程序。示例包括：

• 使用“模型 - 視圖 - 控制器”(Model-View-Controller, MVC) 模式實施 UI
• 對于標準實體，將使用對象關系映射器
• 對于復雜查詢，將使用準備好的 SQL 語句

***，數據架構設計師負責定義數據相關組件，如：

• 在 ETL 期間，必須取消對數據的規范化以構成星型模型
• 在 ETL 期間，必須對所有分類字段和有序字段建立索引

那么在此過程中，富有創造力的全能數據科學家如何一展身手呢?首先，我們嘗試定義在以上定義的角色中，數據科學家能部分承擔其中哪些角色以及能夠與其中哪些角色進行交互。

讓我們再來從上到下審視一下這些角色。為了更直觀地進行說明，我們以城市設計作比喻。企業架構設計師相當于設計整個城市的人。例如，他們負責定義污水處理系統和道路。解決方案架構設計師相當于每棟房屋的設計人，應用程序架構設計師相當于廚房的設計人，數據架構設計師負責監督電路安裝和供水系統。

***，數據科學家負責打造有史以來***進的廚房!他們不會采用任何現有的廚房設計。他們會利用個別的現成組件，但也會根據需要創建原創部件。數據科學家與應用程序架構設計師的交互最為頻繁。如果對廚房有特殊要求，那么數據架構設計師可能需要提供基礎架構。記住這個比喻后，我們再來看一下，如果廚房由數據科學家獨立打造，它會變成什么樣?它將成為一個功能齊全的廚房，具有很多功能，但很可能欠缺適用性。例如，要啟動烤箱，您需要登錄到 Raspberry Pi 并運行一個 Shell 腳本。由于各個部件來自不同的供應商(包括某些定制硬件)，因此廚房的設計可能并不美觀。***，它雖然提供了大量的功能，但其中有些功能并不必要，而且大部分功能都沒有相應的文檔記錄。

再次從 IT 角度來看，此示例展示了原先問題的答案。在此過程中，富有創造力的全能數據科學家將如何一展身手呢?

數據科學家很少與企業架構設計師進行交互。他們可能會與解決方案架構設計師進行交互，但必然會與應用程序架構設計師和數據架構設計師緊密合作。他們不需要承擔對方的角色，但必須能夠從對方的角度來理解對方的想法。由于數據科學是一個新興的創新領域，因此數據科學家必須與架構設計師從同樣的角度(應用程序開發者或數據庫管理員則不必如此)來思考問題，才能轉變和影響企業架構。

我將使用一個示例來說明這其中的含義，以此作為本文的總結。考慮如下架構準則：采用 R-Studio Server 作為企業中的標準數據科學平臺，所有數據科學項目都必須使用 R。此軟件已經過企業架構設計師核準，內部部署的 R-Studio Server 自助服務門戶網站是由解決方案架構設計師設計的。數據科學家使用可顯著提升模型性能的 TensorFlow 后端來查找用 Python 編寫的 Keras 代碼片段。此代碼為開源代碼，由人工智能領域最智慧的大師之一負責維護。數據科學家只需一小時即可將此代碼片段注入其筆記本上運行的數據處理管道(沒錯，他們就是在筆記本上建立原型的，因為他們真的不喜歡所提供的 R-Studio Server 安裝)。那么，您認為這樣做之后會發生什么呢?

在以往企業架構設計師全知全能的時代，數據科學家可能被迫將代碼移植到 R 上(使用不太復雜的深度學習框架)。但這其中存在一種可能性。數據科學家應該能夠在需要時使用此代碼片段。但如果在沒有任何指導的情況下這樣做，那么可能導致數據科學領域成為一片荒蕪之地。

因此，我來介紹一下現有流程模型和參考架構，看看是否以及如何將傳統的架構領域與新興的數據科學領域相結合。

數據科學領域的現有流程模型概述

CRISP-DM

CRISP-DM 代表跨行業的標準數據挖掘流程 (Cross-industry Standard Process for Data Mining)，這是使用最廣泛的開源流程模型(前提是已使用流程模型)。CRISP-DM 定義了構成數據科學項目的一系列階段。最重要的是，這些階段之間的轉換為雙向轉換，整個流程為迭代式流程。這意味著，在到達最終階段后，將會重新開始整個流程并對您的工作進行優化。下圖演示了這***程。

CRISP-DM 流程模型。作者 Kenneth Jensen，參考文獻：IBM SPSS Modeler CRISP-DM Guide

在我看來，此流程模型已經是一個很好的開端。但由于它只是一個流程模型，所以假定已經制定了有關所用技術的架構決策并且已經滿足 NFA 需求。因此，CRISP-DM 模型適用于采用固定技術的環境(如傳統企業數據倉儲或商業智能項目)。

而在像數據科學這樣快速發展的領域，它還不夠靈活。

ASUM-DM

由于 CRISP-DM 存在缺陷，因此 IBM 于 2015 年發布了“適用于數據挖掘/預測分析的分析解決方案統一方法” (Analytics Solutions Unified Method for Data Mining/Predictive Analytics, ASUM-DM) 流程模型。它以 CRISP-DM 為基礎，但經過擴展后包含基礎架構、操作、項目和部署方面的一些任務和活動，并為所有任務添加了模板和準則。ASUM-DM 開放版本可供下載使用，但只有 IBM 客戶才能獲取全功能版本。(有關更多信息，聯系 asmarket@us.ibm.com。)

ASUM-DM 是更通用的“分析解決方案統一方法” (ASUM) 框架的一部分，此框架提供了特定于產品和特定于解決方案的實施路線圖，并涵蓋了所有 IBM Analytics 產品。

ASUM-DM 借鑒了來自 ASUM 的流程模型，如下圖所示。 

IBM Cloud Garage Method

在 2001 年發布 Manifesto for Agile Software Development 后，Waterfall 或 V-Model 之類的許多流程開始逐漸退出歷史舞臺。導致這種模式轉變的主要原因是 20 世紀 90 年代發生的軟件開發危機，在當時，軟件開發尚達不到業務利益相關者對產品上市時間和靈活性的快速增長期望。

由于企業客戶通常難以過渡到敏捷流程，所以 IBM 創建了 IBM Cloud Garage Method，這是一種敏捷軟件架構方法，可根據企業轉型需求進行定制。此方法同樣可以分為多個不同階段，如下圖所示。 

要注意的關鍵是，這個六邊形的中心是文化變遷。這意味著，如果沒有文化變遷，此方法將注定失敗。務必要牢記這一點。在數據科學領域，我們能占得先機的原因是數據科學家傾向于使用輕量級流程模型(前提是已使用流程模型)。 

[[258945]]

下面總結了文化變遷所涉及的六個階段。

思考

設計思維是全新的需求工程。設計思維源于 20 世紀 60 年代，但 IBM 是將此方法應用于 IT 行業的主要貢獻者之一。雖然通常會使用更復雜的術語來解釋設計思維，但我認為設計思維只有一個目的：將人類的大腦轉變到創新思維模式。因此，它使用書寫和繪畫來代替口述和打字。退后一步，您的眼界將更加開闊。

設計思維時刻牢記用戶體驗，并明確強調產品背后的業務。因此，它回答了下列關鍵問題：

• 誰：為誰構建產品?
• 嘗試要解決什么問題?
• 要如何解決問題?
• 每個思考階段的結果都是“最小可行產品”(MVP) 的定義。

編碼

平臺云革命是快速建立原型的主要推動因素。可以在幾小時(而不是幾天或幾周)內運行原型。這可將迭代周期縮短一個數量級。這樣，每天都可以收集用戶反饋。此階段的***實踐包括：

• 每日站立會議
• 結對編程和測試驅動開發
• 持續集成
• 自動測試
• 重構微服務
• 交付

每日交付需要滿足兩個前提條件。首先，必須使用工具鏈完全自動執行構建和部署過程。其次，每次落實到源代碼存儲庫時，都必須生成可供用戶隨時測試的完全生產就緒型產品。基于云的解決方案可以滿足這個需求，從而讓開發者專注于編程。 

運行

如果使用云運行時，那么項目的操作方面將由云服務處理。根據要求，這可能發生在公共云、私有云或混合云中以及基礎架構級別、平臺級別或服務級別。這樣通常會導致運營團隊被淘汰，而開發者可以集中精力為項目增加價值。此階段的***實踐包括：

• 準備實現高可用性
• 暗啟動和功能開關
• 自動縮放 

管理

由于前提是您已擁有完全受管的云運行時，因此可以輕松添加洲際高可用性/故障轉移、持續監控和動態縮放功能。此階段的***實踐包括：

• 自動監控
• 快速自動恢復
• 業務連續性
• 學習

由于迭代周期非常短且可持續獲得用戶反饋，因此可以立即測試假設并生成明智的決策，從而促使將發現的成果添加到待辦任務中以供進一步調整業務核心。此階段的***實踐包括：

• A/B 測試
• 假設驅動的開發
• 實時用戶行為分析 

IBM DataFirst Method

雖然通常與 IBM 客戶有關，但 DataFirst Method 設計合約產品(IBM DataFirst Method 是 IBM Cloud Garage Method 的一個實例)中包含的合約專門以 IT 轉型為目標，旨在使基礎架構、流程和員工為 AI 做好準備。有關更多信息，訪問 [ibm.biz/DataFirstMethod](ibm.biz/DataFirstMethod)。 

IBM 數據與分析參考架構

每個項目都不盡相同，每個用例都需要不同的技術組件。但所有這些都可以 用抽象的術語來加以描述。以下列表列舉并解釋了這些術語。

• 數據源：內部或外部數據源，包括關系數據庫、網頁、CSV 文件、JSON 文件、文本文件、視頻和音頻數據。
• 企業數據：基于云的解決方案，有助于擴展企業數據模型。因此，可能需要持續不斷地將企業數據子集傳輸到云端
• 流式分析：目前最有效的方法是批處理。但有時候，可通過添加實時分析功能來提升數據產品的價值，因為世界上大部分數據在幾秒鐘內就會失去價值。比如，股票市場數據或車輛攝像頭捕獲行人橫穿馬路的事實。
• 數據集成：清理和變換數據，并在可能的情況下添加下游功能。
• 數據存儲庫：用于存儲數據的持久存儲庫。
• 發現和探索：了解您擁有的數據及其外觀。
• 切實可行的洞察：您可在此處完成自己的大部分工作。在這里，您可創建和評估自己的機器學習模型和深度學習模型。
• 應用程序/數據產品：雖然模型行之有效，但只有在普通業務用戶使用它們時，其價值才會提升。因此，您必須創建數據產品。數據產品不一定需要保留在云端。可推送至移動應用程序或企業應用程序。
• 安全性、信息監管和系統管理：這是一個很容易被遺忘的重要步驟。為了滿足許多合規性法規，務必要控制各類信息的訪問者。企業用戶是架構的一部分，因為他們的需求可能與公共用戶不同。云用戶的需求又可能與企業用戶不同。 

結束語

鑒于您現在已經對云端數據科學領域中當前最有效的方法和流程模型有了整體認識，現在是時候來集中了解對于數據科學家最實用的方法了，此方法可幫助數據科學家改進其工作方法，***程度降低架構開銷并自下而上對企業架構產生積極影響。我將此方法稱為 IBM Cloud Garage 輕量級數據科學方法。我將在下一篇文章中介紹此方法。保持關注!