十二、hadoop hbase hive pig zookeeper分析報告白皮書

1、Hbase 分析本文基于環(huán)境 hadoop-0.16.4 和 hbase-0.1.3 編寫Hbase 是一個分散式開源數據庫，基于 Hadoop 分散式文件系統，模仿并提供了基于文件系統的 Bigtable 數據庫的所有功能。Hbaes 的目標是處理非常龐大的表，可以用普通的計算機處理超過 10 億行資料，并且有數百萬列元素組成的資料表。Hbase 可以直接使用本地文件系統或者 Hadoop 作爲資料方式，不過爲了提高資料可靠性和系統的健壯性，發(fā)揮 Hbase 處理大資料量等功能，需要使用 Hadoop 作爲文件系統，那麼就先要了解Hadoop 文件系統的基本特性和原理，才能更好地理解 Hba

2、se 的工作方式。Hadoop 文件系統Hadoop 文件系統是一個能夠兼容普通硬件環(huán)境的分散式文件系統， 和現有的分散式文件系統不同的地方是 Hadoop 更注重容錯性和兼容廉價的硬設備，這樣做是爲了用很小的甚至直接利用現有機器就實現大流量和大資料量的。Hadoop 使用了原來是 Apache NIX 的設計來實現對文件系統文件流的。HDFS（Hadoop FileSystem）h 搜索引擎（從 Lucene 發(fā)展而來）開發(fā)的一個部分，后來獨立出來作爲一個 Apache 子項目。Hadoop 的假設與目標1、 硬件出錯，Hadoop 假設硬件出錯是一種正常的情況，而不是異常，爲的就是在硬件出

3、錯的情況下盡量保證資料完整性，HDFS 設計的目標是在成百上千臺服務器中料，并且可以快速檢測出硬件錯誤和快速進行資料的自動恢復。資2、 流資料讀寫，不同于普通的文件系統，Hadoop 是爲了程序批量處理資料而設計的，而不是與用戶的交互或者隨機讀寫，所以IX 對程序增加了許多硬性限制，程序必須使用流來提高資料吞吐率。3、 大資料集，HDFS 上面一個典型的文件一般是用 GB 或者 TB 計算的，而且一個數百臺機器組成的集群里面可以支援過千萬這樣的文件。4、 簡單的文件模型，HDFS 上面的文件模型十分簡單，就是一次寫入多次的模型，文件一旦創(chuàng)建，寫入并關閉了，之后就再也不會被改變了，只能被合搜索引

4、擎的需求，以后可能會實現追加寫入資料這樣的功能。，這種模型剛好符5、 強大的跨兼容性，由于是基于 java 的實現，無論是硬件或者是要求都不高，只要是 jdk 支援的都可以兼容。Hadoop 體系結構目錄節(jié)點（NameNode）和資料節(jié)點（DataNodes）Hadoop 文件系統是主從架構，一個 Hadoop 文件系統由唯一一個目錄節(jié)點和數個資料節(jié)點組成。Hadoop 文件系統對外表現爲一個普通的文件系統，用戶可以用文件名去和文件，而實際上文件是被分成不同的資料塊，這些資料塊就是在資料節(jié)點上面。目錄節(jié)點是集群里面的主節(jié)點，負責文件名的管理，也是用戶端文件的。文件關名的包括文件和目錄的創(chuàng)建、刪

5、除、重命名等。同時也管理資料塊和資料節(jié)點的系，用戶端需要目錄節(jié)點才能知道一個文件的所有資料塊都保存在哪些資料節(jié)點上。資料節(jié)點一般就是集群里面的一臺機器，負責資料的和。在寫入時，由目錄節(jié)點分時，當用戶端從目錄節(jié)點獲配資料塊的保存，然后用戶端直接寫到對應的資料節(jié)點。在得資料塊的關系后，就會直接到對應的資料節(jié)點資料。資料節(jié)點也要根據目錄節(jié)點令創(chuàng)建、刪除資料塊，和冗余。一個典型的Hadoop 文件系統集群部署，是由一臺性能較好的機器運行目錄節(jié)點，而集群里面的其他機器每臺上面運行一個資料節(jié)點。當然一個機器可以運行任意多個資料節(jié)點，甚至目錄節(jié)點和資料節(jié)點一起運行，不過這種模式在正式的應用部署中很少使用。唯

