最新 ‖ 詳解UBER的機器學習平台：米開朗基羅

本文作者：Jeremy Hermann Uber工程經理，Mike Del Balso是Uber機器學習平台團隊的產品經理。

Uber Engineering致力於開發，為客戶創造無縫體驗的技術。我們正在越來越多地投入人工智慧（AI）和機器學習（ML）來實現這一願景。

在Uber，我們對這個領域的貢獻是米開朗基羅（michelangelo），這是一個內部的ML-as-a-service服務平台，使機器學習民主化，並且AI可以滿足商務需求，就像打車一樣簡單。

米開朗基羅平台使內部團隊能夠以Uber的規模無縫地構建，部署和運行機器學習解決方案。它旨在涵蓋端到端ML工作流程：管理數據、訓練、評估和部署模型，進行預測和監控預測。

該系統還支持傳統ML模型，時間序列預測和深度學習。

米開朗基羅已在Uber應用了大概一年，已成為我們的工程師和數據科學家的機器學習的常用系統，有數十個團隊建立和部署模型。事實上，它被部署在幾個Uber數據中心，利用專門的硬體，並為公司最高負載的在線服務提供預測。

在本文中，我們介紹了Michelangelo以及產品用例，並且深入了解了這個強大的新的ML-as-a-service系統的工作流程。

▍米開朗基羅的初衷

在米開朗基羅之前，我們面臨著：建立和部署Uber的大規模數據機器學習模型的一些挑戰。

雖然數據科學家，正在使用各種各樣的工具來創建預測模型（R，scikit-learning，自定義演算法等），但是單獨的工程團隊，也在構建定製的一次性系統，以在生產中使用這些模型。

因此，Uber希望建立ML平台，數據科學家和工程師可以在短時間內建立大多數開源工具。

具體來說，目前還沒有建立可靠、統一、可重複的管道系統，用於大規模創建、管理訓練和預測數據。在米開朗基羅之前，不可能訓練比數據科學家台式機更適合的模型，而且沒有一個標準的地方來存儲訓練實驗的結果，也不是一個比較一個實驗與另一個實驗的簡單方法。

最重要的是，沒有確定將模型部署到生產中的途徑- 在大多數情況下，相關工程團隊必須創建專門針對項目的定製服務庫。同時，我們也開始看到Scully等人記錄的許多ML反模式的跡象。

米開朗基羅旨在通過將整個團隊的工作流程和工具標準化，通過端到端的系統來解決這些差距，使整個公司的用戶能夠輕鬆構建和運行大規模的機器學習系統。

我們的目標不僅僅是解決這些直接的問題，而且還要建立一個能夠與企業發展相關的體系。

當我們在2015年中期開始建立米開朗基羅時，我們開始將可擴展模型訓練和部署的挑戰應用於生產伺服器。然後，我們專註於建立更好的管理和共享特徵管道的系統。

最近，重點轉移到開發人員的生產力- 如何加快從想法到第一生產模式的路徑以及隨後的快速迭代。

在下一節中，我們將看一個示例應用程序，以了解米開朗基羅如何用於構建和部署模型以解決Uber的特定問題。雖然我們強調了UberEATS的具體用例，但該平台可以管理各種類似的模型，用於各種預測用例。

▍用例：UberEATS預計交貨時間模型

UberEATS有幾種型號運行在米開朗基羅，涵蓋外賣交付時間預測，搜索排名，搜索自動填充和餐廳排名。交付時間模型預測，在訂單發出之前準備和交付外賣需要多少時間，然後在交貨過程的每個階段再次預測。

圖1：UberEATS應用程序承載了，由米開朗基羅建立的機器學習模型提供的預測交付時間功能。

預計外賣送貨時間（ETD）並不簡單。

當UberEATS客戶下訂單時，它被發送到餐廳進行處理。餐館然後需要確認訂單，並準備餐，這將需要時間，這取決於訂單的複雜性和餐廳的繁忙程度。

