Facebook有了“自知之明”

　　在2005年9月，Facebook首次向非大學生公開，允許高中生注冊賬號。忠實的用戶憤怒了，但Facebook團隊認為這是為網站做出的正常方向。那么它該如何證明它的方案是正確的呢？

　　此外，在幾乎所有可登錄Facebook網站的學校中，Facebook已經滲入學生當中，但還是在有部分學校中，該網站一直不受青睞。和那些更成功的網絡相比，這些落后的網絡對于Facebook有什么區別呢？Facebook團隊應該如何做才能激勵他們的成功？

　　當我在2006年2月參加Facebook面試時，他們正積極地期望找到這些問題的答案。我曾在大學學習數學，在華爾街工作近一年，工作內容是構建模型來預測利率、價格復雜的衍生產品和對沖抵押貸款池；有一定編程經驗，GPA成績“暗淡”。雖然我的背景可能不太理想，但是Facebook卻給了我研究科學家的職位。

　　幾乎同時，Facebook聘用了一位報告分析主管。該主管在解決問題方面的經驗遠遠超過我。我們和另外一位工程師一起，開始著手構建一個數據收集和存儲平臺，以便找到我們產品以上問題的答案。

　　我們第一個嘗試是構建一個離線信息庫，其涉及兩個方面：一是用Python腳本把查詢分發到Facebook的MySQL服務器層，二是采用C++實現守護進程，實時地處理事件日志。當腳本可以如期運行，我們每天收集大約10GB的數據。我后來明白系統的這部分通常稱為“ETL”過程，即抽取、轉換和加載。

　　Python腳本和C++守護進程從Facebook的數據源系統中抽取數據，然后這些數據又被加載到MySQL數據庫用于離線查詢。我們在包含這些數據的MySQL上又運行了一些腳本和查詢，對數據進行聚集，以便得到更有用的表現方式。這種用于決策支持的離線數據庫即“數據倉庫”。

　　最后，通過簡單的PHP腳本把數據從離線的MySQL數據庫抽取出來，向內部用戶展示收集到的信息摘要（Summary）。這是我們第一次可以回答網站特性對用戶行為的影響。早期通過以下幾種渠道分析最大化增長：登出用戶的默認頁面的布局、邀請來源、Email聯系方式導入器的設計。除了以上分析，我們開始通過歷史數據開發簡單的產品，包括對贊助商成員特性進行聚集的內部項目。實踐證明，該項目很受品牌廣告商歡迎。

　　我那時沒有意識到，實際上，通過ETL框架、數據倉庫和內部控制臺，我們已經構建了一個簡單的“商業智能”系統。

　　“獵豹”和“大象”(譯注1)

　　從第一天開始對Facebook的點擊流寫日志起，到現在我們已經收集了超過400GB的數據。對該數據集的加載、索引和聚集操作對Oracle數據庫的負載很重。雖然做了很多優化操作，但是我們還是無法在24小時內完成對一天的點擊流的聚集操作。很顯然，我們需要把日志文件聚集到數據庫外，只在數據庫中保存摘要信息供后期查詢。

　　幸運的是，一個來自某大型網站的頂尖工程師加入了我們團隊，他有過處理大規模Web點擊流的經驗。僅僅幾周的時間，該工程師就構建了一個名為Cheetah（獵豹）的并發日志處理系統，該系統能夠在兩個小時內處理一天的點擊流。這實在太讓人振奮了。

　　但是，Cheetah存在一些不足：首先，在處理完點擊流數據后，原始數據還是以歸檔方式保存，不能夠被再次查詢。此外，Cheetah是從一個共享的NetApp歸檔數據中獲取點擊流數據，而NetApp歸檔數據的讀帶寬受限。每個日志文件的“模式”是嵌入在處理腳本中，而不是保存為可查詢格式。我們沒有收集進程信息，而是通過Unix基礎工具cron來調Cheetah任務，因此無法應用復雜的加載共享邏輯。最重要的是，Cheetah不是開源的。我們團隊很小，資源有限，無法分配更多的資源來開發、維護和給新用戶培訓使用Cheetah系統。

　　Apache的Hadoop項目，由Doug Cutting和Mike Cafarella于2005年末啟動，是我們取代Cheetah的最佳選擇。以Doug的孩子的玩具大象命名，Hadoop項目的目標是實現遵從Apache2.0許可的G公司的分布式文件系統和MapReduce技術。雅虎在2006年1月聘用了Doug Cutting，并投入了大量的工程資源來開發Hadoop。在2006年4月，該軟件使用188臺服務器，能夠在47小時內，對1.9TB的數據進行排序。雖然Hadoop的設計在很多方面優于Cheetah，但它在那時還太慢了，不能夠滿足我們的需求。在2008年4月，Hadoop用910臺服務器，可以在209秒內對1TB的數據進行排序。由于Hadoop性能的改進，我說服了運行組團隊利用60臺Web服務器和3臺500GB的SATA驅動器，開始在Facebook第一次部署Hadoop集群。

　　在最開始， 我們通過流方式在Hadoop和Cheetah中都導入一部分日志。Hadoop增強的編程能力加上其能夠查詢歷史數據，從而推動了一些其他有趣的項目。其中一個應用是對所有Facebook用戶交互的有向對進行打分來確定這些用戶的親密程度；這個分數可以被用于搜索和新聞訂閱的排序。過了一段時間，我們把所有的Cheetah工作流都遷移到Hadoop上，廢棄了前者。后來，事務數據庫收集程序也都遷移到了Hadoop。

　　有了Hadoop，Facebook的基礎設施可以支持對無結構化和結構化的數據的大規模分析。隨著平臺擴展為每天幾百TB的數據規模，可以執行成千上萬個任務，我們發現由于現在系統能夠存儲和檢索的數據規模很大，我們可以構建新的應用，探索新問題的答案。

