国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

Hbase-- 03

2年前作者：All996分類：Toy博客閱讀(19)違法舉報

這篇具有很好參考價值的文章主要介紹了Hbase-- 03。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

4.原理加強

4.1數(shù)據(jù)存儲

4.1.1行式存儲

傳統(tǒng)的行式數(shù)據(jù)庫將一個個完整的數(shù)據(jù)行存儲在數(shù)據(jù)頁中

4.1.2列式存儲

列式數(shù)據(jù)庫是將同一個數(shù)據(jù)列的各個值存放在一起

Hbase-- 03

傳統(tǒng)行式數(shù)據(jù)庫的特性如下：
?①數(shù)據(jù)是按行存儲的。
?②沒有索引的查詢使用大量I/O。比如一般的數(shù)據(jù)庫表都會建立索引，通過索引加快查詢效率。
?③建立索引和物化視圖需要花費大量的時間和資源。
?④面對查詢需求，數(shù)據(jù)庫必須被大量膨脹才能滿足需求。

列式數(shù)據(jù)庫的特性如下：
?①數(shù)據(jù)按列存儲，即每一列單獨存放。
?②數(shù)據(jù)即索引。
?③只訪問查詢涉及的列，可以大量降低系統(tǒng)I/O。
?④每一列由一個線程來處理，即查詢的并發(fā)處理性能高。
?⑤數(shù)據(jù)類型一致，數(shù)據(jù)特征相似，可以高效壓縮。比如有增量壓縮、前綴壓縮算法都是基于列存儲的類型定制的，所以可以大幅度提高壓縮比，有利于存儲和網(wǎng)絡輸出數(shù)據(jù)帶寬的消耗。

4.1.3列族式存儲

列族式存儲是一種非關系型數(shù)據(jù)庫存儲方式，按列而非行組織數(shù)據(jù)。它的數(shù)據(jù)模型是面向列的，即把數(shù)據(jù)按照列族的方式組織，將屬于同一列族的數(shù)據(jù)存儲在一起。每個列族都有一個唯一的標識符，一般通過列族名稱來表示。它具有高效的寫入和查詢性能，能夠支持極大規(guī)模的數(shù)據(jù)

如果一個表有多個列族, 每個列族下只有一列, 那么就等同于列式存儲。

如果一個表只有一個列族, 該列族下有多個列, 那么就等同于行式存儲.

Hbase-- 03

4.1.4hbase的存儲路徑：

在conf目錄下的hbase-site.xml文件中配置了數(shù)據(jù)存儲的路徑在hdfs上

XML
<property>
<name>hbase.rootdir</name>
<value>hdfs://linux01:8020/hbase</value>
</property>

hdfs上的存儲路徑：

Hbase-- 03

Hbase-- 03

4.2region

Region是HBase數(shù)據(jù)管理的基本單位,region有一點像關系型數(shù)據(jù)的分區(qū)。
Region中存儲這用戶的真實數(shù)據(jù)，而為了管理這些數(shù)據(jù)，HBase使用了RegionSever來管理region。

4.2.1region的分配

一個表中可以包含一個或多個Region。

每個Region只能被一個RS（RegionServer）提供服務，RS可以同時服務多個Region，來自不同RS上的Region組合成表格的整體邏輯視圖。

regionServer其實是hbase的服務，部署在一臺物理服務器上，region有一點像關系型數(shù)據(jù)的分區(qū)，數(shù)據(jù)存放在region中，當然region下面還有很多結(jié)構(gòu)，確切來說數(shù)據(jù)存放在memstore和hfile中。我們訪問hbase的時候，先去hbase 系統(tǒng)表查找定位這條記錄屬于哪個region，然后定位到這個region屬于哪個服務器，然后就到哪個服務器里面查找對應region中的數(shù)據(jù)

4.2.2region結(jié)構(gòu)

Hbase-- 03

4.2.3數(shù)據(jù)的寫入

Hbase-- 03

4.2.4Memstore Flush流程

flus流程分為三個階段：

prepare階段：遍歷當前 Region中所有的 MemStore ，將 MemStore 中當前數(shù)據(jù)集 CellSkpiListSet 做一個快照 snapshot；然后再新建一個 CellSkipListSet。后期寫入的數(shù)據(jù)都會寫入新的 CellSkipListSet 中。prepare 階段需要加一把 updataLock 對寫請求阻塞，結(jié)束之后會釋放該鎖。因為此階段沒有任何費時操作，因此鎖持有時間很短

flush階段：遍歷所有 MemStore，將 prepare 階段生成的snapshot 持久化為臨時文件，臨時文件會統(tǒng)一放到目錄.tmp下。這個過程因為涉及到磁盤 IO 操作，因此相對耗時

