譯者 | 陳峻

審校 | 孫淑娟

本文將比較Apache Kafka和Redpanda兩種開源的數據流技術，在云原生實時處理能力上的不同，以及如何在項目中做出選擇。  

目前，Apache Kafka不但成為了數據流處理領域事實上的標準，而且帶動了同類產品的出現。Redpanda就是其中之一。它是一種輕量級的且兼容C++的Kafka實現。下面，我將和您一起探討Apache Kafka和Redpanda之間的差異，以及如何對Kafka生態系統、許可證和社區采用等方面產生的影響。

1、Apache Kafka的增長曲線

在Kafka的采用成熟度方面，大多數公司往往或多或少地經歷了如下過程：

· 從一個或幾個用例開始，快速證明其業務價值。

· 將第一個應用程序部署到生產環境中，并全天候（24/7）地運行。

· 充分利用來自各個領域、業務和技術部門的數據流。

· 遷移到分布式數據中心的中樞系統。

下圖展示了使用Maven下載Kafka Java客戶端庫的用戶月活數的增長曲線：

資料來源：Sonatype

顯然，各種數據流的潛在用例和商業價值，是Kafka被采用的曲線能夠持續增長的主要動因。而下圖則展示了各個行業憑借著Kafka的低延遲、可擴展性、可靠性、以及真正的解耦性等特點，在不同的業務場景中創造的豐富數據價值。

2、Redpanda：兼容Kafka的數據流

前面是對Kafka的現狀介紹。下面，讓我們來看看Kafka領域的新玩家：Redpanda。

作為一個數據流平臺，Redpanda在其網站給出了如下市場定位和產品策略介紹：

• 去Java：它是一種既無需JVM，又擺脫了ZooKeeper的基礎設施。
• 采用C++設計：此類設計旨在提供比Apache Kafka更好的性能。
• 單一的二進制架構：它并不依賴于其他任何庫或節點。
• 自我管理和自我修復：它是一種可用于內部和云端部署的、簡單且可擴展的架構。
• 與Kafka兼容：它針對現有應用程序、工具、以及集成的Kafka協議，提供了開箱即用的支持。

3、如何為您的項目選擇合適的Kafka實現

我們往往需要從業務案例的需求出發，進行評估與定義。例如：正常運行時間、SLA、災難恢復策略、企業支持、運營工具、托管式云服務、消息傳遞、數據獲取、以及數據集成等功能與應用。下面，我們將對開源項目Apache Kafka和Redpanda（對Kafka協議的重新實現）進行比較，以便您根據實際需求，來予以評估和選擇。

由于Redpanda和Apache Kafka的高級主張是相同的，因此我們首先來看兩者的相同之處：

• 以數據流的方式持續、實時地處理大體量的數據。
• 使用分布式存儲層去分離應用程序和域。
• 能夠與各種數據源和數據接收器（data sink）相集成。
• 利用流式處理來關聯數據，并能實時采取行動。
• 既能提供自我管理的操作，又可以使用完全托管的云產品。

下面，我們來深入了解Redpanda的各項特點。

4、部署選項：自我管理與云服務

如今，業務對于數據流的需求可謂比比皆是。雖然各行各業紛紛采用了云優先的戰略，但是鑒于成本、延遲、以及安全要求，某些工作負載必須留在邊緣處。對此，您除了自行配置Redpanda之外，還可以購買“Redpanda作為產品”，將其部署到自己的環境中。也就是說，您既可以使用Kubernetes（通常由供應商的外部控制層面提供支持），又可以利用云服務（由供應商完全實施管理）將其部署為環境中的數據層面，而非自行托管Redpanda。

Redpanda的這種不同部署選項，有點類似于Apache Kafka的Confluent部署選項。不過，其唯一缺陷是Redpanda并未提供關于云服務和企業級SLA的官方文檔。

5、自帶集群 (BYOC)

除了自行管理數據流集群和利用完全托管式的云服務之外，其實我們還有第三種選擇：自帶集群 (Bring Your Own Cluster，BYOC)。這種替代方案允許最終用戶在自己的基礎設施（如數據中心或云端的VPC）中，部署由供應商實施部分管理的解決方案。正如Redpanda的宣傳口號說的那樣：“Redpanda集群可以駐留在您的云服務處，并完全由Redpanda來打理。據此，您的數據將永遠不會離開您的環境。”當然，這背后也潛藏著一些問題：

