美國知名科技博客GigaOM近日刊登了對LinkedIn幾大數(shù)據(jù)構架工程師的訪談文章，試圖探尋LinkedIn幕后數(shù)據(jù)挖掘技術的全景圖。LinkedIn是社交網(wǎng)絡數(shù)據(jù)挖掘領域的先行者，最簡潔的功能和設計，幕后往往都有一個強大的技術團隊才能支持運轉。任何一個UGC的社交網(wǎng)絡，都需要過硬的后臺數(shù)據(jù)構架體系，以及精準的匹配算法，才能展現(xiàn)給用戶良好的體驗。鈦媒體特綜合編譯如下：

　　【心語、趙賽坡/鈦媒編譯】LinkedIn最廣為人知的功能，莫過于People You May Know （你可能認識的人）。該功能方便用戶拓展人脈，找到想要認識的人。而這一切都依賴于強大的數(shù)據(jù)處理、管理技術，只有這樣才能讓LinkedIn可以讓數(shù)據(jù)在不同的應用程序之間順暢流通，并且保持準確。而實際上，當Jay Kreps（LinkedIn 首席工程師）五年前開始接手時，情況比現(xiàn)在棘手的多。

　　Kreps現(xiàn)在主要負責的事情，是為LinkedIn尋找合適的工程師，“我來的時候，那時還沒開始架構數(shù)據(jù)?！弊畛?，他是打算來LinkedIn做數(shù)據(jù)研究的，因為他認為這里的數(shù)據(jù)價值很高。后來才發(fā)現(xiàn)，他需要解決的是LinkedIn基本數(shù)據(jù)框架的構架問題。

　　問題有多嚴重？最初，People You May Know 是在一單獨Oracle數(shù)據(jù)庫實例里運行，主要通過幾個腳本和貪婪算法來提供智能分析。于是就造成了更新一次數(shù)據(jù)大約要花六周時間的問題，如果更新過程中宕機，就要花更多時間。當然，這是理想狀態(tài)下的情況，最嚴重的情況可能是系統(tǒng)六個月無法正常運轉。

　　如果數(shù)據(jù)量超過服務器的負荷，服務器就無法應答，只能通過減少貪婪算法，來減輕計算壓力。

　　所以，他的主要工作是在LinkedIn實現(xiàn)Hadoop基礎構架，并建立一個叫Voldemort的分布式數(shù)據(jù)庫，而不是為“你可能認識的人”寫算法。

　　從那以后，他建立了一個叫做Azkaban的開源調度器來批量處理分布式計算，還建立了Kafka（相當于大數(shù)據(jù)消息代理的開源工具）。從更高的層面來說，Kafka是用來管理公司實時數(shù)據(jù)的，以便以最快的方式讓成百上千的app訂閱用戶獲得最新的數(shù)據(jù)。

　　有人要Espresso嗎？

　　這些工作只是Kreps成為LinkedIn的董事后數(shù)據(jù)構架工作的一小部分。該工作的目的是在LinkedIn創(chuàng)建一個和其他互聯(lián)網(wǎng)公司一樣的創(chuàng)新型數(shù)據(jù)環(huán)境，這樣公司里的應用程序開發(fā)員和科學家有更多的時間和精力放在創(chuàng)造他們夢想中的產品上。

　　LinkedIn的高級數(shù)據(jù)主管Bhaskar Ghosh在參加數(shù)據(jù)構架專家論壇時表示，他們用的是一種三級的數(shù)據(jù)構架，包括在線、離線、近線系統(tǒng)，他們是為不同性質的工作設計的。在線系統(tǒng)處理用戶的即時交互；離線系統(tǒng)由 Hadoop 和Teradata數(shù)據(jù)庫構成，主要負責批量處理和分析工作；近線系統(tǒng)處理People You May Know、搜索、以及LinkedIn的社交圖譜，這些功能經常更新，但對延遲的要求沒有在線系統(tǒng)高。

　　公司最重要的成就之一就是一個名為“Espresso”的新數(shù)據(jù)庫系統(tǒng)。他和Voldmort不同，Voldemort繼亞馬遜的Dynamo之后的一款最終一致性的“鍵——值”儲存模型的數(shù)據(jù)庫，用來高速提供特定的數(shù)據(jù)。而Espresso是一款事務一致性的文件儲存系統(tǒng)，用來替代公整個公司里網(wǎng)絡運作時使用的Oracle數(shù)據(jù)庫。Espresso最初是專門設計用來為InMail功能提供信息服務的，源代碼會在今年晚些時候開放。

　　工程總監(jiān)Bob Schulman表示，“我們的郵箱功能中，有個關于郵箱規(guī)模和信息處理靈活性的問題。”Expresso要存儲大量的用戶數(shù)據(jù)，還要和用戶的操作保持同步。此外，郵箱還需要搜索功能，以便用戶（尤其是往來信息很多的用戶），可以迅速找到需要的郵件。

　　在原來的數(shù)據(jù)層保持不變的情況下，這個方案讓開發(fā)者解決了擴展性和穩(wěn)定性問題。

