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

Facebook將數(shù)據(jù)存儲在利用Hadoop/Hive搭建的數(shù)據(jù)倉庫上，這個數(shù)據(jù)倉庫擁有4800個內(nèi)核，具有5.5PB的存儲量，每個節(jié)點可存儲12TB大小的數(shù)據(jù)，同時，它還具有兩層網(wǎng)絡拓撲。Facebook中的MapReduce集群是動態(tài)變化的，它基于負載情況和集群節(jié)點之間的配置信息可動態(tài)移動。

Facebook的數(shù)據(jù)倉庫架構(gòu)，在這個架構(gòu)中，網(wǎng)絡服務器和內(nèi)部服務生成日志數(shù)據(jù)，這里Facebook使用開源日志收集系統(tǒng)，它可以將數(shù)以百計的日志數(shù)據(jù)集存儲在NFS服務器上，但大部分日志數(shù)據(jù)會復制到同一個中心的HDFS實例中，而HDFS存儲的數(shù)據(jù)都會放到利用Hive構(gòu)建的數(shù)據(jù)倉庫中。Hive提供了類SQL的語言來與MapReduce結(jié)合，創(chuàng)建并發(fā)布多種摘要和報告，以及在它們的基礎上進行歷史分析。Hive上基于瀏覽器的接口允許用戶執(zhí)行Hive查詢。Oracle和MySQL數(shù)據(jù)庫用來發(fā)布這些摘要，這些數(shù)據(jù)容量相對較小，但查詢頻率較高并需要實時響應。一些舊的數(shù)據(jù)需要及時歸檔，并存儲在較便宜的存儲器上。

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

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

Facebook的數(shù)據(jù)倉庫使用Hive，這里HDFS支持三種文件格式：文本文件(TextFile)，方便其他應用程序讀寫;順序文件(SequenceFile)，只有Hadoop能夠讀取并支持分塊壓縮;RCFile，使用順序文件基于塊的存儲方式，每個塊按列存儲，這樣有較好的壓縮率和查詢性能。Facebook未來會在Hive上進行改進，以支持索引、視圖、子查詢等新功能。

現(xiàn)在Facebook使用Hadoop遇到的挑戰(zhàn)有：

服務質(zhì)量和隔離性方面，較大的任務會影響集群性能;

安全性方面，如果軟件漏洞導致NameNode事務日志崩潰該如何處理;

數(shù)據(jù)歸檔方面，如何選擇歸檔數(shù)據(jù)，以及數(shù)據(jù)如何歸檔;

性能提升方面，如何有效地解決瓶頸等。

解決Namenode頑疾

Google在2004年創(chuàng)造了MapReduce，MapReduce系統(tǒng)獲得成功的原因之一是它為編寫需要大規(guī)模并行處理的代碼提供了簡單的編程模式。MapReduce集群可包括數(shù)以千計的并行操作的計算機。同時MapReduce允許程序員在如此龐大的集群中快速的轉(zhuǎn)換數(shù)據(jù)并執(zhí)行數(shù)據(jù)。它受到了Lisp的函數(shù)編程特性和其他函數(shù)式語言的啟發(fā)。MapReduce和云計算非常相配。MapReduce的關(guān)鍵特點是它能夠?qū)﹂_發(fā)人員隱藏操作并行語義 — 并行編程的具體工作方式。

HDFS（Hadoop Distributed Filesystem）是專為MapReduce框架而下大規(guī)模分布式數(shù)據(jù)處理而設計的，HDFS可將大數(shù)據(jù)集（TB級）存儲為單個文件，而大多文件系統(tǒng)并不具備這樣的能力。（編者注：NTFS5 Max Files on Volume：264 bytes (16 ExaBytes) minus 1KB，1EB = 1,000,000 TB）。這也是HDFS風靡全球的重要原因。

目前Facebook Hadoop集群內(nèi)的HDFS物理磁盤空間承載超過100PB的數(shù)據(jù)（分布在不同數(shù)據(jù)中心的100多個集群）。由于HDFS存儲著Hadoop應用需要處理的數(shù)據(jù)，因此優(yōu)化HDFS成為Facebook為用戶提供高效、可靠服務至關(guān)重要的因素。

HDFS Namenode是如何工作的？

HDFS客戶端通過被稱之為Namenode單服務器節(jié)點執(zhí)行文件系統(tǒng)原數(shù)據(jù)操作，同時DataNode會與其他DataNode進行通信并復制數(shù)據(jù)塊以實現(xiàn)冗余，這樣單一的DataNode損壞不會導致集群的數(shù)據(jù)丟失。

