HBase_HBase写入流程详解

转载自 ：  HBase写入流程详解_hbase数据写入流程_晓之以理的喵~~的博客-CSDN博客   

        HBase采用LSM树架构，天生适用于写多读少的应用场景。在真实生产线环境中，也正是因为HBase集群出色的写入能力，才能支持当下很多数据激增的业务。需要说明的是，HBase服务端并没有提供update、delete接口，HBase中对数据的更新、删除操作在服务器端也认为是写入操作，不同的是，更新操作会写入一个最新版本数据，删除操作会写入一条标记为deleted的KV数据。所以HBase中更新、删除操作的流程与写入流程完全一致。

一、写入流程的三个阶段

从整体架构的视角来看，写入流程可以概括为三个阶段。

（1）客户端处理阶段：客户端将用户的写入请求进行预处理，并根据集群元数据定位写入数据所在的RegionServer，将请求发送给对应的RegionServer。
（2）Region写入阶段：RegionServer接收到写入请求之后将数据解析出来，首先写入WAL，再写入对应Region列簇的MemStore。
（3）MemStore Flush阶段：当Region中MemStore容量超过一定阈值，系统会异步执行flush操作，将内存中的数据写入文件，形成HFile。

注意：用户写入请求在完成Region MemStore的写入之后就会返回成功。MemStore Flush是一个异步执行的过程。
 

1. 客户端处理阶段

HBase客户端处理写入请求的核心流程基本上可以概括为三步。
（1）步骤1：

        用户提交put请求后，HBase客户端会将写入的数据添加到本地缓冲区中，符合一定条件就会通过AsyncProcess异步批量提交。HBase默认设置autoflush=true，表示put请求直接会提交给服务器进行处理；用户可以设置autoflush=false，这样，put请求会首先放到本地缓冲区，等到本地缓冲区大小超过一定阈值（默认为2M，可以通过配置文件配置）之后才会提交。很显然，后者使用批量提交请求，可以极大地提升写入吞吐量，但是因为没有保护机制，如果客户端崩溃，会导致部分已经提交的数据丢失。

（2）步骤2：

        在提交之前，HBase会在元数据表hbase：meta中根据rowkey找到它们归属的RegionServer，这个定位的过程是通过HConnection的locateRegion方法完成的。如果是批量请求，还会把这些rowkey按照HRegionLocation分组，不同分组的请求意味着发送到不同的RegionServer，因此每个分组对应一次RPC请求。

（3）步骤3：
        HBase会为每个HRegionLocation构造一个远程RPC请求MultiServerCallable，并通过rpcCallerFactory.newCaller（）执行调用。将请求经过Protobuf序列化后发送给对应的RegionServer。
 

2. Region写入阶段

        服务器端RegionServer接收到客户端的写入请求后，首先会反序列化为put对象，然后执行各种检查操作，比如检查Region是否是只读、MemStore大小是否超过blockingMemstoreSize等。检查完成之后，执行一系列核心操作，如上图所示。

（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）结束写事务：此时该线程的更新操作才会对其他读请求可见，更新才实际生效。

注意：branch-1的写入流程设计为：先在第6步释放行锁，再在第7步Sync WAL，最后在第8步打开mvcc让其他事务可以看到最新结果。正是这样的设计，导致了第4章4.2节中提到的“CAS接口是Region级别串行的，吞吐受限”问题。这个问题已经在branch-2中解决。
 

3. MemStore Flush阶段

        随着数据的不断写入，MemStore中存储的数据会越来越多，系统为了将使用的内存保持在一个合理的水平，会将MemStore中的数据写入文件形成HFile。flush阶段是HBase的非常核心的阶段，理论上需要重点关注三个问题：

（1）MemStore Flush的触发时机。即在哪些情况下HBase会触发flush操作。

（2）MemStore Flush的整体流程。

（3）HFile的构建流程。HFile构建是MemStore Flush整体流程中最重要的一个部分，这部分内容会涉及HFile文件格式的构建、布隆过滤器的构建、HFile索引的构建以及相关元数据的构建等。

二、Region写入流程

