Hbase分析報(bào)告模版

Hbase分析報(bào)告本文基于環(huán)境hadoop-0.16.4和hbase-0.1.3編寫Hbase是一個(gè)分布式開源數(shù)據(jù)庫(kù)，基于Hadoop分布式文件系統(tǒng)，仿照并供給了基于Google文件系統(tǒng)的Bigtable數(shù)據(jù)庫(kù)的全部功能。Hbaes10億行數(shù)據(jù)，并且有數(shù)百萬列元素組成的數(shù)據(jù)表。Hbase可以直接使用本地文件系統(tǒng)或者Hadoop作為數(shù)據(jù)存儲(chǔ)方式，不過為了提高數(shù)據(jù)牢靠性和系統(tǒng)的強(qiáng)健性，發(fā)揮Hbase處理大數(shù)據(jù)量等功能，需要使用Hadoop作為文件系統(tǒng)，那么我們就先要了解Hadoop文件系統(tǒng)的根本特性和原理Hbase的工作方式。Hadoop文件系統(tǒng)Hadoop文件系統(tǒng)是一個(gè)能夠兼容一般硬件環(huán)境的分布式文件系統(tǒng)，和現(xiàn)有的分布式文件系統(tǒng)不同的地方是Hadoop甚至直接利用現(xiàn)有機(jī)器就實(shí)現(xiàn)大流量和大數(shù)據(jù)量的讀取。Hadoop使用了POSIX()的設(shè)計(jì)來實(shí)現(xiàn)對(duì)文件系統(tǒng)文件流的讀取。HDFS〔HadoopFileSystem〕原來是ApacheNutch搜尋引擎〔從Lucene進(jìn)展而來〕開發(fā)的一個(gè)局部，后來獨(dú)立出來作為一個(gè)Apache子工程。Hadoop的假設(shè)與目標(biāo)1Hadoop假設(shè)硬件出錯(cuò)是一種正常的狀況，而不是特別，為的就是在硬件出錯(cuò)的狀況下盡量保證數(shù)據(jù)完整性HDFS并且可以快速檢測(cè)出硬件錯(cuò)誤和快速進(jìn)展數(shù)據(jù)的自動(dòng)恢復(fù)。2Hadoop是為了程序批量處理數(shù)據(jù)而設(shè)計(jì)的，而不是與用戶的交互或者隨機(jī)讀寫，所以POSIX對(duì)程序增加了很多硬性限制，程序必需使用流讀取來提高數(shù)據(jù)吞吐率。3HDFSGBTB計(jì)算的，而且一個(gè)數(shù)百臺(tái)機(jī)器組成的集群里面可以支持過千萬這樣的文件。4HDFS上面的文件模型格外簡(jiǎn)潔，就是一次寫入屢次讀取的模型，文件一旦創(chuàng)立，寫入并關(guān)閉了，之后就再也不會(huì)被轉(zhuǎn)變了，只能被讀取，這種模型剛好符合搜尋引擎的需求，以后可能會(huì)實(shí)現(xiàn)追加寫入數(shù)據(jù)這樣的功能。5java不高，只要是jdk支持的平臺(tái)都可以兼容。Hadoop體系構(gòu)造和數(shù)據(jù)節(jié)點(diǎn)〔DataNodes〕Hadoop文件系統(tǒng)是主從架構(gòu)，一個(gè)Hadoop文件系統(tǒng)由唯一一個(gè)名目節(jié)點(diǎn)和數(shù)個(gè)數(shù)據(jù)節(jié)點(diǎn)組成。Hadoop文件系統(tǒng)對(duì)外表現(xiàn)為一個(gè)一般的文件系統(tǒng)，用戶可以用文件名去存儲(chǔ)和訪問文件，而實(shí)際上文件是被分成不同的數(shù)據(jù)塊，這些數(shù)據(jù)塊就是存儲(chǔ)在數(shù)據(jù)節(jié)點(diǎn)上面。系，客戶端需要訪問名目節(jié)點(diǎn)才能知道一個(gè)文件的全部數(shù)據(jù)塊都保存在哪些數(shù)據(jù)節(jié)點(diǎn)上。的命令創(chuàng)立、刪除數(shù)據(jù)塊，和冗余復(fù)制。一個(gè)典型的Hadoop文件系統(tǒng)集群部署，是由一臺(tái)性能較好的機(jī)器運(yùn)行名目節(jié)點(diǎn)，而集群里名目節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)一起運(yùn)行，不過這種模式在正式的應(yīng)用部署中很少使用。Hadoop文件系統(tǒng)里面全部元數(shù)據(jù)的仲裁和存儲(chǔ)。這樣的設(shè)計(jì)使數(shù)據(jù)不會(huì)脫離名目節(jié)點(diǎn)的掌握。Hadoop文件系統(tǒng)命名空間HadoopHadoop允許用戶創(chuàng)立、刪除文件，在名目間轉(zhuǎn)移文件，重命名文件等，但是還沒有實(shí)現(xiàn)磁盤配額和文件訪問權(quán)限等功能，也不支持文件的硬連接和軟連接〔快捷方式，這些功能在短期內(nèi)不會(huì)實(shí)現(xiàn)。名目節(jié)點(diǎn)負(fù)責(zé)存儲(chǔ)和治理整個(gè)文件系統(tǒng)的命名空間，應(yīng)用程序可以指定某一個(gè)文件需要在Hadoop文件系統(tǒng)中冗余多少份，這個(gè)在Hadoop中稱為冗余因素，保存在名目節(jié)點(diǎn)里面。Hadoop存儲(chǔ)原理冗余數(shù)據(jù)保存Hadoop文件系統(tǒng)是為了大文件的牢靠保存而設(shè)計(jì)的，一個(gè)文件被劃分成一連串的數(shù)據(jù)塊，Hadoop這個(gè)文件。名目節(jié)點(diǎn)是依據(jù)數(shù)據(jù)塊的冗余狀況來作出處理決策的，數(shù)據(jù)節(jié)點(diǎn)會(huì)定期發(fā)送一個(gè)存在信號(hào)〔Heartbeat〕和數(shù)據(jù)塊列表給名目節(jié)點(diǎn)，存在信號(hào)使名目節(jié)點(diǎn)認(rèn)為該數(shù)據(jù)節(jié)點(diǎn)還是有效的，而數(shù)據(jù)塊列表包括了該數(shù)據(jù)節(jié)點(diǎn)上面的全部數(shù)據(jù)塊編號(hào)。數(shù)據(jù)存取策略hadoop文件系統(tǒng)最核心的局部hadoop和其它分布式文件系統(tǒng)的最大區(qū)分就是可以調(diào)整冗余數(shù)據(jù)的位置，這個(gè)特性需要很多時(shí)間去優(yōu)化和調(diào)整。一、數(shù)據(jù)存放目前hadoop承受以機(jī)柜為根底的數(shù)據(jù)存放策略，這樣做的目的是提高數(shù)據(jù)牢靠性和充分利用網(wǎng)絡(luò)帶寬。當(dāng)前具體實(shí)現(xiàn)了的策略只是這個(gè)方向的嘗試，hadoop短期的爭(zhēng)論目標(biāo)之一就是在實(shí)際產(chǎn)品環(huán)境中觀看系統(tǒng)讀寫的行為，測(cè)試性能和爭(zhēng)論更深入的規(guī)章。一個(gè)大的hadoop集群常常橫跨多個(gè)機(jī)柜，而不同機(jī)柜之間的數(shù)據(jù)通訊同經(jīng)過交換機(jī)或者路由，所以同一個(gè)機(jī)柜中不同機(jī)器的通訊帶寬是比不同機(jī)柜之間機(jī)器通訊時(shí)候的大。Hadoopapiid，當(dāng)文件系統(tǒng)啟動(dòng)的時(shí)候，數(shù)據(jù)機(jī)就把自己所屬的機(jī)柜id發(fā)給名目機(jī)，然后名目機(jī)治理這些分組。Hadoop默認(rèn)是每個(gè)數(shù)據(jù)機(jī)都是在不同的機(jī)柜上面，這種方法沒有做任何性能優(yōu)化，但是也有不少優(yōu)點(diǎn)：123缺點(diǎn)就是寫入數(shù)據(jù)的時(shí)候并不能完全利用同一機(jī)柜里面機(jī)器的帶寬。在默認(rèn)的配置下，hadoop3，意思就是每一塊文件數(shù)據(jù)一共有3個(gè)地方存放，hadooprackid的不同機(jī)器上面，另外一個(gè)放rackid1/3的冗余數(shù)據(jù)在一個(gè)機(jī)柜里面，2/3的冗余數(shù)據(jù)在另外一個(gè)機(jī)柜里面，這樣既可以防止機(jī)柜特別時(shí)候的數(shù)據(jù)恢復(fù)，又可以提高讀寫性能。上面所說的策略目前還是在測(cè)試優(yōu)化階段。二、數(shù)據(jù)讀取數(shù)據(jù)讀取策略，依據(jù)前面所說的數(shù)據(jù)存放策略，數(shù)據(jù)讀取的時(shí)候，客戶端也有api確定自己的機(jī)柜id，讀取的時(shí)候，假設(shè)有塊數(shù)據(jù)和客戶端的機(jī)柜id一樣，就優(yōu)先選擇該數(shù)據(jù)節(jié)點(diǎn)，客戶端直接和數(shù)據(jù)節(jié)點(diǎn)建立連接，讀取數(shù)據(jù)。假設(shè)沒有，就隨機(jī)選取一個(gè)數(shù)據(jù)節(jié)點(diǎn)。三、數(shù)據(jù)復(fù)制主要是在數(shù)據(jù)寫入和數(shù)據(jù)恢復(fù)的時(shí)候發(fā)生，數(shù)據(jù)復(fù)制是使用流水線復(fù)制的策略。hadoop上面寫一個(gè)文件，首先它先把這個(gè)文件寫在本地，然后對(duì)文件進(jìn)展分64m一塊，每塊數(shù)據(jù)都對(duì)hadoop名目效勞器懇求，名目效勞器選擇一個(gè)數(shù)據(jù)機(jī)列表，返回給客戶端，然后客戶端就把數(shù)據(jù)寫入第一臺(tái)數(shù)據(jù)機(jī)，并且把列表傳給數(shù)據(jù)機(jī)，當(dāng)4k數(shù)據(jù)的時(shí)候，寫入本地并且發(fā)起連接到下一臺(tái)數(shù)據(jù)機(jī)，把這個(gè)4k傳過去，形成一條流水線。勢(shì)。通訊協(xié)議hadooptcp/ipClientProtocol和名目效勞器通訊，數(shù)據(jù)機(jī)使用DatanodeProtocol和名目效勞器通訊，而名目效勞器一般只是應(yīng)答客戶端和數(shù)據(jù)機(jī)的懇求，不會(huì)主動(dòng)發(fā)起通訊。數(shù)據(jù)錯(cuò)誤和特別hadoop文件系統(tǒng)的主要目標(biāo)就是在硬件出錯(cuò)的時(shí)候保證數(shù)據(jù)的完整性，它把磁盤錯(cuò)誤作為器錯(cuò)誤，數(shù)據(jù)機(jī)錯(cuò)誤，和網(wǎng)絡(luò)傳輸特別。1、數(shù)據(jù)機(jī)出錯(cuò)，每個(gè)數(shù)據(jù)時(shí)機(jī)定時(shí)發(fā)送一個(gè)心跳信息給名目效勞器，說明自己仍舊存活，io據(jù)塊也會(huì)標(biāo)記為不行讀。這個(gè)時(shí)候某些數(shù)據(jù)塊的冗余份數(shù)有可能就低于它的冗余因子了，名目效勞器會(huì)定期檢查每一個(gè)數(shù)據(jù)塊，看看它是否需要進(jìn)展數(shù)據(jù)冗余復(fù)制。2客戶端實(shí)現(xiàn)對(duì)數(shù)據(jù)塊的校驗(yàn)，用md5sha1進(jìn)展校驗(yàn)，客戶端在創(chuàng)立文件的時(shí)候，會(huì)對(duì)每一個(gè)文件塊進(jìn)展信息摘錄，并把這些信息寫入到同一個(gè)路徑的隱蔽文件里面。當(dāng)客戶端讀取文件的時(shí)候，會(huì)先讀取該信息文件，然后對(duì)每個(gè)讀取的數(shù)據(jù)塊進(jìn)展校驗(yàn)，假設(shè)校驗(yàn)出錯(cuò)，客戶端就會(huì)懇求到另外一個(gè)數(shù)據(jù)機(jī)讀取該文件塊，并且報(bào)告給名目效勞器這個(gè)文件塊有錯(cuò)誤，名目效勞器就會(huì)定期檢查，并且重復(fù)制這個(gè)塊。3FsImage和Editlog是名目效勞器上面兩個(gè)最核心的數(shù)據(jù)構(gòu)造，假設(shè)其中一個(gè)文件出錯(cuò)的話，會(huì)造成名目效勞器不起作用，由于這兩個(gè)文件如此重要，所以名目效勞器上面可以設(shè)置多個(gè)備份文件和關(guān)心效勞器，當(dāng)這兩個(gè)文件有轉(zhuǎn)變的時(shí)候，名目效勞器就會(huì)發(fā)起同步操作，雖然這樣增加了系統(tǒng)的負(fù)擔(dān)，但是在目前這個(gè)架構(gòu)上面為了實(shí)現(xiàn)數(shù)據(jù)的牢靠性，這個(gè)同步操作是格外必要的。Hadoop文件系統(tǒng)尚未實(shí)現(xiàn)的功能總結(jié)：1數(shù)據(jù)效勞器死機(jī)或者名目效勞器死機(jī)，會(huì)引起文件喪失，并且不行后續(xù)恢復(fù)寫入。23、集群負(fù)載均衡，均衡策略臨時(shí)沒有實(shí)現(xiàn)，有幾個(gè)策略格外有用，比方在某臺(tái)數(shù)據(jù)機(jī)可能磁盤過低的時(shí)候，把該數(shù)據(jù)機(jī)上面的一些數(shù)據(jù)轉(zhuǎn)移到還有很多空間剩余的數(shù)據(jù)機(jī)上；當(dāng)某個(gè)文件突然被大量讀寫的時(shí)候，動(dòng)態(tài)增加該文件的冗余因子，并且數(shù)據(jù)塊復(fù)制到更多的數(shù)據(jù)機(jī)上面，以提高讀取性能。45、訪問權(quán)限，現(xiàn)在是無限制訪問的，沒有訪問權(quán)限掌握。Hadoop文件系統(tǒng)性能分析由于沒方法建立大型的Hadoop文件系統(tǒng)，只能節(jié)選一些網(wǎng)上的性能分析，以表示一二。1KosmosFilesystem的比較，KosmosFilesystemGoogle文件系統(tǒng)的Hadoop具有比較的意義。KFS是用c++編寫的，在代碼執(zhí)行效率上java好不少。數(shù)據(jù)插入測(cè)試：測(cè)試環(huán)境：11.8GHzDual-coreOpteronProcessor22104GBRAM47200RPMSATAdrives(mountedJBOD)測(cè)試使用Hypertable，這也是一個(gè)類似Googlebigtable的具體實(shí)現(xiàn)，可以使用KFS和HDFS75,274,825715測(cè)試結(jié)果：KFS根本大幅度勝出。HDFS(noflush)Elapsedtime:170.66sAvgvaluesiz:e15.25bytesTotal

