DoorDash使用 Kafka 和 Flink 構建可擴充套件的實時事件處理

• 幾乎所有的事件都需要傳輸到我們的OLAP資料倉儲進行業務分析。例如，Dasher 分配團隊（Dasher 是我們對送貨司機的稱呼）依靠資料倉儲中的分配資料來檢測其分配演算法中的任何錯誤。
• 一些事件將由下游系統進一步處理。例如，我們的 ML 平臺處理交付事件以生成實時特徵，例如最近餐廳的平均等待時間。
• 一些移動事件將與我們的時間序列指標後端整合以進行監控和警報，以便團隊可以快速識別最新移動應用程式版本中的問題。例如，我們的 DoorDash 消費者應用程式中的任何結帳頁面載入錯誤都需要傳送到Chronosphere進行監控。

​
圖 1：DoorDash 的舊資料管道

這種方法有幾個問題：

• 構建多個試圖實現類似目的的管道是成本低效的。
• 混合不同型別的資料傳輸並透過多個訊息傳遞/排隊系統而沒有精心設計可觀察性會導致操作困難。

• 異構資料來源和目的地：從各種資料來源中提取資料，包括傳統的單體 Web 應用程式、微服務和移動/Web 裝置，並交付到不同的目的地，包括第三方資料服務。將可靠且低延遲的資料攝取到資料倉儲中是重中之重。
• 易於訪問：使不同團隊和服務能夠輕鬆利用資料流並構建自己的資料處理邏輯的平臺。
• 端到端模式實施和模式演變：模式不僅提高了資料質量，而且還促進了與資料倉儲和 SQL 處理的輕鬆整合。
• 可擴充套件、容錯且易於操作的小型團隊：我們希望構建一個可以輕鬆擴充套件以滿足業務需求且運營開銷最小的系統。

• 使用統一的 API 和事件格式簡化事件釋出，以避免採用瓶頸
• 為不同型別的資料消費者消費事件提供多種抽象
• 在基礎架構即程式碼環境中使用 Github 自動化和工作流程自動化入職流程

​
圖2：Iguazu 整體系統架構圖

簡化和最佳化事件製作 構建處理系統的第一步是選擇處理事件的最佳技術和方法。我們選擇Apache Kafka作為我們的流資料釋出/訂閱系統，因為 Kafka 已被證明是統一異構資料來源同時提供高吞吐量和高效能的出色解決方案。 利用和增強 Kafka Rest Proxy 我們希望每個 DoorDash 服務都能夠輕鬆地為 Kafka 生成事件。一個明顯的選擇是建立一個 Kafka 客戶端並將其與所有服務整合。但是，這種方法有一些缺點：

• 每個服務都需要配置 Kafka 連線，這對於不熟悉 Kafka 的團隊來說可能會出現問題並減慢採用速度
• 跨不同服務的統一和最佳化的 Kafka 生產者配置將很困難
• 對於移動和 Web 應用程式，直接連線到 Kafka 是不可行的

• 支援不同型別的有效負載格式，包括 JSON 和二進位制檔案
• 支援批處理，這對於減少客戶端應用程式和 Kafka 代理的處理開銷至關重要
• 與Confluent 的模式登錄檔整合，可以使用模式驗證和轉換 JSON 有效負載

• 生產多個 Kafka 叢集的能力。生成多個叢集的能力對我們來說至關重要，因為我們的事件迅速擴充套件到多個 Kafka 叢集，並且事件到叢集的對映是我們系統中的一個重要抽象。
• 非同步 Kafka 產生請求。使用非同步生產無需在響應客戶端請求之前先獲得代理的確認。相反，響應會在有效負載經過驗證並新增到 Kafka 生產者的緩衝區後立即發回。此功能大大減少了響應時間，並提高了批處理和系統的整體可用性。雖然當 Kafka 不可用時，此選項可能會導致少量資料丟失，但透過代理端生產者重試和密切監視從代理收到的確認來抵消風險。
• 預取 Kafka 主題後設資料並生成測試 Kafka 記錄，作為 Kubernetes pod 就緒探測的一部分。此增強將確保代理 pod 將預熱所有快取和 Kafka 連線，以避免冷啟動問題。
• 支援 Kafka 標頭作為代理生成請求負載的一部分。我們的事件有效負載格式依賴於事件信封，它是生產記錄中 Kafka 標頭的一部分。我們將在後面的部分中詳細介紹我們的事件有效負載格式和序列化。