数据写入Region的流程可以抽象为两步：追加写入HLog，随机写入MemStore。

1.  追加写入HLog

HBase中HLog的文件格式、生命周期已经在第5章做了介绍。HLog保证成功写入MemStore中的数据不会因为进程异常退出或者机器宕机而丢失，但实际上并不完全如此，HBase定义了多个HLog持久化等级，使得用户在数据高可靠和写入性能之间进行权衡。

（1）HLog持久化等级

HBase可以通过设置HLog的持久化等级决定是否开启HLog机制以及HLog的落盘方式。

HLog的持久化等级的五个等级：

（1）SKIP_WAL：只写缓存，不写HLog日志。因为只写内存，因此这种方式可以极大地提升写入性能，但是数据有丢失的风险。在实际应用过程中并不建议设置此等级，除非确认不要求数据的可靠性。

（2）ASYNC_WAL：异步将数据写入HLog日志中。

（3）SYNC_WAL：同步将数据写入日志文件中，需要注意的是，数据只是被写入文件系统中，并没有真正落盘。HDFS Flush策略详见HADOOP-6313。

（4）FSYNC_WAL：同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级，可以保证数据不会丢失，但是性能相对比较差。

（5）USER_DEFAULT：如果用户没有指定持久化等级，默认HBase使用SYNC_WAL等级持久化数据

（2）HLog写入模型

        在HBase的演进过程中，HLog的写入模型几经改进，写入吞吐量得到极大提升。之前的版本中，HLog写入都需要经过三个阶段：首先将数据写入本地缓存，然后将本地缓存写入文件系统，最后执行sync操作同步到磁盘。

        三个阶段是可以流水线工作的，基于这样的设想，写入模型自然就想到“生产者-消费者”队列实现。然而之前版本中，生产者之间、消费者之间以及生产者与消费者之间的线程同步都是由HBase系统实现，使用了大量的锁，在写入并发量非常大的情况下会频繁出现恶性抢占锁的问题，写入性能较差。

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中。
 

三、MemStore Flush

1. 触发条件

HBase触发flush操作的情况：
（1）MemStore级别限制：当Region中任意一个MemStore的大小达到了上限（hbase.hregion.memstore.flush.size，默认128MB），会触发MemStore刷新。

（2）Region级别限制：当Region中所有MemStore的大小总和达到了上限（hbase.hregion.memstore.block.multiplierhbase.hregion.memstore.flush.size），会触发MemStore刷新。

（3）RegionServer级别限制：当RegionServer中MemStore的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limithbase.regionserver.global.memstore.size，RegionServer开始强制执行flush，先flush MemStore最大的Region，再flush次大的，依次执行。如果此时写入吞吐量依然很高，导致总MemStore大小超过高水位阈值hbase.regionserver.global.memstore.size，RegionServer会阻塞更新并强制执行flush，直至总MemStore大小下降到低水位阈值。

（4）当一个RegionServer中HLog数量达到上限（可通过参数hbase.regionserver.maxlogs配置）时，系统会选取最早的HLog对应的一个或多个Region进行flush。

（5）HBase定期刷新MemStore：默认周期为1小时，确保MemStore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush而导致的问题，定期的flush操作有一定时间的随机延时。

（6）手动执行flush：用户可以通过shell命令flush’tablename’或者flush’regionname’分别对一个表或者一个Region进行flush。

2. 执行流程

为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段。

（1）prepare阶段：遍历当前Region中的所有MemStore，将MemStore中当前数据集CellSkipListSet（内部实现采用ConcurrentSkipListMap）做一个快照snapshot，然后再新建一个CellSkipListSet接收新的数据写入。prepare阶段需要添加updateLock对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。

（2）flush阶段：遍历所有MemStore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及磁盘IO操作，因此相对比较耗时。

（3）commit阶段：遍历所有的MemStore，将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，把storefile添加到Store的storefiles列表中，最后再清空prepare阶段生成的snapshot。

3. 生成HFile

HBase执行flush操作之后将内存中的数据按照特定格式写成HFile文件。

（1）HFile结构

