信息平臺和數(shù)據(jù)科學家的興起

　　Facebook有了“自知之明”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　有了Hadoop，F(xiàn)acebook的基礎設施可以支持對無結構化和結構化的數(shù)據(jù)的大規(guī)模分析。隨著平臺擴展為每天幾百TB的數(shù)據(jù)規(guī)模，可以執(zhí)行成千上萬個任務，我們發(fā)現(xiàn)由于現(xiàn)在系統(tǒng)能夠存儲和檢索的數(shù)據(jù)規(guī)模很大，我們可以構建新的應用，探索新問題的答案。

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

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

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

　　新工具和應用研究

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

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

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

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

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

　　除了支持內部和外部的報表、a/b測試管道和很多不同的數(shù)據(jù)密集型產(chǎn)品和服務，F(xiàn)acebook的Hadoop集群可以實現(xiàn)一些有趣的應用研究項目。

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

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

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

　　數(shù)據(jù)科學家

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

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