Categories
程式開發

高通量低延遲的雲環境大數據流水線架構


在現實環境中部署大數據分析、數據科學和機器學習應用,分析優化和模型訓練僅佔全部工作量的25%,約50%的工作用於準備適用於分析和開展機器學習的數據,其餘25 %的工作是實現易於使用的模型推理和洞察分析。數據流水線將各個過程組織在一起,為機器學習這列重載而神奇的列車提供軌道。只有基於正確配置的流水線,方能確保項目的長期正常運行。

本文將從以下四個維度展開,闡釋數據流水線及實現各步驟的可選組件:

  • 需求願景:切實了解用戶的願景,即可對症下藥。此節將分析各種需求,闡釋數據流水線需提供的相應工程特性。
  • 流水線:此節從數據湖和數據倉庫中數據流轉的角度,從概念上闡釋數據流水線的各個過程。
  • 組件選取:此節闡釋實現處理規模和速度權衡的Lambda架構,以及Lambda架構中關鍵組件在技術上的選取。此外,此節將概要給出AWS、Azure和Google Cloud提供的無服務器流水線。
  • 生產環境:此節給出成功實現生產環境數據流水線的一些小提示。

需求願景

高通量低延遲的雲環境大數據流水線架構 1

圖1 需求願景就是從最有利的角度給出觀察

構建數據分析平台和機器學習應用的切實用戶可歸為三類,即數據科學家、工程人員和業務管理人員。

數據科學家的目標是針對給定的問題和可用的數據,給出魯棒性最好且計算複雜度適中的模型。

工程人員的目標是為用戶構建可信賴的產品。工作創新之處在於構建新產品,或是以新的運行方式運行現有的產品,實現無需人工干預的7X24不間斷運行。

業務管理人員的目標是向用戶交付有價值產品。這正是科學和工程所要達成的目標。

本文聚焦於工程人員,並兼顧其它兩方面,特別是從處理機器學習應用所需海量數據的角度。由此,數據流水線所需的工程特徵為:

  • 可訪問性:數據科學家易於訪問數據,最好是能通過查詢語言訪問數據,以便開展假設評估和模型實驗。
  • 可伸縮性:隨獲數據量增加而彈性擴展的能力,同時維持較低的成本。
  • 效率:在設定時間開銷內給出數據和機器學習結果,滿足業務目標的需求。
  • 可觀測性:對數據和流水線健康狀態自動報警,滿足主動反饋潛在業務風險的需求。

流水線

高通量低延遲的雲環境大數據流水線架構 2

圖2 成功的機器學習必需具備運作潤滑的數據流水線

數據只有在被轉化為具備可操作性的洞察,進而洞察得到及時得交付使用,其價值方能體現出來。

數據流水線實現端到端的操作組,其中包括數據收集、洞察轉換、模型訓練,洞察交付和應用模型。無論何時何處,只要業務目標有需求,流水線就會立刻運轉起來。

和新油田一樣,數據雖然價值不斐,但未經加工則不能真正得以應用。必須深加工為天然氣、塑料、化學製品等方式,才能創造出有利可圖的有價實物。因此數據必須拆解分析後,才能體現出自身的價值。

——Clive Humby,英國數學家,樂購會員卡架構師

數據流水線主要包括五個過程,可分組為三個階段:

  • 數據工程:採集、獲取和準備;(佔總工作量的50%)
  • 分析/機器學習:計算;(佔總工作量的25%)
  • 交付:結果展示。 (佔總工作量的25%)

採集:移動應用、Web網站、Web應用、微服務和IoT設備等數據源設施,按指令採集相關數據。

獲取:受控數據源將數據推送到各種設定的數據入口點,例如HTTP、MQTT和消息隊列等。也有一些任務從Google Analytics等服務導入數據。數據具有兩種形態,即BLOB和流數據。所有數據將匯總到同一數據湖中。

準備:數據通過ETL(抽取、轉化和加載)操作清洗、確證、塑形和轉化,以BLOB和流數據在數據湖中分門別類管理。準備好機器學習可用的數據,並存儲在數據倉庫中。

計算:實現分析、數據科學和機器學習。計算可組合批處理和流處理。所得到的模型和洞察,無論是結構化數據還是流數據,繼續存回數據倉庫中。