當餐點接近準備時，一個Uber派送夥伴被派去拿起飯菜。然後，送餐員需要到達餐廳，找到停車場，走進去拿食物，然後回到車裡，開車到客戶的位置（這取決於路線，交通等因素），找到停車位，並走到客戶的門口完成交貨。

目標是預測這個複雜多階段過程的總持續時間，

在米開朗基羅平台上，UberEATS數據科學家使用梯度推進決策樹回歸模型，來預測這種端到端交付時間。該模型的特徵包括來自請求的信息（例如，時間，交貨地點），歷史特徵（例如過去七天的平均外賣準備時間）和近實時計算的特徵（例如，平均外賣準備時間最後一個小時）。

模型部署在Uber數據中心，提供給伺服器的米開朗基羅模型，並通過UberEATS微伺服器的網路請求進行調用。這些預測，將在從餐廳訂購之前，向UberEATS客戶展示，並且展示正在準備和交付餐點。

▍系統架構

米開朗基羅由一系列的開源系統和內置的組件組成。使用的主要開源組件是HDFS，Spark，Samza，Cassandra，MLLib，XGBoost和TensorFlow。

我們通常更願意，在可能的情況下使用成熟的開放源代碼選項，並根據需要進行分支、定製和貢獻，儘管我們有時，會在開源解決方案不適合我們的用例時，自行構建系統。

米開朗基羅建立在Uber數據和計算基礎設施之上，提供數據湖，存儲所有Uber的事務和記錄數據，Kafka經紀人匯總來自所有Uber服務的記錄消息，Samza流式計算引擎，管理Cassandra群集和Uber's家庭服務配置和部署工具。

在下一節中，我們將使用UberEATS ETD模型作為案例研究，以體現米開朗基羅的技術細節，從而深入了解系統的各個層次。

▍機器學習工作流程

在Uber幾乎所有機器學慣用例中，都存在相同的一般工作流程，無論手頭的挑戰，包括分類和回歸，以及時間序列預測。

工作流通常與實現無關，因此很容易擴展，以支持新的演算法類型和框架，例如較新的深度學習框架。它也適用於不同的部署模式，如在線和離線（以及車載和手機）預測用例。

我們專門設計了米開朗基羅，以提供可擴展，可靠，可重現，易於使用和自動化的工具來解決以下六步工作流程：

• 管理數據

• 訓練模型

• 評估模型

• 部署模型

• 生成預測

• 監控預測

接下來，我們將詳細介紹：米開朗基羅的架構，如何促進這一工作流的每個階段。

管理數據

找到良好的功能，通常是機器學習中最難的部分，我們發現構建和管理數據管道，通常是完整的機器學習解決方案中，最昂貴的部分之一。

平台應提供建立數據管道的標準工具，以生成用於訓練（和重新訓練）的功能和標籤數據集以及僅用於預測的特徵數據集。

這些工具應與公司的數據湖或倉庫，以及公司的在線數據服務系統進行深度整合。管道需要具有可擴展性和性能，包括數據流和數據質量的綜合監控，並支持在線和離線訓練和預測。

理想情況下，他們也應該以可以在團隊間共享的方式生成功能，以減少重複的工作並提高數據質量。他們還應提供強有力的護欄和控制措施，以鼓勵和授權用戶採用最佳做法（例如，使得訓練時間和預測時間，都能夠保證使用相同的數據生成）

米開朗基羅的數據管理組件，在線和離線管道之間劃分。目前，離線管道用於投喂批量模型訓練和批量預測作業，在線管道在線提供，低延遲預測（以及在不久的將來，打造在線學習系統）。

此外，我們還添加了一層數據管理功能，可讓團隊共享，發現和使用高度策劃的功能集，用於機器學習解決問題。

我們發現，Uber的許多建模問題，都使用相同或相似的功能，並且在使團隊能夠分享自己的項目之間的功能，以及不同組織中的團隊之間共享功能方面具有重大價值。

圖2：數據準備管道將數據推送到Feature Store和訓練數據存儲庫。離線

Uber的事務和日誌數據流入HDFS數據湖，並且可以通過Spark和Hive SQL計算作業輕鬆訪問。

