高通量低延遲的雲環境Big Data 流水線Architecture

謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

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

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

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

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

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

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

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

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

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

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

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

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

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

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

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

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

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

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

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

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

總結

本文的要點總結以下：

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

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

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。
謝謝平臺提供-http://bjbsair.com/2020-04-13...

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

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

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

需求願景

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

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

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

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

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

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

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

流水線

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

數據只有在被轉化爲具有可操做性的洞察，進而洞察獲得及時得交付使用，其價值方能體現出來。

數據流水線實現端到端的操做組，其中包括數據收集、洞察轉換、模型訓練，洞察交付和應用模型。不管什麼時候何處，只要業務目標有需求，流水線就會馬上運轉起來。

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

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

數據流水線主要包括五個過程，可分組爲三個階段：

• 數據工程：採集、獲取和準備；（佔總工做量的 50%）
• 分析 / 機器學習：計算；（佔總工做量的 25%）
• 交付：結果展現。（佔總工做量的 25%）

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

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

準備：數據經過 ETL（抽取、轉化和加載）操做清洗、確證、塑形和轉化，以 BLOB 和流數據在數據湖中分門別類管理。準備好機器學習可用的數據，並存儲在數據倉庫中。

計算：實現分析、數據科學和機器學習。計算可組合批處理和流處理。所獲得的模型和洞察，不管是結構化數據仍是流數據，繼續存回數據倉庫中。

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

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

數據湖和數據倉庫

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

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

不管採起何種方式，重要的是保持好原始數據，以便於審計、測試和調試。

探索性數據分析（EDA,Exploratory Data Analysis）

EDA 的目的是分析並可視化數據集，進而造成假設。可能已收集的數據對於實現 EDA 尚存差距，所以須要作進一步的收集、實驗和驗證新數據。

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

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

組件選取

圖 4 體系架構需在性能和成本之間取得權衡

圖中給出了六種三角型賬篷可選，從左上到右下所需的粘合劑成本依次下降。你會在實踐中作出如何選取？請注意，三角形的底邊要小於其它的邊；淺藍色部分是矩形，而不是正方形。

數據流水線、數據湖和數據倉庫不是什麼新概念。過去，數據分析使用批處理程序完成的，例如 SQL 乃至 Excel 工做表。如今不一樣之處在於，可用的大數據推動了機器學習，進而增長了對實時洞察的需求。

現已有多種體系結構可供選擇，提供不一樣的性能和成本權衡。據我所知，從技術上考慮的最好選擇，不必定是最適合生產環境的解決方案。用戶必須仔細覈對自身的需求：

• 是否須要實時洞察或模型更新？
• 對陳舊應用的忍耐程度如何？
• 成本約束如何？

基於對上述問題的回答，用戶必須在 Lambda 架構中的批處理和流處理上作出權衡，以匹配對處理通量和延遲上的需求。Lambda 架構由以下層級組成：

• 批處理層：提供高通量、全面、經濟的 MapReduce 批處理，可是延遲很高。
• 加速層：提供低延遲的實時流處理，可是在數據量很大時，實現代價可能會突破用戶內存規模。
• 服務提供層：實現高吞吐量批處理輸出（在準備就緒時）與流處理輸出的合併，以預先計算的視圖或即席查詢的形式提供全面的結果。

Lambda 架構基於的假設是源數據模型是僅追加（append-only）的，即已獲取的事件會打上時間戳並追加到現有事件中，並且永遠不會被覆蓋。

架構實例：雲上技術棧的選取

下圖給出了一種使用開源技術物化實現流水線各階段的架構。爲優化計算代價，一般會合並數據準備和計算階段。

圖 5 使用開源技術構建的數據處理流水線

架構中的主要組件和技術選擇以下：

• 使用 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 上典型的無服務器架構實現數據流水線。其中每一個過程都能與上一節中闡釋的通用架構緊密對應。用戶以此爲參考，可選取入圍的技術。

圖 6 Amazon Web Services（AWS）的無服務器數據流水線架構

圖 7 Microsoft Azure 的無服務器數據流水線架構

圖 8 Google Cloud 的無服務器數據流水線架構

生產環境

圖 9 對於生產環境，簡單性每每優於完美

請讀者注意，圖中選擇的三角形賬篷形狀，並不是須要最少粘合劑的方式。對於下降潛在的錯誤，相當重要的是如何給出所需的部分，以及總體操做的簡單性。

對於不具操做性的分析和機器學習，生產環境將成爲它們的埋葬之地。若是用戶未對 7x24 全天候監測流水線處理作出投資，使得在某些趨勢閾值被突破時就發出警報，那麼數據處理流水線可能會在沒有引發任何人注意的狀況下失效。

請注意，工程和運營支出並不是惟一的成本。在決定架構時，還應考慮時間、機會和壓力成本。

數據流水線的實操是一件很是棘手的事情。下面給出我歷經波折得到的一些小經驗：

• 在擴展數據科學團隊以前，先擴展數據工程團隊。數據科學這列貨運列車必須先鋪設鐵軌，而後才能運行。
• 勤於清理的數據倉庫。機器學習取決於數據的質量。要定義良好的數據採集模式，並作好目錄。若是上述工做缺失，那麼用戶必定會驚訝地看到，以純字節永久存儲的數據浪費了大量的存儲空間。
• 從簡單之處開始。以無服務器架構爲起步點地，儘量下降管理成本。僅在達到合理的投資回報率的狀況下，再遷移至功能完善的數據流水線，或用戶自身進行部署。在計算階段，逐步投入儘量小規模的適量投資。經過調度 SQL 查詢和雲功能實現計算，甚至是實現爲「無計算模式」。這樣能夠更快地準備好整個流水線，爲用戶專一於數據策略制定以及數據模式和目錄提供充足的時間。
• 只有在通過仔細評估後，再着手構建。用戶的業務目標是什麼？必須使用哪些槓桿來調節業務產出？哪些洞察將是可行的？收集數據，並基於數據構建機器學習。

總結

本文的要點總結以下：

• 分析調優和機器學習模型僅是總工做量的 25%；
• 儘早投資於數據流水線，機器學習的優劣取決於數據的質量；
• 對於探索性任務，需確保數據易於訪問；
• 從業務目標入手，尋求給出能落地的洞察。

但願本文對讀者能有所幫助。讀者在生產環境中創建可靠的數據流水線有哪些技巧？歡迎在評論中分享。

Satish Chandra Gupta 是 Slang Labs 的合夥創始人之一。Slang Labs 正在構建一個使程序開發者能夠輕鬆快速地將多語言、多模式語音加強體驗（VAX）添加到移動和 Web 應用中的平臺。設想 Alexa 或 Siri 這樣的助手，能夠運行在用戶的應用內部，並針對用戶應用量身定製，聽上去多麼使人興奮。