这是参加青训营的第13天
一、HBase 核心数据模型
- HBase 是存储计算分离架构，以 HDFS 作为分布式存储底座。数据实际存储在 HDFS。
- HBase 依赖 Zookeeper 实现元数据管理和服务发现。Client 通过 Zookeeper 配置连接到 HBase集群
- Log-Structured Merge Tree 了解 LSM tree 的基本结构和特性。
-
HBase 写流程：
- 数据先写入 WAL 持久化，用于宕机时恢复内存里丢失的数据；
- 再写入内存态 MemStore，以一种跳表（SkipList）数据结构提供有序的数据和高效的随机读写；
- 当满足特定条件时（比如内存中数据过多，或间隔时间过长），MemStore 数据以 HFile 格式写入 HDFS
-
HBase 读流程
- 首次读某个 rowkey 时，client 需要从 Zookeeper 获取 hbase:meta 表位于哪个 RegionServer上；
- 然后访问该 RegionServer 查询 hbase:meta 表该 rowkey 对应 region 所在的 RegionServer B；
- Client 缓存该位置信息，去 RegionServer B 读取 rowkey；
- 基于该region内可能存在该 rowkey 的 HFile 和 MemStore 构建一个最小堆，用以全局有序地 scan 数据（具体实现可搜索参考 LSM tree 设计原理）
-
Compaction
-
HBase 基于策略和定期整理 HFile 文件集合，将多个有序小文件合并成若干个有序的大文件。
-
HBase 提供两种 compaction 类型：
- Minor compaction： 指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。
- Major compaction： 指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。
-
Compaction 触发条件：
- memstore flush：可以说compaction的根源就在于flush，memstore 达到一定阈值或其他条件时就会触发flush刷写到磁盘生成HFile文件，正是因为HFile文件越来越多才需要compact。HBase每次flush之后，都会判断是否要进行compaction，一旦满足minor compaction或major compaction的条件便会触发执行。
- 后台线程周期性检查： 后台线程 CompactionChecker 会定期检查是否需要执行compaction，检查周期为hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier，这里主要考虑的是一段时间内没有写入请求仍然需要做compact检查。其中参数 hbase.server.thread.wakefrequency 默认值 10000 即 10s，是HBase服务端线程唤醒时间间隔，用于log roller、memstore flusher等操作周期性检查；参数 hbase.server.compactchecker.interval.multiplier 默认值1000，是compaction操作周期性检查乘数因子。10 * 1000 s 时间上约等于2hrs, 46mins, 40sec。
- 手动触发：是指通过HBase Shell、Master UI界面或者HBase API等任一种方式 执行 compact、major_compact等命令。
-
客户端定位数据
直连HBase的客户端需要配置对应的Zookeeper信息来定位数据所在的RegionServer，具体包括zookeeper集群实例的地址列表和该hbase集群在zookeeper中对应的根路径。
直连客户端具体定位步骤如下：
- 客户端访问Zookeeper获取元信息表hbase:meta所在的regionserver地址；
- 客户端访问该regionserver查询要读/写的table的rowkey在哪个regionserver；
- 客户端访问存数据的regionserver进行读写。
通过Thrift协议访问HBase的客户端需要ThriftServer的地址，通过ThriftServer转发请求。可以通过Consul实现thriftserver的服务发现。
LSM tree
HBase将每个column family的数据独立管理，称为HStore。一个HStore包含一到多个物理文件块（称为HFile）存储到HDFS。实际存储时每个column family独立存储，一个column family对应多个HFile文件块。
每个HFile内的数据按rowkey有序存储，但HFile间没有顺序保证。这一特点是由于LSM的写入方式决定的，下面介绍LSM树的读写流程：
- 写入：写入操作先记录到Write-Ahead Log持久化（可选）保存，然后写入内存中的MemStore。WAL可以保证实例挂掉或重启后丢失的内存数据可以恢复。
- 读取：从写入逻辑可以看出HFile包含的rowkey范围会有交集，以全局rowkey顺序读取就需要以一种归并排序的形式组织所有HFile。HBase会打开该cf下所有HFile，分别构建一个迭代器用以rowkey从小到大扫对应HFile的数据。所有这些迭代器又以当前指向rowkey的大小组织成一个最小堆，这样堆顶的迭代器指向的rowkey就是下一个全局最小的rowkey。迭代该rowkey后重新调整最小堆即可。
二、HBase适用场景
- 近在线”的海量分布式KV/宽表存储，数据量级达到百TB级以上
- 写密集型应用，高吞吐，可接受一定的时延抖动
- 需要按行顺序扫描的能力
- 接入Hadoop大数据生态
- 结构化、半结构化数据，可以经常新增/更新列属性
- 平滑的水平扩展
\
业务落地场景包括：
- 电商订单数据 抖音电商每日交易订单数据基于 HBase 存储，支持海量数据存储的同时满足稳定低延时的查询需求，并且只需相对很低的存储成本。通过多个列存储订单信息和处理进度，快速查询近期新增/待处理订单列表。同时也可将历史订单数据用于统计、用户行为分析等离线任务。
- 搜索推荐引擎 存储网络爬虫持续不断抓取并处理后的原始网页信息，通过 MapReduce、Flink、Spark 等大数据计算框架分析处理原始数据后产出粗选、精选、排序后的网页索引集，再存储到 HBase 以提供近实时的随机查询能力，为上层的多个字节跳动应用提供通用的搜索和推荐能力。
- 大数据生态 天生融入 Hadoop 大数据生态。对多种大数据组件、框架拥有良好的兼容性，工具链完善，快速打通大数据链路，提高系统构建落地效率，并借助 HDFS 提供可观的成本优势。敏捷平滑的水平扩展能力可以自如地应对数据体量和流量的快速增长。
- 广告数据流 存储广告触达、点击、转化等事件流，为广告分析系统提供快速的随机查询及批量读取能力，助力提升广告效果分析和统计效率。
- 用户交互数据 Facebook 曾使用 HBase 存储用户交互产生的数据，例如聊天、评论、帖子、点赞等数据，并利用 HBase 构建用户内容搜索功能。
- 时序数据引擎 基于 HBase 构建适用于时序数据的存储引擎，例如日志、监控数据存储。例如 OpenTSDB（Open Time Series Database）是一个基于 HBase 的时序存储系统，适用于日志、监控打点数据的存储查询。
- 图存储引擎 基于 HBase 设计图结构的数据模型，如节点、边、属性等概念，作为图存储系统的存储引擎。例如 JanusGraph 可以基于 HBase 存储图数据。