但NameNode出現(xiàn)故障的損失確是無法容忍的。NameNode主要職責是跟蹤文件如何被分割成文件塊、文件塊又被哪些節(jié)點存儲，以及分布式文件系統(tǒng)的整體運行狀態(tài)是否正常等。但如果NameNode節(jié)點停止運行的話將會導致數(shù)據(jù)節(jié)點無法通信，客戶端無法讀取和寫入數(shù)據(jù)到HDFS，實際上這也將導致整個系統(tǒng)停止工作。

The HDFS Namenode is a single point of failure (SPOF)

Facebook也深知“Namenode-as-SPOF”所帶來問題的嚴重性，所以Facebook希望建立一套系統(tǒng)已破除“Namenode-as-SPOF”帶來的隱患。但在了解這套系統(tǒng)之前，首先來看一下Facebook在使用和部署HDFS都遇到了哪些問題。

Facebook數(shù)據(jù)倉庫的使用情況

在Facebook的數(shù)據(jù)倉庫中部署著最大的HDFS集群，數(shù)據(jù)倉庫的使用情況是傳統(tǒng)的Hadoop MapReduce工作負載——在大型集群中一小部分運行MapReduce批處理作業(yè)

因為集群非常龐大，客戶端和眾多DataNode節(jié)點與NameNode節(jié)點傳輸海量的原數(shù)據(jù)，這導致NameNode的負載非常沉重。而來自CPU、內(nèi)存、磁盤和網(wǎng)絡帶來的壓力也使得數(shù)據(jù)倉庫集群中NameNode高負載狀況屢見不鮮。在使用過程中Facebook發(fā)現(xiàn)其數(shù)據(jù)倉庫中由于HDFS引發(fā)的故障占總故障率的41%。

HDFS NameNode是HDFS中的重要組成部分，同時也是整個數(shù)據(jù)倉庫中的重要組成部分。雖然高可用的NameNode只可以預防數(shù)據(jù)倉庫10%的計劃外停機，不過消除NameNode對于SPOF來說可謂是重大的勝利，因為這使得Facebook可執(zhí)行預訂的硬件和軟件回復。事實上，F(xiàn)acebook預計如果解決NameNode可消除集群50%的計劃停機時間。

那么高可用性NameNode是什么樣子的？它將如何工作？讓我們來看一下高度可用性NameNode的圖表。

在此結(jié)構(gòu)中，客戶端可與Primary NameNode與Standby NameNode通信，同樣眾多DataNode

也具備給Primary NameNode與Standby NameNode發(fā)送block reports的能力。實質(zhì)上Facebook所研發(fā)的AvatarNode就是具備高可用NameNode的解決方案。

Avatarnode：具備NameNode故障轉(zhuǎn)移的解決方案

為了解決單NameNode節(jié)點的設計缺陷，大約在兩年前Facebook開始在內(nèi)部使用AvatarNode工作。

同時AvatarNode提供了高可用性的NameNode以及熱故障切換和回滾功能，目前Facebook已經(jīng)將AvatarNode貢獻到了開源社區(qū)。經(jīng)過無數(shù)次的測試和Bug修復，AvatarNode目前已在Facebook最大的Hadoop數(shù)據(jù)倉庫中穩(wěn)定運行。在這里很大程度上要感謝Facebook的工程師Dmytro Molkov。

當發(fā)生故障時，AvatarNode的兩個高可用NameNode節(jié)點可手動故障轉(zhuǎn)移。AvatarNode將現(xiàn)有的NameNode代碼打包并放置在Zookeeper層。

AvatarNode的基本概念如下：

1.具備Primary NameNode與Standby NameNode

2.當前Master主機名保存在ZooKeeper之中

3.改進的DataNode發(fā)送block reports到Primary NameNode與Standby NameNode

4.改進的HDFS客戶端將在每個事物開始之前對Zookeeper進行檢查，如果失敗會轉(zhuǎn)移到另外的事務之中。同時如果AvatarNode故障轉(zhuǎn)移出現(xiàn)在寫入的過程中，AvatarNode的機制將允許保證完整的數(shù)據(jù)寫入。

Avatarnode客戶端

Avatarnode DataNode

或許有人會Facebook這一解決方案的名字感到好奇，這是因為Facebook的Hadoop工程師Dhruba Borthakur來到公司時正好是James Cameron《阿凡達》電影熱映時間。（我們應該感到慶幸，如果是1998年的話或許應該叫TitanicNode了）。

AvatarNode經(jīng)受住了Facebook內(nèi)部最苛刻的工作環(huán)境，未來Facebook將繼續(xù)大幅度改善AvatarNode的可靠性和HDFS集群的管理性。并整合與一般高可用性框架的整合，還將實現(xiàn)無人值守、自動化與安全故障轉(zhuǎn)移等特性。

Facebook已將自身使用的Hadoop與AvatarNode解決方案托管到GitHub。感興趣的朋友可下載研究。

當然不止Facebook在試圖解決Hadoop的缺陷，MapR和Cloudera的產(chǎn)品也具備相似的能力。