HBase的列式存储在查询时如何读取

hbase的region是按行划分，而非按列，如果你读取指定一行的所有列数据，regionServer虽然无法保证你的所有数据都在一个HFile中，但是至少是在一个Region中。但是具体的HFile所在的hdfs的节点那就不是HBase关心的事了，因为HBase的存储是依赖与hdfs，所以底层存储读取的事会由NameNode *** 心，NameNode会考虑就近原则，而提供最高效的数据读取策略。

你的数据传输是必然，但是HBase不会计算，计算是发生在你将想要的数据获取到之后再自行进行计算的。你读取大量数据必然会有大量数据传输，HBase只是将提供了一种高效的数据读取策略，尽量减小数据传输量

转 >

首先访问Zookeeper，获取-ROOT表的位置信息，然后访问-ROOT表，获得MATA表的信息，接着访问MATA表，找到所需的Region具体位于哪个服务器，最后才找到该Region服务器读取数据。

hbase snapshot数据迁移问题

不需要提前建表，分区也会自动同步

HBase自身也提供了ExportSnapshot的方法可以从HDFS文件层基于某个快照快速的导出HBase的数据，并不会对RegionServer造成影响，但该源生的方法不支持增量

1、在源集群执行

snapshot 'src_table', 'snapshot_src_table'

snapshot的流程主要有三个步骤

加锁: 加锁对象是regionserver的memstore，目的是禁止在创建snapshot过程中对数据进行insert,update,delete *** 作

刷盘：刷盘是针对当前还在memstore中的数据刷到HDFS上，保证快照数据相对完整，此步也不是强制的，如果不刷会，快照中数据有不一致风险

创建指针: snapshot过程不拷贝数据，但会创建对HDFS文件的指针，snapshot中存储的就是这些指针元数据

2、在源集群执行，属于推送方式，在目标集群执行数据拉取方式

hbase orgapachehadoophbasesnapshotExportSnapshot -snapshot test_snap -copy-from hdfs://HDFS80386/hbase -copy-to hdfs://shyt-hadoop-4031xxcomcn:8020/apps/hbase/data -mappers 20 -bandwidth 5

3、在目标集群执行使用hbase用户

disable 'dalishen:bbs_member'

restore_snapshot 'bbs_member_snap'

使用restore命令在目标集群自动新建表，以及与archive里的HFile建立link

执行该步骤的时候，可能会遇到权限问题，需要赋权限

Caused by: orgapachehadoopipcRemoteException(orgapachehadoopsecurityAccessControlException): Permission denied: user=hbase, access=WRITE, inode="/apps/hbase/data/archive/data/dalishen/bbs_member/f9406f2ff1fe4d542a5cc36b850c2689/f/links-91a554a73b1e41a7a0b33208331d62df":hadoop:hdfs:drwxr-xr-x

源集群

groups hadoop hdfs 可以发现导入的是源集群的权限

所以需要赋权限

hdfs dfs -chmod -R 777 /apps/hbase/data/archive/data/dalishen/bbs_member/

enable 'dalishen:bbs_member'

不需要提前建表，分区也会自动同步，支持增量备份，需要指定要备份的时间范围

copyTable也是属于HBase数据迁移的工具之一，以表级别进行数据迁移。copyTable的本质也是利用MapReduce进行同步的，与DistCp不同的时，它是利用MR去scan 原表的数据，然后把scan出来的数据写入到目标集群的表。这种方式也有很多局限，如一个表数据量达到T级，同时又在读写的情况下，全量scan表无疑会对集群性能造成影响。

13->11 高到低版本 不需要提前建表，分区也会自动同步

检查是否开启同步

echo "list_replicated_tables" | hbase shell -n |grep dalishen:app_deviceid

没有的话执行

enable_table_replication 'tname'

1源集群hadoop查询数据量，如太大先别迁移超过5000w

hbase orgapachehadoophbasemapreduceRowCounter 'dalishen:app_deviceid'

2源集群上执行 替换表名

hbase orgapachehadoophbasemapreduceCopyTable -Dhbaseclientscannercaching=1000 -Dmapredmaptasksspeculativeexecution=false -D mapreducetasktimeout=6000000 --families=f:f --peeradr=10522442:2181:/hbase-unsecure --newname=dalishen:app_deviceid dalishen:app_deviceid

3目标集群上执行数据量对比下

hbase orgapachehadoophbasemapreduceRowCounter 'dalishen:app_deviceid'

4指定时间戳进行增量同步

hbase orgapachehadoophbasemapreduceCopyTable -Dhbaseclientscannercaching=1000 -Dmapredmaptasksspeculativeexecution=false -D mapreducetasktimeout=6000000 --starttime=1600792683760 --endtime=1600792684760 --families=f:f --peeradr=17218127:2181:/hbase --newname=testwang testwang

在源集群进入hbase shell

1、 add_peer '1', 'shyt-hadoop-4032xxxcomcn,shyt-hadoop-4031xxxcomcn,shyt-hadoop-4030xxxcomcn:2181:/hbase-unsecure'

2、修改REPLICATION_SCOPE属性=1，全局模式，此数据会被复制给所有peer

alter 'testwang',{NAME => 'f' ,REPLICATION_SCOPE => '1'}