commit階段：遍歷所有 MemStore，將flush階段生成的臨時文件移動到指定的 ColumnFamily 目錄下，針對 HFile生成對應的 StoreFile 和 Reader，把 StoreFile 添加到 HStore 的 storefiles 列表中，最后再清空 prepare 階段生成的 snapshot快照

4.2.5Compact 合并機制

hbase中的合并機制分為自動合并和手動合并

4.2.5.1自動合并：

minor compaction 小合并

major compacton 大合并

minor compaction（小合并）

將 Store 中多個 HFile 合并為一個相對較大的 HFile 過程中會選取一些小的、相鄰的 StoreFile 將他們合并成一個更大的 StoreFile，對于超過 TTL 的數(shù)據(jù)、更新的數(shù)據(jù)、刪除的數(shù)據(jù)僅僅只是做了標記，并沒有進行物理刪除。一次 minor compaction 過后，storeFile會變得更少并且更大，這種合并的觸發(fā)頻率很高

4.2.5.1.1小合并的觸發(fā)方式：

memstore flush會產(chǎn)生HFile文件，文件越來越多就需要compact.每次執(zhí)行完Flush操作之后，都會對當前Store中的文件數(shù)進行判斷，一旦文件數(shù)大于配置3，就會觸發(fā)compaction。compaction都是以Store為單位進行的，而在Flush觸發(fā)條件下，整個Region的所有Store都會執(zhí)行compact

后臺線程周期性檢查

檢查周期可配置：

hbase.server.thread.wakefrequency/默認10000毫秒)*hbase.server.compactchecker.interval.multiplier/默認1000

CompactionChecker大概是2hrs 46mins 40sec 執(zhí)行一次

XML

<property>
??????? <name>hbase.hstore.compactionThreshold</name>
??????? <value>3</value>
</property>


<property>
??????? <name>hbase.hstore.compaction.max</name>
??????? <value>10</value>
</property>


<property>
??????? <name>hbase.hstore.compaction.min.size</name>
??????? <value>134217728</value>
</property>


<property>
?????? ?<name>hbase.hstore.compaction.max.size</name>
??????? <value>9223372036854775807</value>
</property>

4.2.5.1.2major compaction（大合并）

合并 Store 中所有的 HFile 為一個 HFile，將所有的 StoreFile 合并成為一個 StoreFile，這個過程中還會清理三類無意義數(shù)據(jù)：被刪除的數(shù)據(jù)、TTL過期數(shù)據(jù)、版本號超過設定版本號的數(shù)據(jù)。合并頻率比較低，默認7天執(zhí)行一次，并且性能消耗非常大，建議生產(chǎn)關閉（設置為0），在應用空間時間手動觸發(fā)。一般是可以手動控制進行合并，防止出現(xiàn)在業(yè)務高峰期。

XML
線程先檢查小文件數(shù)是否大于配置3，一旦大于就會觸發(fā)compaction。
大文件周期性合并成Major Compaction
如果不滿足，它會接著檢查是否滿足major compaction條件
如果當前store中hfile的最早更新時間早于某個值mcTime就會觸發(fā)major compaction
(默認7天觸發(fā)一次，可配置手動觸發(fā))


<property>
??????? <name>hbase.hregion.majorcompaction</name>
??????? <value>604800000</value>
</property>

4.2.5.2手動合并

一般來講，手動觸發(fā)compaction通常是為了執(zhí)行major compaction，一般有這些情況需要手動觸發(fā)合并是因為很多業(yè)務擔心自動maior compaction影響讀寫性能，因此會選擇低峰期手動觸發(fā)也有可能是用戶在執(zhí)行完alter操作之后希望立刻生效，執(zhí)行手動觸發(fā)maiorcompaction:

造數(shù)據(jù)

Shell
truncate 'doit:test'????????????????????????????????
put 'doit:test','001','f1:name','zss'
put 'doit:test','002','f1:name','zss'
put 'doit:test','003','f1:name','zss'
put 'doit:test','004','f1:name','zss'
flush 'doit:test'???????????????????
put 'doit:test','005','f1:name','zss'
put 'doit:test','006','f1:name','zss'
put 'doit:test','007','f1:name','zss'
put 'doit:test','008','f1:name','zss'
flush 'doit:test'???????????????????
put 'doit:test','009','f1:name','zss'
put 'doit:test','010','f1:name','zss'
put 'doit:test','011','f1:name','zss'
put 'doit:test','012','f1:name','zss'
flush 'doit:test'
put 'doit:test','013','f1:name','zss'
put 'doit:test','014','f1:name','zss'
put 'doit:test','015','f1:name','zss'
put 'doit:test','016','f1:name','zss'
flush 'doit:test'
put 'doit:test','017','f1:name','zss'
put 'doit:test','018','f1:name','zss'
put 'doit:test','019','f1:name','zss'
put 'doit:test','020','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','025','f1:name','zss'
put 'doit:test','026','f1:name','zss'
put 'doit:test','027','f1:name','zss'
put 'doit:test','028','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'
put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'

