HBase写入流程

贵有恒,何必三更起、五更眠、最无益,只怕一日曝、十日寒。这篇文章主要讲述HBase写入流程相关的知识,希望能为你提供帮助。
HBase采用LSM树架构,天生适用于写多读少的应用场景。在真实生产环境中,也正是因为HBase集群出色的写入能力,才能支持当下很多数据激增的业务。需要说明的是,HBase服务端并没有提供update、delete接口,HBase中对数据的更新、删除操作在服务器端也认为是写入操作,不同的是,更新操作会写入一个最新版本数据,删除操作会写入一条标记为deleted的KV数据。所以HBase中更新、删除操作的流程与写入流程完全一致。当然,HBase数据写入的整个流程随着版本的迭代在不断优化,但总休流程变化不大。 1 写入流程的三个阶段 HBase写入流程如下图:

HBase写入流程

文章图片
从整体架构的视角来看,写入流程可以概括为三个阶段。 1)客户端处理阶段:客户端将用户的写入请求进行预处理,并根据集群元数据定位写入数据所在的RegionServer,将请求发送给对应的RegionServer。 2)Region写入阶段:RegionServer接收到写入请求之后将数据解析出来,首先写入WAL,再写入对应Region列簇的MemStore。 3)MemStore Flush阶段:当Region中MemStore容量超过一定阈值,系统会异步执行flush操作,将内存中的数据写入文件,形成HFile。 注意:用户写入请求在完成Region MemStore的写入之后就会返回成功。MemStore Flush是一个异步执行的过程。 1.1 客户端处理阶段 HBase客户端处理写入请求的核心流程基本上可以概括为三步。 步骤1:用户提交put请求后,HBase客户端会将写入的数据添加到本地缓冲区中,符合一定条件就会通过AsyncProcess异步批量提交。HBase默认设置autoflush=true,表示put请求直接会提交给服务器进行处理;用户可以设置autoflush=false,这样,put请求会首先放到本地缓冲区,等到本地缓冲区大小超过一定阈值(默认为2M,可以通过配置文件配置)之后才会提交。很显然,后者使用批量提交请求,可以极大地提升写入吞吐量,但是因为没有保护机制,如果客户端崩溃,会导致部分已提交的数据丢失。 步骤2:在提交之前,HBase会在元数据表hbase:meta中根据rowkey找到它们归属的RegionServer,这个定位的过程是通过HConnection的locateRegion方法完成的。如果是批量请求,还会把这些rowkey按照HRegionLocation分级,不同分组的请求意味着发送到不同的RegionServer,因此每个分组对应一次RPC请求。 Client与ZooKeeper、RegionServer的交互过程如下图:
HBase写入流程

文章图片
    • 客户端根据写入的表以及rowkey在元数据缓存中查找,如果能够找出该rowkey所在的RegionServer以及Region,就可以直接发送写入请求(携带Region信息)到目标RegionServer。
    • 如果客户端缓存中没有查到对应的rowkey信息,需要首先到ZooKeeper上的/hbase/meta-region-server节点查找HBase元数据表所在的RegionServer。向hbase:meta所在的RegionServer发送查询请求,在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接收到返回结果之后会将结果缓存到本地,以备下次使用。
    • 客户端根据rowkey相关元数据信息将写入请求发送给目标RegionServer,RegionServer接收到请求之后会解析出具体的Region信息,查到对应的Region对象,并将数据写入目标Region的MemStore中。
步骤3:HBase为每个HRegionLocation构造一个远程RPC请求MultiServerCallable,并通过rpcCallerFactory.newCaller()执行调用。将请求经过Protobuf序列化后发送给对应的RegionServer。 1.2 Region写入阶段 服务器端RegionServer接收到客户端的写入请求后,首先会反序列化为put对象,然后执行各种检查操作,比如检查Region是否是只读、MemStore大小是否超过blockingMemstoreSize等。检查完成后,执行一系列核心操作,见下图:
HBase写入流程

