如何使用Kafka在生產環境構建大規模機器學習

01-28

作者 | Kai Waehner
譯者 | 薛命燈
編輯 | Vincent
AI前線出品｜ ID：ai-front

AI 前線導語：「這篇文章將介紹機器學習在任務關鍵型實時系統中的應用，將 Apache Kafka 作為中心化的、可伸縮的任務關鍵型系統，同時還將介紹使用 Kafka Streams API 來構建智能流式應用」。

智能實時應用為所有行業帶來了革命性變化。機器學習及其分支深度學習正蓬勃發展，因為機器學習讓計算機能夠在無人指引的情況下挖掘深藏的洞見。這種能力正是多種領域所需要的，如非結構化數據分析、圖像識別、語音識別和智能決策，這完全不同於傳統的編程方式（如 Java、.NET 或 Python）。

機器學習並非新生事物，大數據集的出現和處理能力的進步讓每一個企業都具備了構建分析模型的能力。各行各業都在將分析模型應用在企業應用和微服務上，用以增長利潤、降低成本，或者改善用戶體驗。

可伸縮的任務關鍵型實時系統

互聯網、智能手機和持續在線思維的出現改變了人們的行為方式。其中就包括人們對與設備、產品和服務交互方式的期待：人們希望能夠實時地獲得信息。這也給企業帶來了巨大挑戰：如何快速地採取行動才能把握先機。批處理系統已經無法滿足需求，取而代之的應該是實時系統。

傳統企業可以實現非常強大的實時處理機制來滿足日常的業務需求。這通常需要藉助領域知識來理解各種應用場景，並構建新的流式分析模型來增加業務價值。流式處理已經存在於各個行業中。

欺詐檢測。將支付信息與歷史數據或已知的模式關聯起來，在欺詐發生之前將其檢測出來。這對處理速度提出了很高的要求，因為你必須在交易發生之前將其取消掉。
交叉銷售。利用客戶數據為客戶提供定製化的銷售方案或折扣，爭取讓客戶在離開商店之前成交訂單。這種情況下，你需要利用實時數據（比如位置數據、支付數據）和歷史數據（來自你的 CRM 系統或 Loyalty 平台）為每個客戶提供最合適的銷售方案。
預測性維護。使用機器數據來預測機器故障，在發生故障之前將舊的部件更換掉。從實際情況來看，這可以節省大量的金錢（製造）、增加利潤（自動售賣機）或提升用戶體驗（電信網路故障預測）。

所有這些場景都有一個共同點，那就是在數據產生的同時處理數據。你必須儘快地處理已經發生的事件，是主動處理，而不是被動處理。你的系統需要在欺詐發生之前，或在顧客離開商店之前，或在機器發生故障之前做出決策。

當然，這並不是說一定要求毫秒級別的響應時間。在某些情況下，即使是批處理也是沒有問題的。比如，大部分製造行業或物聯網場景中，預測性維護可以允許幾個小時甚至幾天的時間間隔，更換部件可以在當天或當周內完成。這樣可以節省大量的金錢，因為你可以在問題發生之前檢測出它們，避免造成更大範圍的損失。

在智能實時系統中應用機器學習

任務關鍵型實時應用系統在不使用機器學習的情況下已經存在多年，那為什麼說機器學習將給這一領域帶來革命性的變化？

如果你讀過有關機器學習及其分支深度學習的資料，你經常會看到如下的一些場景。

圖像識別。上傳一張圖片到 Facebook 上，圖像中的物體——比如你的朋友、背景或你手中的啤酒——就會被分析出來。
語音翻譯。機器人因此可以通過生成的文本或聲音與人類進行互動。
仿人類行為。IBM Watson 擊敗了最強大的 Jeopardy 選手；Google 的 AlphaGo 戰勝了最專業的 Go 選手。

上述的例子與那些想要構建創新型應用系統並從競爭當中脫穎而出的企業有著越來越緊密的聯繫。類似的，我們可以將機器學習應用在「傳統場景」里，比如欺詐檢測、交叉銷售或預測性維護，以此來增強業務流程，基於數據驅動做出更好的決策。已有的業務流程可以保持原樣，你只需要將業務邏輯和規則替換成分析模型來改進自動化決策即可。

下面將介紹如何將 Kafka 作為流式平台來構建、運營和監控大規模、任務關鍵型的分析模型。

機器學習——分析模型的開發生命周期

先讓我們了解一下分析模型的開發生命周期：

