從領導臉書Big Data團隊經驗談起：資訊平臺與資料科學家的崛起

2005年9月，Facebook首度開放給非大學生，允許高中生註冊帳號。許多忠實使用者感到不滿，但Facebook團隊認為這麼做對網站而言是正確的方向。然而，要怎麼提出證據證明自己的立場？

還有，Facebook 幾乎受到所有大學生的歡迎，但仍然有些大學生沒有使用Facebook。這些落差與順利完成的同儕之間有什麼差別，而該怎麼做才能促使他們完成任務？我 2006年2月在Facebook面試時，他們早就積極探尋這些問題的答案了。大學時主修數學，還在華爾街工作將近一年，建置模組預測利率、為複雜的衍生性商品定價以及平衡交易貸款群組（hedge pools of mortgages）。我有些程式撰寫經驗和不怎麼樣的 GPA。儘管我的背景不特別出眾，Facebook仍讓我加入擔任研究科學家一職。

值此同時，Facebook 找了個報告暨分析總監（Director of Reporting and Analytics），這個主管在此議題領域比我更有經驗，再加上第三個工程師，我們開始著手建置資料收集與儲存的基礎架構，以便能夠回應有關產品的相關問題。

我們首度嘗試是在離線的資訊倉儲上，用 Python script 執行查出 Facebook的MySQL伺服器層任務，以及用C++寫成的daemon程序，即時處理我們的事件紀錄檔。當script如預想的規劃運作時，我們一天大約會收集到10GB的資料量。之後我意識到我們系統裡的這個部份就是一般所謂的「ETL」程序，也就是「提取、轉換與載入」。

一旦Pythonscript與C++daemon將資料從Facebook的來源系統裡抽取出來後，我們就會把資料餵進MySQL資料庫作離線查詢。我們也有些script與查詢是當資料放進MySQL後才執行，以便將之總合整理成更有效的呈現方式。此種用來做決策支援的離線資料庫更為人熟知的名稱為「資料倉儲（DataWarehouse）」。

最後，我們用PHP script將資料從離線的MySQL資料庫拉進來，然後將我們收集的摘要資訊呈現給內部使用者。第一時間我們就能夠回答一些有關在使用者活動裡特定網站功能造成影響的問題。初步分析著眼於透過幾個管道讓成長最大化。對於登出使用者的預設網頁樣本、邀請的來源，以及電子郵件聯絡人匯入的設計。除了分析外，我們開始利用歷史資料建置一些簡單的產品，例如內部專案，整合贊助的群組成員的功能，證明顯示相當受品牌廣告商的歡迎。

我在那時沒有意識到，用我們的ETL框架、資料倉儲與內部管理面板，已建置出簡單的「商業智慧（BusinessIntelligence）」系統。

商業智慧系統

1958年IBM Systems Journal裡有篇Hans Peter Luhn敘述「選擇性傳播」系統的文章，敘述了以個人行動點（action points）裡「有趣的個人資料」為基礎的「行動點（action points）」。作者展現了令人訝異的先見之明。文章的標題為「商業智慧系統」，是那個時代背景下首度出現「商業智慧」這個名詞。

除了即時資訊傳播外，這個系統還允許在整個文件收集上處理「資訊檢索」，也就是搜尋。Luhn強調行動點（action points）的重心，是放在當目標完成時進行資訊處理的任務上。換句話說，它不單只是收集與聚集資料，一個組織必須不斷精進它對搜集完成之資料的洞察力，以及完成關鍵性任務的能力。他還提出「報表」的觀念，定期篩檢資料，並選擇性地依需求移動資料到行動點（action points）上。

商業智慧方面從Luhn文章發表至今已50年，這些名詞已更接近有關結構化資料的管理。時至今日，典型商業智慧系統結合了將日常基礎資料從來源資料陣列取出放進資料倉儲的ETL架構，以及透過商業分析產生資料供內部使用的商業智慧工具。我們要如何將Luhn的想法實現為時下可行的狀態？

E.F.Codd在1970年首度提出資料的關連性模型，而IBM處理關連性資料庫管理系統（RDBMS）的原型則是始於1970年代中期。建構使用者互動應用程式乃RDBMS一大躍進，1980年代初期，它們的使用已開始慢慢增多。