結果展示:通過儀表面板、電子郵件、短信息、推送通知和微服務等方式展示所得到的洞察。機器學習模型推理將通過微服務提供接口。

高通量低延遲的雲環境大數據流水線架構 3

圖3 數據流水線各處理過程

數據湖和數據倉庫

數據湖中,數據以其原始格式或初始形態存在,即按接收到的BLOB或文件格式。而數據倉庫存儲經清洗和轉換的數據,以及數據的目錄和模式。數據湖和數據倉庫中的數據以多種形態存在,包括結構化(即關係模式)、半結構化、二進制和實時事件流。

用戶可以選擇以不同的物理倉儲分別維護數據湖和數據倉庫,也可以通過Hive查詢等數據湖接口物化數據倉庫。具體如何選擇,取決於用戶在性能上的需求,以及成本約束等因素。

無論採取何種方式,重要的是保持好原始數據,以便於審計、測試和調試。

探索性數據分析(EDA,Exploratory Data Analysis)

EDA的目的是分析並可視化數據集,進而形成假設。可能已收集的數據對於實現EDA尚存差距,因此需要做進一步的收集、實驗和驗證新數據。

這些操作可被視為一組聚焦於可能模型上的小規模機器學習實驗,可用於對比整個數據集並實現調優。

維護具有目錄、模式和可訪問查詢語言接口(無需編寫程序)的數據倉庫,有助於實現高性能的EDA。

組件選取

高通量低延遲的雲環境大數據流水線架構 4

圖4 體系架構需在性能和成本之間取得權衡

圖中給出了六種三角型帳篷可選,從左上到右下所需的粘合劑成本依次降低。你會在實踐中做出如何選取?請注意,三角形的底邊要小於其它的邊;淺藍色部分是矩形,而不是正方形。

數據流水線、數據湖和數據倉庫不是什麼新概念。過去,數據分析使用批處理程序完成的,例如SQL乃至Excel工作表。現在不同之處在於,可用的大數據推進了機器學習,進而增加了對實時洞察的需求。

現已有多種體系結構可供選擇,提供不同的性能和成本權衡。據我所知,從技術上考慮的最好選擇,不一定是最適合生產環境的解決方案。用戶必須仔細核對自身的需求:

  • 是否需要實時洞察或模型更新?
  • 對陳舊應用的忍耐程度如何?
  • 成本約束如何?

基於對上述問題的回答,用戶必須在Lambda架構中的批處理和流處理上做出權衡,以匹配對處理通量和延遲上的需求。 Lambda架構由如下層級組成:

  • 批處理層:提供高通量、全面、經濟的MapReduce批處理,但是延遲很高。
  • 加速層:提供低延遲的實時流處理,但是在數據量很大時,實現代價可能會突破用戶內存規模。
  • 服務提供層:實現高吞吐量批處理輸出(在準備就緒時)與流處理輸出的合併,以預先計算的視圖或即席查詢的形式提供全面的結果。

Lambda架構基於的假設是源數據模型是僅追加(append-only)的,即已獲取的事件會打上時間戳並追加到現有事件中,而且永遠不會被覆蓋。

架構實例:雲上技術棧的選取

下圖給出了一種使用開源技術物化實現流水線各階段的架構。為優化計算代價,通常會合併數據準備和計算階段。

高通量低延遲的雲環境大數據流水線架構 5

圖5 使用開源技術構建的數據處理流水線

架構中的主要組件和技術選擇如下:

  • 使用HTTP/MQTT終端節點獲取數據,並提供結果。這裡存在多種架構和技術可選。
  • 使用發布/訂閱消息隊列獲取海量流數據。Kafka目前是事實上的標準,其經實踐考驗,可擴展性滿足高流量數據獲取需求。
  • 使用低成本高容量的數據倉儲實現數據湖和數據倉庫。可選技術包括Hadoop HDFSAWS S3等BLOB存儲雲服務。
  • 使用查詢和目錄基礎設施,實現將數據湖轉換為數據倉庫。這裡廣泛選取的是Apache Hive
  • 使用MapReduce批處理引擎實現高通量處理,例如,Hadoop Map-ReduceApache Spark等。
  • 使用流計算實現對低延遲性有要求的處理。例如,Apache StormApache Flink。對於編寫數據流計算,Apache Beam不失為一種新選項。它可以部署在Spark批處理和Flink流處理上。
  • 使用機器學習框架實現數據科學和機器學習。例如,普遍使用的Scikit-LearnTensorFlowPyTorch等實現機器學習。
  • 使用低延遲數據倉儲實現結果的存儲。數據倉儲上存在有很多經實踐考驗的選項,可根據數據類型、性能需求、數據規模和實現代價等做出選取。
  • 可使用部署編排工具。例如Hadoop YARNKubernetes/Kubeflow等。