put 'doit:test','021','f1:name','zss'
put 'doit:test','022','f1:name','zss'
put 'doit:test','023','f1:name','zss'
put 'doit:test','024','f1:name','zss'
flush 'doit:test'

每次flush一下都會在底層生成一個小文件

Hbase-- 03

Shell
##使用major_compact命令
major_compact tableName

major_compact 'doit:test'

Hbase-- 03

4.2.6region的拆分

region中存儲的是一張表的數(shù)據(jù)，當region中的數(shù)據(jù)條數(shù)過多的時候，會直接影響查詢效率。當region過大的時候，region會被拆分為兩個region，HMaster會將分裂的region分配到不同的regionserver上，這樣可以讓請求分散到不同的RegionServer上，已達到負載均衡? , 這也是HBase的一個優(yōu)點

4.2.6.1region的拆分策略

1. ConstantSizeRegionSplitPolicy：0.94版本前，HBase region的默認切分策略

當region中最大的store大小超過某個閾值(hbase.hregion.max.filesize=10G)之后就會觸發(fā)切分，一個region等分為2個region。

但是在生產(chǎn)線上這種切分策略卻有相當大的弊端（切分策略對于大表和小表沒有明顯的區(qū)分）：

閾值(hbase.hregion.max.filesize)設置較大對大表比較友好，但是小表就有可能不會觸發(fā)分裂，極端情況下可能就1個，形成熱點，這對業(yè)務來說并不是什么好事。

如果設置較小則對小表友好，但一個大表就會在整個集群產(chǎn)生大量的region，這對于集群的管理、資源使用、failover來說都不是一件好事。

2. IncreasingToUpperBoundRegionSplitPolicy：0.94版本~2.0版本默認切分策略

總體看和ConstantSizeRegionSplitPolicy思路相同，一個region中最大的store大小大于設置閾值就會觸發(fā)切分。但是這個閾值并不像ConstantSizeRegionSplitPolicy是一個固定的值，而是會在一定條件下不斷調(diào)整，調(diào)整規(guī)則和region所屬表在當前regionserver上的region個數(shù)有關系.

region split閾值的計算公式是：

設regioncount：是region所屬表在當前regionserver上的region的個數(shù)

閾值 = regioncount^3 * 128M * 2，當然閾值并不會無限增長，最大不超過MaxRegionFileSize（10G),當region中最大的store的大小達到該閾值的時候進行region split

例如：

第一次split閾值 = 1^3 * 256 = 256MB

第二次split閾值 = 2^3 * 256 = 2048MB

第三次split閾值 = 3^3 * 256 = 6912MB

第四次split閾值 = 4^3 * 256 = 16384MB > 10GB，因此取較小的值10GB

后面每次split的size都是10GB了

特點

相比ConstantSizeRegionSplitPolicy，可以自適應大表、小表；

在集群規(guī)模比較大的情況下，對大表的表現(xiàn)比較優(yōu)秀

對小表不友好，小表可能產(chǎn)生大量的小region，分散在各regionserver上

小表達不到多次切分條件，導致每個split都很小，所以分散在各個regionServer上

3. SteppingSplitPolicy：2.0版本默認切分策略

相比 IncreasingToUpperBoundRegionSplitPolicy 簡單了一些? region切分的閾值依然和待分裂region所屬表在當前regionserver上的region個數(shù)有關系

如果region個數(shù)等于1，切分閾值為flush size 128M * 2

否則為MaxRegionFileSize。

這種切分策略對于大集群中的大表、小表會比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不會再產(chǎn)生大量的小region，而是適可而止。

4. KeyPrefixRegionSplitPolicy

根據(jù)rowKey的前綴對數(shù)據(jù)進行分區(qū)，這里是指定rowKey的前多少位作為前綴，比如rowKey都是16位的，指定前5位是前綴，那么前5位相同的rowKey在相同的region中

5. DelimitedKeyPrefixRegionSplitPolicy

保證相同前綴的數(shù)據(jù)在同一個region中，例如rowKey的格式為：userid_eventtype_eventid，指定的delimiter為 _ ，則split的的時候會確保userid相同的數(shù)據(jù)在同一個region中。按照分隔符進行切分，而KeyPrefixRegionSplitPolicy是按照指定位數(shù)切分

6. BusyRegionSplitPolicy

按照一定的策略判斷Region是不是Busy狀態(tài)，如果是即進行切分

如果你的系統(tǒng)常常會出現(xiàn)熱點Region，而你對性能有很高的追求，那么這種策略可能會比較適合你。它會通過拆分熱點Region來緩解熱點Region的壓力，但是根據(jù)熱點來拆分Region也會帶來很多不確定性因素，因為你也不知道下一個被拆分的Region是哪個

