hbase 的基本結構

HBASE 基本結構
一。overview
1. hbase <=> NOSQL
   不錯，hbase 就是某種型別的nosql 資料庫，唯一的區別就是他支援海量的資料。
   hbase的基本功能：
   1）強一致性的讀寫，而非“最終一致性”（eventually consistent）的資料倉儲。基於此，hbase非常適合高速的統計計數工作。

    2）自動sharding ，hbase 是分散式的資料庫，支援資料的自動切分。

    3） regionServer 的自動failover

    4）整合hadoop/hdfs ，habase 是構建在hadoop/hdfs 檔案系統上的。

    5）支援mapreduce

    6） java client api

    7） Thift/Rest api ：支援非java 語言的訪問。

    8）資料塊級cache 及布隆過濾（bloom filter）

    9）整合操作管理系統，提供基於web 及command-line的工具。

2.適用場景：

    1） hbase 並非適合所有的場景，首先，你要有足夠的資料，如果只有幾百萬筆記錄，一般的RDBMS 就可以管理了。 hbase 設計是支援數十億記錄級別的資料倉儲

    2） hbase 不支援RDBMS的功能，比如表連線，索引，排序等。

    3）確信，你有足夠的硬體系統來支援。hbase 不保證能夠在5個節點一下的叢集中，正確的執行。

3.hbase 與hadoop/hdfs 的區別：

    1） hdfs 是一個分散式的檔案系統，他非常適合於儲存大檔案，他僅完成了一般檔案系統的功能，他不支援檔案內部記錄級別的搜尋功能。

    2） hbase 是構建在hdfs之上的，並且提供了記錄級別的快速查詢功能。hbase 將資料放在索引過的storefile 中。

二。字典表

    hbase 的資料字典: -ROOT- .META 這倆表被hbase shell 的list 命令過濾掉，不顯示，但是他們跟普通的hbase TABLE 是一樣的。

1.ROOT
    1) root表記錄了.META. 表的位置他的結構：

    A) Key:
        .META. region key(.META.,,1)

    B) Values:
        info:regioninfo (serialized HRegionInfo instance of .META.)
        info:server    (server:port of the RegionServer holding .META.)
        info:serverstartcode (start-time of RegionServer process holding .META.)

2.META.
    1) META. 表儲存了系統中所有的regions 的資訊，結構：

    A) Key:
        Region key of the format ([table],[region start key],[region id])

    B) Values:
        info:regioninfo (serialized HRegionInfo instance for this region)
        info:server (server:port of the RegionSever containing this region)
        info:serverstartcode (start-time of the RegionSever process containing this region)

    2) 當一個region 正在執行split 的時候，會出現另外兩個列 info:splitA 與 info:splitB 這倆列的值也是HRegionInfo 的例項，當split 完畢後，這兩列會被刪除掉。

    3）注意: HRegionInfo: 如果key 為空，指示表的開始與表的結尾，
        如果一個region 有空的start key 則這個region 是表的第一個region。如果region 同事有空的start key 與空的end key ，那麼這個表只有當前一個region。

3.啟動序列：

    META. 的位置寫入ROOT META. 跟新server 與startcode 的值。

三。 CLIENT

    Hbase 的client HTable 負責查詢resionserver 用來提供基本的操作，通過查詢.META. 以及-ROOT- 字典表來查詢regionsever 。
    一旦找到對應的region ，客戶端會直接連去region 對應的resionserver ，同事也會cache 這個結果，之後就不再通過meta. 來讀寫資料，除非這個regionserver死掉，才會從新從meta. 查詢新的regionserver 。

1.連線：

    HTable 不是執行緒安全的，不適合多執行緒呼叫。一般建議使用HBaseConfiguration 例項來連線資料庫。

    1) 連線池，目前沒有最終的解決方案，有個HTablePool ，但是難於管理。

        一般提前建立一個陣列來儲存已經建立的連線：
        HConnectionManager.createConnection(Configuration)

    2) WriterBuffer 與批量(batch) 方法
        如果客戶端的 AutoFlush 被設為off 那麼資料的寫入，會先寫滿writebuffer 然後再重新整理的resionserver。 writebuffer 預設是2MB .
    注意： htable.delete(Delete) 方法，不會進入writebuffer 。
    關於控制writebuffer 的細粒度的參考 HTable的batch 方法。

    3）對非java 客戶端的支援。

    4）行級鎖，目前的client 還有行級鎖，以後的版本會去除這塊。