構建：使用機器學習演算法（如 GLM、Naive Bayes、Random Forest、Gradient Boosting、Neural Networks 等）分析歷史數據，挖掘洞見。在這一步需要進行數據的收集、準備和轉換。
驗證：使用一些驗證技術（如交叉驗證）再次確認分析模型能夠處理新的輸入數據。
運營：將分析模型部署到生產環境。
監控：觀察分析模型的輸出。這裡包含了兩部分內容：在達到某個閾值時發送告警（業務層面的監控）；保持結果的準確性和度量指標的質量（分析模型的監控）。
持續循環：重複上述步驟來改進分析模型，可以通過手動批次的方式來完成，也可以在線完成，在新事件達到時更新模型。

整個團隊在一開始就要在一起工作，並考慮如下問題：

它需要在生產環境有怎樣的表現？
生產環境系統支持哪些技術？
如何監控模型的推理和性能？
是構建一個完整的機器學習基礎設施還是使用已有的框架來分離模型訓練和模型推理？

例如，一個數據科學家開發出一個 Python 程序，創建了一個精確度非常高的模型，但如果你無法將它部署到生產環境（因為它無法伸縮也無法表現得如預期一樣），它就毫無用處。這個時候，或許你已經可以意識到為什麼 Apache Kafka 如此適合用在生產環境的分析模型上。下面的章節將介紹使用 Apache Kafka 作為流式平台以及結合機器學習或深度學習框架來構建、運營和監控分析模型。

機器學習和 Apache Kafka 架構參考

在了解了機器學習開發生命周期之後，接下來我們來看一個用於構建、營運和監控分析模型的架構參考：

該架構的核心之處在於它使用 Kafka 作為各種數據源、模型構建環境以及生產環境應用程序之間的媒介。

用於構建模型的特徵數據從各個應用程序和資料庫流入 Kafka。模型構建環境可以是一個數據倉庫、一個大數據環境（如 Spark 或 Hadoop）或者一個運行 Python 腳本的伺服器。模型可以被部署在某個地方，只要生產環境的應用程序能夠訪問到它們，並把它們應用在輸入樣本數據上。生產環境的應用程序可以從 Kafka 數據管道接收數據，或者使用 Kafka Streams API。

Kafka 成為整個系統的中樞神經，這也帶來了如下好處：

數據管道變得更簡單的了。
分析模型的構建和服務之間不再耦合。
根據具體情況使用實時模式或批處理模式。
分析模型可以被部署到高性能、可伸縮的任務關鍵型環境里。

除了 Kafka 本身，還可以加入 Kafka 生態系統的其他開源組件，如 Kafka Connect、Kafka Streams、Confluent REST Proxy、Confluent Schema Registry 或者 KSQL，而不僅僅是使用 Kafka Producer 和 Consumer API。

下面兩個章節將介紹如何使用 Kafka Steams API 來部署分析模型。

機器學習開發生命周期示例

現在我們來深入了解一個圍繞 Kafka 構建的機器學習架構示例：

在綠色區域，我們可以看到用於構建和驗證分析模型的組件。在橙色區域，我們可以看到流式平台，分析模型就部署在該平台上，用於對新事件做出推理以及執行監控。

數據生產者持續地發送事件，分析平台以批次或實時的方式接收這些數據，然後使用機器學習演算法來構建分析模型。分析模型被部署在流式平台上，流式平台將分析模型應用在事件上，從而推理出結果（也就是預測），最後結果被發送給數據消費者。

在這個例子里，我們將模型訓練和模型推理分離開，這在當今的大部分機器學習項目中是很常見的做法。

模型訓練

數據經由 Kafka 集中到 Hadoop 集群上，進而使用 H2O.ai 分析這些歷史數據，構建出神經網路。數據科學家可以使用各種介面來完成這項工作——R 語言、Python、Scala、Web UI Notebook 等。模型的構建和驗證就發生在 Hadoop 集群上，最後得到一個 Java 位元組碼形式的分析模型，接下來就可以將它們部署到生產環境。

模型推理

神經網路被部署到 Kafka Streams 應用程序里。Streams 應用程序可以運行在任何地方，它可以作為單獨的 Java 進程運行，也可以運行在 Docker 容器里或 Kubernetes 集群上。模型被實時地應用在每一個新生成的事件上。Kafka Streams 藉助 Kafka 集群為我們提供了可伸縮、任務關鍵型的分析模型操作以及高性能的模型推理。

在線模型訓練

除了分離模型訓練和模型推理，我們也可以為在線模型訓練構建一個完整的基礎設施。很多巨頭科技公司（比如 LinkedIn）在過去就將 Apache Kafka 作為模型的輸入、訓練、推理和輸出的基礎。當然，這種做法存在一些權衡。大部分傳統的公司會使用第一種方案，它可以滿足現今大部分的使用場景。

模型監控和告警

