26Hbase大合集

最新推荐文章于 2024-08-31 08:49:17 发布

Sigmund_Y

最新推荐文章于 2024-08-31 08:49:17 发布

阅读量2k

点赞数

分类专栏： hbase 文章标签： hbase

本文链接：https://blog.csdn.net/yangbllove/article/details/105848888

版权

本文深入剖析了HBase的架构，包括Zookeeper、HDFS和RegionServer的角色。详细阐述了HBase的读写流程，强调了其读写分离的特性，以及StoreFile的合并方式。探讨了HBase的优化策略，如Zookeeper的session.timeout调整、Memstore和BlockCache管理。此外，文章还讨论了HBase在时间序列、推荐画像等场景的应用，并给出了具体的优化建议和场景案例。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、hbase架构简介

在这里插入图片描述

Zookeeper：作为分布式的协调。RegionServer也会把自己的信息写到ZooKeeper中。
HDFS是Hbase运行的底层文件系统。
RegionServer，理解为数据节点，存储数据的。
Master ：RegionServer要实时的向Master报告信息。Master知道全局的RegionServer运行情况，可以控制RegionServer的故障转移和Region的切分。

架构的细分

在这里插入图片描述

HMaster是Master Server的实现，负责监控集群中的RegionServer实例，同时是所有metadata改变的接口，在集群中，通常运行在NameNode上面。
- HMasterInterface暴露的接口：Table(createTable, modifyTable, removeTable, enable, disable),ColumnFamily (addColumn, modifyColumn, removeColumn),Region (move, assign, unassign)
- Master运行的后台线程：LoadBalancer线程，控制region来平衡集群的负载。CatalogJanitor线程，周期性的检查hbase:meta表。
HRegionServer是RegionServer的实现，服务和管理Regions，集群中RegionServer运行在DataNode。
- HRegionRegionInterface暴露接口：Data (get, put, delete, next, etc.)，Region (splitRegion, compactRegion, etc.)
- RegionServer后台线程：CompactSplitThread，MajorCompactionChecker，MemStoreFlusher，LogRoller。
Regions，代表table，Region有多个Store(列簇)，Store有一个Memstore和多个StoreFiles(HFiles)，StoreFiles的底层是Block。

HLog，预写日志文件，也叫做WAL(write-ahead log)。

通常情况，每个RegionServer只有一个WAL实例。
MultiWAL: 如果每个RegionServer只有一个WAL，由于HDFS必须是连续的，导致必须写WAL连续的，然后出现性能问题。MultiWAL可以让RegionServer同时写多个WAL并行的，通过HDFS底层的多管道，最终提升总的吞吐量，但是不会提升单个Region的吞吐量。
WAL的配置：

// 启用multiwal
<property>
  <name>hbase.wal.provider</name>
  <value>multiwal</value>
</property>

HFile 真实的数据存储文件。HFile的生成方式：

起初，HFile中并没有任何Block，数据还存在于MemStore中。
Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。
而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：
注：如果配置了Data Block Encoding，则会在Append KeyValue的时候进行同步编码，编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。

二、Hbase的读写数据流程

HBase用-ROOT-表记录.META.表的位置信息(即元数据信息)，而.META.表记录了用户表Region的位置信息。

要搞清楚hbase的读写流程，首先来看hbase的几张系统表：
hbase:namespace 存储了hbase中的所有namespace的信息
在这里插入图片描述
hbase:meta 存储了hbase中所有的region的信息，包括rowkey范围，region所在的regionserver的地址。

hbase:meta 在zookeeper中，进入zookeeper中查看

hbase的读流程：

1、Client 先访问 zookeeper，找到 Meta 表，并获取 Meta 表元数据。。
2、找到meta表所在的regionserver的地址。
3、访问对应的regionserver，读meta表的信息。
4、通过命令找到rowkey对应的region，得到region的名称。
5、访问region所在的regionserver。
6、Client到HRegion的中去查找数据，首先到MemStore中查找，查到直接返回；查不到就去BlockCache中查找，查到直接返回；再查不到就去StoreFile中读数据，把读到的数据存入BlockCache中再返回Client。

一个 RegionServer 上有一个 BlockCache 和N个 Memstore，它们的大小之和不能大于等于 heapsize * 0.8，否则 hbase 不能启动。默认 BlockCache 为 0.2，而 Memstore 为 0.4。对于注重读响应时间的系统，应该将 BlockCache 设大些，比如设置BlockCache =0.4，Memstore=0.39。这会加大缓存命中率。
在这里插入图片描述

hbase的写流程：

1、Client通过Zookeeper调度获取表的元数据信息。
2、Cilent通过rpc协议与RegionServer交互，通过-ROOT-表与.META.表找到对应的对应的Region。
3、将数据写入HLog日志中，如出现意外可以通过HLog恢复信息。
4、将数据写入Region的MemStore中，当MemStore达到阈值开始溢写，将其中的数据Flush成一个StoreFile。
5、MemStore不断生成新的StoreFile，当StoreFile的数量到达阈值后会出发Compact合并操作，将多个StoreFile合并成一个StoreFile。
6、StoreFile文件会不断增大，当达到阈值后会出发Split操作，把当前的Region且分为两个新的Region。**父Region会下线，**两个子Region会被HMaster分配到相应的RegionServer。

数据写到store以后是先缓存在memstore中，同一个region中存在多个列族则存在多个store，每个store都一个memstore，当其实memstore进行flush时，属于同一个region
的store中的memstore都会进行flush。

HBase的流程高性能：

1、由读写数据的流程可以发现，Region中的内存分为两块：MemStore(负责写数据)、BlockCache(负责读数据)，这是HBase的一大特点——读写分离，这也是HBase读写速度极快的原因之一。
2、在HBase中，可以看出只有增添操作，所有的更新和删除都是在后续的Compact合并过程中进行的，这使得用户的写操作只有进入内存就可以立刻返回，实现了I/O的高性能。

Hbase的storeFile合并的两种方式minor 和 major

hbase中有两种类型的合并

minor compaction 小合并
major compaction 大合并

minor compaction 小合并

多个StoreFile合并成一个更大的StoreFile
这个过程是将多个小的、相近的StoreFile合并成一个更大的StoreFile，对于超过TTL(Time To Live)的数据、更新的数据和删除的数据仅仅做个了标记（即新增了一个带有标记的版本号），并没有进行物理删除，一次minor compaction的结果会得到更少、更大的StoreFile。这种合并的触发频率很高
minor compaction触发的条件：
- 表示一次minor compaction中最多选取10个store file
- 文件大小小于该值的store file （128MB）一定会加入到minor compaction的store file中
- 默认值为LONG.MAX_VALUE，表示文件大小大于该值的store file 会被minor compaction排除

<!--表示至少需要三个满足条件的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，表示文件大小大