1983年，Teradata賣出第一套用於決策支援的關連性資料庫設計給 Wells Fargo。三年後，Ralph Kmball建置了針對相同市場的資料庫Red Brack System。使用Teradata與Red Brick所開發的解決方案仍持續提供，不過，不到1991年第一份資料倉儲的正式文件就出版了。

Bill Inmon的Building the Data Warehouse（Wiley）是一份相當有條理的資料倉儲設計論文，裡頭涵蓋了有關建置資料倉儲的詳盡處理方式與最佳實作方式。Inmon提倡在謹慎研究現有資料來源與商業目標後，再建構企業資料模組。

1995年，Inmon的書大受歡迎，企業資料中心裡迅速增加了許多資料倉儲。DataWarehouse Institute（TDWI）成立，舉辦會議與研討會，並且在闡明與傳播關於資料倉 儲的知識上，一直具有關鍵性影響力。同年，資料倉儲因 Stanford University 啟動它們的 WHIPS 研究機構而在大學社群裡廣為流傳。

針對關於Inmon正統性的挑戰出現在1996年Ralph Kimball發表的The Data Warehouse Toolkit（Wiley）。Kimball提倡用不同的方式達到資料倉儲的完美境界，首先就是丟掉企業資料模型。取而代之的是 Kimball所主張的不同商業單位應建置它自有的資料「marts」，之後可以透過「匯流排」連結。進一步取代一般資料模型的使用，Kimball 提倡維度模型化，以人工方式處理關連性資料模組，以適應許多資料倉儲實作之常見的特定工作。

資料倉儲經過一段時間的成長，自然會出現商業分析師想快速處理小型資料子集的情況。通常這種資料子集會用一些「維度」的方式進行參數化。在這些觀察的建置上，1997年Microsoft的一群研究人員─包括Jim Gray 引進了CUBE運算元。這個新的運算元可以快速處理小型、多維資料集查詢。

維度模型化與CUBE運算元雙雙指出，無論它在建置使用者互動應用程式上有多成功，關連性模組可能並不是建構資訊平台最好的方式。而且，文件與行動點而非表格，才是Luhn對商業智慧系統所提出之建議書的核心。此外，這一代的工程師在建置關連性資料處理的系統上，都有相當程度的經驗。

有了我們的一些背景歷史說明，現在回到Facebook的挑戰上。

資料倉儲之死與重生

在Facebook，我們持續在MySQL資料倉儲上載入更多資料進去，並在其中執行更多的查詢。在已上線站台上提供服務的資料庫裡，只不過執行一些查詢，便訝異地發現在我們的資料倉儲裡進行查詢竟要執行這麼久。經過與有經驗的資料倉儲老手討論之後，我們意識到因查詢的複雜度、大規模的資料量，或者兩個因素都有，查詢必須執行數小時，有時甚至是好幾天，是很正常的。

有一天，我們的資料庫將近有TB（terabyte）大小時，mysqld deamon 程序突然停止（halt）。花了一些時間判斷後，我們嘗試重新啟動資料庫。執行初始化重新啟動後我們就回家了。

隔天早上回來工作時，發現資料庫還在執行回復動作中。為取得被眾多用戶端修改過之資料的一致性檢視，資料庫伺服器維護所有編輯的固定清單叫作「redo log」或「write-ahead log」。當資料庫以非正規形式刪除或重新啟動時，它就會從redolog重讀最近做的編輯以便加快恢復的速度。就我們資料倉儲的大小來看，MySQL資料庫的回復速度必須再加快些才趕得上。它花了三天的時間，才讓我們再度擁有能夠運作的資料倉儲。

我們在這個時間點做出了把資料倉儲移轉至Oracle的決定，這個資料庫軟體對管理大型資料集的支援較佳。我們也購買了一些昂貴的高密度儲存裝置與功能強大的Sun伺服器，以便執行這個新的資料倉儲。

在將我們的處理程序從MySQL轉換到Oracle的過程中，我才體會出推測標準關連性資料庫實作之間的差異。每個資料庫所使用的大量資料匯入匯出工具，使用的是完全不同的機制。而且各個SQL語言支援的慣用語也各不相同，因而逼得我們不得不重做許多查詢。更糟的是，Oracle所使用的Python用戶端函式庫竟為非正式提供的支援而且還有點小問題，因而我們得直接聯繫開發人員。

