在現實環境中部署大數據分析、數據科學和機器學習應用，分析優化和模型訓練僅佔全部工作量的25%，約50%的工作用於準備適用於分析和開展機器學習的數據，其餘25%的工作是實現易於使用的模型推理和洞察分析。數據流水線將各個過程組織在一起，爲機器學習這列重載而神奇的列車提供軌道。只有基於正確配置的流水線，方能確保項目的長期正常運行。
本文將從以下四個維度展開，闡釋數據流水線及實現各步驟的可選組件：
- 需求願景：切實瞭解用戶的願景，即可對症下藥。此節將分析各種需求，闡釋數據流水線需提供的相應工程特性。
- 流水線：此節從數據湖和數據倉庫中數據流轉的角度，從概念上闡釋數據流水線的各個過程。
- 組件選取：此節闡釋實現處理規模和速度權衡的Lambda架構，以及Lambda架構中關鍵組件在技術上的選取。此外，此節將概要給出AWS、Azure和Google Cloud提供的無服務器流水線。
- 生產環境：此節給出成功實現生產環境數據流水線的一些小提示。
需求願景
構建數據分析平臺和機器學習應用的切實用戶可歸爲三類，即數據科學家、工程人員和業務管理人員。
數據科學家的目標是針對給定的問題和可用的數據，給出魯棒性最好且計算複雜度適中的模型。
工程人員的目標是爲用戶構建可信賴的產品。工作創新之處在於構建新產品，或是以新的運行方式運行現有的產品，實現無需人工干預的7X24不間斷運行。
業務管理人員的目標是向用戶交付有價值產品。這正是科學和工程所要達成的目標。
本文聚焦於工程人員，併兼顧其它兩方面，特別是從處理機器學習應用所需海量數據的角度。由此，數據流水線所需的工程特徵爲：
- 可訪問性：數據科學家易於訪問數據，最好是能通過查詢語言訪問數據，以便開展假設評估和模型實驗。
- 可伸縮性：隨獲數據量增加而彈性擴展的能力，同時維持較低的成本。
- 效率：在設定時間開銷內給出數據和機器學習結果，滿足業務目標的需求。
- 可觀測性：對數據和流水線健康狀態自動報警，滿足主動反饋潛在業務風險的需求。
流水線
數據只有在被轉化爲具備可操作性的洞察，進而洞察得到及時得交付使用，其價值方能體現出來。
數據流水線實現端到端的操作組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。無論何時何處，只要業務目標有需求，流水線就會立刻運轉起來。
和新油田一樣，數據雖然價值不斐，但未經加工則不能真正得以應用。必須深加工爲天然氣、塑料、化學制品等方式，才能創造出有利可圖的有價實物。因此數據必須拆解分析後，才能體現出自身的價值。
——Clive Humby，英國數學家，樂購會員卡架構師
數據流水線主要包括五個過程，可分組爲三個階段：
- 數據工程：採集、獲取和準備；（佔總工作量的50%）
- 分析/機器學習：計算；（佔總工作量的25%）
- 交付：結果展示。（佔總工作量的25%）
採集：移動應用、Web網站、Web應用、微服務和IoT設備等數據源設施，按指令採集相關數據。
獲取：受控數據源將數據推送到各種設定的數據入口點，例如HTTP、MQTT和消息隊列等。也有一些任務從Google Analytics等服務導入數據。數據具有兩種形態，即BLOB和流數據。所有數據將彙總到同一數據湖中。
準備：數據通過ETL（抽取、轉化和加載）操作清洗、確證、塑形和轉化，以BLOB和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。
計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所得到的模型和洞察，無論是結構化數據還是流數據，繼續存回數據倉庫中。
結果展示：通過儀表面板、電子郵件、短信息、推送通知和微服務等方式展示所得到的洞察。機器學習模型推理將通過微服務提供接口。
數據湖和數據倉庫
在數據湖中，數據以其原始格式或初始形態存在，即按接收到的BLOB或文件格式。而數據倉庫存儲經清洗和轉換的數據，以及數據的目錄和模式。數據湖和數據倉庫中的數據以多種形態存在，包括結構化（即關係模式）、半結構化、二進制和實時事件流。
用戶可以選擇以不同的物理倉儲分別維護數據湖和數據倉庫，也可以通過Hive查詢等數據湖接口物化數據倉庫。具體如何選擇，取決於用戶在性能上的需求，以及成本約束等因素。
無論採取何種方式，重要的是保持好原始數據，以便於審計、測試和調試。
探索性數據分析（EDA,Exploratory Data Analysis）
EDA的目的是分析並可視化數據集，進而形成假設。可能已收集的數據對於實現EDA尚存差距，因此需要做進一步的收集、實驗和驗證新數據。
這些操作可被視爲一組聚焦於可能模型上的小規模機器學習實驗，可用於對比整個數據集並實現調優。
維護具有目錄、模式和可訪問查詢語言接口（無需編寫程序）的數據倉庫，有助於實現高性能的EDA。
組件選取
圖中給出了六種三角型帳篷可選，從左上到右下所需的粘合劑成本依次降低。你會在實踐中做出如何選取？請注意，三角形的底邊要小於其它的邊；淺藍色部分是矩形，而不是正方形。
數據流水線、數據湖和數據倉庫不是什麼新概念。過去，數據分析使用批處理程序完成的，例如SQL乃至Excel工作表。現在不同之處在於，可用的大數據推進了機器學習，進而增加了對實時洞察的需求。
現已有多種體系結構可供選擇，提供不同的性能和成本權衡。據我所知，從技術上考慮的最好選擇，不一定是最適合生產環境的解決方案。用戶必須仔細覈對自身的需求：
- 是否需要實時洞察或模型更新？
- 對陳舊應用的忍耐程度如何？
- 成本約束如何？
基於對上述問題的回答，用戶必須在Lambda架構中的批處理和流處理上做出權衡，以匹配對處理通量和延遲上的需求。Lambda架構由如下層級組成：
- 批處理層：提供高通量、全面、經濟的MapReduce批處理，但是延遲很高。
- 加速層：提供低延遲的實時流處理，但是在數據量很大時，實現代價可能會突破用戶內存規模。
- 服務提供層：實現高吞吐量批處理輸出（在準備就緒時）與流處理輸出的合併，以預先計算的視圖或即席查詢的形式提供全面的結果。
Lambda架構基於的假設是源數據模型是僅追加（append-only）的，即已獲取的事件會打上時間戳並追加到現有事件中，而且永遠不會被覆蓋。
架構實例：雲上技術棧的選取
下圖給出了一種使用開源技術物化實現流水線各階段的架構。爲優化計算代價，通常會合並數據準備和計算階段。
架構中的主要組件和技術選擇如下：
- 使用HTTP/MQTT終端節點獲取數據，並提供結果。這裏存在多種架構和技術可選。
- 使用發佈/訂閱消息隊列獲取海量流數據。Kafka目前是事實上的標準，其經實踐考驗，可擴展性滿足高流量數據獲取需求。
- 使用低成本高容量的數據倉儲實現數據湖和數據倉庫。可選技術包括Hadoop HDFS和AWS S3等BLOB存儲雲服務。
- 使用查詢和目錄基礎設施，實現將數據湖轉換爲數據倉庫。這裏廣泛選取的是Apache Hive。
- 使用MapReduce批處理引擎實現高通量處理，例如，Hadoop Map-Reduce、Apache Spark等。
- 使用流計算實現對低延遲性有要求的處理。例如，Apache Storm、Apache Flink。對於編寫數據流計算，Apache Beam不失爲一種新選項。它可以部署在Spark批處理和Flink流處理上。
- 使用機器學習框架實現數據科學和機器學習。例如，普遍使用的Scikit-Learn、TensorFlow和PyTorch等實現機器學習。
- 使用低延遲數據倉儲實現結果的存儲。數據倉儲上存在有很多經實踐考驗的選項，可根據數據類型、性能需求、數據規模和實現代價等做出選取。
- 可使用部署編排工具。例如Hadoop YARN、Kubernetes/Kubeflow等。
規模和效率上的權衡，由以下槓桿調節：
- 吞吐量取決於數據獲取（即REST / MQTT終端節點和消息隊列）的彈性、數據湖的存儲容量，以及MapReduce批處理。
- 延遲取決於消息隊列、流計算和存儲計算結果數據庫的效率。
架構實例：無服務器
無服務器計算可避免在項目中引入DevOps代價，實現項目的快速啓動。無服務器架構中的各種組件，可由選定的雲服務提供商的無服務器組件替換。下圖分別給出了Amazon Web Services（AWS）、Microsoft Azure和Google Cloud上典型的無服務器架構實現數據流水線。其中每個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。
生產環境
請讀者注意，圖中選擇的三角形帳篷形狀，並非需要最少粘合劑的方式。對於降低潛在的錯誤，至關重要的是如何給出所需的部分，以及整體操作的簡單性。
對於不具操作性的分析和機器學習，生產環境將成爲它們的埋葬之地。如果用戶未對7x24全天候監測流水線處理做出投資，使得在某些趨勢閾值被突破時就發出警報，那麼數據處理流水線可能會在沒有引起任何人注意的情況下失效。
請注意，工程和運營支出並非唯一的成本。在決定架構時，還應考慮時間、機會和壓力成本。
數據流水線的實操是一件非常棘手的事情。下面給出我歷經波折獲得的一些小經驗：
- 在擴展數據科學團隊之前，先擴展數據工程團隊。數據科學這列貨運列車必須先鋪設鐵軌，然後才能運行。
- 勤於清理的數據倉庫。機器學習取決於數據的質量。要定義良好的數據採集模式，並做好目錄。如果上述工作缺失，那麼用戶一定會驚訝地看到，以純字節永久存儲的數據浪費了大量的存儲空間。
- 從簡單之處開始。以無服務器架構爲起步點地，儘可能降低管理成本。僅在達到合理的投資回報率的情況下，再遷移至功能完善的數據流水線，或用戶自身進行部署。在計算階段，逐步投入儘可能小規模的適量投資。通過調度SQL查詢和雲功能實現計算，甚至是實現爲“無計算模式”。這樣可以更快地準備好整個流水線，爲用戶專注於數據策略制定以及數據模式和目錄提供充足的時間。
- 只有在經過仔細評估後，再着手構建。用戶的業務目標是什麼？必須使用哪些槓桿來調節業務產出？哪些洞察將是可行的？收集數據，並基於數據構建機器學習。
總結
本文的要點總結如下：
- 分析調優和機器學習模型僅是總工作量的25%；
- 儘早投資於數據流水線，機器學習的優劣取決於數據的質量；
- 對於探索性任務，需確保數據易於訪問；
- 從業務目標入手，尋求給出能落地的洞察。
希望本文對讀者能有所幫助。讀者在生產環境中建立可靠的數據流水線有哪些技巧？歡迎在評論中分享。
作者簡介：
Satish Chandra Gupta是Slang Labs的合夥創始人之一。Slang Labs正在構建一個使程序開發者可以輕鬆快速地將多語言、多模式語音增強體驗（VAX）添加到移動和Web應用中的平臺。設想Alexa或Siri這樣的助手，可以運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼令人興奮。
原文鏈接：
Architecture for High-Throughput Low-Latency Big Data Pipeline on Cloud