事件流平臺Kafka、Pulsar和RabbitMQ比較 - Picnic

讓我們首先將事件定義為機器可讀資料，當發生某些事情時，裝置或服務會發出該資料，例如，客戶在應用程式中單擊。事件流是單個事件或小批量事件從生產者到消費者的代理和傳輸過程。事件流平臺正在接收、即時轉換事件（儘管這是可選的），然後將事件暴露給消費者。事件流平臺區別於訊息佇列系統的一個重要特性是，當事件存在於流中時，許多消費者應該能夠多次讀取同一事件。此外，平臺應該是可靠的，並遵循至少一次語義（或者甚至更好——恰好一次）以避免任何資料丟失。

根據這個定義，我們可以看到像經典 RabbitMQ 這樣的技術不在列表中，因為多個消費者不能多次讀取相同的訊息（但我們將討論 RabbitMQ Streams！）。雖然我們進行了內部比較，但如果我們放棄事件流平臺並轉向訊息佇列，那麼沒有可重播性的弊大於已採用 RabbitMQ 的利弊。

此外，像 Apache Spark 或 Apache Flink 這樣的技術更多地是關於事件處理而不是流；他們實際上並沒有為多個消費者保留訊息。關注點的分離和這些系統的分類之間的界限非常模糊。例如，事件流平臺 Apache Kafka 支援 KStreams 和 KSQL，以實現聚合和聯接等流內處理。然而，最重要的分類是其核心：要麼是接收、儲存和提供資料給消費者，要麼是處理和修改資料。因此，我們今天將討論流優先技術而不是處理優先。

Apache Kafka

它充當分散式持久日誌，對保留時間或大小沒有（理論上）限制。主題是 Kafka 中的語義單元，通常為每個資料模式建立一個主題。資料的消費者可以組合在一起，同時從一個主題中讀取資料。它們將主題偏移量儲存在 Kafka 本身中，明確它們的位置，並使它們能夠適應重啟。一個主題由作為並行單元的分割槽組成：它們限制了一個組內（但不是跨組）並行工作的消費者的數量。

在 Apache Kafka 3.0 之前，Kafka 由 2 個核心基礎設施元件組成：Kafka brokers 和 Apache Zookeeper。前者處理消費者、生產者和資料儲存，後者用於代理和配置儲存的編排。值得一提的是，很快 Apache Zookeeper 將在 Kafka 3.0 中被刪除，並且 Kafka 代理將能夠通過仲裁控制器自行建立共識。這不僅簡化了自託管系統的管理，而且還應該帶來顯著的效能改進並擴充套件對每個叢集分割槽數量的軟上限。

除了作為一項在全球擁有龐大社群的體面技術外，Apache Kafka 通過圍繞它引入一個蓬勃發展的資料工程生態系統，在骨頭上長出了很多肉。Apache Kafka Connect 是一個通過使用聯結器從 Kafka 獲取和接收資料的系統。其他 Apache 專案，如 Apache Camel，也製作介面卡以進一步豐富 Apache Kafka Connect 功能。大多數聯結器只需簡單的配置即可工作，但當然，您可以修改程式碼，或者更好的是，編寫自己的轉換和驗證函式來對傳遞的資料進行單個訊息轉換。

在 Picnic 中，我們嚴重依賴 Snowflake 聯結器將資料直接傳送到我們的資料倉儲，但也依賴 RabbitMQ 聯結器從我們的內部服務傳播資料。

Apache Kafka Connect 並不是唯一的閃亮寶石。KSQL 允許您在流上執行復雜的 SQL 查詢，包括連線以完成流內資料分析。如果您需要，Apache Kafka 還提供一次性保證，並準備為效能付出代價（但對於某些用例，這是必須的）。

當然，沒有什麼是免費的。Apache Kafka 以其複雜的配置而聞名，它可以有效地處理大規模資料。選擇正確數量的分割槽來處理資料流中的雜散也很困難。

