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

    智能實時應用爲全部行業帶來了革命性變化。機器學習及其分支深度學習正蓬勃發展，由於機器學習讓計算機可以在無人指引的狀況下挖掘深藏的洞見。這種能力正是多種領域所須要的，如非結構化數據分析、圖像識別、語音識別和智能決策，這徹底不一樣於傳統的編程方式（如 Java、.NET 或 Python）。機器學習並不是新生事物，大數據集的出現和處理能力的進步讓每個企業都具有了構建分析模型的能力。各行各業都在將分析模型應用在企業應用和微服務上，用以增加利潤、下降成本，或者改善用戶體驗。    

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

---

    互聯網、智能手機和持續在線思惟的出現改變了人們的行爲方式。其中就包括人們對與設備、產品和服務交互方式的期待：人們但願可以實時地得到信息。這也給企業帶來了巨大挑戰：如何快速地採起行動才能把握先機。批處理系統已經沒法知足需求，取而代之的應該是實時系統。傳統企業能夠實現很是強大的實時處理機制來知足平常的業務需求。這一般須要藉助領域知識來理解各類應用場景，並構建新的流式分析模型來增長業務價值。流式處理已經存在於各個行業中。

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

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

固然，這並非說必定要求毫秒級別的響應時間。在某些狀況下，即便是批處理也是沒有問題的。好比，大部分製造行業或物聯網場景中，預測性維護能夠容許幾個小時甚至幾天的時間間隔，更換部件能夠在當天或當週內完成。這樣能夠節省大量的金錢，由於你能夠在問題發生以前檢測出它們，避免形成更大範圍的損失。

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

---

 任務關鍵型實時應用系統在不使用機器學習的狀況下已經存在多年，那爲何說機器學習將給這一領域帶來革命性的變化？ 若是你讀過有關機器學習及其分支深度學習的資料，你常常會看到以下的一些場景。

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

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

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

---

 先讓咱們瞭解一下分析模型的開發生命週期：

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

整個團隊在一開始就要在一塊兒工做，並考慮以下問題：

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

例如，一個數據科學家開發出一個 Python 程序，建立了一個精確度很是高的模型，但若是你沒法將它部署到生產環境（由於它沒法伸縮也沒法表現得如預期同樣），它就毫無用處。這個時候，或許你已經能夠意識到爲何 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 構建的機器學習架構示例：

  

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

• 數據生產者持續地發送事件，分析平臺以批次或實時的方式接收這些數據，而後使用機器學習算法來構建分析模型。

• 分析模型被部署在流式平臺上，流式平臺將分析模型應用在事件上，從而推理出結果（也就是預測），最後結果被髮送給數據消費者。

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

• 模型訓練:  數據經由 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/
• https://36kr.com/p/5101194.html