原文鏈接

1.? 背景介紹

談到分布式系統(tǒng)惋嚎，就不得不提到Google的三駕馬車(chē):GFS[1],MapReduce[2]和BigTable[3]杠氢。雖然Google沒(méi)有開(kāi)源這三個(gè)技術(shù)的實(shí)現(xiàn)源碼，但是基于這三篇開(kāi)源文檔, Nutch項(xiàng)目子項(xiàng)目之一的Yahoo資助的Hadoop分別實(shí)現(xiàn)了三個(gè)強(qiáng)有力的開(kāi)源產(chǎn)品：HDFS另伍，MapReduce和HBase鼻百。在大數(shù)據(jù)時(shí)代的背景下，許多公司都開(kāi)始采用Hadoop作為底層分布式系統(tǒng)摆尝，而Hadoop的開(kāi)源社區(qū)日益活躍温艇，Hadoop家族不斷發(fā)展壯大，已成為IT屆最炙手可熱的產(chǎn)品结榄。

本文將在簡(jiǎn)單介紹Hadoop主要成員的基礎(chǔ)上中贝，探討Hadoop在應(yīng)用中的改進(jìn)。

第一部分是對(duì)Hadoop誕生和現(xiàn)狀的簡(jiǎn)單描述臼朗。

第二部分將簡(jiǎn)單介紹hadoop的主要成員邻寿，主要包括他們的基本特性和優(yōu)勢(shì)蝎土。分別是分布式文件系統(tǒng)HDFS，NoSQL家族之一的HBase绣否，分布式并行編程方式MapReduce以及分布式協(xié)調(diào)器Zookeeper誊涯。

第三、四蒜撮、五部分分別介紹了Hadoop的不同改進(jìn)和使用暴构。按次序分別是facebook的實(shí)時(shí)化改進(jìn)，HadoopDB段磨，以及CoHadoop取逾。

最后是我的總結(jié)和體會(huì)。

如果對(duì)Hadoop的基本架構(gòu)和基礎(chǔ)知識(shí)熟悉苹支，可以從第三部分看起砾隅。

2.? 關(guān)于Hadoop

Hadoop本身起源于Apache Nutch項(xiàng)目，曾也是Lucene項(xiàng)目的一部分债蜜。從結(jié)構(gòu)化數(shù)據(jù)晴埂，到半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，從關(guān)系型數(shù)據(jù)庫(kù)到非結(jié)構(gòu)化數(shù)據(jù)庫(kù)（NoSQL）寻定，更高性能的并行計(jì)算/批處理能力和海量數(shù)據(jù)存儲(chǔ)成為現(xiàn)代主流IT公司的一致需求儒洛。

2.1? HDFS

HDFS，全稱(chēng)Hadoop Distributed Filesystem狼速，是Hadoop生態(tài)圈的分布式文件系統(tǒng)琅锻。分布式文件系統(tǒng)跨多臺(tái)計(jì)算機(jī)存儲(chǔ)文件，該系統(tǒng)架構(gòu)于網(wǎng)絡(luò)之上唐含，誕生即具備了網(wǎng)絡(luò)編程的復(fù)雜性浅浮，比普通磁盤(pán)文件系統(tǒng)更加復(fù)雜。

2.1.1? HDFS數(shù)據(jù)塊

HDFS以流式數(shù)據(jù)訪問(wèn)模式來(lái)存儲(chǔ)超大文件捷枯，運(yùn)行于商用硬件集群上滚秩。數(shù)據(jù)集通常由數(shù)據(jù)源生成或從數(shù)據(jù)源復(fù)制而來(lái)，接著長(zhǎng)時(shí)間在此數(shù)據(jù)集上進(jìn)行格類(lèi)分析處理淮捆。每次都將涉及該數(shù)據(jù)集的大部分?jǐn)?shù)據(jù)甚至全部郁油，因此讀取整個(gè)數(shù)據(jù)集的時(shí)間延遲比讀取第一條記錄時(shí)間的延遲更重要。而一次寫(xiě)入攀痊、多次讀取是最高效的訪問(wèn)模式桐腌。有一點(diǎn)要說(shuō)明的是，HDFS是為高數(shù)據(jù)吞吐量應(yīng)用優(yōu)化的苟径，而這可能會(huì)以高時(shí)間延遲為代價(jià)案站。

HDFS默認(rèn)的最基本的存儲(chǔ)單元是64M的數(shù)據(jù)塊(block)。HDFS的塊比磁盤(pán)塊(512字節(jié))大得多棘街，目的是為了最小化尋址開(kāi)銷(xiāo)蟆盐。HDFS上的文件也被劃分為多個(gè)分塊(chunk)承边，作為獨(dú)立存儲(chǔ)單元。與其他文件系統(tǒng)不同的是石挂，HDFS中小于一個(gè)塊大小的文件不會(huì)占據(jù)整個(gè)塊的空間博助。

