这是我参与「第四届青训营 」笔记创作活动的的第6天
今天的笔记主要分为四个部分：
一、适用场景
二、架构设计
三、大数据支撑
四、最佳实践
一、适用场景
1.HBase设计理念
1.1什么是HBase？
HBase是一个开源的NoSQL分布式数据库，是Apache软件基金hi顶级项目之一。
参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。
采用存储计算分离架构：
-存储层基于HDFS存储数据，提供容错机制和高可靠性
-计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
提供强一致语义，在CAP理论中属于CP系统
1.2HBase和关系型数据库的区别
2.数据模型
2.1HBase数据模型概述
HBase以列族为单位存储数据，以行键索引数据。
-列族需要在使用前预先创建，列名不需要预先声明，因此支持半结构化数据模型。
-支持保留多个版本的数据，（行键+列族+列名+版本号）定位一个具体的值
2.2HBase数据模型-逻辑结构
-HBase是半结构化数据模型。以列族为单位存储数据，以行键索引数据。
2.3HBase数据模型-物理结构
-物理数据结构最小单元是KeyValue结构：
-每个版本的数据都携带全部行列信息。
-同一行，同一列组的数据物理上连续有序存储。
-同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列
-不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
-仅单个物理文件内有效
3.适用场景
-“近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上
-写密集型、高吞吐应用，可接受一定程度的时延抖动
-字典序主键索引、批量顺序扫描多行数据的场景
-Hadoop大数据生态友好兼容
-半结构化数据模型，行列稀疏的数据分布，动态增减列名
-敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
4.业界典型用例
4.1字节跳动推荐中台基于HBase提供“近在线”读写的推荐候选数据集
4.2商家订单系统使用HBase管理买家、卖家的订单操作信息
4.3Facebook在2010年开始使用HBase存储用户的互动消息，包括电子邮件、即时消息、短信等
5.HBase数据模型的优缺点
二、HBase架构设计
2.1架构设计
主要组件包括：
-HMaster：元数据管理，集群调度、保活。
-RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据。
-ThriftServer：提供ThriftAPI读写的代理层。
依赖组件包括：
-Zookeeper：分布式一致性共识协作管理
-HDFS：分布式文件系统，HBase数据存储底座
2.2Hmaster主要职责
-管理RegionServer实例生命周期，保证服务可用性
-协调RegionServer数据故障恢复，保证数据正确性
-集中管理集群元数据，执行负载均衡等维护集群稳定性
-定期巡检元数据，调整数据分布，清理废弃数据等
-处理用户主动发起的元素数据操作如建表、删表等
2.3RegionServer主要职责
-提供部分rowkey区间数据的读写服务
-如果负责meta表，向客户端SDK提供rowkey位置信息
-认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
-处理HMaster下达的元数据操作，如Region打开/关闭/分裂/合并操作
2.4ZooKeeper主要职责
-HMaster登记信息，对active/backup分工达成共识
-RegionServer登记信息，失联时HMaster保活处理
-登记meta表位置信息，供SDK查询读写位置信息
-供HMaster和RegionServer协作处理分布式任务
2.5ThriftServer主要职责
-实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
-用户可根据IDL自行生成客户端实现
-独立于RegionServer水平扩展，用户可随意访问任意ThriftServer实例
三、大数据支撑
3.1HBase在大数据生态的定位
-对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务
-支持字典序批量扫描大量数据，支持只读取部分列族数据，灵活支持不同查询模式，避免读取不必要的数据
-存储大规模任务的中间或最终结果
-平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问
-精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费
3.2水平扩展能力
-增加RegionServer实例，分配部分region到新实例
-扩展过程平滑，无需搬迁实际数据
-可用性影响时间很短，用户基本无感知
3.3Region热点切分-流程设计
AssignmentManager检查cluster、table、region的状态后，创建SplitTableRegionProcedure通过状态机实现执行切分过程。
3.4Region碎片整合-流程设计
类似于region切分，不立刻处理实际数据文件，而是通过创建reference files引用到原文件，然后原子的更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠CatalogJanitor异步巡检元数据处理遗留数据。
3.5故障恢复机制-HMaster
HMaster通过多实例基于Zookeeper选主实现高可用性
-所有实例尝试向Zookeeper的hbase、active-master临时节点CAS写入自身信息
-写入成功表示成为主实例，失败即为从实例，通过watch监听hbase、active-master结点的变动
-主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主
3.6Distributed Log Split原理
背景：
-写入HBase的数据首先顺序持久化到Write-Ahead-Log，然后写入内存态的MemStore即完成，不立即写盘，RegionServer故障会导致内存中的数据丢失，需要回放WAL来恢复
-同RegionServer的所有region复用WAL，因此不同region的数据交错穿插，RegionServer故障后重新分配region前需要先按region维度拆分WAL
四、最佳实践分享
4.1Rowkey设计策略
场景分类
-不需要顺序扫描批量连续rowkey
-需要顺序扫描批量连续rowkey
-rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中
4.2Column Family设计策略
-Column family数量过多容易影响性能，建议尽量少，不超过5个
-需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族
-列族名称尽量短，因为会冗余存储到每个KeyValue中
4.3ByteTable-字节跳动自研分布式表格存储系统
优势：
-存储层基于字节跳动自研分布式存储底座，从设计上充分支持在线场景的性能、功能需求
-采用C++编写构建，杜绝了Garbage Collection在Stop-The-World阶段带来的性能抖动
-架构设计上支持更细粒度、更灵活的数据分片组织方式，激活更多优化空间
-元数据设计提供更好的故障域控制，避免多租户相互影响
-更短的故障恢复时间，对在线场景的高可用性支持更好
