HBase 写入流程

1. HBase 写入流程

从整理架构的视角来看，HBase写入流程整体分为3个阶段：

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

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

1.1. 客户端处理流程

客户端处理写入请求的核心流程基本可以概括为三步：

1.1.1. 步骤1

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

1.1.2. 步骤2

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

Client与Zookeeper、RegionServer的交互过程如下图所示：

1. 客户端根据写入的表以及rowkey在元数据缓存中查找，如果能够查找出该rowkey所在的RegionServer以及Region，就可以直接发送写入请求（携带Region信息）到目标RegionServer。
2. 如果客户端缓存中没有查到对应的rowkey信息，需要首先到ZooKeeper上/hbase/meta-region-server节点查找HBase元数据表所在的RegionServer。
   向hbase:meta所在的RegionServer发送查询请求，在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接收到返回结果之后会将结果缓存到本地，以备下次使用。
3. 客户端根据rowkey相关元数据信息将写入请求发送给目标RegionServer，RegionServer接收到请求之后会解析出具体的Region信息，查到对应的Region对象，并将数据写入目标Region的MemStore中。

1.1.3. 步骤3

HBase会为每个HRegionLocation构造一个远程RPC请求MultiServerCallable。将请求经过Protobuf序列化后发送给对应的RegionServer。

1.2. Region 写入阶段

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

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

1.2.1. 追加写入 HLog

之前的版本中，HLog写入都需要经过三个阶段：首先将数据写入本地缓存，然后将本地缓存写入文件系统，最后执行sync操作同步到磁盘。

当前版本中，HBase使用LMAX Disruptor框架实现了无锁有界队列操作。
(1) 图中最左侧部分是Region处理HLog写入的两个前后操作：append和sync。
当调用append后，WALEdit和HLogKey会被封装成FSWALEntry类，进而再封装成RingBufferTruck类放入Disruptor无锁有界队列中。
当调用sync后，会生成一个SyncFuture，再封装成RingBufferTruck类放入同一个Disruptor无锁有界队列中，然后工作线程会被阻塞，等待notify()来唤醒。
(2) 图中最右侧部分是消费者线程，在LMAX Disruptor框架中有且仅有一个消费者线程工作。这个框架会从Disruptor无锁有界队列中依次取出RingBufferTruck对象，然后根据如下选项来操作：

• 如果RingBufferTruck对象中封装的是FSWALEntry，就会执行文件append操作，将记录追加写入HDFS文件中。需要注意的是，此时数据有可能并没有实际落盘，而只是写入到文件缓存。
• 如果RingBufferTruck对象是SyncFuture，会调用线程池的线程异步地批量刷盘，刷盘成功之后唤醒工作线程完成HLog的sync操作。

1.2.2. 随机写入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中。

1.3. MemStore Flush阶段

详见 MemStore

---

《HBase原理与实践》读书笔记