7. DisabledRegionSplitPolicy：不啟用自動拆分, 需要指定手動拆分

4.2.6.2手動合并拆分region

手動合并

Shell
hbase(main):025:0> list_regions 'doit:test'
???? ????????????SERVER_NAME |????????????????????????????????????????????????????????? REGION_NAME |? START_KEY |??? END_KEY |? SIZE |?? REQ |?? LOCALITY |
?--------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
?linux03,16020,1684200651855 |?????????? doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5. |??????????? | rowkey_010 |???? 0 |???? 0 |??????? 0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0. | rowkey_010 | rowkey_015 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |???? 0 |???? 0 |? ??????0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |???? 0 |???? 0 |??????? 0.0 |
?linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |???? 0 |???? 0 |??????? 0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |??????????? |???? 0 |???? 0 |??????? 0.0 |
?6 rows
Took 0.0299 seconds? ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
hbase(main):026:0> merge_region 'doit:test,,1684205468848.920ae3e043ad95890c4f5693cb663bc5.','doit:test,rowkey_010,1684207066858.5e04eb75e5510ad65a0f3001de3c7aa0.'
Took 1.2638 seconds???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
hbase(main):027:0> list_regions 'doit:test'
???????????????? SERVER_NAME |????????????????????????????????????????????????????????? REGION_NAME |? START_KEY |??? END_KEY |? SIZE |?? REQ |?? LOCALITY |
?--------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
?linux03,16020,1684200651855 |?????????? doit:test,,1684207066859.cdc1226d634c0cf16f58832637f485b6. |??????????? | rowkey_015 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_015,1684207066858.ed1b328ca4c485d4fa429922f6c18f0b. | rowkey_015 | rowkey_020 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_020,1684205468848.25d62e8cc2fdaecec87234b8d28f0827. | rowkey_020 | rowkey_030 |? ???0 |???? 0 |??????? 0.0 |
?linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |???? 0 |???? 0 |??????? 0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |??????????? |???? 0 |???? 0 |??????? 0.0 |
?5 rows
Took 0.0271 seconds

手動拆分

Shell
hbase(main):029:0> list_regions 'doit:test'
???????????????? SERVER_NAME |????????????????????????????????????????????????????????? REGION_NAME |? START_KEY |??? END_KEY |? SIZE |?? REQ |?? LOCALITY |
?--------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
?linux03,16020,1684200651855 |?????????? doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235. |??????????? | rowkey_030 |???? 0 |???? 0 |??????? 0.0 |
?linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |???? 0 |???? 0 |??????? 0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |??????????? |???? 0 |???? 0 |??????? 0.0 |
?3 rows
Took 0.0329 seconds???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
hbase(main):030:0> split 'doit:test,,1684207066860.8ebf4555c58bd0e5fedae5d4efbe4235.','rowkey_025'
Took 0.1179 seconds???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
hbase(main):031:0> list_regions 'doit:test'
??????? ?????????SERVER_NAME |????????????????????????????????????????????????????????? REGION_NAME |? START_KEY |??? END_KEY |? SIZE |?? REQ |?? LOCALITY |
?--------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
?linux02,16020,1684200651886 |?????????? doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d. |??????????? | rowkey_025 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |???? 0 |???? 0 |??????? 0.0 |
?linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |???? 0 |???? 0 |???? ???0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |??????????? |???? 0 |???? 0 |??????? 0.0 |
?4 rows
Took 0.0179 seconds?????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????????????
hbase(main):032:0> split 'doit:test,,1684207502853.af0819bd7f6daa9db2a8f994fb41682d.','rowkey_015'
Took 0.1262 seconds??????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????
hbase(main):033:0> list_regions 'doit:test'
???????????????? SERVER_NAME |????????????????????????????????????????????????????????? REGION_NAME |? START_KEY | ???END_KEY |? SIZE |?? REQ |?? LOCALITY |
?--------------------------- | -------------------------------------------------------------------- | ---------- | ---------- | ----- | ----- | ---------- |
?linux02,16020,1684200651886 |?????????? doit:test,,1684207546572.0f550ec8fa1af0ab9e73032d224d9f00. |??????????? | rowkey_015 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_015,1684207546572.09a2022c54dfef68866ac73e3f78bc70. | rowkey_015 | rowkey_025 |???? 0 |???? 0 |??????? 0.0 |
?linux02,16020,1684200651886 | doit:test,rowkey_025,1684207502853.80d7feace447978ffe4a54418a20afd0. | rowkey_025 | rowkey_030 |???? 0 |???? 0 |??????? 0.0 |
?linux03,16020,1684200651855 | doit:test,rowkey_030,1684205468848.2b0468e6643b95159fa6e210fa093e66. | rowkey_030 | rowkey_040 |???? 0 |???? 0 |??????? 0.0 |
?linux01,16020,1684205091382 | doit:test,rowkey_040,1684205468848.fb12c09c7c73cfeff0bf79b5dda076cb. | rowkey_040 |??????????? |???? 0 |???? 0 |??????? 0.0 |
?5 rows
Took 0.0241 seconds?