　　然而，主要的軟件架構師Das指出，僅僅嘗試用代碼來解決問題并不是長遠之計。因為這會很快的消耗團隊和用戶的精力，此外你不知道下次挑戰(zhàn)將會在什么時候出現(xiàn)。

　　Schulman認為，在靈活易變的環(huán)境下，最重要的是如何能在不破壞已有的情況下做出調整。當然，另外一條途徑就是打到一切重新來，不過“想讓一切停下運轉，你根本無法找到合適的時間?！?/P>

　　下一步戰(zhàn)略：改進Hadoop系統(tǒng)

　　迄今為止，LinkedIn的最大成功表現(xiàn)在優(yōu)化近線和在線系統(tǒng)（Ghosh說：我們已經做的很棒了），下一個改進目標就是離線系統(tǒng)——特別是Hadoop。目前他們已經使用Hadoop來運行公司的整個常規(guī)業(yè)務，比如ETL（提取、轉換、加載數(shù)據(jù)）、構建模型、數(shù)據(jù)分析以及近線系統(tǒng)的程序數(shù)據(jù)的預處理。而Ghosh希望有更大的改進。

　　他提出了一項方案，方案的重點在于對Hadoop集群和關系型數(shù)據(jù)庫進行高度整合。他們希望實現(xiàn)的目標有：更好的ETL框架、隨機查詢、可選擇的存儲模式以及被Ghosh稱之為“圣杯”的整合式元數(shù)據(jù)框架——該框架可以極大的方便不同分析系統(tǒng)互相共享數(shù)據(jù)。他表示，有些事Linkedin已經完成了一半，在年底之前將完成全部工作。

　　Ghosh說：“Hadoop上的SQL還需要兩年才能投入應用，我們還能怎樣呢？我們不能拋棄它?！?/P>

　　Das表示，實際上，LinkedIn數(shù)據(jù)工程的重心是構建一系列可以方便協(xié)作的服務。像Espresso API，就使得開發(fā)者可以連接到多欄存儲引擎，然后從事務數(shù)據(jù)庫里做一些有限的在線分析。

　　良好的基礎設施讓數(shù)據(jù)科學家快樂工作

　　Yael Garten是一位LinkedIn的高級數(shù)據(jù)科學家，她坦言公司越來越好的底層架構讓她的工作變得更容易。和Kreps一樣，她被吸引到LinkedIn（她上一份工作是在斯坦福大學的生物信息研究所）的原因也是這里擁有大量有趣的數(shù)據(jù)分析工作，只是她有幸錯過了當年由于底層架構不完善導致連1000萬用戶信息都無法處理的困難日子，如今LinkedIn要面對2億用戶的信息處理任務。Garten表示她還沒有遇到因為公司基礎架構不完善而無法解決的數(shù)據(jù)問題。

　　數(shù)據(jù)分析團隊和產品團隊并肩作戰(zhàn)，有時產品經理主導產品走向，而有時則是圍繞數(shù)據(jù)科學家的結論進行開發(fā)。Garten表示在2013年，開發(fā)者希望基礎架構能讓他們實時開發(fā)產品原型并進行測試。而且那些業(yè)務經理們也需要盡可能實時的看到產品分析報告，以便于他們可以了解產品運行情況。

　　Garten認為：“基礎架構并不僅僅是要將所有的工作加速，有時一些想法是無法實現(xiàn)的?！八龥]有介紹基礎架構中某個神奇部分的細節(jié)，我猜想這可能涉及到公司機密的分布式圖譜系統(tǒng)。Ghosh在公司其他方面毫不諱言，但在這個問題上卻拒絕透露更多。

　　“倉鼠滾輪”式的良性循環(huán)

　　無論是Ghosh還是Kreps認為LinkedIn以及其他領先的互聯(lián)網(wǎng)公司，任何時候都不會放棄創(chuàng)新。一方面是由于業(yè)務決策需要，Ghosh覺得這源于公司文化和招聘的積極影響。Kreps則指出公司決策層在計算運營成本時所面臨的苦難，主要反映在到底是購買軟件證書、雇傭開源項目權限擁有者還是進行內部建設的權衡比較方面。

　　Kreps將公司構建新系統(tǒng)的循環(huán)比作“一種倉鼠滾輪”，但公司也提供了足夠多的基于特殊需求而開發(fā)新產品的機會。比如最初他設想為用Hadoop解決兩種用例，但現(xiàn)在公司大約有300種用例由Hadoop處理。它也從之前的兩次實時反饋發(fā)展到了現(xiàn)在的650次。

　　他說：“公司現(xiàn)在所做的這些的目的就是一個，解決問題?！?/P>

　　Ghosh否認了公司過度依賴商業(yè)授權技術或開源項目的說法，他說：“我們認真思考過我們應該在哪里做些復雜的工作。”但他馬上補充說：“你并不想讓你的系統(tǒng)變成一個系統(tǒng)整合商場”。

　　他表示，今年會有更多基于LinkedIn的開發(fā)工程和開源項目?！拔乙呀浽谙虢酉聛淼膬蓚€或三個重頭戲了”。