事件流平臺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 是否可以在我們的環境下正常工作。然後我們可以填寫一份適當的提案並評估此次遷移的風險和影響。第二年,我們忙於建立健全的試驗流程。我們:
- 使用 Kafka 為我們的生產環境之一構建了額外的管道。
- 徹底驗證資料完整性,檢查是否發生任何資料丟失(反過來,它確實發生了,但它是什麼以及我們如何修復它是另一篇文章)。
- 圍繞新管道建立監控設定。
- 準備了一組我們需要的指令碼來簡化進一步的工作。
試用過程花了我們半年時間,包括嘗試新的 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 新增到我們的雷達中,並將等待更多新聞、功能和基準測試來採取下一步行動。
相關文章
- 簡單比較 Apache Kafka 和 Apache Pulsar要點 - JaroslawApacheKafkaJARROS
- 分散式訊息流平臺:不要只想著Kafka,還有Pulsar分散式Kafka
- 比較Apache Pulsar 和Apache Kafka:統一排隊和流式傳輸 - splunkApacheKafka
- 訊息中介軟體(RabbitMq、Kafka)分析比較MQKafka
- Apache Pulsar 與 Kafka 效能比較:延遲性(測試方法)ApacheKafka
- 從消費者角度比較Kafka 與 RabbitMQ - OpenCredoKafkaMQ
- 分散式流平臺Kafka分散式Kafka
- 譯文 | 科普:Pulsar 和 Kafka 架構對比Kafka架構
- 大資料技術 - 分散式訊息流平臺:Kafka與Pulsar的介紹大資料分散式Kafka
- 微服務訊息代理比較:Redis vs Kafka vs RabbitMQ - Mertcan微服務RedisKafkaMQ
- 訊息中介軟體部署及比較:rabbitMQ、activeMQ、zeroMQ、rocketMQ、Kafka、redisMQKafkaRedis
- 三種大資料流處理框架選擇比較:Apache Kafka流、Apache Spark流和Apache Flink - quora大資料框架ApacheKafkaSpark
- 博文推薦|Apache Pulsar: 統一訊息流平臺Apache
- RabbitMQ與Kafka選型對比MQKafka
- RabbitMQ推出類似Kafka的流StreamMQKafka
- 博文推薦|使用 Apache Pulsar 和 Scala 進行事件流處理Apache事件
- 多平臺大型檔案系統比較
- 有哪些比較好的外匯平臺?
- 技術探究:Apache Pulsar 的事務型事件流Apache事件
- 直播平臺開發,純時間比較(時分),不含日期,js前端比較JS前端
- 大資料流處理:Flume、Kafka和NiFi對比大資料KafkaNifi
- DDD中事件與命令比較事件
- js 深比較和淺比較JS
- 免費的雲渲染平臺有哪些?哪些平臺價效比較高?
- RabbitMQ和Kafka到底怎麼選?MQKafka
- 事件流處理 (ESP) 與 Kafka 簡介事件Kafka
- 基於 Apache Hudi 構建增量和無限回放事件流的 OLAP 平臺Apache事件
- 槓上Spark、Flink?Kafka為何轉型流資料平臺SparkKafka
- 槓上 Spark、Flink?Kafka 為何轉型流資料平臺SparkKafka
- Apache Pulsar 里程碑簡史:打造統一訊息流平臺與生態Apache
- RabbitMQ和Kafka到底怎麼選(二)?MQKafka
- Oracle date 型別比較和String比較Oracle型別
- 什麼是聚合支付?聚合支付哪家平臺比較好?
- 低程式碼開發平臺有哪些比較好用的?
- JS事件流和事件委託JS事件
- RabbitMQ,RocketMQ,Kafka 幾種訊息佇列的對比MQKafka佇列
- RabbitMQ和Erlang相容對比MQ
- not in 和 not exists 比較和用法