4.2.7bulkLoad實現(xiàn)批量導入

bulkloader ：一個用于批量快速導入數(shù)據(jù)到hbase的工具/方法

用于已經(jīng)存在一批巨量靜態(tài)數(shù)據(jù)的情況！如果不用bulkloader工具，則只能用rpc請求，一條一條地通過rpc提交給regionserver去插入，效率極其低下

4.2.7.1原理

Hbase-- 03

相比較于直接寫HBase，BulkLoad主要是繞過了寫WAL日志這一步，還有寫Memstore和Flush到磁盤，從理論上來分析性能會比Put快！

4.2.7.2BulkLoad實戰(zhàn)示例1：importTsv工具

原理：

Importtsv是hbase自帶的一個 csv文件--》HFile文件的工具，它能將csv文件轉(zhuǎn)成HFile文件，并發(fā)送給regionserver。它的本質(zhì)，是內(nèi)置的一個將csv文件轉(zhuǎn)成hfile文件的mr程序！

案例演示：

Shell
CSV轉(zhuǎn)HFILE的命令示例如下：
// 001,北戴河,河北省,河北省北戴河昌平區(qū)沙河鎮(zhèn)賦騰國際創(chuàng)客中心A座4018室
hbase? org.apache.hadoop.hbase.mapreduce.ImportTsv \
-Dimporttsv.separator=, \
-Dimporttsv.columns='HBASE_ROW_KEY,f:city,f:province,x:address'? \
-Dimporttsv.bulk.output=/tsv/output \
user_info \
/tsv/input

ImportTsv命令的參數(shù)說明如下：

-Dimporttsv.skip.bad.lines=false - 若遇到無效行則失敗

-Dimporttsv.separator=, - 使用特定分隔符,默認是tab也就是\t

-Dimporttsv.timestamp=currentTimeAsLong - 使用導入時的時間戳

-Dimporttsv.mapper.class=my.Mapper - 使用用戶自定義Mapper類替換TsvImporterMapper

-Dmapreduce.job.name=jobName - 對導入使用特定mapreduce作業(yè)名

-Dcreate.table=no - 避免創(chuàng)建表，注：如設為為no，目標表必須存在于HBase中

-Dno.strict=true - 忽略HBase表列族檢查。默認為false

-Dimporttsv.bulk.output=/user/yarn/output 作業(yè)的輸出目錄

示例演示：

Plain Text
創(chuàng)建一張表：
hbase(main):005:0> create 'doit:user_info1','f1','f2'
Created table doit:user_info1
Took 1.4252 seconds???????????????????????????????????????????????????????????????????????????????????????????????
=> Hbase::Table - doit:user_info1
hbase(main):006:0>

準備文件：
rowkey_001,zss,18,male,chengxuyuan,beijing
rowkey_002,lss,28,male,jinrongdalao,shanghai
rowkey_003,liuyan,18,female,yanyuan,beijing
rowkey_004,tanyang,38,female,yanyuan,shanghai

上傳文件至hdfs上
[root@linux01 data]# hdfs dfs -mkdir -p /tsv/input
[root@linux01 data]# hdfs dfs -put hbase.txt /tsv/input/
[root@linux01 data]#

使用importtsv將測試文件轉(zhuǎn)為hfile
hbase org.apache.hadoop.hbase.mapreduce.ImportTsv \
-Dimporttsv.separator=, \
-Dimporttsv.columns='HBASE_ROW_KEY,f1:name,f1:age,f1:gender,f2:job,f2:address' \
-Dimporttsv.bulk.output=/uu/output \
doit:user_info1 \
/tsv/input/hbase.txt

將hfile注入hbase
hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles /uu/output/? doit:user_info1

