這篇文章給大家介紹Facebook中怎么實(shí)現(xiàn)Hadoop和AvatarNode集群，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。
Facebook將數(shù)據(jù)存儲(chǔ)在利用Hadoop/Hive搭建的數(shù)據(jù)倉(cāng)庫(kù)上，這個(gè)數(shù)據(jù)倉(cāng)庫(kù)擁有4800個(gè)內(nèi)核，具有5.5PB的存儲(chǔ)量，每個(gè)節(jié)點(diǎn)可存儲(chǔ)12TB大小的數(shù)據(jù)，同時(shí)，它還具有兩層網(wǎng)絡(luò)拓?fù)洹acebook中的MapReduce集群是動(dòng)態(tài)變化的，它基于負(fù)載情況和集群節(jié)點(diǎn)之間的配置信息可動(dòng)態(tài)移動(dòng)。
Facebook的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)，在這個(gè)架構(gòu)中，網(wǎng)絡(luò)服務(wù)器和內(nèi)部服務(wù)生成日志數(shù)據(jù)，這里Facebook使用開源日志收集系統(tǒng)，它可以將數(shù)以百計(jì)的日志數(shù)據(jù)集存儲(chǔ)在NFS服務(wù)器上，但大部分日志數(shù)據(jù)會(huì)復(fù)制到同一個(gè)中心的HDFS實(shí)例中，而HDFS存儲(chǔ)的數(shù)據(jù)都會(huì)放到利用Hive構(gòu)建的數(shù)據(jù)倉(cāng)庫(kù)中。Hive提供了類SQL的語(yǔ)言來(lái)與MapReduce結(jié)合，創(chuàng)建并發(fā)布多種摘要和報(bào)告，以及在它們的基礎(chǔ)上進(jìn)行歷史分析。Hive上基于瀏覽器的接口允許用戶執(zhí)行Hive查詢。Oracle和MySQL數(shù)據(jù)庫(kù)用來(lái)發(fā)布這些摘要，這些數(shù)據(jù)容量相對(duì)較小，但查詢頻率較高并需要實(shí)時(shí)響應(yīng)。一些舊的數(shù)據(jù)需要及時(shí)歸檔，并存儲(chǔ)在較便宜的存儲(chǔ)器上。
下面介紹Facebook在AvatarNode和調(diào)度策略方面所做的一些工作。AvatarNode主要用于HDFS的恢復(fù)和啟動(dòng)，若HDFS崩潰，原有技術(shù)恢復(fù)首先需要花10～15分鐘來(lái)讀取12GB的文件鏡像并寫回，還要用20～30分鐘處理來(lái)自2000個(gè)DataNode的數(shù)據(jù)塊報(bào)告，最后用40～60分鐘來(lái)恢復(fù)崩潰的NameNode和部署軟件。表3-1說明了BackupNode和AvatarNode的區(qū)別，AvatarNode作為普通的NameNode啟動(dòng)，處理所有來(lái)自DataNode的消息。AvatarDataNode與DataNode相似，支持多線程和針對(duì)多個(gè)主節(jié)點(diǎn)的多隊(duì)列，但無(wú)法區(qū)分原始和備份。人工恢復(fù)使用AvatarShell命令行工具，AvatarShell執(zhí)行恢復(fù)操作并更新ZooKeeper的zNode，恢復(fù)過程對(duì)用戶來(lái)說是透明的。分布式Avatar文件系統(tǒng)實(shí)現(xiàn)在現(xiàn)有文件系統(tǒng)的上層。
基于位置的調(diào)度策略在實(shí)際應(yīng)用中存在著一些問題：如需要高內(nèi)存的任務(wù)可能會(huì)被分配給擁有低內(nèi)存的TaskTracker;CPU資源有時(shí)未被充分利用;為不同硬件的TaskTracker進(jìn)行配置也比較困難等。Facebook采用基于資源的調(diào)度策略，即公平享有調(diào)度方法，實(shí)時(shí)監(jiān)測(cè)系統(tǒng)并收集CPU和內(nèi)存的使用情況，調(diào)度器會(huì)分析實(shí)時(shí)的內(nèi)存消耗情況，然后在任務(wù)之間公平分配任務(wù)的內(nèi)存使用量。它通過讀取/proc/目錄解析進(jìn)程樹，并收集進(jìn)程樹上所有的CPU和內(nèi)存的使用信息，然后通過TaskCounters在心跳(heartbeat)時(shí)發(fā)送信息。
Facebook的數(shù)據(jù)倉(cāng)庫(kù)使用Hive，這里HDFS支持三種文件格式：文本文件(TextFile)，方便其他應(yīng)用程序讀寫;順序文件(SequenceFile)，只有Hadoop能夠讀取并支持分塊壓縮;RCFile，使用順序文件基于塊的存儲(chǔ)方式，每個(gè)塊按列存儲(chǔ)，這樣有較好的壓縮率和查詢性能。Facebook未來(lái)會(huì)在Hive上進(jìn)行改進(jìn)，以支持索引、視圖、子查詢等新功能。
現(xiàn)在Facebook使用Hadoop遇到的挑戰(zhàn)有：
服務(wù)質(zhì)量和隔離性方面，較大的任務(wù)會(huì)影響集群性能;
安全性方面，如果軟件漏洞導(dǎo)致NameNode事務(wù)日志崩潰該如何處理;
數(shù)據(jù)歸檔方面，如何選擇歸檔數(shù)據(jù)，以及數(shù)據(jù)如何歸檔;
性能提升方面，如何有效地解決瓶頸等。
解決Namenode頑疾
Google在2004年創(chuàng)造了MapReduce，MapReduce系統(tǒng)獲得成功的原因之一是它為編寫需要大規(guī)模并行處理的代碼提供了簡(jiǎn)單的編程模式。MapReduce集群可包括數(shù)以千計(jì)的并行操作的計(jì)算機(jī)。同時(shí)MapReduce允許程序員在如此龐大的集群中快速的轉(zhuǎn)換數(shù)據(jù)并執(zhí)行數(shù)據(jù)。它受到了Lisp的函數(shù)編程特性和其他函數(shù)式語(yǔ)言的啟發(fā)。MapReduce和云計(jì)算非常相配。MapReduce的關(guān)鍵特點(diǎn)是它能夠?qū)﹂_發(fā)人員隱藏操作并行語(yǔ)義 — 并行編程的具體工作方式。
HDFS（Hadoop Distributed Filesystem）是專為MapReduce框架而下大規(guī)模分布式數(shù)據(jù)處理而設(shè)計(jì)的，HDFS可將大數(shù)據(jù)集（TB級(jí)）存儲(chǔ)為單個(gè)文件，而大多文件系統(tǒng)并不具備這樣的能力。（編者注：NTFS5 Max Files on Volume：264 bytes (16 ExaBytes) minus 1KB，1EB = 1,000,000 TB）。這也是HDFS風(fēng)靡全球的重要原因。
目前Facebook Hadoop集群內(nèi)的HDFS物理磁盤空間承載超過100PB的數(shù)據(jù)（分布在不同數(shù)據(jù)中心的100多個(gè)集群）。由于HDFS存儲(chǔ)著Hadoop應(yīng)用需要處理的數(shù)據(jù)，因此優(yōu)化HDFS成為Facebook為用戶提供高效、可靠服務(wù)至關(guān)重要的因素。
HDFS Namenode是如何工作的？
HDFS客戶端通過被稱之為Namenode單服務(wù)器節(jié)點(diǎn)執(zhí)行文件系統(tǒng)原數(shù)據(jù)操作，同時(shí)DataNode會(huì)與其他DataNode進(jìn)行通信并復(fù)制數(shù)據(jù)塊以實(shí)現(xiàn)冗余，這樣單一的DataNode損壞不會(huì)導(dǎo)致集群的數(shù)據(jù)丟失。
但NameNode出現(xiàn)故障的損失確是無(wú)法容忍的。NameNode主要職責(zé)是跟蹤文件如何被分割成文件塊、文件塊又被哪些節(jié)點(diǎn)存儲(chǔ)，以及分布式文件系統(tǒng)的整體運(yùn)行狀態(tài)是否正常等。但如果NameNode節(jié)點(diǎn)停止運(yùn)行的話將會(huì)導(dǎo)致數(shù)據(jù)節(jié)點(diǎn)無(wú)法通信，客戶端無(wú)法讀取和寫入數(shù)據(jù)到HDFS，實(shí)際上這也將導(dǎo)致整個(gè)系統(tǒng)停止工作。
The HDFS Namenode is a single point of failure (SPOF)
Facebook也深知“Namenode-as-SPOF”所帶來(lái)問題的嚴(yán)重性，所以Facebook希望建立一套系統(tǒng)已破除“Namenode-as-SPOF”帶來(lái)的隱患。但在了解這套系統(tǒng)之前，首先來(lái)看一下Facebook在使用和部署HDFS都遇到了哪些問題。
Facebook數(shù)據(jù)倉(cāng)庫(kù)的使用情況
在Facebook的數(shù)據(jù)倉(cāng)庫(kù)中部署著較大的HDFS集群，數(shù)據(jù)倉(cāng)庫(kù)的使用情況是傳統(tǒng)的Hadoop MapReduce工作負(fù)載——在大型集群中一小部分運(yùn)行MapReduce批處理作業(yè)
因?yàn)榧悍浅｝嫶?，客戶端和眾多DataNode節(jié)點(diǎn)與NameNode節(jié)點(diǎn)傳輸海量的原數(shù)據(jù)，這導(dǎo)致NameNode的負(fù)載非常沉重。而來(lái)自CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)帶來(lái)的壓力也使得數(shù)據(jù)倉(cāng)庫(kù)集群中NameNode高負(fù)載狀況屢見不鮮。在使用過程中Facebook發(fā)現(xiàn)其數(shù)據(jù)倉(cāng)庫(kù)中由于HDFS引發(fā)的故障占總故障率的41%。
HDFS NameNode是HDFS中的重要組成部分，同時(shí)也是整個(gè)數(shù)據(jù)倉(cāng)庫(kù)中的重要組成部分。雖然高可用的NameNode只可以預(yù)防數(shù)據(jù)倉(cāng)庫(kù)10%的計(jì)劃外停機(jī)，不過消除NameNode對(duì)于SPOF來(lái)說可謂是重大的勝利，因?yàn)檫@使得Facebook可執(zhí)行預(yù)訂的硬件和軟件回復(fù)。事實(shí)上，F(xiàn)acebook預(yù)計(jì)如果解決NameNode可消除集群50%的計(jì)劃停機(jī)時(shí)間。
那么高可用性NameNode是什么樣子的？它將如何工作？讓我們來(lái)看一下高度可用性NameNode的圖表。
在此結(jié)構(gòu)中，客戶端可與Primary NameNode與Standby NameNode通信，同樣眾多DataNode
也具備給Primary NameNode與Standby NameNode發(fā)送block reports的能力。實(shí)質(zhì)上Facebook所研發(fā)的AvatarNode就是具備高可用NameNode的解決方案。
Avatarnode：具備NameNode故障轉(zhuǎn)移的解決方案
為了解決單NameNode節(jié)點(diǎn)的設(shè)計(jì)缺陷，大約在兩年前Facebook開始在內(nèi)部使用AvatarNode工作。
同時(shí)AvatarNode提供了高可用性的NameNode以及熱故障切換和回滾功能，目前Facebook已經(jīng)將AvatarNode貢獻(xiàn)到了開源社區(qū)。經(jīng)過無(wú)數(shù)次的測(cè)試和Bug修復(fù)，AvatarNode目前已在Facebook較大的Hadoop數(shù)據(jù)倉(cāng)庫(kù)中穩(wěn)定運(yùn)行。在這里很大程度上要感謝Facebook的工程師Dmytro Molkov。
當(dāng)發(fā)生故障時(shí)，AvatarNode的兩個(gè)高可用NameNode節(jié)點(diǎn)可手動(dòng)故障轉(zhuǎn)移。AvatarNode將現(xiàn)有的NameNode代碼打包并放置在Zookeeper層。
AvatarNode的基本概念如下：
1.具備Primary NameNode與Standby NameNode
2.當(dāng)前Master主機(jī)名保存在ZooKeeper之中
3.改進(jìn)的DataNode發(fā)送block reports到Primary NameNode與Standby NameNode
4.改進(jìn)的HDFS客戶端將在每個(gè)事物開始之前對(duì)Zookeeper進(jìn)行檢查，如果失敗會(huì)轉(zhuǎn)移到另外的事務(wù)之中。同時(shí)如果AvatarNode故障轉(zhuǎn)移出現(xiàn)在寫入的過程中，AvatarNode的機(jī)制將允許保證完整的數(shù)據(jù)寫入。
Avatarnode客戶端
關(guān)于Facebook中怎么實(shí)現(xiàn)Hadoop和AvatarNode集群就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