　　當Facebook向所有的用戶開放注冊，用戶數在一些國家增長迅猛。但是在那時，我們無法根據國家執行點擊流粒度分析。自從有了Hadoop集群，我們可以通過加載所有的歷史訪問日志到Hadoop，寫一些簡單的MapReduce任務來重新分析Facebook在一些國家，如加拿大和挪威增長迅猛的原因。

　　Facebook的用戶每天都有幾百萬半公開的對話。據一次內部估算，留言板的數據量是博客的10倍！但是，這些對話的內容還是無法進行訪問用來數據分析。在2007年，一個對語言學和統計學有強烈興趣的暑期實習生Roddy Lindsay加入了數據組。通過Hadoop，Roddy能夠獨立構建一個強大的趨勢分析系統，該系統名為Lexicon，每天晚上能夠處理TB級別的留言板數據。

　　在為Facebook應用構建信譽積分系統時，我們證明了把不同系統的數據存儲到相同的存儲庫中會導致嚴重的問題。在2007年5月啟動了Facebook平臺后不久，我們的用戶就被“淹沒”在添加應用的請求中。我們很快意識到需要添加一個工具來識別有用的應用和用戶認為是spam的應用。通過收集API服務器的數據、用戶信息以及來自網站本身的行為數據，系統能夠構建一個模型對應用進行打分，這使得系統可以分發我們認為對用戶最有用的應用邀請。

　　新工具和應用研究

　　在Facebook，絕大部分Hadoop集群的早期用戶都是渴望追求新興技術的工程師。為了使企業的更多人可以訪問信息，我們在Hadoop上構建了一個數據倉庫框架，并稱為Hive。

　　Hive的查詢語言類似于SQL，支持嵌入MapReduce邏輯、表分區、抽樣和處理任意序列化數據的能力。最后一個特征至關重要，因為收集到Hadoop的數據在結構上不斷變化；允許用戶指定自己的序列化模式，可以使我們把為數據指定結構問題轉為把數據加載到Hive。此外，我們還實現了一個簡單的用戶界面來構建Hive查詢，名為Hipal。使用這些新的工具，市場、產品管理、銷售和客戶服務的非工程師都能夠在幾TB的數據上自己執行查詢。經過幾個月的內部使用后，在Apache2.0許可下，Hive成為Hadoop的官方子系統，現在仍然在積極地開發中。

　　除了Hive，我們構建了分享圖表和圖形的門戶Argus（受IBM的Many Eyes 項目啟發） 、工作流管理系統Databee、用Python寫MapReduce腳本的框架PyHive、為終端用戶提供結構化數據服務的存儲系統Cassandra（現在作為開源，在Apache孵化器中）。

　　隨著這些新系統的穩定，我們最終構建了由單一Hadoop集群管理的多層模式的數據。企業中的所有數據，包括應用日志、事務數據庫和Web爬蟲，都以原始數據格式，定期收集到Hadoop分布式文件系統中。夜間執行的幾萬個Databee進程將把一部分數據轉化為結構化格式，把它放入由Hive管理的HDFS文件目錄中。在Hive中執行下一步聚集操作，用來生成Argus服務報表。此外，在HDFS內，在自己的home目錄下維護“沙盒”的工程師可以運行原型任務。

　　目前，Hadoop包含了將近2.5PB的數據，而且以每天15TB的數量級增加。每天都有3000個以上的MapReduce任務在運行，處理55TB的數據。為了適應這些運行在集群上的任務的不同優先級，我們構建了作業調度器，實現在多個隊列上的資源共享。

　　除了支持內部和外部的報表、a/b測試管道和很多不同的數據密集型產品和服務，Facebook的Hadoop集群可以實現一些有趣的應用研究項目。

　　由數據科學家Itamar Rosenn 和Cameron Marlow主持的一個縱向研究項目用于預測長期的用戶參與的最重要的因素是什么。我們使用信息平臺來選擇一些用戶的樣本，刪除游離點，并對參與度的不同尺度使用一些最小角度回歸技術來生成大量的特性。有些特性能夠通過Hadoop生成，包含計算好友網絡密度的各種尺度和基于信息特性的用戶范圍。

　　另一個探索激勵新用戶貢獻內容的動機的內部研究，在2009年CHI 會議的論文“Feed Me: Motivating Newcomer Contribution in Social Network Sites”中有描述。Fa c ebook數據組的一個更新的研究是查看信息流是如何在Facebook的社會圖中流動，該研究的標題為“Gesundheit! Modeling Contagion through Facebook News Feed”，已被2009 ICWSM會議接收。

　　在Facebook，每天收集證據、測試假設、構建應用和使用共享的信息平臺生成新的洞察。而在Facebook之外，其他公司也同時構建了類似的系統。

　　數據科學家

　　在最近的訪談中，G公司首席經濟學家Hal Varian強調了員工需要能夠從之前描述的信息平臺中抽取信息。正如Varian所言：“找到能夠為一些變得普遍且廉價的東西提供稀缺、互補的服務。那么，是什么變得普遍且廉價？數據。是什么與數據相輔相成？分析。”

　　在Facebook，我們發現傳統的頭銜如商業分析師、統計學家、工程師和研究科學家都不能確切地定義我們團隊的角色。該角色的工作是變化多樣的：在任意給定的一天，團隊的一個成員可以用Python實現一個多階段的處理管道流、設計假設檢驗、用工具R在數據樣本上執行回歸測試、在Hadoop上為數據密集型產品或服務設計和實現算法，或者把我們分析的結果以清晰簡潔的方式展示給企業的其他成員。為了掌握完成這多方面任務需要的技術，我們創造了“數據科學家”這種角色。