我們提供容器和調度，以運行常規作業以計算功能，這些功能可以對項目進行private，或發布到Feature Store（見下文），並在團隊之間共享，而批處理作業按計劃或觸發器運行，並與數據集成質量監控工具合作，可以快速檢測流程中的回歸- 由於本地或上游代碼或數據問題。

在線

在線部署的模型，無法訪問存儲在HDFS中的數據，並且通常難以從Uber的生產服務（例如，無法直接查詢UberEATS訂單服務）直接從在線資料庫中，計算特定時段內餐館的平均外賣準備時間）。

相反，我們允許將在線模型所需的功能，預先計算並存儲在Cassandra中，在預測時可以以低延遲讀取它們。

我們支持兩種在線計算服務功能，批量預計算和近實時計算，如下所示：

• 批量預計算：計算的第一個選擇是，定期進行批量預先計算，並將歷史特徵從HDFS載入到Cassandra中。這是簡單而有效的，一般適用於歷史功能，只要功能只能每隔幾小時更新一次即可。

  該系統保證了相同的數據和批次管道用於訓練和服務。UberEATS使用該系統的功能，如「 餐廳在過去七天的平均外賣準備時間」。

• 近實時計算：第二個選擇是將相關指標發布到Kafka，然後運行基於Samza的流計算任務，以低延遲生成聚合特徵。然後將這些功能直接寫入Cassandra，提供服務並登錄到HDFS，以便將來進行訓練。

像批量系統一樣，近實時計算確保了相同的數據用於訓練和服務。為了避免冷啟動，我們提供了一個工具，通過對歷史日誌運行批處理作業，來「回填」此數據並生成訓練數據。

UberEATS使用這種近乎實時的管道，來實現「餐廳在過去一個小時的平均外賣準備時間」的功能。

Shared feature store

我們發現，建立一個集中的Feature Store非常有價值，其中Uber的團隊可以創建和管理他們的團隊使用，並與他人共享功能規範。在高層次上，它完成了兩件事情：

它允許用戶輕鬆地將他們內置的功能，添加到共享功能存儲中，只需要少量額外的元數據（所有者，描述，SLA等），而不需要private，項目 - 具體用法。

一旦功能部件在Feature Store中，通過在模型配置中引用功能的簡單規範名稱，它們在線和離線都很容易使用。配備此信息，系統處理加入正確的HDFS數據集進行模型訓練或批量預測，並從Cassandra獲取正確的值以進行在線預測。

目前，Feature Store中有大約10,000個功能用於加速機器學習項目，而整個公司的團隊都在增加新的功能。Feature Store中的功能每天都會自動計算和更新。

將來，我們打算探索構建自動化系統，以搜索Feature Store的可能性，並確定解決給定預測問題的、最有用和最重要的功能。

功能選擇和轉換的域特定語言

通常，由數據流水線生成，或從客戶端服務發送的功能，不是模型的正確格式，並且它們可能缺少需要填充的值。此外，該模型可能只需要提供的一部分功能。

在某些情況下，模型可能會把時間戳轉換為一小時或一周的時間，以更好地捕捉季節性模式。在其他情況下，特徵值可能需要歸一化（例如，減去平均值併除以標準偏差）。

為了解決這些問題，我們創建了一個DSL（域特定語言），建模者用於選擇，轉換和組合，在訓練和預測時間發送到模型的功能。DSL實現為Scala的子集。它是一個純功能語言，具有一套完整的常用功能。

使用這種DSL，我們還為客戶團隊，添加自己的用戶定義功能的能力。存在從當前上下文（在離線模型的情況下的數據流水線，或來自客戶端的在線模型的情況下的當前請求）或從Feature Store獲取特徵值的訪問功能。

重要的是要注意，DSL表達式是模型配置的一部分，並且在訓練時間和預測時間應用相同的表達式，以幫助確保在兩種情況下，都生成相同的最終特徵集，並將其發送到模型。

訓練模型

