#带着问题去学习寻找答案,其实也是工作和生活中的每个执行的一小步#
问题:
- Region什么条件触发分片? 不同的版本有不同的策略,0.94版本之前的是默认当Region中某个Store的所有Store File大小总和超过10G
- Hflie划分个数的依据? memstore每次刷写生成一个新的HFile
- 在flush的时候是否阻塞客户端读写? flush是以Region为单位进行操作的,不会阻塞读,但是会短暂阻塞写,Region级别的flush影响可以忽略,RegionServer级别对写阻塞可达几秒甚至几分钟。
- 在合并的时候是否阻塞客户端读写,合并触发的最小单位是? Compaction是以Store为单位进行合并的,阻塞写不阻塞读。小合并对更新服务的阻塞不会太久,大合并可能会因为占用过多资源而对客户端的读写有影响
- flush的触发条件有不一致的地方 ?
- 合并条件:7天周期的是指触发的大合并,Store下默认3个HFile触发的是小合并。
- ZK对Hbase集群的作用是? 分三点:保证集群的高可用,监控Region Server的状态,存储元数据位置信息并维护集群配置
- *单元格由(rowkey)+(列族:列名)+(时间戳)。
- *版本数为N即代表hbase在磁盘(HDFS)中存储了n个版本的单元格信息。
- *客户端的put操作只负责在MemStore中追加写入并且以时间戳作为区别,不需要管理版本数,也不需要查找统计并标记删除前版本的墓碑,版本的整理和删除会在flush和compact操作中完成。
- *数据的物理删除操作是在大合并的时候。只有在大合并的时候才会删除数据并清理标记删除的墓碑文件,但是大合并资源耗费很大,不常触发,生产上建议关闭自动触发而在空闲时间手动触发大合并。
- *大合并:指定region的一个列族的所有HFile合并完成后,这个列族的所有HFile文件合并成一个HFile文件,并且【会】清理掉过期和删除的数据。
- *小合并:将region的一个列族的多个小的HFile文件内容读取出来合并生成一个大的HFile,把新文件设置成激活状态,然后删除小的HFile(默认128M以下称为小文件),但【不会】清理过期和删除的数据。hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size,前者表示一个store中的文件数超过多少就应该进行minor合并,后者表示参数合并的文件大小最大是多少,超过此大小的文件不参与minor合并,相当于通过这个参数定义了运维者认为的小文件。
- *Region Split拆分/分片: 默认情况下,每个Table起初只有一个Region,随着数据的不断写入,压缩也会造成整体StoreFile变得很大,所以对于Region维度来说,会自动进行拆分。刚拆分时,两个子Region都位于当前的RegionServer,但处于负载均衡的考虑,HMaster有可能会将某个Region转移给其他的Region Server。
- *合并原理:分为三步排序文件、合并文件、代替原文件服务。HBase首先从待合并的文件中读出HFile中的key-value,再按照由小到大的顺序写入一个新文件(storeFile)中。这个新文件将代替所有之前的文件,对外提供服务。
参考链接:https://blog.csdn.net/qq_37865420/article/details/108323487
高级进阶:
《HBase Rowkey设计和实现》 https://mp.weixin.qq.com/s/aEhpvpRyV4X2P4LmiWiOMg
《HBase性能与可用性在滴滴的探索与实践》 https://mp.weixin.qq.com/s/Ixhxnkc2quXNQgacRWO5kA