6、一的目錄節(jié)點的設計大大簡化了整系結構，目錄節(jié)點負責Hadoop 文件系統里面所有元資料的仲裁和。這樣的設計使資料不會脫離目錄節(jié)點的控制。Hadoop 文件系統命名空間Hadoop 文件系統使用的是傳統的分級文件體系，用戶端程序可以創(chuàng)建目錄并且在目錄里面保存文件，類似與現在一般的文件系統。Hadoop 允許用戶創(chuàng)建、刪除文件，在目錄間轉移文件，重命名文件等，但是還沒有實現磁盤和文件權限等功能，也不支援文件的硬連接和軟連接（快捷方式），這些功能在短期內不會實現。目錄節(jié)點負責和管理整個文件系統名空間，應用程序可以指定某一個文件需要在Hadoop 文件系統中冗余多少份，這個在 Hadoop 中稱爲冗余

7、，保存在目錄節(jié)點里面。Hadoop原理冗余數據保存Hadoop 文件系統是爲了大文件的可靠保存而設計的，一個文件被劃分成一連串的資料塊，除了文件的最后一塊以外其他所有的資料塊都是固定大小的，爲了資料容錯性，每一個資料塊都會被冗余起來，而每個文件的塊大小和冗余都是可以設置的，程序可以設置文件的資料塊要被多少份，而且這個冗余除了可以在創(chuàng)建的時候指定，還可以在之后改變。在 Hadoop 文件系統里面文件只會被寫入一次，并且任何時間只會有一個程序在寫入這個文件。目錄節(jié)點是根據資料塊的冗余狀況來作出處理決策的，資料節(jié)點會定期發(fā)送一個存在信號（Heartbeat）和資料塊列表給目錄節(jié)點，存在信號使目錄節(jié)點

8、認爲該資料節(jié)點還是有效的，而資料塊列表包括了該資料節(jié)點上面的所有資料塊。資料存取策略策略是 hadoop 文件系統最的部分，對讀寫性能影響很大，hadoop 和其他分散式文件系統的最大區(qū)別就是可以調整冗余數據的位置，這個特性需要很多時間去優(yōu)化和調整。一、資料存放目前 hadoop 采用以機柜爲基礎的資料存放策略，這樣做的目的是提高資料可靠性和充分利用網絡帶寬。當前具體實現了的策略只是這個方向的嘗試，hadoop 短期的研究目標之一就是在實際産品環(huán)境中觀察系統讀寫的行爲，測試性能和研究更深入的規(guī)則。一個大的 hadoop 集群經常橫跨多個機柜，而不同機柜之間的資料通訊同經過交換機或者路由，所以同

9、一個機柜中不同機器的通訊帶寬是比不同機柜之間機器通訊時候的大。Hadoop 提供了一個 api 來決定資料機所屬的機柜 id，當文件系統啓動的時候，資料機就把自己所屬的機柜 id 發(fā)給目錄機，然后目錄機管理這些分組。Hadoop 默認是每個資料機都是在不同的機柜上面，這種方法沒有做任何性能優(yōu)化，但是也有不少優(yōu)點：1、 資料可靠性是最高的。因爲這樣可以防止機柜出錯的時候資料丟失。2、 在資料的時候充分利用不同機柜之間的帶寬。3、 而且這個策略可以很容易的完成負載平衡和錯誤處理。缺點就是寫入資料的時候并不能完全利用同一機柜里面機器的帶寬。在默認的配置下，hadoop 的冗余因子是 3，意思就是每一

10、塊文件資料一共有 3 個地方存放，hadoop 目前的存放策略是其中兩份放在同一個rack id 的不同機器上面，另外一個放在不同 rack id 的機器上面，簡單來說就是 1/3 的冗余數據在一個機柜里面，2/3 的冗余數據在另外一個機柜里面，這樣既可以防止機柜異常時候的資料恢復，又可以提高讀寫性能。上面所說的策略目前還是在測試優(yōu)化階段。二、資料資料策略，根據前面所說的資料存放策略，資料的時候，用戶端也有api 確定自己的機柜 id，的時候，如果有塊資料和用戶端的機柜 id 一樣，就優(yōu)先選擇該資料節(jié)點，用戶端直接和資料節(jié)點建立連接，資料。如果沒有，就隨機選取一個資料節(jié)點。三、資料主要是在資料

11、寫入和資料恢復的時候發(fā)生，資料是使用流水線的策略。當用戶端要在 hadoop 上面寫一個文件，首先它先把這個文件寫在本地，然后對文件進行分塊，默認 64m 一塊，每塊資料都對 hadoop 目錄服務器請求，目錄服務器選擇一個資料機列表，返回給用戶端，然后用戶端就把資料寫入第一臺資料機，并且把列表傳給資料機，當資料機接收到 4k 資料的時候，寫入本地并且發(fā)起連接到下一臺資料機，把這個 4k 傳過去，形成一條流水線。當最后文件寫完的時候，資料也同時完成，這個就是流水線處理的優(yōu)勢。通訊協定hadoop 的通訊協定基本是在 tcp/ip 的基礎上開發(fā)的，用戶端使用 CntProtocol 和目錄服務器

