在 Lyft 使用 Beam 進行即時機器學習

背景

Lyft, Inc. 是一家美國的移動即服務供應商，提供叫車、汽車和電動滑板車租賃、自行車共享、外送和商務運輸解決方案。Lyft 的總部位於加利福尼亞州舊金山，並在美國 644 個城市和加拿大 12 個城市營運。

正如您可能預期的一家像 Lyft 這樣的大公司，在如此大的規模下連接司機和乘客需要一個強大的即時串流基礎架構。Lyft 軟體工程師 Ravi Kiran Magham 分享了 Apache Beam 如何透過實現大規模串流資料處理和機器學習管線，成為 Lyft 的關鍵任務和不可或缺的即時資料處理技術的故事。

普及串流處理

Lyft 最初建構串流 ETL 管線，以轉換、豐富和將應用程式服務產生的事件同步到他們在 AWS S3 中的資料湖，使用 Amazon Kinesis 和 Apache Flink。Apache Flink 是 Lyft 串流架構的基礎，由於其強大、容錯且直觀的用於分散式有狀態串流處理、精確一次處理和各種 I/O 連接器的 API，因此選擇了它而不是 Apache Spark。

Lyft 的受歡迎程度和成長為資料串流基礎架構帶來了新的需求：更多具有不同程式語言偏好的團隊希望探索事件驅動的串流應用程式，並為即時機器學習模型建構串流功能，以提高業務效率、增強客戶體驗並提供對時間敏感的合規性操作。資料平台團隊研究了如何改善市場團隊的黃金時段（動態定價）計算，該團隊有一個服務來協調 ML 模型組合，透過 Redis 交換資料。團隊的目標是降低程式碼複雜性並縮短延遲（從 5 分鐘到 < 1 分鐘端到端）。由於市場團隊以 Python 為先決條件，而資料平台團隊大量使用 Java，Lyft 開始在 2019 年探索 Apache Beam 可移植性框架，以普及所有團隊的串流。

Apache Beam 的可移植性和多語言功能是我們開始以更大規模探索 Beam 的主要原因。

Ravi Kiran Magham

Lyft 軟體工程師

Apache Beam 為程式語言和資料處理引擎困境提供了解決方案，因為它提供了各種 執行器（包括用於 Apache Flink 的 Beam Flink 執行器）和 各種程式語言 SDK。Apache Beam 以「編寫一次，隨處執行」的概念及其建立 多語言管線 - 資料管線（使用來自多種程式語言的轉換）的能力提供了終極的可移植性。

利用 Apache Beam 對我們來說是一個「雙贏」的決定，因為我們的資料基礎架構團隊使用 Java，但我們能夠為我們的產品團隊提供 Python SDK，因為它一直是他們偏好的事實標準語言。我們輕鬆舒適地編寫串流管線，並在 Beam Flink 執行器上執行它們。

Ravi Kiran Magham

Lyft 軟體工程師

資料平台團隊建構了一個內部服務的控制平面和 FlinkK8sOperator，以管理 Kubernetes 叢集上的 Flink 應用程式，並部署串流 Apache Beam 和 Apache Flink 作業。Lyft 在關鍵管線上使用藍/綠部署策略，以最大限度地減少任何停機時間，並使用自訂巨集來提高可觀察性和 CI/CD 部署的無縫整合。為了提高開發人員的生產力，資料平台團隊提供了一個輕量的、基於 YAML 的 DSL 來抽象來源和接收器配置，並為傳入事件的篩選和豐富提供可重複使用的 Apache Beam PTransforms。

驅動即時機器學習管線

Lyft 市場在最佳化車隊需求和供應預測、動態定價、ETA 計算等方面發揮著關鍵作用。Apache Beam Python SDK 和 Flink Runner 使團隊能夠靈活地應對變化並支援即時 ML 的需求 – 串流功能生成和模型執行。資料平台團隊已擴展串流基礎架構以支援持續學習使用案例。Apache Beam 使用 2 小時的較大時間範圍的即時資料，為 ML 模型提供持續訓練，以識別和微調成本和 ETA 中的偏差。

Apache Beam 功能生成和 ML 模型執行