四. 客戶端請求過濾(Client Request Filter)

    Get 與Scan 例項，可以配置filter 來過濾，但是Filter 可能會被拒絕因為型別太多了，需要先理解他們的功能。

    這一部分，需要對系統程式碼有一定的瞭解，需要比較好的java 知識，先掠過去。
    考一段例項程式碼：
FilterList list = new FilterList(FilterList.Operator.MUST_PASS_ONE);
SingleColumnValueFilter filter1 = new SingleColumnValueFilter(
    cf,
    column,
    CompareOp.EQUAL,
    Bytes.toBytes("my value")
    );
list.add(filter1);
SingleColumnValueFilter filter2 = new SingleColumnValueFilter(
    cf,
    column,
    CompareOp.EQUAL,
    Bytes.toBytes("my other value")
    );
list.add(filter2);
scan.setFilter(list);

2.列值的filter

    SingleColumnValueFilter 用來過濾列值（column value）操作CompareOp.EQuAL 相等 CompareOp.NOT_EQUAL 不相等，CompareOpGREATER 範圍

    一段示例程式碼：
SingleColumnValueFilter filter = new SingleColumnValueFilter(
    cf,
    column,
    CompareOp.EQUAL,
    Bytes.toBytes("my value")
    );
scan.setFilter(filter);

3.正規表示式支援：

SubstringComparator comp = new SubstringComparator("y val");   // looking for 'my value'
SingleColumnValueFilter filter = new SingleColumnValueFilter(
    cf,
    column,
    CompareOp.EQUAL,
    comp
    );
scan.setFilter(filter);

關於filter 這部分，參考https://hbase.apache.org/book.html#architecture 9.4. 節內容。

五. Master

    HMaster 是一臺管理伺服器，負責監控所有的regionserver 例項，以及提供修改.META.的介面，在生產環境中，hmaster 一般部署在namenode 上。

1.啟動時行為：

    如果執行在多主的環境中，如果主要的master 故障，或則無法與ZOOKEEPer 的聯絡，備機會接替。

2.執行時故障：
    如果在叢集執行期間，hmaster下線，因為client 都直接與regionserver 聯絡，所以叢集可以繼續執行一小段時間，但是因為hmaster 控制了核心功能，所以如果master 下線，應儘快重啟master 。

3.介面（Interface）
    HMasterInterface 提供基於metadata的介面

    Table （createTable modifyTable removeTable enable。。。。）
    ColumnFamily （addColumn modifyColumn removeClolumn）
    Region （move assign unassign）

4.程式：
    hmaster 執行著幾個後臺程式。
    1) LoadBalance 程式負載負載均衡。

    2） CatalogJanitor 檢查並清理.META. 表。

六. RegionServer
    regionserver 為region 提供管理服務在生產部署上，regionserver 執行在datanode 上。

1.介面   提供資料的訪問，以及region 的管理
    Data （get put delete next 。。。）

    Region （splitRegion compactRegion。。。）

2.程式 regionserver 執行幾個後臺程式。

    1） CompactSplitThread
        提供split 以及小型壓縮/整理工作

    2） MajorCompactionChecker
        提供大型壓縮/整理工作
    3）MemStoreFlusher
        週期性的重新整理記憶體的資料導磁碟
    4） LogRoller
        週期性檢查regionserver 的HLOG

3.Coprocessors
    因為java 不能多繼承，所以很多複雜性的工作，導致java程式碼的編寫變的很複雜，而hbase 的不同的功能點，都在不同的模組裡，這就導致，一個程式碼同事完成幾個功能時，使編碼工作很複雜，於是參照goole 論文裡的技術，開發了Coprocessors 模組。詳細資訊參照： https://blogs.apache.org/hbase/entry/coprocessor_introduction

