本文作者是 David Kjerrumgaard，目前任職於 Splunk，Apache Pulsar 和 Apache NiFi 專案貢獻者。譯者為 Sijia@StreamNative。原文連結：https://searchdatamanagement.... ，翻譯已獲授權。
關於 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）。
服務層與儲存層解耦的架構有很多優勢。首先，各層都可以彈性擴充套件，彼此之間互不影響。藉助雲和容器等環境的彈效能力，各層可以自動擴縮容，動態適應流量高峰。其次，通過顯著降低叢集擴充套件和升級複雜性，提高了系統可用性和可管理性。再次，這種設計還屬於容器友好型設計，使 Pulsar 成為託管雲原生流系統的最佳方案。Apache Pulsar 使用高可擴充套件的 BookKeeper 作為儲存層，實現了強大的持久保證與分散式資料儲存和複製，並原生支援跨地域複製。
多層設計可以輕鬆實現分層儲存，從而可以將訪問頻率較低的資料解除安裝到低成本的持久化儲存（如 AWS S3、Azure 雲）中。Pulsar 支援配置預定義的儲存大小或時間段，自動將儲存在本地磁碟的資料解除安裝至雲端儲存平臺，釋放本地磁碟，同時安全備份事件資料。
Pulsar vs. Kafka
Apache Pulsar 和 Apache Kafka 都具有類似的訊息傳遞概念。客戶端通過 topic（邏輯上分為多個分割槽）與二者進行互動。通常而言，寫入 topic 的無限資料流會被分為分割槽（特定數量、大小相等的分組），從而使資料均勻分佈在系統中，並被多個客戶端同時使用。
Apache Pulsar 和 Apache Kafka 之間的本質區別在於儲存分割槽的基礎架構。Apache Kafka 是基於分割槽的釋出/訂閱系統，旨在作為整體架構執行，服務層和儲存層位於同一節點上。
Kafka 儲存：基於分割槽
在 Kafka 中，分割槽資料作為 leader 節點上的單個連續資料儲存，然後複製到副本節點上（副本節點可預配置），實現資料多副本。這種設計通過兩種方式限制了分割槽的容量，並擴充套件了 topic。首先，由於分割槽只能儲存在本地磁碟中，分割槽大小取決於主機上最大的單個磁碟大小（“新”安裝使用者的磁碟大小約為 4 TB）；其次，由於必須複製資料，所以分割槽的大小不能超過副本節點上最小磁碟空間的大小。
假設可以將 leader 儲存在新節點上，磁碟大小為 4 TB 且只用於分割槽儲存，兩個副本節點的儲存容量都為 1 TB 。在向 topic 釋出 1 TB 資料後，Kafka 將檢測到副本節點無法繼續接收資料，並且在副本節點釋放空間之前，不能繼續向該 topic 釋出訊息（如圖 3）。如果 producer 在中斷期間無法緩衝訊息，則可能會造成資料丟失。
面對這一問題，有兩種解決方案：刪除磁碟上的資料，儲存現有副本節點，但由於來自其他 topic 的資料可能還沒有被消費，可能會導致資料丟失；或為 Kafka 叢集新增新節點並“重平衡”分割槽，將新增節點用作副本節點。但是這需要重新複製整個 1 TB 的分割槽，耗時、易出錯，對網路頻寬和磁碟 IO 要求高，且代價高昂。此外，對於具有嚴格 SLA 的程式而言，離線複製的方案並不可取。
使用 Kafka，不僅在擴充套件叢集時需要重新複製分割槽資料，其他故障也可能需要重新複製分割槽資料，如副本故障、磁碟故障、計算機故障等。如果沒有在生產環境中出現故障，我們通常會忽視 Kafka 的這一弊端。
Pulsar 儲存：基於分片
在基於分片的儲存架構（如 Apache Pulsar 使用的架構）中，分割槽被進一步分成分片，可以根據預先配置的時間或大小進行滾動。分片均勻分佈在儲存層的 bookie 中，實現資料多副本和擴容。
當 bookie 磁碟空間用盡，不能繼續向其中寫入資料時，Kafka 需要重新複製資料，Pulsar 如何應對這種場景呢？由於分割槽被進一步分成分片，因此無需複製整個 bookie 的內容到新增 bookie 中。在新增新 bookie 前，Pulsar 可以繼續接收新資料分片，並寫入儲存容量未滿的 bookie 中。新增新 bookie 時，新節點和新分割槽上的流量立即自動增加，無需重新複製舊資料。
如圖 5 所示，在第 4 個 bookie 節點不再繼續接收新訊息分片時，訊息分片 4-7 被路由到其他活躍 bookie 上。新增 bookie 後，分片自動被路由到新 bookie 上。整個過程中，Pulsar 始終在執行，並且可以為 producer 和 consumer 提供服務。在這種情況下，Pulsar 的儲存系統更加靈活，高可擴充套件。
相關閱讀
點選 連結 ，獲取 Apache Pulsar 硬核乾貨資料！