bytes1792158.6bytes1482527986869.7insersElapsedtime:167.44sAvgvaluesiz:e15.26bytesTotal

bytes1871062.7bytes1518534990690.8insersElapsedtime:179.91sAvgvaluesiz:e15.20bytesTotal

7.03bytes1737888.1bytes1520831084532.6insersElapsedtime:169.57sAvgvaluesiz:e15.22bytesTotalKFS(noflush)

7.11bytes1831688.5bytes1508092688937.4insersElapsedtime:125.51sAvgvaluesiz:e15.25bytesTotal

bytes2436864.8bytes14825279118120.0insersElapsedtime:126.25sAvgvaluesiz:e15.26bytesTotal

bytes2481447.5bytes15185349120276.3insersElapsedtime:135.51sAvgvaluesiz:e15.20bytesTotal

7.03bytes2307335.2bytes15208310112231.1insersElapsedtime:127.66sAvgvaluesiz:e15.22bytesTotal

7.11bytes2433069.6bytes15080926118137.4insers2Hadoophadoop自帶的FileBench1ghadoop文件系統(tǒng)的比較，好很多。本地文件系統(tǒng)測(cè)試：java -classpathhadoop-0.16.4-test.jar:hadoop-0.16.5-dev-core.jar:lib/commons-logging-api-1.0.4.jar:lib/log4j-1.2.13.jar:lib/commons-logging-1.0.4.jar:lib/commons-cli-2.0-SNAPSHOT.jarorg.apache.hadoop.io.FileBench-dir/home/ssmax/test-nolzo-nozipDIR:file:/home/ssmax/testWSEQ_PLN:42secondsWTXT_PLN:31secondsRSEQ_PLN:25secondsRTXT_PLN:21seconds取。Hadoopjava -classpathbuild/hadoop-0.16.5-dev-test.jar:hadoop-0.16.5-dev-core.jar:lib/commons-logging-api-1.0.4.jar:lib/log4j-1.2.13.jar:lib/commons-logging-1.0.4.jar:lib/commons-cli-2.0-SNAPSHOT.jar org.apache.hadoop.io.FileBench -dir“hdfs://38:9000/user/ssmax“-now-nolzo-nozipDIR:hdfs://38:9000/user/ssmaxWSEQ_PLN:437secondsWTXT_PLN:439secondsRSEQ_PLN:>15RTXT_PLN:>15分鐘數(shù)據(jù)機(jī)做讀操作，讀取速度會(huì)大大提高。java -classpathhadoop-0.16.5-dev-test.jar:hadoop-0.16.5-dev-core.jar:lib/commons-logging-api-1.0.4.jar:lib/log4j-1.2.13.jar:lib/commons-logging-1.0.4.jar:lib/commons-cli-2.0-SNAPSHOT.jar org.apache.hadoop.io.FileBench -dir“hdfs://38:9000/user/ssmax“-now-nolzo-nozip DIR:hdfs://38:9000/user/ssmaxRSEQ_PLN:80secondsRTXT_PLN:63secondsrackidHadoopHbaseHadoopHypertableKFSBigtableGFSc++實(shí)現(xiàn)的，這里先記錄一下，以后再做爭(zhēng)論。Hypertable:HypertableHBaseHypertableBigtable〔InfoQHBaseJimKellermanHadoopHBaseJava，C+HypertableHbase數(shù)據(jù)模型Hbase是一個(gè)類似BigtableBigtable一個(gè)稀疏的，長(zhǎng)期存儲(chǔ)的｛存在硬盤上，多維度的，排序的映射表。這張表的索引是行關(guān)鍵字，列關(guān)鍵字和時(shí)間戳。每個(gè)值是一個(gè)不解釋的字符數(shù)組，數(shù)據(jù)都是字符串，沒類型。用戶在表格中存儲(chǔ)數(shù)據(jù)，每一行都有一個(gè)可排序的主鍵和任意多的列。由于是稀疏存儲(chǔ)的，所以同一張表里面的每一行數(shù)據(jù)都可以有截然不同的列。列名字的格式是“<family>:<label>“，都是由字符串組成，每一張表有一個(gè)family集合，這個(gè)集合是固定不變的，相當(dāng)于表的構(gòu)造，只能通過轉(zhuǎn)變表構(gòu)造來轉(zhuǎn)變。但是label值相對(duì)于每一行來說都是可以轉(zhuǎn)變的。Hbase把同一個(gè)family里面的數(shù)據(jù)存儲(chǔ)在同一個(gè)名目底下，而Hbase的寫操作是鎖行的，每一行都是一個(gè)原子元素，都可以加鎖。全部數(shù)據(jù)庫(kù)的更都有一個(gè)時(shí)間戳標(biāo)記，每個(gè)更都是一個(gè)的版本，而hbase會(huì)保存肯定一次獵取全部版本。概念視圖：RowKeyTimeColumnStampRowKeyTimeColumnStamp“contents:“Column“anchor:“Column“mime:““n.www“ t9“anchor:cnnsi““CNN“t8“anchor:my.look.ca““CNN“t6“<html>...““text/html“t5“<html>...“t3“<html>...“上圖是一個(gè)存儲(chǔ)Web網(wǎng)頁的范例列表片斷UR｛即n.wwcontents列族｛原文用family，譯為族，詳見列族｝存放網(wǎng)頁內(nèi)容，anchor列族存放引用該網(wǎng)頁的CNN的主頁被SportsIllustrater｛SI，CNN的王牌體育節(jié)目MY-look的主頁引用，因此該行包含了名叫“anchor:cnnsi”和“anchhor:my.look.ca”的列。每個(gè)錨鏈接只有一個(gè)版本｛由時(shí)間戳標(biāo)識(shí)，如t，t；而contents列則有三個(gè)版本，分別由時(shí)間t3，t5，和t6標(biāo)識(shí)。物理視圖雖然從概念視圖來看每個(gè)表格是由很多行組成它是依據(jù)列來保存的，這點(diǎn)在數(shù)據(jù)設(shè)計(jì)和程序開發(fā)的時(shí)候必需牢記。上面的概念視圖在物理存儲(chǔ)的時(shí)候應(yīng)當(dāng)表現(xiàn)成下面那樣子：RowRowKeyTimeStampColumn“contents:““n.www“t6“<html>...“t5“<html>...“t3“<html>...“RowKey TimeStamp“n.www“ t9t8