查看表中的數(shù)據(jù)
hbase(main):067:0> scan 'doit:user_info1'
ROW?????????????????????????? COLUMN+CELL???????????????????????????????????????????????????????????????? ?????????
?rowkey_001?????????????????? column=f1:age, timestamp=1684062601474, value=18????????????????????????????????????
?rowkey_001?????????????????? column=f1:gender, timestamp=1684062601474, value=male???????????????????????????????
?rowkey_001?? ????????????????column=f1:name, timestamp=1684062601474, value=zss??????????????????????????????????
?rowkey_001?????????????????? column=f2:address, timestamp=1684062601474, value=beijing???????????????????????????
?rowkey_001?????????????????? column=f2:job, timestamp=1684062601474, value=chengxuyuan???????????????????????????
?rowkey_002?????????????????? column=f1:age, timestamp=1684062601474, value=28????????????????????????????????????
?rowkey_002?????????????????? column=f1:gender, timestamp=1684062601474, value=male???????????????????????????????
?rowkey_002?????????????????? column=f1:name, timestamp=1684062601474, value=lss??????????????????????????????????
?rowkey_002?????????????????? column=f2:address, timestamp=1684062601474, value=shanghai??????????????????????????
?rowkey_002?????????????????? column=f2:job, timestamp=1684062601474, value=jinrongdalao??????????????????????????
?rowkey_003?????????????????? column=f1:age, timestamp=1684062601474, value=18??????????????????????????????? ?????
?rowkey_003?????????????????? column=f1:gender, timestamp=1684062601474, value=female?????????????????????????????
?rowkey_003?????????????????? column=f1:name, timestamp=1684062601474, value=liuyan???????????????????????????????
?rowkey_003?????? ????????????column=f2:address, timestamp=1684062601474, value=beijing???????????????????????????
?rowkey_003?????????????????? column=f2:job, timestamp=1684062601474, value=yanyuan???????????????????????????????
?rowkey_004?????????????????? column=f1:age, timestamp=1684062601474, value=38????????????????????????????????????
?rowkey_004?????????????????? column=f1:gender, timestamp=1684062601474, value=female?????????????????????????????
?rowkey_004?????????????????? column=f1:name, timestamp=1684062601474, value=tanyang??????????????????????????????
?rowkey_004?????????????????? column=f2:address, timestamp=1684062601474, value=shanghai??????????????????????????
?rowkey_004?????????????????? column=f2:job, timestamp=1684062601474, value=yanyuan?????? ?????????????????????????
4 row(s)
Took 0.0587 seconds?????????

4.3hfile

4.3.1邏輯數(shù)據(jù)組織格式：

Hbase-- 03

Scanned block section：表示順序掃描HFile時（包含所有需要被讀取的數(shù)據(jù)）所有的數(shù)據(jù)塊將會被讀取，包括Leaf Index Block和Bloom Block；

Non-scanned block section：HFile順序掃描的時候該部分數(shù)據(jù)不會被讀取，主要包括Meta Block和Intermediate Level Data Index Blocks兩部分；

Load-on-open-section：這部分數(shù)據(jù)在HBase的region server啟動時，需要加載到內(nèi)存中。包括FileInfo、Bloom filter block、data block index和meta block index等各種索引的元數(shù)據(jù)信息；

Trailer：這部分主要記錄了HFile的基本信息、各個部分的偏移值和尋址信息。

Data Block：主要存儲用戶的key，value信息

Meta Block：記錄布隆過濾器的信息

Root Data Index：DataBlock的根索引以及MetaBlock和Bloom Filter的索引

Intermediate Level Index:DataBlock的第二層索引

Leaf Level Index：DataBlock的第三層索引，即索引數(shù)的葉子節(jié)點

Fileds for midKey:這部分數(shù)據(jù)是Optional的，保存了一些midKey信息，可以快速地定位到midKey,常常在HFileSplit的時候非常有用

MetaIndex:即meta的索引數(shù)據(jù)，和data index類似，但是meta存放的是BloomFilter的信息

FileInfo:保存了一些文件的信息，如lastKey,avgKeylen,avgValueLen等等

Bloom filter metadata:是布隆過濾器的索引

4.3.2物理數(shù)據(jù)結(jié)構(gòu)圖：

Hbase-- 03

4.3.3數(shù)據(jù)的讀取

Hbase-- 03

Client訪問zookeeper，獲取hbase:meta所在RegionServer的節(jié)點信息

Client訪問hbase:meta所在的RegionServer，獲取hbase:meta記錄的元數(shù)據(jù)后先加載到內(nèi)存中，然后再從內(nèi)存中根據(jù)需要查詢的RowKey查詢出RowKey所在的Region的相關信息（Region所在RegionServer）

Client訪問RowKey所在Region對應的RegionServer，發(fā)起數(shù)據(jù)讀取請求

讀取memstore中的數(shù)據(jù)，看是否有key對應的value的值

不管memstore中有沒有值，都需要去讀取Hfile中的數(shù)據(jù)(再讀取Hfile中首先通過索引定位到data block)

判斷cache block中中是否已經(jīng)加載過需要從文件中讀取的bloom block和data block，如果加載過了，就直接讀取cache block中的數(shù)據(jù)，如果沒有，就讀取文件中的block數(shù)據(jù)

將memstore和Hfile中讀取的數(shù)據(jù)匯總?cè)≌_的數(shù)據(jù)返回給客戶端

4.4rowkey的設計

4.4.1設計的三大原則

Rowkey長度原則

Rowkey是一個二進制碼流，Rowkey的長度被很多開發(fā)者建議設計在10-100個字節(jié)，不過建議是越短越好，不要超過16個字節(jié)