4.Block Cache
    1）設計： block cache 是lru CACHE 有3個級別的cache 策略
        a）單次訪問策略：一個資料塊第一次從hdfs載入cache
        b）多次訪問側路：一個資料塊在a)策略基礎上，被多次訪問。
        c） In-memory策略：
    關於cache 策略： https://hbase.apache.org/xref/org/apache/hadoop/hbase/io/hfile/LruBlockCache.html

    2） USAGE
        Block cache 預設對所有的使用者表起作用，也就是所有的資料讀取操作，都會經過block cache 的快取。適合於大多數情況，為了特定的效能提升關閉cache 也是可以的。cache 的設定取決於工作集（WSS working_set_size) 大小。
block cache 的大小的估算公式：
    number of region servers * heap size * hfile.block.cache.size * 0.85
    預設的block cache的尺寸是heapsize 的25% 幾個例項：
    一個region server 預設的heapsize 1g 那麼block cache 大約為217Mb
    20個 region serer 預設的heapsize 8g 那麼blocK CACHE 大約為34Gb
    100個region server 預設的heapsize 24g block cache 大約1TB

    .META. -ROOT- 字典表預設為In-memory 策略。
    HFILE 的索引 keys， Bloom filter 也會用到block cache 。

     使用原則：應該瞭解一下自己要訪問的資料集的大小，
    對於隨機訪問的，不建議使用block cache ，因為大資料量的隨機訪問，會導致block cache 別佔滿，而後，因為lru策略會導致jvm 更多的垃圾回收，帶來效能損失。
    對於MAPPING TABLE ： A在mapreduce任務中，因為每個記錄僅被讀取一次，所以沒有必要使用block cache 。

5.WAL （hbase 日誌）

    1）    每個regionserver 會把對資料的修改寫進wal 日誌，然後寫memstore 然後才寫到store 物理檔案中。HLOG 是wallog的實現，每個regionserver 一個例項。

    2） wal flush 目前沒有文件記載。
    3） wal splitting
        沒有詳細文件記載

七.Regions

    regions 是高可用，與可分散式表的基本元素，每個列族（column family）一個store （對應我們理解上的一個資料檔案）
       (HBase table)
    Region       (Regions for the table)
         Store          (Store per ColumnFamily for each Region for the table)
              MemStore           (MemStore for each Store for each Region for the table)
              StoreFile          (StoreFiles for each Store for each Region for the table)
                    Block             (Blocks within a StoreFile within a Store for each Region for the table)

    hbase 在HDFS 上的儲存結構：
/hbase
     /             (Tables in the cluster)
          /           (Regions for the table)
               /      (ColumnFamilies for the Region for the table)
                    /        (StoreFiles for the ColumnFamily for the Regions for the table)


    WAL 日誌在hdfs 裡儲存結構：
/hbase
     /.logs
          /    (RegionServers)
               /           (WAL HLog files for the RegionServer)


1.Region Size
    確定一個合適的region size 是個比較難的事情需要考慮幾個情況：

    1） hbase 通過region 在伺服器間實現可擴充套件性，但是如果你有2個16gb的region 在一個20個節點的叢集了，大約只會用到幾臺伺服器，大部分伺服器都是閒置的，浪費了資源。
    2）另一方面，更過的region 數量，會讓整個工作變慢，對於同樣大小的資料，700個region 的效能要好於3000個region 的情況，
    3） regionsever 在記憶體封裝上，1個region 跟多個region 是沒有區別的。

2.Region-RegionServer-Assignment（region 在regionserver 的分配）

    1）啟動過程
        a） master 呼叫AssignmentMenager
        b） AssignmentManager 檢視.META. 裡已存在的region 的分配情況
        c）如果region 的assignment 還有效，就繼續保持
        d）如果這assignment 失效，LoadbalanceFactory 被呼叫重新分配這個region ，預設是在所有的regionserver間隨機的分派的。
        e） META. 資訊隨這個region 的重新指派而更新。

    2） failover
        當一個regionserver失敗時：
        a) region 馬上變得不可用
        b）hmaster 檢測到regionserver失敗
        c）region assignment 被認為失效，將啟動重新分派的工作。

    3） loadbalance
        region 可以週期性通過LoadBalance 在regionserver建移動。