經過幾週的努力後，我們讓重新撰寫的script在Oracle平台上運作了。每晚執行的程序不再是問題，我們也很興奮地試了一些Oracle體系所提供的工具程式。值得一提的是，Oracle有個叫作OracleWarehouseBuilder（OWB）的ETL工具程式，幫我們取代了手寫的Pythonscript。較遺憾的一點是，這個軟體沒有預期到我們必須支援的資料來源確切數量。當時，每晚收集到的資料在Facebook裡是以上萬個MySQL資料庫支應。Oracle不僅能夠幫助我們處理ETL端在擴充規模上的挑戰，我們也很高興只要執行處理幾TB（terabyte）資料量的資料倉儲。

而當我們開啟點擊資料流的紀錄，發現第一個整天就傳送400GB未結構化的資料衝向我們的Oracle資料庫。再一次，我們對自家資料倉儲產生疑慮。

Cheetah 與 Elephant

第一天紀錄Facebook點擊資料流，就收集到超過400 GB的資料。載入、索引與聚集這些資料集的程序，確實成為Oracle資料倉儲的負擔。即便經過一番調校，我們仍無法在24小時以內，統整一天點擊資料流的資料。很明顯地，我們必須將事件紀錄檔集中收集在資料庫以外的地方，並且只儲存摘要資料供日後查詢。

很幸運，最近有個大型網站的頂尖工程師加入我們團隊，而且對於處理網站規模的點擊資料流資料很有經驗。只花幾個禮拜，他就將平行事件紀錄處理系統建置完成，稱之為Cheetah，它能夠在兩小時內處理一整天點擊資料流的資料。相當令人振奮。

僅管我們成功了，但Cheetah仍有不足之處。首先，在處理完點擊資料流的資料後，原始資料會被存放至檔案式儲存裝置裡，且不能夠再被查詢。此外，Cheetah從共享的NetApp filer把資料拉進來，用的是有限的讀取頻寬。每個事件紀錄檔的「schema」是嵌入在處理中的script，而不是以能夠查詢的格式儲存。我們並未收集處理過程的資料，而且是使用基本的Unixt工具cron排程Cheetah的工作，因此沒有複雜的負載共享邏輯可以應用。然而最重要的是，Cheetah不是開放源碼。我們只有一個小型團隊，無法撥出資源給必要的開發、維護，也無法訓練新的使用者，使用我們的專利權系統。

Apache Hadoop專案，由Doug Cutting與Mike Cafarella在2005年後期發起，是取代Cheetah的絕佳方案。Hadoop以Doug兒子的絨毛大象為名，此專案致力於在Apache 2.0許可權下，建置Google的分散式檔案系統與MapReduce技術。Yahoo！於2006年1月雇用DougCutting，投入可觀的工程資源開發Hadoop。2006年4月，這個軟體已經能夠在使用188台伺服器下，於47小時內排序1.9TB的資料。雖然Hadoop的設計改良Cheetah諸多層面，但這個軟體以我們當下需求來說仍太慢。2008年4月，Hadoop已經能夠在使用910台伺服器的條件下，於209秒內排序1TB的資料。為了改善手頭的效能數字，我說服了營運團隊，在60台非使用中的網頁伺服器背後插入三台500GB的SATA磁碟，便著手啟動Facebook第一個Hadoop叢集。

一開始，我們讓事件紀錄檔子集資料流注入Hadoop與Cheetah。Hadoop強化後的可編程能力，結合歷史資料查詢功能，引出一些有趣的專案。其中一個應用程式是在Facebook互動的使用者雙向的計分，決定他們之間的關係，這個分數之後可以用於搜尋與NewsFeed的排名。一段時日後，我們將Cheetah工作流程移至Hadoop，並重試舊系統。之後，交易資料庫收集程序也被移往Hadoop了。

有了Hadoop，我們的基礎架構便能夠提供大規模未結構化資料與結構化資料的分析。當平台成長到一天數百TB與數千筆任務，我們深深瞭解，就我們現在能儲存與檢索資料的規模，新的應用程式得以建置，而新的問題也能輕鬆獲得解答。