原因如下：

數(shù)據(jù)的持久化文件HFile中是按照KeyValue存儲的，如果Rowkey過長比如100個字節(jié)，1000萬列數(shù)據(jù)光Rowkey就要占用100*1000萬=10億個字節(jié)，將近1G數(shù)據(jù)，這會極大影響Hfile的存儲效率；

MemStore將緩存部分數(shù)據(jù)到內(nèi)存，如果Rowkey字段過長內(nèi)存的有效利用率降低，系統(tǒng)將無法緩存更多的數(shù)據(jù)，這會降低檢索效率，因此Rowkey的字節(jié)長度越短越好。

目前操作系統(tǒng)一般都是64位系統(tǒng)，內(nèi)存8字節(jié)對齊，空值在16個字節(jié)，8字節(jié)的整數(shù)倍利用操作系統(tǒng)的最佳特性。

Rowkey散列原則

如果Rowkey是按時間戳的方式遞增，因為rowkey是按照字典順序排序的，這樣會出現(xiàn)大量的數(shù)據(jù)插入到一個reion中，而其他的region相對比較空閑從而造成熱點問題，所以盡量不要將開頭相同的內(nèi)容作為rowkey造成熱點問題，可以將時間戳反轉(zhuǎn)后在作為rowkey。

Rowkey唯一原則

必須在設計Rowkey上保證其唯一性。否則前面插入的數(shù)據(jù)將會被覆蓋。

4.4.2常見的避免熱點的方法以及它們的優(yōu)缺點

加鹽

這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數(shù)，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同。分配的前綴種類數(shù)量應該和你想使用數(shù)據(jù)分散到不同的region的數(shù)量一致。加鹽之后的rowkey就會根據(jù)隨機生成的前綴分散到各個region上，以避免熱點。

哈希

哈希會使同一行永遠用一個前綴加鹽。哈希也可以使負載分散到整個集群，但是讀卻是可以預測的。使用確定的哈?？梢宰尶蛻舳酥貥?gòu)完整的rowkey，可以使用get操作準確獲取某一個行數(shù)據(jù)

反轉(zhuǎn)

第三種防止熱點的方法時反轉(zhuǎn)固定長度或者數(shù)字格式的rowkey。這樣可以使得rowkey中經(jīng)常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。

比如手機號的反轉(zhuǎn)，時間戳的反轉(zhuǎn)，當一個連續(xù)遞增的數(shù)字類型想要作為rowkey時，可以用一個很大的數(shù)去減這個rowkey，反轉(zhuǎn)后再當成rowkey文章來源地址http://www.zghlxwxcb.cn/news/detail-490491.html

到了這里，關于Hbase-- 03的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！

本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權(quán)，不承擔相關法律責任。如若轉(zhuǎn)載，請注明出處：如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實不符，請點擊違法舉報進行投訴反饋，一經(jīng)查實，立即刪除！

分享到：

領支付寶紅包贊助服務器費用

