本文作者是 David Kjerrumgaard，目前任職於 Splunk，Apache Pulsar 和 Apache NiFi 項目貢獻者。譯者爲 Sijia@StreamNative。原文鏈接：https://searchdatamanagement.techtarget.com/post/Apache-Pulsar-vs-Kafka-and-other-data-processing-technologies，翻譯已獲授權。

關於 Apache Pulsar

Apache Pulsar 是 Apache 軟件基金會頂級項目，是下一代雲原生分佈式消息流平臺，集消息、存儲、輕量化函數式計算爲一體，採用計算與存儲分離架構設計，支持多租戶、持久化存儲、多機房跨區域數據複製，具有強一致性、高吞吐、低延時及高可擴展性等流數據存儲特性。
GitHub 地址：http://github.com/apache/pulsar/

相比於 Kafka 等數據處理中間件，分佈式消息平臺 Apache Pulsar 如何存儲數據？本文基於架構，對比了 Apache Kafka 等傳統數據處理中間件和分佈式消息平臺 Apache Pulsar 的優劣勢，供大家參考。

存儲可擴展

Apache Pulsar 的多層架構將消息服務層與存儲層完全解耦，從而使各層可以獨立擴展。傳統的分佈式數據處理中間件（如 Hadoop、Spark）則在同一集羣節點 / 實例上處理和存儲數據。這種設計可以降低通過網絡進行傳輸的數據量，使得架構更簡潔，性能也有所提升，但同時擴展性、彈性、運維受到了影響。

Pulsar 的分層架構在雲原生解決方案中獨樹一幟。如今，大幅提升的網絡帶寬爲此架構提供了堅實基礎，有利於計算和存儲的分離。Pulsar 的架構將服務層與存儲層解耦：無狀態 broker 節點負責數據服務；bookie 節點負責數據存儲（如圖 1）。

圖 1. 服務層與存儲層解耦

服務層與存儲層解耦的架構有很多優勢。首先，各層都可以彈性擴展，彼此之間互不影響。藉助雲和容器等環境的彈性能力，各層可以自動擴縮容，動態適應流量高峯。其次，通過顯著降低集羣擴展和升級複雜性，提高了系統可用性和可管理性。再次，這種設計還屬於容器友好型設計，使 Pulsar 成爲託管雲原生流系統的最佳方案。Apache Pulsar 使用高可擴展的 BookKeeper 作爲存儲層，實現了強大的持久保證與分佈式數據存儲和複製，並原生支持跨地域複製。

多層設計可以輕鬆實現分層存儲，從而可以將訪問頻率較低的數據卸載到低成本的持久化存儲（如 AWS S3、Azure 雲）中。Pulsar 支持配置預定義的存儲大小或時間段，自動將存儲在本地磁盤的數據卸載至雲存儲平臺，釋放本地磁盤，同時安全備份事件數據。

Pulsar vs. Kafka

Apache Pulsar 和 Apache Kafka 都具有類似的消息傳遞概念。客戶端通過 topic（邏輯上分爲多個分區）與二者進行交互。通常而言，寫入 topic 的無限數據流會被分爲分區（特定數量、大小相等的分組），從而使數據均勻分佈在系統中，並被多個客戶端同時使用。

Apache Pulsar 和 Apache Kafka 之間的本質區別在於存儲分區的基礎架構。Apache Kafka 是基於分區的發佈 / 訂閱系統，旨在作爲整體架構運行，服務層和存儲層位於同一節點上。

圖 2. Kafka 分區

Kafka 存儲：基於分區

在 Kafka 中，分區數據作爲 leader 節點上的單個連續數據存儲，然後複製到副本節點上（副本節點可預配置），實現數據多副本。這種設計通過兩種方式限制了分區的容量，並擴展了 topic。首先，由於分區只能存儲在本地磁盤中，分區大小取決於主機上最大的單個磁盤大小（“新” 安裝用戶的磁盤大小約爲 4 TB）；其次，由於必須複製數據，所以分區的大小不能超過副本節點上最小磁盤空間的大小。

圖 3. Kafka 故障和擴容

假設可以將 leader 存儲在新節點上，磁盤大小爲 4 TB 且只用於分區存儲，兩個副本節點的存儲容量都爲 1 TB 。在向 topic 發佈 1 TB 數據後，Kafka 將檢測到副本節點無法繼續接收數據，並且在副本節點釋放空間之前，不能繼續向該 topic 發佈消息（如圖 3）。如果 producer 在中斷期間無法緩衝消息，則可能會造成數據丟失。

面對這一問題，有兩種解決方案：刪除磁盤上的數據，存儲現有副本節點，但由於來自其他 topic 的數據可能還沒有被消費，可能會導致數據丟失；或爲 Kafka 集羣添加新節點並 “重平衡” 分區，將新增節點用作副本節點。但是這需要重新複製整個 1 TB 的分區，耗時、易出錯，對網絡帶寬和磁盤 IO 要求高，且代價高昂。此外，對於具有嚴格 SLA 的程序而言，離線複製的方案並不可取。

使用 Kafka，不僅在擴展集羣時需要重新複製分區數據，其他故障也可能需要重新複製分區數據，如副本故障、磁盤故障、計算機故障等。如果沒有在生產環境中出現故障，我們通常會忽視 Kafka 的這一弊端。

圖 4. Pulsar 分片

Pulsar 存儲：基於分片

在基於分片的存儲架構（如 Apache Pulsar 使用的架構）中，分區被進一步分成分片，可以根據預先配置的時間或大小進行滾動。分片均勻分佈在存儲層的 bookie 中，實現數據多副本和擴容。

當 bookie 磁盤空間用盡，不能繼續向其中寫入數據時，Kafka 需要重新複製數據，Pulsar 如何應對這種場景呢？由於分區被進一步分成分片，因此無需複製整個 bookie 的內容到新增 bookie 中。在添加新 bookie 前，Pulsar 可以繼續接收新數據分片，並寫入存儲容量未滿的 bookie 中。添加新 bookie 時，新節點和新分區上的流量立即自動增加，無需重新複製舊數據。

圖 5. Pulsar 故障和擴容

如圖 5 所示，在第 4 個 bookie 節點不再繼續接收新消息分片時，消息分片 4-7 被路由到其他活躍 bookie 上。新增 bookie 後，分片自動被路由到新 bookie 上。整個過程中，Pulsar 始終在運行，並且可以爲 producer 和 consumer 提供服務。在這種情況下，Pulsar 的存儲系統更加靈活，高可擴展。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7L_O3HVtrel5bD7JNNGFhw