LinkedIn的後台需要精准算法和強大的數據支撐，而這些數據正是令許多優秀工程師著迷的地方；好的數據底層架構讓工程師的工作變更有效率，正是富於創新的“技術黨”造就了這家領袖級的職業社交網絡。
钛媒體注：美國知名科技博客GigaOM近日刊登了對LinkedIn幾大數據構架工程師的訪談文章，試圖探尋LinkedIn幕後數據挖掘技術的全景圖。LinkedIn是社交網絡數據挖掘領域的先行者，最簡潔的功能和設計，幕後往往都有一個強大的技術團隊才能支持運轉。任何一個UGC的社交網絡，都需要過硬的後台數據構架體系，以及精准的匹配算法，才能展現給用戶良好的體驗。钛媒體特綜合編譯如下：
LinkedIn最廣為人知的功能，莫過於People You May Know （你可能認識的人）。該功能方便用戶拓展人脈，找到想要認識的人。而這一切都依賴於強大的數據處理、管理技術，只有這樣才能讓LinkedIn可以讓數據在不同的應用程序之間順暢流通，並且保持准確。而實際上，當Jay Kreps（LinkedIn 首席工程師）五年前開始接手時，情況比現在棘手的多。
Kreps現在主要負責的事情，是為LinkedIn尋找合適的工程師，“我來的時候，那時還沒開始架構數據。”最初，他是打算來LinkedIn做數據研究的，因為他認為這裡的數據價值很高。後來才發現，他需要解決的是LinkedIn基本數據框架的構架問題。
問題有多嚴重？最初，People You May Know 是在一單獨Oracle
數據庫實例裡運行，主要通過幾個腳本和貪婪算法來提供智能分析。於是就造成了更新一次數據大約要花六周時間的問題，如果更新過程中宕機，就要花更多時間。當然，這是理想狀態下的情況，最嚴重的情況可能是系統六個月無法正常運轉。
如果數據量超過服務器的負荷，服務器就無法應答，只能通過減少貪婪算法，來減輕計算壓力。
所以，他的主要工作是在LinkedIn實現Hadoop基礎構架，並建立一個叫Voldemort的分布式數據庫，而不是為“你可能認識的人”寫算法。
從那以後，他建立了一個叫做Azkaban的開源調度器來批量處理分布式計算，還建立了Kafka（相當於大數據消息代理的開源工具）。從更高的層面來說，Kafka是用來管理公司實時數據的，以便以最快的方式讓成百上千的app訂閱用戶獲得最新的數據。
有人要Espresso嗎？
這些工作只是Kreps成為LinkedIn的董事後數據構架工作的一小部分。該工作的目的是在LinkedIn創建一個和其他互聯網公司一樣的創新型數據環境，這樣公司裡的應用程序開發員和科學家有更多的時間和精力放在創造他們夢想中的產品上。
LinkedIn的高級數據主管Bhaskar Ghosh在參加數據構架專家論壇時表示，他們用的是一種三級的數據構架，包括在線、離線、近線系統，他們是為不同性質的工作設計的。在線系統處理用戶的即時交互；離線系統由 Hadoop 和Teradata數據庫構成，主要負責批量處理和分析工作；近線系統處理People You May Know、搜索、以及LinkedIn的社交圖譜，這些功能經常更新，但對延遲的要求沒有在線系統高。
公司最重要的成就之一就是一個名為“Espresso”的新數據庫系統。他和Voldmort不同，Voldemort繼亞馬遜的Dynamo之後的一款最終一致性的“鍵——值”儲存模型的數據庫，用來高速提供特定的數據。而Espresso是一款事務一致性的文件儲存系統，用來替代公整個公司裡網絡運作時使用的Oracle數據庫。Espresso最初是專門設計用來為InMail功能提供信息服務的，源代碼會在今年晚些時候開放。
工程總監Bob Schulman表示，“我們的郵箱功能中，有個關於郵箱規模和信息處理靈活性的問題。”Expresso要存儲大量的用戶數據，還要和用戶的操作保持同步。此外，郵箱還需要搜索功能，以便用戶（尤其是往來信息很多的用戶），可以迅速找到需要的郵件。
在原來的數據層保持不變的情況下，這個方案讓開發者解決了擴展性和穩定性問題。
然而，主要的軟件架構師Das指出，僅僅嘗試用代碼來解決問題並不是長遠之計。因為這會很快的消耗團隊和用戶的精力，此外你不知道下次挑戰將會在什麼時候出現。
Schulman認為，在靈活易變的環境下，最重要的是如何能在不破壞已有的情況下做出調整。當然，另外一條途徑就是打到一切重新來，不過“想讓一切停下運轉，你根本無法找到合適的時間。”
下一步戰略：改進Hadoop系統
迄今為止，LinkedIn的最大成功表現在優化近線和在線系統（Ghosh說：我們已經做的很棒了），下一個改進目標就是離線系統——特別是Hadoop。目前他們已經使用Hadoop來運行公司的整個常規業務，比如ETL（提取、轉換、加載數據）、構建模型、數據分析以及近線系統的程序數據的預處理。而Ghosh希望有更大的改進。
他提出了一項方案，方案的重點在於對Hadoop集群和關系型數據庫進行高度整合。他們希望實現的目標有：更好的ETL框架、隨機查詢、可選擇的存儲模式以及被Ghosh稱之為“聖杯”的整合式元數據框架——該框架可以極大的方便不同分析系統互相共享數據。他表示，有些事Linkedin已經完成了一半，在年底之前將完成全部工作。
Ghosh說：“Hadoop上的SQL還需要兩年才能投入應用，我們還能怎樣呢？我們不能拋棄它。”
Das表示，實際上，LinkedIn數據工程的重心是構建一系列可以方便協作的服務。像Espresso API，就使得開發者可以連接到多欄存儲引擎，然後從事務數據庫裡做一些有限的在線分析。
良好的基礎設施讓數據科學家快樂工作
Yael Garten是一位LinkedIn的高級數據科學家，她坦言公司越來越好的底層架構讓她的工作變得更容易。和Kreps一樣，她被吸引到LinkedIn（她上一份工作是在斯坦福大學的生物信息研究所）的原因也是這裡擁有大量有趣的數據分析工作，只是她有幸錯過了當年由於底層架構不完善導致連1000萬用戶信息都無法處理的困難日子，如今LinkedIn要面對2億用戶的信息處理任務。Garten表示她還沒有遇到因為公司基礎架構不完善而無法解決的數據問題。
數據分析團隊和產品團隊並肩作戰，有時產品經理主導產品走向，而有時則是圍繞數據科學家的結論進行開發。Garten表示在2013年，開發者希望基礎架構能讓他們實時開發產品原型並進行測試。而且那些業務經理們也需要盡可能實時的看到產品分析報告，以便於他們可以了解產品運行情況。
Garten認為：“基礎架構並不僅僅是要將所有的工作加速，有時一些想法是無法實現的。“她沒有介紹基礎架構中某個神奇部分的細節，我猜想這可能涉及到公司機密的分布式圖譜系統。Ghosh在公司其他方面毫不諱言，但在這個問題上卻拒絕透露更多。
“倉鼠滾輪”式的良性循環
無論是Ghosh還是Kreps認為LinkedIn以及其他領先的互聯網公司，任何時候都不會放棄創新。一方面是由於業務決策需要，Ghosh覺得這源於公司文化和招聘的積極影響。Kreps則指出公司決策層在計算運營成本時所面臨的苦難，主要反映在到底是購買軟件證書、雇傭開源項目權限擁有者還是進行內部建設的權衡比較方面。
Kreps將公司構建新系統的循環比作“一種倉鼠滾輪”，但公司也提供了足夠多的基於特殊需求而開發新產品的機會。比如最初他設想為用Hadoop解決兩種用例，但現在公司大約有300種用例由Hadoop處理。它也從之前的兩次實時反饋發展到了現在的650次。
他說：“公司現在所做的這些的目的就是一個，解決問題。”
Ghosh否認了公司過度依賴商業授權技術或開源項目的說法，他說：“我們認真思考過我們應該在哪裡做些復雜的工作。”但他馬上補充說：“你並不想讓你的系統變成一個系統整合商場”。
他表示，今年會有更多基於LinkedIn的開發工程和開源項目。“我已經在想接下來的兩個或三個重頭戲了”。