將分析模型部署到生產環境只是第一步，對模型的準確性、分數、SLA 和其他度量指標進行監控並自動實時地發出告警也同樣重要。度量指標可以通過 Kafka 反饋給機器學習工具，用於改進模型。使用 H2O.ai 開發分析模型

以下是使用 H2O 來構建分析模型的例子。H2O 是一個開源的機器學習框架，它在內部使用了其他框架，如 Apache Spark 或 TensorFlow。數據科學家可以在上面使用他們喜歡的編程語言，如 R 語言、Python 或 Scala。H2O 引擎會生成 Java 位元組碼，可以很方便地通過 Streams 進行伸縮。

下面是使用 H2O.ai Flow（Web UI 或 Notebook）和 R 語言構建分析模型的截圖：

輸出的是一個位元組碼形式的分析模型，它可以直接部署到任務關鍵型的生產環境里。因此，我們就不再需要花時間去考慮如何將 Python 或 R 生成的模型「移植」到基於 Java 平台的生產系統里。

這個例子使用 H2O 來產生 Java 位元組碼，當然，你也可以使用其他框架（如 TensorFlow、Apache MXNet 或 DeepLearning4J）完成類似的工作。

使用 Kafka Steams API 部署分析模型

使用 Kafka Streams 來部署分析模型非常簡單，只要將模型添加到基於 Streams 構建的應用程序里就可以了，然後將其應用在新生成的事件上。

因為 Kafka Streams 應用程序實際上用到了 Kafka 的特性，所以已經具備了伸縮性和任務關鍵型用途，不需要對模型做出任何調整。

例子的代碼可以在 GitHub 上找到：

https://github.com/kaiwaehner/kafka-streams-machine-learning-examples

拉取項目代碼，運行 maven 構建命令，就可以看到 H2O 模型是如何與 Kafka Streams 應用集成在一起的。後續我們會不斷擴充這個例子，加入更多複雜的應用場景，不僅使用 H2O，還會加入 TensorFlow 和 DeepLearning4J。

藉助一些 CI/CD 工具，如 Maven、Gradle、Chef、Puppet、Jenkins，機器學習與流式處理相結合的方式可以很容易地被集成到自動化持續集成工作流當中。

使用開放標準在訓練和推理之間共享分析模型

以下是其他一些用於在數據科學家之間共享和更新模型以及 DevOps 團隊部署模型的方式。

原生模型（Native Model）：直接將模型部署到流式處理引擎里，比如通過 JNI 將 Python 模型部署到 Java 應用程序里
位元組碼生成（Generated Code）：不管使用哪一種編程語言來構建模型，都可以通過生成二進位庫或源代碼的方式將它們部署到流式處理應用里。它們經過優化，可以獲得更好的性能。例如，數據科學家使用 R 語言或 Python 訓練的模型可以轉成 Java 位元組碼的形式。
外部伺服器（External Server）：以請求和響應的方式調用外部的分析伺服器。外部調用可以通過 SAS、MATLAB、KNIME 或 H2O 這類分析工具來完成，它們一般會提供 REST 介面。
PMML（預測模型標記語言）：這是一種比較古老的 XML 標準，儘管還存在一些局限和不足，一些分析工具仍然在支持它。
PFA（可移植分析格式）：一種新標準，可以為模型提供預處理，利用了 JSON、Apache Avro，並支持 Hadrian。不過大部分分析工具並沒有為它提供開箱即用的支持。

以上這些方案之間存在權衡的關係。例如，PFA 帶來了獨立性和可移植性，但同時也存在一些限制。從 Kafka 角度來看，如果要部署大規模的任務關鍵型系統，使用 Java 位元組碼生成的方式會更加合適，因為這種方式具有更高的性能、更容易伸縮，並且更容易嵌入到 Kafka Streams 應用中。同時，在進行模型預測時，它免去了與外部 REST 伺服器交互的成本。

結論

機器學習為行業帶來了價值，Kafka 迅速成為很多企業的中樞神經系統。我們可以藉助 Kafka 來：

進行實時的模型推理
監控和告警
在線訓練模型
將數據攝取到批次層或分析集群上進行分析模型的訓練

查看英文原文

https://www.confluent.io/blog/build-deploy-scalable-machine-learning-production-apache-kafka/

－全文完－

關注人工智慧的落地實踐，與企業一起探尋 AI 的邊界，AICon 全球人工智慧技術大會火熱售票中，8 折倒計時一周搶票，詳情點擊：

http://t.cn/Rl2MftP

《深入淺出TensorFlow》迷你書現已發布，關注公眾號「AI前線」，ID：ai-front，回復關鍵字：TF，獲取下載鏈接！