深入浅出HBase实战|青训营笔记

huntressie
76 阅读10分钟

这是我参与「第四届青训营 」笔记创作活动的的第10天

  • 适用场景
    • 设计理念
      • HBase基于HDFS实现存储计算分离框架的分布式表格存储服务
      • 是一个开源的NoSQL分布式数据库，参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率
      • 基于存储计算分离架构
        • 存储层基于HDFS存储数据，提供容错机制和高可靠性
        • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
      • 提供强一致语义，在CAP理论中属于CP系统
    • 数据模型
      • HBase以列族(column family)组织数据，以行键(rowkey)索引数据
        • 基本概念
          • 行键(rowkey)
            • 用于唯一索引一行数据的"主键"，以字典序组织。一行可以包括多个列族。
          • 列族(column family)
            • 用于组织一系列列名，一个列族可以包含任意多个列名。每个列族的数据物理上相互独立地存储，以支持按列读取部分数据。
          • 列名(column qualifier)
            • 用于定义到一个具体的列，一个列名可以包含多个版本的数据。不需要预先定义列名，以支持半结构化的数据模型。
          • 版本号(version)
            • 用于标识一个列内多个不同版本的数据，每个版本号对应一个值。
          • 值(value)
            • 存储的一个具体值。
        • 列族需要在使用前预先创建，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型。
        • 支持保留多个版本的数据，(行键+列族+列名+版本号)定义一个具体的值
      • 逻辑模型
        • 适合稀疏数据，缺省列不占用存储空间
        • 通过(行键+列族+列名+版本号)定义一个具体的值
        • 允许批量读取多行的部分列族/列数据
      • 物理结构
        • 物理数据结构的最小单元是keyvalue结构
          • 每个版本的数据都携带全部行列信息
          • 同一行、同一列族的数据物理上连续有序存储
          • 同列族内的keyvalue按rowkey字典序升序，column qualifier升序，value降序排列
          • 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
          • 同列族下不同物理文件间不保证数据全局有序
          • 仅单个物理文件内有序
    • 使用场景
      • "近在线"的海量分布式KV/宽表存储，数据量级可达到PB级以上
      • 写密集型、高吞吐应用，可接受一定程度的时延抖动
      • 字典序主键索引、批量顺序扫描多行数据的场景
      • Hadoop大数据生态友好兼容
      • 半结构化数据模型，行列稀疏的数据分布，动态增删列名
      • 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
  • 架构设计
    • 主要组件
      • HMaster
        • 元数据管理，集群调度、保活。
        • 主要职责
          • 管理RegionServer实例生命周期，保证服务可用性
          • 协调RegionServer数据故障恢复，保证数据正确性
          • 集中管理集群元数据，执行负载均衡等维护集群稳定性
          • 定期巡检元数据，调整数据分布，清理废弃数据等
          • 处理用户主动发起的元数据操作如建表、删表等
        • 主要组件
          • ActiveMasterManager
            • 管理HMaster的active/backup状态
          • ServerManager
            • 管理集群内RegionServer的状态
          • AssignmentManager
            • 管理数据分片(region)的状态
          • SplitWalManager
            • 负责故障数据恢复的WAL拆分工作
          • LoadBalancer
            • 定期巡检、调整集群负载状态
          • RegionNormalize
            • 定期巡检并拆分热点、整合碎片
          • CatalogJanitor
            • 定期巡检、清理元数据
          • Cleaners
            • 定期清理废弃的HFile\WAL等文件
          • MasterFileSystem
            • 封装访问HDFS的客户端SDK
      • RegionServer
        • 提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
        • 主要职责
          • 提供部分rowkey区间数据的读写服务
          • 如果负责meta表，向客户端SDK提供rowkey位置信息
          • 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
          • 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等
        • 主要组件
          • MemStore
            • 基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
          • Write-Ahead-Log
            • 顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
          • StoreFile
            • 即HFile，表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
          • BlockCache
            • HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取
      • ThriftServer
        • 提供Thrift API读写的代理层
        • 主要职责
          • 实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
          • 用户可根据IDL自行生成客户端实现
          • 独立于RegionServer水平扩展，用户可访问任意ThriftServer实例(scan操作较特殊，需要同实例维护scan状态)
    • 依赖组件
      • ZooKeeper
        • 分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等。
        • 主要职责
          • HMaster登记信息，对active/backup分工达成共识
          • RegionServer登记信息，失联时HMaster保活处理
          • 登记Meta表位置信息，供SDK查询读写位置信息
          • 供HMaster和RegionServer协作处理分布式任务
      • HDFS
        • 分布式文件系统，HBase数据存储底座
  • 大数据支撑
    • 水平扩展能力
      • 增加RegionServer实例，分配部分Region到新实例
      • 扩展过程平滑，无需搬迁实际数据
      • 可用性影响时间很短，用户基本无感知
    • Region热点切分
      • 当某个Region数据量过多，切分为两个独立的子Region分摊负载
      • RegionServer在待定时机(flush、compaction)检查Region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition
      • 不搬迁实际数据，切分产生的新Region数据目录下生成一个以原Region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。
      • 切分点选择
        • 目标
          • 优先把最大的数据文件均匀切分
        • 切分点选择步骤
            1. 找到该表中哪个Region的数据大小最大
            1. 找到该表中哪个column family最大
            1. 找到该表中哪个HFile最大
            1. 找到HFile里处于最中间位置的Data Block
            1. 用这个Data Block的第一条KeyValue的RowKey作为切分点
        • 切分步骤
          • 所有column family都按照统一的切分点来切分数据
          • 目的是优先均分最大的文件，不保证所有column family的所有文件都被均分
          • 最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对其新Region的rowkey区间
          • 每个新Region分别负责原Region的上/下半部分rowkey区间的数据
          • 在compaction执行前不实际切分文件，新Region下的文件通过reference file指向原文件读取实际数据
    • 碎片整合
      • 当某些Region数据量较小、碎片化，合并相邻Region整合优化数据分布
      • 不搬迁实际数据,通过reference file指向原文件读取实际数据，直到下次compaction时实际处理数据。
      • 注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定
    • 负载均衡策略
      • 定期巡检RegionServer上的region数量，保持region的数量均匀分布在各个RegionServer上。
      • SimpleLoadBalancer
          1. 根据总Region数量和RegionServer数量计算平均Region数，设定弹性上下界避免不必要的操作。
          1. 将RegionServer按照Region数量降序排序，对Region数量超出上限的选取要迁出Region并按创建时间从新到老排序
          1. 选取出Region数量低于下限的RegionServer列表，round-robin分配步骤2选取的Region，尽量使每个RS的Region数量都不低于下界
          1. 处理边界情况，无法满足所有RS的Region数量都在合理范围时，尽量保持Region数量相近
      • 其他策略
        • StochasticLoadBalancer
          • 随机尝试不同的region放置策略，根据提供的cost function计算不同策略的分值排名
          • cost计算将下列指标纳入统计
            • Region负载、表负载、数据本地性(本地访问HDFS)、Memstore大小、HFile大小
          • 根据配置加权计算最终cost，选择最优方案进行负载均衡
        • FavoredNodeLoadBalance
          • 用于充分利用本地读写HDFS文件来优化读写性能
          • 每个Region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该Region的数据
          • 即使第一节点出现故障，HBase也可以将第二节点提升为第一节点，保证稳定的读时延
    • 故障恢复机制
      • HMaster
        • 通过多实例基于ZooKeeper选主实现高可用性
          • 所有实例尝试向ZooKeeper的/hbase/active-master临时节点CAS写入自身信息
          • 写入成功表示成为主实例，失败则成为从实例，通过watch监听/hbase/active-master节点的变动
          • 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主
        • 自身恢复流程
            1. 监听到/hbase/active-master临时节点被删除的时间，触发选主逻辑
            1. 选主成功后执行HMaster启动流程，从持久化存储读取未完成的Procedures从之前状态继续执行
            1. 故障HMaster实例恢复后发现主节点已存在，继续监听/hbase/active-master
      • RegionServer
        • 每个RegionServer实例启动时都会向ZooKeeper的/hbase/rs路径下创建对应的临时节点
        • HMaster通过监听RegionServer在ZooKeeper的临时节点情况，监控数据读写服务的可用性，及时调度恢复不可用的regions
        • RegionServer的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster利用ZooKeeper配合所有RegionServer实例，分布式地处理WAL数据，提升恢复速度
      • Distributed Log Split
        • 背景
            1. 写入HBase的数据首先顺序持久化到Write-Ahead-Log中，然后写入内存的MemStore即完成，不立即写盘，RegionServer故障会导致内存中的数据丢失，需要回放WAL恢复
            1. 同RegionServer的所有Region复用WAL，因此不同Region的数据交错穿插，RegionServer故障后重新分配的Region前需要先按Region维度拆分WAL
        • 实现原理
          • HMaster监测到RegionServer挂掉，读取该RegionServer负责的Region，找到WAL，将拆分任务发给ZooKeeper，ZooKeeper分发给其他RegionServer完成拆分
      • Distributed Log Replay
        • HMaster先将故障RegionServer上的所有Region以Recovering状态调度分配到其他正常RS上
        • 再进行类似Distributed Log Split的WAL日志按Region维度切分
        • 切分后不写入HDFS，而是直接回放，通过SDK写流程将WAL记录写到对应的新RS
        • Recovering状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成
  • 最佳实践
    • rowkey设计策略
      • 不需要顺序扫描批量连续rowkey
        • 对原始rowkey进行哈希，作为真实rowkey前缀，建议取适当长度的子串，避免过多占用存储空间
      • 需要顺序扫描批量连续rowkey
        • 首先用groupID/appID/userID前缀避免数据热点，然后加上定义顺序的信息(如时间戳)
        • ID前缀也建议哈希处理，避免非预期的热点
      • rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中
      • 避免使用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通过水平扩容缓解
    • Column Family设计
      • Column Family数量过多容易影响性能，建议尽量少，不超过5个
      • 需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族
      • 列族以及列名尽量短，因为会冗余存储到每个KeyValue中
avatar
文章
阅读
粉丝