3、hbase(main):006:0> enable_table_replication 'testwang'

0 row(s) in 00860 seconds

The replication swith of table 'testwang' successfully enabled

验证在源集群 put 'testwang','1005','f:name','1005'

在目标集群 get 'testwang','1005'

校验数据量：通count

hbase orgapachehadoophbasemapreduceRowCounter 'testwang'

查看同步状态： status 'replication'

建议大表先进行snapshot方式同步，然后再利用copy进行增量数据同步，小表直接copy table数据迁移，最后配置hbase replication peer实时同步

1、用户画像

比如大型的视频网站，电商平台产生的用户点击行为、浏览行为等等存储在HBase中为后续的智能推荐做数据支撑。

2、消息/订单存储

这个场景主要应用在电商平台，因为HBase提供了一个低延时、高并发的访问能力

3、对象存储

这里的对象存储实际是中等对象存储，是对HDFS存储文件的一个缓冲过度，因为如果我们大量的1M或2M这种小文件直接存储在HDFS上，会对NAMENODE造成元数据维护的压力，所以在HBase中可以很好的做过度合并后在持久化到HDFS上。HBase提供了中等对现象的存储能力，中等对象的大小范围在100k至10M之间。

4、时序数据

这里的时序数据是指随着时间而变化的数据，比如速度的展示，天气、温度、风速、车流量等等

5、Cube分析（KyLin）

通过KyLin将Hive或kafka中的数据，来构建Cube，这些Cube会存储在HBase中，以供其他的应用或其他的系统做实时查询或实时展示。

6、Feeds流

这个场景主要是应用在抖音、或其他小视频系统中，可以把Feeds流理解为一种内容聚合器，它可以帮助用户实时的获取最新的订阅源内容。

最近进行 HBase 表跨集群迁移，使用组内同事给的方案 : bulkload，但是 bulkload 完之后出现了一系列预料之外的问题，记录如下：

bulkload 结束后，这张 700 亿行的大表，只有一个 region，花了近一周的时间 minor compaction，region split 好；

原先以为，拷贝的数据里面除了列族数据，还包含 region 信息（/region_id/regioninfo），本来以为 bulkload 会自动处理 region，通过了解了一番源码发现，事情并非如此。

1 初始化一个线程池 ，线程池 corePoolSize 来源于参数配置 hbaseloadincrementalthreadsmax，如果未配置，默认取 jvm 可以用到的处理器的个数（RuntimegetRuntime()availableProcessors()）。

2 遍历搜索过滤出 HFile 文件 ：遍历目录，搜索 hfile。途中经过一系列校验，判断是否有 families，family name 是否合法性，跳过非 hfile 文件，例如 _ 开头的文件，引用，HFileLink，最后判断 HFile 格式的有效性。

扫描过程中会检查 HFile 文件的大小是否超出 region 大小的阈值（hbasehregionmaxfilesize，未配置的话默认是 10G），如果超出阈值，会打印提示这可能会导致出现 oversplitting 的问题。

将遍历后的 hfile 以对象 LoadQueueItem(byte[] family, Path hfilePath) 的方式放入队列 ：Deque。

这一步就把 regioninfo 就排除掉了，所以这个拷贝过来的 region 信息对于 bulkload 是无用了。

famliy 存在性校验 ：再经过一次筛选，判断是否有获取到的 family 是否是即将导入 HBase 表中的 family。

3 groupOrSplitPhase 阶段

这个阶段判断 hfile 判断应该写到表的哪个 region，如果跨 region 了，需要进行 split。

获取当前表所有 region 的 startkeys endkeys

拿到即将导入的 hfile 的 startkey，通过二分查找算法在 startkey 列表里面搜索，如果搜到匹配的 startkey 直接返回数组索引值，没搜到，返回插入点，插入点是第一个大于值的索引位置。

通过这个索引值，判断是否有跨 region 的 hfile，有的话需要 split。怎么判断是否不需要 split，也就是有合适的 region，满足其中两个条件之一即可：

拆分是把当前 HFile 拆分成两半，top 和 bottom 两部分，保留元数据，重建 bloom 过滤等，生成新的 HFile ，拆分策略是：根据匹配 region 的 endkey 的位置拆分成两个。

bulkLoadPhase ：bulkload 阶段

计算出 region 信息之后，就是正式的 load 阶段，最终定位到 HStore 里面的 bulkLoadFile 方法

通过 StoreFile reader 读取 StoreFile ，获取写锁，往 storefile 中新增数据。

对于待迁移的 HBase 大表， bulkload 前尽可能在建表时做好预分区

hbase每次处理数据不需要实时的调用数据。根据查询相关公开信息显示，在HBase中，客户端在访问数据时不需要每次实时调用数据，HBase使用一个称为RegionServer的组件来缓存和管理数据，客户端可以通过与RegionServer进行交互来获取数据，当客户端首次请求数据时，RegionServer会将数据加载到内存中，并在内存中保持一段时间以提高下一次访问的性能。

以上就是关于HBase的列式存储在查询时如何读取全部的内容，包括:HBase的列式存储在查询时如何读取、HBase条件查询（多条件查询）、在hbase三层结构下客户端怎么样访问到数据的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！