文章图片
1)Acquire locks:HBase中使用行锁保证对一行数据的更新都是互斥操作,用以保证更新的原子性,要么更新成功,要么更新失败。 2)Update LATEST_TIMESTAMP timestamps:更新所有等写入(更新)KeyValue的时间戳为当前系统时间。 3)Build WAL edit:HBase使用WAL机制保证数据可靠性,即首先写日志再写缓存,即使发生宕机,也可以通过恢复HLog还原出原始数据。该步骤就是在内存中构建WALEdit对象,为了保证Region级别事务的写入原子性,一次写入操作中所有KeyValue会构建成一条WALEdit记录。 4)Append WALEdit TO WAL:将步骤3中构造在内存中的WALEdit记录顺序写入HLog中,此时不需要执行sync操作。当前版本的HBase使用了disruptor实现了高效的生产者消费者队列,实现WAL的追加写操作。 5)Write back to MemStore:写入WAL之后再将数据写入MemStore。 6)Release row locks:释放行锁。 7)Sync wal:HLog真正sync到HDFS,在释放行锁之后执行sync操作是为了尽量减少持锁时间,提升写性能。如果sync失败,执行回滚操作将MemStore中已经写入的数据移除。 8)结束写事务:此时该线程的更新操作才会对其他读请求可见,更新才实际生效。 1.3 MemStore Flush阶段 随着数据的不断写入,MemStore中存储的数据会越来越多,系统为了将使用的内存保持在一个合理水平,会将MemStore中的数据写入文件形成HFile。flush阶段是HBase的非常核心的阶段,理论上需要重点关注三个问题: MemStore Flush的触发机制。即在哪些情况下HBase会触发flush操作。 MemStore Flush的整体流程。 HFile的构建流程。HFile构建是MemStore Flush整体流程中最重要的一部分,这部分内容会涉及HFile文件格式的构建、布隆过滤器的构建、HFile索引的构建以及相关元数据的构建等。 2 Region写入流程 数据写入Region的流程可以抽象为两步:追加写HLog,随机写入MemStore。 2.1 追加写入HLog HBase保证成功写入MemStore中的数据不会因为进程异常退出或者机器宕机而丢失,但实际上并不完全如此,HBase定义了多个HLog持久化等级,使得用户在数据高可靠和写入性能之间进行权衡。 (1)HLog持久化等级 HBase可以通过设置HLog的持久化等级决定是否开启HLog机制以及HLog落盘方式。HLog的持久化等级分为如下下一个等级。
    • SKIP_WAL:只写缓存,不写HLog。因为只写内存,因此这种方式可以极大地提长写入性能,但数据有丢失的风险。在实际应用过程中并不建议设置些等级,除非确认不要求数据的可靠性。
    • ASYNC_WAL:异步将数据写入HLog日志中。
    • SYNC_WAL:同步将数据写入日志文件中,需要注意的是,数据只是被写入文件系统中,并没有真正落盘。
    • FSYNC_WAL:同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级,可以保证数据不会丢失,但性能相对比较差。
    • USER_DEFAULT:如果用户没有指定持久化等级,默认HBase使用SYNC_WAL等级持久化数据。
用户可以通过客户端设置HLog持久化等级,代码如下: put.SetDurability(Durability.SYNC_WAL); (2)HLog写入模型 在HBase的演进过程中,HLog的写入模型几经改进,写入吞吐量得到极大提升。之处的版本中,HLog写入都需要经过三个阶段:首先将数据写入本地缓存,然后将本地缓存写入文件系统,最后执行sync操作同步磁盘。 很显然,三个阶段是可以流水线工作的,基于这样的设想,写入模型自然就想到“生产者-消费者”队列实现。然而之前版本中,生产者之间、消费者之间以及生产者与消费者之间的线程同步都是由HBase系统实现,使用了大量的锁,在写入并发量非常大的情况下会频繁出现恶性抢占锁的问题,写入性能较差。 当前版本中,HBase使用LMAX Disruptor框架实现了无锁有界队列操作。基于Disruptor的写入模型如下图:
HBase写入流程

文章图片
图中最左侧部分是Region处理HLog写入的两个前后操作:append和sync。当调用append后,WALedit和HLogKey会被封装成FSWALEntry类,进而再封装成Ring BufferTruck类放入Disruptor无锁有界队列中。当调用sync后,会生成一个SyncFuture,再封装成RingBufferTruck类放入同一个队列中,然后工作线程会被阻塞,等待notify()来唤醒。 图中最右侧部分是消费者线程,在Disruptor框架中有且仅有一个消费者线程工作。这个框架会从Disruptor队列中依次取出RingBufferTruck对象,然后根据如下选项来操作:
    • 如果RingBufferTruck对象中封装的是FSWALEntry,就会执行文件append操作,将记录追加到HDFS文件中。需要注意的是,此时数据有可能并没有实际落盘,而只是写入到文件缓存。
    • 如果RingBufferTruck对象是SyncFuture,会调用线程池的线程异步地批量刷盘,刷般成功之后唤醒工作线程完成HLog的sync操作。