12、通訊，資料機使用 DatanodeProtocol 和目錄服務器通訊，而目錄服務器一般只是應答用戶端和資料機的請求，不會主動發(fā)起通訊。資料錯誤和異常hadoop 文件系統的主要目標就是在硬件出錯的時候保證資料的完整性，它把磁盤錯誤作爲肯定會出現的情況來對待，而不是異常。一般資料務器錯誤，資料機錯誤，和網絡傳輸異常。中出現的錯誤有幾種，分別是目錄服1、 資料機出錯，每個資料機會定時發(fā)送一個心跳信息給目錄服務器，表明自己仍然存活，網絡異常可能會導致一部分資料機無法和目錄服務器通訊，這時候目錄服務器收不到心跳信息，就認爲這個資料機已經死機，從有效 io 列表中清除，而該資料機上面的所有資料塊也會標記

13、爲不可讀。這個時候某些資料塊的冗余份數有可能就低于它的冗余因子了，目錄服務器會定期檢查每一個資料塊，看看它是否需要進行資料冗余。2、 出現資料異常，由于網絡傳輸和磁盤出錯的原因，從資料機的資料有可能出現異常，用戶端實現對資料塊的校驗，用 md5 和 sha1 進行校驗，用戶端在創(chuàng)建文件的時候，會對每一個文件塊進行信息摘錄，并把這些信息寫入到同一個路徑的隱藏文件里面。當用戶端文件的時候，會先該信息文件，然后對每個的資料塊進行校驗，如果校驗出錯，用戶端就會請求到另外一個資料機該文件塊，并且給目錄服務器這個文件塊有錯誤，目錄服務器就會定期檢查，并且重新這個塊。3、 目錄服務器出錯，FsImage 和

14、Editlog 是目錄服務器上面兩個最的資料結構，如果其中一個文件出錯的話，會造成目錄服務器不起作用，由于這兩個文件如此重要，所以目錄服務器上面可以設置多個備份和輔助服務器，當這兩個文件有改變的時候，目錄服務器就會發(fā)起同步操作，雖然這樣增加了系統的負擔，但是在目前這個架構上面爲了實現資料的可靠性，這個同步操作是非常必要的。Hadoop 文件系統尚未實現的功能總結：1、 文件追加寫入，這個功能近期內不會實現，沒有這個功能會引起當文件尚未關閉的時候，資料服務器死機或者目錄服務器死機，會引起文件文件丟失，并且不可后續(xù)恢復寫入。2、 系統快照，一個全系統的快照功能，如果沒有這個功能就不能實現文件系統的

15、回滾操作。3、 集群負載均衡，均衡策略暫時沒有實現，有幾個策略十分有用，比如在某臺資料機可能磁盤過低的時候，把該資料機上面的一些資料轉移到還有很多空間剩余的資料機上；當某個文件突然被大量讀寫的時候，動態(tài)增加該文件的冗余因子，并且資料塊到的資料機上面，以提高性能。4、 文件系統的用戶權限，這個也是近期內不會實現的了。5、權限，現在是的，沒有權限控制。Hadoop 文件系統性能分析由于沒辦法建立大型的 Hadoop 文件系統，只能節(jié)選一些網上的性能分析，以表示一二。1、 和 Kosmos Filesystem 的比較，Kosmos Filesystem 也是一個類似文件系統的具體實現，所以和 Ha

16、doop 具有比較的意義。KFS 是用 c+編寫的，在代碼執(zhí)行效率上面比 java 好不少。資料測試：測試環(huán)境：1 1.8GHz Dual-core Opteron Pro4 GB RAMsor 22104 7200 RPM SATA drives (mounted JBOD)測試使用 Hypertable，這也是一個類似bigtable 的具體實現，可以使用 KFS和 HDFS 作爲文件系統，在測試后，表格含有 75,274,825 個資料單元，每一個鍵值是 7 字節(jié)大小，每一個資料是 15 字節(jié)大小。：KFS 基本大幅度勝出。HDFS (no flush)Elapsed time: Avg

17、 value size: Avg key size:Throughput:Total inserts: Throughput:170.66 s15.25 bytes7.10 bytes 1792158.60 bytes/s 1482527986869.79 inserts/sElapsed time: Avg value size: Avg key size:Throughput: Total inserts:Throughput:167.44 s15.26 bytes7.11 bytes 1871062.70 bytes/s 1518534990690.84 inserts/sElapsed

18、 time: Avg value size: Avg key size:Throughput: Total inserts:Throughput:179.91 s15.20 bytes7.03 bytes 1737888.10 bytes/s 1520831084532.68 inserts/sElapsed time:169.57 sAvg value size: Avg key size:Throughput: Total inserts:Throughput:15.22 bytes7.11 bytes 1831688.52 bytes/s 1508092688937.45 inserts