塊抽象給分布式文件系統(tǒng)帶來(lái)的好處：

?? 文件的大小可以大于網(wǎng)絡(luò)中任意一個(gè)磁盤(pán)的容量。

?? 使用塊抽象而非整個(gè)文件作為存儲(chǔ)單元痹愚，大大簡(jiǎn)化了存儲(chǔ)子系統(tǒng)的設(shè)計(jì)富岳，同時(shí)也消除了對(duì)元數(shù)據(jù)的顧慮。

?? 塊非常適合用于數(shù)據(jù)備份進(jìn)而提供數(shù)據(jù)容錯(cuò)能力和可用性拯腮。

2.1.2?? Namenode和Datanode

namenode和datanode的管理者-工作者模式有點(diǎn)類(lèi)似主從架構(gòu)窖式。namenode對(duì)應(yīng)多個(gè)datanode。namenode管理文件系統(tǒng)的命名空間疾瓮，維護(hù)文件系統(tǒng)和內(nèi)部的文件及目錄脖镀。datanode是文件系統(tǒng)的真正工作節(jié)點(diǎn)，根據(jù)需要存儲(chǔ)并檢索數(shù)據(jù)塊（一般受namenode調(diào)度）狼电，并且定期向namenode發(fā)送它們所存儲(chǔ)的塊的列表。

namenode一旦掛掉弦蹂，文件系統(tǒng)的所有文件就丟失了肩碟，不知道如何根據(jù)datanode的塊來(lái)重建文件。因此凸椿，namenode的容錯(cuò)或者備份是很重要的晦譬。在HDFS中存在secondarynamenode（雖然不完全是個(gè)namenode的備份斩郎，更確切的是個(gè)輔助節(jié)點(diǎn)）周期性將元數(shù)據(jù)節(jié)點(diǎn)的命名控件鏡像文件和修改日志合并。

2.2? HBase

跟傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）基于行存儲(chǔ)不同，HBase是一個(gè)分布式的鼓蜒，在HDFS上開(kāi)發(fā)的面向列的分布式數(shù)據(jù)庫(kù)。HBase行中的列分成“列族”（column family）寂纪，所有的列族成員有相同的前綴枣宫。所有列族成員都一起存放在文件系統(tǒng)中。

2.2.1?? 與RDBMS比較

HBase通過(guò)在HDFS上提供隨機(jī)讀寫(xiě)來(lái)解決Hadoop不能處理的問(wèn)題网杆。HBase自底層設(shè)計(jì)開(kāi)始即聚焦于各種可伸縮性問(wèn)題：表可以很“高”羹饰，有數(shù)十億個(gè)數(shù)據(jù)行；也可以很“寬”碳却，有數(shù)百萬(wàn)個(gè)列队秩；水平分區(qū)并在上千個(gè)普通商用機(jī)節(jié)點(diǎn)上自動(dòng)復(fù)制。表的模式是物理存儲(chǔ)的直接反映昼浦，使系統(tǒng)有可能提高高效的數(shù)據(jù)結(jié)構(gòu)的序列化馍资、存儲(chǔ)和檢索。

而RDBMS是模式固定关噪、面向行的數(shù)據(jù)庫(kù)且具有ACID性質(zhì)和復(fù)雜的SQL查詢處理引擎鸟蟹，強(qiáng)調(diào)事物的強(qiáng)一致性（strong consistency）乌妙、參照完整性（referential integrity）、數(shù)據(jù)抽象與物理存儲(chǔ)層相對(duì)獨(dú)立戏锹，以及基于SQL語(yǔ)言的復(fù)雜查詢支持冠胯。

2.2.2?? HBase特性

簡(jiǎn)單列舉下HBase的關(guān)鍵特性。

?? 沒(méi)有真正的索引：行是順序存儲(chǔ)的锦针，每行中的列也是荠察，所以不存在索引膨脹的問(wèn)題，而且插入性能和表的大小有關(guān)奈搜。

?? 自動(dòng)分區(qū)：在表增長(zhǎng)的時(shí)候悉盆，表會(huì)自動(dòng)分裂成區(qū)域（region），并分布到可用的節(jié)點(diǎn)上馋吗。

?? 線性擴(kuò)展：對(duì)于新增加的節(jié)點(diǎn)焕盟，區(qū)域自動(dòng)重新進(jìn)行平衡，負(fù)載會(huì)均勻分布宏粤。

?? 容錯(cuò)：大量的節(jié)點(diǎn)意味著每個(gè)節(jié)點(diǎn)重要性并不突出脚翘，所以不用擔(dān)心節(jié)點(diǎn)失效問(wèn)題。

