上辽宁建设工程信息网站,网站调用微博,徐州企业免费建站,wordpress固定链自定义结构参考来源: B站尚硅谷HBase2.x 目录 Master 架构RegionServer 架构写流程MemStore Flush读流程HFile 结构读流程合并读取数据优化 StoreFile CompactionRegion Split预分区#xff08;自定义分区#xff09;系统拆分 Master 架构
Master详细架构
1#xff09;Meta 表格介…参考来源: B站尚硅谷HBase2.x 目录 Master 架构RegionServer 架构写流程MemStore Flush读流程HFile 结构读流程合并读取数据优化 StoreFile CompactionRegion Split预分区自定义分区系统拆分 Master 架构
Master详细架构
1Meta 表格介绍警告不要去改这个表 全称 hbasemeta只是在 list 命令中被过滤掉了本质上和 HBase 的其他表格一样。 RowKey ([table],[region start key],[region id]) 即 表名region 起始位置和 regionID。 列 inforegioninfo 为 region 信息存储一个 HRegionInfo 对象。 infoserver 当前 region 所处的 RegionServer 信息包含端口号。 infoserverstartcode 当前 region 被分到 RegionServer 的起始时间。 如果一个表处于切分的过程中即 region 切分还会多出两列 infosplitA 和 infosplitB存储值也是 HRegionInfo 对象拆分结束后删除这两列。 注意在客户端对元数据进行操作的时候才会连接 master如果对数据进行读写直接连接zookeeper 读取目录/hbase/meta-region-server 节点信息会记录 meta 表格的位置。直接读取即可不需要访问 master这样可以减轻 master 的压力相当于 master 专注 meta 表的写操作客户端可直接读取 meta 表。 在 HBase 的 2.3 版本更新了一种新模式Master Registry。客户端可以访问 master 来读取meta 表信息。加大了 master 的压力减轻了 zookeeper 的压力。
RegionServer 架构 1MemStore 写缓存由于 HFile 中的数据要求是有序的所以数据是先存储在 MemStore 中排好序后等到达刷写时机才会刷写到 HFile每次刷写都会形成一个新的 HFile写入到对应的文件夹 store 中。2WAL 由于数据要经 MemStore 排序后才能刷写到 HFile但把数据保存在内存中会有很高的概率导致数据丢失为了解决这个问题数据会先写在一个叫做 Write-Ahead logfile 的文件中然后再写入 MemStore 中。所以在系统出现故障的时候数据可以通过这个日志文件重建。3BlockCache 读缓存每次查询出的数据会缓存在 BlockCache 中方便下次查询。
写流程 写流程 写流程顺序正如 API 编写顺序首先创建 HBase 的重量级连接 1首先访问 zookeeper获取 hbase:meta 表位于哪个 Region Server 2访问对应的 Region Server获取 hbase:meta 表将其缓存到连接中作为连接属性 MetaCache由于 Meta 表格具有一定的数据量导致了创建连接比较慢 之后使用创建的连接获取 Table这是一个轻量级的连接只有在第一次创建的时候会检查表格是否存在访问 RegionServer之后在获取 Table 时不会访问 RegionServer 3调用Table的put方法写入数据此时还需要解析RowKey对照缓存的MetaCache查看具体写入的位置有哪个 RegionServer 4将数据顺序写入追加到 WAL此处写入是直接落盘的并设置专门的线程控制 WAL 预写日志的滚动类似 Flume 5根据写入命令的 RowKey 和 ColumnFamily 查看具体写入到哪个 MemStory并且在 MemStory 中排序 6向客户端发送 ack 7 等达到 MemStore 的刷写时机后将数据刷写到对应的 story 中。
MemStore Flush
MemStore 刷写由多个线程控制条件互相独立 主要的刷写规则是控制刷写文件的大小在每一个刷写线程中都会进行监控 1当某个 memstroe 的大小达到了 hbase.hregion.memstore.flush.size默认值 128M 其所在 region 的所有 memstore 都会刷写。 当 memstore 的大小达到了
hbase.hregion.memstore.flush.size默认值 128M
* hbase.hregion.memstore.block.multiplier默认值 4时会刷写同时阻止继续往该 memstore 写数据由于线程监控是周期性的所以有可能面对数据洪峰尽管可能性比较小 2由 HRegionServer 中的属性 MemStoreFlusher 内部线程 FlushHandler 控制。标准为LOWER_MARK低水位线和 HIGH_MARK高水位线意义在于避免写缓存使用过多的内 存造成 OOM 当 region server 中 memstore 的总大小达到低水位线
java_heapsize
*hbase.regionserver.global.memstore.size默认值 0.4
*hbase.regionserver.global.memstore.size.lower.limit默认值 0.95region 会按照其所有 memstore 的大小顺序由大到小依次进行刷写。直到 region server中所有 memstore 的总大小减小到上述值以下。 当 region server 中 memstore 的总大小达到高水位线
java_heapsize
*hbase.regionserver.global.memstore.size默认值 0.4时会同时阻止继续往所有的 memstore 写数据。 3为了避免数据过长时间处于内存之中到达自动刷写的时间也会触发 memstore flush。由 HRegionServer 的属PeriodicMemStoreFlusher 控制进行由于重要性比较低5min才会执行一次。 自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval默认 1 小时。 4当 WAL 文件的数量超过 hbase.regionserver.max.logsregion 会按照时间顺序依次进行刷写直到 WAL 文件数量减小到hbase.regionserver.max.log 以下该属性名已经废弃现无需手动设置最大值为 32。
读流程
HFile 结构
在了解读流程之前需要先知道读取的数据是什么样子的。 HFile 是存储在 HDFS 上面每一个 store 文件夹下实际存储数据的文件。里面存储多种内容。包括数据本身keyValue 键值对、元数据记录、文件信息、数据索引、元数据索引和一个固定长度的尾部信息记录文件的修改情况。键值对按照块大小默认 64K保存在文件中数据索引按照块创建块越多索引越大。每一个 HFile 还会维护一个布隆过滤器就像是一个很大的地图文件中每有一种 key就在对应的位置标记读取时可以大致判断要 get 的 key 是否存在 HFile 中。 KeyValue 内容如下: rowlength -----------→ key 的长度 row -----------------→ key 的值 columnfamilylength --→ 列族长度 columnfamily --------→ 列族 columnqualifier -----→ 列名 timestamp -----------→ 时间戳默认系统时间 keytype -------------→ Put 由于 HFile 存储经过序列化所以无法直接查看。可以通过 HBase 提供的命令来查看存储在 HDFS 上面的 HFile 元数据内容。
[jjmhadoop102 hbase]$ bin/hbase hfile -m -f /hbase/data/命名空间/表名/regionID/列族/HFile 名读流程 创建连接同写流程。 1创建 Table 对象发送 get 请求。 2优先访问 Block Cache查找是否之前读取过并且可以读取 HFile 的索引信息和布隆过滤器。 3不管读缓存中是否已经有数据了可能已经过期了都需要再次读取写缓存和store 中的文件。 4最终将所有读取到的数据合并版本按照 get 的要求返回即可。
合并读取数据优化
每次读取数据都需要读取三个位置最后进行版本的合并。效率会非常低所有系统需要对此优化。 1HFile 带有索引文件读取对应 RowKey 数据会比较快。 2Block Cache 会缓存之前读取的内容和元数据信息如果 HFile 没有发生变化记录在 HFile 尾信息中则不需要再次读取。 3使用布隆过滤器能够快速过滤当前 HFile 不存在需要读取的RowKey从而避免读取文件。布隆过滤器使用 HASH 算法不是绝对准确的出错会造成多扫描一个文件对读取数据结果没有影响
StoreFile Compaction
由于 memstore 每次刷写都会生成一个新的 HFile文件过多读取不方便所以会进行文件的合并清理掉过期和删除的数据会进行 StoreFile Compaction。 Compaction 分为两种分别是 Minor Compaction 和 Major Compaction。Minor Compaction会将临近的若干个较小的 HFile 合并成一个较大的 HFile并清理掉部分过期和删除的数据有系统使用一组参数自动控制Major Compaction 会将一个 Store 下的所有的 HFile 合并成一个大 HFile并且会清理掉所有过期和删除的数据由参数 hbase.hregion.majorcompaction控制默认 7 天。 Minor Compaction 控制机制 参与到小合并的文件需要通过参数计算得到有效的参数有 5 个 1hbase.hstore.compaction.ratio默认 1.2F合并文件选择算法中使用的比率。 2hbase.hstore.compaction.min默认 3 为 Minor Compaction 的最少文件个数。 3hbase.hstore.compaction.max默认 10 为 Minor Compaction 最大文件个数。 4hbase.hstore.compaction.min.size默认 128M为单个 Hfile 文件大小最小值小于这个数会被合并。 5hbase.hstore.compaction.max.size默认 Long.MAX_VALUE为单个 Hfile 文件大小最大值高于这个数不会被合并。 小合并机制为拉取整个 store 中的所有文件做成一个集合。之后按照从旧到新的顺序遍历。 判断条件为 ① 过小合并过大不合并 ② 文件大小/ hbase.hstore.compaction.ratio (剩余文件大小和) 则参与压缩。所有把比值设置过大如 10 会最终合并为 1 个特别大的文件相反设置为 0.4会最终产生 4 个 storeFile。不建议修改默认值 ③ 满足压缩条件的文件个数达不到个数要求3 count 10则不压缩。
Region Split
Region 切分分为两种创建表格时候的预分区即自定义分区同时系统默认还会启动一个切分规则避免单个 Region 中的数据量太大。
预分区自定义分区
每一个 region 维护着 startRow 与 endRowKey如果加入的数据符合某个 region 维护的rowKey 范围则该数据交给这个 region 维护。那么依照这个原则我们可以将数据所要投放的分区提前大致的规划好以提高 HBase 性能。 1手动设定预分区
create staff1,info, SPLITS [1000,2000,3000,4000]2生成 16 进制序列预分区
create staff2,info,{NUMREGIONS 15, SPLITALGO
HexStringSplit}3按照文件中设置的规则预分区 1创建 splits.txt 文件内容如下
aaaa
bbbb
cccc
dddd2然后执行
create staff3, info,SPLITS_FILE splits.txt4使用 JavaAPI 创建预分区
package com.jjm.hbase;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.hbase.HBaseConfiguration;
import org.apache.hadoop.hbase.TableName;
import org.apache.hadoop.hbase.client.*;
import org.apache.hadoop.hbase.util.Bytes;
import java.io.IOException;
public class HBaseConnect {public static void main(String[] args) throws IOException {// 1.获取配置类Configuration conf HBaseConfiguration.create();// 2.给配置类添加配置conf.set(hbase.zookeeper.quorum,hadoop102,hadoop103,hadoop104);// 3.获取连接Connection connection ConnectionFactory.createConnection(conf);// 4.获取 adminAdmin admin connection.getAdmin();// 5.获取 descriptor 的 builderTableDescriptorBuilder builder TableDescriptorBuilder.newBuilder(TableName.valueOf(bigdata, staff4));// 6. 添加列族builder.setColumnFamily(ColumnFamilyDescriptorBuilder.newBuilder(Bytes.toBytes(info)).build());// 7.创建对应的切分byte[][] splits new byte[3][];splits[0] Bytes.toBytes(aaa);splits[1] Bytes.toBytes(bbb);splits[2] Bytes.toBytes(ccc);// 8.创建表admin.createTable(builder.build(),splits);// 9.关闭资源admin.close();connection.close();}
}系统拆分
Region 的拆分是由 HRegionServer 完成的在操作之前需要通过 ZK 汇报 master修改对应的 Meta 表信息添加两列 infosplitA 和 infosplitB 信息。之后需要操作 HDFS 上面对应的文件按照拆分后的 Region 范围进行标记区分实际操作为创建文件引用不会挪动数据。刚完成拆分的时候两个 Region 都由原先的 RegionServer 管理。之后汇报给Master由Master将修改后的信息写入到Meta表中。等待下一次触发负载均衡机制才会修改Region的管理服务者而数据要等到下一次压缩时才会实际进行移动。 不管是否使用预分区系统都会默认启动一套 Region 拆分规则。不同版本的拆分规则有差别。系统拆分策略的父类为 RegionSplitPolicy。 0.94 版本之前 ConstantSizeRegionSplitPolicy 1 当 1 个 region 中 的 某 个 Store 下 所 有 StoreFile 的 总 大 小 超 过hbase.hregion.max.filesize 10G该 Region 就会进行拆分。 0.94 版本之后2.0 版本之前 IncreasingToUpperBoundRegionSplitPolicy 2 当 1 个 region 中 的 某 个 Store 下 所 有 StoreFile 的 总 大 小 超 过Min(initialSize*R^3 ,hbase.hregion.max.filesize)该 Region 就会进行拆分。其中 initialSize 的默认值为 2*hbase.hregion.memstore.flush.sizeR 为当前 Region Server 中属于该 Table 的Region 个数0.94 版本之后。 具体的切分策略为 第一次 split1^3 * 256 256MB 第二次 split2^3 * 256 2048MB 第三次 split3^3 * 256 6912MB 第四次 split4^3 * 256 16384MB 10GB因此取较小的值 10GB 后面每次 split 的 size 都是 10GB 了。 2.0 版本之后 SteppingSplitPolicy 3Hbase 2.0 引入了新的 split 策略如果当前 RegionServer 上该表只有一个 Region按照 2 * hbase.hregion.memstore.flush.size 分裂否则按照 hbase.hregion.max.filesize 分裂。这叫大道至简学海抽丝。
