譯者 | 陳峻

審校 | 孫淑娟

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

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

1、Apache Kafka的增長(zhǎng)曲線

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

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

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

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

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

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

資料來(lái)源：Sonatype

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

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

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

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

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

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

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

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

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

下面，我們來(lái)深入了解Redpanda的各項(xiàng)特點(diǎn)。

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

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

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

5、自帶集群 (BYOC)

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

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

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

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

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

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

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

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

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

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

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

資料來(lái)源：Jack Vanlightly

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

9、軟實(shí)時(shí)與硬實(shí)時(shí)

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

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

10、無(wú)需ZooKeeper

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

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

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

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

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

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

通常，跨集群復(fù)制是Apache Kafka的一個(gè)組成部分。MirrorMaker 2（基于Kafka Connect）就能夠支持此類(lèi)用例。當(dāng)然，來(lái)自Confluent Replicator或Cluster Linking等廠商的高級(jí)專(zhuān)有工具，會(huì)使得數(shù)據(jù)復(fù)制之類(lèi)的用例更加便捷可靠，而不需要通過(guò)額外的基礎(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之間的非功能性差異

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

1）許可證

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

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

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

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

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

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

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

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

14、何時(shí)該選擇Redpanda

而非Apache Kafka？

在如下情況下，您可以?xún)?yōu)先評(píng)估和考慮Redpanda，而不是Apache Kafka。

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

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

在筆記本電腦和自動(dòng)化測(cè)試環(huán)境中進(jìn)行簡(jiǎn)單、輕量級(jí)的開(kāi)發(fā)。

15、小結(jié)

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

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

譯者介紹

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