納尼寞射?納尼渔工?納尼稀并?
1.什么是map的數(shù)據(jù)本地化優(yōu)化厨剪?
????Hadoop 在存儲有輸入數(shù)據(jù)(hdfs中的數(shù)據(jù))的節(jié)點上運行map任務(wù)澡为,可以獲得最佳性能烦粒,因為他無需使用寶貴的集群帶寬資源遭庶。這就是所謂的數(shù)據(jù)本地化優(yōu)化拐云,但是有時對于一個map任務(wù)的輸入分片來說颤殴,存儲該分片的hdfs數(shù)據(jù)塊副本的所有節(jié)點可能正在運行其他map任務(wù)杭跪,此時作業(yè)調(diào)度需要從某一數(shù)據(jù)塊所在的機架中的一個節(jié)點上尋找一個空閑的map槽(slot)來運行該map任務(wù)分片通惫。僅僅在非常偶然的情況下茂翔,會使用其他機架中的節(jié)點運行該map 任務(wù),這將導(dǎo)致機架與機架之間的網(wǎng)絡(luò)傳輸履腋。
2.為什么map最佳分片大小與塊大小相同珊燎?
3.map任務(wù)將其輸入寫入本地硬盤芦瘾,而非hdfs,這是為什么捌蚊?????因為它是確保可以存儲在單個節(jié)點上的最大輸入塊的大小遵湖,如果分片跨越兩個數(shù)據(jù)塊悔政,那么對于任何一個hdfs節(jié)點,基本上都不可能同時存儲這兩個數(shù)據(jù)塊延旧,因此分片中的部分數(shù)據(jù)需要通過網(wǎng)絡(luò)傳輸?shù)絤ap任務(wù)運行的節(jié)點谋国,與使用本地數(shù)據(jù)運行整個mao任務(wù)相比,這種方法顯然效率更低迁沫。
????因為map的輸出是中間結(jié)果,該中間結(jié)果由reduce任務(wù)處理后才產(chǎn)生最終輸出結(jié)果近弟,一旦完成缅糟,map的輸出結(jié)果就可以刪除。因此如果把他存儲在hdfs中并實現(xiàn)備份祷愉,難免有些小題大做窗宦。如果運行map任務(wù)的節(jié)點在將map中間結(jié)果傳送給reduce任務(wù)之前失敗,hadoop 將在另一個節(jié)點上重新運行這個map以再次構(gòu)建map中間結(jié)果二鳄。
5.hdfs 中塊進行抽象的好處是什么?? ??Hdfs 的塊比磁盤的塊大赴涵,其目的是為了最小化尋址開銷。如果塊足夠大泥从,從磁盤傳輸數(shù)據(jù)的時間會明顯大于定位這個塊開始位置所需的時間。因而沪摄,傳輸一個由多個塊組成的大文件的時間取決于磁盤傳輸速率躯嫉。
但是這個參數(shù)也不會設(shè)置的過大,mr中的map任務(wù)通常一次只處理一個塊中的數(shù)據(jù)杨拐,因此如果任務(wù)數(shù)太少祈餐,作業(yè)的運行速度就會比較慢。?
?>1 一個文件的大小可以大于網(wǎng)絡(luò)中任意一個磁盤的容量哄陶。文件的所有塊并不需要存儲在同一個磁盤上帆阳。
?>2 使用抽象塊而非整個文件作為存儲單元,大大簡化了存儲子系統(tǒng)的設(shè)計屋吨。對于故障種類繁多的分布式系統(tǒng)來說尤為重要
?>3 塊還非常適合用于數(shù)據(jù)備份進而提供數(shù)據(jù)容錯能力和提高可用性?
6.hadoop 對于namenode單點問題有哪些容錯機制蜒谤?
>1 備份那些組成文件系統(tǒng)運輸局持久狀態(tài)的文件,Hadoop 可以通過配置使namenode在多個文件系統(tǒng)上保存元數(shù)據(jù)的持久狀態(tài)至扰。這些寫操作是實時同步的鳍徽,且是原子操作。一般的配置是敢课,將持久狀態(tài)寫入本地磁盤的同時阶祭,寫入一個遠程掛載的網(wǎng)絡(luò)文件系統(tǒng)(NFS)。
?>2 運行一個輔助namenode,但它不能被用作namenode,這個輔助namenode的重要作用是定期合并編輯日志與命名空間鏡像直秆,以防止編輯日志過大濒募。這個輔助namenode 一般在另一臺單獨的物理計算機上運行,因為他需要占用大量cpu時間圾结,并且需要與namenode 一樣多的內(nèi)存執(zhí)行合并操作瑰剃。?
7.hadoop2 對hdfs 高可用(HA)是怎么做的?
????配置活動-備用(active-standby)namenode,當活動namenode失效筝野,備用namenode就會接管他的任務(wù)并開始服務(wù)與來自客戶端的請求培他,不會有任何明顯中斷鹃两。
?? ?1.namenode之間通過高可用共享存儲(NFS或QJM)實現(xiàn)編輯日志的共享,只有活動namenode才能對外提供讀寫服務(wù)舀凛,活動namenode把editlog寫入JN中俊扳,備用namenode從JN中獲取editlog合并到FsImage中,當備用的namenode接管工作之后猛遍,它將通讀共享編輯日志直至末尾馋记,以實現(xiàn)與活動namenode的狀態(tài)同步,并繼續(xù)讀取由活動namenode寫入的新條目懊烤。
? ? 2.datanode同時向namenode發(fā)送數(shù)據(jù)塊處理報告梯醒,因為數(shù)據(jù)塊的映射信息存儲在namenode的內(nèi)存里,而非磁盤腌紧。
? ? 3.客戶端需要使用特定的機制來處理namenode的失效問題茸习,這一機制對用戶是透明的
? ? 4.輔助namenode的角色被備用namenode所包含,備用namenode為活動namenode命名空間設(shè)置周期性檢查點
? ? 5.為了實現(xiàn)熱備壁肋,增加FailoverController(故障轉(zhuǎn)移控制器)和Zookeeper号胚,F(xiàn)ailoverController與Zookeeper通信,通過Zookeeper選舉機制浸遗,F(xiàn)ailoverController通過RPC讓NameNode轉(zhuǎn)換為Active或Standby猫胁。?
知識點:
NFS(Network File System 網(wǎng)絡(luò)文件系統(tǒng))
?? NFS作為active namenode和standby namenode之間數(shù)據(jù)共享的存儲。
?? active namenode會把最近的edits文件寫到NFS跛锌,而standby namenode從NFS中把數(shù)據(jù)讀過來弃秆。
???這個方式的缺點是,如果active或standby有一個和NFS之間網(wǎng)絡(luò)有問題髓帽,則會造成他們之前數(shù)據(jù)的同步出問題菠赚。并且不能保證同一時間只有一個namenode向NFS中寫入數(shù)據(jù)
QJM(Quorum Journal Manager 群體日志管理器)【目前hadoop2.x使用】
?? QJM是一個專用的HDFS實現(xiàn),提供了一個高可用的編輯日志郑藏。這種方式可以解決上述NFS容錯機制不足的問題锈至。
???同一時間QJM僅允許一個namenode向編輯日志中寫入數(shù)據(jù)。
故障轉(zhuǎn)移控制器(failover controller)译秦,管理著將活動namenode轉(zhuǎn)移為備用namenode的轉(zhuǎn)換過程峡捡。有多重故障轉(zhuǎn)移控制器,但默認的一種是使用了zookeeper來確保有且僅有一個活動namenode筑悴。每一個namenode運行著一個輕量級的故障轉(zhuǎn)移控制器们拙。其工作就是監(jiān)視宿主namenode是否失效(通過一個簡單的心跳機制實現(xiàn))并在namenode失效時進行故障轉(zhuǎn)移管理員也可以手動發(fā)起故障轉(zhuǎn)移,例如在日常維護時阁吝。
JN:active和standby之間是通過一組日志節(jié)點journal node(數(shù)量是奇數(shù)砚婆,可以是3,5,7...,2n+1)來共享數(shù)據(jù)。active把最近的edits文件寫到2n+1個journal node上,只要有n+1個寫入成功,就認為這次寫入操作成功了装盯。然后standby就可以從journalnode上讀取了坷虑。QJM方式有容錯的機制,可以容忍n個journalnode的失敗埂奈。??