當Facebook開放所有人註冊，使用者人數在部份國家以不可思議的速度成長。因此，在這個時侯我們無法執行因為國家因素而爆滿的點擊資料流粒度分析（granularanalyses）。一旦我們的Hadoop叢集啟動，便能將所有歷史存取事件紀錄載入Hadoop裡，並重寫一些簡單的MapReduce任務，重新建構Facebook在像是Canada與Norway那種適當快速成長的方式。

每天，數百萬半公開的對話在Facebook使用者的塗鴨牆裡發生。有個內部粗估，塗鴨牆發表內容的規模，竟是部落格圈的十倍。然而，在Hadoop出現前，這些對話內容是很難進行資料分析的。在2007年，一個對語意學與統計學具強烈興趣的暑期實習生RoddyLindsay加入了Data團隊。透過Hadoop，Roody一個人獨立建構了強大的趨勢分析系統，稱之為Lexicon，它可以每晚持續處理數TB的塗鴨牆發表。你可以自行到http://facebook.com/lexicon瞭解這個成果。

由於必須讓來源互不相關的系統資料存放進單一倉儲裡，對Facebook應用程式而言，建構評等系統（reputation scoring system）顯然至關重要。在2007年5月啟動Facebook平台後沒多久，我們的使用者疲於接收加入應用程式的要求。我們隨即體認到需要一個工具將有用的應用程式與使用者接收到的垃圾區隔開來。使用收集自API伺服器、使用者個人資料，以及來自網站本身的活動資料，我們可以建構計分應用程式模組，因此能夠分配我們認為對使用者最有用之應用程式的邀請。

The Unreasonable Effectiveness of Data

最近有一篇由Google三人研究小組所寫的文章，集結了他們嘗試解決機器學習上遇到的一些最困難的問題精華。在探討語音辯識與機器移轉的部份，他們描述:「始終如一的是，簡單模組與大量資料的組合，遠勝於建置於少量資料上的精細模組。」我不打算探討他們的研究成果，絕對也有將精細模組使用得相當成功的領域。在他們的經驗裡，確實存在各種範疇的問題，這種情況下較多資料與簡單模組的搭配會比較好。

在Facebook裡，Hadoop是我們用來活用過份資料有效性（unreasonable effectiveness of data）的工具程式。舉例來說，當我們將一個站台轉換成另一種語言時，我們會試著鎖定使用特殊語言的目標使用者，在這個轉換任務裡尋求他們的協助。我們的資料科學家Cameron Marlow爬過所有Wikipedia，為每個語言建置character trigram頻率計數。利用這些頻率計數，建立簡單的分類器，可以查看使用者撰寫的塗鴨牆，決定他所說的語言。

利用這樣的分類器，我們就能以目標為導向，主動募集使用者進入我們的轉換程式。Facebook與Google都在很多的應用程式裡使用自然語言資料。

這份來自Google的觀察，指出了現今商業智慧系統進程的第三條路，除了在單一系統裡管理結構化與非結構化的資料，還必須擴充規模以儲存足夠的資料，才能讓「簡單模組、大量資料」的方式啟動機器學習。

新工具與應用研究

絕大多數在Facebook裡H/badoop叢集的早期使用者，都是嘗試這個新技術的工程師。為了讓資料能夠讓組織多數人存取，我們在Hadoop上為資料倉儲建立框架，稱之為Hive。
Hive涵蓋類似SQL的查詢語言，並具備給嵌入式MadReduce邏輯使用的工具，還擁有表單分割、取樣，以及處理任意序列資料的能力。最後一個功能相當重要，因為資料收集至Hadoop裡的結構不斷在演變。允許使用者指定他們自有的序列格式，讓我們能夠將為資料指定架構的問題，交給載入資料至Hive負責。此外，建構Hive查詢的簡單UI，稱之為HiPal亦建置完成。使用這個新的工具程式，就連像是行銷、產品管理、業務與客服這些非工程師的人，也能夠編輯處理數TB資料量的查詢。在經過幾個月內部使用後，Hive捐回給Hadoop，成為Apache2.0許可權下的官方子專案，並持續積極開發。

