譯者 | 陳峻

審校 | 孫淑娟

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

目前，Apache Kafka不但成為了數(shù)據(jù)流處理領(lǐng)域事實上的標(biāo)準(zhǔn)，而且?guī)恿送惍a(chǎn)品的出現(xiàn)。Redpanda就是其中之一。它是一種輕量級的且兼容C++的Kafka實現(xiàn)。下面，我將和您一起探討Apache Kafka和Redpanda之間的差異，以及如何對Kafka生態(tài)系統(tǒng)、許可證和社區(qū)采用等方面產(chǎn)生的影響。

1、Apache Kafka的增長曲線

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

· 從一個或幾個用例開始，快速證明其業(yè)務(wù)價值。

· 將第一個應(yīng)用程序部署到生產(chǎn)環(huán)境中，并全天候（24/7）地運行。

· 充分利用來自各個領(lǐng)域、業(yè)務(wù)和技術(shù)部門的數(shù)據(jù)流。

· 遷移到分布式數(shù)據(jù)中心的中樞系統(tǒng)。

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

資料來源：Sonatype

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

2、Redpanda：兼容Kafka的數(shù)據(jù)流

前面是對Kafka的現(xiàn)狀介紹。下面，讓我們來看看Kafka領(lǐng)域的新玩家：Redpanda。

作為一個數(shù)據(jù)流平臺，Redpanda在其網(wǎng)站給出了如下市場定位和產(chǎn)品策略介紹：

• 去Java：它是一種既無需JVM，又?jǐn)[脫了ZooKeeper的基礎(chǔ)設(shè)施。
• 采用C++設(shè)計：此類設(shè)計旨在提供比Apache Kafka更好的性能。
• 單一的二進(jìn)制架構(gòu)：它并不依賴于其他任何庫或節(jié)點。
• 自我管理和自我修復(fù)：它是一種可用于內(nèi)部和云端部署的、簡單且可擴(kuò)展的架構(gòu)。
• 與Kafka兼容：它針對現(xiàn)有應(yīng)用程序、工具、以及集成的Kafka協(xié)議，提供了開箱即用的支持。

3、如何為您的項目選擇合適的Kafka實現(xiàn)

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

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

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

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

4、部署選項：自我管理與云服務(wù)

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

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

5、自帶集群 (BYOC)

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

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

鑒于上述原因，用戶要么將責(zé)任交給SaaS產(chǎn)品，要么自行控制。而云服務(wù)供應(yīng)商往往僅能在自己的環(huán)境中提供托管服務(wù)。

6、既是社區(qū)產(chǎn)品也是商業(yè)產(chǎn)品

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

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

7、Kafka協(xié)議的兼容性

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

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

8、低延遲與基準(zhǔn)化

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

資料來源：Jack Vanlightly

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

9、軟實時與硬實時

當(dāng)我們在談?wù)搶崟r性時，通常是指數(shù)據(jù)處理管道至少需要幾毫秒的時間，進(jìn)行端到端的傳輸。這實際上是一種軟實時，也是Apache Kafka、Apache Pulsar、Redpanda、Azure Event Hubs、Apache Flink、以及Amazon Kinesis等平臺的實現(xiàn)方式。那么，什么是硬實時呢？

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

10、無需ZooKeeper

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

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

11、Redpanda的數(shù)據(jù)流

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

12、跨集群的數(shù)據(jù)復(fù)制

如今，在各種應(yīng)用中，擁有多個Kafka集群已是常態(tài)。針對不同國家、地區(qū)的災(zāi)難恢復(fù)、聚合、數(shù)據(jù)主權(quán)、以及從內(nèi)部部署遷移到云端等用例，都需要多種類型的數(shù)據(jù)流集群。

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

如下圖所示，Kafka生態(tài)系統(tǒng)的數(shù)據(jù)流，非常適合作為去中心化數(shù)據(jù)網(wǎng)格的基礎(chǔ)。此外，在數(shù)據(jù)復(fù)制方面，Redpanda同樣可以使用Kafka的Mirrormaker。

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

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

1）許可證

由于Apache Kafka使用非常寬松的Apache許可證 2.0，因此每個人，包括云服務(wù)提供商在內(nèi)，都可以使用該框架，來構(gòu)建內(nèi)部應(yīng)用程序、商業(yè)產(chǎn)品和云服務(wù)。提交者（Committer）和貢獻(xiàn)者（Contribution）可以來自不同的公司和個人。

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

2）成熟度、社區(qū)和生態(tài)系統(tǒng)

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

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

3）總體擁有成本和商業(yè)價值

TCO不僅僅包括了產(chǎn)品或云服務(wù)的購置成本。眾所周知，數(shù)據(jù)流平臺既需要專職的工程師進(jìn)行運維和集成，也需要昂貴的項目負(fù)責(zé)人、架構(gòu)師、以及開發(fā)人員，去構(gòu)建應(yīng)用程序。

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

14、何時該選擇Redpanda

而非Apache Kafka？

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

由于您的運營團(tuán)隊無法處理和分析JVM日志，因此需要C++基礎(chǔ)設(shè)施。不過，請注意，這只涉及消息傳遞的內(nèi)核，而不是數(shù)據(jù)集成、數(shù)據(jù)處理或Kafka生態(tài)系統(tǒng)的其他功能。

細(xì)微的性能差異對您來說非常重要，當(dāng)然您并不需要硬實時性。

在筆記本電腦和自動化測試環(huán)境中進(jìn)行簡單、輕量級的開發(fā)。

15、小結(jié)

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

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

譯者介紹

陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗。