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

用户5236754501065
110 阅读13分钟

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

Lecture10. 深入浅出 HBase 实战

01. 适用场景

1.1 什么是HBase

HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一。

参考Google BigTable 的设计，对稀疏表提供更高的存储空间使用率和读写效率。

采用存储计算分离架构，

  • 存储层基于HDFS存储数据，提供容错机制和高可靠性;
  • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力;

提供强─致语义，在 CAP理论中属于CP系统。

  • Consistency , Availability , Partition Tolerance

1.2 HBase和关系型数据库的区别

1.3 HBase数据模型

HBase 以列族（column family)组织数据，以行键( rowkey ）索引数据。

  • 列族需要在使用前预先创建，列名( column qualifier )不需要预先声明，因此支持半结构化数据模型。
  • 支持保留多个版本的数据，(行键＋列族＋列名+版本号）定位一个具体的值。

半结构化：用户可随时添加新的列名

逻辑结构

HBase是半结构化数据模型。以列族（ column family)为单位存储数据，以行键（rowkey）索引数据。

  • 列族需要在使用前预先创建，列名( column qualfier )不需要预先声明，因此支持半结构化数据模型。
  • 支持保留多个版本的数据，（行键＋列族＋列名＋版本号）定位一个具体值。

有冗余，有多版本

通过非关系型视图理解HBase数据模型:

  • 适合稀疏数据，缺省列不占用存储空间。
  • 通过(rowkey, column family, column qualifier, version )√唯一指定一个具体的值。
  • 允许批量读取多行的部分列族/列数据。

缺省的column family并不占用存储空间

物理结构

物理数据结构最小单元是 KeyValue结构;

  • 每个版本的数据都携带全部行列信息。
  • 同一行，同一列族的数据物理上连续有序存储。
  • 同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列。
  • 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序。
  • 同列族下不同物理文件间不保证数据全局有序。
  • 仅单个物理文件内有序。

数据冗余

数据排序

1.4 使用场景

适用场景∶

  • “近在线”（读写性能 ms-100ms）的海量分布式KV/宽表存储，数据量级可达到PB级以上
  • 写密集型（监控、日志）、高吞吐应用，可接受一定程度的时延抖动
  • 字典序主键索引、批量顺序扫描多行数据的场景
  • Hadoop大数据生态友好兼容
  • 半结构化数据模型，行列稀疏的数据分布，动态增减列名
  • 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化

典型应用

  • 电商订单数据：查询最新/待处理订单进度
  • 搜索推荐引擎：存储原始数据、排序推荐结果
  • 广告数据流∶触达、点击、转化等事件流
  • 用户交互数据：IM、Email、点赞、搜索
  • 时序数据引擎：日志、监控( OpenTSDB)
  • 图存储引擎：JanusGraph
  • 大数据生态：高度融入Hadoop生态

半结构化/字典序有序索引的数据

典型用例:

  • 字节跳动推荐中台基于HBase提供“近在线"”读写的推荐候选数据集

查询模式：

批量查询指定tenantID租户的指定 channelID频道下的推荐候选集。例如∶

start rowkey: "part1:tenant1:changel1",
end rowkey: "part1:tenant1:channel2",

对应数据∶

value:"features(e.g. sport, basketball,...)”
columns: "additional labels (e.g. region=CN,...)”

“近在线”海量分布式KV/宽表存储

典型用例:

  • 商家订单系统使用HBase管理买家、卖家的订单操作信息

查询指定orderlD订单最近新增/待处理的操作记录。例如︰

rowkey: "e1cb:orderlD1",column family: "customer"

对应多个column的数据:

column1: actionType1_actionlD1, value1: "{timestamp=21, action='...'}"
column2: actionType2_actionlD2, value2: "{timestamp=26, action='...'}" 
// 这一条才是23之后的目标
column3: checkpoint, value:"timestamp=23”

典型用例：

  • Facebook 在2010年开始使用HBase存储用户的互动消息，包括电子邮件、即时消息、短信等

查询模式：

查询指定userlD 用户包含给定词语word的最近N条消息的messagelD。例如:

rowkey: "userlD1", column:"cf:hello”

对应多个版本的数据︰

value1: "offset=23", version: "messagelD=1234",
value2: "offset=12", version: "messagelD=1134”,
value3: "offset=41", version: "messagelD=1034",...

写密集型的高吞吐场景

典型用例:

  • 时序存储引擎，典型场景是日志、监控数据存储，例如OpenTSDB ( Open Time Series Database )

查询模式︰

查询指定metric_uid指标在指定时间段的所有数据。例如:

start rowkey: “[hash]metric1:1655386954”,
end rowkey: “[hash]metric1:1665386954",
column family: "dp",

查询1655386954到1665386954时间内该监控的所有数据点

*rowkey 和column通过编码尽量简短，减少空间用量。

1.5 HBase数据模型的优缺点

02. 架构设计

2.1 HBase架构设计

主要组件包括:

  • HMaster :元数据管理，集群调度、保活。
  • RegionServer:提供数据读写服务，每个实例负责若干个互不重叠的rowkey 区间内的数据。
  • ThriftServer :提供Thrift API读写的代理层。

依赖组件包括:

  • Zookeeper :分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等。
  • HDFS:分布式文件系统，HBase数据存储底座。

2.2 Hmaster主要职责

  • 管理RegionServer 实例生命周期，保证服务可用性
  • 协调RegionServer数据故障恢复，保证数据正确性
  • 集中管理集群元数据,执行负载均衡等维护集群稳定性
  • 定期巡检元数据，调整数据分布，清理废弃数据等
  • 处理用户主动发起的元数据操作如建表、删表等

主要组件

  • ActiveMasterManager:管理HMaster的active/backup状态

    • 多实例选主、切主

  • ServerManager:管理集群内RegionServer的状态

    • 宕机后标记Server不健康、后续恢复

  • AssignmentManager :管理数据分片( region )的状态

    • 故障恢复、负载均衡...：数据分片调度

  • SplitWalManager：负责故障数据恢复的 WAL （中数据）拆分工作

  • LoadBalancer：定期巡检、调整集群负载状态

  • RegionNormalizer：定期巡检并拆分热点、整合碎片

  • CatalogJanitor：定期巡检、清理元数据

  • Cleaners：定期清理废弃的HFile / WAL等文件

  • MasterFileSystem：封装访问HDFS的客户端 SDK

2.3 RegionServer主要职责

  • 提供部分rowkey区间数据的读写服务的
  • 如果负责meta表，向客户端SDK提供rowkey位置信息
  • 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
  • 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等

主要组件

  • MemStore：基于SkipList（跳表）数据结构实现的内存态存储，定期批量写入硬盘

    • 先写到WAL，再写入MemStore，这次写入算成功

  • Write-Ahead-Log：顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据

  • Store：对应一个Column Family在一个region下的数据集合，通常包含多个文件

  • StoreFile：即 HFile，表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列

  • BlockCache：HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取

2.4 ZooKeeper主要职责

  • HMaster登记信息，对active/backup 分工达成共识
  • RegionServer 登记信息，失联时HMaster保活处理
  • 登记meta表位置信息，供SDK查询读写位置信息供
  • HMaster和RegionServer协作处理分布式任务

2.5 ThriftServer主要职责

  • 实现 HBase定义的 Thrift API，作为代理层向用户提供RPC读写服务
  • 用户可根据IDL自行生成客户端实现
  • 独立于RegionServer 水平扩展，用户可访问任意ThriftServer 实例
  • ( scan操作较特殊，需要同实例维护scan状态)

03. 大数据支撑

3.1 HBase在大数据生态的定位

  • 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务

    • 突然想做这样的分析，并不想当时建表

  • 支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据

  • 动存储大规模任务（例如MapReduce，Spark，Flink，兼容度毫）的中间/最终计算结果

  • 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问

  • 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。

3.2 水平扩展能力

  • 增加RegionServer 实例，分配部分region到新实例。
  • 扩展过程平滑，无需搬迁实际数据。
  • 可用性影响时间很短，用户基本无感知。

切换分片调度

3.3 Region 热点切分

  • 当某个region 数据量过多，切分成两个独立的子region分摊负载。

  • RegionServer在特定时机(flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行 RegionStateTransition。

  • 不搬迁实际数据，切分产生的新 region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。

    • （指针 reference file）指到原始未拆分文件

临时目录——正式目录——指引到原始文件

切分点选取

HBase原生提供的多种切分策略使用相同的切分点选择策略。

目标:优先把最大的数据文件均匀切分。

切分点选择步骤:

  1. 找到该表中哪个region 的数据大小最大

  2. 找到该region内哪个column family的数据大小最大

  3. 找到column family内哪个HFile的数据大小最大

  4. 找到HFile里处于最中间位置的Data Block

  5. 用这个Data Block的第一条KeyValue的Rowkey 作为切分点。

切分过程

  • 所有Column Family都按照统一的切分点来切分数据。

  • 目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

  • HFile 1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region 的rowkey区间。

  • 切分出的新region分别负责rowkey 区间[2000,2500)和[2500,4000)。

  • 每个新region分别负责原region的上/下半部分rowkey 区间的数据。

  • 在compaction 执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

流程设计

AssignmentManager检查cluster、table、region的状态后，创建 SplitTableRegionProcedure通过状态机实现执行切分过程。

3.4 Region碎片整合

  • 当某些region 数据量过小、碎片化，合并相邻 region 整合优化数据分布。
  • AssignmentManager创建 MergeTableRegionsProcedure 执行整合操作。
  • 不搬迁实际数据，通过 reference file定位原region 的文件，直到下次compaction时实际处理数据。
  • 注意∶只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。

3.5 Region负载均衡

调度策略

定期巡检各RegionServer上的region数量，保持region的数量均匀分布在各个 RegionServer 上

SimpleLoadBalancer具体步骤:

  1. 根据总region 数量和RegionServer数量计算平均region数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region数为5，负载均衡的RS 上region 数量应该在[4,6]区间内。
  2. 将RegionServer按照region数量降序排序，对region 数量超出上限的选取要迁出的region并按创建时间从新到老排序;
  3. 选取出region数量低于下限的RegionServer 列表，round-robin分配步骤⒉选取的regions, 尽量使每个RS的region数量都不低于下限;
  4. 处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近。

其他策略

SochasticLoadBalancer

  • 随机尝试不同的region放置策略，根据提供的cost function计算不同策略的分值排名（0为最优策略，1为最差策略）

  • cost计算将下列指标纳入统计:

    • region 负载、表负载、数据本地性(本地访问HDFS )、Memstore大小、HFile大小

  • 根据配置加权计算最终cost，选择最优方案进行负载均衡;

FavoredNodeLoadBalancer

  • 用于充分利用本地读写HDFS文件来优化读写性能。省去一次RPC
  • 每个region 会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region 的数据;-
  • 即使第一节点出现故障，HBase也可以将第二节点提升为第一节点，保证稳定的读时延;

3.6 故障恢复机制-HMaster

HMaster通过多实例基于Zookeeper选主实现高可用性

  • 所有实例尝试向Zookeeper的/hbase/active-master 临时节点CAS地写入自身信息，
  • 写入成功表示成为主实例，失败即为从实例，通过watch 监听/hbaselactive-master节点的变动。
  • 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主。

故障恢复机制-HMaster恢复流程

—、HMaster自身恢复流程:

  1. 监听到/hbase/active-master 临时节点被删除的事件，触发选主逻辑;
  2. 选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures 从之前状态继续执行;
  3. 故障HMaster 实例恢复后发现主节点已存在，继续监听/hbaselactive-master。

二、调度RegionServer的故障恢复流程:

  1. AssignmentManager 从 procedure列表中找出Region-In-Transition状态的region继续调度过程
  2. RegionServerTracker 从Zookeeper梳理_online状态的RegionServer列表，结合ServerCrashProcedure列表.HDFS中 WAL目录里alive / splitting 状态的RegionServer记录，获取掉线RegionServer的列表，分别创建ServerCrashProcedure 执行恢复流程。

3.7 故障恢复机制 - RegionServer

  • 每个 RegionServer实例启动时都会往Zookeeper的/hbaselrs路径下创建对应的临时节点。
  • HMaster通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions。
  • RegionServer的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster利用Zookeeper配合所有RegionServer 实例，分布式地处理WAL数据，提升恢复速度。

故障恢复机制- RegionServer 恢复流程

启动流程:

  1. 启动时去Zookeeper登记自身信息，告知主HMaster实例有新RS 实例接入集群
  2. 接收和执行来自HMaster的region调度命令
  3. 打开region前先从HDFS读取该region的recovered.edits目录下的WAL记录，回放恢复数据
  4. 恢复完成，认领Zookeeper上发布的分布式任务(如WAL 切分）帮助其他数据恢复
avatar
文章
阅读
粉丝