region

Region是HBase資料管理的基本單位,region有一點像關系型資料的磁區，
Region中存盤這用戶的真實資料，而為了管理這些資料，HBase使用了RegionSever來管理region，

region的分配

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

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

regionServer其實是hbase的服務，部署在一臺物理服務器上，region有一點像關系型資料的磁區，資料存放在region中，當然region下面還有很多結構，確切來說資料存放在memstore和hfile中，我們訪問hbase的時候，先去hbase 系統表查找定位這條記錄屬于哪個region，然后定位到這個region屬于哪個服務器，然后就到哪個服務器里面查找對應region中的資料

region結構

資料的寫入

Memstore Flush流程

flus流程分為三個階段：

prepare階段：遍歷當前 Region中所有的 MemStore ，將 MemStore 中當前資料集 CellSkpiListSet 做一個快照 snapshot；然后再新建一個 CellSkipListSet，后期寫入的資料都會寫入新的 CellSkipListSet 中，prepare 階段需要加一把 updataLock 對寫請求阻塞，結束之后會釋放該鎖，因為此階段沒有任何費時操作，因此鎖持有時間很短
flush階段：遍歷所有 MemStore，將 prepare 階段生成的snapshot 持久化為臨時檔案，臨時檔案會統一放到目錄.tmp下，這個程序因為涉及到磁盤 IO 操作，因此相對耗時
commit階段：遍歷所有 MemStore，將flush階段生成的臨時檔案移動到指定的 ColumnFamily 目錄下，針對 HFile生成對應的 StoreFile 和 Reader，把 StoreFile 添加到 HStore 的 storefiles 串列中，最后再清空 prepare 階段生成的 snapshot快照

Compact 合并機制

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

自動合并：

minor compaction 小合并
major compacton 大合并

minor compaction（小合并）
將 Store 中多個 HFile 合并為一個相對較大的 HFile 程序中會選取一些小的、相鄰的 StoreFile 將他們合并成一個更大的 StoreFile，對于超過 TTL 的資料、更新的資料、洗掉的資料僅僅只是做了標記，并沒有進行物理洗掉，一次 minor compaction 過后，storeFile會變得更少并且更大，這種合并的觸發頻率很高

小合并的觸發方式：
memstore flush會產生HFile檔案，檔案越來越多就需要compact.每次執行完Flush操作之后，都會對當前Store中的檔案數進行判斷，一旦檔案數大于配置3，就會觸發compaction，compaction都是以Store為單位進行的，而在Flush觸發條件下，整個Region的所有Store都會執行compact

后臺執行緒周期性檢查
檢查周期可配置：
hbase.server.thread.wakefrequency 默認10000毫秒)
hbase.server.compactchecker.interval.multiplier 默認1000
CompactionChecker大概是2hrs 46mins 40sec 執行一次

<!--表示至少需要三個滿足條件的store file時，minor compaction才會啟動-->
<property>
        <name>hbase.hstore.compactionThreshold</name>
        <value>3</value>
</property>

<!--表示一次minor compaction中最多選取10個store file-->
<property>
        <name>hbase.hstore.compaction.max</name>
        <value>10</value>
</property>

<!--默認值為128m,
表示檔案大小小于該值的store file 一定會加入到minor compaction的store file中
-->
<property>
        <name>hbase.hstore.compaction.min.size</name>
        <value>134217728</value>
</property>

<!--默認值為LONG.MAX_VALUE，表示檔案大小大于該值的store file 一定會被minor compaction排除-->
<property>
        <name>hbase.hstore.compaction.max.size</name>
        <value>9223372036854775807</value>
</property>

major compaction（大合并）

合并 Store 中所有的 HFile 為一個 HFile，將所有的 StoreFile 合并成為一個 StoreFile，這個程序中還會清理三類無意義資料：被洗掉的資料、TTL過期資料、版本號超過設定版本號的資料，合并頻率比較低，默認7天執行一次，并且性能消耗非常大，建議生產關閉（設定為0），在應用空間時間手動觸發，一般是可以手動控制進行合并，防止出現在業務高峰期，

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