19、/sKFS (no flush)Elapsed time: Avg value size: Avg key size:Throughput: Total inserts:Throughput:125.51 s15.25 bytes7.10 bytes 2436864.83 bytes/s 14825279118120.09 inserts/sElapsed time: Avg value size: Avg key size:Throughput:Total inserts: Throughput:126.25 s15.26 bytes7.11 bytes 2481447.59 bytes/s

20、 15185349120276.33 inserts/sElapsed time: Avg value size: Avg key size:Throughput:Total inserts: Throughput:135.51 s15.20 bytes7.03 bytes 2307335.26 bytes/s 15208310112231.19 inserts/sElapsed time: Avg value size: Avg key size:Throughput:Total inserts: Throughput:127.66 s15.22 bytes7.11 bytes 243306

21、9.68 bytes/s 15080926118137.45 inserts/s2、 Hadoop測試，與本地文件系統比較使用 hadoop 自帶的 Fiench 程序，寫入兩個 1g 大小的文件，第一個是字節(jié)流文件，隨機生成，第二個是字符文件，隨機字典生成。下面是本地文件系統和 hadoop 文件系統的比較，由于集群是在條件下測試，目錄服務器在廣州網通機房，兩臺資料服務器一臺在電信機房，一臺在好很多。網通機房，所以測試的瓶頸基本在網絡傳輸，估計在局域網中表現應該本地文件系統測試：javahadoop-0.16.4-test.jar:hadoop-0.16.5-de-classpath mon

22、s-logging-api-1.0.4 mons-cli-2.0-SNA/home/ssmax/test -nolzo -nozip.jar:lib/log4j-mons-loggingench -dirPSHOT.jar.apache.hadoop.io.FiDIR: file:/home/ssmax/testW W RRSEQ_PLN: TXT_PLN: SEQ_PLN:TXT_PLN:42312521seconds seconds secondsseconds第一行是流文件寫入，第二行是文字取。寫入，第三行是流文件，第四行是文字讀Hadoop 文件系統測試：javabuild/hadoo

23、p-0.16.5-dev-test.jar:hadoop-0.16.5-de-classpath mons-loggingmons-c-dir-api-1.0.4.jar:lib/log4j-li-2.0-SNAPSHOT.jarmons-logging.apache.hadoop.io.Fienchhdfs:/38:9000/user/ssmax -now -nolzo -nozipDIR: hdfs:/38:9000/user/ssmaxW W RRSEQ_PLN: TXT_PLN: SEQ_PLN:TXT_PLN:437 seconds439 seconds15 分鐘15 分鐘由于測試用

24、戶端上行比下行快很多，所以的時候很慢，超過了可以接受的時間，如果在資料機做讀操作，java速度會大大提高。-classpath mons-logging-api-1mons-cli-2.0-dirhadoop-0.16.5-dev-test.jar:hadoop-0.16.5-de.0.4.jar:lib/log4j-SNAPSHOT.jarmons-logging.apache.hadoop.io.Fienchhdfs:/38:9000/user/ssmax hdfs:/38:9000/user/ssmaxR SEQ_PLN: 80 secondsR TXT_PLN: 63 seconds-

25、now-nolzo-nozipDIR:所以得出結論就是 rack id 的配置十分重要，需要區(qū)分機柜，傳輸的瓶頸主要在網絡。上面就是關于 Hadoop 文件系統的原理和測試，Hbase 可以通過配置使用本地文件系統或者Hadoop 文件系統。而測試的過程中也發(fā)現了一個更成組合，也是開源項目的 Hypertable和 KFS，這兩個也是類似 Bigtable 和 GFS 的實現，主要是使用 c+實現的，這里先下，以后再做研究。一Hypertable 作者語:Hypertable 與 HBase 的差別是，Hypertable 是Bigtable 的一個更高性能的實現（InfoQ同樣采訪了 HBa

26、se 的團隊）。我開始的時候跟 Jim Kellerman 以及 Hadoop 團隊的一些成員一起爲 HBase 工作。但對 HBase 應該變成什麼樣子有不同意見，對實現語言的選擇也有不同意見。他們堅持用 Java，而我力推 C+。于是我就分出來，開始了 Hypertable 項目。Hbase 分散式數據庫資料模型Hbase 是一個類似 Bigtable 的分散式數據庫，大部分特性和 Bigtable 一樣，是一個稀疏的，長期的存在硬盤上，度的，排序的表。這的索引是行關鍵字，列關鍵字和時間戳。每個值是一個不解釋的字符陣列，資料都是字符串，沒類型。用戶在表格中所以同一資料，每一行都有一個可排序

