HBase采纳LSM树架构，天生实用于写多读少的利用场景。在实在生产线环境中，也正是因为HBase集群杰出的写入能力，能力反对当下很多数据激增的业务。须要阐明的是，HBase服务端并没有提供update、delete接口，HBase中对数据的更新、删除操作在服务器端也认为是写入操作，不同的是，更新操作会写入一个最新版本数据，删除操作会写入一条标记为deleted的KV数据。所以HBase中更新、删除操作的流程与写入流程完全一致。当然，HBase数据写入的整个流程随着版本的迭代在一直优化，但总体流程变动不大。
写入流程的三个阶段
从整体架构的视角来看，写入流程能够概括为三个阶段。
1）客户端解决阶段：客户端将用户的写入申请进行预处理，并依据集群元数据定位写入数据所在的RegionServer，将申请发送给对应的RegionServer。
2）Region写入阶段：RegionServer接管到写入申请之后将数据解析进去，首先写入WAL，再写入对应Region列簇的MemStore。
3）MemStore Flush阶段：当Region中MemStore容量超过肯定阈值，零碎会异步执行f lush操作，将内存中的数据写入文件，造成HFile。
用户写入申请在实现Region MemStore的写入之后就会返回胜利。MemStoreFlush是一个异步执行的过程。
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的交互过程如图所示。
•客户端依据写入的表以及rowkey在元数据缓存中查找，如果可能查找出该rowkey所在的RegionServer以及Region，就能够间接发送写入申请（携带Region信息）到指标RegionServer。
•如果客户端缓存中没有查到对应的rowkey信息，须要首先到ZooKeeper上/hbase-root/meta-region-server节点查找HBase元数据表所在的RegionServer。向hbase:meta所在的RegionServer发送查问申请，在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接管到返回后果之后会将后果缓存到本地，以备下次应用。
•客户端依据rowkey相干元数据信息将写入申请发送给指标RegionServer，Region Server接管到申请之后会解析出具体的Region信息，查到对应的Region对象，并将数据写入指标Region的MemStore中。
步骤3：HBase会为每个HRegionLocation结构一个近程RPC申请MultiServerCallable，并通过rpcCallerFactory. newCaller()执行调用。将申请通过Protobuf序列化后发送给对应的RegionServer。
2. Region写入阶段
服务器端RegionServer接管到客户端的写入申请后，首先会反序列化为put对象，而后执行各种查看操作，比方查看Region是否是只读、MemStore大小是否超过blockingMemstoreSize等。查看实现之后，执行一系列外围操作
Region写入流程
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）完结写事务：此时该线程的更新操作才会对其余读申请可见，更新才理论失效。
3. MemStore Flush阶段
随着数据的一直写入，MemStore中存储的数据会越来越多，零碎为了将应用的内存放弃在一个正当的程度，会将MemStore中的数据写入文件造成HFile。f lush阶段是HBase的十分外围的阶段，实践上须要重点关注三个问题：
•MemStore Flush的触发机会。即在哪些状况下HBase会触发f lush操作。
•MemStore Flush的整体流程。
•HFile的构建流程。HFile构建是MemStore Flush整体流程中最重要的一个局部，这部分内容会波及HFile文件格式的构建、布隆过滤器的构建、HFile索引的构建以及相干元数据的构建等。
Region写入流程
数据写入Region的流程能够形象为两步：追加写入HLog，随机写入MemStore。
1. 追加写入HLog
HLog保障胜利写入MemStore中的数据不会因为过程异样退出或者机器宕机而失落，但实际上并不齐全如此，HBase定义了多个HLog长久化等级，使得用户在数据高牢靠和写入性能之间进行衡量。
（1）HLog长久化等级
HBase能够通过设置HLog的长久化等级决定是否开启HLog机制以及HLog的落盘形式。HLog的长久化等级分为如下五个等级。
• SKIP_WAL：只写缓存，不写HLog日志。因为只写内存，因而这种形式能够极大地晋升写入性能，然而数据有失落的危险。在理论利用过程中并不倡议设置此等级，除非确认不要求数据的可靠性。
• SYNC_WAL：同步将数据写入日志文件中，须要留神的是，数据只是被写入文件系统中，并没有真正落盘。HDFS Flush策略详见HADOOP-6313。
• FSYNC_WAL：同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级，能够保证数据不会失落，然而性能绝对比拟差。
• USER_DEFAULT：如果用户没有指定长久化等级，默认HBase应用SYNC_WAL等级长久化数据。
用户能够通过客户端设置HLog长久化等级，代码如下：
put.setDurability(Durability.SYNC_WAL);
（2）HLog写入模型
在HBase的演进过程中，HLog的写入模型几经改良，写入吞吐量失去极大晋升。之前的版本中，HLog写入都须要通过三个阶段：首先将数据写入本地缓存，而后将本地缓存写入文件系统，最初执行sync操作同步到磁盘。
很显然，三个阶段是能够流水线工作的，基于这样的构想，写入模型天然就想到“生产者-消费者”队列实现。然而之前版本中，生产者之间、消费者之间以及生产者与消费者之间的线程同步都是由HBase零碎实现，应用了大量的锁，在写入并发量十分大的状况下会频繁呈现恶性抢占锁的问题，写入性能较差。
以后版本中，HBase应用LMAX Disruptor框架实现了无锁有界队列操作。基于Disruptor的HLog写入模型如图所示。
Hlog写入模型
图中最左侧局部是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. 随机写入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中的数据从内存f lush到硬盘的时候，JVM内存留下来的就不再是小的无奈应用的内存碎片，而是大的可用的内存片段。
基于这样的设计思路，MemStore的写入流程能够表述为以下3步。
1）查看以后可用的Chunk是否写满，如果写满，从新申请一个2M的Chunk。
2）将以后KeyValue在内存中从新构建，在可用Chunk的指定offset处申请内存创立一个新的KeyValue对象。
3）将新创建的KeyValue对象写入ConcurrentSkipListMap中。
MemStore Flush
1. 触发条件
HBase会在以下几种状况下触发flush操作。
•MemStore级别限度：当Region中任意一个MemStore的大小达到了下限（hbase.hregion.memstore.flush.size，默认128MB），会触发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进行f lush。
•HBase定期刷新MemStore ：默认周期为1小时，确保MemStore不会长时间没有长久化。为防止所有的MemStore在同一时间都进行flush而导致的问题，定期的f lush操作有肯定工夫的随机延时。
•手动执行flush ：用户能够通过shell命令f lush 'tablename'或者f lush'regionname'别离对一个表或者一个Region进行f lush。
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的storef iles列表中，最初再清空prepare阶段生成的snapshot。
3. 生成HFile
HBase执行f lush操作之后将内存中的数据依照特定格局写成HFile文件，本大节将会顺次介绍HFile文件中各个Block的构建流程。
（1）HFile构造
本书第5章对HBase中数据文件HFile的格局进行了具体阐明，HFile构造参见下图。HFile顺次由Scanned Block、Non-scanned Block、Load-on-open以及Trailer四个局部组成。
• Scanned Block：这部分次要存储实在的KV数据，包含Data Block、LeafIndex Block和Bloom Block。
• Non-scanned Block：这部分次要存储Meta Block，这种Block大多数状况下能够不必关怀。
• Load-on-open：次要存储HFile元数据信息，包含索引根节点、布隆过滤器元数据等，在RegionServer关上HFile就会加载到内存，作为查问的入口。
• Trailer：存储Load-on-open和Scanned Block在HFile文件中的偏移量、文件大小（未压缩）、压缩算法、存储KV个数以及HFile版本等根本信息。Trailer局部的大小是固定的。
MemStore中KV在f lush成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个步骤。
KV数据写入HFile流程图
1）MemStore执行flush，首先新建一个Scanner，这个Scanner从存储KV数据的CellSkipListSet中顺次从小到大读出每个cell（KeyValue）。这里必须留神读取的程序性，读取的程序性保障了HFile文件中数据存储的程序性，同时读取的程序性是保障HFile索引构建以及布隆过滤器Meta Block构建的前提。
2）appendGeneralBloomFilter ：在内存中应用布隆过滤器算法构建BloomBlock，下文也称为Bloom Chunk。
3）appendDeleteFamilyBloomFilter ：针对标记为"DeleteFamily"或者"DeleteFamilyVersion"的cell，在内存中应用布隆过滤器算法构建BloomBlock，根本流程和appendGeneralBloomFilter雷同。
4）(HFile.Writer)writer.append ：将cell写入Data Block中，这是HFile文件构建的外围。
（3）构建Bloom Block
图为Bloom Block构建示意图，理论实现中应用chunk示意Block概念，两者等价。
构建Bloom Block
布隆过滤器内存中保护了多个称为chunk的数据结构，一个chunk次要由两个元素组成：
•一块间断的内存区域，次要存储一个特定长度的数组。默认数组中所有位都为0，对于row类型的布隆过滤器，cell进来之后会对其rowkey执行hash映射，将其映射到位数组的某一位，该位的值批改为1。
•firstkey，第一个写入该chunk的cell的rowkey，用来构建Bloom IndexBlock。
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就能够应用特定的一个f lag标记，不须要再残缺地存储整个rowkey。这样，在某些场景下能够极大地缩小存储空间。
2）将编码后的KeyValue写入DataOutputStream。
随着cell的一直写入，以后Data Block会因为大小超过阈值（默认64KB）而写满。写满后Data Block会将DataOutputStream的数据f lush到文件，该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的构建如图所示。
同样，Leaf Index Block会随着Leaf Index Entry的一直写入缓缓变大，一旦大小超过阈值（默认64KB），就须要f lush到文件执行落盘。须要留神的是，LeafIndex Block落盘是追加写入文件的，所以就会造成HFile中Data Block、LeafIndex Block穿插呈现的状况。
和Data Block落盘流程一样，Leaf Index Block落盘之后还须要再往上构建RootIndex 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 IndexBlock中二分查找定位到某个Data Block，最初将Data Block加载到内存进行遍历查找。
（6）构建Bloom Block Index
实现Data Block落盘还有一件十分重要的事件：查看是否有曾经写满的BloomBlock。如果有，将该Bloom Block追加写入文件，在内存中构建一个BloomIndex Entry并写入Bloom Index Block。
整个流程与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，写入LeafIndex Block，直至Leaf Index Block写满落盘。实际上，每写入一个KeyValue就会动静地去构建"Scanned Block"局部，等所有的KeyValue都写入实现之后再动态地构建"Non-scanned Block"局部、"Load on open"局部以及"Trailer"局部。
- MemStore Flush对业务的影响
在实际过程中，flush操作的不同触发形式对用户申请影响的水平不尽相同。失常状况下，大部分MemStore Flush操作都不会对业务读写产生太大影响。比方零碎定期刷新MemStore、手动执行flush操作、触发MemStore级别限度、触发HLog数量限度以及触发Region级别限度等，这几种场景只会阻塞对应Region上的写申请，且阻塞工夫较短。
然而，一旦触发RegionServer级别限度导致f lush，就会对用户申请产生较大的影响。在这种状况下，零碎会阻塞所有落在该RegionServer上的写入操作，直至MemStore中数据量升高到配置阈值内。
文章基于《HBase原理与实际》一书