• 我們使用 2 的複製因子和一個最小的同步副本。與三個副本的典型配置相比，這節省了磁碟空間並降低了 broker 在複製時的 CPU 使用率，同時仍然提供了足夠的資料冗餘。
• 生產者配置為在分割槽的領導者（而不是追隨者）持久化資料後立即接收來自代理的確認。這種配置減少了生產請求的響應時間。
• 我們透過在 50 毫秒到 100 毫秒之間設定一個合理的逗留時間來利用 Kafka 的粘性分割槽器，這顯著提高了批處理並降低了代理的 CPU 利用率。

​
圖 3：顯示 Kubernetes 水平 pod 自動縮放對 Kafka Rest Proxy 生效

既然我們描述了簡化和高效的事件生成，讓我們在下一節中關注我們為促進事件消費所做的工作。 不同抽象的事件處理 如開頭所述，伊瓜蘇的一個重要目標是建立一個便於資料處理的平臺。Flink 的分層 API架構完全符合這個目標。
Data Stream API 和 Flink SQL 是我們支援的兩個主要抽象。 我們選擇 Apache Flink 還因為它的低延遲處理、基於事件時間的處理的原生支援、容錯以及與各種源和接收器的開箱即用整合，包括 Kafka、Reddis（透過三分之一-party OSS）、ElasticSearch 和 S3。
在 Kubernetes 中使用 Helm 進行部署 我們的平臺提供了一個基本的 Flink docker 映象，其中包含與 DoorDash Kubernetes 基礎設施的其餘部分良好整合的所有必要配置。
Flink 的高可用性設定和 Flink 指標是開箱即用的。為了更好的故障隔離和獨立擴充套件的能力，每個 Flink 作業都以獨立模式部署，作為一個單獨的 Kubernetes 服務。 在使用資料流 API 開發 Flink 應用程式時，工程師首先會克隆一個 Flink 應用程式模板，然後新增自己的程式碼。
應用程式和 Flink 作業的配置（如並行度和工作管理員計數）將在terraform模板中定義。
在構建過程中，將使用組合的應用程式 jar 檔案和我們內部的 Flink 基礎 docker 映象建立一個 docker 映象。部署過程將同時採用 terraform 模板和應用程式 docker 映像，並根據生成的Helm Chart將應用程式部署在我們的 K8s 叢集中的獨立 Flink 作業叢集中。該過程如下圖所示：

​
圖 4：使用 terraform 和 Helm 構建和部署 Flink 應用程式的過程

提供 SQL 抽象 雖然 Flink 的資料流 API 對於後端工程師來說並不難理解，但對於資料分析師和其他臨時資料使用者來說，它仍然是一個主要障礙。
對於這些使用者，我們提供了一個平臺來使用 SQL 以宣告方式建立 Flink 應用程式，而無需擔心基礎設施級別的細節。該工作的詳細資訊可在此部落格中找到。
在開發基於 SQL 的應用程式時，所有必要的處理邏輯和接線都被捕獲在一個YAML檔案中，該檔案非常簡單，每個人都可以閱讀或創作。YAML 檔案捕獲了許多高階抽象，例如，連線到 Kafka 源並輸出到不同的接收器。以下是此類 YAML 檔案的示例： 要建立 Flink 作業，使用者只需要使用 YAML 檔案建立 PR。PR 合併後，將啟動 CD 管道並將 YAML 檔案編譯為 Flink 應用程式並進行部署。 在以上兩節中，我們介紹了在伊瓜蘇發生和消費的事件。但是，如果沒有統一的事件格式，生產者和消費者仍然很難相互理解。在下一節中，我們將討論作為生產者和消費者之間協議的事件格式。

事件格式、序列化和模式驗證 從一開始，我們就為在Iguazu 伊瓜蘇製作和處理的事件定義了統一的格式。
統一的事件格式大大降低了消費事件的門檻，減少了事件生產者和消費者之間的摩擦。 所有事件都有一個標準的信封和有效負載。信封包含事件的上下文（例如建立時間和來源）、後設資料（包括編碼方法）和對模式的引用。有效負載包含事件的實際內容。
信封還包括作為 JSON blob 的非模式化事件屬性。信封中的這個 JSON 部分有助於使部分事件模式變得靈活，其中的更改不涉及正式的模式演變過程。 從內部微服務產生的事件有效負載將經過模式驗證和編碼。無效的有效載荷將直接在生產者端丟棄。對於從移動/Web 裝置產生的事件，它們採用原始 JSON 格式，我們使用單獨的流處理應用程式進行模式驗證和轉換為模式化格式以供下游流程使用。