Hbase的JavaAPI和數(shù)據(jù)存儲
傳統(tǒng)的行式數(shù)據(jù)庫將一個個完整的數(shù)據(jù)行存儲在數(shù)據(jù)頁中列式數(shù)據(jù)庫是將同一個數(shù)據(jù)列的各個值存放在一起傳統(tǒng)行式數(shù)據(jù)庫的特性如下：數(shù)據(jù)是按行存儲的。沒有索引的查詢使用大量I/O。比如一般的數(shù)據(jù)庫表都會建立索引，通過索引加快查詢效率。建立索引和物化視圖需
2024年02月08日
瀏覽(17)
HBase的數(shù)據(jù)壓縮與存儲效率實踐
HBase是一個分布式、可擴展、高性能的列式存儲系統(tǒng)，基于Google的Bigtable設計。它是Hadoop生態(tài)系統(tǒng)的一部分，可以與HDFS、MapReduce、ZooKeeper等組件集成。HBase適用于大規(guī)模數(shù)據(jù)存儲和實時數(shù)據(jù)訪問場景，如日志記錄、實時數(shù)據(jù)分析、實時數(shù)據(jù)挖掘等。數(shù)據(jù)壓縮是提高存儲效率和
2024年02月20日
瀏覽(17)
Spark + HBase 數(shù)據(jù)處理和存儲實驗
了解Spark中的基本概念和主要思想，熟悉Spark與MapReduce的區(qū)別；掌握基本的Spark編程，實現(xiàn)基礎RDD編程；了解HBase的基本特性及其適用場景；熟悉HBase Shell常用命令；學習使用HBase的Java API，編程實現(xiàn)HBase常用功能；實驗平臺：基于實驗一搭建的虛擬機Hadoop大數(shù)據(jù)實驗平臺上的
2024年02月05日
瀏覽(36)
Hive、HBase對比【相同：HDFS作為底層存儲】【區(qū)別：①Hive用于離線數(shù)據(jù)的批處理，Hbase用于實時數(shù)據(jù)的處理；②Hive是純邏輯表，無物理存儲功能，HBase是物理表，放非結(jié)構(gòu)數(shù)據(jù)】
1. Hive是hadoop數(shù)據(jù)倉庫管理工具，嚴格來說，不是數(shù)據(jù)庫，本身是不存儲數(shù)據(jù)和處理數(shù)據(jù)的，其依賴于HDFS存儲數(shù)據(jù)，依賴于MapReducer進行數(shù)據(jù)處理。 2. Hive的優(yōu)點是學習成本低，可以通過類SQL語句（HSQL）快速實現(xiàn)簡單的MR任務，不必開發(fā)專門的MR程序。 3. 由于Hive是依賴于MapRed
2024年04月17日
瀏覽(26)
【大數(shù)據(jù)存儲與處理】實驗一 HBase 的基本操作
一、實驗目的： 1.?掌握?Hbase?創(chuàng)建數(shù)據(jù)庫表及刪除數(shù)據(jù)庫表? 2.?掌握?Hbase?對數(shù)據(jù)庫表數(shù)據(jù)的增、刪、改、查。二、實驗內(nèi)容： 1、題目?0：進入?hbase?shell? 2 、題目 ?1 ：Hbase?創(chuàng)建數(shù)據(jù)庫表?創(chuàng)建數(shù)據(jù)庫表的命令：create?\\\'表名\\\',?\\\'列族名?1\\\',\\\'列族名?2\\\',\\\'列族名?N\\\' 3、題
2024年02月03日
瀏覽(24)
【大數(shù)據(jù)存儲】實驗3 HBase的安裝和基本操作
Ubuntu 22.04.3 Jdk 1.8.0_341 Hadoop 3.2.3 Hbase 2.4.17 HBase偽分布式安裝的配置 1. 配置hbase-env.sh文件 3. 啟動運行HBase 4. 停止運行HBase HBase常用的Shell命令打開hbase 在HBase中創(chuàng)建表 create \\\'template\\\',\\\'f1\\\',\\\'f2\\\',\\\'f3\\\' 添加數(shù)據(jù) put \\\'template\\\',\\\'r1\\\',\\\'f1:c1\\\',\\\'hello\\\' scan \\\'template\\\' 查看數(shù)據(jù) get：通過表名、行、列、時
2024年04月15日
瀏覽(26)
大數(shù)據(jù)處理技術作業(yè)——使用HBase&MongoDB&MapReduce進行數(shù)據(jù)存儲和管理
寫這篇文章的目的，主要是為了記錄一下這次作業(yè)歷程，并且筆者了解到很多同志飽受作業(yè)折磨，遂簡單分享一下個人完成作業(yè)的歷程，以下內(nèi)容僅為本人的一些亂七八糟的想法，僅作參考O(∩_∩)O 1、本作業(yè)的鏈接【完成本次作業(yè)用到的代碼文件，列出網(wǎng)盤鏈接，https://p
2024年02月07日
瀏覽(23)
大數(shù)據(jù) | HBase基本工作原理
前文回顧：MapReduce基本原理目錄 ??HBase基本介紹 ??HBase的設計目標和功能特點 ??HBase在Hadoop中的生態(tài)環(huán)境 ??HBase的數(shù)據(jù)模型 ??邏輯數(shù)據(jù)模型 ??物理存儲格式 ??HBase基本構(gòu)架 ??HBase數(shù)據(jù)存儲管理方法 ??HBase子表數(shù)據(jù)存儲與子表服務器 ??HBase數(shù)據(jù)的訪問 ??HBase數(shù)據(jù)記錄
2024年02月03日
瀏覽(13)
Linux加強篇-存儲結(jié)構(gòu)與管理硬盤（一）
目錄 ??推薦 ?從“/”開始物理設備命名規(guī)則文件系統(tǒng)與數(shù)據(jù)資料前些天發(fā)現(xiàn)了一個巨牛的人工智能學習網(wǎng)站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉(zhuǎn)到網(wǎng)站 Linux系統(tǒng)中一切都是文件，都是從“根”目錄（/）開始的，Linux系統(tǒng)中的文件和目錄名稱是嚴格
2024年04月26日
瀏覽(12)
Linux加強篇-存儲結(jié)構(gòu)與管理硬盤（三）
目錄 ???推薦磁盤容量配額 VDO虛擬數(shù)據(jù)優(yōu)化軟硬方式鏈接前些天發(fā)現(xiàn)了一個巨牛的人工智能學習網(wǎng)站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉(zhuǎn)到網(wǎng)站使用磁盤容量配額服務來限制某位用戶或某個用戶組針對特定文件夾可以使用的最大硬盤空間或最大文
2024年04月28日
瀏覽(9)