圖：Facebook的Jay Parikh（攝：Ariel Zambelich/Wired）
這就是Parikh和他的團隊開發 Scuba這 類工具的原因。Scuba是新一代的軟件平台，它可以幫助Facebook的工程師時刻分析數據，並描述出公司大量基礎設施的使用狀態。很多時候，當你需 要獲得大量的繁雜的信息時，總存在延遲，你可能需要幾個小時來處理這些數據。但Scuba是內存數據庫，它將所有數據運行在數以百計的服務器的內存中，這 意味著你可以幾乎實時的查詢數據。
“Scuba能夠動態的顯示我們的基礎設施的狀態——服務器工作的怎麼樣，網絡工作怎麼樣，不同的軟件系統的協同如 何，”Parikh說，“所以，當我的助理（通過Facebook）在我的圖片打標簽後，這一操作需要幾秒鐘才能看到，但是我們卻可以通過Scuba提前 發現。”
自9年前Mark Zuckerberg創立Facebook開始，也逐漸產生了在這個星球上最復雜的運維工程。Facebook要面對獨一無二的困難——如何給十億用戶提供個性化的頁面，要處理十億組不同的消息、圖片、視頻和其它數據，這需要大量的科技天才。
是的，Facebook的目標是籠絡包括Lars Rasmussen這樣創立 社交圖譜搜索的工程師，也包括其它開發各種用於測試、部署應用的流行的工具和小組件的工程師。當今，還包括像 Amir Michael這樣設計了Facebook自定義的服務器、存儲設備以及整個數據中心的硬件工程師。
來自各個部門的工程師組成了管理數據的團隊，以應對快速增長的現代化在線運維模式。Scuba只是 Facebook眾多大數據軟件平台中的一個，大數據軟件平台把Facebook打造成通過在線運維提供指導信息的平台。在線運維平台通過一個進程就能藝 術的管理者數百甚至數以千計的計算機。
這些工具是Raghu Murthy、Avery Ching、Josh Metzler等工程師的成果，它們不僅幫助Facebook定位數據中心中的故障，而且還可以幫助數據科學家 分析在線應用的效率以及用戶行為，在一些情況下，它們甚至可以將數據直接提供給Facebook的用戶。
Google的大數據平台被視為最先進的代表，然而Facebook正在努力擴張自己的互聯網帝國，與Google差距並不大，Facebook意圖向世界各地的用戶分享更多軟件。Google在去年分享了最新的成果——Google Spanner，而Facebook也分享了代碼，並希望用戶們喜歡。“作為一家企業，我們的使命是讓世界更加開放、更多連接，”Parihk表示，“我們在建設基礎設施的同時，也完成了我們的使命。”
從一次事故開始建立數據團隊
Facebook的數據團隊由 Jeff Hammerbacher創立，他和Mark Zuckerberg曾同時在哈佛就學，攻讀數學，在2006年春季加入Facebook之前，他在紐約貝爾斯登商行做一名數據科學家。
Hammerbacher喜歡談起Facebook的數據運維的起源，這要回 到在貝爾斯登的一個下午，當時路透數據服務突然中斷，數據無法采集，致使所有交易被迫中止，系統癱瘓了整整一個小時，調查發現故障是由一個人瘋狂的運行了 某個程序引起的。Hammerbacher從這次教訓學到了：數據工具與數據專家同樣重要。
“我意識到，相對於在路透數據服務崩潰的兩小時期產生的損失，我創建 的數據模型和另一家公司數學家們建立的數據模型的付出就顯得微不足道，”Hammerbacher回憶道。“我感覺我們有機會創建一個完整的系統，最初先 獲取數據，然後再過渡到數據模式創建——並嘗試從每個點對系統進行優化。”
這也是他在Facebook時所做的。他入職的身份是數據分 析師——這一職位可通過信息分析對公司運營起到輔助作用——但是由於他難以抹去腦中路透數據服務崩潰的記憶，所以他走得更遠一點。他創建了一支可以控制公 司數據的團隊。這個團隊不僅可以分析數據，還可以創建可用於收集和處理這些數據的工具。
他剛加入Facebook的時候，公司仍很保守的使用甲骨文的數據倉庫。但是這類軟件的數據處理能力並不能跟上Facebook的步伐。Hammerbacher的加入，促進了公司使用Hadoop的進程， Hadoop業務在2011年從Yahoo分拆出來。
在利用機器的強大收集能力把數據轉化成有用信息之前，Hadoop通過海量商用服務器傳輸數據。它之所以如此具有吸引力，是因為商用服務器比較便宜，而且你只需增加服務器數量來滿足不斷增長的數據。
Yahoo使用Hadoop為其網 頁搜索引擎創建索引，但是Hammerbacher和Facebook則將其視為公司數據科學家的助手——把它作為分析大量信息的方式，而不是把數據塞進 甲骨文數據倉庫。公司借助Hive——該工具可以讓分析師在Hadoop之上快速處理大量數據，作用類似於80年代以來被廣泛使用的SQL——很快這一工 具就成為了雅虎分析在線廣告等性能的主要工具。
圖：Raghu Murty與Santosh Janardhan（攝：Ariel Zambelich/Wired）
Hammerbacher在2008年秋季離開Facebook，協助創建了Cloudera。Cloudera是一家致力於將Hadoop帶入商業超越網絡的初創公司。 這是大勢所趨。在他離開之前，Hammerbacher甚至自創 曲子為Facebook數據團隊打氣。
未來的Hadoop
現在，Hadoop的明星用戶在不斷增加，從Twitter、eBay到LinkedIn，再到Facebook，都在把自己的平台推向極致。據Jay Parikh透露，Facebook管理著世界上最大的Hadoop集群。其中一個集群就擁有4000台機器，存儲的數據量超過100PB。
一個這樣的集群已 如此龐大，已經不得不分散到四個數據中心，Facebook工程師Raghu Murthy說。在四個獨立的環境下，由於要處理激增的網頁數據，Facebook將數據中心的資源分配給Hadoop服務器，每一次都被迫尋找新設備。 “我們每次設計的容量上限都似乎永遠不會被超越，”Murthy（Jeff Hammerbacher約四年前從斯坦福博士項目中雇傭來，此後成為Facebook大數據業務的奠基人）稱，“但是很快又不得不把所有的數據搬去其他 地方。”
但是，自 從上次轉移數據後，公司就發誓不再轉移，並且計劃創建一個跨越多個數據中心的Hadoop集群。這個項目由Murthy領導，他在Yahoo創建 Hadoop分布式計算預備系統的時候引起了Hammerbacher的注意，而且已經參與過包括Hive在內的Facebook的多個重要項目。不過這 次情況不太一樣。Hadoop不是要跨設備運行。通常，由於它非常依賴於服務器之間的通信，所以集群被限制在一個單獨的數據中心。
采用的解決方案是 Prism， 這個平台由Murthy及其團隊在Facebook架構上推出。一個典型的Hadoop集群由一個單獨的“命名空間”（name space）控制，其中包含用於每項工作的運算資源列表，但是Prism開設了多個命名空間，創建了多個在相同物理集群之上運作的“邏輯集群”。
這些命名空間被多個Facebook團隊分組——每個團隊獲取一個自己的命名空間——但是所有團隊都需要訪問一個通用數據集，這個數據集可以跨多個數據中心。巧妙之處在於，團隊運行一項工作的時候，就可以對此項工作所需的特殊數據進行復制，再將其轉移到一個單獨的數據中心裡。“我們把容量計劃細分到單個團隊，”Murthy說。“他們更了解網頁的實際需求。
據 Murthy透露，該系統的服務器數量可以無限制的擴張——至少理論上如此。這意味著，公司不再需要擔心數據中心容量告急的問題。但對於Santosh Janardhan而言——他是數據團隊的操作者——則意味著他需要確保這個架構運行流暢。“將Hadoop集群放到一個數據中心裡面簡直嚇死我了，”他 說。“Prism幫了大忙。”
Prism只是改進和擴展Hadoop的一個方面。由另一名前Yahoo員工Avery Ching領導的第二支工程師團隊最近部署了一個名為 Corona的新平台，這個平台可以讓多項工作運行於一個單獨Hadoop集群之上，且不會造成崩潰。Murthy還在幫助推廣 Peregrine工具，這款工具可以讓你更快速地檢索Hadoop數據。Hadoop被設計成一個“批量系統”，意味著你要在工作運行時進行等待，與Hammerbacher打造的 Impala一樣，Peregrine使平台檢索更貼近實時情況。
圖：Facebook 的數據基礎設施核心團隊，Avery Ching、Ravi Murthy、Raghu Murthy、Jay Parikh、Sameet Agarwal、Santosh Janardhan、Josh Metzler、Subbu Submaranian。（攝：Ariel Zambelich/Wired）
Facebook 暫未與外界完全分享Prism，但是已經分享了Corona，如果依照慣例，不久後就會進一步開放該軟件的分享了。這也是雇傭Avery Ching這類工程師的原因之一。“在Facebook，我們率先面對問題，”他說。“其他人可以從中受益。他們不需要重蹈覆轍。”
數據藏在糖果島
Hadoop是Facebook數據運營的基礎——雖需假以時日，但有了Scuba等工具的幫助，公司仍是沿著新方向在發展。
Scuba由有著Josh Metzler（在 Top Coder編程競賽中經常名列前茅）在內的工程師團隊創建，是致力於提高信息分析速度的內存數據數據庫。運行於Facebook數據中心的微型軟件客戶端會手機基礎架構的狀態變化等信息，然後由Scuba把這些日志數據壓縮到存儲系統。之後就可以立即查詢這些數據了。
“就好像Excel透視表”Parikh提到常用數據表時說，“除非你要處理的數據行有幾百萬，否則你就可以以次秒級響應時間來處理數據。”
這 個項目似乎與Peregrine有重復——至少部分如此。但正如Jeff Hammerbacher指出，“Facebook的創建方式是找最快的解決辦法。”“Facebook不會創建一個龐大的萬能系統作為解決方案。”和很 多Facebook項目一樣，Scuba是公司發展的結果。工程師遇到問題解決問題，不會等到另一個項目批復才解決。
這些問題處處可見。Santosh Janardhan要處理PayPal和YouTube的數據，但他認為和Facebook的數據比起來，這些工作相形之下顯得微不足道。如果你是一個技術控，這裡就是你的糖果島。