• 供應商如何訪問您的數據中心或VPC？
• 誰來決定何時、以及如何擴展集群？
• 何時、以及如何部署集群，以修復錯誤或升級版本？
• 誰來保證SLA？是供應商嗎？
• 對于受監管的行業，如何支持安全控制和合規性？
• 如何知曉供應商在您的環境中的各項行為？
• 如何定制第三方風險評估？

鑒于上述原因，用戶要么將責任交給SaaS產品，要么自行控制。而云服務供應商往往僅能在自己的環境中提供托管服務。

6、既是社區產品也是商業產品

Redpanda的銷售方式看起來與Confluent銷售數據流的方式如出一轍。它既提供可用于生產環境的免費社區版，又在其企業版增加了分層存儲、自動化數據平衡、以及24/7的企業支持等功能。

下面，我們來深入探討Redpanda與Apache Kafka之間的技術差異。

7、Kafka協議的兼容性

為了提供API的兼容性，Redpanda重新實現了Kafka協議。不過它終究不是Kafka，無法保證來自Kafka生態系統的其他組件（如：Kafka Connect、Kafka Streams、REST Proxy和Schema Registry）在與僅使用Kafka協議、及其自我實現的非Kafka方案集成時，具有相同的表現。畢竟，即使其API能夠100%地兼容，一些底層的行為也會有所差異。當然，這并不總是劣勢。例如，Redpanda會專注于使用C++來進行性能上的優化，而在某些性能和內存情況下，C++所提供的性能會優于Java和JVM。

目前，Apache Kafka已經包含了用于數據集成的Kafka Connect，以及用于流處理的Kafka Streams。類似于大多數與Kafka相兼容的項目，Redpanda在其產品中也剔除了一些關鍵的、但“無用”的部分。因此，即使它號稱具有100%的協議兼容性，也并不意味著該產品會重新實現Apache Kafka項目中的所有內容。

8、低延遲與基準化

在項目之初，我們需要考慮性能方面的需求。這往往離不開通過使用Apache Kafka、Apache Pulsar和Redpanda，進行概念驗證(proof of concept，POC)。注意，不要隨意采用有關性能和吞吐量的“基準”。這些基準通常只是針對某個特定問題提供的配置參考。我的同事Jack Vanlightly曾用如下圖表，詮釋了基準測試的相關概念。您可以參考一下：

資料來源：Jack Vanlightly

您可能會在Redpanda的基準測試中發現：Kafka并非為高吞吐量的生產者（producer）構建的。這正是Redpanda在吞吐量方面優于Kafka的地方。畢竟，在1 GB/s的用例中，誰又會僅創建4個生產者的吞吐量級呢？可見，基準化并不能說明一切，我們往往需要自行測試與嘗試。

9、軟實時與硬實時

當我們在談論實時性時，通常是指數據處理管道至少需要幾毫秒的時間，進行端到端的傳輸。這實際上是一種軟實時，也是Apache Kafka、Apache Pulsar、Redpanda、Azure Event Hubs、Apache Flink、以及Amazon Kinesis等平臺的實現方式。那么，什么是硬實時呢？

硬實時需要的是零延遲且無峰值的確定性網絡。其典型的場景包括：制造業、汽車、機器人、證券交易等領域的嵌入式系統、現場總線、以及PLC。您可以通過搜索關鍵詞--時間敏感網絡(Time-Sensitive Networking，TSN)，了解更多相關內容。可見，Kafka和Redpanda并不適用于此類OT（Operational Technology，運營技術），而適用于IT（Information Technology，信息技術）。在OT領域，我們往往需要采用由純C或Rust構建的嵌入式軟件。

10、無需ZooKeeper

除了采用C++而非JVM來實現之外，Redpanda的第二項獨特之處在于：它不需要ZooKeeper和兩個復雜的分布式系統。當然，Kafka如今憑借著KIP-500，也可以在沒有ZooKeeper的情況下，被投入生產環境。

Redpanda的ZooKeeper-less數據流不僅對Kafka的可擴展性和可靠性有著巨大優勢，而且操作十分簡單。不過，新的ZooKeeper-less架構仍需要一些時間，才能投入生產環境，而且它僅受到新的Kafka集群的支持。雖然我們可以預見它會從今年開始，支持零停機和零數據丟失的遷移場景，但是作為成熟的軟件產品，它有著嚴格的發布周期。

11、Redpanda的數據流

得益于C++的實現，Redpanda不但輕量級而且高效。這在有限的邊緣硬件計算環境中非常實用。與基于JVM的Kafka引擎相比，您可以針對完整的端到端數據管道，使用Redpanda作為消息隊列，以實現更高級的數據流用例。此外，Redpanda的延遲峰值比Apache Kafka更少。當然，在部署單個Kafka代理的邊緣用例中，如果工業計算機 (IPC)在硬件上能夠提供4到8 GB的內存，那么我們就可以圍繞著Kafka和其他技術，去部署整個數據流平臺。

