哈囉，各位對資料和系統架構充滿好奇的朋友們！今天我們要來聊一個超酷的話題：Pinterest 怎麼處理他們家數百 TB 的海量資料傳輸？ 說到 Pinterest，大家可能想到的都是那些美美的圖片、生活靈感，但你知道在這些光鮮亮麗的背後，藏著一套多麼精妙的資料工程系統嗎？特別是他們如何利用 Change Data Capture (CDC) 這項技術，讓資料在龐大的分散式系統中，既能即時流動，又能保持穩定可靠，這簡直就是一場資料傳輸的魔術秀！

什麼是 Change Data Capture (CDC)？為什麼 Pinterest 需要它？

想像一下，你的資料庫就像一本超級厚的日記本，每天都有成千上萬的人在上面寫寫畫畫（新增資料）、修改內容，甚至撕掉幾頁（刪除資料）。如果每次你想知道「今天日記本裡發生了什麼事」，都得從頭到尾翻一遍，那效率肯定低到爆對吧？這就是傳統「批次處理」的困境：它就像每天固定時間，把整本日記本複製一份，然後慢慢比對哪裡不一樣，費時又費力。

Change Data Capture (CDC) 就像是請了一個超級厲害的偵探，他不是去翻整本日記，而是直接在日記本的「寫作過程」中，即時記錄下每一個變動：哪一頁新增了什麼、哪一句被修改了、哪一段被刪除了。這樣一來，你就能在「事情發生當下」立刻知道，並且把這些變動通知給所有關心這本日記的人。

CDC 的超能力：即時、高效、低負擔

CDC 之所以會成為現代資料平台不可或缺的技術，主要有以下幾個原因：

• 即時資料處理： 傳統批次處理可能每隔幾小時才跑一次，但 CDC 能讓你的系統在資料一有變動時就立即響應，實現真正的即時分析和應用。
• 更好的資料整合： 不同的系統之間需要保持資料同步？CDC 讓它們不必重複複製整個資料集，只需傳輸增量變動，大大提升效率。
• 降低來源資料庫負載： 只捕捉增量變動，而不是掃描整個資料庫，這能顯著減少對來源資料庫的壓力。
• 稽核與合規性： 所有資料變動都被記錄下來，形成完整的資料歷史，對於法規遵循和安全稽核來說，這可是個大寶藏！

那麼，像 Pinterest 這樣擁有數百 TB 資料、每秒處理數百萬次查詢的巨型平台，為什麼會對 CDC 如此著迷呢？簡單來說，他們需要讓使用者新增一個 Pin、更新個人資料這些動作，能夠「瞬間」反應到推薦引擎、廣告系統、詐騙偵測等數十個下游服務中。如果沒有 CDC，這些系統的資料同步將會是一場噩夢，甚至是不可能完成的任務。

Pinterest 的資料傳輸挑戰：從「各自為政」到「統一戰線」

在 Pinterest 決定建立一個統一的 CDC 平台之前，他們也經歷過一段「群雄割據」的時期。當時，公司內部不同的團隊為了各自的需求，都開發了自己的 CDC 解決方案。這聽起來好像很靈活，但實際上卻帶來了一堆麻煩：

• 行為不一致： 各自為政的系統，行為模式當然也五花八門，難以管理和維護。
• 責任歸屬不明： 系統出問題了？大家面面相覷，不知道該找誰負責。
• 可靠性堪憂： 在處理海量資料的環境下，這種碎片化的架構很快就成為系統可靠性的瓶頸。

為了擺脫這種混亂局面，Pinterest 的工程團隊決定痛定思痛，建立一個通用且可擴展的 CDC 平台。他們的目標很明確：用一個可靠的系統取代多個獨立的方案，減少重複勞動，簡化升級流程，並為所有團隊提供一致的資料捕捉與處理方式。

新 CDC 平台的目標：快、穩、廣、彈

這個新平台可不是隨便搭搭就好的，它肩負著幾項重要的使命：

• 資料不遺漏 (At-least-once processing)： 確保每一筆資料變動都能被捕捉並傳遞，即使需要重試。這就像是郵局保證你的信件至少會送到一次，不會丟失。
• 超大規模支援： Pinterest 的資料庫有上萬個分片 (shards)，新平台必須能夠輕鬆處理這麼龐大的規模，而且不能影響效能。
• 資源平均分配： 系統要能將工作量均勻分配到各個機器上，同時盡量減少對來源資料庫的影響。
• 高度靈活性與可觀測性： 團隊可以根據自己的使用場景調整設定，並且能透過詳細的指標監控系統的健康狀況。

