Facebook作為全球知名的社交網站，擁有超過3億的活躍用戶，其中約有3千萬用戶至少每天更新一次自己的狀態；用戶每月總共上傳10億余張照 片、1千萬個視頻；以及每周共享10億條內容，包括日志、鏈接、新聞、微博等。因此Facebook需要存儲和處理的數據量是非常巨大的，每天新增加 4TB壓縮后的數據，掃描135TB大小的數據，在集群上執行Hive任務超過7500次，每小時需要進行8萬次計算，所以高性能的云平臺對 Facebook來說是非常重要的，而Facebook主要將Hadoop平臺用于日志處理、推薦系統和數據倉庫等方面。

Facebook將數據存儲在利用Hadoop/Hive搭建的數據倉庫上，這個數據倉庫擁有4800個內核，具有5.5PB的存儲量，每個節點可 存儲12TB大小的數據，同時，它還具有兩層網絡拓撲，如圖3-5所示。Facebook中的MapReduce集群是動態變化的，它基于負載情況和集群 節點之間的配置信息可動態動。

圖 3-6為Facebook的數據倉庫架構，在這個架構中，網絡服務器和內部服務生成日志數據，這里Facebook使用開源日志收集系統，它可以將數以百 計的日志數據集存儲在NFS服務器上，但大部分日志數據會復制到同一個中心的HDFS實例中，而HDFS存儲的數據都會放到利用Hive構建的數據倉庫 中。Hive提供了類SQL的語言來與MapReduce結合，創建并發布多種摘要和報告，以及在它們的基礎上進行歷史分析。Hive上基于瀏覽器的接口 允許用戶執行Hive查詢。Oracle和MySQL數據庫用來發布這些摘要，這些數據容量相對較小，但查詢頻率較高并需要實時響應。一些舊的數據需要及 時歸檔，并存儲在較便宜的存儲器上，如圖3-7所示。

下 面介紹Facebook在AvatarNode和調度策略方面所做的一些工作。AvatarNode主要用于HDFS的恢復和啟動，若HDFS崩潰，原有 技術恢復首先需要花10～15分鐘來讀取12GB的文件鏡像并寫回，還要用20～30分鐘處理來自2000個DataNode的數據塊報告，最后用 40～60分鐘來恢復崩潰的NameNode和部署軟件。表3-1說明了BackupNode和AvatarNode的區別，AvatarNode作為普 通的NameNode啟動，處理所有來自DataNode的消息。AvatarDataNode與DataNode相似，支持多線程和針對多個主節點的多 隊列，但無法區分原始和備份。人工恢復使用AvatarShell命令行工具，AvatarShell執行恢復操作并更新ZooKeeper的 zNode，恢復過程對用戶來說是透明的。分布式Avatar文件系統實現在現有文件系統的上層。

表3-1　BackupNode和AvatarNode的區別

基于位置的調度策略在實際應用中存在著一些問題：如需要高內存的任務可能會被分配給擁有低內存的TaskTracker；CPU資源有時未被充分利 用；為不同硬件的TaskTracker進行配置也比較困難等。Facebook采用基于資源的調度策略，即公平享有調度方法，實時監測系統并收集CPU 和內存的使用情況，調度器會分析實時的內存消耗情況，然后在任務之間公平分配任務的內存使用量。它通過讀取/proc/目錄解析進程樹，并收集進程樹上所 有的CPU和內存的使用信息，然后通過TaskCounters在心跳（heartbeat）時發送信息。

Facebook的數據倉庫使用Hive，其構架如圖3-8所示，有關Hive查詢語言的相關知識可查閱第11章的內容。這里HDFS支持三種文件 格式：文本文件（TextFile），方便其他應用程序讀寫；順序文件（SequenceFile），只有Hadoop能夠讀取并支持分塊壓 縮；RCFile，使用順序文件基于塊的存儲方式，每個塊按列存儲，這樣有較好的壓縮率和查詢性能。Facebook未來會在Hive上進行改進，以支持 索引、視圖、子查詢等新功能。

 現在Facebook使用Hadoop遇到的挑戰有：

• 服務質量和隔離性方面，較大的任務會影響集群性能；
• 安全性方面，如果軟件漏洞導致NameNode事務日志崩潰該如何處理；
• 數據歸檔方面，如何選擇歸檔數據，以及數據如何歸檔；
• 性能提升方面，如何有效地解決瓶頸等。

作者：陸嘉恒