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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#p#

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)

• 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