3.region regionserver 本地化
    經過一段時間後，會達到region 本地化
    因為hdfs的複製是
    a）第一份寫本地節點
    b）第二份複製寫同一個機櫃的另一臺機器
    3）第三份複製寫另一個機櫃
    這樣通過一段時間，hbase 就達到本地化了，在regionserver failover 時候，資料會從新分配，region 可能會被指派到不同的節點上，但是經過一段時間，通過上面的過程，還是會實現本地化。

4.Region splits
    應該禁止讓hbase 自己執行region split ，控制引數為hbase.hregion.max.filesize 禁止自動split 時，可以設定這個值為100gb 左右，一旦忘記執行手工split 100gb的資料檔案通過compation 的時間在大約1小時左右。

    0.94版面以後，可以用手工的split 策略覆蓋全域性的策略
    region 的split 策略，可以全域性設定，也可以單個表設定。

5線上Region merge

master 跟regionserver 都可以執行merge 操作，
示例操作：
    $ hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME'
          hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME', true


6.store
    一個store 包括一個memstore 和0個或多個store file （HFILE) 每個store 對應於一個column family

    1） memstore 儲存了記憶體裡的修改影像，資料的修改在memstore裡完成然後請求flush 將資料寫入store file 。
    2） store file 就是我們常規意義上儲存在hbase裡的資料檔案了。
        a） HFILE 的格式：
            參考資訊：https://hbase.apache.org/book.html#hfilev2

        b) hfile 工具：
            $ ${HBASE_HOME}/bin/hbase org.apache.hadoop.hbase.io.hfile.HFile -v -f hdfs://10.81.47.41:8020/hbase/TEST/1418428042/DSMP/4759508618286845475 檢視文集內容

        c）storefile in hdfs 參考前面的hbase 在hdfs上儲存格式。

    3）資料塊（BLOCK)
        storefile 由block 組成，block的大小可以在columfamily 裡設定
        資料壓縮（compact）就是在資料塊級別上進行。

    4） keyvalue 對
        keyvalue 的儲存格式：
            a）keylength
            b) valuelength
            c) key
            d) value
        key 的結構：

            a） rowlength
            b) row (i.e. the rowkey)
            c) columnfamilylenth
            d)columnfamily
            e)columnqualifier
            f)timestamp
            g)keytype (i.e. Put Delete DeleteColumn DeleteFamily)
        一個示例資料：
        Put #1: rowkey=row1, cf:attr1=value1
        Put #2: rowkey=row1, cf:attr2=value2

        我們想hbase 寫了兩行資料，結構分拆

        for PUT 1:
        rowlength ------------&gt 4
        row -----------------&gt row1
        columnfamilylength ---&gt 2
        columnfamily --------&gt cf
        columnqualifier ------&gt attr1
        timestamp -----------&gt server time of Put
        keytype -------------&gt Put

for PUT 2:

        rowlength ------------&gt 4
        row -----------------&gt row1
        columnfamilylength ---&gt 2
        columnfamily --------&gt cf
        columnqualifier ------&gt attr2
        timestamp -----------&gt server time of Put
        keytype -------------&gt Put




    5）關於Compaction
        這部分不太好說，參考文件：
        https://hbase.apache.org/book.html#architecture 9.7.6.5 小節。

八. 批量匯入(BULK LOAD)
    這個屬於工具性，一個主要的過程，先根據hbase 的檔案格式，
    把要匯入hbase 的資料寫成hbase 的檔案格式，然後在通過工具把這些檔案註冊到.META.中。

    這個部分沒有實際操作過，參考下文件吧：https://hbase.apache.org/book.html#architecture 9.8 小節。

           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            好了，到這裡就結束了

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/133735/viewspace-763450/，如需轉載，請註明出處，否則將追究法律責任。