27、的主鍵和任意多的列。由于是稀疏的，里面的每一行資料都可以有截然不同的列。列名字的格式是:，都是由字符串組成，每一有一個 family 集合，這個集合是固定不變的，相當于表的結構，只能通過改變表結構來改變。但是 label 值相對于每一行來說都是可以改變的。Hbase 把同一個 family 里面的資料在同一個目錄，而Hbase 的寫操作是鎖行的，每一行都是一個原子元素，都可以加鎖。所有數據庫的更新都有一個時間戳標記，每個更新都是一個新的版本，而 hbase 會保留一定數量的版本，這個值是可以設定的。用戶端可以選擇獲取距離某個時間最近的版本，或者一次獲取所有版本。概念視圖：一個表可以想象成一個大

28、的關系，通過主鍵，或者主鍵+時間戳，可以定位一行資料，由于是稀疏資料，所以某些列可以是空白的，下面就是資料的概念視圖：Row KeyTime StColumncontents:Column anchor:Columnmime:n.wwwt9t8anchor:my.look.cat6.text/htmlt5.t3.上圖是一個Web 網頁的范例列表片斷。行名是一個反向URL即n.www。contents列族原文用 family，譯爲族，詳見列族存放網頁內容，anchor 列族存放該網頁的錨鏈結文本。的主頁被 Sports Illustrater即所謂 SI，的王牌體育和 MY-look的主頁，因此

29、該行包含了名叫“”和 “anchhor:my.look.ca”的列。每個錨鏈結只有一個版本由時間戳標識，如 t9，t8；而 contents 列則有三個版本，分別由時間 戳t3，t5，和 t6 標識。物理視圖雖然從概念視圖來看每個表格是由很多行組成，但是在物理的，這點在資料設計和程序開發(fā)的時候必須牢記。上面，它是按照列來保存上面的概念視圖在物理的時候應該表現成下面那樣子：需要注意的是在概念視圖上面有些列是空白的，這樣的列實際上并不會被空白的單格的時候，會返回 null 值。，當請求這些如果在查詢的時候不提供時間戳，那麼會返回距離現在最近的那一個版本的資料。因爲在存儲的時候，資料會按照時間戳排序

30、。例子：一個程序寫 9 行資料，row0-9，先寫入 anchor:foo 列，再寫入 anchor:bar 列，最后重復寫入 anchor:foo 列，由于是同一個列族，寫到同一個這個樣子的：文件里面，最后寫到文件里面是row=row0, column=anchor:bar, timest =1174184619081 row=row0, column=anchor:foo, timest =1174184620720 row=row0, column=anchor:foo, timest =1174184617161 row=row1, column=anchor:bar, timest

31、=1174184619081Row KeyTime StColumn mime:n.wwwt6text/htmlRow KeyTime StColumn anchor:n.wwwt9t8anchor:my.look.caRow KeyTime StColumn contents:n.wwwt6.t5.t3.row=row1, column=anchor:foo, timest=1174184620721row=row1, column=anchor:foo, timest=1174184617167row=row2, column=anchor:bar, timest=117418461908

32、1row=row2, column=anchor:foo, timest=1174184620724row=row2, column=anchor:foo, timest=1174184617167row=row3, column=anchor:bar, timest=1174184619081row=row3, column=anchor:foo, timest=1174184620724row=row3, column=anchor:foo, timest=1174184617168row=row4, column=anchor:bar, timest=1174184619081row=r

33、ow4, column=anchor:foo, timest=1174184620724row=row4, column=anchor:foo, timest=1174184617168row=row5, column=anchor:bar, timest=1174184619082row=row5, column=anchor:foo, timest=1174184620725row=row5, column=anchor:foo, timest=1174184617168row=row6, column=anchor:bar, timest=1174184619082row=row6, c

34、olumn=anchor:foo, timest=1174184620725row=row6, column=anchor:foo, timest=1174184617168row=row7, column=anchor:bar, timest=1174184619082row=row7, column=anchor:foo, timest=1174184620725row=row7, column=anchor:foo, timest=1174184617168row=row8, column=anchor:bar, timest=1174184619082row=row8, column=

35、anchor:foo, timest=1174184620725row=row8, column=anchor:foo, timest=1174184617169row=row9, column=anchor:bar, timest=1174184619083row=row9, column=anchor:foo, timest=1174184620725row=row9, column=anchor:foo, timest=1174184617169其中 anchor:foo 被保存了兩次，由于時間戳不同，是兩個不同的版本，而的資料排在前面，所以那次更新會先被找到。分散式數據庫體系結構Hba