除了Hive外，我們還建置了分享圖表與圖形的入口網站Argus（靈感來自IBM的Many Eyes專案）、工作流程管理系統Databee、為了使用Python撰寫MapReduce script的框架PyHive，以及為終端使用者提供結構性資料的儲存系統，稱之為Cassandra（現為Apache Incubator下可用的開發源碼）。

因為新的系統已穩定，我們便結束單一Hadoop叢集所管理的多層級資料。所有來自於企業的資料，包括應用程式事件紀錄、交易資料庫與網頁抓取，皆定期以原始型式收集至Hadoop分散式檔案系統（HDFS）裡。每夜執行上千筆Datebee程序之後會轉換部份資料為結構化型式，放進由Hive管理的HDFS目錄裡。在Hive裡執行進一步的匯集，以便Argus產生報告。另外，在HDFS裡，個別工程師在他們家目錄下，針對雛型工作所維護的「sandboxes」也能運作。

就其現有的能力而言，叢集能夠處理近2.5PB的資料，而新加入的資料每天也有15TB的比例。每天執行的MapReduce任務超過3,000筆，處理55TB的資料量。為對應叢集裡執行之不同工作的優先性，我們建置了排程工具程式，為多重查詢執行公平的資源分配。

除了啟動內部與外部報告、a/b測試管道，以及許多不同資料密度產品與服務外，Facebook的Hadoop叢集還啟動了一些有趣的應用研究專案。

一個由資料科學家Itamar Rosenn與Cameron Marlow所領導的長期研究，打算找出能夠預知長期使用者參與的最關鍵因子。我們利用自己的平台選擇使用者樣本、微調異常部份，並以最小角度回歸（least-angle regressions）產生大量的使用特徵並因應不同的參與度衡量方式。有些功能我們可以透過Hadoop產生，包括各種朋友網路密度的計算，以及利用個人資料功能所做的使用者分類。

每一天，透過Facebook共享資訊平台，進行著收集證據、測試假說、建立應用程式並產生新的看法。同時，除Facebook外也有類似的系統正在建構。

MAD Skills與Cosmos

在2009年VLDB會議裡發表的「MADSkills:NewAnalysisPracticesforBigData」裡，對FoxInteractiveMedia（FIM）分析環境有相當詳盡的敘述。利用結合Hadoop與Greenplum資料庫系統的方式，FIM團隊建置了一個類似的資料處理系統，和我們在Facebook裡作的事完全不同。

這篇文章指出了FIM平台的三個宗旨，吸引力（Magnetic）、敏捷（Agile）與深度（Deep）。「吸引力」指的是要能夠儲存所有產生自企業的資料，而不只是那些符合企業資料模組的結構化資料。以此類推，「敏捷」的平台必須要能夠優雅處理規劃的進程，可以立即著手分析資料，並依需求發展資料模組。「深度」指的是在資料上執行更複雜的統計分析實作。

FIM的環境裡，單一Greenplum資料庫裡的資料以階段性、產品、報告，以及沙箱模組區分，相當類似先前所述Facebook裡Hadoop內部的多層分級。

在這之外，Microsoft 公開發表其資料管理堆疊的詳細內容。在名為「Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks」與「SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets」的文章裡，Microsoft敘述的資訊平台，和我們在Facebook已建立的那個極為相似。其基礎架構裡涵蓋了稱之為Cosmos的分散式檔案系統，以及平行資料處理系統Dryad。它甚至發明了類SQL的查詢語言，名為SCOPE。

三個團隊處理三個分開的技術堆疊，卻發展出類似的大量資料處理平台。怎會如此？從儲存資料的能力與資料檢索API的改革中，抽掉特定架構的需求，可得出大型網站屬性的儲存系統，所以要開始尋找的不是像資料庫這樣的東西，而是更接近資料倉儲（dataspaces）的概念。

以資料倉儲作資訊平台

據說，Yahoo！、Quantcast與Last.fm這些公司裡也有類似PB規模的平台。這些平台不全然是資料倉儲，它們通常不使用關連性資料庫或任何傳統資料倉儲模型化技術。它們也不能說是企業搜尋系統，因為只有部份資料被索引化，且它們還公開了相當豐富的API。除了傳統資料分析的工作外，它們多半用於建置產品與服務上。這些資料處理的共享平台，在組織裡進行吸取、處理與產生資訊的服務，更幸運的是，它們可以加快組織從經驗資料學習的腳步。

