Apache Pulsar：用計算／儲存分離統一 messaging 與 streaming

1. 問題：即時、可靠、大規模搬資料 0:00–0:52

作者提出一個看似簡單但會弄垮團隊的問題：如何在系統各部分之間即時、可靠、大規模地搬資料。過去十年的預設答案是 Kafka；本片要介紹為了解決 Kafka 在成長時的痛點而設計的 Apache Pulsari，並預告內容：是什麼、架構、用途、為什麼在流行、誰在用。

推理因為資料流動是所有分散式系統都躲不掉的問題，作者先把它明確定義成一句話：「如何可靠、即時、大規模地把資料從 A 搬到 B」。接著點名過去十年的預設答案是 Kafka，並埋下伏筆：Kafka 在規模長大後會出現痛點，而 Pulsar 就是針對這些痛點設計的。他用 Yahoo、Tencent、Splunk、Cisco、Discord 等採用者建立可信度，並列出本片五個面向：是什麼、架構、用途、為什麼流行、誰在用。

• C開源的分散式 messaging 與 streaming 平台，解決 Kafka 在規模成長後的痛點→ 畫地圖
• Rreliably / at scale / real time 分別對回什麼→ 存＋回想

AI 補充作者沒說「reliably at scale in real time」三個詞各自的意思，但後面整支影片就是圍繞它們展開：可靠（reliably）對應資料不能遺失；大規模（at scale）對應擴展與百萬 topic；即時（real time）對應 streaming 而非批次。先把這三個詞記住，後面每個架構決策都能對回其中一個。畫面上是 Pulsar 官網的 features 頁，六個特色（快速水平擴展、低延遲 messaging 與 streaming、geo-replication、multi-tenancy、自動負載平衡、多語言 client）就是影片後半會逐一展開的清單。

術語:Apache Kafkai

2. 中間層：broker、queue vs streaming 0:52–2:06

用叫車 app 的司機位置更新舉例：多個服務都要同一筆資料，服務互相直呼會變義大利麵。解法是放一個中央管線，producer 發一次、有興趣的 consumer 訂閱，雙方只約定 channel。這就是 message broker / streaming platformi。這類系統有兩種口味：message queuingi（RabbitMQ，任務交接後 ack）與 streamingi（Kafka，連續有序 log 可重播），過去必須二選一並維護兩套。

推理因為要說明中間層的必要，作者用叫車 app 舉例：一百萬個司機每秒更新位置，同一筆資料要同時給乘客畫面、定價引擎、詐欺偵測、分析儀表板。若服務直接互呼，連線數是 N×M 的義大利麵，任一慢元件會拖垮全體。所以在中間放一根「中央管線」：位置更新只發布一次，誰需要誰訂閱，producer 與 consumer 互不認識、只約定 channel。這根管線就叫 message broker 或 streaming platform。接著他指出這類系統有兩種口味：message queuing（RabbitMQ：交付一個任務、被領走、處理、回 ack）和 streaming（Kafka：連續有序 log，多個 consumer 可從任一點讀與重播）。歷史上兩者要二選一，通常是同時養兩套系統。

• Rmessage queuing 與 streaming 的本質差異→ 存＋回想
• A中央管線像廣播電台，producer 與 consumer 互不認識→ 批判類比

AI 補充投影片把三件事疊在一起：上方是 point-to-point 的義大利麵（問題），中間是 queuing 與 streaming 的歷史分裂（兩種模型、兩套團隊與維運），下方是 Pulsar 的「一根管線同時裝兩種 workload」（解法預告）。兩種模型的本質差異是「訊息被消費後還在不在」：queue 模型裡任務被 ack 後就消失，適合分派工作；streaming 模型裡訊息留在 log 上，consumer 只是移動自己的讀取位置，適合多方各自讀同一份歷史。作者沒明說，但這個差異正是後面「兩種 ack 方式」的根源。

術語:Acknowledge (ack)i

3. Pulsar 的定位與 Yahoo 起源 2:06–3:12