Column“anchor:““anchor:cnnsi“ “CNN““anchor:my.look.ca““CNN“RowRowKeyTimeStampColumn“mime:““n.www“t6“text/html“空白的單元格的時(shí)候，會(huì)返回null儲(chǔ)的時(shí)候，數(shù)據(jù)會(huì)依據(jù)時(shí)間戳排序。例子：9row[0-9]，先寫入anchor:foo列，再寫入anchor:bar列，最終重復(fù)寫入anchor:foo列，由于是同一個(gè)列族，寫到同一個(gè)映射文件里面，最終寫到文件里面是這個(gè)樣子的：row=row0,column=anchor:bar,timestamp=1174184619081row=row0,column=anchor:foo,timestamp=1174184620720row=row0,column=anchor:foo,timestamp=1174184617161row=row1,column=anchor:bar,timestamp=1174184619081row=row1,column=anchor:foo,timestamp=1174184620721row=row1,column=anchor:foo,timestamp=1174184617167row=row2,column=anchor:bar,timestamp=1174184619081row=row2,column=anchor:foo,timestamp=1174184620724row=row2,column=anchor:foo,timestamp=1174184617167row=row3,column=anchor:bar,timestamp=1174184619081row=row3,column=anchor:foo,timestamp=1174184620724row=row3,column=anchor:foo,timestamp=1174184617168row=row4,column=anchor:bar,timestamp=1174184619081row=row4,column=anchor:foo,timestamp=1174184620724row=row4,column=anchor:foo,timestamp=1174184617168row=row5,column=anchor:bar,timestamp=1174184619082row=row5,column=anchor:foo,timestamp=1174184620725row=row5,column=anchor:foo,timestamp=1174184617168row=row6,column=anchor:bar,timestamp=1174184619082row=row6,column=anchor:foo,timestamp=1174184620725row=row6,column=anchor:foo,timestamp=1174184617168row=row7,column=anchor:bar,timestamp=1174184619082row=row7,column=anchor:foo,timestamp=1174184620725row=row7,column=anchor:foo,timestamp=1174184617168row=row8,column=anchor:bar,timestamp=1174184619082row=row8,column=anchor:foo,timestamp=1174184620725row=row8,column=anchor:foo,timestamp=1174184617169row=row9,column=anchor:bar,timestamp=1174184619083row=row9,column=anchor:foo,timestamp=1174184620725row=row9,column=anchor:foo,timestamp=1174184617169其中anchor:foo被保存了兩次，由于時(shí)間戳不同，是兩個(gè)不同的版本，而最的數(shù)據(jù)排在前面，所以最那次更會(huì)先被找到。分布式數(shù)據(jù)庫(kù)體系構(gòu)造Hbase的效勞器體系構(gòu)造也是遵從簡(jiǎn)潔的主從效勞器架構(gòu)，由Hregion效勞器群和HBaseMaster主效勞器構(gòu)成。Hregion效勞器對(duì)用戶來說，每個(gè)表是一堆數(shù)據(jù)的集合，靠主鍵來區(qū)分。物理上，一張表是被拆分成多塊，每一塊就稱呼為一個(gè)Hregion+開頭/Hregion，一個(gè)HregionHregion上面的。全部的數(shù)據(jù)庫(kù)數(shù)據(jù)一般是保存在Hadoop分布式文件系統(tǒng)上面，用戶通過一系列Hregion效勞器獵取這些數(shù)據(jù)，一般一臺(tái)機(jī)器上面運(yùn)行一個(gè)Hregion效勞器，而每一個(gè)區(qū)段Hregion只會(huì)被一個(gè)Hregion效勞器維護(hù)。當(dāng)用戶需要更數(shù)據(jù)的時(shí)候，他會(huì)被安排到對(duì)應(yīng)的Hregion效勞器提交修改，這些修改先是被寫到Hmemcache緩存和效勞器的Hlog文件里面，Hmemcache是在內(nèi)存中的緩存，保存最近更的數(shù)據(jù)，Hlog是磁盤上面的記錄文件，它記錄著全部的更操作，當(dāng)操作寫Hlog之后，commit調(diào)用才會(huì)返回給客戶端。Hregion效勞器會(huì)先訪問Hmemcache才回到HstoresHstoreHstore集合包含很多HstoreFiles具體文件，這些文件都是B樹構(gòu)造的，便利快速讀取。定期HRegion.flushcache把緩存里面的內(nèi)容寫到文件中，一般這樣會(huì)增加一個(gè)的HstoreFile文件，而此時(shí)高速緩存就會(huì)被清空，并且寫入一個(gè)標(biāo)記到Hlog，表示上面的內(nèi)容已經(jīng)被寫入到文件中保存。在啟動(dòng)的時(shí)候，每個(gè)Hregion效勞器都會(huì)檢查自己的Hlog文件，看看最近一次執(zhí)行flushcache件中了；假設(shè)有更，效勞器就會(huì)先把這些更寫入高速緩存，然后調(diào)用flushcache寫入到文件。最終效勞器會(huì)刪除舊的Hlog文件，并開頭給用戶訪問數(shù)據(jù)。因此，為了節(jié)約時(shí)間可以很少調(diào)用flushcacheflushcache而且Hlogflushcache的時(shí)候會(huì)造成系統(tǒng)負(fù)載瞬間增加。Hlog會(huì)被定期回滾，回滾的時(shí)候是依據(jù)時(shí)間備份文件，每當(dāng)回滾的時(shí)候，系統(tǒng)會(huì)刪除那些已經(jīng)被寫到文件的更，回滾Hlog只會(huì)占用很少的時(shí)間，建議常?；貪L以削減文件尺寸。每一次調(diào)用flushcache會(huì)生成一個(gè)的HstoreFileHstore里面獵取一個(gè)值都需要訪問全部的HstoreFile文件，這樣格外耗時(shí)，所以我們要定期把這些分散的文件合并到一個(gè)大文件里面，HStorepact資源的，當(dāng)HstoreFile文件的數(shù)量超過一個(gè)設(shè)定值的時(shí)候才會(huì)觸發(fā)。Google的BigtableHbase面兩點(diǎn)就可以了：1、flushcache會(huì)建立一個(gè)的HstoreFile里面，flushcache之后，log的重建次數(shù)會(huì)清零。2compact會(huì)把全部HstoreFile文件合并成一個(gè)大文件。3、和Bigtable不同的是，Hbase每個(gè)更假設(shè)是被正確提交了，commit沒有返回錯(cuò)誤的話，它就肯定是被寫到記錄文件里面了，這樣不會(huì)造成數(shù)據(jù)喪失。兩個(gè)Hregion可以通過調(diào)用HRegion.closeAndMerge合并成一個(gè)的Hregion，當(dāng)前版本這個(gè)操作是需要兩臺(tái)Hregion都停機(jī)才能操作。當(dāng)一個(gè)Hregion變得太過巨大的時(shí)候，超過了設(shè)定的閾值， HRegion效勞器會(huì)調(diào)用HRegion.closeAndSplit，這個(gè)Hregion會(huì)被拆分為兩個(gè)并且報(bào)告給主效勞器讓它打算由哪個(gè)Hregion效勞器來存放的Hregion。這個(gè)拆分過程是格外快速的，由于兩個(gè)的Hregion最初只是保存原來HregionFile文件的引用，而這個(gè)時(shí)候舊的Hregion會(huì)處于停頓效勞的狀態(tài)，當(dāng)?shù)腍region合并完成并且把引用刪除了以后，舊的Hregion才會(huì)刪除。最終總結(jié)幾點(diǎn)：1、客戶端以表格的形式讀取數(shù)據(jù)2、一張表是被劃分成多個(gè)Hregion區(qū)域3、Hregion是被Hregion效勞器治理的，當(dāng)客戶端需要訪問某行數(shù)據(jù)的時(shí)候，需要訪問Hregion效勞器。4、Hregions效勞器里面有三種方式保存數(shù)據(jù)：AHmemcache高速緩存，保存是最寫入的數(shù)據(jù)B、Hlog記錄文件，保存的是提交成功了，但未被寫入文件的數(shù)據(jù)Hstores文件，數(shù)據(jù)的物理存放形式。Hbase主效勞器HregionHmaster效勞器通訊，Hmaster的主要任務(wù)就是要告知每個(gè)Hregion效勞器它要維護(hù)哪些Hregion。Hmaster效勞器會(huì)和每個(gè)Hregion效勞器保持一個(gè)長(zhǎng)連接導(dǎo)致：A、Hregion效勞器自動(dòng)重啟。B、Hmaster認(rèn)為HregionHregion安排到其它Hregion效勞器。和Google的BigtableBigtable的TabletServer和主效勞器通訊中斷的狀況下，HbaseHbase沒有Bigtable那樣額外的加鎖系統(tǒng)，BigtableTabletServerHbase只有唯一一個(gè)接入點(diǎn)，就是Hmaster效勞器。當(dāng)一個(gè)的Hregion效勞器登陸到Hmaster效勞器，Hmaster會(huì)告知它先等待安排數(shù)據(jù)。而當(dāng)一個(gè)Hregion死機(jī)的時(shí)候，Hmaster會(huì)把它負(fù)責(zé)的Hregion安排到其它Hregion效勞器。元數(shù)據(jù)表之前我們說過Hregion正好在執(zhí)行這些操作的過程中消滅死機(jī)，這個(gè)就要通過Hbase的元數(shù)據(jù)信息來區(qū)分哪一份才是正確的數(shù)據(jù)文件了，為了區(qū)分這樣的狀況，每個(gè)Hregion都有一個(gè)”regionId”來標(biāo)識(shí)它的唯一性。所以一個(gè)Hregion的表達(dá)符最終是表名+開頭主鍵+唯一id〔tablename+startkey+regionId〕舉個(gè)例子：hbaserepository,w-nk5YNZ8TBb2uWFIRJo7V==,6890601455914043877我們可以用這個(gè)識(shí)別符來區(qū)分不同的Hregion，這些數(shù)據(jù)就稱呼為元數(shù)據(jù)，而元數(shù)據(jù)本身也是被保存在HregionHregion標(biāo)識(shí)符和實(shí)際Hregion效勞器的映射關(guān)系。元數(shù)據(jù)表本身也會(huì)增長(zhǎng)，并且可能被分割為幾個(gè)Hregion，為了定位這些Hregion，有一個(gè)ROOTtabl只存在一個(gè)Hregion。在Hbase啟動(dòng)的時(shí)候，主效勞器先去掃描根數(shù)據(jù)表，由于這個(gè)表只會(huì)有一個(gè)Hregion，所以這個(gè)Hregion的名字是被寫死的Hregion效勞器需要肯定的時(shí)間。后把元數(shù)據(jù)表安排到不同的Hregion效勞器。最終就是掃描元數(shù)據(jù)表，找到全部Hregion區(qū)域的信息，然后把它們安排給不同的Hregion效勞器。主效勞器在內(nèi)存中保存著當(dāng)前活潑的Hregion效勞器的數(shù)據(jù)，因此假設(shè)主效勞器死機(jī)的話，整個(gè)系統(tǒng)也就無法訪問了，而效勞器的信息也沒有必要保存到文件里面。元數(shù)據(jù)表和根數(shù)據(jù)表的每一行都包含一個(gè)列族，info列族：info:regioninfoHregionInfo對(duì)象。info:server保存了一個(gè)字符串，是效勞器地址HServerAddress.toStringinfo:startcode一個(gè)長(zhǎng)整型的數(shù)字的字符串，是Hregion效勞器啟動(dòng)的時(shí)候傳給主效勞器的，讓主效勞器打算這個(gè)Hregion效勞器的信息有沒有更改。因此，當(dāng)一個(gè)客戶端拿到根數(shù)據(jù)表地址以后，就沒有必要再連接主效勞器了。主效勞器的負(fù)載相對(duì)就小了很多，它只會(huì)處理超時(shí)的Hregion效勞器，在啟動(dòng)的時(shí)候掃描根數(shù)據(jù)表和元數(shù)據(jù)表，和返回根數(shù)據(jù)表的Hregion效勞器地址。因此Hbase的客戶端是格外簡(jiǎn)單的，它常常需要掃瞄元數(shù)據(jù)表和根數(shù)據(jù)表，在查詢表格的時(shí)候，假設(shè)一個(gè)Hregion端保存的映射關(guān)系并不會(huì)始終正確的。這里的機(jī)制還需要進(jìn)一步完善?？偨Y(jié)：1、HregionHregion訪問，一個(gè)HregionHregion效勞器上面。2Hregion會(huì)注冊(cè)到主效勞器上面。34Hregion效勞器列表只有主效勞器知道。5HregionHregion效勞器的對(duì)應(yīng)關(guān)系保存在兩個(gè)特別的Hregion里面，它們像Hregion一樣被安排到不同的效勞器。6〔在程序中寫死〕7客戶端需要自己掃瞄這些表，來找到數(shù)據(jù)在哪里。Hbase和傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的比照分析HbaseBigtable來開發(fā)的，套用一個(gè)Bigtable的定義就是：ABigtableisasparse,distributed,persistentmultidimensionalsortedmap.BigtableHbase就是這樣一個(gè)基于列模式的映射數(shù)據(jù)庫(kù)，它只能表示很簡(jiǎn)潔的鍵-數(shù)據(jù)的映射關(guān)系，它大大簡(jiǎn)化了傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)。1、數(shù)據(jù)類型，Hbase只有簡(jiǎn)潔的字符串類型，全部類型都是交由用戶自己處理，它只保存字符串。而關(guān)系數(shù)據(jù)庫(kù)有豐富的類型選擇和存儲(chǔ)方式。2、數(shù)據(jù)操作，Hbase沒有簡(jiǎn)單的表和表之間的關(guān)系，所以也不能也沒有必要實(shí)現(xiàn)表和表之間的關(guān)聯(lián)等操作。而傳統(tǒng)的關(guān)系數(shù)據(jù)通常有各種各樣的函數(shù)、連接操作。Hbasealter Altercolumnfamilyschema;passtablenameandadictionaryspecifyingnewcolumnfamilyschema.DictionariesaredescribedbelowintheGENERALNOTESsection.Dictionarymustincludenameofcolumnfamilytoalter.Forexample,tochangethe”f1”columnfamilyintable”t1”fromdefaultstoinsteadkeepamaximumof5cellVERSIONS,do:hbase>alter”t1”,{NAME=>”f1”,VERSIONS=>5}count Countthenumberofrowsinatable.ThisoperationmaytakeaLONGtime(Run”$HADOOP_HOME/bin/hadoopjarhbase.jarrowcount”torunacountingmapreducejob).Currentcountisshownevery1000rowsbydefault.Countintervalmaybeoptionallyspecified.Examples:hbase>count”t1”hbase>count”t1”,100000create Createtable;passtablename,adictionaryofspecificationspercolumnfamily,andoptionallyadictionaryoftableconfiguration.DictionariesaredescribedbelowintheGENERALNOTESsection.Examples:hbase>create”t1”,{NAME=>”f1”,VERSIONS=>5}hbase>create”t1”,{NAME=>”f1”},{NAME=>”f2”},{NAME=>”f3”}hbase>#Theaboveinshorthandwouldbethefollowing:hbase>create”t1”,”f1”,”f2”,”f3”hbase>create”t1”,{NAME=>”f1”,VERSIONS=>1,TTL=>2592000,\BLOCKCACHE=>true}describeDescribethenamedtable:e.g.“hbase>describe”t1”“delete Putadeletecellvalueatspecifiedtable/row/columnandoptionallytimestampcoordinates.Deletesmustmatchthedeletedcell”scoordinatesexactly.Whenscanning,adeletecellsuppressesolderversions.Takesargumentslikethe”put”commanddescribedbelowdeleteallDeleteallcellsinagivenrow;passatablename,row,andoptionallyacolumnandtimestampdisable Disablethenamedtable:e.g.“hbase>disable”t1”“drop Dropthenamedtable.Tablemustfirstbedisabledenable Enablethenamedtableexists Doesthenamedtableexist?e.g.“hbase>exists”t1”“exit Type“hbase>exit“toleavetheHBaseShellget Getroworcellcontents;passtablename,row,andoptionallyadictionaryofcolumn(s),timestampandversions.Examples:hbase>get”t1”,”r1”hbase>get”t1”,”r1”,{COLUMN=>”c1”}hbase>get”t1”,”r1”,{COLUMN=>[”c1”,”c2”,”c3”]}hbase>get”t1”,”r1”,{COLUMN=>”c1”,TIMESTAMP=>ts1}hbase>get”t1”,”r1”,{COLUMN=>”c1”,TIMESTAMP=>ts1,VERSIONS=4}list Listalltablesinhbaseput Putacell”value”atspecifiedtable/row/columnandoptionallytimestampcoordinates.Toputacellvalueintotable”t1”atrow”r1”undercolumn”c1”markedwiththetime”ts1”,do:hbase>put”t1”,”r1”,”c1”,”value”,ts1scan Scanatable;passtablenameandoptionallyanarrayofcolumnnamesORanarrayofcolumnnamesANDadictionaryofscannerspecifications.Ifyouwishtoincludescannerspecifications,youmustalsoincludeanarrayofcolumns.Scannerspecificationsmayincludeoneormoreofthefollowing:LIMIT,STARTROW,STOPROW,orTIMESTAMP.Toscanallmembersofacolumnfamily,leavethequalifieremptyasin”col_family:”.Examples:hbase>scan”.META.”hbase>scan”.META.”,[”info:regioninfo”]hbase>scan”t1”,[”c1”,”c2”],{LIMIT=>10,STARTROW=>”xyz”}version OutputthisHBaseversion3、存儲(chǔ)模式，Hbase是基于列存儲(chǔ)的，每個(gè)列族都有幾個(gè)文件保存，不同列族的文件是分別的。傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)是基于表格構(gòu)造和行模式保存的。4Hbase而它舊有的版本仍舊會(huì)保存，所以它實(shí)際上是插入了的數(shù)據(jù)，而不是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)里面的替換修改。5Hbase和Bigtable夠輕易的增加或者削減〔在硬件錯(cuò)誤的時(shí)候〕硬件數(shù)量，而且對(duì)錯(cuò)誤的兼容性比較高。而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)通常需要增加中間層才能實(shí)現(xiàn)類似的功能。當(dāng)前的關(guān)系數(shù)據(jù)庫(kù)根本都是從上世紀(jì)70年月進(jìn)展而來的，它們根本都有一下的體系特點(diǎn)：1234log而Bigtable和Hbase用就是以字符為根底的，Bigtable和Hbase由于其中的時(shí)間戳特性，Bigtable和Hbase與生俱來就特別適合于開發(fā)wiki、archiveorg之類的效勞，而HbaseBigtableGoogle1GoogleAnalytics網(wǎng)站流量分析(analytics.google)〔cookie判定〕，另外一個(gè)就是頁面掃瞄量〔View〕，網(wǎng)站治理員只要在每一個(gè)需要統(tǒng)計(jì)的頁面加上google供給javascript代碼，就可以每天在后臺(tái)看到相關(guān)的統(tǒng)計(jì)信息了。這個(gè)效勞的數(shù)據(jù)保存主要由兩個(gè)打表實(shí)現(xiàn)：第一個(gè)是原始點(diǎn)擊表，記錄了用戶點(diǎn)擊頁面的原始數(shù)據(jù)，這個(gè)表的列包括：網(wǎng)站名稱，url和用戶點(diǎn)擊時(shí)間、ip等資料，按用戶點(diǎn)擊時(shí)間排序，大小掌握在200TB左右，定期需要做壓縮備份等操作。其次個(gè)表就是統(tǒng)計(jì)數(shù)據(jù)表，這個(gè)表是從原始點(diǎn)擊表中計(jì)算而來，定期運(yùn)行批量計(jì)算任務(wù)生成數(shù)據(jù)〔使用Map/Reduce程序〕，20TB左右。2GoogleEarth地圖(maps.google)這個(gè)效勞包括網(wǎng)頁版的google地圖和客戶端版的google地球。用戶通過這些效勞，能選擇不同的區(qū)分率掃瞄地圖、衛(wèi)星照片等數(shù)據(jù)。這個(gè)系統(tǒng)主要包括一個(gè)數(shù)據(jù)處理表，和一系列的數(shù)據(jù)效勞表〔用戶讀取時(shí)候用〕。原始的圖片信息通過程序批量輸入到數(shù)據(jù)處理表，形成格式化數(shù)據(jù)。這個(gè)數(shù)據(jù)處理表的每一行表示了物理地圖上面的每一塊，而鍵值的命名確保這些地理塊是連續(xù)的，由于地理的信息很多，所以有很多列族，根本上每個(gè)列族都有圖片數(shù)據(jù)，多列族確保數(shù)據(jù)是稀疏的，單個(gè)存儲(chǔ)文件不會(huì)太大。后臺(tái)處理程序定期處理這些數(shù)據(jù)，把它們整理并錄入數(shù)據(jù)效勞表，并清空處理過的原始數(shù)據(jù)。需要遍歷全部數(shù)據(jù)表。3、網(wǎng)絡(luò)歷史記錄 (“://google/psearch)“google/psearch)主要功能：查看并搜尋您過去曾訪問過的網(wǎng)頁，包括Google的搜尋記錄。查找有關(guān)網(wǎng)絡(luò)活動(dòng)的搜尋趨勢(shì)，如最常訪問的網(wǎng)站和熱門搜尋等。依據(jù)您搜尋的內(nèi)容以及曾訪問過的網(wǎng)站，獵取更具共性化的搜尋結(jié)果。這個(gè)效勞中的網(wǎng)絡(luò)歷史記錄是需要安裝Google工具欄并在掃瞄器中啟用才能搜集數(shù)據(jù)。id，而每種類型的操作〔搜尋關(guān)鍵字、掃瞄網(wǎng)頁等〕都有一個(gè)不同列族，用戶搜尋記錄是通過后臺(tái)程序從搜尋引擎端批量生成并插入的，而網(wǎng)頁掃瞄記錄是通過用戶的Google工具欄定期上傳數(shù)據(jù)并插入的。同地區(qū)的用戶再建立多個(gè)大表集群，讓用戶可以就近訪問，加快傳輸速度。為了保證用戶之間的共享不會(huì)占用太多資源，我們?yōu)槊總€(gè)用戶加上了簡(jiǎn)潔的配額機(jī)制，分別在客戶端和大表集群上面實(shí)現(xiàn)。結(jié)論：Hbase由于Hbase頭開頭就使用HbaseHbaseapiHbaseJDBC而且最重要的一點(diǎn)是當(dāng)前hbaseapi裝的時(shí)候是hbase-0.1.3，一個(gè)月后版本進(jìn)展到hbase-0.2.0，全部API根本都轉(zhuǎn)變了，連HQLhbase要同時(shí)升級(jí)hadoop，這樣升級(jí)所需要的維護(hù)工作量太大。固然，據(jù)聞HbaseHypertable的目的就是在web應(yīng)用市場(chǎng)上面取代Mysql。1測(cè)試環(huán)境：3臺(tái)效勞器組成的hadoop由一臺(tái)單獨(dú)的機(jī)器單機(jī)模擬Hbase由一臺(tái)機(jī)器單機(jī)測(cè)試Mysql測(cè)試規(guī)模：50萬條記錄以上，單線程、多線程測(cè)試測(cè)試結(jié)果：插入100條記錄插入1000條記錄

