LinkedIn實時低延遲數據抓取系統Databus開源

去年的架構師峰會上，來自LinkedIn的高級軟件工程師Lei Gao做了一場名為《LinkedIn的數據處理架構》的演講，著重介紹LinkedIn內部的數據基礎設施的演變，其中提到Databus數據總線項目，當時就引起大家諸多好奇。前不久，LinkedIn工程團隊官方博客發布消息：Databus項目開源。

在互聯網架構中，數據系統通常分為真實數據（source-of-truth）系統，作為基礎數據庫，存儲用戶產生的寫操作；以及衍生數據庫或索 引，提供讀取和其他復雜查詢操作。後者常常衍生自主數據存儲，會對其中的數據做轉換，有時還要包括復雜的業務邏輯處理。緩存中的數據也來自主數據存儲，當 主數據存儲發生變化，緩存中的數據就需要刷新，或是轉為無效。

LinkedIn內部有很多專用的數據存儲和服務系統，構成了一個多種多樣的生態系統。基礎的OLTP數據存儲用來處理面向用戶的寫操作和部分讀操 作。其他專用系統提供負責查詢，或者通過緩存用來加速查詢結果。因此，整個生態系統中就需要一個可靠的、支持事務的、保持一致性的數據變更抓取系統。

Databus就是一個實時的低延遲數據抓取系統。從2005年就已經開始開發，2011年在LinkedIn正式進入生產系統。

在Databus的Github頁面上，介紹了他們選擇目前解決方案的決策過程。

處理這種需求有兩種常用方式：

應用驅動雙向寫：這種模式下，應用層同時向數據庫和另一個消息系統發起寫操作。這種實現看起來簡單，因為可以控制向數據庫寫的應用代碼。但是，它會 引入一致性問題，因為沒有復雜的協調協議（比如兩階段提交協議或者paxos算法），所以當出現問題時，很難保證數據庫和消息系統完全處於相同的鎖定狀 態。兩個系統需要精確完成同樣的寫操作，並以同樣的順序完成序列化。如果寫操作是有條件的或是有部分更新的語義，那麼事情就會變得更麻煩。

數據庫日志挖掘：將數據庫作為唯一真實數據來源，並將變更從事務或提交日志中提取出來。這可以解決一致性問題，但是很難實現，因為Oracle和 MySQL這樣的數據庫有私有的交易日志格式和復制冗余解決方案，難以保證版本升級之後的可用性。由於要解決的是處理應用代碼發起的數據變更，然後寫入到 另一個數據庫中，冗余系統就得是用戶層面的，而且要與來源無關。對於快速變化的技術公司，這種與數據來源的獨立性非常重要，可以避免應用棧的技術鎖定，或 是綁死在二進制格式上。

在評估了兩種方式的優劣之後，我們決定選擇日志挖掘，將一致性和單一真實數據來源作為最高優先級，而不是易於實現。

Databus的傳輸層端到端延遲是微秒級的，每台服務器每秒可以處理數千次數據吞吐變更事件，同時還支持無限回溯能力和豐富的變更訂閱功能。概要結構如下圖。

圖中顯示：Search Index和Read Replicas等系統是Databus的消費者。當主OLTP數據庫發生寫操作時，連接其上的中繼系統會將數據拉到中繼中。簽入在Search Index或是緩存中的Databus消費者客戶端，就會從中繼中拉出數據，並更新索引或緩存。

Databus提供如下功能：

• 來源獨立：Databus支持多種數據來源的變更抓取，包括Oracle和MySQL。Oracle適配器在開源版本中有提供，MySQL適配器將在以後提供。
• 可擴展、高度可用：Databus能擴展到支持數千消費者和事務數據來源，同時保持高度可用性。
• 事務按序提交：Databus能保持來源數據庫中的事務完整性，並按照事務分組和來源的提交順尋交付變更事件。
• 低延遲、支持多種訂閱機制：數據源變更完成後，Databus能在微秒級內將事務提交給消費者。同時，消費者使用Databus中的服務器端過濾功能，可以只獲取自己需要的特定數據。
• 無限回溯：這是Databus最具創新性的組件之一，對消費者支持無限回溯能力。當消費者需要產生數據的完整拷貝時（比如新的搜索索引），它不會對主OLTP數據庫產生任何額外負擔，就可以達成目的。當消費者的數據大大落後於來源數據庫時，也可以使用該功能。

上圖中介紹了Databus系統的構成，包括中繼Relay、bootstrap服務和客戶端庫。Bootstrap服務中包括Bootstrap Producer和Bootstrap Server。快速變化的消費者直接從Relay中取事件。如果一個消費者的數據更新大幅落後，它要的數據就不在Relay的日志中，而是在 Bootstrap Producer裡面，提交給它的，將會是自消費者上次處理變更之後的所有數據變更快照。

Databus Relay中繼的功能主要包括：

1. 從Databus來源讀取變更行，並在內存緩存內將其序列化為Databus變更事件
2. 監聽來自Databus客戶端（包括Bootstrap Producer）的請求，並傳輸新的Databus數據變更事件

Databus客戶端的功能主要包括：

1. 檢查Relay上新的數據變更事件，並執行特定業務邏輯的回調
2. 如果落後Relay太多，向Bootstrap Server發起查詢
3. 新Databus客戶端會向Bootstrap Server發起bootstrap啟動查詢，然後切換到向中繼發起查詢，以完成最新的數據變更事件
4. 單一客戶端可以處理整個Databus數據流，或者可以成為消費者集群的一部分，其中每個消費者只處理一部分流數據

Databus Bootstrap Producer只是一種特定的Databus客戶端，它的功能有：

1. 檢查中繼上的新數據變更事件
2. 將變更存儲在MySQL數據庫中
3. MySQL數據庫供Bootstrap和客戶端使用

Databus Bootstrap Server的主要功能，就是監聽來自Databus客戶端的請求，並返回長期回溯數據變更事件。

在LinkedIn，Databus支持的系統有：

• 社會化圖譜索引（Social Graph Index），服務LinkedIn所有圖譜查詢
• 人員搜索索引（People Search Index），支持搜索所有LinkedIn用戶
• 用戶檔案數據（Member Profile）多個冗余的讀取查詢

對Databus項目感興趣的同學，可以去Github上查看更多信息和相關源碼。