Pulsar 的賣點：一個平台同時處理 queue 型與 stream 型工作負載。它是開源分散式 messaging & streaming 平台，從第一天就為 cloud-nativei 與超大規模設計。2013 年在 Yahoo 內部誕生、2015 上線、2016 開源，動機是要服務 100+ 個產品、跨全球、零訊息遺失。多租戶i、跨區域、不容忍資料遺失都內建在核心。

推理因為提案已經丟出來，作者先給正式定義：Pulsar 是開源、分散式的 messaging 與 streaming 平台，能在同一系統處理 queue 型與 stream 型工作，並且從第一天就為 cloud-native 與超大規模設計。接著用起源說明「為什麼它會有這些性質」：2013 年 Yahoo 內部需要一套能服務 100+ 產品（Mail、Finance、Ads…）、跨全球、絕不掉訊息的系統，市面上沒有，於是自己造，2015 上線、2016 開源，之後持續演進（4.1 版去年釋出）。因此多租戶、跨區域、零資料遺失都是核心內建，不必使用者自己疊上去。

• EYahoo 2013 年起源：100+ 產品跨全球、絕不掉訊息→ 存＋演練
• RCloud-native 的定義→ 存＋回想

AI 補充這段的邏輯是「需求決定設計」：Yahoo 的三個需求（多產品共用、跨區域、不掉訊息）分別對應後面會講的 multi-tenancy、geo-replication、以及寫入複製後才 ack 的耐久性保證。把這個對應記住，後面的優勢清單就不是零散功能，而是同一組需求的落實。另外「cloud-native」在這裡的實際含義是：元件可以獨立、無狀態地增減，這正是下一步要講的分離架構。

4. 基本詞彙與核心想法：計算與儲存分離 3:12–4:12

共通詞彙：producer 寫、consumer 讀、messages 組織成 topici（具名 channel）。定義 Pulsar 的大想法是把 compute 與 storage 分離。對比 Kafka：每個 broker 同時處理訊息收發與把資料存本機磁碟，簡單快速，但加新機器時是空的，必須複製大量既有資料（rebalancingi），大叢集上可能耗時數小時並拖慢效能。

推理因為要講架構，作者先定義三個所有這類系統共用的詞：producer 寫訊息、consumer 讀訊息、messages 組織進 topic（一個具名 channel，如 driver-locations）。然後直接點出定義 Pulsar 的大想法：compute 與 storage 分離。為了讓這個想法有份量，他用 Kafka 做對照：Kafka 的每個 broker 同時做兩件事——處理訊息進出、把資料存在自己本機磁碟。這很簡單很快，但有個代價：新加一台 broker 時它是空的，Kafka 必須把大量既有資料實體複製過去（rebalancing），大叢集上可能要數小時，期間效能受損。

• C把處理訊息收發與持久保存訊息資料放在不同機器層，讓兩者能獨立擴展→ 畫地圖
• RProducer / Consumer / Topic 的定義→ 存＋回想
• Acompute/storage 分離像餐廳把現場烹飪跟食材倉庫分開→ 批判類比
• EKafka rebalancing：新增 broker 要實體複製既有資料，大叢集數小時→ 存＋演練
• P用 producer/consumer/topic 重新描述自己維運的訊息系統→ 練習

AI 補充「compute 與 storage 分離」是整支影片的樞紐概念，之後每個優勢都從它推出。理解方式：在 Kafka 裡「處理能力」和「資料在哪」綁在同一台機器，所以擴充處理能力必然牽動資料搬遷；只要把兩者拆開，擴充其中一個就不需要動另一個。作者這裡只講了 Kafka 的痛，還沒講 Pulsar 怎麼拆——這是刻意的鋪陳。補充一點作者略過的細節：Kafka 的 rebalancing 之所以慢，是因為 partition 是儲存單位也是負載單位，搬 partition 等於搬整段歷史資料。

術語:Producer / ConsumeriCompute/Storage 分離i

5. 兩層架構：無狀態 broker + BookKeeper 4:12–5:25