HBase155ms/154ms740ms/884ms

Mysql243ms/198ms1506ms/1554ms單線程

插入10000條記錄 8304ms/6610ms插入100000條記錄43090ms/64715ms讀取500000

14110ms/12839m108082ms/110664ms條記錄插入100條記錄1001000條記錄讀取500000條記錄插入100條記錄1000程 讀取500000左右的條記錄

640ms/721ms5929ms/3825ms/4134ms35684ms/52677ms/34208ms最快的1104ms/最慢的110897ms325907ms/322465ms/342163ms最快的717ms

2779ms/2794ms?15352ms/12912ms/12853ms135839ms/161711ms/119909ms假設(shè)不加limit，數(shù)據(jù)庫(kù)連接超時(shí)17455ms/18953ms/15169ms假設(shè)不加limit，數(shù)據(jù)庫(kù)連接超時(shí)HBase不同于一般的關(guān)系數(shù)據(jù)庫(kù),它是一個(gè)適合于非構(gòu)造化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫(kù).另一個(gè)不同HBasechar).上面兩種特性，導(dǎo)致HBase關(guān)聯(lián)，正由于這樣在查詢的時(shí)候效率格外高HBase數(shù)據(jù)表的性能選項(xiàng):MAX_VERSIONS：每一個(gè)單元保存多少版本的數(shù)據(jù)(默認(rèn)是3)MAX_LENGTH：每個(gè)單元中的版本能夠保存多少字節(jié)的數(shù)據(jù)〔默認(rèn)字節(jié)數(shù)是32位有符號(hào)整數(shù)最大值〕COMPRESSION：數(shù)據(jù)壓縮，有BLOCK壓縮和RECORDIN_MEMORYHDFS的備份BLOOMFILTER：假設(shè)這個(gè)列組支持布隆過濾器(BLOOMFILTER),那么在內(nèi)存中有個(gè)索引來快速IO果在這個(gè)列組你擁有大量的列,每一個(gè)列的數(shù)據(jù)包含的數(shù)據(jù)格外小，你可能需要在這個(gè)列組中應(yīng)用布隆過濾器〔BLOOMFILTER〕2測(cè)試目標(biāo)：測(cè)試列族增長(zhǎng)對(duì)性能的影響10005000任意一列。測(cè)試結(jié)果：?jiǎn)螜C(jī)集群列族數(shù)量101005001000建表時(shí)間12.319.245.9Timeout每秒寫入164323419Timeout每秒讀取99139122Timeout5機(jī)器集群列族數(shù)量101005001000建表時(shí)間12.218.746.4Timeout每秒寫入29153376Timeout每秒讀取119111120Timeout測(cè)試結(jié)論：Hbase建表時(shí)間過長(zhǎng)，對(duì)大列族的時(shí)候支持不好寫入速度在多機(jī)集群的時(shí)候提高較快3測(cè)試目標(biāo)：Hbase的行排序是依據(jù)主鍵排序，測(cè)試動(dòng)態(tài)或者反序插入時(shí)候的性能。測(cè)試數(shù)據(jù)：動(dòng)態(tài)生成字母數(shù)據(jù)，zzzzz-aaaaa，還有隨機(jī)插入測(cè)試結(jié)果：?jiǎn)螜C(jī)集群〔每秒多少行〕寫入行10,000100,0001,000,000挨次485432334反序451477354隨機(jī)4624213345機(jī)集群〔每秒多少行〕寫入行10,000100,0001,000,000挨次488440346反序522387343隨機(jī)468441370測(cè)試結(jié)論：承受B樹存儲(chǔ)和寫入緩存，寫入數(shù)量和挨次對(duì)速度影響并不大，應(yīng)當(dāng)只是cpu占用的不同。主要瓶頸還是在網(wǎng)絡(luò)傳輸速度上。4測(cè)試目標(biāo)：測(cè)試大表下的讀取性能測(cè)試數(shù)據(jù)：在肯定規(guī)模的表中隨機(jī)讀取5000條記錄的時(shí)間測(cè)試數(shù)據(jù)：?jiǎn)螜C(jī)集群〔每秒多少行〕規(guī)?！残小?0,000100,0001,000,000讀取9542245機(jī)集群〔每秒多少行〕規(guī)模〔行〕10,000100,0001,000,000讀取953435測(cè)試結(jié)論：讀取速度隨著表規(guī)模的增加而降低，集群模式下面讀取表現(xiàn)比較優(yōu)秀。估量假設(shè)加上數(shù)據(jù)合并以后集群的讀取力量會(huì)更加強(qiáng)勁?？偨Y(jié)：Hypertable和Hbase但是照這個(gè)方向進(jìn)展下去在web應(yīng)用端有很好的前景。Hadoop文件系統(tǒng)相對(duì)較穩(wěn)定，可以考慮在產(chǎn)品中試驗(yàn)。參考文獻(xiàn)：TheHadoopDistributedFileSystem:ArchitectureandDesign“:///core/docs/r0.16.4/hdfs_design.html“:///core/docs/r0.16.4/hdfs_design.htmlHDFSUndertheHoodPresentation1“