我們目前支持決策樹的離線，大規模分散式訓練，線性和邏輯模型，無監督模型（k-means），時間序列模型和深度神經網路。

我們定期添加新的演算法來應對客戶的需求，並且由Uber的AI實驗室和其他內部研究人員開發。此外，我們讓客戶團隊通過提供定製訓練，評估和服務代碼來添加自己的模型類型。

分散式模型訓練系統可以擴展到，處理數十億個樣本和低質量數據集，以進行快速迭代。

模型配置指定模型類型，超參數，數據源引用和特徵DSL表達式，以及計算資源需求（計算機數量，內存量，是否使用GPU等）。它用於配置在YARN或Mesos群集上運行的訓練作業。

在模型訓練之後，計算績效指標（如ROC曲線和PR曲線），並將其合併到模型評估報告中。在訓練結束時，將原始配置，學習參數和評估報告，保存回我們的模型庫進行分析和部署。

除了訓練單一模型之外，米開朗基羅還支持對所有模型類型，以及分區模型的超參數搜索。使用分區模型，我們會根據用戶的配置，自動對訓練數據進行分區，然後對每個分區訓練一個模型，在需要時回到父模型（例如，每個城市訓練一個模型，並回到國家級模型，當準確的城市級模式無法實現）。

訓練作業可以通過Web UI或API進行配置和管理，通常用 Jupyter notebook（http://jupyter.org/）。許多團隊使用API和工作流程工具來安排他們的模型的定期重新培訓。

圖3：模型訓練作業，使用Feature Store和訓練資料庫數據集來訓練模型，然後將其推送到模型庫。

評估模型

模型訓練，以識別為其問題創建最佳模型的一組特徵，演算法和超參數。在達到給定用例的理想模式之前，訓練數百種不進行切割的機型並不罕見。

雖然這些模型並沒有最終用於生產，但是這些模型的性能，可以指導工程師進行模型配置，從而獲得最佳的模型性能。跟蹤這些受過訓練的模型（例如，誰訓練他們，什麼時候，什麼數據集，哪些超參數等等），評估它們，並將它們相互比較通常是處理這麼多模型和呈現的大挑戰為平台增添了很多價值的機會。

對於在米開朗基羅訓練的每個模型，我們在Cassandra的模型庫中，存儲一個版本化對象，其中包含以下記錄：

• 誰訓練了模型

• 訓練工作的開始和結束時間

• 完整型號配置（使用的功能，超參數值等）

• 參考訓練和測試的數據集

• 每個特徵的分佈和相對重要性

• 模型精度指標

• 每種模型類型的標準圖表（例如二進位分類器的ROC曲線，PR曲線和混淆矩陣）

• 模型的完整學習參數

• 模型可視化的摘要統計

• 該信息可通過Web UI輕鬆獲得，並通過API以編程方式提供，用於檢查單個模型的細節，以及將一個或多個模型彼此進行比較。

模型精度報告

回歸模型的模型精度報告，顯示了標準精度指標和圖表。分類模型將顯示不同的集合，如圖4和5所示：

圖4：回歸模型報告顯示與回歸相關的績效指標。

圖5：二進位分類績效報告顯示與分類有關的績效指標。

決策樹可視化

對於重要的模型類型，我們提供複雜的可視化工具，以幫助建模者了解模型的行為原理，以及如有必要幫助調試。

對於決策樹模型，我們讓用戶瀏覽每個單獨的樹，以查看它們對整個模型，它們的分割點，每個特徵對特定樹的重要性的相對重要性，以及每個樹的數據分佈分割等變數。

用戶可以指定特徵值，並且將可視化描繪決策樹下的觸發路徑，每棵樹的預測和模型的總體預測，如圖6所示：

圖6：可以用強大的樹可視化來探索樹模型。

功能報告

米開朗基羅提供了一個功能報告，其中顯示了每個功能的順序，對模型的重要性以及部分依賴圖和分佈直方圖。選擇兩個功能，可讓用戶將功能交互理解為雙向部分依賴關係圖，如下所示：