說到分片 (shards)，這又是 Pinterest 處理海量資料的另一個秘密武器。由於單一資料庫無法承受每秒數百萬次的查詢，Pinterest 將資料庫分割成數千個獨立的部分，每個部分就是一個分片。這樣做雖然能提高擴展性，但也讓 CDC 變得更複雜了——你不能只監控一個資料庫，而是要同時監控上萬個！

Pinterest 的 CDC 系統架構：控制平面、資料平面與 Kafka 的完美協奏曲

Pinterest 選擇了開源的 Red Hat Debezium 作為其 CDC 系統的核心。Debezium 是一個強大的工具，能夠追蹤資料庫變動並將其串流到 Apache Kafka 等系統。然而，Debezium 在處理單一分片時表現出色，但 Pinterest 需要同時管理數千個分片。直接修改 Debezium 的原始碼會讓未來的升級變得困難重重，這可不是一個好主意。

於是，Pinterest 的工程師們想出了一個聰明的辦法：將系統拆分成兩個層次——控制平面 (Control Plane) 和 資料平面 (Data Plane)。這種分離的設計讓他們無需深度客製化底層工具，就能實現大規模擴展。這就像是把一個大型樂團分成指揮和演奏者，指揮負責協調，演奏者專心演奏，各司其職，才能奏出美妙的樂章。

系統架構一覽

以下是 Pinterest CDC 系統的簡化架構圖：

控制平面 (Control Plane)：聰明的指揮家

控制平面就像是整個 CDC 系統的「大腦」和「指揮家」。它的核心職責就是確保所有的 Debezium 連接器（負責讀取資料庫變動的組件）都能正確設定、順暢運行，並且在出問題時能自動修復。

• 運行環境： 它運行在 AWS Auto Scaling Group 中的單一 EC2 主機上，並設定最小和最大實例數都為一。這表示如果這台主機掛掉了，AWS 會自動替換一台新的，確保高可用性。
• 工作流程： 控制平面每分鐘執行一次主循環，主要有三個步驟：
  1. 確定理想狀態： 從 ZooKeeper（儲存所有分片資訊）讀取連接器配置和資料庫拓撲，了解應該有多少連接器在運行，以及它們的配置應該是什麼樣的。
  2. 檢查當前狀態： 查詢 Kafka Connect，看看目前有哪些連接器在運行，以及它們的實際配置。
  3. 協調差異： 如果有新的分片，就創建新的連接器；如果現有配置過時，就更新它們；如果任何連接器失敗了，就重啟它們。這就像一個盡責的管家，隨時確保一切都在正軌上。

完成這些步驟後，控制平面還會發出詳細的指標，幫助工程師們監控系統的健康狀況和效能。

資料平面 (Data Plane)：勤勞的執行者

資料平面是真正執行 CDC 工作的地方。它直接連接到資料庫，讀取變動，並將它們串流到 Kafka。

• 運行環境： 它在一個獨立的叢集上以分散式模式運行 Kafka Connect，這個叢集橫跨 AWS 的三個可用區 (Availability Zones, AZs)。這樣設計可以提高系統的彈性，即使一個可用區出現問題，其他可用區也能繼續運行。
• 工作分配： 這個叢集中的所有機器都屬於同一個 Kafka Connect 群組，它們會自動共享工作。
• 連接器與分片： 每台機器可以運行多個 Debezium 連接器，每個連接器負責處理一個資料庫分片。當資料在分片中發生變動時，這些連接器就會將變動串流到 Kafka 主題 (topics)，供下游系統消費。

Apache Kafka：資料傳輸的高速骨幹

Apache Kafka 在這個系統中扮演著至關重要的角色，它就像一條堅固、高速的訊息骨幹，肩負著三大任務：

• 儲存連接器元資料： Kafka 內部會儲存所有連接器的記錄，這些記錄對於系統的協調至關重要。
• 儲存 CDC 資料： 所有捕捉到的資料庫變動都會寫入預先配置好的 Kafka 主題中，任何需要即時資料的 Pinterest 內部系統或團隊都可以從這裡消費。
• 協調分散式工作者： Kafka Connect 利用 Kafka 代理 (brokers) 來管理協調任務，例如領導者選舉（決定哪台機器負責管理任務）和工作者同步。

挑戰與解決方案：Pinterest 的「打怪升級」之路

要在 Pinterest 這種規模下運行 CDC 系統，絕不是一帆風順的。每秒數百萬次的查詢、每天數百 TB 的資料，這些都讓再精巧的系統也可能達到極限。Pinterest 的工程團隊在部署和擴展系統的過程中，也遇到了不少「大魔王」，但他們都透過精準的技術方案一一擊破。

挑戰一：資料積壓與記憶體溢出 (OOM)

