HBase介绍
HBase是Hadoop Database的简称,是建立在Hadoop文件系统之上的分布式面向列的数据库,它具有高可靠、高性能、面向列和可伸缩的特性,提供快速随机访问海量数据能力。
HBase采用Master/Slave架构,由HMaster节点、RegionServer节点、ZooKeeper集群组成,底层数据存储在HDFS上。
整体架构如图所示:
HMaster主要负责:
- 在HA模式下,包含主用Master和备用Master。
- 主用Master:负责HBase中RegionServer的管理,包括表的增删改查;RegionServer的负载均衡,Region分布调整;Region分裂以及分裂后的Region分配;RegionServer失效后的Region迁移等。
- 备用Master:当主用Master故障时,备用Master将取代主用Master对外提供服务。故障恢复后,原主用Master降为备用。
RegionServer主要负责:
- 存放和管理本地HRegion。
- RegionServer负责提供表数据读写等服务,是HBase的数据处理和计算单元,直接与Client交互。
- RegionServer一般与HDFS集群的DataNode部署在一起,实现数据的存储功能。读写HDFS,管理Table中的数据。
ZooKeeper集群主要负责:
- 存放整个 HBase集群的元数据以及集群的状态信息。
- 实现HMaster主从节点的Failover。
HDFS集群主要负责:
- HDFS为HBase提供高可靠的文件存储服务,HBase的数据全部存储在HDFS中。
结构说明:
Store
- 一个Region由一个或多个Store组成,每个Store对应图中的一个Column Family。
MemStore
- 一个Store包含一个MemStore,MemStore缓存客户端向Region插入的数据,当RegionServer中的MemStore大小达到配置的容量上限时,RegionServer会将MemStore中的数据“flush”到HDFS中。
StoreFile
- MemStore的数据flush到HDFS后成为StoreFile,随着数据的插入,一个Store会产生多个StoreFile,当StoreFile的个数达到配置的阈值时,RegionServer会将多个StoreFile合并为一个大的StoreFile。
HFile
- HFile定义了StoreFile在文件系统中的存储格式,它是当前HBase系统中StoreFile的具体实现。
HLog(WAL)
- HLog日志保证了当RegionServer故障的情况下用户写入的数据不丢失,RegionServer的多个Region共享一个相同的HLog。
HBase提供两种API来写入数据。
- Put:数据直接发送给RegionServer。
- BulkLoad:直接将HFile加载到表存储路径。
HBase为了保证数据可靠性,使用WAL(Write Ahead Log)来保证数据可靠性。它是HDFS上的一个文件,记录HBase中数据的所有更改。所有的写操作都会先保证将数据写入这个文件后,才会真正更新MemStore,最后写入HFile中。如果写WAL文件失败,则操作会失败。在正常情况下,不需要读取WAL文件,因为数据会从MemStore中持久化为HFile文件。但是如果RegionServer在持久化MemStore之前崩溃或者不可用,系统仍然可以从WAL文件中读取数据,回放所有操作,从而保证数据不丢失。
写入流程如图所示:
默认情况下RegionServer上管理的所有HRegion共享同一个WAL文件。WAL文件中每个记录都包括相关Region的信息。当打开Region时,需要回放WAL文件中属于该Region的记录信息。因此,WAL文件中的记录信息必须按Region进行分组,以便可以回放特定Region的记录。按Region分组WAL的过程称为WAL Split。
WAL Split由HMaster在集群启动时完成或者在RegionServer关闭时由ServershutdownHandler完成。在给定的Region再次可用之前,需要恢复和回放所有的WAL文件。因此在数据恢复之前,对应的Region无法对外服务。
HBase启动时,Region分配简要分配流程如下:
- HMaster启动时初始化AssignmentManager。
- AssignmentManager通过hbase:meta表查看当前Region分配信息。
- 如果Region分配依然有效(Region所在RegionServer依然在线),则保留分配信息。
- 如果Region分配无效,调用LoadBalancer来进行重分配。
- 分配完成后更新hbase:meta表。
本文主要关注集群重新启动和恢复相关内容,着重描述相关优化,减少HBase恢复时长。
RegionServer故障恢复流程
当HMaster检测到故障时,会触发SCP(Server Crash Procedure)流程。SCP流程包括以下主要步骤:
- HMaster创建WAL Split任务,用于对属于崩溃RegionServer上Region进行记录分组。
- 将原属于崩溃RegionServer上Region进行重分配,分配给正常RegionServer。
- 正常RegionServer执行Region上线操作,对需要恢复数据进行回放。
故障恢复常见问题
HMaster等待Namespace表超时终止
当集群进行重启时,HMaster进行初始化会找到所有的异常RegionServer(Dead RegionServer)并开始SCP流程,并继续初始化Namespace表。
如果SCP列表中存在大量的RegionServer,那么Namespace表的分配将可能被延迟并超过配置的超时时间(默认5分钟),而这种情况在大集群场景下是最常见的。为临时解决该问题,常常将默认值改大,但是必不能保证一定会成功。
另外一种方式是在HMaster上启用表来避免此问题(hbase.balancer.tablesOnMaster=hbase:namespace),HMaster会优先将这些表进行分配。但是如果配置了其它表也可以分配到HMaster或者由于HMaster性能问题,这将无法做到100%解决此问题。此外在HBase 2.X版本中也不推荐使用HMaster来启用表。解决这个问题的最佳方法是支持优先表和优先节点,当HMaster触发SCP流程时,优先将这些表分配到优先节点上,确保分配的优先级,从而完全消除此问题。
批量分配时RPC超时
HBase专门线性可扩展性而设计。如果集群中的数据随着表增加而增多,集群可以很容易扩展添加RegionServer来管理表和数据。例如:如果一个集群从10个RegionServer扩展到20个RegionServer,它在存储和处理能力方面将会增加。
随着RegionServer上Region数量的增加,批量分配RPC调用将会出现超时(默认60秒)。这将导致重新进行分配并最终对分配上线时间产生严重影响。
在10个RegionServer节点和20个RegionServer节点的测试中,RPC调用分别花费了约60秒和116秒。对于更大的集群来说,批量分配无法一次成功。主要原因在于对ZooKeeper进行大量的读写操作和RPC调用,用来创建OFFLINE ZNode节点,创建正在恢复的Region ZNode节点信息等。
恢复可扩展性测试
在10到100个节点的集群测试中,我们观察到恢复时间随着集群规模的增大而线性增加。这意味着集群越大,恢复所需的时间就越多。特别是当要恢复WAL文件时,恢复时间将会非常大。在100个节点的集群中,通过Put请求写入数据的情况下,恢复需要进行WAL Split操作,发现需要100分钟才能从集群崩溃中完全恢复。而在相同规模的集群中,如果不写入任何数据大约需要15分钟。这意味着85%以上的时间用于WAL Split操作和回放用于恢复。
Cluster Size | Recovered edit files count | Total No. Of regions [2k per RS] | Region Assignment (with WAL split) | Empty Region Assignment |
---|---|---|---|---|
10 Node | 4,00,000 | 20,000 | 7.5 Mins | 4 Min |
20 Node | 8,00,000 | 40,000 | 12 Mins | 6 Mins |
40 Node | 1.6 Million | 80,000 | 42 Mins | 7 Mins |
100 Nodes | 4 Million | 0.2 Million | 106 Mins | 15 Mins |
下面我们将分析测试过程中发现的瓶颈在哪里?
恢复耗时分析
HDFS负载
在10个节点的HBase集群上,通过JMX来获取HDFS的RPC请求监控信息,发现在启动阶段有1200万读取RPC调用。
其中GetBlockLocationNumOps:380万、GetListingNumOps:13万、GetFileInfoNumOps:840万。
当集群规模达到100个时,RPC调用和文件操作将会非常大,从而对HDFS负载造成很大压力,成为瓶颈。可能由于以下原因导致HDFS写入失败、WAL Split和Region上线缓慢超时重试。
- 巨大的预留磁盘空间。
- 并发访问达到DataNode的xceiver的限制。
HMaster负载
HMaster使用基于ZooKeeper的分配机制时,在Region上线过程中HMaster会创建一个OFFLINE ZNode节点,RegionServer会将该ZNode更新为OPENING和OPENED状态。对于每个状态变化,HMaster都会进行监听并处理。
对于100个节点的HBase集群,大概将会有6,000,000个ZNode创建和更新操作和4,000,000个监听事件要进行处理。
ZooKeeper的监听事件通知处理是顺序的,旨在保证事件的顺序。这种设计在Region锁获取阶段将会导致延迟。在10个节点的集群中发现等待时间为64秒,而20节点的集群中等待时间为111秒。
GeneralBulkAssigner 在批量发送OPEN RPC请求到RegionServer之前会获取相关Region的锁,再收到RegionServer的OPEN RPC请求响应时才会释放该锁。如果RegionServer再处理批量OPEN RPC请求时需要时间,那么在收到确认响应之前GeneralBulkAssigner将不会释放锁,其实部分Region已经上线,也不会单独处理这些Region。
HMaster按照顺序创建OFFLINE ZNode节点。观察发现在执行批量分配Region到RegionServer之前将会有35秒的延迟来创建ZNode。
采用不依赖ZooKeeper的分配机制将会减少ZooKeeper的操作,可以有50%左右的优化。HMaster依然会协调和处理Region的分配。
提升WAL Split性能
持久化FlushedSequenceId来加速集群重启WAL Split性能(HBASE-20727)
ServerManager有每个Region的flushedSequenceId信息,这些信息被保存在一个Map结构中。我们可以利用这些信息来过滤不需要进行回放的记录。但是这个Map结构并没有被持久化,当集群重启或者HMaster重启后,每个Region的flushedSequenceId信息将会丢失。
如果这些信息被持久化那么即使HMaster重启,这些依然存在可用于过滤WAL记录,加快恢复记录和回放。hbase.master.persist.flushedsequenceid.enabled 可用于配置是否开启此功能。flushedSequenceId信息将会定时持久化到如下目录 < habse root dir >/.lastflushedseqids。可以通过参数 hbase.master.flushedsequenceid.flusher.interval 来配置持久化间隔,默认为3小时。
注意:此特性在HBase 1.X版本不可用。
改善WAL Split在故障切换时稳定性(HBASE-19358)
在WAL记录恢复期间,WAL Split任务将会将RegionServer上的所有待恢复记录输出文件打开。当RegionServer上管理的Region数量较多时将会影响HDFS,需要大量的磁盘保留空间但是磁盘写入非常小。
当集群中所有RegionServer节点都重启进行恢复时,情况将变得非常糟糕。如果一个RegionServer上有2000个Region,每个HDFS文件为3副本,那么将会导致每个WAL Splitter打开6000个文件。
通过启用hbase.split.writer.creation.bounded可以限制每个WAL Splitter打开的文件。当设置为true时,不会打开任何recovered.edits的写入直到在内存积累的记录已经达到 hbase.regionserver.hlog.splitlog.buffersize(默认128M),然后一次性写入并关闭文件,而不是一直处于打开状态。这样会减少打开文件流数量,从hbase.regionserver.wal.max.splitters * the number of region the hlog contains减少为hbase.regionserver.wal.max.splitters * hbase.regionserver.hlog.splitlog.writer.threads。
通过测试发现在3节点集群中,拥有15GB WAL文件和20K Region的情况下,集群整体重启时间从23分钟缩短为11分钟,减少50%。
hbase.regionserver.wal.max.splitters = 5
hbase.regionserver.hlog.splitlog.writer.threads= 50
WAL Split为HFile(HBASE-23286)
WAL恢复时使用HFile文件替换Edits文件这样可以避免在Region上线过程中写入。Region上线过程中需要完成HFile文件校验、执行bulkload加载并触发Compaction来合并小文件。此优化可以避免读取Edits文件和持久化内存带来的IO开销。当集群中的Region数量较少时(例如50个Region)观察发现性能有显著提升。
当集群中有更多的Region时,测试发现由于大量的HFile写入和合并将会导致CPU和IO的增加。可以通过如下额外的措施来减少IO。
- 将故障RegionServer作为首选WAL Splitter,减少远程读取。
- 将Compaction延迟后台执行,加快region上线处理。
Observer NameNode(HDFS-12943)
当HBase集群规模变大时,重启会触发大量的RPC请求,使得HDFS可能成为瓶颈,可以通过使用Observer NameNode负担读请求来降低HDFS的负载。
总结
通过上述分析,可以配置如下参数来提升HBase MTTR,尤其是在集群整体从崩溃中恢复的情况。
Configuration | Recommendation | Remarks |
---|---|---|
HMaster hbase.master.executor.openregion.thread | 2 * no. of cores | Opened region thread to process OPENED ZK events. Can increase based on the cores in large cluster. |
HMaster hbase.assignment.zkevent.workers | 2 * no. of cores | ZK event worker thread to process RIT ZK notification, can be tuned based on cores |
HMaster hbase.master.skip.log.split.task | true | Master participate in WAL split as namespace region is assigned to Hmaster. Hmaster may be overloaded during MTTR |
HMaster hbase.balancer.tablesOnMaster | hbase:namespace | Assign namespace region to Hmaster, so that HM WAL will be split first to recover namespace region and there wont be any Hmaster abort due to Namespace init timeout Note: Later this will be replaced with Assign system tables to specified RS Group |
RegionServer hbase.regionserver.executor.openregion.threads | 2 * no. of cores | Handlers to process Open region requests |
RegionServer hbase.regionserver.metahandler.count | 5 * no. of cores | Meta operation handlers. During full cluster restart, all RSs are opening the region concurrently, so we need more handlers. We observed better perf upto 400 handlers. |
RegionServer hbase.regionserver.wal.max.splitters | Same as hbase.regionserver.maxlogs | To perform WAL split concurrently and avoid overlap with assignment region cycle. If SCP is blocked for assignment which takes more time, WAL split would be delayed. |
RegionServer hbase.regionserver.hlog.splitlog.writer.threads | 50 | Works in combination with hbase.split.writer.creation.bounded Writer thread to flush the recovered edits region wise. , can be reduced when active regions are less |
RegionServer hbase.split.writer.creation.bounded | true | To control the number of open files in HDFS for writing recovered edits. If true, edits are cached and flushed once the buffer is full. |
RegionServer hbase.wal.split.to.hfile | true | When the active regions are less per RS, can use this configurations to reduce IO. But if the active regions are high, this feature may not have impact. |
RegionServer hbase.regionserver.maxlogs | 20 | Lesser the logs, lesser the time for wal split & recovering edits |
HMaster hbase.master.persist.flushedsequenceid.enabled | true | Skip WAL edits which are already flushed into Hfile |
HMaster hbase.rpc.timeout | 120000 | Bulk assignment RPC gets timed out due to slow processing by RS if there are many regions in RS |
本文由华为云发布。