2.2 随机写入MemStore KeyValue写入Region分为两步:首先追加写入HLog,再写入MemStore。MemStore使用数据结构ConcurrentSkipListMap来实际存储KeyValue,优点是能够非常友好地支持大规模并发写入,同时跳跃表本身是有序存储的,这有利于数据有序落盘,并且有利于提升MemStore中的KeyValue查找性能。 KeyValue写入MemStore并不会每次都随机在堆上创建一个内存对象,然后再放到ConcurrentSkipListMap中,这样会带来非常严重的内存碎片,进而可能频繁触发Full GC。HBase使用MemStore-Local Allocation Buffer(MSLAB)机制预先申请一个大的(2M)的Chunk内存,写入的KeyValue会进行一次封装,顺序拷贝这个Chunk中,这样,MemStore中的数据从内存flush到硬盘的时候,JVM内存留下来的就不再是小的无法使用的内存碎片,而是大的可用的内存片段。 基于这样的设计思路,MemStore的写入流程可以表述为以下3步。 1)检查当前可用的Chunk是否写满,如果写满,重新申请一个2M的Chunk。 2)将当前KeyValue在内存中重新构建,在可用Chunk的指定offset处申请内存创建一个新的KeyValue对象 3)将新建的KeyValue对象写入ConCurrentSkipListMap中。 3 MemStore Flush 3.1 触发条件 HBase会在以下几种情况下触发flush操作。
    • MemStore级别限制:当Region中任意一个MemStore的大小达到了上限(hbase.hregion.memstore.flush.size,默认为128M),会触发MemStore刷新。
    • Region级别限制:当Region中所有MemStore的大小总和达到了上限(hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size),会触发MemStore刷新。
    • RegionServer级别限制:当RegionServer中MemStore的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit * hbase.regionserver.global.memstore.size,RegionServer开始强制执行flush,先flush MemStore最大的Region,再flush次大的,依次执行。如果此时写入吞吐量依然很高,导致总MemStore大小超过高水位阈值hbase.regionserver.global.memstore.size,RegionServer会阻塞更新并强制执行flush,直到总MemStore大小下降到低水位阈值。
    • 当一个RegionServer中的HLog数量达到上限(可通过参数hbase.regionserver.maxlogs配置)时,系统会选取最早的HLog对应的一个或多个Region进行flush。
    • HBase定期刷新MemStore:默认周期为1小时,确保MemStore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush而导致的问题,定期的flush操作有一定时间的随机延时。
    • 手动flush:用户可以通过shell命令flush \'tablename\'或者flush \'regionname\'分别对一个表或者一个Region进行flush。
3.2 执行流程 为了减少flush过程对读写的影响,HBase采用了类似于两阶段提交的方式,将整个flush过程分为三个阶段。 1)prepare阶段:遍历当前Region中的所有MemStore,将MemStore中当前数据集CellSkipListSet(内部实现采用ConcurrSkipListMap)做一个快照snapshot,然后再新建一个CellSkipListSet接收新的数据写入。prepare阶段需要添加updateLock对写请求阻塞,结束之后会释放该锁。因为此阶段没有任何费时操作,因此持锁时间很短。 2)flush阶段:遍历所有MemStore,将prepare阶段生成的snapshot持久化为临时文件,临时文件会统一放到目录.tmp下。这个过程因为涉及磁盘IO操作,因此相对比较耗时。 3)commit阶段:遍历所有的MemStore,将flush阶段生成的临时文件移到指定的ColumnFamily目录下,针对HFile生成对应的storefile和Reader,把storefile添加到Store的storefiles列表中,最后再清空prepare阶段生成的snapshot。 flush流程可以通过日志信息查看: flush阶段
HBase写入流程

文章图片
commit阶段
HBase写入流程

文章图片
3.3 生成HFile HBase执行flush操作之后将内存中的数据按照特定格式写成HFile文件。 (1)HFile结构 HFile依次由Scanned Block、Non-scanned Block、Load-on-open以及Trailer四部分组成。结构如下图:
HBase写入流程

文章图片
HFile依次由Scanned Block、Non-scanned Block、Load-on-open以及Trailer四个部分组成。 Scanned Block:这部分主要存储真实的KV数据,包括Data Block、Leaf Index Block和Bloom Block。 Non-scanned Block:这部分主要存储Meta Block,这种Block大多数据情况下可以不用关心。 Load-on-open:主要存储HFile元数据信息,包括索引根节点、布隆过滤器元数据等,在RegionServer打开HFile就会加载到内存,作为查询的入口。 Trailer:存储Load-on-open和Scanned Block在HFile文件中的偏移量、文件大小(未压缩)、压缩算法、存储KV个数以及HFile版本等信息。Trail部分的大小是固定的。 MemStore中KV在flush成HFile时首先构建Scanned Block部分,即KV写进来之后先构建Data Block并依次写入文件,在形成Data Block过程中会依次构建形成Leaf index Block、Bloom Block并依次写入文件。一量MemStore中所有KV都写入完成,Scanned Block部分就构建完成。 Non-scanned Block、Load-on-open以及Trailer这三部分是在所有KV数据完成写入后再追加写入的。 (2)构建“Scanned Block” 下图为MemStore中KV数据写入HFile的基本流程,可以分为以下4个步骤。
HBase写入流程