36、se 的服務器體系結構也是遵從簡單的主從服務器架構，又 Hregion 服務器群和 HBaseMaster 主服務器。Hregion 服務器對用戶來說，每個表是一堆資料的集合，靠主鍵來區(qū)分。物理上，一是被拆分成多塊，每一塊就稱呼爲一個Hregion。用表名+開始/結束主鍵，來區(qū)分一個 Hregion，一個 Hregion會保存一個表里面某段連續(xù)的資料，從開始主鍵到結束主鍵，一張完整的表格是保存在多個Hregion 上面的。所有的數據庫資料一般是保存在 Hadoop 分散式文件系統上面，用戶通過一系列 Hregion服務器獲取這些資料，一般一臺機器上面運行一個Hregion 服務器，而每一個區(qū)段

37、 Hregion只會被一個Hregion 服務器。當用戶需要更新資料的時候，他會被分配到對應的 Hregion 服務器提交修改，這些修改先是被寫到 Hmemcache 緩存和 服務器的 Hlog 文件里面，Hmemcache 是在器中的緩存，保存最近更新的資料，Hlog 是磁盤上面的文件，它著所有的更新操作，當操作寫入 Hlog 之后，commit()調用才會返回給用戶端。當資料的時候，Hregion 服務器會先Hmemcache 緩存，如果緩存里面沒有該資料，才回到 Hstores 磁盤上面尋找，每一個列族都會有一個 Hstore 集合，每個Hstore 集合包含很多 HstoreFiles

38、 具體文件，這些文件都是 B 樹結構的，方便快速。系統會定期調用 HRegion.flushcache()個新的 HstoreFile 文件，而此時快取上面的內容已經被寫入到文件中保存。把緩存里面的內容寫到文件中，一般這樣會增加一器就會被清空，并且寫入一個標記到 Hlog，表示在啓動的時候，每個 Hregion 服務器都會檢查自己的 Hlog 文件，看看最近一次執(zhí)行flushcache 之后有沒有新的更新寫入操作。如果沒有更新，就表示所有資料都已經更新到文件中了；如果有更新，服務器就會先把這些更新寫入快取器，然后調用 flushcache 寫入到文件。最后服務器會刪除舊的 Hlog 文件，并開

39、始給用戶資料。因此，爲了節(jié)省時間可以很少調用 flushcache，但是這樣會增加器占用，而且在服務器重啓的時候會延長很多時間。如果可以定期調用 flushcache，緩存大小會控制在一個較低的水平，而且 Hlog 文件也會很快地重構，但是調用 flushcache 的時候會造成系統負載瞬間增加。Hlog 會被定期回滾，回滾的時候是按照時間備份，每當回滾的時候，系統會刪除那些已經被寫到文件的更新，回滾Hlog 只會占用很少的時間，建議經常回滾以減少文件尺寸。每一次調用 flushcache 會生成一個新的HstoreFile 文件，從一個 Hstore 里面獲取一個值都需要所有的 Hstore

40、File 文件，這樣十分耗時，所以要定期把這些分散的文件合并pact()就可以完成這樣的工作。這樣的合并工作是十分占用到一個大文件里面，資源的，當HstoreFile 文件的數量超過一個設定值的時候才會觸發(fā)。的 Bigtable 有高級合并和低級合并的區(qū)別，但是 Hbase 沒有這個概念，只要記住下面兩點就可以了：1、flushcache 會建立一個新的 HstoreFile 文件，并把緩存中所有需要更新的資料寫到文件里面，flushcache 之后，log 的重建次數會清零。2、compact 會把所有 HstoreFile 文件合并成一個大文件。3、和 Bigtable 不同的是，Hbas

41、e 每個更新如果是被正確提交了，commit 沒有返回錯誤的話，它就一定是被寫到文件里面了，這樣不會造成資料丟失。兩個 Hregion 可以通過調用 HRegion.closeAndMerge()合并成一個新的 Hregion，當前版本這個操作是需要兩臺Hregion 都停機才能操作。當一個 Hregion 變得太過巨大的時候，超過了設定的閾值， HRegion 服務器會調用HRegion.closeAndSplit()，這個 Hregion 會被拆分爲兩個，并且給主服務器讓它決定由哪個 Hregion 服務器來存放新的 Hregion。這個拆分過程是十分迅速的，因爲兩個新的Hregion 最

42、初只是保留原來 HregionFile 文件的服務的狀態(tài)，當新的Hregion 合并完成并且把，而這個時候舊的 Hregion 會處于停止刪除了以后，舊的 Hregion 才會刪除。最后總結幾點：1、用戶端以表格的形式資料2、一是被劃分成多個 Hregion 區(qū)域3、Hregion 是被 Hregion 服務器管理的，當用戶端需要對應的 Hregion 服務器。4、Hregions 服務器里面有三種方式保存資料：某行資料的時候，需要A、 Hmemcache 快取器，保留是寫入的資料B、Hlog文件，保留的是提交成功了，但未被寫入文件的資料C、 Hstores 文件，資料的物理存放形式。Hbas

