Facebook作為全球知名的社交網站，擁有超過3億的活躍用戶，其中約有3千萬用戶至少每天更新一次自己的狀態;用戶每月總共上傳10億余張照片、1千萬個視頻;以及每周共享10億條內容，包括日志、鏈接、新聞、微博等。因此Facebook需要存儲和處理的數據量是非常巨大的，每天新增加4TB壓縮后的數據，掃描135TB大小的數據，在集群上執行Hive任務超過7500次，每小時需要進行8萬次計算，所以高性能的云平臺對Facebook來說是非常重要的，而Facebook主要將Hadoop平臺用于日志處理、推薦系統和數據倉庫等方面。
Facebook將數據存儲在利用Hadoop/Hive搭建的數據倉庫上，這個數據倉庫擁有4800個內核，具有5.5PB的存儲量，每個節點可存儲12TB大小的數據，同時，它還具有兩層網絡拓撲，如下圖所示。Facebook中的MapReduce集群是動態變化的，它基于負載情況和集群節點之間的配置信息可動態移動。
▲集群的網絡拓撲
下圖為Facebook的數據倉庫架構，在這個架構中，網絡服務器和內部服務生成日志數據，這里Facebook使用開源日志收集系統，它可以將數以百計的日志數據集存儲在NFS服務器上，但大部分日志數據會復制到同一個中心的HDFS實例中，而HDFS存儲的數據都會放到利用Hive構建的數據倉庫中。Hive提供了類SQL的語言來與MapReduce結合，創建并發布多種摘要和報告，以及在它們的基礎上進行歷史分析。Hive上基于瀏覽器的接口允許用戶執行Hive查詢。Oracle和MySQL數據庫用來發布這些摘要，這些數據容量相對較小，但查詢頻率較高并需要實時響應。
▲Facebook數據倉庫架構
一些舊的數據需要及時歸檔，并存儲在較便宜的存儲器上，如下圖所示。下面介紹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文件系統實現在現有文件系統的上層。
▲數據歸檔
表：BackupNode和AvatarNode的區別
基于位置的調度策略在實際應用中存在著一些問題：如需要高內存的任務可能會被分配給擁有低內存的TaskTracker;CPU資源有時未被充分利用;為不同硬件的TaskTracker進行配置也比較困難等。Facebook采用基于資源的調度策略，即公平享有調度方法，實時監測系統并收集CPU和內存的使用情況，調度器會分析實時的內存消耗情況，然后在任務之間公平分配任務的內存使用量。它通過讀取/proc/目錄解析進程樹，并收集進程樹上所有的CPU和內存的使用信息，然后通過TaskCounters在心跳(heartbeat)時發送信息。
Facebook的數據倉庫使用Hive，其構架如下圖所示，有關Hive查詢語言的相關知識可查閱第11章的內容。這里HDFS支持三種文件格式：文本文件(TextFile)，方便其他應用程序讀寫;順序文件(SequenceFile)，只有Hadoop能夠讀取并支持分塊壓縮;RCFile，使用順序文件基于塊的存儲方式，每個塊按列存儲，這樣有較好的壓縮率和查詢性能。Facebook未來會在Hive上進行改進，以支持索引、視圖、子查詢等新功能。
▲Hive的體系結構
現在Facebook使用Hadoop遇到的挑戰有：
·服務質量和隔離性方面，較大的任務會影響集群性能;
·安全性方面，如果軟件漏洞導致NameNode事務日志崩潰該如何處理;
·數據歸檔方面，如何選擇歸檔數據，以及數據如何歸檔;
·性能提升方面，如何有效地解決瓶頸等
京公網安備 11010502049343號