人腦具備不斷積累經驗的能力，依賴經驗我們便具備了分析處理的能力，比如我們要去菜場挑一個西瓜，別人或者自己的經驗告訴我們色澤青綠、根蒂蜷縮、紋路清晰、敲聲渾響的西瓜比較好吃。

我們具備這樣的能力，那麼機器呢？機器不是隻接收指令，處理指令嗎？和人腦類似，可以餵給機器歷史數據，機器依賴建模算法生成模型，根據模型便可以處新的數據得到未知屬性。以下便是機器學習與人腦歸納經驗的類別圖：

平臺設想

在同程內部，我們對應用機器學習的一些團隊做了瞭解，發現他們普遍的處理步驟如下：

這個過程中存在一些痛點：

• 線上數據到線下搬運耗時
• 訓練數據量難均衡，如果訓練數據量較大，用 R 或者 Python 做單機訓練將會非常耗時。如果訓練數據量較小，訓練出來的模型容易過擬合。
• 對分析和挖掘人員的編碼能力有一定的要求。

因此我們覺得可以構建一套平臺化的產品直接對線上數據進行建模實驗，節省機器學習的開發成本，降低機器學習的應用門檻。

平臺構建

設計目標

• 支持大數據量的建模實驗，通過並行計算縮短耗時
• 抽象出最小執行單元，配置簡單。通過拖拽以及連線的形式構建建模流程
• 支持常用的機器學習學習算法處理迴歸、分類、聚類等問題支持常用的特徵工程組件，如標準化、歸一化、缺失值處理等
• 支持算法評估結果可視化

算法庫

在算法庫方面，我們選擇了 Spark，相比於 R 或者 Python，Spark 具備分佈式計算的能力，更高效。

ml 和 mllib 都是 Spark 中的機器學習庫，目前常用的機器學習功能兩個個庫都能滿足需求。ml 主要操作的是 DataFrame，相比於 mllib 在 RDD 提供的基礎操作，ml 在 DataFrame 上的抽象級別更高，數據和操作耦合度更低。

ml 提供 pipeline，和 Python 的 sklearn 一樣，可以把很多操作 (算法 / 特徵提取 / 特徵轉換) 以管道的形式串起來，對於任務組合非常便利，如 StringToIndexer、IndexerToString、VectorAssembler 等。

組件化設計

從架構設計上來說，不管是算法單元、特徵工程單元、評估單元或者其他工具單元，我們認為都可以以組件的形式來設計。藉助通用的接口行為以及不同的實現可以達到松耦合、易擴展的目的。

上圖是整個設計類圖的一部分，實際上我們做了較多層次的抽象以及公用代碼。下面看看核心類 BaseTask：

run 方法的實現是一套模板，步驟如下：

每個組件只要實現自己的核心邏輯 execute 方法就可以了。

平臺迭代

v1.0（平臺核心架構）

基於上述的設計目標，機器學習平臺第一個版本的架構如下：

• 用戶通過界面拖拽組件構建建模流程，並將組件配置以及依賴關係保存到 DB 中
• 用戶可以在界面上觸發建模試驗的運行，實際上通過 spark-submit 提交一個 spark 任務
• Ml Engine 負責這個任務的執行，在 Driver 端會從 DB 中獲取當前試驗的依賴組件以及流程關係。這些組件將依次運行，涉及 RDD 相關的操作時會提交到 Spark Executor 進行並行計算

流程 & 評估視圖

第一個版本我們並沒有提供太多的算法組件，只有線性迴歸和邏輯迴歸，但是基於組件化的思想，我們非常有信心在後期快速迭代。

除了算法較少外，結合業務反饋與自身思考。我們覺得機器學習平臺可以做更多的事：

• 平臺定位不僅僅是實驗控制檯，增加預測結果落地的功能（離線計算）
• 訓練模型隨著歷史數據的不斷擴充在大部分情況下都應該是個週期性的事情。我們希望在平臺層面能夠幫助用戶託管這個過程。

v2.0（擴充組件 & 離線計算 & 週期性調度）

第二個版本中，我們首先基於原有的設計框架擴充完善了相關實用組件:

同時在第二個版本中，我們在細節上又做了一些完善：

• 建模實驗運行狀態流程展示，用戶可以觀察到每個組件的運行時間，狀態，日誌等
• 依賴完整的組件可以進行局部運行，在一個較複雜的建模實驗中，完全可以先進行局部驗證以及參數調整
• 建模實驗支持克隆

離線計算

我們提供了‘字段落地’的工具組件，可以將預測結果以 csv 的格式落入 hdfs 中：

週期性調度 & 宏變量支持

我們的另一款產品：大數據開發套件（BDK），函蓋週期性調度的功能，機器學習平臺的建模實驗可以以子任務的形式嵌入其中，結合宏變量（某種規則的語法替換，例如’/%Y/%m/%d’可以表示為當前天等等）用戶可以在我們的平臺中託管他們的建模試驗，從而達到週期性離線計算的目的。

架構

綜上，豐富組件及完善功能、離線計算結果落地、結合 BDK 進行週期性離線計算是我們平臺第二個版本主要的，具體架構有了以下演進：

v3.0（實時預測 & 交叉驗證）

實時預測

在我們的平臺中可以通過建模實驗訓練模型，模型可以通過 PMML 這樣的標準導出，同樣也可以通過我們的模型導出功能將模型以 parquet 格式保存在 Hdfs 相應的目錄上。用戶可以得到這些模型標準，自己去實現一些功能。但是我們覺得實時預測的功能在我們平臺上也可以抽象出來。於是 3.0 的架構中我們開發了提供實時預測服務的 tcscoring 系統：

tcscoring 系統的依賴介質就是模型的 PMML 文件，用戶可以在機器學習平臺上直接部署訓練完成了的模型對應的 PMML 文件，或者通過其他路徑生成的 PMML 文件。部署成功後會返回用於預測的 rest 接口供業務使用：

當然，PMML 的部署也可以結合 BDK 設置成周期性調度，這些結合模型的週期性訓練，整個訓練 + 預測的過程都可以交給機器學習平臺 +BDK 實現託管。

交叉驗證

在機器學習平臺的第三個版本中，我們還有個點就是交叉驗證，之前的版本中用戶一次只能實驗一組超參數，有了交叉驗證，用戶便可以在一次實驗中配置多組超參數，在訓練集中在按比例進行循環拆分，一部分訓練，一部分驗證，從而得到最優模型：

平臺展望

個性化

迭代完 3 個版本後，機器學習平臺抽象出了很多通用的東西，但是還有一些個性化的東西沒有辦法很好地變現。我們的想法是對於用戶來說，最好的個性化途徑就是讓用戶自己寫代碼，我們會嘗試開放接口自定義插件，同時利用動態編譯技術加載這些個性化的組件，融合進建模流程中。

融合其他算法包

我們目前也在嘗試融合 spark ml 之外的算法包，如使用度較廣的 xgboost 等。另一方面目前的算法還是基於傳統的機器學習算法，對於深度學習，不管是嵌入 tensorflow 還是使用一些第三方的深度學習庫，如 Deeplearning4j 等。我們接下來會嘗試融合這些 spark ml 之外的算法包。

在不久的將來，多智時代一定會徹底走入我們的生活，有興趣入行未來前沿產業的朋友，可以收藏多智時代，及時獲取人工智能、大數據、雲計算和物聯網的前沿資訊和基礎知識，讓我們一起攜手，引領人工智能的未來！