圖7：功能，它們對模型的影響及其相互作用可以通過功能報告進行探索。

部署模型

米開朗基羅擁有，通過UI或API管理模型部署的端到端支持，以及可以部署模型的三種模式：

離線部署：該模型部署到離線容器中，並運行在Spark作業中，以按要求或重複計劃生成批量預測。

在線部署：該模型部署到在線預測服務集群（通常包含負載平衡器後面的數百台機器），客戶端可以將單個或批量預測請求作為網路RPC調用發送。

Library 部署：我們打算推出一個部署到一個服務容器的模型，該容器在另一個服務中，作為庫嵌入並通過Java API進行調用。（以下圖8中未顯示，但與在線部署相似）。

圖8：來自模型存儲庫的模型部署到在線和離線容器進行投喂。

在所有情況下，所需的模型數據（元數據文件，模型參數文件和已編譯的DSL表達式）打包在ZIP存檔中，並使用我們的標準代碼部署基礎架構，將其複製到Uber數據中心的相關主機。預測容器自動從磁碟載入新模型，並開始處理預測請求。

許多團隊擁有自動化腳本，可通過米開朗基羅的API，安排定期的模擬再訓練和部署。在UberEATS交付時間模型運行時，數據科學家和工程師通過Web UI手動觸發訓練和部署。

生成預測

一旦模型被服務容器部署和載入，它們將用於根據從數據管道載入的特徵數據或直接從客戶端服務進行預測。原始功能通過編譯的DSL表達式傳遞，可以修改原始特徵和/或從Feature Store獲取附加功能。

最終特徵向量被構造，並傳遞給模型進行評分。在線模型運行時，通過網路將預測返回給客戶端服務。在離線模型的情況下，預測將被寫回Hive，可以通過下游批處理作業進行消費，或直接通過基於SQL的查詢工具訪問用戶，如下所示：

圖9：在線和離線預測服務使用特徵向量集來生成預測。

參考模型

可以同時將多個模型部署到給定的服務容器。這允許從舊型號到新型號的安全過渡以及模型的并行A / B測試。在服務時間，模型由其UUID和部署期間指定的可選標記（或別名）標識。

在線模型的情況下，客戶端服務與要使用的模型UUID或模型標籤，一起發送特徵向量; 在標籤的情況下，容器將使用最近部署到該標籤的模型，來生成預測。

在批量模型運行時，所有部署的模型，用於對每個批次數據集進行評分，並且預測記錄包含模型UUID和可選標記，以便消費者可以適當地過濾。

如果兩個模型，在部署新模型以替換舊模型時，具有相同的簽名（即期望相同的特徵集），則用戶可以將新模型部署到，與舊模型相同的標籤，並且容器將開始使用新模型立即。

這允許客戶更新其模型，而不需要更改其客戶端代碼。用戶還可以使用其UUID部署新模型，然後修改客戶端或中間服務中的配置，以逐漸將流量從舊模型UUID切換到新模型。

對於模型的A / B測試，用戶可以通過UUID或標籤簡單地部署競爭模型，然後使用Uber的客戶端服務中的實驗框架，將部分流量發送到每個模型並跟蹤性能指標。

規模和延遲

由於機器學習模型是無狀態的，不分享任何東西，因此在線上和離線服務模式下，它們都是微不足道的。在線模型，我們可以簡單地為預測服務集群，添加更多的主機，並讓負載均衡器擴展負載。在離線預測的情況下，我們可以添加更多的Spark執行程序，並讓Spark管理并行性。

在線服務延遲取決於模型類型和複雜性，以及模型是否需要Cassandra功能存儲區的功能。在不需要Cassandra功能的模型的情況下，我們通常會看到P95的延遲小於5毫秒（ms）。

在需要Cassandra功能的型號的情況下，我們通常會看到P95的延遲小於10ms。目前最高的交通模式每秒提供超過25萬次預測。

監控預測

當對模型進行訓練和評估時，始終使用歷史數據。為了確保模型在未來運行良好，監控其預測至關重要，以確保數據管道繼續發送準確的數據，並且生產環境沒有改變，使得模型不再準確。