在資料庫社群裡，出現了一些致力於將純關連性資料管理，轉換為更包羅萬象的大型資料集儲存與查詢系統 「資料倉儲」的研究議程。在「From Databases to Dataspaces: A New Abstraction for Information Management」（http://www.eecs.berkeley.edu/~franklin/Papers/ dataspaceSR.pdf）裡，作者強調儲存系統必須接受所有資料格式，並提供API供資料存取，此進程乃建立於對儲存系統對資料的瞭解上。

我認為我們所敘述的資訊平台就是真實世界裡資料倉儲的實例。管理來自企業所有層面數PB結構化與未結構化資料的單一儲存系統，呈現出各種供工程使用、分析與報告的資料存取API。由於業界這些系統的激增，我衷心盼望資料庫社群能持續探索資料倉儲的理論基礎與實務意涵。

資訊平台乃建置學習組織的關鍵基礎架構元件。用來加速學習程序與資訊平台使用中，資料科學家為最關鍵的人為元件新塑造的角色。

資料科學家

最近的一次採訪，Google首席經濟學家Hal Varian強調對員工的要求，必須有能夠從先前所述的資訊平台抽取資訊出來的能力。一如Varian所述：「我們要找的是，可以提供能夠隨處輕鬆取得的罕見、互補性服務。所以什麼是隨處且可輕鬆取得的？那就是資料。而什麼可以為資料截長補短？答案是分析。」

在Facebook，我們覺得典型的職稱像是商業分析、統計學、工程師與研究科學家，都無法確切表達我們團隊所作的事。我們所設定的角色執行的是多樣化的工作。以一天的工作來說，團隊成員可以用Python編程多階段的處理管線、設計假說測試、利用R在資料範本上執行回歸分析、針對Hadoop的一些資料密集產品與服務設計與執行演算法，或是以明確而簡潔的方式與組織的其他成員溝通我們分析的結果。為切合此技能設定執行這些多重任務的需求，我們創造了「資料科學家」的角色。

在金融服務領域，該領域的資料科學家已開發出可以為複雜的新模組執行驗證的基礎平台，建置過去市場活動的大型資料的存儲，也就是Quants。產業之外，我也發現諸多領域的研究生，一直在扮演資料科學家的角色。我們為Facebook Data團隊雇用的其中一位，就是來自於生物訊息實驗室，他在那裡建置了資料管線，並以類似的形式執行離線資料分析。CERN知名的Large Hadron Collider產生大量能夠讓尋求突破的研究生，進行收集與鑽研的資料。

結論

當我在Facebook面對建置資訊平台的挑戰時，我發現看不同時間點與領域各異的其他人是怎麼試著解決相同問題相當有用。身為工程師的我一開始的方式是直接找可用的技術，而事後證明這樣目光很短淺。最大的挑戰是如何把重點放在為大量問題建置基礎架構以及學習組織裡的人因元件，而非特定技術系統，像資料倉儲或企業搜尋系統那些。

我確定硬體與軟體的使用可以加快資訊平台建置，而資料科學家的技能需求也會以對應速度變化。把重點放在讓學習程序更快的目標上，對組織與科學家來說都是好的。未來是屬於資料科學家的！（摘錄整理自本書第5章）

---

資料之美：優雅資料解決方案的幕後祕辛

Toby Segaran、Jeff Hammerbacher／編

柳百郁／譯

歐萊禮出版、碁峯資訊發行

售價：580元

《作者簡介》
Jeff Hammerbacher

Jeff Hammerbacher為Cloudera的產品副總裁暨首席科學家。Jeff在加入Cloudera前，是常駐Accel Partners的企業家。在Accel前，他孕育、建置並輔導Facebook的Data團隊。Data團隊負責推動Facebook裡許多統計學家與機器學習應用程式，並且建置支援處理這些大量資料集任務的基礎架構。這個團隊發表數篇學術文件並產出兩個開放源碼專案：建置在Hadoop上的離線分析系統Hive，以及P2P網路上的結構化儲存系統Cassandra。在加入Facebook前，Jeff是Wall Street的定量分析師，在哈佛大學取得數學學士學位。