# LinkedIn：使用 Databus 創建低延遲更改數據捕獲系統 > 原文： [http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html)  *這是 LinkedIn 分布式數據系統團隊的高級成員 [Siddharth Anand](http://practicalcloudcomputing.com/) 的特邀帖子。* 在過去的三年中，我很幸運能夠與許多新興的 NoSQL 產品一起使用，以支持高流量，面向客戶的網站的需求。 在 2010 年，我幫助 Netflix 成功 [將其 Web 規模用例從 Oracle 轉換為 AWS 的托管數據庫服務 SimpleDB](http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-to-high-availability-storage-syste.html) 。 遷移完成后，我們開始了第二次遷移，這次是從 SimpleDB 到 Cassandra 的遷移。 第一次過渡是我們從自己的數據中心遷移到 AWS 的云的關鍵。 第二個是我們從一個 AWS 區域擴展到多個地理分布區域的關鍵-今天，Netflix 為兩個 AWS 區域提供流量，一個在弗吉尼亞州，另一個在愛爾蘭（ [F1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_1) ）。 這兩個過渡都是成功的，但都涉及集成難題，例如創建數據庫復制技術。 2011 年 12 月，我加入了 LinkedIn 的分布式數據系統（ DDS ）團隊。 DDS 開發了數據基礎結構，包括但不限于 NoSQL 數據庫和數據復制系統。 LinkedIn 對構建和開放源代碼創新項目并不陌生，它正在加倍使用 NoSQL 來加速其業務-DDS 正在開發一個名為 Espresso（ [R1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Reference_1) ）的新 NoSQL 數據庫，這是以后的主題。 觀察到兩家流量大的網絡公司解決了類似的問題之后，我不禁注意到了一系列的創新。 這些問題中有些是困難的，對于每個公司來說，單獨解決其問題確實是不幸的。 同時，由于缺乏可靠的開源替代方案，每個公司都不得不解決這些問題。 這顯然對一個以快速發展的新興企業為主導的行業產生了影響，這些行業無法建立 50 人的基礎設施開發團隊，也無法花數月的時間來構建功能。 ## **更改數據捕獲系統** 今天，我想重點介紹一種這樣的創新：Change Data Capture 系統 關系數據庫已經存在很長時間了，已經成為公司所有數據的可靠存儲介質。 換句話說，它是公司業務關鍵數據的真實來源。 通常，數據會從此主要數據存儲中提取，轉換并存儲在輔助數據存儲中，例如數據倉庫。 該二級存儲通常支持推動業務洞察力和方向的數據分析。 在此方案中，這兩個存儲分別稱為 OLTP 存儲和 OLAP 存儲。 （ [F2](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_2) ） 所有這些已經存在了數十年，那么有什么新東西？ 來自主存儲的數據越來越多地用于提供業務決策之外的其他信息。 在 LinkedIn 上，它還提供實時搜索索引，實時網絡圖索引，緩存一致性，數據庫只讀副本等。這些都是 LinkedIn 的近實時數據需求的示例。 如果您曾經從事過將數據從主存儲轉移到輔助存儲的工作，那么您無疑會熟悉可用的選項。 例如，如果您在 OLTP 到 OLAP 的空間中工作，則使用某種 ETL（提取，轉換和加載）技術。 這個領域已經看到了圍繞工具（，例如，使用 GUI 拖放工具輕松定義轉換）和跨供應商集成（，例如從 Oracle 到 Teradata，Aster Data 等）的創新。 .. ）。 該行業通常使用 ETL 進行夜間工作，以使高管可以了解前一天，一周，一個月，一年的業務表現。 如果需要從主數據存儲中獲取近實時更新流（如下所示）以解決 LinkedIn 的近實時需求，該怎么辦？  除了昂貴且專有的特定于供應商的產品外，幾乎沒有其他選擇。 ## **引入數據總線** Databus 是該領域的創新解決方案。 它具有以下功能： * Pub-sub 語義 * 訂單內交付保證 * 源處的提交按事務分組 * ACID 語義在整個管道中得以保留 * 支持流分割 * 然后按分區確定訂購保證 * 像其他消息傳遞系統一樣，為最近發布的消息提供了非常低的延遲消耗 * 與其他郵件系統不同，它提供任意長的回溯，而不會影響源 * 高可用性和可靠性 ## 數據總線如何工作？ 數據總線由 3 個重要部分組成： * 繼電器 * 引導程序 * 客戶資料庫 下圖顯示了 Databus 架構。 數據總線中繼將從源數據庫（例如 Oracle，MySQL 等... ）（ **步驟 1** ）中拉出最近提交的事務。 中繼會將這些數據反序列化為緊湊形式（Avro 等），并將結果存儲在循環的內存緩沖區中。 偵聽事件的客戶端（訂戶）將拉動最近在線的更改，因為它們出現在中繼中（ **步驟 2** ）。 Bootstrap 組件還在監聽中繼中出現的在線更改。（ **步驟 3** ）  如果訂戶落在后面，以致其請求的數據不再位于中繼的內存緩沖區中，則訂戶可以請求從過去的時間 T 開始出現的合并增量（ **步驟 4** ）。 這將返回自時間 T 以來發生的所有更改的有效表示。  如果沒有數據集先驗知識的新訂戶要加入聚會，則需要完全引導。 首先，訂戶的 Databus 客戶端庫將在過去的某個時間 T 請求一個一致的快照（ **步驟 5** ）。 然后，自該時間 T 起，客戶端庫將請求合并 Delta（ **步驟 6** ）。 在訂閱服務器應用合并增量之后，客戶端庫將切換為偵聽來自中繼的聯機更改（ **步驟 7** ）。 客戶端庫幫助訂戶獲得自時間 T 以來的所有更改，時間 T 可以是任意時間點，從而使訂戶不受更改來源的詳細信息的影響。  ## **Databus 的自舉組件** Databus 最具創新性的功能之一是其 Bootstrap 組件。 數據變更捕獲系統已經存在了很長時間（，例如 Oracle Streams ）。 但是，當使用者落后時，所有這些系統都會在主數據存儲上增加負載。 引導一個全新的消費者是另一個問題。 它通常涉及一個非常手動的過程-即在一個臨時的 Oracle 實例上恢復前一晚的快照，轉換數據并將其傳輸給使用者，然后應用自快照以來的更改等... Databus 的 Bootstrap 組件以無縫，自動化的方式處理上述兩個用例。 ## Databus 的自舉組件如何工作？ Databus Bootstrap 組件由兩種類型的存儲組成：日志存儲和快照存儲。 日志存儲服務于合并增量，而快照存儲服務于一致的快照。  1. 如前所述，Bootstrap 組件偵聽中繼中發生的在線更改。 LogWriter 將這些更改附加到日志存儲。 2. 日志應用程序將日志存儲中的最新操作應用于快照存儲 3. 如果新訂戶連接到 Databus，則該訂戶將從運行在 Bootstrap 組件中的 Bootstrap 服務器進行引導。 4. 客戶端將首先從快照存儲中獲取一致的快照 5. 然后，客戶端將從日志存儲中獲得出色的合并增量 6. 客戶端趕上中繼的內存緩沖區窗口后，客戶端將切換為從中繼讀取 ## 數據總線的未來計劃 Databus 和 Espresso（我們下一個 NoSQL 商店的的工程師，足夠說）的團隊一直在不懈地努力以支持 Espresso 中的 Databus 復制-Databus 將成為 Espresso 的本機內部復制技術。 此外，一旦團隊找到了一些空閑時間，他們將對其進行開源。 我們正在尋找在解決棘手問題方面有良好記錄的工程師加入我們的 DDS。 如果您有興趣，可以隨時在 [LinkedIn](http://www.linkedin.com/in/siddharthanand) 上 ping 我。 ## 這對 NoSQL 意味著什么 與 Databus 一樣酷，它不適用于所有 NoSQL 存儲。 當前，許多 NoSQL 技術（尤其是許多 Dynamo 風格的鍵-值存儲）提供的功能集之間存在很大差距。 它們沒有提供 Databus 可以提取的時間軸一致的更改流。 沒有這種支持，將有兩個未實現的用例： * 支持向現有商業智能基礎架構（，即每晚，面向 ETL 的負載）中的出站提要 * 支持向二級索引（例如搜索，網絡圖，緩存等）的出站近實時提要... 最近，對于 Cassandra，Netflix 和 Ooyala 都分別解決了這個問題。 Netflix 發布了一個有關 [Aegisthus](http://techblog.netflix.com/2012/02/aegisthus-bulk-data-pipeline-out-of.html) 的技術博客，該系統將最終一致的數據文件集轉換為時間軸一致的流。 該流當前由 Business Intelligence 消耗-它不是實時的，因為它取決于內存刷新間隔。 但是，通過一些調整，它可以接近實時。 我們期待該技術的開源。 更重要的是，我們希望 NoSQL 供應商為其產品解決此問題。 ## 更多資源 * [數據基礎結構@ LinkedIn](http://www.slideshare.net/r39132/linkedin-data-infrastructure-qcon-london-2012) -QCON London 2012，Sid Anand，LinkedIn 高級會員 * [數據總線：用于時間線一致的更改數據捕獲的系統](http://www.slideshare.net/dtunkelang/databus-a-system-for-timelineconsistent-lowlatency-change-capture) -CIKM 2011，Chavdar Botev，LinkedIn 高級會員 * LinkedIn 上的 [數據基礎結構](http://www-conf.slac.stanford.edu/xldb2011/talks/xldb2011_tue_1005_LinkedIn.pdf)-XLDB 2011，Shirshanka Das，LinkedIn 高級成員 * [LinkedIn 基礎設施](http://qconsf.com/dl/QConSF2007/slides/public/JeanLucVaillant_LinkedIn.pdf) -QCON SF 2007，Jean-Luc Vaillant，LinkedIn 聯合創始人兼前首席技術官 ## 致謝 我要感謝構建此系統的工程師們的不懈努力： 阿迪亞·奧拉德卡（Aditya Auradkar），查夫達爾·博特夫（Chavdar Botev），席爾香卡·達斯（Shirshanka Das），戴夫·德馬格（Dave DeMaagd），亞歷克斯·費恩伯格（Alex Feinberg），潘寧德拉·甘蒂（Phanindra Ganti），雷·高（Bhaskar Ghosh），基肖爾·戈帕拉克里希納（Kishore Gopalakrishna），米希爾·甘地（Mihir Gandhi），布倫丹·哈里斯（Broaddan Harris），斯沃洛普·賈加迪什（Swaroop Jagadish），喬爾·科西（Joel Koshy），凱文·克魯瓦茲（Jay Lua Naga） ，Neha Narkhede，Sasha Pachev，Igor Perisic，Lin Qiao，Tom Quiggle，Jun Rao，Bob Schulman，Abraham Sebastian，Oliver Seeliger，Adam Silberstein，Boris Shkolnik，Chinmay Soman，Subbu Subramaniam，Roshan Sumbaly，Kapil Surlaker，Sajid Topiwala Tran，Balaji Varadarajan，Jemiah Westerman，Zach White，David Zhang，Jason Zhang，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar，Nishant Vyas，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar 和 Nishant Vyas。 我還要特別感謝 Bob Schulman，Kapil Surlaker 和 Shirshanka Das 對本文的幫助。 ## 腳注 1. 就快速延遲而言，Netflix 的英國和愛爾蘭客戶受益于 Netflix 在本地的區域性業務。 如果您不熟悉 AWS 區域，則區域可為最終用戶提供地理位置優勢。 區域本身由幾個數據中心組成，這些數據中心在 AWS 中稱為“可用區”。 顧名思義，可用區在托管區域內提供災難恢復。 對于像網站這樣的對延遲敏感的應用程序，跨區域災難恢復從來都不是一個好主意。 2. OLTP（在線事務處理）與 OLAP（在線分析處理）：這區分了它們的用途-OLTP 用于主數據服務，OLAP 用于主數據的修改后的副本的分析處理。 “ Databus 簡介” ...這可用開源嗎？ 那將會？ 我們想開始討論。 它將很快開源。 人們對此有何看法？ 人們將如何使用它？ 等等... 我們計劃在今年晚些時候開源 Databus。 我期待它被開源。 我認為許多人（包括我自己在內）都將使用它從舊版源數據庫中將其用于 ETL，在這些舊版源數據庫中，架構不太適合加載增量數據集。 那里的商業 CDC 產品（例如 Attunity）使開發人員難以自定義和做出貢獻。 我正在研究一種通過對 SQL Server 事務日志進行反向工程來獲取 CDC 數據的解決方案，并且很樂意遵循常見的 CDC 抽象。 我看到這被用于將交易從關系業務軟件數據庫中引入并進入多個專用系統-圖形數據庫，統計平臺，HDFS 存儲，內存 BI 存儲和流數據庫-都在同一時間 時間。 我很高興聽到這一消息，因為它是我對商業軟件的未來愿景的關鍵部分。 首先，感謝您與我們分享。 我對 ETL 方面的理解不夠充分，但是我嘗試查看 MongoDB 如何適合此方案。 我很可能在這里簡化了一些事情，但是請忍受。 :) 因此，我們都知道有一個常規數據庫存儲主要數據。 該數據庫按順序發布它的更改，這些更改被捕獲并保存在固定大小的緩沖區中，并可供訂戶使用。 更改的緩沖區定期備份到磁盤上。 打算進行完全同步的新成員可以從備份副本中提取更改。 與訂戶一起的數據可以被用來導出其他有意義的數據。 在我看來，MongoDB 提供了所有這些功能，或者至少提供了構建此類系統的基本基礎結構。 常規數據庫是 MongoDB。 它以 oplog 的形式發布更改-通常是內存映射。 客戶端可以打開一個尾部游標到 oplog 集合，并在更改發生時將更改流式傳輸到數據庫中。 客戶端可以與作為副本集的一部分安排的輔助 DB 相關聯，在該副本集上可以運行 Map-Reduce 或 Aggregation 任務。 輔助服務器之一可以充當“ Bootstrap 服務器”。 （通過執行完全同步，可以從另一個輔助節點啟動新的輔助節點）。 特殊輔助節點的操作日志可能類似于“中繼”，以避免在主節點上加載。 這有道理嗎？ MongoDB 是否為此項目進行了評估？ 任何想法，將不勝感激。 OTOH，現在，如果這必須與特定的數據庫一起使用，那么每個數據庫都將有“ Databus 驅動程序”嗎？ 例如，如果必須與 MongoDB 一起使用，則必須有一個 MongoDB 驅動程序，該驅動程序可以理解 MongoDB 發布的 oplog 格式并以通用格式提供給客戶端。 還是您要發布標準并要求數據庫開發人員根據該標準進行更改？ 再次感謝您。 順便說一句，我也正在等待有關 Espresso 的帖子。 :) -婆羅門 席德，不錯的帖子 在 Yammer，我們正在為近實時搜索做類似的事情。 Databus 看起來更廣泛，但是原理相似。 我們正在使用 BDB JE 作為本質上是變更集服務的后備存儲。 在更新 ActiveRecord 模型時，Rails 應用程序將更改為變更集服務的信標。 變更集服務為變更建立索引。 另一個服務遍歷更改集索引并生成 Lucene 索引。 模型之間存在一些額外的依賴關系，因此，當依賴模型更新時，依賴于該模型的模型將“失效”，因此將其重新索引。 我真的很想了解更多信息，并且對開放源代碼有所了解。 我們所提供的大部分服務滿足了我們的需求，但是絕對可以改善。 席德 好的帖子，并感謝分享。 我們正在尋求重新發明輪子，以創建與您上面描述的非常相似的東西。 您是否知道何時可以嘗試使用這些位？ 我們將非常有興趣了解更多有關該產品的信息，并看一看開放源代碼并在適用的情況下做出貢獻。 我試圖找到有關中繼如何將已提交的更改從數據庫中拉出的詳細信息。 是否有任何視頻或文檔對此進行了詳細說明？ 據我了解，今天它已在 Oracle 上使用。 該技術是否取決于特定的 Oracle 功能，或者可以在“通用” RDBMS 上實現？ Databus Relay 可以從 MS SQL Server（源數據庫）中提取事務。