Pulsar 把兩個工作拆成兩層。第一層 broker 只做訊息收發與 ack 追蹤，且是 stateless、不存資料，像交通指揮。第二層是儲存層，由 Apache BookKeeperi 負責，節點叫 bookiei；broker 收到訊息就寫進 BookKeeper，預設三份複本i。好處：要更多訊息容量就加 broker，立刻上線、無需複製；要更多儲存就加 bookie，立刻接新寫入。官方說法「rapid scaling without data reshuffling」，兩個維度獨立、秒級擴展。

推理因為要回答「怎麼拆」，作者直接給兩層。第一層是 broker：只做訊息收發——接收 producer 的訊息、派送給 consumer、追蹤 ack——而且是 stateless，不在自己磁碟存任何訊息資料，作者比喻為交通指揮。第二層是儲存層，由另一個 Apache 專案 BookKeeper 負責，其節點叫 bookie；broker 收到訊息就寫進 BookKeeper，BookKeeper 耐久保存並複製到多個 bookie（預設三份）。這樣拆的收穫是：需要更多訊息處理能力就加 broker，因為它不帶資料所以立即上線、沒東西要複製；需要更多儲存就加 bookie，立即接收新寫入、不用重排既有資料。官方口號「rapid scaling without data reshuffling」，兩個維度各自獨立、秒級而非小時級。

• CPulsar 的訊息層節點：只做收發與追蹤 ack，不在本機保存訊息資料→ 畫地圖
• CPulsar 的儲存層，獨立的 Apache 分散式日誌儲存專案，負責耐久寫入與跨節點複製→ 畫地圖

AI 補充投影片左半是兩層圖（producer/consumer → brokers → bookies，附 3× replication 放大鏡），右半是「payoff」：加 broker 的天平顯示 capacity 增加、data copying 為零；加 bookie 則 new writes 立即開始。這裡有個容易誤解的點：「加 bookie 不用 reshuffle」不代表舊資料會自動平均分佈到新 bookie——舊資料留在原處，只是新寫入會用到新節點；這對擴容來說已足夠，因為訊息系統的寫入壓力永遠在「新資料」上。另外 BookKeeper 本身是一個獨立的分散式 write-ahead log 服務，Pulsar 只是它的使用者之一，這也是為什麼儲存層能被單獨演進。

術語:Broker（Pulsar）iStateless brokeri

6. 協調層、ledger 分段與 tiered storage 5:25–6:31

誰記得哪個 broker 擁有哪個 topic、資料段在哪？metadata 存在 Apache ZooKeeper（通常三台高可用），是共享的 source of truthi；新版正在改用替代方案，概念上就是一個協調大腦。資料不是一個大檔，而是切成 segment（Pulsar 叫 ledger）分散在多個 bookie，所以單一 topic 的歷史不會困在一台機器上；這也讓 tiered storagei 成為可能：冷資料自動推到 S3 之類的物件儲存，熱資料留在本地。收束：stateless broker 管訊息、bookie 管耐久複製儲存、ZooKeeper 管 metadata，各自獨立且即時擴展。

推理因為 broker 無狀態、資料又分散，作者引入第三個角色：metadata 存在 Apache ZooKeeper（通常三台高可用小叢集），它是系統的共享 source of truth，記錄哪個 broker 擁有哪個 topic、資料段在哪些 bookie。他補充新版正轉向 ZooKeeper 的替代品，但概念上就是「一個協調大腦」。接著說明資料在儲存層的實體形狀：不是一個大檔，而是切成 segment（Pulsar 叫 ledger）散佈在多個 bookie，所以單一 topic 的歷史不會被困在一台機器；這既是擴展順暢的原因，也讓 tiered storage 成為可能——冷資料自動推到 S3 之類的便宜物件儲存，熱資料留在本地保持快。最後他把三個角色收束成一句：stateless broker 管訊息、bookie 管耐久複製儲存、ZooKeeper 管 metadata，各自獨立且即時擴展，這就是 Pulsar 的核心。