?? 批處理：與MapReduce的集成可以全并行地進(jìn)行分布式作業(yè)绍哎。

2.3? MapReduce

MapReduce是一種可用于數(shù)據(jù)處理的編程模型来农，是一個(gè)簡(jiǎn)單易用的軟件框架，基于它寫(xiě)出來(lái)的應(yīng)用程序能夠運(yùn)行在由上千個(gè)商用機(jī)器組成的大型集群上崇堰，并以一種可靠容錯(cuò)的方式并行處理上T級(jí)別的數(shù)據(jù)集沃于。

2.3.1 Map & Reduce

一個(gè)Map/Reduce 作業(yè)（job）通常會(huì)把輸入的數(shù)據(jù)集切分為若干獨(dú)立的數(shù)據(jù)塊，由 map任務(wù)以完全并行的方式處理它們海诲》庇ǎ框架會(huì)對(duì)map的輸出先進(jìn)行排序，然后把結(jié)果輸入給reduce任務(wù)特幔。通常作業(yè)的輸入和輸出都會(huì)被存儲(chǔ)在文件系統(tǒng)（一般為HDFS）中咨演。整個(gè)框架負(fù)責(zé)任務(wù)的調(diào)度和監(jiān)控（jobtracker協(xié)調(diào)作業(yè)的運(yùn)作，tasktracker運(yùn)行作業(yè)劃分后的任務(wù)）敬辣，以及重新執(zhí)行已經(jīng)失敗的任務(wù)雪标。

通常，Map/Reduce框架和分布式文件系統(tǒng)是運(yùn)行在一組相同的節(jié)點(diǎn)上的溉跃，也就是說(shuō)村刨，計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)通常在一起。這種配置允許框架在那些已經(jīng)存好數(shù)據(jù)的節(jié)點(diǎn)上高效地調(diào)度任務(wù)撰茎，這可以使整個(gè)集群的網(wǎng)絡(luò)帶寬被非常高效地利用嵌牺。

2.3.2 Matser/Slave架構(gòu)

Map/Reduce框架由一個(gè)單獨(dú)的master JobTracker 和每個(gè)集群節(jié)點(diǎn)一個(gè)slave TaskTracker共同組成。master負(fù)責(zé)調(diào)度構(gòu)成一個(gè)作業(yè)的所有任務(wù)，這些任務(wù)分布在不同的slave上逆粹，master監(jiān)控它們的執(zhí)行募疮，重新執(zhí)行已經(jīng)失敗的任務(wù)。而slave僅負(fù)責(zé)執(zhí)行由master指派的任務(wù)僻弹。

應(yīng)用程序至少應(yīng)該指明輸入/輸出的位置（路徑）阿浓，并通過(guò)實(shí)現(xiàn)合適的接口或抽象類(lèi)提供map和reduce函數(shù)。再加上其他作業(yè)的參數(shù)蹋绽，就構(gòu)成了作業(yè)配置（jobconfiguration）芭毙。然后，Hadoop的 job client提交作業(yè)（jar包/可執(zhí)行程序等）和配置信息給JobTracker卸耘，后者負(fù)責(zé)分發(fā)這些軟件和配置信息給slave退敦、調(diào)度任務(wù)并監(jiān)控它們的執(zhí)行，同時(shí)提供狀態(tài)和診斷信息給job-client蚣抗。

2.4? Zookeeper

Zookeeper是一個(gè)高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架侈百。簡(jiǎn)單的說(shuō)，就是個(gè)分布式協(xié)調(diào)器翰铡。它以主從的架構(gòu)钝域，基于Paxos算法實(shí)現(xiàn)，保證了分布式環(huán)境中數(shù)據(jù)的強(qiáng)一致性锭魔，也因此各種分布式開(kāi)源項(xiàng)目中都有它的身影网梢。

2.4.1? Zookeeper機(jī)制

Zookeeper的核心是一個(gè)精簡(jiǎn)的文件系統(tǒng)，它的原語(yǔ)操作是一組豐富的構(gòu)件（building block）赂毯，可用于實(shí)現(xiàn)很多協(xié)調(diào)數(shù)據(jù)結(jié)構(gòu)和協(xié)議，包括分布式隊(duì)列拣宰、分布式鎖和一組同級(jí)節(jié)點(diǎn)中的“領(lǐng)導(dǎo)者選舉”（leader election）党涕。

Zookeeper實(shí)現(xiàn)的是Paxos算法。Zookeeper集群?jiǎn)?dòng)后自動(dòng)進(jìn)行l(wèi)eader selection巡社，投票選出一臺(tái)機(jī)器作為L(zhǎng)eader膛堤，其他的都是Follower。通過(guò)heartbeat的機(jī)制晌该，F(xiàn)ollower從Leader獲取命令或者消息肥荔，同步自己的數(shù)據(jù)，和Leader保持一致朝群。為了保證數(shù)據(jù)的一致性燕耿，只有當(dāng)半數(shù)以上的Follower的狀態(tài)和Leader成功同步了之后，才認(rèn)為這次數(shù)據(jù)更新是成功的姜胖。為了選舉方便誉帅，Zookeeper集群數(shù)目是奇數(shù)。