在 Picnic，我們通過使用Confluent Cloud管理 Apache Kafka 解決方案解決了第一個問題。通過取消維護並將配置時間減少到幾乎為零，它給我們的團隊帶來了極大的安慰。通過為 Apache Kafka Connect 和 KSQL DB 提供託管的 Snowflake 聯結器，它還大大加快了開發和整合的速度。至於第二個問題，我們目前過度配置了分割槽數量，並一直在思考可能的最佳解決方案。

我們在 AWS Kinesis 降級前後開始了對 Apache Kafka 的評估。第一步是技術和架構審查。之後，我們使用 docker-compose 構建了一個小型 PoC，以檢視我們的 Snowplow 管道和 Apache Kafka Connect 是否可以在我們的環境下正常工作。然後我們可以填寫一份適當的提案並評估此次遷移的風險和影響。第二年，我們忙於建立健全的試驗流程。我們：

1. 使用 Kafka 為我們的生產環境之一構建了額外的管道。
2. 徹底驗證資料完整性，檢查是否發生任何資料丟失（反過來，它確實發生了，但它是什麼以及我們如何修復它是另一篇文章）。
3. 圍繞新管道建立監控設定。
4. 準備了一組我們需要的指令碼來簡化進一步的工作。

試用過程花了我們半年時間，包括嘗試新的 Apache Kafka 生態系統功能、解決我們設定中的任何問題以及與所有利益相關者溝通。之後，我們完全採用了 Apache Kafka，並開始了在所有市場環境中進行全面部署的旅程。

Apache Pulsar

Apache Pulsar 是一個相對較新的分散式訊息系統和事件流平臺。它涵蓋了這兩個領域，看起來好像 Apache Kafka 中新增了一些 RabbitMQ 功能以及它自己的特殊津貼。從訊息佇列的角度來看，Apache Pulsar 可以在代理級別通過 AMQP 協議工作，並使用類似於 RabbitMQ 的直接或扇出策略（但不是主題策略，即路由鍵並不真正存在）。因此，有人可能會爭辯說它遵循基本的釋出/訂閱模式，而不是成熟的訊息佇列。它的事件流功能很廣泛，符合我們的定義，而且它支援從主題中隨機訪問讀取，假設訊息 ID 是已知的。

Apache Pulsar 架構由 3 個元件組成：Pulsar brokers、Apache Zookeeper 和 Apache BookKeeper。這種分離中的一件有趣的事情是 Pulsar 代理是無狀態的，它們的主要目標是為入站和出站訊息和請求提供服務，而 Apache BookKeeper 提供事件資料的永續性。它允許獨立擴充套件這兩個層，提供更大的靈活性。

我們將密切關注 Apache Pulsar，但目前 Apache Kafka 正在贏得我們的芳心，原因有以下幾個：

• 與 Apache Pulsar I/O 相比，Apache Kafka Connect 具有更多種類的源和接收器。特別是，對我們來說，缺少Snowflake聯結器是一個缺點。
• KStreams 和 KSQL 非常強大，Apache Pulsar 中的下一個最接近的等價物是 Pulsar Functions。但是，在我們看來，它更類似於功能稍微豐富的 Apache Kafka Connect 單訊息轉換，不足以滿足我們對流內資料分析的需求。
• Apache Pulsar 的社群規模在不斷增長，但與 Apache Kafka 相比仍然相形見絀。

RabbitMQ Streams

RabbitMQ Streams 是事件流平臺領域的一個全新參與者，於 2021 年 7 月宣佈。這項新功能允許使用者通過提供正確的標頭集，通過 AMQP 協議建立類似日誌的流，就像 Lazy Queues 將 RabbitMQ 移動到超出主記憶體永續性的領域。總的來說，核心功能集非常枯燥，完全符合我們的定義，最大的優勢是如果你有 RabbitMQ 3.9，你可以免費獲得它，你的所有應用程式都可以通過 AMQP 將資料傳送到流。消費者需要使用新的 API，但它與現有 API 非常接近。

目前，我們將 RabbitMQ Streams 新增到我們的雷達中，並將等待更多新聞、功能和基準測試來採取下一步行動。