<!--默認值為7天進行一次大合并，-->
<property>
        <name>hbase.hregion.majorcompaction</name>
        <value>604800000</value>
</property>

手動合并

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

# 造資料
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一下都會在底層生成一個小檔案

##使用major_compact命令
major_compact tableName

major_compact 'doit:test'

region的拆分

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

region的拆分策略

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

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

但是在生產線上這種切分策略卻有相當大的弊端（切分策略對于大表和小表沒有明顯的區分）：
1.閾值(hbase.hregion.max.filesize)設定較大對大表比較友好，但是小表就有可能不會觸發分裂，極端情況下可能就1個，形成熱點，這對業務來說并不是什么好事，
2.如果設定較小則對小表友好，但一個大表就會在整個集群產生大量的region，這對于集群的管理、資源使用、failover來說都不是一件好事，

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

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

region split閾值的計算公式是：
1.設regioncount：是region所屬表在當前regionserver上的region的個數
2.閾值 = 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，可以自適應大表、小表；
? 在集群規模比較大的情況下，對大表的表現比較優秀
? 對小表不友好，小表可能產生大量的小region，分散在各regionserver上
? 小表達不到多次切分條件，導致每個split都很小，所以分散在各個regionServer上

SteppingSplitPolicy：2.0版本默認切分策略

相比 IncreasingToUpperBoundRegionSplitPolicy 簡單了一些 region切分的閾值依然和待分裂region所屬表在當前regionserver上的region個數有關系
? 如果region個數等于1，切分閾值為flush size 128M * 2
? 否則為MaxRegionFileSize，

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

KeyPrefixRegionSplitPolicy

根據rowKey的前綴對資料進行磁區，這里是指定rowKey的前多少位作為前綴，比如rowKey都是16位的，指定前5位是前綴，那么前5位相同的rowKey在相同的region中

DelimitedKeyPrefixRegionSplitPolicy

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

BusyRegionSplitPolicy

按照一定的策略判斷Region是不是Busy狀態，如果是即進行切分
如果你的系統常常會出現熱點Region，而你對性能有很高的追求，那么這種策略可能會比較適合你，它會通過拆分熱點Region來緩解熱點Region的壓力，但是根據熱點來拆分Region也會帶來很多不確定性因素，因為你也不知道下一個被拆分的Region是哪個

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

手動合并拆分region

手動合并

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

手動拆分

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

bulkLoad實作批量匯入

bulkloader ：一個用于批量快速匯入資料到hbase的工具/方法

用于已經存在一批巨量靜態資料的情況！如果不用bulkloader工具，則只能用rpc請求，一條一條地通過rpc提交給regionserver去插入，效率極其低下

原理

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

importTsv工具

原理：
Importtsv是hbase自帶的一個 csv檔案--》HFile檔案的工具，它能將csv檔案轉成HFile檔案，并發送給regionserver，它的本質，是內置的一個將csv檔案轉成hfile檔案的mr程式！

# CSV轉HFILE的命令示例如下：
# 001,北戴河,河北省,河北省北戴河昌平區沙河鎮賦騰國際創客中心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命令的引數說明如下：
-Dimporttsv.skip.bad.lines=false - 若遇到無效行則失敗
-Dimporttsv.separator=, - 使用特定分隔符,默認是tab也就是\t
-Dimporttsv.timestamp=currentTimeAsLong - 使用匯入時的時間戳
-Dimporttsv.mapper.class=my.Mapper - 使用用戶自定義Mapper類替換TsvImporterMapper
-Dmapreduce.job.name=jobName - 對匯入使用特定mapreduce作業名
-Dcreate.table=no - 避免創建表，注：如設為為no，目標表必須存在于HBase中
-Dno.strict=true - 忽略HBase表列族檢查，默認為false
-Dimporttsv.bulk.output=/user/yarn/output 作業的輸出目錄

