早期的LinkedIn數(shù)據(jù)架構(gòu)

像其它初創(chuàng)公司一樣，LinkedIn 早期也是通過單個的RDBMS （關(guān)系型數(shù)據(jù)庫管理系統(tǒng)）的幾張表來保存用戶資料和人脈關(guān)系。是不是很原始？后來這個RDMBS擴展出兩個額外的數(shù)據(jù)庫系統(tǒng)，其中一個用來支撐用戶個人資料的全文搜索，另一個用來實現(xiàn)社交圖。這兩個數(shù)據(jù)庫通過Databus來取得***數(shù)據(jù)。Databus是一個變化捕捉系統(tǒng)，它的主要目標就是捕捉那些來至可信源（像Oracle）中數(shù)據(jù)集的變更，并且把這些變化更新到附加數(shù)據(jù)庫系統(tǒng)中。

但是，沒過多久這種架構(gòu)就已經(jīng)很難滿足網(wǎng)站的數(shù)據(jù)需求了。因為按照Brewerd的CAP理論想要同時滿足下面的條件看似不太可能：

一致性：所有應(yīng)用在同一時刻看到相同的數(shù)據(jù)

可用性：保證每個請求都能收到應(yīng)答，無論成功或失敗

分區(qū)容錯性：部分系統(tǒng)的消息丟失或失敗不影響系統(tǒng)系統(tǒng)整體的正常運行

根據(jù)上面的法則，LinkedIn工程師團隊實現(xiàn)了他們稱作為時間線一致性（或者說近線系統(tǒng)的最終一致性，下面會解釋）以及另外兩個特性：可用性和分區(qū)容錯性。下面介紹目前LinkedIn的數(shù)據(jù)架構(gòu)。

LinkedIn如今的數(shù)據(jù)架構(gòu)

如果要支撐在不到一秒鐘內(nèi)處理數(shù)百萬用戶的相關(guān)事務(wù)，上面的數(shù)據(jù)架構(gòu)已經(jīng)明顯不足了。因此，LinkedIn 工程師團隊提出了三段式（three-phase）數(shù)據(jù)架構(gòu)，由在線、離線以及近線數(shù)據(jù)系統(tǒng)組成。總體上講，LinkedIn數(shù)據(jù)被存儲在如下幾種不同形式的數(shù)據(jù)系統(tǒng)中（看下面的圖）：

• RDBMS
  • Oracle
  • MySQL（作為Espresso的底層數(shù)據(jù)存儲）
• RDBMS
  • Espresso（LinkedIn自己開發(fā)的文檔型NoSQL數(shù)據(jù)存儲系統(tǒng)）
  • Voldemart （分布式Key-value存儲系統(tǒng)）
  • HDFS （存放Hadoop map-reduce任務(wù)的數(shù)據(jù)）
• Caching
  • Memcached
• 基于Lucene的索引
  • 存放查詢、關(guān)系圖等功能數(shù)據(jù)的Lucene 索引
  • Espresso使用的索引

上面提到的數(shù)據(jù)存儲庫被歸為三種不同類型的系統(tǒng)，下面會逐一解釋：

在線數(shù)據(jù)庫系統(tǒng)

在線系統(tǒng)處理用戶的實時互動；主數(shù)據(jù)庫像Oracle就屬于這一類別。主數(shù)據(jù)存儲用來支撐用戶的寫操作和少量的讀操作。以O(shè)rcale為例，Oracle master會執(zhí)行所有的寫操作。最近，LinkedIn正在開發(fā)另一個叫做“Espresso”的數(shù)據(jù)系統(tǒng)來滿足日益復(fù)雜的數(shù)據(jù)需求，而這些數(shù)據(jù)看似不應(yīng)從像Oracle這類的RDBMS中獲取。他們能否淘汰所有或大部分的Oracle并將數(shù)據(jù)完全轉(zhuǎn)移到像Espresso這類的NoSQL數(shù)據(jù)存儲系統(tǒng)中去？讓我們拭目以待。

離線數(shù)據(jù)庫系統(tǒng)

離線系統(tǒng)主要包括Hadoop和一個Teradata數(shù)據(jù)倉庫，用來執(zhí)行批處理和分析類的工作。之所以被稱為離線是因為它對數(shù)據(jù)執(zhí)行的的批處理操作。 Apache Azkaban被用來管理Hadoop和ETL任務(wù)，這些任務(wù)從主可信源系統(tǒng)獲取數(shù)據(jù)后交由map-reduce處理，處理結(jié)果被保存在HDFS，然后通知’消費者‘（例如：Voldemart）通過合適的方式來獲取這些數(shù)據(jù)并切換索引來保證能獲取到***的數(shù)據(jù)。

#p#

近線數(shù)據(jù)庫系統(tǒng)（時間線一致性）

近線系統(tǒng)的目標是為了實現(xiàn)時間線一致性（或最終一致性），它處理類似’你可能認識的人（只讀數(shù)據(jù)集）‘、搜索以及社交圖這些功能，這些功能的數(shù)據(jù)會持續(xù)更新，但它們對延遲性的要求并不像在線系統(tǒng)那樣高。下面是幾種不同類型的近線系統(tǒng)：