規模和效率上的權衡,由以下槓桿調節:

  • 吞吐量取決於數據獲取(即REST / MQTT終端節點和消息隊列)的彈性、數據湖的存儲容量,以及MapReduce批處理。
  • 延遲取決於消息隊列、流計算和存儲計算結果數據庫的效率。

架構實例:無服務器

無服務器計算可避免在項目中引入DevOps代價,實現項目的快速啟動。無服務器架構中的各種組件,可由選定的雲服務提供商的無服務器組件替換。下圖分別給出了Amazon Web Services(AWS)、Microsoft Azure和Google Cloud上典型的無服務器架構實現數據流水線。其中每個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此為參考,可選取入圍的技術。

高通量低延遲的雲環境大數據流水線架構 6

圖6 Amazon Web Services(AWS)的無服務器數據流水線架構

高通量低延遲的雲環境大數據流水線架構 7

圖7 Microsoft Azure的無服務器數據流水線架構

高通量低延遲的雲環境大數據流水線架構 8

圖8 Google Cloud的無服務器數據流水線架構

生產環境

高通量低延遲的雲環境大數據流水線架構 9

圖9 對於生產環境,簡單性往往優於完美

請讀者註意,圖中選擇的三角形帳篷形狀,並非需要最少粘合劑的方式。對於降低潛在的錯誤,至關重要的是如何給出所需的部分,以及整體操作的簡單性。

對於不具操作性的分析和機器學習,生產環境將成為它們的埋葬之地。如果用戶未對7×24全天候監測流水線處理做出投資,使得在某些趨勢閾值被突破時就發出警報,那麼數據處理流水線可能會在沒有引起任何人注意的情況下失效。

請注意,工程和運營支出並非唯一的成本。在決定架構時,還應考慮時間、機會和壓力成本。

數據流水線的實操是一件非常棘手的事情。下面給出我歷經波折獲得的一些小經驗:

  • 在擴展數據科學團隊之前,先擴展數據工程團隊。數據科學這列貨運列車必須先鋪設鐵軌,然後才能運行。
  • 勤於清理的數據倉庫。機器學習取決於數據的質量。要定義良好的數據採集模式,並做好目錄。如果上述工作缺失,那麼用戶一定會驚訝地看到,以純字節永久存儲的數據浪費了大量的存儲空間。
  • 從簡單之處開始。以無服務器架構為起步點地,盡可能降低管理成本。僅在達到合理的投資回報率的情況下,再遷移至功能完善的數據流水線,或用戶自身進行部署。在計算階段,逐步投入盡可能小規模的適量投資。通過調度SQL查詢和雲功能實現計算,甚至是實現為“無計算模式”。這樣可以更快地準備好整個流水線,為用戶專注於數據策略制定以及數據模式和目錄提供充足的時間。
  • 只有在經過仔細評估後,再著手構建。用戶的業務目標是什麼?必須使用哪些槓桿來調節業務產出?哪些洞察將是可行的?收集數據,並基於數據構建機器學習。

總結

本文的要點總結如下:

  • 分析調優和機器學習模型僅是總工作量的25%;
  • 儘早投資於數據流水線,機器學習的優劣取決於數據的質量;
  • 對於探索性任務,需確保數據易於訪問;
  • 從業務目標入手,尋求給出能落地的洞察。

希望本文對讀者能有所幫助。讀者在生產環境中建立可靠的數據流水線有哪些技巧?歡迎在評論中分享。

作者簡介:

Satish Chandra Gupta是Slang Labs的合夥創始人之一。 Slang Labs正在構建一個使程序開發者可以輕鬆快速地將多語言、多模式語音增強體驗(VAX)添加到移動和Web應用中的平台。設想Alexa或Siri這樣的助手,可以運行在用戶的應用內部,並針對用戶應用量身定制,聽上去多麼令人興奮。

原文鏈接:

Architecture for High-Throughput Low-Latency Big Data Pipeline on Cloud