写入流程
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。
客户端处理阶段:
- 数据首先会被写入到本地缓存，达到阈值之后，才会被提交。后者使用批量提交请求，可以极大地提升写入吞吐量，但是因为没有保护机制，如果客户端崩溃，会导致部分已经提交的数据丢失。
- 批量请求会根据rowke按照HRegionLocation分组，不同分组的请求意味着发送到不同的RegionServer，因此每个分组对应一次RPC请求。
(1) 在本地metacache 中查找，是否有对应rowkey所在的regionserver和region。
(2) 没有，则请求zk，查找元数据 hbase:meta 对应的regionserver的信息。
(3) 在hbase:meta中找到rowkey对应的regionserver和region信息,并缓存到客户端本地。
(4)将请求发送到对应的regionserver。regionserver解析数据后发送到对应region，存储到memstore中。
- HBase会为每个HRegionLocation构造一个远程RPC请求MultiServerCallable，并通过rpcCallerFactory. newCaller()执行调用。将请求经过Protobuf序列化后发送给对应的RegionServer。
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）结束写事务：此时该线程的更新操作才会对其他读请求可见，更新才实际生效。
Region 写入流程
- HLog 写入
数据写入Region的流程可以抽象为两步：追加写入HLog，随机写入MemStore。 - （1）HLog持久化等级
• SKIP_WAL：只写缓存，不写HLog日志。因为只写内存，因此这种方式可以极大地提升写入性能，但是数据有丢失的风险。在实际应用过程中并不建议设置此等级，除非确认不要求数据的可靠性。
• ASYNC_WAL：异步将数据写入HLog日志中。
• SYNC_WAL：同步将数据写入日志文件中，需要注意的是，数据只是被写入文件系统中，并没有真正落盘。HDFS Flush策略详见HADOOP-6313。
• FSYNC_WAL：同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级，可以保证数据不会丢失，但是性能相对比较差。
• USER_DEFAULT：如果用户没有指定持久化等级，默认HBase使用SYNC_WAL等级持久化数据。
-
（2）HLog写入模型
HLog写入都需要经过三个阶段：首先将数据写入本地缓存，然后将本地缓存写入文件系统，最后执行sync操作同步到磁盘。
image.png
•如果RingBufferTruck对象中封装的是FSWALEntry，就会执行文件append操作，将记录追加写入HDFS文件中。需要注意的是，此时数据有可能并没有实际落盘，而只是写入到文件缓存。
•如果RingBufferTruck对象是SyncFuture，会调用线程池的线程异步地批量刷盘，刷盘成功之后唤醒工作线程完成HLog的sync操作。
- 随机写入MemStore
MemStore使用数据结构ConcurrentSkipListMap来实际存储KeyValue，优点是能够非常友好地支持大规模并发写入，同时跳跃表本身是有序存储的，这有利于数据有序落盘，并且有利于提升MemStore中的KeyValue查找性能。
- 随机写入MemStore
HBase使用MemStore-Local Allocation Buffer（MSLAB）机制预先申请一个大的（2M）的Chunk内存，写入的KeyValue会进行一次封装，顺序拷贝这个Chunk中，这样，MemStore中的数据从内存f lush到硬盘的时候，JVM内存留下来的就不再是小的无法使用的内存碎片，而是大的可用的内存片段。
6.1.3 MemStore Flush
1.触发条件
*（1）MemStore级别限制
当Region中任意一个MemStore的大小达到了上限（hbase.hregion.memstore.f lush.size，默认128MB），会触发MemStore刷新。
（2）.Region级别限制
当Region中所有MemStore的大小总和达到了上限（hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.f lush.size），会触发MemStore刷新。（3）.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大小下降到低水位阈值。（4）.当一个RegionServer中HLog数量达到上限
（可通过参数hbase.regionserver.maxlogs配置），系统会选取最早的HLog对应的一个或多个Region进行f lush。（5）.HBase定期刷新MemStore
默认周期为1小时，确保MemStore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush而导致的问题，定期的f lush操作有一定时间的随机延时。（6）.手动执行f lush
用户可以通过shell命令f lush 'tablename'或者f lush 'regionname'分别对一个表或者一个Region进行flush。
2.执行流程
为了减少f lush过程对读写的影响，HBase采用了类似于两阶段提交的方式。
- prepare阶段
（1）添加updateLock对写请求阻塞
（2） 遍历当前Region中的所有MemStore，将MemStore中当前数据集CellSkipListSet（内部实现采用ConcurrentSkipListMap）做一个快照snapshot，然后再新建一个CellSkipListSet接收新的数据写入。
（3）结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。 - f lush阶段
遍历所有MemStore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及磁盘IO操作，因此相对比较耗时。 - commit阶段
遍历所有的MemStore，将f lush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storef ile和Reader，把storef ile添加到Store的storef iles列表中，最后再清空prepare阶段生成的snapshot。
3. 生成HFile
（1）HFile结构
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版本等基本信息。
Trailer部分的大小是固定的。
（2）构建"Scanned Block"部分
1）MemStore执行f lush，首先新建一个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文件构建的核心。