• C一個 topic 的歷史由一串 ledger 組成，各自分散存在不同 bookie 上→ 畫地圖
• E加 bookie 後新開的 ledger 自然落到新節點，不用搬舊資料→ 存＋演練
• C依冷熱把資料放不同成本儲存層：舊 ledger 自動卸載到 S3，近期資料留在 bookie→ 畫地圖
• RSource of truth 與 metadata store→ 存＋回想

AI 補充投影片下半三格對應這段三個概念：左「coordination brain」（大腦圖示連到 broker 與 bookie）、中「distributed ledgers」（topic history 被切成 L1、L2、L3…分散）、右「tiered storage」（舊 ledger 推向雲端）。ledger 是理解 Pulsar 擴展性的關鍵：一個 topic 的資料 = 一串 ledger，每個 ledger 各自選一組 bookie 存放，所以「加 bookie」後新開的 ledger 自然落到新節點，這就是上一段「不用 reshuffle」的實作原因。作者提到的 ZooKeeper 替代方案，實務上指的是 Pulsar 可插拔的 metadata store（例如以 etcd 或 Oxia 取代），目的是拿掉 ZooKeeper 這個運維負擔。

術語:Apache ZooKeeper / Metadata storeiLedger（segment）i

7. 架構帶來的五個優勢 6:31–8:20

一、多租戶是一等公民：tenant → namespace → topic 三層階層，一個叢集可安全服務整個組織，各團隊有獨立存取控制與資源政策（Yahoo 原始需求，Kafka 沒有原生支援）。二、geo-replicationi 開箱即用，且支援自動 client failoveri。三、單叢集可達百萬 topic，可以每個使用者／裝置一個 topic。四、彈性訂閱型態i：逐筆 ack（RabbitMQ 風格，適合任務佇列）或累積 ack（Kafka offset 風格，適合有序串流），這就是「messaging 與 streaming 合一」的具體化。五、Pulsar Functionsi：內建的輕量 serverless 計算，用 Java/Python/Go 寫小函式做過濾、路由、轉換、豐富化，不必另起串流處理系統。

推理因為架構已建立，作者逐一推出五個優勢，每個都能對回架構。一、multi-tenancy 是一等公民：topic 組織成 tenant → namespace → topic 三層，一個實體叢集可安全服務整個組織，各團隊有獨立存取控制與資源政策——這是 Yahoo 的原始需求，Kafka 沒有原生支援。二、geo-replication 開箱即用，策略彈性，且獨特地支援自動 client failover：整個區域掛掉，client 自動切到健康叢集。三、單叢集可達百萬 topic，因為儲存是分散的；這解鎖「每個使用者／裝置一個專屬 topic」的設計，不必把大家塞進幾個共享 channel 再過濾。四、彈性訂閱型態：可以逐筆 ack（RabbitMQ 風格，適合任務佇列）也可以累積 ack（Kafka offset 風格，適合有序串流）——同一系統、兩種模型，這就是「messaging 與 streaming 合一」的具體實現。五、Pulsar Functions：內建的輕量 serverless 計算，用 Java/Python/Go 寫小函式在訊息到達時做過濾、路由、轉換、豐富化，簡單處理不必另起一套串流處理系統。

• C同一套實體系統安全服務多個彼此隔離的團隊／產品，各有存取控制與資源配額→ 畫地圖
• C把 topic 資料自動複製到其他地理區域，且能自動 client failover→ 畫地圖
• RSubscription type 的兩種 ack 模式→ 存＋回想
• RPulsar Functions 的定義→ 存＋回想
• A百萬 topic 像每個使用者一個專屬信箱，不用貼標籤過濾→ 批判類比

AI 補充投影片把五項排成一張圖，值得對照架構看：百萬 topic 之所以可能，是因為 topic 資料是 ledger 分段而非每 topic 一個實體檔案；geo-replication 能做到 client failover，是因為 broker 無狀態、資料在儲存層有複本。第四項回應了最早「queue vs streaming 二選一」的痛：差別只在 consumer 怎麼 ack，Pulsar 讓同一個 topic 支援兩種訂閱方式。作者這裡對「multi-tenancy Kafka 不原生支援」說得略重——Kafka 有 ACL 與 quota，但沒有 tenant/namespace 這種一等結構，隔離要靠命名慣例與外部工具拼湊。