3. Hadoop在Facebook變得實(shí)時(shí)[4]

論文主要解釋了Facebook引進(jìn)Hadoop的原因。結(jié)合自己的需求蚜锨，F(xiàn)acebook對(duì)hadoop進(jìn)行了更實(shí)時(shí)的改進(jìn)档插。

3.1? HDFS與MySQL的性能互補(bǔ)

HDFS適合大塊地讀取數(shù)據(jù)（推薦節(jié)點(diǎn)是64M），它關(guān)于隨機(jī)讀取的工作的accesslatency比較大亚再，所以一般會(huì)用大規(guī)模的MySQL集群結(jié)合memcached這樣的緩存工具來(lái)做處理郭膛。在Facebook中，從Hadoop中產(chǎn)生的類(lèi)似中間結(jié)果的數(shù)據(jù)會(huì)裝載到MySQL集群或者memcached中去氛悬，用來(lái)被web層使用则剃。

同時(shí)，HDFS的順序讀取性能很好圆雁。Facebook需求寫(xiě)方面的高吞吐量忍级，代價(jià)低的彈性存儲(chǔ)，同時(shí)要求低延遲和硬盤(pán)上高效的順序和隨機(jī)讀取伪朽。MySQL存儲(chǔ)引擎被證明有比較高的隨機(jī)讀取能力轴咱，但是隨機(jī)寫(xiě)吞吐率比較差。因此烈涮，F(xiàn)acebook決定采用Hadoop和HBase來(lái)平衡順序和隨機(jī)讀取的性能朴肺，而不是只采用MySQL集群來(lái)不斷嘗試一種難以把握的balance。具體Facebook的需求將在下一節(jié)仔細(xì)剖析坚洽。

3.2??Facebook需求

Facebook認(rèn)為戈稿，用他們已有的基于MySQL集群的一些解決方案來(lái)處理問(wèn)題已經(jīng)遇到了瓶頸。之前的用例對(duì)工作量的擴(kuò)展是有挑戰(zhàn)性的讶舰。在一個(gè)RDBMS的環(huán)境下解決非常高的寫(xiě)吞吐量鞍盗，大數(shù)據(jù)，不可預(yù)測(cè)增長(zhǎng)及其他問(wèn)題變得十分困難跳昼。

3.3? 選擇Hadoop和HBase原因

采用Hadoop和HBase來(lái)解決以上需求的存儲(chǔ)系統(tǒng)方案的原因可以總結(jié)為以下幾點(diǎn)：

?? 彈性：需要能夠用最小的開(kāi)銷(xiāo)和零宕機(jī)修復(fù)時(shí)間來(lái)對(duì)存儲(chǔ)系統(tǒng)增量式地?cái)U(kuò)容般甲。這里的擴(kuò)容應(yīng)該指的是可以比較方便地實(shí)時(shí)增加服務(wù)器臺(tái)數(shù)來(lái)應(yīng)對(duì)一些高峰或者突發(fā)服務(wù)需求。

?? 高的寫(xiě)吞吐量

?? 高效的硬盤(pán)隨機(jī)讀寫(xiě)

?? 高可用性和容災(zāi)

?? 錯(cuò)誤隔離：當(dāng)局部數(shù)據(jù)庫(kù)掛掉或者服務(wù)器不能提供服務(wù)的時(shí)候鹅颊，讓最少的用戶受到影響敷存。HDFS應(yīng)對(duì)這樣的場(chǎng)景還是很不錯(cuò)的。

?? 讀寫(xiě)改的原子性：底層存儲(chǔ)系統(tǒng)針對(duì)高并發(fā)量的需求

?? 范圍掃描：指特定場(chǎng)景下高效獲取一個(gè)范圍結(jié)果集堪伍。

HBase已經(jīng)以key-value存儲(chǔ)的方式提供了高一致性的高寫(xiě)吞吐锚烦，且在大規(guī)模數(shù)據(jù)傳送和快速隨機(jī)寫(xiě)以及流式讀方面表現(xiàn)優(yōu)異。它同時(shí)保證了行層次的原子性帝雇。從數(shù)據(jù)模型的角度看涮俄，面向列的實(shí)現(xiàn)給數(shù)據(jù)存儲(chǔ)帶來(lái)了極高的靈活性，“寬”行允許在一個(gè)table內(nèi)存放百萬(wàn)數(shù)量級(jí)的被索引的值摊求。