Lyft 將功能生成和 ML 模型執行分成多個串流管線。串流 Apache Beam 管線會即時產生功能，並將其寫入 Kafka 主題，以供模型執行管線使用。根據使用者配置，這些功能會被複製並由模型 ID 分鍵到 有狀態 ParDo 轉換中，它們利用 計時器和/或資料（功能）可用性來調用 ML 模型。這些功能儲存在全域視窗中，並明確清除 狀態。ML 模型作為模型服務基礎架構的一部分執行，它們的輸出可以是另一個 ML 模型的輸入功能。為了支援此 DAG 工作流程，Apache Beam 管線將輸出寫入 Kafka 並將其饋送到模型執行串流管線進行處理，此外還將其寫入 Redis。

複雜的即時功能生成涉及處理每分鐘約 400 萬個 1KB 的事件，具有亞秒級的延遲，在空間和時間粒度（1 分鐘和 5 分鐘）上產生約 100 個多個事件屬性的功能。Apache Beam 使 Lyft 市場團隊能夠將延遲縮短 60%，顯著簡化了程式碼，並將許多團隊和使用案例整合到串流中。

市場團隊是 Apache Beam 的重度使用者，用於即時功能計算和模型執行。以亞秒級延遲即時處理事件使我們的 ML 模型能夠儘早了解市場動態並做出明智的決策。

Ravi Kiran Magham

Lyft 軟體工程師

擴大使用案例

Lyft 已將 Apache Beam 用於 60 多個使用案例，並使他們能夠完成關鍵業務承諾並改善即時使用者體驗。

例如，Lyft 的地圖資料交付團隊從批次處理轉變為串流管線，以即時識別道路封閉。他們的路線引擎使用此資訊來確定最佳路線、縮短 ETA 並提供更好的司機和客戶體驗。此作業每秒處理約 40 萬個事件，將來自第三方道路封閉和即時交通資料的資料串流合併，以確定實際封閉並將其作為事件發佈到 Kafka。自訂 S3 PTransform 允許作業定期發佈封閉快照，以供下游批次處理。

Apache Beam 使 Lyft 能夠最佳化一個非常特定的使用案例，該案例與報告機場的上下車有關。機場要求移動應用程式報告每一次上下車，並將其與車隊進入和退出的時間相符。如果未能做到這一點，將導致合規分數較低，甚至有被處罰的風險。最初，Lyft 使用 KCL 程式庫來使用事件並將其儲存在 Redis 中，實作非常複雜。Python 工作進程定期執行以使用來自 Redis 的資料、透過服務 API 呼叫聯結和豐富資料，並將輸出傳送到機場應用程式。使用該實作，延遲到達的更新和亂序事件顯著影響了完整性分數。Lyft 將此使用案例遷移到具有狀態和計時器的串流 Apache Beam 管線，以將事件保留在全域視窗中並管理會話。Apache Beam 透過將事件報告的延遲從 5 秒縮短到 2 秒，並將遺失的進入/退出資料減少到 1.3%，幫助 Lyft 獲得了最高的合規分數。

像許多顛覆標準商業模式的公司一樣，Lyft 依賴開放原始碼軟體，並且喜歡回饋社群。Lyft 開發的許多大數據框架、工具和實作都在他們的 GitHub 上開放原始碼。自 2018 年以來，Lyft 一直是 Apache Beam 的重要貢獻者，Lyft 工程師也在各種活動中展示了他們的 Apache Beam 整合，例如 Beam Summit North America、Berlin Buzzwords、O’Reilly Strata Data & AI 等。

成果

Apache Beam 模型的可移植性是實現分散式執行的關鍵。它使 Lyft 能夠在基於 JVM 的執行器上運行以非 JVM 語言編寫的關鍵任務數據管道。因此，他們避免了代碼重寫，並規避了多種 API 樣式和運行時環境的潛在成本，將管道開發時間從數天縮短到僅數小時。用戶代碼的完全隔離和無庫限制的原生 CPython 執行，實現了輕鬆的入門和採用。Apache Beam 的多語言和跨語言功能解決了 Lyft 在程式語言上的兩難。透過統一的程式設計模型，Lyft 不再受限於特定的技術堆疊。

Apache Beam 使 Lyft 能夠使用視窗化功能，從批次 ML 模型訓練切換到即時 ML 訓練，並對數據新鮮度進行精細控制。他們的數據工程和產品團隊可以根據特定任務的適用性或偏好，使用 Python 和 Java。Apache Beam 已幫助 Lyft 成功建構並擴展了 60 多個串流管道，以極低的延遲近乎即時地處理事件。新的用例不斷出現，Lyft 計劃利用 Beam SQL 和 Go SDK，為他們的團隊提供全方位的 Apache Beam 多語言功能。