文章目录
1. HBase 写入流程
从整理架构的视角来看,HBase写入流程整体分为3个阶段:
- 客户端处理阶段:客户端将用户的写入请求进行预处理,并根据集群元数据定位写入数据所在的RegionServer,将请求发送给对应的RegionServer。
- Region写入阶段:RegionServer接收到写入请求之后将数据解析出来,首先写入WAL,再写入对应Region列簇的MemStore。
- 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的交互过程如下图所示:
- 客户端根据写入的表以及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中。
1.1.3. 步骤3
HBase会为每个HRegionLocation
构造一个远程RPC请求MultiServerCallable
。将请求经过Protobuf序列化后发送给对应的RegionServer。
1.2. Region 写入阶段
数据写入Region的流程可以抽象为两步:追加写入HLog,随机写入MemStore。
服务器端RegionServer接收到客户端的写入请求后,首先会反序列化为put对象,然后执行各种检查操作,比如检查Region是否是只读、MemStore大小是否超过blockingMemstoreSize等。检查完成之后,执行一系列核心操作:
- Acquire locks :获取行锁,HBase中使用行锁保证对同一行数据的更新都是互斥操作,用以保证更新的原子性,要么更新成功,要么更新失败。
- Update LATEST_TIMESTAMP timestamps :更新所有待写入/更新
KeyValue
的时间戳为当前系统时间。 - Build WAL edit :HBase使用WAL机制保证数据可靠性,即首先写日志再写缓存,即使发生宕机,也可以通过恢复HLog还原出原始数据。
该步骤就是在内存中构建WALEdit
对象,为了保证Region级别事务的写入原子性,一次写入操作中所有KeyValue
会构建成一条WALEdit
记录。 - Append WALEdit To WAL :将步骤3中构造在内存中的
WALEdit
记录顺序写入HLog中,此时不需要执行sync操作。当前版本的HBase使用了disruptor实现了高效的生产者消费者队列,来实现WAL的追加写入操作。 - Write back to MemStore:写入WAL之后再将数据写入MemStore。
- Release row locks:释放行锁。
- Sync wal :HLog真正sync到HDFS,在释放行锁之后执行sync操作是为了尽量减少持锁时间,提升写性能。如果sync失败,执行回滚操作将MemStore中已经写入的数据移除。
- 结束写事务(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步。
- 检查当前可用的Chunk是否写满,如果写满,重新申请一个2M的Chunk。
- 将当前
KeyValue
在内存中重新构建,在可用Chunk的指定offset处申请内存创建一个新的KeyValue
对象。 - 将新创建的
KeyValue
对象写入ConcurrentSkipListMap
中。
1.3. MemStore Flush阶段
详见 MemStore
《HBase原理与实践》读书笔记