雖然HDFS的核心namenode的宕機(jī)會(huì)帶來(lái)巨大影響禽拔，但是Facebook有信心打造一個(gè)在合理時(shí)限內(nèi)的高可用的NameNode刘离。根據(jù)一些實(shí)踐測(cè)試，F(xiàn)acebook對(duì)HDFS進(jìn)行了設(shè)計(jì)和改進(jìn)睹栖，主要針對(duì)namenode硫惕。將在下節(jié)展開(kāi)。

3.4? 實(shí)時(shí)HDFS

HDFS剛開(kāi)始是為了支持MapReduce這樣的并行應(yīng)用的數(shù)據(jù)存取的野来，是面向批處理系統(tǒng)的恼除，所以在實(shí)時(shí)方面講本身可能是存在不足的。Facebook主要改造在于一個(gè)高可用的AvatarNode曼氛。

我們知道HDFS的namenode一旦掛掉豁辉，整個(gè)集群就得等到namenode再次啟動(dòng)才能繼續(xù)運(yùn)行提供服務(wù)，所以需要這個(gè)熱備份——AvatarNode的設(shè)計(jì)舀患。在HDFS啟動(dòng)的時(shí)候徽级，namenode是從一個(gè)叫fsimage的文件里讀取文件系統(tǒng)的元數(shù)據(jù)的。元數(shù)據(jù)信息包括了HDFS上所有文件和目錄的名字和元數(shù)據(jù)聊浅。但是namenode不會(huì)持續(xù)地去存每一塊block的位置信息餐抢。所以冷啟動(dòng)namenode的時(shí)候包括兩部分：首先讀文件系統(tǒng)鏡像；然后低匙，大部分datanode匯報(bào)進(jìn)程上的block信息旷痕，以此來(lái)恢復(fù)集群上每一塊已知block的位置信息。這樣的冷啟動(dòng)會(huì)花很長(zhǎng)時(shí)間顽冶。

雖然一個(gè)備用的可用node可以避免failover時(shí)候去讀磁盤(pán)上的fsimage欺抗，但是依然需要從datanodes里獲取block信息。所以强重，時(shí)間相對(duì)還是偏長(zhǎng)绞呈。于是誕生了AvatarNode。

如圖所示间景。HDFS擁有兩個(gè)AvatarNode——Active AvatarNode和Standby AvatarNode报强。他們形成了一對(duì)“主被動(dòng)熱備份”（active-passive-hot-standby）。AvatarNode是對(duì)NameNode的包裝拱燃。Facebook的HDFS集群都采用NFS來(lái)存一份文件系統(tǒng)鏡像的備份和一份事物日志的備份。Active AvatarNode把自己處理的事務(wù)寫(xiě)進(jìn)NFS里的事務(wù)日志力惯。同時(shí)碗誉，StandbyAvatarNode打開(kāi)NFS上同一份事務(wù)日志，然后在自己的命名空間內(nèi)開(kāi)始執(zhí)行事務(wù)父晶，以保證自己的命名空間盡可能和初始信息接近哮缺。Standby AvatarNode同時(shí)照顧到初始信息的核查并創(chuàng)建新的文件系統(tǒng)鏡像，和HDFS相比就沒(méi)有了分離的SecondNameNode甲喝。

Datanodes同時(shí)和兩個(gè)AvatarNode交流尝苇。這保證了Standby處也獲得到最新的block狀態(tài)信息，以在分鐘時(shí)間級(jí)內(nèi)轉(zhuǎn)化成為Activer的Node（之前說(shuō)namenode的冷啟動(dòng)的時(shí)長(zhǎng)問(wèn)題可以解決了）。Avatar DataNode相互之間輸送心跳糠溜，block信息匯報(bào)和接受到的block淳玩。Avatar DataNodes集成了Zookeeper，因此他們知道主節(jié)點(diǎn)信息非竿，會(huì)執(zhí)行主節(jié)點(diǎn)發(fā)送的復(fù)制/刪除命令（基于Zookeeper的leader selection和heartbeat機(jī)制）蜕着，而來(lái)自Standby AvatarNode的復(fù)制/刪除請(qǐng)求是忽略的。

對(duì)于事務(wù)日志的記錄红柱，還進(jìn)行了一些改進(jìn)承匣。

i.?? 為了讓故障和失效盡可能透明，Standby必須知道失效發(fā)生時(shí)的block位置信息锤悄，所以對(duì)每一塊block分配記錄一個(gè)額外的記錄日志韧骗。這樣允許客戶端在發(fā)生失效的時(shí)刻前還是一直在寫(xiě)文件。

