Apache Pulsar 里程碑簡史：打造統一訊息流平臺與生態

ApachePulsar發表於2021-08-13
Apache

關於 Apache Pulsar

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

轉載與作者資訊：本文翻譯自 StreamNative 部落格，原作者 Matteo Merli、郭斯傑，譯者 Jipei@StreamNative。原文地址：https://streamnative.io/en/bl...

Apache Pulsar 自誕生並從 Apache 軟體基金會畢業以來，已發展為完整的專案並形成了全球上萬人的社群。今年，值此 Pulsar 北美峰會收官和 Pulsar 2.8.0 版本釋出之際，Pulsar 在專案和社群上都迎來了新的里程碑。藉此機會，我們共同回顧 Pulsar 的技術及生態發展。

Apache Pulsar 的誕生

Apache Pulsar 在全球有數百家公司廣泛採用，包括 Splunk、騰訊、Verizon 和 Yahoo! JAPAN 等。Apache Pulsar 從一開始的只是一款雲原生分散式訊息系統，現已發展成為一個完整的訊息和流的平臺，可用於釋出和訂閱、實時儲存和處理大規模資料流。

Pulsar 誕生於 2012 年，最初的目的是為在 Yahoo 內部，整合其他訊息系統，構建統一邏輯、支撐大叢集和跨區域的訊息平臺。當時的其他訊息系統（包括 Kafka），都不能滿足 Yahoo 的需求，比如大叢集多租戶、穩定可靠的 IO 服務質量、百萬級 Topic、跨地域複製等，因此 Pulsar 應運而生。

當時，通常有兩種型別的系統來處理動態資料：實時處理關鍵業務事件的訊息佇列，以及大規模處理可擴充套件資料管道的流系統。許多公司不得不將他們的功能限制在其中一種，或者不得不採用多種不同的技術。如果選擇多種技術通常會導致資料隔離和資料孤島：一個用於訊息佇列的孤島來構建應用服務，另一個用於構建資料服務的流系統。公司的基礎設施通常極其複雜，下圖說明該架構。

圖片

然而，隨著公司需要處理的資料型別增多，運營資料（如日誌資料、點選事件等），以及需要訪問組合業務資料和運營資料的下游系統數量的增加，系統需要支援訊息佇列和流兩種場景。

除此之外，公司需要一個基礎設施平臺，允許他們在其上構建所有應用程式，然後讓這些應用程式預設處理動態資料（訊息和流資料）。通過這種方式，可以顯著簡化實時資料基礎設施，如下圖。

圖片

在這樣的願景下，Yahoo! 團隊開始致力於為動態資料構建統一的訊息流平臺。以下是 Pulsar 成立至今的關鍵里程碑。

里程碑 1：資料流的可擴充套件儲存

Pulsar 的誕生始於 Apache BookKeeper。Apache BookKeeper 為連續流實現了類似日誌的抽象，並提供了在網際網路規模上使用簡單的寫-讀日誌 API 執行它的能力。日誌為構建分散式系統提供了很好的抽象，如分散式資料庫和釋出-訂閱訊息。寫入 API 以附加到日誌的形式出現。讀取 API 是從 reader 定義的起始偏移量連續讀取。BookKeeper 的實現奠定了基礎——可擴充套件的基於日誌的訊息和流系統。

里程碑 2：儲存、計算分離的多層架構。

在可擴充套件的日誌儲存之上引入了一個無狀態服務層，通過執行無狀態 broker 來發布和消費訊息。這種多層架構將服務/計算與儲存分離，允許 Pulsar 在不同的層中管理服務和儲存。

這種架構保證了即時可擴充套件性和更高的可用性，使 Pulsar 非常適合構建關鍵任務服務，例如金融場景中的計費平臺、電子商務和零售商的交易處理系統以及金融機構的實時風險控制系統。

里程碑 3：統一的訊息模型和 API

在現代資料架構中，實時場景通常可以分為兩類：佇列和流。佇列通常用於構建核心業務應用程式服務，流通常用於構建實時資料服務，如資料管道。

為了提供一個能夠同時為應用程式和資料服務提供服務的平臺，需要一個整合了佇列和流語義的統一訊息模型。Pulsar topic 成為消費的真正來源。訊息只能在 topic 上儲存一次，但可以通過不同的訂閱以不同的方式消費。這種統一大大降低了管理和開發訊息和流應用程式的複雜性。

里程碑 4：Schema API

