使用Kafka本機模型服務器進行流式機器學習

離開了編程我會死

本文章探討了使用Kafka進行模型部署的三個選項之間的架構和取舍：將模型嵌入到Kafka應用程序中，模型服務器和RPC，模型服務器以及Kafka本地通信。

Kafka和機器學習架構

模型部署通常與模型訓練完全分開（從過程和技術角度而言）。通常在彈性雲基礎架構或數據湖（例如Hadoop或Spark）中執行模型訓練。模型評分（即進行預測）通常是具有不同正常運行時間SLA和延遲要求的關鍵任務工作負載。

在Kafka基礎架構中進行模型部署的兩種方法：將模型嵌入到Kafka應用程序中，或者將其部署到單獨的模型服務器中。以下內容探討了這兩個選項的權衡，並介紹了第三個選項：Kafka原生流模型服務器。

Kafka應用程序與模型服務器之間的RPC

分析模型已部署到模型服務器中。流式Kafka應用程序執行請求-響應調用，以將輸入數據發送到模型並接收預測作為回報。

幾乎每個ML產品或框架都提供一個模型服務器。這包括TensorFlow等開放源框架以及相關的模型服務器TF Serving，還包括SAS等專有工具，DataRobot等AutoML供應商以及來自所有主要雲提供商（例如AWS，Azure，GCP）的雲ML服務。

使用RPC的模型服務器的優缺點

使用Kafka結合基於RPC的模型服務器和HTTP / gRPC進行權衡：

與現有技術和組織流程的簡單集成

應用程序與模型服務器之間的可用性、可伸縮性以及延遲/吞吐量的緊密耦合

關注點分離（例如Python模型+ Java流應用程序）

有限的可擴展性和健壯性

以後也可以遷移到實際流

內置用於不同模型、版本控制和A / B測試的模型管理

內置模型監控

將模型嵌入到Kafka應用程序中

分析模型只是二進制文件，即存儲在內存或持久性存儲中的文件。

數據類型不同，並且取決於ML框架。任何模型都可以嵌入到Kafka應用程序中（如果ML解決方案提供編程API，但幾乎所有工具都可以做到）。

用於嵌入模型的Kafka應用程序可以是Kafka本機流處理引擎（例如Kafka Streams或ksqlDB），也可以是使用任何Kafka客戶端（例如Java，Scala，Python，Go，C，C ++等）的“常規” Kafka應用程序。

將分析模型嵌入Kafka應用程序的利弊

將分析模型嵌入到Kafka應用程序中的權衡取舍：

最佳延遲是本地推理而不是遠程調用

Kafka Streams應用程序的可用性，可伸縮性和延遲/吞吐量之間沒有耦合

離線推斷（設備，邊緣處理等）

無副作用（例如，如果發生故障），全部由Kafka處理（例如，僅一次）覆蓋

沒有內置的模型管理和監控

Kafka原生流模型服務器

Kafka原生流模型服務器結合了上述兩種方法的一些特征。通過為模型服務器提供所有預期功能，它可以使關注點分離。但是模型服務器不使用通過HTTP / gRPC進行的RPC通信，這不會為流式傳輸體系結構帶來所有缺點。相反，模型服務器通過本機Kafka協議和Kafka主題與客戶端應用程序進行通信。

Kafka原生流模型服務器的優缺點

Kafka原生流模型服務器的權衡：

通過Kafka原生流通信的良好延遲

Kafka Streams應用程序的可用性，可伸縮性和延遲/吞吐量之間的某種耦合

一些副作用（例如，在失敗的情況下），但是Kafka處理涵蓋了大多數潛在問題（例如，通過Kafka主題進行的去耦和持久性）

內置用於不同模型，版本控制和A / B測試的模型管理

內置模型監控

模型服務器的可伸縮性和健壯性不一定像Kafka一樣（因為基礎實現通常不是Kafka原生的）

Kafka本機流模型服務器提供了流體系結構的許多優點以及模型服務器的功能。請注意，Kafka本機接口並不意味著模型服務器本身是使用Kafka在後台實現的。

在流式機器學習架構中，所有模型部署選項都需要權衡取舍

本介紹了在Kafka基礎架構中部署模型的三種選擇：具有RPC的模型服務器，將模型嵌入到Kafka應用程序中以及Kafka本機模型服務器。這三個都需要權衡，了解他們，並為您的項目評估正確的選擇。方便的是，從一種方法轉換為另一種方法也很簡單。