HFile依次由Scanned Block、Non-scanned Block、Load-on-open以及Trailer四个部分组成。

1）Scanned Block：这部分主要存储真实的KV数据，包括Data Block、Leaf Index Block和Bloom Block。

2）Non-scanned Block：这部分主要存储Meta Block，这种Block大多数情况下可以不用关心

3）Load-on-open：主要存储HFile元数据信息，包括索引根节点、布隆过滤器元数据等，在RegionServer打开HFile就会加载到内存，作为查询的入口。

4）Trailer：存储Load-on-open和Scanned Block在HFile文件中的偏移量、文件大小（未压缩）、压缩算法、存储KV个数以及HFile版本等基本信息。Trailer部分的大小是固定的。

注意：
1）MemStore中KV在flush成HFile时首先构建Scanned Block部分，即KV写进来之后先构建Data Block并依次写入文件，在形成Data Block的过程中也会依次构建形成Leaf index Block、BloomBlock并依次写入文件。一旦MemStore中所有KV都写入完成，Scanned Block部分就构建完成。

2）Non-scanned Block、Load-on-open以及Trailer这三部分是在所有KV数据完成写入后再追加写入的。
 

（2）构建"Scanned Block"部分

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

实际实现中使用chunk表示Block概念，布隆过滤器内存中维护了多个称为chunk的数据结构，一个chunk主要由两个元素组成：
1）一块连续的内存区域，主要存储一个特定长度的数组。默认数组中所有位都为0，对于row类型的布隆过滤器，cell进来之后会对其rowkey执行hash映射，将其映射到位数组的某一位，该位的值修改为1。
2）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以及PrefixKeyDeltaEncoder等。编码的基本思路是，根据上一个KeyValue和当前KeyValue比较之后取delta，展开讲就是rowkey、column family以及column分别进行比较然后取delta。假如前后两个KeyValue的rowkey相同，当前rowkey就可以使用特定的一个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对象有三个重要的字段。

（1）firstKey：落盘Data Block的第一个key。用来作为索引节点的实际内容，在索引树执行索引查找的时候使用。

（2）blockOffset：落盘Data Block在HFile文件中的偏移量。用于索引目标确定后快速定位目标Data Block。

（3）blockDataSize：落盘Data Block的大小。用于定位到Data Block之后的数据加载。
 

（6）构建Bloom Block Index

        完成Data Block落盘还有一件非常重要的事情：检查是否有已经写满的Bloom Block。如果有，将该Bloom Block追加写入文件，在内存中构建一个Bloom Index Entry并写入Bloom IndexBlock。
整个流程与Data Block落盘后构建Leaf Index Entry并写入Leaf Index Block的流程完全一样。

基本流程总结：

        flush阶段生成HFile和Compaction阶段生成HFile的流程完全相同，不同的是，flush读取的是MemStore中的KeyValue写成HFile，而Compaction读取的是多个HFile中的KeyValue写成一个大的HFile，KeyValue来源不同。KeyValue数据生成HFile，首先会构建Bloom Block以及Data Block，一旦写满一个Data Block就会将其落盘同时构造一个Leaf Index Entry，写入Leaf Index Block，直至Leaf Index Block写满落盘。实际上，每写入一个KeyValue就会动态地去构建"Scanned Block"部分，等所有的KeyValue都写入完成之后再静态地构建"Non-scannedBlock"部分、"Load on open"部分以及"Trailer"部分。
 

4. MemStore Flush对业务的影响

        在实践过程中，flush操作的不同触发方式对用户请求影响的程度不尽相同。正常情况下，大部分MemStore Flush操作都不会对业务读写产生太大影响。比如系统定期刷新MemStore、手动执行flush操作、触发MemStore级别限制、触发HLog数量限制以及触发Region级别限制等，这几种场景只会阻塞对应Region上的写请求，且阻塞时间较短。
然而，一旦触发RegionServer级别限制导致flush，就会对用户请求产生较大的影响。在这种情况下，系统会阻塞所有落在该RegionServer上的写入操作，直至MemStore中数据量降低到配置阈值内。

文章来源：《HBase原理与实践》 作者：胡争；范欣欣