探秘LinkedIn工程師團(tuán)隊(duì)：技術(shù)黨支撐的SNS未來(lái)

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

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

　　Kreps現(xiàn)在主要負(fù)責(zé)的事情，是為L(zhǎng)inkedIn尋找合適的工程師，“我來(lái)的時(shí)候，那時(shí)還沒(méi)開(kāi)始架構(gòu)數(shù)據(jù)?！弊畛?，他是打算來(lái)LinkedIn做數(shù)據(jù)研究的，因?yàn)樗J(rèn)為這里的數(shù)據(jù)價(jià)值很高。后來(lái)才發(fā)現(xiàn)，他需要解決的是LinkedIn基本數(shù)據(jù)框架的構(gòu)架問(wèn)題。

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

　　如果數(shù)據(jù)量超過(guò)服務(wù)器的負(fù)荷，服務(wù)器就無(wú)法應(yīng)答，只能通過(guò)減少貪婪算法，來(lái)減輕計(jì)算壓力。

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

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

　　有人要Espresso嗎？

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

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

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

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

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

　　然而，主要的軟件架構(gòu)師Das指出，僅僅嘗試用代碼來(lái)解決問(wèn)題并不是長(zhǎng)遠(yuǎn)之計(jì)。因?yàn)檫@會(huì)很快的消耗團(tuán)隊(duì)和用戶的精力，此外你不知道下次挑戰(zhàn)將會(huì)在什么時(shí)候出現(xiàn)。

　　Schulman認(rèn)為，在靈活易變的環(huán)境下，最重要的是如何能在不破壞已有的情況下做出調(diào)整。當(dāng)然，另外一條途徑就是打到一切重新來(lái)，不過(guò)“想讓一切停下運(yùn)轉(zhuǎn)，你根本無(wú)法找到合適的時(shí)間?！?/P>

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

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

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

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

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

　　良好的基礎(chǔ)設(shè)施讓數(shù)據(jù)科學(xué)家快樂(lè)工作

　　Yael Garten是一位LinkedIn的高級(jí)數(shù)據(jù)科學(xué)家，她坦言公司越來(lái)越好的底層架構(gòu)讓她的工作變得更容易。和Kreps一樣，她被吸引到LinkedIn（她上一份工作是在斯坦福大學(xué)的生物信息研究所）的原因也是這里擁有大量有趣的數(shù)據(jù)分析工作，只是她有幸錯(cuò)過(guò)了當(dāng)年由于底層架構(gòu)不完善導(dǎo)致連1000萬(wàn)用戶信息都無(wú)法處理的困難日子，如今LinkedIn要面對(duì)2億用戶的信息處理任務(wù)。Garten表示她還沒(méi)有遇到因?yàn)楣净A(chǔ)架構(gòu)不完善而無(wú)法解決的數(shù)據(jù)問(wèn)題。

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

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

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

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

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

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

　　Ghosh否認(rèn)了公司過(guò)度依賴商業(yè)授權(quán)技術(shù)或開(kāi)源項(xiàng)目的說(shuō)法，他說(shuō)：“我們認(rèn)真思考過(guò)我們應(yīng)該在哪里做些復(fù)雜的工作。”但他馬上補(bǔ)充說(shuō)：“你并不想讓你的系統(tǒng)變成一個(gè)系統(tǒng)整合商場(chǎng)”。

　　他表示，今年會(huì)有更多基于LinkedIn的開(kāi)發(fā)工程和開(kāi)源項(xiàng)目?！拔乙呀?jīng)在想接下來(lái)的兩個(gè)或三個(gè)重頭戲了”。