全文共6177字，預計學習時長16分鐘
機器學習（ML）被稱為技術債務的高利率信用卡。對於特定的業務問題，使用適用的模型會相對容易一些，但是要使該模型在可伸縮的生產環境中運行，並能夠處理不斷變化的混亂數據語義和關係，以及以可靠的自動化方式演進模式，則完全是另一回事。
對於機器學習生產系統而言，只有5%的實際代碼是模型本身。將一組機器學習解決方案轉變為端到端的機器學習平臺的，是一種運用了加速建模、自動化部署和確保生產中的可伸縮性和可靠性的技術的架構。
筆者此前講過lean D/MLOps，數據和機器學習操作，因為沒有數據的機器學習操作是沒有意義的，所以端到端機器學習平臺需要進行整體構建。CI/CD基金會啟動了一個MLOps特別興趣小組(SIG)。其端到端機器學習平臺確定的步驟如下圖所示：
不過，其中掩蓋了一些不太重要的細節。例如，服務可能需要不同的技術取決於它是否是實時完成的。可伸縮的解決方案通常將模型放在一個負載均衡器後的服務集群的多個機器上的容器內運行。因此，上述圖表中的單個框並不意味著實際平臺的單個步驟、容器或組件。
這並不是對圖中步驟進行批評，而是一個警示：看似簡單的事情在實踐中可能並不那麼容易。
圖表中沒有模型（配置）管理。可以考慮諸如版本控制、實驗管理、運行時統計、用於培訓、測試和驗證數據集的數據沿襲跟蹤，從頭開始或從模型快照、超參數值、精度度量等等對模型進行再培訓的能力。
此外，圖中缺失的另一個關鍵點是檢查模型偏差的能力，例如，根據不同的維度來分割模型的關鍵性能指標。許多公司也需要能夠熱交換一個模型或並行運行多個模型。前者至關重要，可以避免模型在後臺更新時，用戶的請求進入伺服器時失敗。而後者對於A/B測試或模型驗證也舉足輕重。
從CI/CD中我們可以得出另一個觀點，它提到了版本化數據和代碼的需要，這一點經常被忽略。
谷歌：TFX
谷歌開發TensorFlow eXtended（TFX）的主要動機是將機器學習模型的生產時間從數月縮短到幾周。谷歌工程師和科學家為此焦頭爛額，因為「當機器學習需要應用於生產時，實際的工作流程將變得更加複雜。」
TensorFlow和TFX均可免費使用，不過後者在2019年才發布，比谷歌提供的ML基礎設施晚了兩年，遠不如前者成熟。
模型性能度量用於部署安全服務模型。因此，如果新模型的性能不如現有模型，它就無法投入生產。按照TFX的說法，該模型並非幸運兒。有了TFX，整個過程都是自動化的。
以下是一個開源TFX組件的基本概述：
· ExampleGen提取並分割輸入數據集。
· StatisticsGen為數據集計算統計數據。
· SchemaGen檢查統計數據並創建數據模式。
· ExampleValidator在數據集中查找異常值和缺失值。
· Transform對數據集執行特徵工程。
· Trainer使用TensorFlow對模型進行訓練。
· Evaluator分析訓練結果。
· ModelValidator確保模型的高安全性。
· Pusher將模型部署到服務基礎設施中。
TensorFlow服務是一個c++後端，服務於TensorFlow SavedModel文件。為了最小化訓練/服務偏差，TensorFlow轉換會「凍結」計算圖中的值，這樣在訓練中發現的相同值會在服務中使用。當訓練在運行時間是單一的固定值時，DAG可能會有若干個操作。
Uber: Michelangelo
大約在2015年，Uber的ML工程師注意到機器學習系統中隱藏的技術債務。Uber已經建立了一個一次性的自定義系統，與ML模型集成在一起，這在大型工程組織中不是很容易擴展。用他們自己的話來說，沒有合適的系統來建立可靠、統一和可重複的管道以創建和管理大規模的訓練和預測數據。
這就是他們創造Michelangelo的原因。它依賴於Uber的數據湖——事務性和日誌數據，支持離線（批處理）和在線（流）預測。對於脫機預測，包含的Spark作業生成批預測，而對於在線部署，模型在預測服務集群中提供服務，該集群通常由負載均衡器後面的數百臺機器組成，客戶機將單個或批預測請求作為rpc發送到該集群。
為每個實驗存儲與模型管理相關的元數據，例如，訓練師的運行時統計信息、模型配置、沿襲、分布和特性的相對重要性、模型評估指標、標準評估圖表、學習的參數值和匯總統計信息等。
Michelangelo可以在同一個服務容器中部署多個模型，這允許從舊模型版本到新模型版本的安全轉換，以及對模型的並行A/B測試。
Michelangelo的最初版本並不支持深度學習在GPU上進行訓練，但其開發團隊解決了這一遺漏問題。當前平臺使用了Spark的ML管道序列化，但是有一個用於在線服務的附加接口，該接口添加了一個單例(在線)評分方法，可以既輕量級又能夠處理緊密型SLA，例如用於欺詐檢測和預防。它通過繞過Spark SQL的Catalyst優化器的開銷來實現這一點。
值得注意的是，谷歌和Uber都為服務構建了內部協議緩衝區解析器和表示物，避免了默認實現中存在的瓶頸。
Airbnb: Bighead
基於類似原因，Airbnb在2016/2017年建立了自己的ML基礎架構團隊。首先，儘管他們只有幾款模型正在構建中，但每一款模型的構建都可能需要長達三個月的時間。第二，模型之間不存在一致性。第三，線上和線下的預測差異極大。Bighead是其努力的頂峰：
數據管理由內部工具Zipline處理。Redspot是一個託管的、集裝的、多用戶的Jupyter Notebook服務。Bighead庫用於數據轉換和管道提取，為通用模型框架提供了包裝器。其通過轉換保存元數據，因此可用於跟蹤沿襲。
Deep Thought是一個用於在線預測的REST API。Kubernetes對服務進行精心優化。對於離線預測，Airbnb則使用他們自己的自動裝置。
Netflix也面臨著與上述公司類似的問題。他們的解決方案是運用Metaflow，這是一個為數據科學家提供的Python庫，用於處理數據管理和模型訓練，而不提供預測服務。因此，它不是用於機器學習的端到端平臺，可能更適合於公司內部的用例，而不是面向用戶的用例。當然，它可以與由Kubernetes或AWS SageMaker支持的Seldon結合轉化為一個成熟的解決方案。
數據科學家將工作流程寫成DAG步驟，就像數據工程師使用Airflow一樣。和Airflow一樣，可以使用任何數據科學庫，因為Metaflow只執行Python代碼。Metaflow在後臺分布處理和訓練。所有的代碼和數據都會自動快照到S3中，以確保每個模型和實驗都有版本歷史。Pickle是默認的模型序列化格式。
開源版本還沒有內置的調度器。其鼓勵用戶「主要依賴於垂直可伸縮性」，儘管他們可以使用AWS SageMaker實現水平可伸縮性，它與AWS緊密耦合。
Lyft：Flyte
Lyft已開放了其雲本地平臺Flyte，在這個平臺上數據和機器學習操作融合在一起。這與我的D/MLOps方法相一致——數據（Ops）之於MLOps就像燃料之於火箭：沒有它將徒勞無功。
Flyte是建立於Kubernetes之上。它是由Lyft內部使用的，可以擴展到至少7000個獨特的工作流，每個月執行超過100,000次，100萬個任務和1000萬個容器。
Flyte中的所有實體都是不可變的，因此可以跟蹤數據沿襲、重現實驗和削減部署。重複任務可以利用任務緩存來節省時間和金錢。目前支持的任務包括Python、Hive、Presto和Spark以及sidecars。從原始碼來看，似乎是EKS。他們的數據目錄也是Amundsen，這與Spotify的Lexikon很像。
AWS、Azure、GCP和Co
公共雲領域的主要參與者都有自己的機器學習平臺，除了Oracle，他們只為特定的用例和行業提供封閉的基於機器學習的模型。
AWS SageMaker是一個全堆棧的機器學習解決方案，支持TensorFlow、Keras、PyTorch和MXNet。使用SageMaker Neo，可以將模型部署到雲端和邊緣。它有一個內置的功能，可以通過Amazon MechanicalTurk對S3中存儲的數據附上標籤。
谷歌沒有託管平臺，但是通過TFX、Kubeflow和AI平臺，可以將在CPU、GPU和TPUs上運行的模型所需的組件組合在一起，調優超參數，並自動部署到生產環境中。Spotify甚至選擇了TFX/Kubeflow-on-GCP選項。
除了TensorFlow，還有對scikit-learn和XGBoost的支持。自定義容器允許使用任何框架，如PyTorch。SageMaker Ground Truth的標籤服務目前處於測試階段。
Azure機器學習支持多種框架，如scikit-learn、Keras、PyTorch、XGBoost、TensorFlow和MXNet。其擁有自己的D/MLOps套件，其中包含大量的圖形。喜歡模型開發的人可以使用拖放界面，不過也附帶了各種警告。模型和實驗管理，如預期的那樣由微軟通過註冊表完成。使用Azure Kubernetes服務進行生產部署，控制轉出也是可能的。
IBM Watson ML提供了指向和點擊機器學習選項（SPSS）和對常見框架組的支持。作為兩大主要參與者之一，模型是在CPU或GPU上訓練的，超參數調優也包含在框中。該平臺沒有很多關於數據和模型驗證的細節，因為這些在其他IBM產品中是可用的。
儘管阿里巴巴的人工智慧機器學習平臺標榜著兩個流行詞，但它並沒有改進文檔，關於最佳實踐的部分寫的是用例而非建議。
不管怎樣，它在拖放方面下了功夫，特別是在數據管理和建模方面，這可能對一個自動化的端到端ML平臺幫助不大。該平臺支持諸如TensorFlow、MXNet和Caffe等框架，但它也支持大量的傳統算法。正如所料，它還包括一個超參數調諧器。
模型序列化使用PMML、TensorFlow的SavedModel格式或Caffe格式完成。請注意，採用PMML、ONNX或PFA文件的評分引擎可能會支持快速部署，但它有引入培訓/服務傾斜的風險，因為服務的模型是從不同的格式加載的。
其他平臺
H2O提供了一個使用POJO或MOJO進行數據操作、多種算法、交叉驗證、超參數調優網格搜索、特性排序和模型序列化的平臺。
valohai——芬蘭語：輕鯊，是一個管理機器學習平臺，其可在私有、公共、混合或多雲設置上運行。
每個操作（或執行）都對Docker Image運行一個命令，類似於Kubeflow。二者主要區別在於，Valohai直接管理Kubernetes部署集群，而Kubeflow要求開發人員執行這一任務。
然而，Kubeflow和TFX認為他們提供了一些與TensorFlow相關的工具。使用Valohai，需要重用現有的Docker Image，或者滾動自己的Docker Image，這意味著可使用任何機器學習框架，但是自由度必須與可維護性考慮相權衡。
因此，可以通過Spark、Horovod、TensorFlow或任何適配個人需求和基礎設施的工具來分配訓練，但這些都由個人決定。這還意味著要負責確保數據轉換的兼容性，以避免訓練/服務傾斜。注意，它目前只支持對象存儲。
Iguazio提到了從筆記本或IDE在幾秒鐘內部署的能力，儘管這似乎錯過了最常見的場景：CI/CD管道，甚至是包含TFX的Pusher組件的平臺本身。它使用Kubeflow進行工作流編制。
Iguazio確實具備功能商店，可為鍵值對和時間序列提供統一的API。儘管大多數大型科技公司都有特色商店，但許多可用的產品卻並不具備。
功能商店處於核心位置，具有可在多個模型之間共享以加速模型開發的可隨時重用的功能。它可以在企業規模上實現特性工程自動化。例如，可以從時間戳中提取許多特性：年、季節、月、星期、時間、是否為本地假日、自最新相關事件以來所經過的時間、特定事件在固定窗口中發生的頻率，等等。
SwiftStack AI通過RAPIDS套件面向NVIDIA gpu的高吞吐量深度學習。RAPIDS提供了庫，比如cuML，允許人們使用熟悉的scikit-learn API，但受益於GPU加速支持的算法，以及用於GPU驅動的圖形分析的cuGraph。
AI層是D/MLOps的API，其內置了對多個數據源、程式語言和機器學習框架的支持。
MLflow由Databricks支持，這解釋了與Spark的緊密集成。它提供了一組有限的部署選項。例如，在PySpark中將模型導出為矢量化的UDF的能力對實時系統來說不是最合理的，因為Python UDF帶來了Python運行時環境和JVM之間的通信開銷。
儘管開銷沒有使用標準PySpark UDFs那麼大，因在Python和JVM之間的傳輸中使用了Apache Arrow（一種內存中的柱狀格式），也不是無關緊要的。如果使用Spark Sreaming作為默認的數據提取解決方案，那麼使用Spark的微批處理模型可能很難實現亞秒延遲。
對日誌記錄的支持仍然處於實驗階段，這對於D/MLOps來說是非常重要的。從文檔可以看出，MLflow並不關注數據和模型驗證，至少不是平臺的標準部分。有一個MLflow的託管版本(在AWS和Azure上)提供了更多的特性。
D2iQ的KUDO for Kubeflow是一個基於Kubeflow的面向企業客戶的平臺。與開源的Kubeflow不同，它自帶Spark和Horovod，以及對TensorFlow、PyTorch和MXNet等主要框架進行預構建和完全測試的CPU/GPU圖像。數據科學家可以在筆記本中部署表單，而不需要切換情景。
默認情況下，它支持多用戶使用。集成了Istio和Dex以實現額外的安全性和身份驗證。Kubeflow的KUDO位於Konvoy之上，是D2iQ的託管Kubernetes平臺。它可以運行在雲、On-Prem、混合或在邊緣，還可用於氣隙集群的埠。
在Kubernet中，Kubeflow中的KUDO是用KUDO定義的操作符集合，KUDO是一個聲明性工具包，用於使用YAML創建Kubernetes操作符，而非Go。Kubernetes統一聲明操作符(KUDOs)的Cassandra、Elastic、Flink、Kafka、Redis等都是開源的，可以與平臺集成。
留言點讚關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範