接著，Pulsar 內新增了新的 Pulsar schema registry 和一個新安全型別 producer 和 consumer API。內建的 schema registry 使 Pulsar topic 上的訊息 producer 和 consumer 能夠通過 Pulsar broker 本身協調 topic 資料的結構，而無需外部協調機制。使用 schema 資料，通過 Pulsar 傳輸的每條資料都是完全可發現的，使用者能夠構建輕鬆適應資料變化的系統。

此外，schema registry 會跟蹤 schema 版本之間的資料相容性。隨著新的 schema 的上傳，registry 保證舊的 consumer 能夠讀取新的 schema 版本，以確保 producer 不能破壞 consumer。

里程碑 5：Functions 和 IO API

下一步是構建 API，以便輕鬆地從 Pulsar 輸入輸出並處理資料。其目標是使用 Apache Pulsar 輕鬆構建事件驅動的應用程式和實時資料管道，無論來自何處，使用者都可以在事件到達時對其進行處理。

Pulsar IO API 使使用者可以通過插入各種 source connector - 將資料從外部系統輸入到 Pulsar 、sink connector - 將資料從 Pulsar 輸出到外部系統，來構建實時流資料管道。目前，Pulsar 提供了多個內建 connector，使用者開箱即用。

此外，StreamNative 維護的 StreamNative Hub（Pulsar connector 的 registry），提供了數十個與流行資料系統整合的 connector。如果 IO API 用於構建流資料管道，則 Functions API 用於構建事件驅動的應用程式和實時流處理器。

無伺服器 function 的概念被用於流處理，然後將 Functions API 構建為輕量級無伺服器庫，使用者可以使用任何語言編寫任何事件、處理邏輯。工程師團隊無需執行和維護另一個叢集就能夠編寫流處理邏輯。

里程碑 6：通過分層儲存為 Pulsar 提供無限儲存

隨著 Apache Pulsar 的普及以及 Pulsar 中儲存的資料量的增加，使用者最終遇到了“保留懸崖”（retention cliff），此時在 Apache BookKeeper 中儲存、管理和檢索資料的成本變得更加昂貴。為了解決這個問題，運維工程師和應用程式開發人員通常使用 AWS S3 等外部儲存作為長期儲存的 sink，然而這樣會失去 Pulsar 的不可變流和排序語義的大部分優勢，而使用者最終不得不管理具有不同訪問模式的兩套系統。

分層儲存的引入支援 Pulsar 將大部分資料解除安裝到遠端雲原生儲存。這種更便宜的儲存形式很容易隨著資料量而擴充套件。更重要的是，通過分層儲存，Pulsar 提供了在與 Flink 等批流融合處理器整合時所需的批處理儲存能力。與 Pulsar 整合的批流一體使公司能夠快速輕鬆地查詢具有歷史背景的實時流，增加競爭優勢。

里程碑 7：外掛協議

在引入分層儲存之後，Pulsar 從一個 Pub/Sub 訊息系統演變為一個可擴充套件的流資料系統，可以接收、儲存和處理資料流。但是，使用其他訊息協議（例如 Kafka、AMQP、MQTT 等）編寫的現有應用程式必須重寫才能採用 Pulsar 的訊息協議。

外掛協議 API 進一步降低了採用 Pulsar 構建訊息流的開銷，開發人員可利用 Pulsar 架構提供的所有優勢將 Pulsar 功能擴充套件到其他訊息領域。於是 StreamNative 和其他行業領導者展開合作，開發流行的外掛協議，包括：

里程碑 8：用於 exactly-once 流處理的事務 API

最近，事務被新增到 Apache Pulsar，以便為流處理啟用 exactly-once 語義。這項基本功能為流資料轉換提供了強有力的保證，可以輕鬆構建可擴充套件、容錯、有狀態的訊息流應用程式來處理流資料。

此外，事務 API 功能不限於已有的客戶端語言。Pulsar 對事務性訊息流的支援是一種可以用任何語言呈現的協議級功能。此類協議級功能可用於各種應用程式。

打造訊息流統一的生態

除了對 Pulsar 技術持續升級，社群還致力於建立一個強大的周邊生態系統。Pulsar 能夠支援豐富的 pub-sub 庫、connector、function、外掛協議以及與流行引擎整合的生態系統，使 Pulsar 使用者能夠簡化工作流程並應用於新的場景。

相關閱讀

想要與社群交流嗎？掃描下方 Pulsar Bot 二維碼，加入 Pulsar 微信交流群

點選連結 ，獲取 Apache Pulsar 硬核乾貨資料！

相關文章