43、e 主服務器每個 Hregion 服務器都會和 Hmaster 服務器通訊，Hmaster 的主要任務就是要告訴每個Hregion 服務器它要哪些Hregion。Hmaster 服務器會和每個 Hregion 服務器保持一個長連接。如果這個連接超時或者斷開，會導致：A、Hregion 服務器自動重啓。B、Hmaster 認爲 Hregion 已經死機，同時把它負責的 Hregion 分配到其他Hregion 服務器。的 Bigtable 不同的是，當 Bigtable 的 TabletServer 和主服務器通訊中斷的情況和下，它仍然能提供服務。而Hbase 不能這麼做，因爲Hbase 沒有

44、Bigtable 那樣額外的加鎖系統，Bigtable 是由主服務器管理 TabletServer，同時加鎖服務器提供資料只有唯一一個接入點，就是Hmaster 服務器。的，而 Hbase當一個新的 Hregion 服務器登陸到 Hmaster 服務器，Hmaster 會告訴它先等待分配資料。而當一個Hregion 死機的時候，Hmaster 會把它負責的 Hregion 標記爲未分配，然后把它們分配到其他Hregion 服務器。元資料表之前Hregion 是按照表名和主鍵范圍區(qū)分的，由于主鍵范圍是連續(xù)的，所以一般用開始主鍵就可以表達出來。但是如果只要開始主鍵還是不夠的，因爲有合并和分割操作，

45、如果正好在執(zhí)行這些操作的過程中出現死機，那麼就可能存在多份表名和開始主鍵一樣的資料，這個就要通過 Hbase了，爲了區(qū)分這樣的情況，每個 Hregion的元資料信息來區(qū)分哪一份才是正確的資料都有一個regionId來標識它的唯一性。所以一個 Hregion 的表達符最后是 表名+開始主鍵+唯一 id（tablename + startkey +regionId）舉個例子：hbasereitory,w-nk5YNZ8TBb2uWFIRJo7V=,7可以用這個識別符來區(qū)分不同的Hregion，這些資料就稱呼爲元資料，而元資料本身也是被保存在Hregion 里面的，和實際 Hregion 服務器的稱

46、呼這個表爲元資料表，里面保存的就是 Hregion 標識符關系。元資料表本身也會增長，并且可能被分割爲幾個 Hregion，爲了定位這些 Hregion，有一個根資料表（ROOT table），保存了所有元資料表的位置，而根資料表是不能被分割的，之存在一個Hregion。在 Hbase 啓動的時候，主服務器先去掃描根資料表，因爲這個表只會有一個 Hregion，所以這個 Hregion 的名字是被寫死的。當然要把根資料表分配到一個 Hregion 服務器需要一定的時間。當根資料表被分配好之后，主服務器就會去掃描根資料表，獲取元資料表的名字和位置，然后把元資料表分配到不同的Hregion 服務器

47、。最后就是掃描元資料表，找到所有Hregion 區(qū)域的信息，然后把它們分配給不同的 Hregion服務器。主服務器在器中保存著當前活躍的 Hregion 服務器的資料，因此如果主服務器死機的話，整個系統也就無法了，而服務器的信息也沒有必要保存到文件里面。元資料表和根資料表的每一行都包含一個列族，info 列族：info:regioninfo 包含了一個串列化的 HregionInfo 物件。info:server 保存了一個字符串，是服務器位址 HServerAddress.toString()info:startcode 一個長整型的數位的字符串，是Hregion 服務器啓動的時候傳給主服務

48、器的，讓主服務器決定這個 Hregion 服務器的信息有沒有更改。因此，當一個用戶端拿到根資料表位址以后，就沒有必要再連接主服務器了。主服務器的負載相對就小了很多，它只會處理超時的 Hregion 服務器，在啓動的時候掃描根資料表和元資料表，和返回根資料表的 Hregion 服務器位址。因此 Hbase 的用戶端是十分復雜的，它經常需要瀏覽元資料表和根資料表，在查詢表格的時候，如果一個Hregion 服務器死機或者它上面的資料更改了，用戶端就會繼續(xù)重試，用戶端保留的關系并不會一直正確的。這里的機制還需要進一步完善。總結：1、Hregion 服務器提供 Hregion面。，一個 Hregion

49、只會保存在一個 Hregion 服務器上2、 Hregion 會到主服務器上面。3、 如果主服務器死機，那麼整個系統都會無效。4、 當前的 Hregion 服務器列表只有主服務器知道。5、 Hregion 區(qū)域和 Hregion 服務器的對應關系保存在兩個特別的 Hregion 里面，它們像其他 Hregion 一樣被分配到不同的服務器。6、 根資料表是最特別的一個表，主服務器知道它的位置（在程序中寫死）7、 用戶端需要自己瀏覽這些表，來找到資料在哪里。Hbase 和傳統關聯數據庫的對比分析Hbase 是大大不同于以前的關聯數據庫，它是按照 Bigtable 來開發(fā)的，套用一個 Bigtabl

