|
|
來自LinkedIn的Jay Kreps在近日舉辦的Hadoop峰會上詳細(xì)介紹了LinkedIn對數(shù)據(jù)的處理方式。Kreps介紹了LinkedIn每天是如何處理1.2千億個關(guān)系并通過高容量、低延遲的站點(diǎn)服務(wù)來混合大量的數(shù)據(jù)計算的。
LinkedIn的很多重要數(shù)據(jù)都是離線的，移動起來相當(dāng)慢。因此，他們將每天對Hadoop的批處理作為計算的重要組成部分。比如說，他們采用這種方式對其“People You May Know”產(chǎn)品數(shù)據(jù)進(jìn)行預(yù)計算，這么做每天會在mapreduce管道（擁有82個Hadoop job）中產(chǎn)生1.2千億個關(guān)系，需要16TB的臨時數(shù)據(jù)。這個job使用了一個統(tǒng)計模型來預(yù)測兩個人認(rèn)識的概率。有趣的是，他們使用布隆過濾器（bloom filters）來加速巨大的連接關(guān)系，這提升了10倍的性能。
LinkedIn有兩個工程師從事這個管道開發(fā)，他們每周可以測試5個新算法。為了實現(xiàn)這種變化率，他們使用A/B測試來比較新舊方法，使用“fly by instruments”方法來優(yōu)化結(jié)果。為了提升性能，他們還需要操縱大范圍數(shù)據(jù)：使用大范圍集群處理。為了實現(xiàn)這個目標(biāo)，他們從客戶化的圖處理代碼遷移到了Hadoop mapreduce代碼上：這需要一些周全的設(shè)計，因為很多圖算法無法直接轉(zhuǎn)換為mapreduce。
LinkedIn對開源項目投入巨大，希望構(gòu)建出一流的組件并號召社區(qū)參與進(jìn)來。其中兩個開源項目構(gòu)成了其數(shù)據(jù)基礎(chǔ)設(shè)施的中心。Azkaban是個面向Hadoop的開源工作流系統(tǒng)，提供了類似于cron的調(diào)度，類似于make的依賴分析，還包含了重啟。它用于控制ETL job，該job可以將數(shù)據(jù)庫與事件日志推送到邊緣服務(wù)器存儲（Voldemort）中。
Voldemort是LinkedIn的NoSQL 鍵/值存儲引擎。它每天都會向其站點(diǎn)推送出幾十億的邊緣概率關(guān)系圖，用于渲染網(wǎng)頁時查詢所用。這種數(shù)據(jù)是只讀的：它是通過這些集群job計算出來的，但之后會實時通過搜索進(jìn)行過濾，這么做會限定到用戶感興趣的某些公司，或是排除掉用戶已經(jīng)表明不認(rèn)識的那些人。這個方法來源于使用數(shù)據(jù)庫解決這個問題時所遇到的障礙，后者需要分片并遷移至完全依靠手工移動數(shù)據(jù)的系統(tǒng)。Voldemort完全是分布式且去中心化的，支持分區(qū)與容錯。
LinkedIn通過同時獲取Hadoop與Voldemort大范圍的結(jié)果來更新服務(wù)器，預(yù)熱緩存，然后分別在每個服務(wù)器上針對新一天的數(shù)據(jù)建立原子轉(zhuǎn)換。他們會將前一天的數(shù)據(jù)保持在服務(wù)器上，這樣一旦新一天的數(shù)據(jù)集出現(xiàn)了問題就可以立刻恢復(fù)過來。LinkedIn在其Hadoop管道上構(gòu)建了一個索引結(jié)構(gòu)：這會產(chǎn)生幾個TB的查找結(jié)構(gòu)，該結(jié)構(gòu)完美地使用了散列（每個鍵只需要2.5個位）。這種處理權(quán)衡了集群計算資源以實現(xiàn)更快的服務(wù)器響應(yīng)；LinkedIn大約需要90分鐘時間在45個結(jié)點(diǎn)集群上構(gòu)建900GB的數(shù)據(jù)。他們使用Hadoop來處理大塊的批數(shù)據(jù)，這樣其Hadoop集群就需要周期性地進(jìn)行升級，但Voldemort則永遠(yuǎn)不需要。
感興趣的讀者可以查看演講的幻燈片以進(jìn)一步了解詳情。
it知識庫：LinkedIn數(shù)據(jù)基礎(chǔ)設(shè)施簡介，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