ii.? 當(dāng)Standby向正在被Active寫(xiě)事務(wù)記錄的日志里讀取事務(wù)信息的時(shí)候零聚，有可能讀到的是一個(gè)局部的事務(wù)袍暴。為了避免這樣的問(wèn)題，給每個(gè)要寫(xiě)進(jìn)日志里的事務(wù)增加記錄事務(wù)長(zhǎng)度信息握牧，事務(wù)id和校驗(yàn)和容诬。

要了解更具體的信息，可以從原paper中獲得更多具體的情況沿腰。

4.? HadoopDB[6]

HadoopDB簡(jiǎn)單介紹下設(shè)計(jì)理念和他的架構(gòu)览徒。

4.1 HadoopDB理念

HadoopDB是一個(gè)混合系統(tǒng)∷塘基本思想是用MapReduce作為與正在運(yùn)行著單節(jié)點(diǎn)DBMS實(shí)例的多樣化節(jié)點(diǎn)的通信層习蓬。查詢語(yǔ)言用SQL表示，并用現(xiàn)有工具翻譯成MapReduce可以接受的語(yǔ)言措嵌，使得盡可能多的任務(wù)可以被推送到每個(gè)高性能的單節(jié)點(diǎn)數(shù)據(jù)庫(kù)上躲叼。這樣基于MapReduce的并行化的數(shù)據(jù)庫(kù)代價(jià)幾乎是零。因?yàn)镸apReduce是現(xiàn)有的企巢。

HadoopDB背后的一些主要思想包括以下兩個(gè)關(guān)鍵字：share-nothing MPP架構(gòu)和parallel databases枫慷。

4.2 HadoopDB架構(gòu)介紹

作為一個(gè)混合的系統(tǒng)，讓我們看看HadoopDB由哪些部分構(gòu)成：HDFS浪规，MapReduce或听，SMS Planner，DB Connector等等笋婿。HadoopDB的核心框架還是Hadoop誉裆，具體就是存儲(chǔ)層HDFS，和處理層MapReduce缸濒。關(guān)于HDFS上namenode足丢，datanode各自處理任務(wù)粱腻，數(shù)據(jù)備份存儲(chǔ)機(jī)制以及MapReduce內(nèi)master-slave架構(gòu)，jobtracker和tasktracker各自的工作機(jī)制和任務(wù)負(fù)載分配斩跌，數(shù)據(jù)本地化特性等內(nèi)容就不詳細(xì)說(shuō)了绍些。下面對(duì)主要構(gòu)成部件做簡(jiǎn)單介紹：

1.??? Databae Connector：承擔(dān)的是node上獨(dú)立數(shù)據(jù)庫(kù)系統(tǒng)和TaskTracker之間的接口。圖中可以看到每個(gè)single的數(shù)據(jù)庫(kù)都關(guān)聯(lián)一個(gè)datanode和一個(gè)tasktracker滔驶。他傳輸SQL語(yǔ)句遇革，得到一些KV返回值。擴(kuò)展了Hadoop的InputFormat揭糕，使得與MapReduce框架實(shí)現(xiàn)無(wú)縫拼接萝快。

2.??? Catalog：維持?jǐn)?shù)據(jù)庫(kù)的元數(shù)據(jù)信息。包括兩部分：數(shù)據(jù)庫(kù)的連接參數(shù)和元數(shù)據(jù)著角，如集群中的數(shù)據(jù)集揪漩，復(fù)本位置，數(shù)據(jù)分區(qū)屬性±艨冢現(xiàn)在是以XML來(lái)記錄這些元數(shù)據(jù)信息的奄容。由JobTracker和TaskTracker在必要的時(shí)候來(lái)獲取相應(yīng)信息。

3.??? Data Loader：主要職責(zé)涉及根據(jù)給定的分區(qū)key來(lái)裝載數(shù)據(jù)产徊，對(duì)數(shù)據(jù)進(jìn)行分區(qū)昂勒。包含自身兩個(gè)主要Hasher：Global Hasher和Local Hasher。簡(jiǎn)單地說(shuō)舟铜，Hasher無(wú)非是為了讓分區(qū)更加均衡戈盈。

4.??? SMS Planner：SMS是SQL to MapReduce to SQL的縮寫(xiě)。HadoopDB通過(guò)使他們能執(zhí)行SQL請(qǐng)求來(lái)提供一個(gè)并行化數(shù)據(jù)庫(kù)前端做數(shù)據(jù)處理谆刨。SMS是擴(kuò)展了Hive塘娶。關(guān)于Hive我在這里不展開(kāi)介紹了∪玻總之是關(guān)于一種融入到MapReduce job內(nèi)的SQL的變種語(yǔ)言刁岸，來(lái)連接HDFS內(nèi)存放文件的table∷遥可以貼個(gè)圖看下虹曙。不詳細(xì)說(shuō)了。

5.? CoHadoop[7]