文章图片
1)MemStore执行flush,首先新建一个Scanner,这个Scanner从存储KV数据的CellSkipListSet中依次从小到大读出每个cell(KeyValue)。这里必须注意读取的顺序性,读取的顺序性保证了HFile文件中数据存储的顺序性,同时读取的顺序性是保证HFile索引构建以及布隆过滤器Meta Block构建的前提。 2)appendGeneralBloomFilter:在内存中使用布隆过滤器算法构建Bloom Block,也称为Bloom Chunk。 3)appendDeleteFamilyBloomFilter:针对标记为“DeleteFamily”或者“DeleteFamilyVersion”的cell,在内存中使用布隆过滤器算法构建Bloom Block,基本流程和appendGeneralBloomFilter相同。 4)(HFile。Writer)writer.append:将cell写入Data Block中,这是HFile文件构建的核心。 (3)构建Bloom Block 下图为Bloom Block构建示意图,实际实现中使用chunk表示Block概念,两者等价。
HBase写入流程

文章图片
布隆过滤器内存中维护了多个称为chunk的数据结构,一个chunk主要由两个元素组成:
    • 一块连续的内存区域,主要存储一个特定长度的数组。默认数组中所有位都为0,对于row类型的布隆过滤器,cell进来之后会对其rowkey执行hash映射,将其映射到位数组的某一位,该位的值修改为1.
    • firstkey,第一个写入该chunk的cell的rowkey,用来构建Bloom Index Block
cell写进来之后,首先判断当前chunk是否已经写满,写满的标准是这个chunk容纳的cell个数是否超过阈值。如果超过阈值,就会重新申请一个chunk,并将当前chunk放入ready chunks集合中。如果没有写满,则根据布隆过滤器算法使用多个hash函数分别对cell的rowkey进行映射,并将相应的位数组位置为1. (4)构建Data Block 一个cell在内存中生成对应的布隆过滤器信息之后就会写入Data Block,写入过程分为两步。 1)Encoding KeyValue:使用特定的编码对cell进行编码处理,HBase中主要的编码器有DiffKeyDeltaEncoder、FastDiffDeltaEncoder以及PrefixDeltaEncoder等。编码的基本思路是,根据上一个KeyValue和当前KeyValue比较之后取delta,展开讲就是rowkey、column family以及column分别进行比较然后取delta。假如前两个KeyValue的rowkey相同,当前keyrow就可以使用特定的一个flag标记,不需要再完整地存储整个rowkey。这样,在某些场景下可以极大地减少存储空间。 2)将编码后的KeyValue写入DataOutputStream。 随着cell的不断写入,当前Data Block会因为大小超过阈值(默认64KB)而写满。写满后Data Block会将DataOutputStream的数据flush到文件,该Data Block此时完成落盘。 (5)构建Leaf Index Block Data Block完成落盘之后会立刻在内存中构建一个Leaf Index Entry对象,并将该对象加入到当前Leaf Index Block。Leaf Index Entry对象有三个重要的字段。 firstKey:落盘Data Block的第一个key。用来作为索引节点的实际内容,在索引树执行索引查找的时候使用。 blockOffset:落盘Data Block在HFile中的偏移量。用于索引目标确定后快速定位目标Data Block。 blockDataSize:落盘Data Block的大小。用于定位到Data Block之后的数据加载。 Leaf Index Entry的构建如下图所示
HBase写入流程

文章图片
同样,Leaf Index Block会随着Leaf Index Entry的不断写入慢慢变大,一量大小超过阈值(默认64K),就需要flush到文件执行落盘。需要注意的时,Leaf Index Block落盘是追加写入文件的,所以就会形成HFile中Data Block、Leaf Index Block交叉出现的情况。 和Data Block落盘流程一样,Leaf Index Block落盘之后还需要再往上构建Root Index Entry并写入Root Index Block,形成索引树的根节点。但根节点并没有追加写入“Scanned block”部分,而是在最后写入“Load-on-open”部分。 可以看出,HFile文件中的索引树的构建是由低向上发展的,先生成Data Block,再生成Leaf Index Block,最后生成Root Index Block。而检索rowkey时刚好相反,先在Root Index Block中查询定位到某个Leaf Index Block,再在Leaf Index Block中二分查找定位到某个Data Block,最后将Data Block加载到内存进行遍历查找 。 (6)构建Bloom Block Index 完成Data Block落盘还有一件非常重要的事情:检查是有否已经写满的Bloom Block。如果有,将Bloom Block追加写入文件,在内存中构建一个Bloom Index Entry并写入Bloom Index Block。 整个流程与Data Block落盘后构建Leaf Index Entry并写入Leaf Index Block的流程完全一样。 《HBase原理与实践》学习笔记【HBase写入流程】

    推荐阅读