術語:Tenant / Namespace / Topic 階層i

8. 誰在用、用來做什麼 8:20–9:30

四類用途：一、公司級訊息平台，把 Kafka、RabbitMQ、ActiveMQ、SQS 合併成一個多租戶 Pulsar，只維運一套。二、任務佇列：影片轉檔、縮圖、背景工作，靠 shared subscriptioni 與逐筆 ack。三、可擴展的 RPC：服務透過 topic 而非直接 API 互通，因為 topic 便宜所以可行。四、關鍵任務應用：銀行、支付、訂單，訊息先複製到多個 bookie 並寫入磁碟才回 ack，機器斷電資料也在。

推理因為能力要落到場景，作者列四類用途，每類對應前面某項能力。一、公司級訊息平台：把 Kafka、RabbitMQ、ActiveMQ、SQS 通通整併成一個多租戶 Pulsar，只維運一套技術，不同團隊的服務互通變得簡單——這靠 multi-tenancy 與兩種模型合一。二、任務佇列：影片轉檔、縮圖、按鈕觸發的背景工作，需要分派給一池 worker 並可靠 ack——Pulsar 的 shared subscription 與逐筆 ack 原生支援。三、可擴展的 RPC：服務透過 topic 而非直接 API 呼叫互通，因為 Pulsar 的 topic 便宜到可以每個請求路徑一個，其他系統會貴到做不起。四、關鍵任務應用：銀行、支付、訂單處理，掉一則訊息就不可接受；Pulsar 保證訊息複製到多個 bookie 並寫入磁碟後才回 ack 給應用，機器斷電資料也在。

• C訊息先複製到多個 bookie 並寫入磁碟，系統才向 producer 回 ack→ 畫地圖
• E金融級保證：ack 那一刻資料已在多台機器磁碟上→ 存＋演練
• RShared subscription 與 RPC over topics→ 存＋回想
• P評估自己系統卡在哪個需求，值得列入 Pulsar 候選清單→ 練習

AI 補充畫面是 Pulsar 官網的 use cases 頁：Cisco IoT（數億裝置、跨多個 Kubernetes 叢集、取代舊 message queue）、vivo（監控架構）、Netdata（每個 agent 一個專屬 topic）、以及 Huawei、Verizon Media。Netdata 的例子正是「百萬 topic」能力的實際用法。第四類的耐久性保證值得展開：「複製到多個 bookie 且落盤後才 ack」意味著 producer 收到 ack 的那一刻資料已經在多台機器的磁碟上，這是比 Kafka 預設（acks 可設、fsync 通常延後）更強的預設保證，代價是寫入延遲略高。

術語:RPC over topicsiDurable write（落盤後 ack）i

9. 為什麼在流行與收尾 9:30–10:04

為什麼大公司採用：cloud-native 的分離式架構、整併多套系統、能在那個規模下維運。作者收尾：這是入門介紹，若想看實際怎麼用請留言。

推理因為前面已把用途對回能力、能力對回架構，作者的收束很短：一、cloud-native 的分離式架構；二、整併多套系統為一套；三、能在那種規模下維運。這三點分別就是本片第二部分（架構）、第一部分（queue 與 streaming 合一）、第三部分（能力）的濃縮。最後他說明這只是入門，若想看實際怎麼使用 Pulsar，請留言，他會再做後續。

AI 補充作者的三句收束其實漏了一個他自己前面強調過的點：「不掉資料」的耐久性保證，這是金融類採用者的主因。另外，影片完全沒碰的面向是運維成本與生態：Pulsar 需要 broker + bookie + metadata store 三種元件，比 Kafka（尤其 KRaft 模式後只剩 broker）多；而 Kafka 的 connector、串流處理（Kafka Streams、Flink 整合）生態更成熟。這些是選型時要自己補的功課，也是下一步值得看的方向。