論文提出CoHadoop來(lái)解決Hadoop無(wú)法把相關(guān)的數(shù)據(jù)定位到同一個(gè)node集合下的性能瓶頸番舆。CoHadoop是對(duì)Hadoop的一個(gè)輕量級(jí)擴(kuò)展根吁，目的是允許應(yīng)用層能控制數(shù)據(jù)的存儲(chǔ)。應(yīng)用層通過(guò)某種方式提示CoHadoop某些集合里的文件是相關(guān)性比較大的合蔽，可能需要合并，之后CoHadoop就嘗試去轉(zhuǎn)移這些文件以提高一定的數(shù)據(jù)讀取效率介返。

5.1? 研究意義

Hadoop++[6]項(xiàng)目其實(shí)也做過(guò)類(lèi)似的事拴事，它將同一個(gè)job產(chǎn)生的兩個(gè)file共同放置沃斤，但是當(dāng)有新文件注入系統(tǒng)的時(shí)候，它需要對(duì)數(shù)據(jù)重新組織刃宵。

CoHadoop的改進(jìn)主要給以下幾個(gè)操作帶來(lái)了比較大的好處：索引（indexing）衡瓶，聚合（grouping），聚集（aggregation）牲证，縱向存儲(chǔ)（columnar storage）哮针，合并（join）以及sessionization。而像日志分析這樣的操作坦袍，涉及到的就是把一些參考數(shù)據(jù)合并起來(lái)或者進(jìn)行sessionization十厢。這可以體現(xiàn)CoHadoop的改進(jìn)意義所在。

以下是paper關(guān)于CoHadoop的總結(jié)：

?? 這是一種很靈活捂齐，動(dòng)態(tài)蛮放，輕量級(jí)的共置相關(guān)數(shù)據(jù)文件的方案，而且是直接在HDFS上實(shí)現(xiàn)的奠宜。

?? 在日志處理方面包颁，確定了兩個(gè)用例：join和sessionization，使得在查詢處理方面得到了顯著的性能提高压真。

?? 作者還研究了CoHadoop的容錯(cuò)娩嚼，分布式數(shù)據(jù)和數(shù)據(jù)丟失。

?? 在不同的場(chǎng)景下測(cè)試了join和sessionization的效果滴肿。

接下來(lái)還是介紹下CoHadoop的設(shè)計(jì)思想岳悟。

5.2? 改進(jìn)設(shè)計(jì)介紹

HDFS本身存數(shù)據(jù)的時(shí)候是有冗余的。默認(rèn)是存三分拷貝嘴高。這三份復(fù)制品會(huì)存在不同的地方竿音。最簡(jiǎn)單是存在datanode里。默認(rèn)的存放方式是第一份拷貝存在新建的本地誕生的node的block里（假設(shè)足夠存）拴驮，這叫寫(xiě)“親和”（write affinity）春瞬。HDFS然后選擇同一機(jī)架上的datanode存放第二個(gè)拷貝，選擇不同機(jī)架上的一個(gè)datanode存第三份拷貝套啤。這是HDFS的本來(lái)的機(jī)制宽气。那么為了實(shí)現(xiàn)相關(guān)數(shù)據(jù)的共置存儲(chǔ)，論文修改了存放策略潜沦。

以上Hadoop現(xiàn)有的存放策略主要是為了負(fù)載均衡萄涯，但是當(dāng)應(yīng)用需要從不同的文件里去取所需的數(shù)據(jù)的時(shí)候，如果能自定義一些策略唆鸡，那可能會(huì)得到顯著的提升涝影。輕量級(jí)的CoHadoop使得開(kāi)發(fā)自定義的策略變得簡(jiǎn)單。雖然分區(qū)在Hadoop里實(shí)現(xiàn)很簡(jiǎn)單争占，但是共置并不容易燃逻，Hadoop也沒(méi)有提供這樣類(lèi)似的可行性功能實(shí)現(xiàn)序目。

如圖是CoHadoop的數(shù)據(jù)存放示意圖。CoHadoop擴(kuò)展了HDFS伯襟，提出了新的文件層屬性——locator猿涨，并且修改了Hadoop的數(shù)據(jù)存放策略以使用這個(gè)locator。假設(shè)每個(gè)locator由一個(gè)整數(shù)值表示（也可以是別的表示方法）姆怪，那么文件和locator之間可以是一個(gè)N：1的關(guān)系叛赚。每個(gè)HDFS的文件最多和一個(gè)locator關(guān)聯(lián)，同一個(gè)locator可以關(guān)聯(lián)很多文件稽揭。同一個(gè)locator下的文件存在同一個(gè)datanode集合里俺附，而沒(méi)有l(wèi)ocator映射的文件依舊按照默認(rèn)的Hadoop的存儲(chǔ)機(jī)制存放。圖中的A和B就屬于同一個(gè)locator淀衣，A文件的兩塊block和B文件的三塊Block結(jié)果存在了同一個(gè)datanode集合里昙读。