我們為事件生產者和消費者建立了序列化/反序列化庫，以便與這種標準事件格式進行互動。在 Kafka 中，事件信封儲存為 Kafka 記錄頭，有效負載儲存為記錄值。對於事件消費者，我們的庫將解碼 Kafka 標頭和值並重新建立事件以供消費者處理。

​
圖 5：顯示從 Kafka 記錄到 Event 的反序列化以及 Event 的概念如何在儲存 (Kafka) 與應用程式執行時中表示

我們幾乎所有的微服務都是基於GRPC和Protobuf 的。所有事件都由 Protobuf 在集中共享的 Protobuf Git 儲存庫中定義。在 API 級別，我們對 Event 的定義是對 Protobuf 訊息的包裝，以使我們的微服務易於使用。

但是，對於大多數事件的最終目的地，Avro格式仍然比 Protobuf 得到更好的支援。對於這些用例，我們的序列化庫負責將 Protobuf 訊息無縫轉換為 Avro 格式，這要歸功於Avro 的 protobuf 庫，並在需要時轉換回 Protobuf 訊息。

我們大量利用 Confluent 的模式登錄檔進行通用資料處理。所有事件都在模式登錄檔中註冊。隨著最近在 Confluent 模式登錄檔中引入的 Protobuf 模式支援，我們實現了使用 Protobuf 和 A​​vro 模式進行通用資料處理的能力。
我們一開始面臨的一個挑戰是我們如何強制和自動化模式註冊。我們不想在生成事件時在執行時註冊模式，因為：

1. 它會在某個時間顯著增加模式更新請求，從而導致模式登錄檔的可伸縮性問題。
2. 任何不相容的模式更改都會導致模式更新失敗和客戶端應用程式的執行時錯誤。

• 在構建時檢測不相容的架構更改，以及
• 已釋出的 Protobuf 類二進位制檔案與模式登錄檔中的模式之間的一致性。

​
圖 6：編排複雜步驟以建立從服務到 Snowflake 的管道的自動化到位

為了解決這個問題，我們與我們的基礎架構團隊合作，建立了正確的拉取審批流程，並使用 Git 自動化來自動化拉取請求。本質上，建立了一個 Github 應用程式，我們可以在其中以程式設計方式建立和合並來自我們作為控制器的服務之一的拉取請求。我們還利用了Cadence 工作流引擎，並將該流程實現為可靠的工作流。整個自動化將事件啟動時間從幾天縮短到幾分鐘。 為了使其更接近自助服務，我們使用Retool框架建立了 UI，供使用者探索模式並從那裡載入事件。使用者可以使用正規表示式搜尋架構，為事件選擇正確的架構，啟動工作流以建立必要的資源和服務，並有機會自定義 Snowflake 表和 Snowpipe。

我們 Iguazu 的最終目標是使其成為一個自助服務平臺，使用者可以在其中透過正確的抽象和最少的支援或人工干預自行參與活動。

​
圖 7：顯示模式探索 UI，使用者可以在其中深入瞭解主題和版本。

​
圖 8：顯示用於檢視/自定義 Snowflake 表架構和 Snowpipe 的 UI

學習和未來的工作 我們發現建立具有平臺思維方式的事件處理系統很重要。不同技術相互疊加的臨時解決方案不僅效率低下，而且難以擴充套件和運營。
選擇正確的框架並建立正確的構建塊對於確保成功至關重要。Apache Kafka、Apache Flink、Confluent Rest Proxy 和 Schema 登錄檔被證明具有可擴充套件性和可靠性。研究和利用這些框架的最佳點顯著減少了開發和操作這個大規模事件處理系統所需的時間。

為了使系統使用者友好且易於採用，需要正確的抽象。從宣告式 SQL 方法、事件的無縫序列化到高階使用者引導 UI，我們努力使其成為一個簡單的過程，以便我們的使用者可以專注於他們自己的業務邏輯，而不是我們的實現細節。

我們還想在Iguazu 伊瓜蘇實現很多目標。我們已經開始了在Iguazu 伊瓜蘇之上構建客戶資料平臺的旅程，我們可以輕鬆地以自助方式轉換和分析使用者資料。會話化是我們想要解決的一個重要用例。

為了能夠會話化大量資料，我們開始透過利用 Kubernetes StatefulSet、持久化卷和探索使用Spinnaker的新部署方式來增強對 Flink 狀態處理的支援。與資料湖更好地整合是我們前進的另一個方向。結合 SQL 抽象和正確的表格式，從流處理應用程式直接訪問資料湖可以使用同一應用程式進行回填和重放，並提供另一種替代方案Lambda 架構。