Facebook中怎么實現Hadoop和AvatarNode集群

這篇文章給大家介紹Facebook中怎么實現Hadoop和AvatarNode集群，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

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

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

下面介紹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文件系統實現在現有文件系統的上層。

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

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

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

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

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

數據歸檔方面，如何選擇歸檔數據，以及數據如何歸檔;

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

解決Namenode頑疾

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

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

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

HDFS Namenode是如何工作的？

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

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

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

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

Facebook數據倉庫的使用情況

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

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

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

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

在此結構中，客戶端可與Primary NameNode與Standby NameNode通信，同樣眾多DataNode

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

Avatarnode：具備NameNode故障轉移的解決方案

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

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

當發生故障時，AvatarNode的兩個高可用NameNode節點可手動故障轉移。AvatarNode將現有的NameNode代碼打包并放置在Zookeeper層。

AvatarNode的基本概念如下：

1.具備Primary NameNode與Standby NameNode

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

3.改進的DataNode發送block reports到Primary NameNode與Standby NameNode

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

Avatarnode客戶端

關于Facebook中怎么實現Hadoop和AvatarNode集群就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。