有些資料集實在是太龐大了，導致 CDC 任務出現資料積壓 (backlogs)。當資料變動湧入的速度比系統處理的速度還快時，就會發生積壓。這不僅會造成延遲，還會導致記憶體溢出 (Out-of-Memory, OOM) 錯誤，讓 CDC 任務直接崩潰。

• 解決方案：
  • 從最新偏移量啟動 (Bootstrapping from the latest offset)： 當新的 CDC 任務啟動時，它會從資料流的最新點開始讀取，而不是重新處理所有歷史資料。這大大減少了任務啟動時需要處理的資料量。
  • 流量限制 (Rate limiting)： 控制資料攝入的速度，防止記憶體超載。這就像給水龍頭裝上一個開關，避免水流過大而淹沒水槽。

挑戰二：頻繁的任務再平衡 (Frequent Task Rebalancing)

每個 CDC 連接器都被分配到一台主機上。在一個叢集中大約有 3,000 個連接器，Pinterest 發現 Kafka Connect 經常發生任務再平衡。再平衡是將任務重新分配到可用主機的過程，但如果發生得太頻繁且不可預測，就會帶來問題：

• 所有連接器暫時轉移到單一主機，導致過載。
• 部署和故障轉移期間出現高延遲。
• 增加重複任務的風險（多個主機處理同一份資料）。

根本原因在於 rebalance.timeout.ms 的預設設定太短了。Kafka Connect 沒有足夠的時間來穩定任務分配，就急著重新洗牌。

• 解決方案：
  • 增加再平衡超時時間： Pinterest 將 rebalance.timeout.ms 增加到 10 分鐘，給予 Kafka Connect 足夠的時間來穩定任務分配。這使得工作在主機之間分佈得更加平衡和可預測。

挑戰三：KV 儲存故障轉移時間過長

Pinterest 的鍵值 (Key-Value, KV) 儲存叢集在執行領導者故障轉移 (leader failover) 時，可能需要兩個多小時。領導者故障轉移是指當叢集中的主伺服器掛掉時，領導權轉移到另一台伺服器。在這段期間，CDC 任務會因為仍然指向舊的領導者而失敗。

控制平面會反覆刪除並重新創建任務，導致長時間的持續再平衡。

• 解決方案：
  • 讓 CDC 工作者自行處理分片發現和故障轉移： Pinterest 讓 CDC 工作者本身負責分片發現和故障轉移，而不是依賴控制平面。這將故障轉移的恢復延遲縮短到一分鐘以內，並避免了不必要的任務重新洗牌。

挑戰四：Kafka Bug 導致重複任務

一個已知的 Kafka Bug (KAFKA-9841) 導致多個主機運行相同 CDC 任務的重複實例。這造成了幾個嚴重的問題：

• 重複的資料被傳送到下游系統。

• 工作負載在主機之間變得不均勻。

• 頻繁的再平衡。

• CPU 使用率飆升至 99%，將系統推向極限。

• 解決方案：

  • 升級 Kafka 版本： Pinterest 升級到 Kafka 2.8.2 版本 3.6，這個版本包含了對該 Bug 的修復。他們也維持了增加後的再平衡超時時間。在應用這些變更後：
    • 每個任務都如預期般只在一台主機上運行。
    • CPU 使用率下降並穩定在 45% 左右。
    • 系統能夠穩定運行 3,000 個任務，不再出現不穩定現象。

總結：從 Pinterest 學到的資料工程智慧

Pinterest 在 Change Data Capture 上的實踐，為我們展示了如何在極大規模下運行開源資料工具。透過在 Debezium 和 Kafka 的基礎上進行構建，Pinterest 的工程團隊創建了一個能夠處理數千個資料庫分片、每秒數百萬次查詢，並確保資料即時可靠流動的系統。

他們設計的一個主要優勢在於控制平面和資料平面的明確分離。控制平面作為中央協調者，管理連接器配置並確保一切同步；資料平面則專注於在分散式叢集中串流實際的資料庫變動。這種分離使得 Pinterest 能夠在不修改核心 Debezium 程式碼的情況下進行擴展，這也讓系統更容易維護和升級。

Pinterest 的經驗也告訴我們，在這種規模下運行 CDC，即使是再小的細節也需要仔細關注。頻繁的任務再平衡、漫長的故障轉移時間、記憶體超載以及重複任務等問題，都需要仔細調整、更改配置和有針對性的升級才能解決。

這不僅僅是技術的勝利，更是工程師們面對挑戰、不斷優化、追求卓越的體現。希望這篇文章能讓你對 Pinterest 的資料傳輸魔法有更深入的了解，也為你在自己的資料工程之路上帶來一些啟發！

參考資料

1. How Pinterest Transfers Hundreds of Terabytes of Data With CDC
2. 什麼是變更資料捕獲 (CDC)？
3. Apache Kafka 官方網站
4. Debezium 官方網站