12、跨集群的數據復制

如今，在各種應用中，擁有多個Kafka集群已是常態。針對不同國家、地區的災難恢復、聚合、數據主權、以及從內部部署遷移到云端等用例，都需要多種類型的數據流集群。

通常，跨集群復制是Apache Kafka的一個組成部分。MirrorMaker 2（基于Kafka Connect）就能夠支持此類用例。當然，來自Confluent Replicator或Cluster Linking等廠商的高級專有工具，會使得數據復制之類的用例更加便捷可靠，而不需要通過額外的基礎設施，進行偏移同步等操作。

如下圖所示，Kafka生態系統的數據流，非常適合作為去中心化數據網格的基礎。此外，在數據復制方面，Redpanda同樣可以使用Kafka的Mirrormaker。

13、Apache Kafka和Redpanda之間的非功能性差異

我們在Redpanda與Apache Kafka之間進行選擇時，技術性評估往往占有主導性地位。不過，許可證、采用曲線、以及總擁有成本(total cost of ownership，TCO)等非功能性因素，對于數據流平臺的成功建立，有時候同樣至關重要。

1）許可證

由于Apache Kafka使用非常寬松的Apache許可證 2.0，因此每個人，包括云服務提供商在內，都可以使用該框架，來構建內部應用程序、商業產品和云服務。提交者（Committer）和貢獻者（Contribution）可以來自不同的公司和個人。

而Redpanda是根據更嚴格的資源可用性許可證 (Source Available License，BSL) 發布的。其目的是阻止云服務提供商將Redpanda的成果作為服務隨意向外提供。雖然其目的是好的，但是它限制了不同社區和供應商更廣泛地采用。與Kafka等Apache項目相比，外部貢獻者、提交者、以及其他供應商選擇該技術的可能性要小得多。當然，這對于其采用曲線而言，也會造成重大的影響。

2）成熟度、社區和生態系統

Kafka有著完善的文檔，龐大的專家社區，大量的工具支持。其操作也更為直接。目前，您可以選擇包括：在線課程、書籍、聚會和研討會等形式的本地和在線Kafka資源。

而Redpanda是一個全新的產品和實現，其引擎和操作行為有所不同。由于除了其供應商的基本內容，并無太多的文檔，也尚無專家支持，因此請無比仔細檢查Redpanda網站給出的功能列表。例如，Redpanda的RBAC（基于角色的訪問控制）文檔會說：“Redpanda控制臺中的RBAC，僅管理控制臺用戶的訪問，而不管理通過Kafka API交互的客戶端。若要限制Kafka API的訪問，您需要使用Kafka ACL。” 同時，請確保不要像若干年前使用Apache Pulsar的用戶那樣，陷入產品功能營銷方面的誤區。

3）總體擁有成本和商業價值

TCO不僅僅包括了產品或云服務的購置成本。眾所周知，數據流平臺既需要專職的工程師進行運維和集成，也需要昂貴的項目負責人、架構師、以及開發人員，去構建應用程序。

您可能經常聽到Redpanda宣傳：“C++可以更有效地利用CPU資源。”不過，問題在于Kafka其實很少受到CPU的限制，而更多地受限于I/O。可以說，由于Redpanda與Kafka具有相同的網絡和磁盤要求，因此這意味著Redpanda在基礎設施的TCO方面與Kafka的差異并不大。

14、何時該選擇Redpanda

而非Apache Kafka？

在如下情況下，您可以優先評估和考慮Redpanda，而不是Apache Kafka。

由于您的運營團隊無法處理和分析JVM日志，因此需要C++基礎設施。不過，請注意，這只涉及消息傳遞的內核，而不是數據集成、數據處理或Kafka生態系統的其他功能。

細微的性能差異對您來說非常重要，當然您并不需要硬實時性。

在筆記本電腦和自動化測試環境中進行簡單、輕量級的開發。

15、小結

本文從技術和非功能性兩個角度，和您探討了該如何在Apache Kafka和Redpanda之間做出選擇。總的說來，如果您需要企業級的解決方案、完全托管的云服務、廣泛的生態系統（如：各種連接器、以及數據處理能力），并且可以接受10毫秒的延遲、以及幾個p99峰值的話，選擇Apache Kafka可能要比Redpanda更穩妥一些。

原文鏈接：https://dzone.com/articles/when-to-choose-redpanda-instead-of-apache-kafka

譯者介紹

陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。