為了更好地管理和跟蹤這些locator和文件之間的映射信息，設(shè)計(jì)了一個(gè)新的數(shù)據(jù)結(jié)構(gòu)——locatortable存在namenode里膨桥。它存放了每個(gè)locator映射的文件集蛮浑。圖中也可以看到。當(dāng)namenode運(yùn)行的時(shí)候只嚣，locator table是在內(nèi)存里動(dòng)態(tài)維護(hù)的沮稚，

關(guān)于數(shù)據(jù)存放策略的修改是這么做的：只要有一個(gè)新的和locator l關(guān)聯(lián)的文件f被創(chuàng)建，會(huì)去locator table里查詢是否存在一個(gè)實(shí)例是屬于這個(gè)locator l的册舞。如果不存在蕴掏，就新增一條（l, f）在table里，并用HDFS默認(rèn)的存放方式存這份文件的拷貝們调鲸。如果已經(jīng)存在盛杰，就可以知道這個(gè)l映射的file list，如果從現(xiàn)有的存放了這個(gè)list內(nèi)的文件的r個(gè)datanode里按一定方式（考慮空間）選出幾個(gè)用于存新來(lái)的文件的拷貝的節(jié)點(diǎn)藐石，存放這份文件的拷貝們即供。大致的意思就是這樣。

關(guān)于日志的join和sessionization的改進(jìn)于微，就不展開(kāi)了逗嫡。簡(jiǎn)單貼兩個(gè)圖。

做sessionization株依，對(duì)于日志處理時(shí)候MapReduce計(jì)算的影響比較驱证。

6.? 總結(jié)

雖然我對(duì)Hadoop有濃厚的興趣，但是自己所能接觸到的項(xiàng)目和環(huán)境恋腕，都沒(méi)有到達(dá)一個(gè)比較飽和的需求點(diǎn)抹锄。要做分布式存儲(chǔ)？根本用不著動(dòng)用HBase或者別的NoSQL組成的分布式集群，只需要一個(gè)分布式的MySQL集群就可以了伙单，NoSQL可以做的事呆万，其實(shí)MySQL何嘗不能完成？只是說(shuō)NoSQL對(duì)某些數(shù)據(jù)的存儲(chǔ)车份，在某些讀寫(xiě)性能上有局部的個(gè)性化的優(yōu)勢(shì)而已。更不必說(shuō)要用MapReduce去完成什么樣大規(guī)模牡彻，TB級(jí)數(shù)據(jù)的分布式并行計(jì)算了扫沼。在數(shù)據(jù)和硬件設(shè)施方面，以至到技術(shù)程度方面庄吼，學(xué)校里都沒(méi)有滿足條件缎除，沒(méi)有如此的需求。

學(xué)校的課程里也沒(méi)有涉及到分布式的內(nèi)容总寻。分布式文件系統(tǒng)/存儲(chǔ)/索引之類(lèi)的話題一直是存在于企業(yè)級(jí)別器罐，存在于大公司大數(shù)據(jù)基礎(chǔ)和服務(wù)器集群基礎(chǔ)的。學(xué)校里偶爾可以聽(tīng)到如阿里開(kāi)的關(guān)于分布式的講座渐行，也是很基礎(chǔ)的，淺嘗截止。

出生在什么樣的年代危队，就會(huì)接觸什么樣的技術(shù)宙枷。學(xué)習(xí)什么樣的技術(shù)，就能充實(shí)自己成什么樣的技術(shù)人才蕴忆。把握Hadoop颤芬，把握時(shí)代的核心技術(shù)，就掌握了現(xiàn)在大數(shù)據(jù)時(shí)代套鹅，甚至可以遇見(jiàn)并操控未來(lái)站蝠！

7.? 參考文獻(xiàn)和資料

[1] S. Ghemawat,H. Gobioff, and S.-T. Leung, “The google ?le system,” SIGOPS Oper. Syst. Rev.,vol. 37, no. 5, pp. 29–43, 2003.

[2] J. Dean and S.Ghemawat. MapReduce: Simpli?ed Data Processing on Large Clusters. In OSDI,2004.

[3] Bigtable: ADistributed Storage System for Structured Data. In OSDI, 2006.

[4] Apache HadoopGoes Realtime at Facebook. In SIGMOD, 2011.

[5] A. Abouzeidand et al. HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologiesfor Analytical Workloads. In VLDB, 2009.

[6] J. Dittrich etal. Hadoop++: Making a yellow elephant run like a cheetah (without it evennoticing). In VLDB, 2010.

[7] CoHadoop: Flexible Data Placementand Its Exploitation in Hadoop. In VLDB, 2011.

原文鏈接