Hbase在hdfs上有一個可配置的根目錄，默認是"/hbase"。

?

Root-level files： WAL 的文件：由HLog實例控制，創建在hbase根目錄的.logs目錄。這個目錄為每個HRegionServer創建了一個子目錄。在每個子目錄下面有HLog的文件。所有的regions共享本臺regionserver的HLog文件。 有時候會有這樣的現象：hadoop fs -lsr ./hbase/logs 會發現有的log文件是0。當這個文件是最近建立的時候相當的典型，因為hdfs正使用嵌入的附加的支持去往這個文件里面寫東西（那段英文不太理解HDFS?is using built-in?append?support towrite to this file），并且只有完整的數據塊對讀者可用的，包括hadoop fs -ls 這種命令的查看。盡管put操作的數據已經安全的持久化的，但是當前正在寫log file的大小還是被輕微的關掉了。 之后等一個小時使得logfile is rolled，這個時候就能看到真是大小，這個時候它被關閉了，hdfs可以加載現在的大小了。下一個新的log file又開始從0開始。 當一個logfile不再被需要，因為所有包含的編輯都已經被持久化到store files了，logs將被移動到.oldlogs下面。當logfile 基于配置的閥值被 rooled的時候被觸發。 old log每10分鐘（默認）由master進行刪除（hbase.master.logcleaner.ttl這個參數可以配置）。 ?master會每10分鐘檢查一次這些文件（默認），這個參數hbase.master.cleaner.interval可以進行配置。 Table-level files: 每個表在hbase上都有一個自己的目錄在hbase的根目錄下面。 Region-level files： 在每個表目錄的下面，每個region有一個獨立的目錄構成整個表。那些目錄的名是MD5哈希值分給每個region的名。 -ROOT-,.META.表的目錄名使用的是老的風格，不使用哈希，使用結尾點。 在硬盤上的目錄region的名字也是不同的使用的是jenkins 哈希編碼。 哈希命名保證了目錄名總是有效的，就操作系統的規則而言不包括'/'。從總體上說region文件是這樣的：/<hbase-root-dir>/<tablename>/<encoded-regionname>/<column-family>/<filename>. 在每個列族的目錄里，可以看到真實的數據的文件HFile。它們的名字是隨意的數據，是有java 隨機數進行創建的。代碼會檢查保證名字不發生沖突，如果新的名字已經存在了則循環直到找到一個沒用過的名字，用這個來代替。 region的目錄也有一個.regioninfo文件，包含了這個region的HRegionInfo的序列化信息。 在split WAL 和region之間有明顯的不同。有時從操作系統文件名的角度很難區分文件和目錄。因為他們都和split相關。所以操作一定要注意避免誤操作。 一旦region需要split，因為它超過了配置的region大小的最大值，一個相稱的splits的目錄會被創建，它被用來作為兩個新子regions的舞臺。如果這個進程成功了-通常是幾秒鐘甚至更短的時間，他們被移動到表的目錄里來組成兩個新的region，每個相當于原始那個region的一半。 當你看到一個region目錄里面沒有.tmp目錄的時候，說明還沒有壓縮發生。沒有recovered.edits文件說明還沒有WAL重做發生。 region slipt進程會創建很多中間文件。 Region splits： 當一個store文件隨著一個region的增長超過了配置的hbase.hregion.max.filesize大小或者其他情況在列族等級配置使用HColumnDescriptor時region會被拆分為二。這個起初會完成的非常快，因為系統就是為兩個新的region創建兩個相關文件，每個承擔原始region的一半。 regionserver則通過在父region里創建splits來實現。接著會關閉region使之不提供任何其他的訪問。 regionserver之后會通過在splits目錄里建立必要的文件結構來為兩個新的子regions做準備（使用多線程）。這個包括多個新的region目錄和相關文件。如果這個進程成功完成了，它將會這兩個新的region 目錄移動到table的目錄下。然后.META.這個表會被更新父region拆分了，拆分成了哪兩個子regions。這樣做阻止了它被意外的重新打開。 兩個子regions都準備好就將被同一個server平行的打開。這個包括更新.META.表來列出這兩個region都是可用的region就像其他的一樣。之后regions就可以上線服務了。 打開子region也會為這兩個都安排一次壓縮。在后臺將父region重寫store files到兩個新的一半里面來替代相關的文件。這個在子region的.tmp目錄里面進行。一旦文件已經被搞定，它們將自動替換原來的相關文件。 當父region在沒有任何相關的時候就將它徹底清除，從.META.表中移除，硬盤上所有它的文件都將被刪除。最后master才被通知split，可以為新的region安排移動到其他的regionserver上以保證負載均衡。 所有的這些步驟包括split都被跟蹤記錄在zookeeper上。這樣做的原因是一旦某個regionserver掛掉了允許其他進程知道region的狀態。 Compactions： store 文件被后臺進程管理以保證他們在控制下。flush memstores 慢慢的建立了逐漸增長的硬盤文件數目。當文件數目足夠多的時候，compaction 進程就會將他們合并到少但是更大點的文件。這樣一直進行知道這些文件的最大值已經超過了配置的streo files大小的最大值，觸發region的split。 cmpactions有兩種：輕量級的，重量級的。輕量級的compactions 負責重寫最近的小文件到一個更大的文件里。文件的數量室友hbase.hstore.compaction.min參數進行設置（之前叫hbase.hstore.compactionThreshold）。默認是被設為3，知道要被設成2或者更多。如果這個數被設置的太大的話compactions將會延遲，但這樣也將會需要更多的資源，一旦開始compacions時間也更長。 在輕量級的合并中文件最大數目被設為10默認（hbase.hstore.comaction.max中可以設置） 列表也會被hbase.hstore.compaction.min.size（用來配置region的memstore flush 大小）和hbase.hstore.compaction.max.size(默認Long.MAX_VALUE)參數進一步縮小。任何比最大的合并大小大的文件總是不存在的。合并的最小值工作有輕微的不同：它是一個閥值而不是每個文件的大小限制。它包括在這個值下面的到每個壓縮允許的總文件數的所有文件。下圖：所有符合在最小值合并閥值下面的文件都包含在合并進程中。 算法使用hbase.hstore.compaction.ratio(默認是1.2或120%)來保證在選中的進程中包括足夠多的文件。這個比率也將選擇比所有新文件中的store files的總數合并大小大的文件。選舉總是先從老的檢查到新的，這樣可以保證老的文件總是先被壓縮。這些合并內容允許你調整有多少文件被包括在輕度合并中。 與輕量級合并相比，重量級的合并所有的文件到一個文件中。這種類型的壓縮當壓縮檢查被執行時是自動運行的。當一個memstore被flush到硬盤，當compact或major_compact的shell命令被執行或者api中進行調用，或者是后臺進程要求，壓縮的檢查都會被觸發。這個后臺進程被叫做CompactionChecker并且每個regionserver運行一個單獨的實例。它是按規則的原則進行檢查，有參數hbase.server.thread.wakefrequency（多線程是hbase.server.thread.wakefrequency.multiplier 設成1000會比其他基本線程任務運行的頻率更低）參數進行控制。 如果調用majar_compact命令或者majorCompact() API 會強制major compaction 運行。否則，服務會從首次運行先根據hbase.hregion.majorcompacion（默認24小時）參數檢查major compaction 是否合理。hbase.hregion.majorcompaction.jitter參數（默認0.2）將會導致這個stores的時間被展開。如果沒有他所有stores將會在同一時間沒24小時運行一次major compaction。 如果檢查發現沒有合理的major compaction則將啟用輕量級的合并。根據前面提及的配置參數，服務決定對于輕量級的合并是否有足夠的文件。當前這包括所有store文件并且比每個合并配置的最大文件數少的時候，輕量級的合并會被提升到重量級的合并。 真正的存儲文件是由HFile類實現的。是以hadoop TFile類為基礎的。這個文件里面包含可變數目的塊，只有file info和trailer是固定的塊。trailer有指向其他塊的指針。當數據被持久化到文件后trailer會被寫完成當前數據永恒不變的存儲。索引數據塊記錄data和meta數據塊的遷移。data和meta的數據塊都是隨意存儲的。但是鑒于hbase是怎么使用數據文件的，你講幾乎總是可以至少在store文件中找到數據塊。數據塊的大小可以由參數HColumnDescriptor參數配置，在表被用戶創建的時候被指定或默認合理的規格值。Minimum block size：一般用法期待大小是8KB--1MB。如果是連續訪問，大的數據塊大小是被允許的，然而這也將導致隨機訪問的低效率，因為有更多的數據需要解壓。更小的數據塊對隨機訪問好，但是需要更多的內存來保存數據塊的索引，而且創建也會變慢（因為必須我們必須在每個數據塊的總結部分flush壓縮流，這將導致fs的io的flush）。根據壓縮袋的內部的caching，可能的最小數據塊大小可以在20KB-30KB左右。 每個數據塊包含一個magic頭部，和一些序列化了的keyvalue實例。如果不使用壓縮算法，每個數據塊就和配置的block size一樣大。這不是確認無誤的科學，作者不得不迎合你要的任何東西，如果你存儲的一個keyvalue對比block size大，作者也是不得不接受的。但是就算是小一些的數值，對于block size 的檢查是在最后一個值被寫完之后檢查。所以在實踐中，大多數的數據塊會稍微大一點。當使用壓縮算法的時候會沒有多少在block size上的控制。如果可以決定多少數據可以足夠獲得有效的壓縮率那么壓縮的編碼可以工作的最好。例如，將數據塊設為256KB，使用LZO壓縮以保證數據塊總會被寫入少于或等于256KB的數據來配合LZO的內部buffer 大小。 有一件事情需要注意Hdfs文件默認的數據塊大小是6MB，是HFile默認數據塊大小的1024倍。 有時可以直接訪問一個HFile是必要的，通過HBase，例如檢查健康，或者dump它的信息。：./bin/hbase org.apache.hadoop.hbase.io.hfile.HFile keyValue 格式： 在HFiel中的每個KeyValue是一個低位的字節數組，允許零拷貝的訪問數據。 這個結構以兩個固定長度的用來表示大小的數和key的值開頭。有了這些信息，可以以偏移訪問數組，例如直接訪問數據而忽略key。否則，得的從key中獲得需要的信息。一旦數據在keyValue對java實例中解析，就可以使用獲得的信息訪問詳細信息。在先前的例子中，key的平均值比value還大是因為它不得不存儲組成key部分的keyValue。key保存rowkey。列族名，列的名，一些信息等等。對于下的負荷，這個就會引起重頭。如果你處理的數據很小，也試著使用小的key。選短的row和列key（列族和列都小）以保證檢測率。 另一方面，compression也會幫助減輕無法抵抗的key大小問題，這樣看起來數據有窮的，并且所有重復數據會被壓縮。在store file中，所有keyValue的排序幫助保持簡單的key緊密的保存在一起。

總結

以上是生活随笔為你收集整理的Hbase 权威指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。