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