Hadoop的分布式架構(gòu)改進(jìn)與應(yīng)用

Hadoop的分布式架構(gòu)改進(jìn)與應(yīng)用

1.背景介紹談到分布式系統(tǒng)，就不得不提到Google的三駕馬車:GFS[1],MapReduce[2]和BigTable[3]。雖然Google沒有開源這三個(gè)技術(shù)的實(shí)現(xiàn)源碼，但是基于這三篇開源文檔,Nutch項(xiàng)目子項(xiàng)目之一的Yahoo資助的Hadoop分別實(shí)現(xiàn)了三個(gè)強(qiáng)有力的開源產(chǎn)品：HDFS，MapReduce和HBase。在大數(shù)據(jù)時(shí)代的背景下，許多公司都開始采用Hadoop作為底層分布式系統(tǒng)，而Hadoop的開源社區(qū)日益活躍，Hadoop家族不斷發(fā)展壯大，已成為IT屆最炙手可熱的產(chǎn)品。本文將在簡單介紹Hadoop主要成員的基礎(chǔ)上，探討Hadoop在應(yīng)用中的改進(jìn)。第一部分是對Hadoop誕生和現(xiàn)狀的簡單描述。第二部分將簡單介紹hadoop的主要成員，主要包括他們的基本特性和優(yōu)勢。分別是分布式文件系統(tǒng)HDFS，NoSQL家族之一的HBase，分布式并行編程方式MapReduce以及分布式協(xié)調(diào)器Zookeeper。第三、四、五部分分別介紹了Hadoop的不同改進(jìn)和使用。按次序分別是facebook的實(shí)時(shí)化改進(jìn)，HadoopDB，以及CoHadoop。最后是我的總結(jié)和體會。如果對Hadoop的基本架構(gòu)和基礎(chǔ)知識熟悉，可以從第三部分看起。2.關(guān)于HadoopHadoop本身起源于ApacheNutch項(xiàng)目，曾也是Lucene項(xiàng)目的一部分。從結(jié)構(gòu)化數(shù)據(jù)，到半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，從關(guān)系型數(shù)據(jù)庫到非結(jié)構(gòu)化數(shù)據(jù)庫（NoSQL），更高性能的并行計(jì)算/批處理能力和海量數(shù)據(jù)存儲成為現(xiàn)代主流IT公司的一致需求。2.1HDFSHDFS，全稱HadoopDistributedFilesystem，是Hadoop生態(tài)圈的分布式文件系統(tǒng)。分布式文件系統(tǒng)跨多臺計(jì)算機(jī)存儲文件，該系統(tǒng)架構(gòu)于網(wǎng)絡(luò)之上，誕生即具備了網(wǎng)絡(luò)編程的復(fù)雜性，比普通磁盤文件系統(tǒng)更加復(fù)雜。2.1.1HDFS數(shù)據(jù)塊HDFS以流式數(shù)據(jù)訪問模式來存儲超大文件，運(yùn)行于商用硬件集群上。數(shù)據(jù)集通常由數(shù)據(jù)源生成或從數(shù)據(jù)源復(fù)制而來，接著長時(shí)間在此數(shù)據(jù)集上進(jìn)行格類分析處理。每次都將涉及該數(shù)據(jù)集的大部分?jǐn)?shù)據(jù)甚至全部，因此讀取整個(gè)數(shù)據(jù)集的時(shí)間延遲比讀取第一條記錄時(shí)間的延遲更重要。而一次寫入、多次讀取是最高效的訪問模式。有一點(diǎn)要說明的是，HDFS是為高數(shù)據(jù)吞吐量應(yīng)用優(yōu)化的，而這可能會以高時(shí)間延遲為代價(jià)。HDFS默認(rèn)的最基本的存儲單元是64M的數(shù)據(jù)塊(block)。HDFS的塊比磁盤塊(512字節(jié))大得多，目的是為了最小化尋址開銷。HDFS上的文件也被劃分為多個(gè)分塊(chunk)，作為獨(dú)立存儲單元。與其他文件系統(tǒng)不同的是，HDFS中小于一個(gè)塊大小的文件不會占據(jù)整個(gè)塊的空間。塊抽象給分布式文件系統(tǒng)帶來的好處：文件的大小可以大于網(wǎng)絡(luò)中任意一個(gè)磁盤的容量。使用塊抽象而非整個(gè)文件作為存儲單元，大大簡化了存儲子系統(tǒng)的設(shè)計(jì)，同時(shí)也消除了對元數(shù)據(jù)的顧慮。塊非常適合用于數(shù)據(jù)備份進(jìn)而提供數(shù)據(jù)容錯能力和可用性。2.1.2Namenode和Datanodenamenode和datanode的管理者-工作者模式有點(diǎn)類似主從架構(gòu)。namenode對應(yīng)多個(gè)datanode。namenode管理文件系統(tǒng)的命名空間，維護(hù)文件系統(tǒng)和內(nèi)部的文件及目錄。datanode是文件系統(tǒng)的真正工作節(jié)點(diǎn)，根據(jù)需要存儲并檢索數(shù)據(jù)塊（一般受namenode調(diào)度），并且定期向namenode發(fā)送它們所存儲的塊的列表。namenode一旦掛掉，文件系統(tǒng)的所有文件就丟失了，不知道如何根據(jù)datanode的塊來重建文件。因此，namenode的容錯或者備份是很重要的。在HDFS中存在secondarynamenode（雖然不完全是個(gè)namenode的備份，更確切的是個(gè)輔助節(jié)點(diǎn)）周期性將元數(shù)據(jù)節(jié)點(diǎn)的命名控件鏡像文件和修改日志合并。2.2HBase跟傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（RDBMS）基于行存儲不同，HBase是一個(gè)分布式的，在HDFS上開發(fā)的面向列的分布式數(shù)據(jù)庫。HBase行中的列分成“列族”（columnfamily），所有的列族成員有相同的前綴。所有列族成員都一起存放在文件系統(tǒng)中。2.2.1與RDBMS比較HBase通過在HDFS上提供隨機(jī)讀寫來解決Hadoop不能處理的問題。HBase自底層設(shè)計(jì)開始即聚焦于各種可伸縮性問題：表可以很“高”，有數(shù)十億個(gè)數(shù)據(jù)行；也可以很“寬”，有數(shù)百萬個(gè)列；水平分區(qū)并在上千個(gè)普通商用機(jī)節(jié)點(diǎn)上自動復(fù)制。表的模式是物理存儲的直接反映，使系統(tǒng)有可能提高高效的數(shù)據(jù)結(jié)構(gòu)的序列化、存儲和檢索。而RDBMS是模式固定、面向行的數(shù)據(jù)庫且具有ACID性質(zhì)和復(fù)雜的SQL查詢處理引擎，強(qiáng)調(diào)事物的強(qiáng)一致性（strongconsistency）、參照完整性（referentialintegrity）、數(shù)據(jù)抽象與物理存儲層相對獨(dú)立，以及基于SQL語言的復(fù)雜查詢支持。2.2.2HBase特性簡單列舉下HBase的關(guān)鍵特性。沒有真正的索引：行是順序存儲的，每行中的列也是，所以不存在索引膨脹的問題，而且插入性能和表的大小有關(guān)。自動分區(qū)：在表增長的時(shí)候，表會自動分裂成區(qū)域（region），并分布到可用的節(jié)點(diǎn)上。線性擴(kuò)展：對于新增加的節(jié)點(diǎn)，區(qū)域自動重新進(jìn)行平衡，負(fù)載會均勻分布。容錯：大量的節(jié)點(diǎn)意味著每個(gè)節(jié)點(diǎn)重要性并不突出，所以不用擔(dān)心節(jié)點(diǎn)失效問題。批處理：與MapReduce的集成可以全并行地進(jìn)行分布式作業(yè)。2.3MapReduceMapReduce是一種可用于數(shù)據(jù)處理的編程模型，是一個(gè)簡單易用的軟件框架，基于它寫出來的應(yīng)用程序能夠運(yùn)行在由上千個(gè)商用機(jī)器組成的大型集群上，并以一種可靠容錯的方式并行處理上T級別的數(shù)據(jù)集。2.3.1Map&Reduce一個(gè)Map/Reduce作業(yè)（job）通常會把輸入的數(shù)據(jù)集切分為若干獨(dú)立的數(shù)據(jù)塊，由map任務(wù)以完全并行的方式處理它們。框架會對map的輸出先進(jìn)行排序，然后把結(jié)果輸入給reduce任務(wù)。通常作業(yè)的輸入和輸出都會被存儲在文件系統(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)上的，也就是說，計(jì)算節(jié)點(diǎn)和存儲節(jié)點(diǎn)通常在一起。這種配置允許框架在那些已經(jīng)存好數(shù)據(jù)的節(jié)點(diǎn)上高效地調(diào)度任務(wù)，這可以使整個(gè)集群的網(wǎng)絡(luò)帶寬被非常高效地利用。2.3.2Matser/Slave架構(gòu)Map/Reduce框架由一個(gè)單獨(dú)的masterJobTracker和每個(gè)集群節(jié)點(diǎn)一個(gè)slaveTaskTracker共同組成。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)該指明輸入/輸出的位置（路徑），并通過實(shí)現(xiàn)合適的接口或抽象類提供map和reduce函數(shù)。再加上其他作業(yè)的參數(shù)，就構(gòu)成了作業(yè)配置（jobconfiguration）。然后，Hadoop的jobclient提交作業(yè)（jar包/可執(zhí)行程序等）和配置信息給JobTracker，后者負(fù)責(zé)分發(fā)這些軟件和配置信息給slave、調(diào)度任務(wù)并監(jiān)控它們的執(zhí)行，同時(shí)提供狀態(tài)和診斷信息給job-client。2.4ZookeeperZookeeper是一個(gè)高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架。簡單的說，就是個(gè)分布式協(xié)調(diào)器。它以主從的架構(gòu)，基于Paxos算法實(shí)現(xiàn)，保證了分布式環(huán)境中數(shù)據(jù)的強(qiáng)一致性，也因此各種分布式開源項(xiàng)目中都有它的身影。2.4.1Zookeeper機(jī)制Zookeeper的核心是一個(gè)精簡的文件系統(tǒng)，它的原語操作是一組豐富的構(gòu)件（buildingblock），可用于實(shí)現(xiàn)很多協(xié)調(diào)數(shù)據(jù)結(jié)構(gòu)和協(xié)議，包括分布式隊(duì)列、分布式鎖和一組同級節(jié)點(diǎn)中的“領(lǐng)導(dǎo)者選舉”（leaderelection）。Zookeeper實(shí)現(xiàn)的是Paxos算法。Zookeeper集群啟動后自動進(jìn)行l(wèi)eaderselection，投票選出一臺機(jī)器作為Leader，其他的都是Follower。通過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對hadoop進(jìn)行了更實(shí)時(shí)的改進(jìn)。3.1HDFS與MySQL的性能互補(bǔ)HDFS適合大塊地讀取數(shù)據(jù)（推薦節(jié)點(diǎn)是64M），它關(guān)于隨機(jī)讀取的工作的accesslatency比較大，所以一般會用大規(guī)模的MySQL集群結(jié)合memcached這樣的緩存工具來做處理。在Facebook中，從Hadoop中產(chǎn)生的類似中間結(jié)果的數(shù)據(jù)會裝載到MySQL集群或者memcached中去，用來被web層使用。同時(shí)，HDFS的順序讀取性能很好。Facebook需求寫方面的高吞吐量，代價(jià)低的彈性存儲，同時(shí)要求低延遲和硬盤上高效的順序和隨機(jī)讀取。MySQL存儲引擎被證明有比較高的隨機(jī)讀取能力，但是隨機(jī)寫吞吐率比較差。因此，F(xiàn)acebook決定采用Hadoop和HBase來平衡順序和隨機(jī)讀取的性能，而不是只采用MySQL集群來不斷嘗試一種難以把握的balance。具體Facebook的需求將在下一節(jié)仔細(xì)剖析。3.2Facebook需求Facebook認(rèn)為，用他們已有的基于MySQL集群的一些解決方案來處理問題已經(jīng)遇到了瓶頸。之前的用例對工作量的擴(kuò)展是有挑戰(zhàn)性的。在一個(gè)RDBMS的環(huán)境下解決非常高的寫吞吐量，大數(shù)據(jù)，不可預(yù)測增長及其他問題變得十分困難。3.3選擇Hadoop和HBase原因采用Hadoop和HBase來解決以上需求的存儲系統(tǒng)方案的原因可以總結(jié)為以下幾點(diǎn)：彈性：需要能夠用最小的開銷和零宕機(jī)修復(fù)時(shí)間來對存儲系統(tǒng)增量式地?cái)U(kuò)容。這里的擴(kuò)容應(yīng)該指的是可以比較方便地實(shí)時(shí)增加服務(wù)器臺數(shù)來應(yīng)對一些高峰或者突發(fā)服務(wù)需求。高的寫吞吐量高效的硬盤隨機(jī)讀寫高可用性和容災(zāi)錯誤隔離：當(dāng)局部數(shù)據(jù)庫掛掉或者服務(wù)器不能提供服務(wù)的時(shí)候，讓最少的用戶受到影響。HDFS應(yīng)對這樣的場景還是很不錯的。讀寫改的原子性：底層存儲系統(tǒng)針對高并發(fā)量的需求范圍掃描：指特定場景下高效獲取一個(gè)范圍結(jié)果集。HBase已經(jīng)以key-value存儲的方式提供了高一致性的高寫吞吐，且在大規(guī)模數(shù)據(jù)傳送和快速隨機(jī)寫以及流式讀方面表現(xiàn)優(yōu)異。它同時(shí)保證了行層次的原子性。從數(shù)據(jù)模型的角度看，面向列的實(shí)現(xiàn)給數(shù)據(jù)存儲帶來了極高的靈活性，“寬”行允許在一個(gè)table內(nèi)存放百萬數(shù)量級的被索引的值。雖然HDFS的核心namenode的宕機(jī)會帶來巨大影響，但是Facebook有信心打造一個(gè)在合理時(shí)限內(nèi)的高可用的NameNode。根據(jù)一些實(shí)踐測試，F(xiàn)acebook對HDFS進(jìn)行了設(shè)計(jì)和改進(jìn)，主要針對namenode。將在下節(jié)展開。3.4實(shí)時(shí)HDFSHDFS剛開始是為了支持MapReduce這樣的并行應(yīng)用的數(shù)據(jù)存取的，是面向批處理系統(tǒng)的，所以在實(shí)時(shí)方面講本身可能是存在不足的。Facebook主要改造在于一個(gè)高可用的AvatarNode我們知道HDFS的namenode一旦掛掉，整個(gè)集群就得等到namenode再次啟動才能繼續(xù)運(yùn)行提供服務(wù)，所以需要這個(gè)熱備份——AvatarNode的設(shè)計(jì)。在HDFS啟動的時(shí)候，namenode是從一個(gè)叫fsimage的文件里讀取文件系統(tǒng)的元數(shù)據(jù)的。元數(shù)據(jù)信息包括了HDFS上所有文件和目錄的名字和元數(shù)據(jù)。但是namenode不會持續(xù)地去存每一塊block的位置信息。所以冷啟動namenode的時(shí)候包括兩部分：首先讀文件系統(tǒng)鏡像；然后，大部分datanode匯報(bào)進(jìn)程上的block信息，以此來恢復(fù)集群上每一塊已知block的位置信息。這樣的冷啟動會花很長時(shí)間。雖然一個(gè)備用的可用node可以避免failover時(shí)候去讀磁盤上的fsimage，但是依然需要從datanodes里獲取block信息。所以，時(shí)間相對還是偏長。于是誕生了AvatarNode。如圖所示。HDFS擁有兩個(gè)AvatarNode——ActiveAvatarNode和StandbyAvatarNode。他們形成了一對“主被動熱備份”（active-passive-hot-standby）。AvatarNode是對NameNode的包裝。Facebook的HDFS集群都采用NFS來存一份文件系統(tǒng)鏡像的備份和一份事物日志的備份。ActiveAvatarNode把自己處理的事務(wù)寫進(jìn)NFS里的事務(wù)日志。同時(shí)，StandbyAvatarNode打開NFS上同一份事務(wù)日志，然后在自己的命名空間內(nèi)開始執(zhí)行事務(wù)，以保證自己的命名空間盡可能和初始信息接近。StandbyAvatarNode同時(shí)照顧到初始信息的核查并創(chuàng)建新的文件系統(tǒng)鏡像，和HDFS相比就沒有了分離的SecondNameNode。Datanodes同時(shí)和兩個(gè)AvatarNode交流。這保證了Standby處也獲得到最新的block狀態(tài)信息，以在分鐘時(shí)間級內(nèi)轉(zhuǎn)化成為Activer的Node（之前說namenode的冷啟動的時(shí)長問題可以解決了）。AvatarDataNode相互之間輸送心跳，block信息匯報(bào)和接受到的block。AvatarDataNodes集成了Zookeeper，因此他們知道主節(jié)點(diǎn)信息，會執(zhí)行主節(jié)點(diǎn)發(fā)送的復(fù)制/刪除命令（基于Zookeeper的leaderselection和heartbeat機(jī)制），而來自StandbyAvatarNode的復(fù)制/刪除請求是忽略的。對于事務(wù)日志的記錄，還進(jìn)行了一些改進(jìn)。i.為了讓故障和失效盡可能透明，Standby必須知道失效發(fā)生時(shí)的block位置信息，所以對每一塊block分配記錄一個(gè)額外的記錄日志。這樣允許客戶端在發(fā)生失效的時(shí)刻前還是一直在寫文件。ii.當(dāng)Standby向正在被Active寫事務(wù)記錄的日志里讀取事務(wù)信息的時(shí)候，有可能讀到的是一個(gè)局部的事務(wù)。為了避免這樣的問題，給每個(gè)要寫進(jìn)日志里的事務(wù)增加記錄事務(wù)長度信息，事務(wù)id和校驗(yàn)和。要了解更具體的信息，可以從原paper中獲得更多具體的情況。4.HadoopDB[6]HadoopDB簡單介紹下設(shè)計(jì)理念和他的架構(gòu)。4.1HadoopDB理念HadoopDB是一個(gè)混合系統(tǒng)?；舅枷胧怯肕apReduce作為與正在運(yùn)行著單節(jié)點(diǎn)DBMS實(shí)例的多樣化節(jié)點(diǎn)的通信層。查詢語言用SQL表示，并用現(xiàn)有工具翻譯成MapReduce可以接受的語言，使得盡可能多的任務(wù)可以被推送到每個(gè)高性能的單節(jié)點(diǎn)數(shù)據(jù)庫上。這樣基于MapReduce的并行化的數(shù)據(jù)庫代價(jià)幾乎是零。因?yàn)镸apReduce是現(xiàn)有的。HadoopDB背后的一些主要思想包括以下兩個(gè)關(guān)鍵字：share-nothingMPP架構(gòu)和paralleldatabases。4.2HadoopDB架構(gòu)介紹作為一個(gè)混合的系統(tǒng)，讓我們看看HadoopDB由哪些部分構(gòu)成：HDFS，MapReduce，SMSPlanner，DBConnector等等。HadoopDB的核心框架還是Hadoop，具體就是存儲層HDFS，和處理層MapReduce。關(guān)于HDFS上namenode，datanode各自處理任務(wù)，數(shù)據(jù)備份存儲機(jī)制以及MapReduce內(nèi)master-slave架構(gòu)，jobtracker和tasktracker各自的工作機(jī)制和任務(wù)負(fù)載分配，數(shù)據(jù)本地化特性等內(nèi)容就不詳細(xì)說了。下面對主要構(gòu)成部件做簡單介紹：1.DatabaeConnector：承擔(dān)的是node上獨(dú)立數(shù)據(jù)庫系統(tǒng)和TaskTracker之間的接口。圖中可以看到每個(gè)single的數(shù)據(jù)庫都關(guān)聯(lián)一個(gè)datanode和一個(gè)tasktracker。他傳輸SQL語句，得到一些KV返回值。擴(kuò)展了Hadoop的InputFormat，使得與MapReduce框架實(shí)現(xiàn)無縫拼接。2.Catalog：維持?jǐn)?shù)據(jù)庫的元數(shù)據(jù)信息。包括兩部分：數(shù)據(jù)庫的連接參數(shù)和元數(shù)據(jù)，如集群中的數(shù)據(jù)集，復(fù)本位置，數(shù)據(jù)分區(qū)屬性。現(xiàn)在是以XML來記錄這些元數(shù)據(jù)信息的。由JobTracker和TaskTracker在必要的時(shí)候來獲取相應(yīng)信息。3.DataLoader：主要職責(zé)涉及根據(jù)給定的分區(qū)key來裝載數(shù)據(jù)，對數(shù)據(jù)進(jìn)行分區(qū)。包含自身兩個(gè)主要Hasher：GlobalHasher和LocalHasher。簡單地說，Hasher無非是為了讓分區(qū)更加均衡。4.SMSPlanner：SMS是SQLtoMapReducetoSQL的縮寫。HadoopDB通過使他們能執(zhí)行SQL請求來提供一個(gè)并行化數(shù)據(jù)庫前端做數(shù)據(jù)處理。SMS是擴(kuò)展了Hive。關(guān)于Hive我在這里不展開介紹了。總之是關(guān)于一種融入到MapReducejob內(nèi)的SQL的變種語言，來連接HDFS內(nèi)存放文件的table?？梢再N個(gè)圖看下。不詳細(xì)說了。5.CoHadoop[7]論文提出CoHadoop來解決Hadoop無法把相關(guān)的數(shù)據(jù)定位到同一個(gè)node集合下的性能瓶頸。CoHadoop是對Hadoop的一個(gè)輕量級擴(kuò)展，目的是允許應(yīng)用層能控制數(shù)據(jù)的存儲。應(yīng)用層通過某種方式提示CoHadoop某些集合里的文件是相關(guān)性比較大的，可能需要合并，之后CoHadoop就嘗試去轉(zhuǎn)移這些文件以提高一定的數(shù)據(jù)讀取效率。5.1研究意義Hadoop++[6]項(xiàng)目其實(shí)也做過類似的事，它將同一個(gè)job產(chǎn)生的兩個(gè)file共同放置，但是當(dāng)有新文件注入系統(tǒng)的時(shí)候，它需要對數(shù)據(jù)重新組織。CoHadoop的改進(jìn)主要給以下幾個(gè)操作帶來了比較大的好處：索引（indexing），聚合（grouping），聚集（aggregation），縱向存儲（columnarstorage），合并（join）以及sessionization。而像日志分析這樣的操作，涉及到的就是把一些參考數(shù)據(jù)合并起來或者進(jìn)行sessionization。這可以體現(xiàn)CoHadoop的改進(jìn)意義所在。以下是paper關(guān)于CoHadoop的總結(jié)：這是一種很靈活，動態(tài)，輕量級的共置相關(guān)數(shù)據(jù)文件的方案，而且是直接在HDFS上實(shí)現(xiàn)的。在日志處理方面，確定了兩個(gè)用例：join和sessionization，使得在查詢處理方面得到了顯著的性能提高。作者還研究了CoHadoop的容錯，分布式數(shù)據(jù)和數(shù)據(jù)丟失。在不同的場景下測試了join和sessionization的效果。接下來還是介紹下CoHadoop的設(shè)計(jì)思想。5.2改進(jìn)設(shè)計(jì)介紹HDFS本身存數(shù)據(jù)的時(shí)候是有冗余的。默認(rèn)是存三分拷貝。這三份復(fù)制品會存在不同的地方。最簡單是存在datanode里。默認(rèn)的存放方式是第一份拷貝存在新建的本地誕生的node的block里（假設(shè)足夠存），這叫寫“親和”（writeaffinity）。HDFS然后選擇同一機(jī)架上的datanode存放第二個(gè)拷貝，選擇不同機(jī)架上的一個(gè)datanode存第三份拷貝。這是HDFS的本來的機(jī)制。那么為了實(shí)現(xiàn)相關(guān)數(shù)據(jù)的共置存儲，論文修改了存放策略。以上Hadoop現(xiàn)有的存放策略主要是為了負(fù)載均衡，但是當(dāng)應(yīng)用需要從不同的文件里去取所需的數(shù)據(jù)的時(shí)候，如果能自定義一些策略，那可能會得到顯著的提升。輕量級的CoHadoop使得開發(fā)自定義的策略變得簡單。雖然分區(qū)在Hadoop里實(shí)現(xiàn)很簡單，但是共置并不容易，Hadoop也沒有提供這樣類似的可行性功能實(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集合里，而沒有l(wèi)ocator映射的文件依舊按照默認(rèn)的Hadoop的存儲機(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í)候，locatortable是在內(nèi)存里動態(tài)維護(hù)的，關(guān)于數(shù)據(jù)存放策略的修改是這么做的：只要有一個(gè)新的和locatorl關(guān)聯(lián)的文件f被創(chuàng)建，會去locatortable里查詢是否存在一個(gè)實(shí)例是屬于這個(gè)locatorl的。如果不存在，就新增一條（l,f）在table里，并用HDFS默認(rèn)的存放方式存這份文件的拷貝們。如果已經(jīng)存在，就可以知道這個(gè)l映射的filelist，如果從現(xiàn)有的存放了這個(gè)list內(nèi)的文件的r個(gè)datanode里按一定方式（考慮空間）選出幾個(gè)用于存新來的文件的拷貝的節(jié)點(diǎn)，存放這份文件的拷貝們。大致的意思就是這樣。關(guān)于日志的join和sessionization的改進(jìn)，就不展開了。簡單貼兩個(gè)圖。做sessionization，對于日志處理時(shí)候MapReduce計(jì)算的影響比較。6.總結(jié)雖然我對Hadoop有濃厚的興趣，但是自己所能接觸到的項(xiàng)目和環(huán)境，都沒有到達(dá)一個(gè)比較飽和的需求點(diǎn)。要做分布式存儲？根本用不著動用HBase或者別的NoSQL組成的分布式集群，只需要一個(gè)分布式的MySQL集群就可以了，NoSQL可以做的事，其實(shí)MySQL何嘗不能完成？只是說No