為了解決這個問題，米開朗基羅可以自動記錄，並選擇性地阻止其所做的預測的百分比，然後將這些預測，加入到由數據管道生成的觀察結果（或標籤）中。

有了這些信息，我們可以生成持續的，實時的模型精度測量。在回歸模型運行下，我們將U 平方/ 確定係數，均方根對數誤差（RMSLE），均方根誤差（RMSE）和平均絕對誤差度量，發布到Uber的時間序列監測系統，以便用戶可以隨時間分析圖表並設置閾值警報，如下所示：

圖10：預測被採樣，並與觀察到的結果進行比較，以生成模型精度指標。

管理plane，API和Web UI

系統的最後一個重要部分是API層。這是系統的大腦。它包括一個管理應用程序，用於提供Web UI和網路API，並與Uber的系統監控和警報基礎架構集成。

該層還包含用於編排批處理數據管道，訓練作業，批量預測作業以及批量和在線容器部署模型的工作流系統。

米開朗基羅的用戶，通過Web UI，REST API以及監視和警報工具，直接與這些組件進行交互。

▍未來的米開朗基羅平台

在接下來的幾個月中，我們計劃繼續擴展和加強現有系統，以支持我們的客戶團隊的增長和Uber的整體業務。隨著平台層次的逐漸成熟，我們計劃投入更高層次的工具和服務，來推動機器學習的民主化，更好地支持我們的業務需求：

AutoML：這將是一個自動搜索和發現模型配置（演算法，功能集，超參數值等）的系統，該模型配置可為給定的建模問題提供最佳性能模型。

系統還將自動構建生產數據管道，以生成為模型供電所需的功能和標籤。我們已經通過我們的Feature Store，統一的離線和在線數據流水線以及超參數搜索功能來解決了大部分問題。

我們計劃通過AutoML加速我們早期的數據科學工作。該系統將允許數據科學家指定一組標籤和目標函數，然後使最多的隱私和安全感知使用Uber的數據找到問題的最佳模型。

模型可視化： 理解和調試 模型越來越重要，特別是對於深入學習。雖然我們為基於樹型的模型提供了可視化工具的一些重要的第一步，但還需要做更多的工作，以使數據科學家能夠理解，調試和調整模型，並讓用戶信任結果。

在線學習：大部分的Uber機器學習模型直接影響了Uber產品的實時性。這意味著它們在物理世界中移動物體的複雜和不斷變化的環境中運作。

為了保持模型的準確性，隨著環境的變化，我們的模型需要隨之改變。今天，團隊定期在米開朗基羅再訓練模型。

該用例的完整平台解決方案，涉及易於更新的模型類型，更快的訓練和評估架構和管道，自動化模型驗證和部署，以及複雜的監控和警報系統。

分散式深度學習：越來越多的Uber機器學習系統正在實施深度學習技術。定義和迭代深度學習模型的用戶工作流程，與標準工作流程完全不同，因此需要獨特的平台支持。

深度學慣用例通常會處理更大量的數據，而不同的硬體要求（即GPU）會激發對分散式學習的進一步投資，並與靈活的資源管理堆棧進行更緊密的集成。

★推薦閱讀★

美國計算機專業大學排名及十大熱門專業（申請攻略）

特斯拉AI主管Karpathy：通用人工智慧簡史（PPT）

亞馬遜AI主任科學家李沐打造免費中文深度學習課程

揭秘谷歌內部的萬人機器學習項目—忍者計劃！

100大機器學習數據集，總有一款適合你！

小伙用57行代碼開發系統，節省了8600萬美元

騰訊的願景：讓AI無處不在！（附PPT）

江澤民：要在AI、機器學習方面有所創新

一文盡覽人臉識別獨角獸大戰

前FB產品經理：打造機器學習產品的黃金手冊

用大數據和機器學習揭示十二星座的真實面目！

長期招聘志願者

加入「AI從業者社群」請備註個人信息

添加小雞微信 liulailiuwang