hfile

邏輯資料組織格式

Scanned block section：表示順序掃描HFile時（rile時（包含所有需要被讀取的資料）所有的資料塊將會被讀取，包括Leaf Index Block和Bloom Block；
Non-scanned block section：HFile順序掃描的時候該部分資料不會被讀取，主要包括Meta Block和Intermediate Level Data Index Blocks兩部分；
Load-on-open-section：這部分資料在HBase的region server啟動時，需要加載到記憶體中，包括FileInfo、Bloom filter block、data block index和meta block index等各種索引的元資料資訊；
Trailer：這部分主要記錄了HFile的基本資訊、各個部分的偏移值和尋址資訊，
Data Block：主要存盤用戶的key，value資訊
Meta Block：記錄布隆過濾器的資訊
Root Data Index：DataBlock的根索引以及MetaBlock和Bloom Filter的索引
Intermediate Level Index:DataBlock的第二層索引
Leaf Level Index：DataBlock的第三層索引，即索引數的葉子節點
Fileds for midKey:這部分資料是Optional的，保存了一些midKey資訊，可以快速地定位到midKey,常常在HFileSplit的時候非常有用
MetaIndex:即meta的索引資料，和data index類似，但是meta存放的是BloomFilter的資訊
FileInfo:保存了一些檔案的資訊，如lastKey,avgKeylen,avgValueLen等等
Bloom filter metadata:是布隆過濾器的索引

物理資料結構圖

資料的讀取

Client訪問zookeeper，獲取hbase:meta所在RegionServer的節點資訊
Client訪問hbase:meta所在的RegionServer，獲取hbase:meta記錄的元資料后先加載到記憶體中，然后再從記憶體中根據需要查詢的RowKey查詢出RowKey所在的Region的相關資訊（Region所在RegionServer）
Client訪問RowKey所在Region對應的RegionServer，發起資料讀取請求
讀取memstore中的資料，看是否有key對應的value的值
不管memstore中有沒有值，都需要去讀取Hfile中的資料(再讀取Hfile中首先通過索引定位到data block)
判斷cache block中中是否已經加載過需要從檔案中讀取的bloom block和data block，如果加載過了，就直接讀取cache block中的資料，如果沒有，就讀取檔案中的block資料
將memstore和Hfile中讀取的資料匯總取正確的資料回傳給客戶端

rowkey的設計

設計的三大原則

Rowkey長度原則

Rowkey是一個二進制碼流，Rowkey的長度被很多開發者建議設計在10-100個位元組，不過建議是越短越好，不要超過16個位元組

原因如下：

資料的持久化檔案HFile中是按照KeyValue存盤的，如果Rowkey過長比如100個位元組，1000萬列資料光Rowkey就要占用100*1000萬=10億個位元組，將近1G資料，這會極大影響Hfile的存盤效率；
MemStore將快取部分資料到記憶體，如果Rowkey欄位過長記憶體的有效利用率降低，系統將無法快取更多的資料，這會降低檢索效率，因此Rowkey的位元組長度越短越好，
目前作業系統一般都是64位系統，記憶體8位元組對齊，空值在16個位元組，8位元組的整數倍利用作業系統的最佳特性，

Rowkey散列原則

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

Rowkey唯一原則

必須在設計Rowkey上保證其唯一性，否則前面插入的資料將會被覆寫，

常見的避免熱點的方法以及它們的優缺點

加鹽

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

哈希

哈希會使同一行永遠用一個前綴加鹽，哈希也可以使負載分散到整個集群，但是讀卻是可以預測的，使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行資料

反轉

第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey，這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面，這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性，
比如手機號的反轉，時間戳的反轉，當一個連續遞增的數字型別想要作為rowkey時，可以用一個很大的數去減這個rowkey，反轉后再當成rowkey

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/555133.html

標籤：大數據

上一篇：如何成功實施一個資料治理專案？實施步驟有哪些？

下一篇：返回列表

Hbase中的region和rowkey