• Voldemart，一個Key-Value存儲系統(tǒng)，為系統(tǒng)中的只讀頁面提供服務(wù)。Voldemart的數(shù)據(jù)來源于Hadoop框架（Hadoop Azkaban：編排Hadoop map-reduce任務(wù)的執(zhí)行計劃）。這就是近線系統(tǒng)，它們從類似Hadoop的離線系統(tǒng)獲取數(shù)據(jù)。下面這些頁面的數(shù)據(jù)都是來自于Voldemart：
  • 你可能認識的人
  • 看過本頁面的人還在看
  • 相關(guān)搜索
  • 你可能感興趣的工作
  • 你可能感興趣的事件
• 下面是幾種不同的索引，這些索引由Databus-一個變化數(shù)據(jù)捕捉系統(tǒng)-來更新的：
  • 供SeaS（Search-as-a-Service）使用的’成員搜索索引‘。當你在LinkedIn上搜索不同的成員時，這些數(shù)據(jù)就是來自于搜索索引。通常這個功能對招聘人員的幫助很大。
  • 社交圖索引幫助在人們的人脈關(guān)系中顯示成員以及關(guān)系。通過這個索引用戶幾乎可以實時的得到網(wǎng)絡(luò)關(guān)系的變化。
  • 通過讀復(fù)制集獲取到的成員資料數(shù)據(jù)。這些數(shù)據(jù)會被’標準化服務(wù)‘訪問。讀復(fù)制集是對源數(shù)據(jù)庫的復(fù)制，這樣能使源數(shù)據(jù)庫的更新同步到這些復(fù)制集上面。增加讀復(fù)制集的最主要原因是能夠通過將讀操查詢分散到讀復(fù)制集上來減輕源數(shù)據(jù)庫（執(zhí)行用戶發(fā)起的寫操作）的壓力。

下圖展示了數(shù)據(jù)變化捕獲事件是如何利用Databus更新到近線系統(tǒng)的：

用數(shù)據(jù)用例來展示它們是如何工作的

假如你更新了你個人資料中的***技能和職位。你還接受了一個連接請求。那么在系統(tǒng)內(nèi)部到底發(fā)生了什么：

數(shù)據(jù)架構(gòu)經(jīng)驗

如果要設(shè)計一個像LinkedIn.com一樣的支持數(shù)據(jù)一致性、高擴展性且高可用性的數(shù)據(jù)架構(gòu)，可以借鑒下面的經(jīng)驗：

• 數(shù)據(jù)庫讀寫分離：你應(yīng)當計劃兩種數(shù)據(jù)庫，一種用來執(zhí)行寫操作的可以稱為“可信源”系統(tǒng)，另一種執(zhí)行讀操作的可以稱為派生數(shù)據(jù)庫系統(tǒng)。這里的經(jīng)驗法則就是將由用戶發(fā)起的寫操作和用戶讀操作使用的數(shù)據(jù)庫區(qū)分開來。
• 派生數(shù)據(jù)庫系統(tǒng)：用戶的讀操作應(yīng)該被分配到派生數(shù)據(jù)庫或者讀復(fù)制集上去。而派生數(shù)據(jù)庫系統(tǒng)則可以建立在下面的系統(tǒng)之上：
  • Lucene 索引
  • NoSQL數(shù)據(jù)存儲，例如：Voldemart、Redis、Cassandra、MongoDB等。
• 對于用戶的讀操作，應(yīng)該盡量從主可信源數(shù)據(jù)庫系統(tǒng)創(chuàng)建索引或者基于key-value的數(shù)據(jù)（來源于Hadoop map-reduce之類的系統(tǒng)），并且將每次由用戶發(fā)起的被寫入主可信源系統(tǒng)的變更一并更新到這些索引或派生數(shù)據(jù)（key-value）。
• 為確保派生數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)是***的，你可以選擇應(yīng)用復(fù)寫（application-dual writes），即在應(yīng)用層同時寫入主數(shù)據(jù)庫和派生數(shù)據(jù)庫系統(tǒng)，或日志挖掘（讀取通過批處理任務(wù)得到的主數(shù)據(jù)存儲系統(tǒng)的事務(wù)提交日志）。
• 創(chuàng)建派生數(shù)據(jù)時，你可以針對主數(shù)據(jù)集或者變更數(shù)據(jù)集執(zhí)行基于Hadoop的map-reduce任務(wù)，然后更新HDFS并且通知派生數(shù)據(jù)存儲系統(tǒng)（類似Voldemart的NoSQL存儲）來取走數(shù)據(jù)。
• 對于數(shù)據(jù)一致性來說，你可以以將這些數(shù)據(jù)存儲庫創(chuàng)建為分布式系統(tǒng)，集群中的每個節(jié)點又都包含主從節(jié)點。所有節(jié)點都可以創(chuàng)建水平擴展的數(shù)據(jù)Shards。
• 為了保證這些分布式數(shù)據(jù)存儲系統(tǒng)正常運行時間***化，你可以使用像Apache Helix這一類的集群管理工具。

參考文獻

• Siddarth Anand LinkedIn Data Infrastructure paper
• https://github.com/linkedin/databus
• http://gigaom.com/2013/03/03/how-and-why-linkedin-is-becoming-an-engineering-powerhouse/
• http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html