50、e的定義就是：A Bigtable is a sparse, distributed, persistent multidimenal sorted map.Bigtable 是一個稀疏的，分布的，持續(xù)度的排序陣列。Hbase 就是這樣一個基于列模式的它大大簡化了傳統的關聯數據庫。數據庫，它只能表示很簡單的鍵-資料的關系，1、資料類型，Hbase 只有簡單的字符串類型，所有類型都是交由用戶自己處理，它只保存字符串。而關聯數據庫有豐富的類型選擇和方式。2、資料操作，Hbase 操作只有很簡單的、查詢、刪除、清空等，表和表之間是分離的，沒有復雜的表和表之間的關系，所以也不能也沒有必要實現表和表之間

51、的關聯等操作。而傳統的關系資料通常有各種各樣的函數、連接操作。Hbase 的操作列表：alterAlter column family schema; pass table name and a dictionaryspecifying new column family schema. Dictionaries are describedbelowERAL NOTES section. Dictionary must include nameof column familycell VERfamily to alter. For exle, to change the f1 columnab

52、le t1 from defaults to instead keep aS, do:um of 5hbase alter t1, NAME = f1, VERS = 5countCount the number of rows in a table. This operation may take a LONG time (Run $HADOOP_HOME/bin/hadoop jar hbase.jar rowcount to run acounting mapreduce job). Current count is shown every 1000 rows bydefault. Co

53、unterval may be optionally specified. Exles:hbasehbasecount t1count t1,100000createCreatecolumntable; passfamily, andtable name, a dictionary of specifications peroptionally a dictionary of table configuration.Dictionaries are described belowERAL NOTES section.Exles:hbase hbase hbase hbasehbasecreat

54、e t1, NAME =create t1, NAME = # The above in shorf1, VERS = 5f1, NAME = f2, NAME = f3nd would be the following:create t1, f1,create t1, NAMEf2, f3= f1, VERS = 1, TTL = 2592000, BLOCKCACHEDescribe the= truenamed table:describee.g. hbase describe t1deletePut a deletecell value at specifiedtable/row/co

55、lumn and optionally match the deleted cellsa delete cell suppresses oldertimestcoordinates. Deletes mustcoordinates exactly. When scanning,vers. Takes arguments like the putd described belowdeleteall Delete all cells in a given row; pass a table name, row, and optionallya column and timestdisableDis

56、able the named table: e.g. hbase disable t1dropDrop the named table. Tablemustbe disabledenableEnable the named tableexistsDoes the named table exist?e.g. hbase existst1exitType hbase exit to leavethe HBase SgetGet row or cell contents; pass table name, row,and optionallya dictionary of column(s), t

57、imestand vers. Exles:hbase hbase hbasehbaseget get getgett1,t1,t1,t1,r1 r1,r1,r1,COLUMNCOLUMNCOLUMN=c1c1, c2, c1, TIMESTc3= ts1= ts1, VERhbase get t1, r1, COLUMN = c1, TIMESTS = 4listList all tables in hbaseputPut a cell value at specified table/row/column and optionallytimestcoordinates. To put a c

58、ell valueo table t1 atrow r1 under column c1 marked with the time ts1, do:hbase put t1, r1, c1, value, ts1scanScan a table; pass table name and optionally an array of column names OR an array of column names AND a dictionary of scanner specifications. If you wish to include scanner specifications, y

59、ou must also include an array of columns. Scanner specificationsmay include one or more of the following: LIMIT, STARTROW, STOPROW,or TIMEST. To scqualifier empty as inl members of a column family, leave thecol_family:. Exles:hbasehbase hbasescanscan scan.META.META.,info:regioninfot1, c1, c2, LIMIT

60、= 10, STARTROW = xyzver3、Output this HBase ver模式，Hbase 是基于列的，每個列族都有幾個文件保存，不同列族的文件是分離的。傳統的關聯數據庫是基于表格結構和行模式保存的。4、 資料，Hbase 的更新正確來說應該不叫更新，而且一個主鍵或者列對應的新的版本，而它舊有的版本仍然會保留，所以它實際上是里面的替換修改。了新的資料，而不是傳統關聯數據庫5、 可伸縮性，Hbase 和 Bigtable 這類分散式數據庫就是直接爲了這個目的開發(fā)出來的，能夠輕易的增加或者減少（在硬件錯誤的時候）硬件數量，而且對錯誤的兼容性比較高。而傳統的關聯數據庫通常需要增加中