Hbase 写入 hdfs 源码分析

原创

腾讯云数据库团队

修改于 2017-06-30 16:55:10

4.3K0

修改于 2017-06-30 16:55:10

文章被收录于专栏：腾讯云数据库团队的专栏腾讯云数据库团队的专栏腾讯云数据库团队的专栏

作者：熊训德腾讯云工程师

本文档从源码角度分析了，hbase 作为 dfs client 写入hdfs 的 hadoop sequence 文件最终刷盘落地的过程。

之前在《wal线程模型源码分析》中描述wal的写过程时说过会写入hadoop sequence文件，hbase为了保证数据的安全性，一般都是写入同为hadoop生态的hdfs(Hadoop Distribute File System)中。append的最终结果是使用write.append()写入，而sync()则是使用write.sync()刷盘。

这时其实并未真正的结束，为了保障数据安全性，hdfs可会根据用户的配置写到多个datanode节点中，不管是HFile还是FSHLog都不仅仅是简单的写入或刷入(flush)了真正的存储节点--DataNode中，其中涉及到数据流（WALEntry）如何安全有序且高效地写到datanode文件中，而flush又是具体如何做的，这个文档就将从源码上分析hbase的“写”操作到了wirter.append()和writer.sync()后具体发生了什么，如何落地的。

下图是《Hbase权威指南》中描述Hbase底层存储结构的顶层结构图。可以看到Hbase将处理HFile文件（memstore生成）和HLog文件（WAL生成）这两种文件都将有HRegionServer管理，当真正存储到HDFS中时，会使用DFS Client作为hdfs的客户端把大批量的这两种数据流写到多个DataNode节点中。

在文档《wal线程模型源码分析》中为了突出重点说明wal线程模型，并未具体说明writer.append()和writer.sync()中writer实例是什么，在FSHLog中被volatile关键字修饰声明为一个WALProvider.Writer类型的接口：

其实它的实现类是ProtobufLogWriter，这个类也在org.apache.hadoop.hbase.regionserver.wal包中，在wal包中是作为wal向datanode的writer，它在FSHLog是使用工厂模式createWriterInstance()实例化，然后调用init()方法初始化：

从源码中可以看到真正写实例是FSDataOutputStream，它用于向新生成的文件中写入数据，就像前面叙述的，在ProtobufLogWriter的init()方法中被初始化：

在这里我们仅仅讨论使用hdfs作为hbase的文件系统，也即是init参数中fs(System)是DistributedFileSystem的实例。在其createNonRecursive的实现的参数除了path参数指明需要在hdfs创建的文件路径比较重要以外，还有一个replication参数也很重要，这个参数说明了备份数量也即是写datanode份数。DistributedFileSystem中dfs是DFSClient的实例引用，也即最开始那张架构图中所指的DFS Client。hbase使用DFSClient的create方法通过RPC调用向hdfs的namenode创建一个文件并构造了输出流DFSOutputStream实例，这个方法另外一个重点就启动了一个pipeline，具体调用是streamer.start()，这个pipleline是hbase向hdfs的多个datanode管道写的实现。虽然这里分析的是wal的写入过程，但是其实keyvalue写到memstore，再写到HFile后也是采用这种方式管道写(pipeline)的方式实现。

通过rpc调用NameNode的create函数，调用namesystem.startFile函数，其又调用startFileInternal函数，它创建一个新的文件，状态为under construction，没有任何data block与之对应。于此同时创建成功后会返回一个DFSOutputStream类型的实例，在FSDataOutputStream中被称作wrappedStream，该对象负责处理datanode和namenode之间的通讯。

hdfs的文件结构，HDFS一个文件由多个block(默认64MB)构成。这里通过注释可以看到HDFS在进行block读写的时候是以packet(默认每个packet为64K)为单位进行的。每一个packet由若干个chunk（默认512Byte）组成。Chunk是进行数据校验的基本单位，对每一个chunk生成一个校验和(默认4Byte)并将校验和进行存储。

分析到这，已经可以看出hbase文件写入hdfs的过程并没有特别，hdfs就把hbase当做hdfs的client然后封装成chunk再组装成packet，再向datanode批量写数据。为了保证数据有序的传输，使用了数据发送队列dataqueue和待确认队列ackqueue，并使用两个线程DFSOutputStream$DataStreamer和DFSOutputStream$DataStreamer$ResponseProcessor(在run()中)分别来发送数据到对应block和确认数据是否到达。

还有另外一个重点就是hbase是如何把数据到datanode的磁盘的。

在此，我们又要回到ProtobufLogWriter类中因为writer.sync()最终调用的就是ProtobufLogWriter的writer方法，它的源码如下：

其中，output在就是之前分析过的FSDataOutputStream的实例，在sync()方法中调用了FSDataOutputStream的flush和hflush，其实flush什么都没做(noop，源码中也说明了)，hflush()则会调用也是前面提过的DFSOutputStrem类的hflush方法，hflush方法将Client缓存的所有数据(packet)立即发送给Datanodes，并阻塞直到它们写入成功为止。hflush之后，可以确保Client端故障不会导致数据丢失，但如果Datanodes失效仍有丢失数据的可能，当FSDataOutputStream关闭时也会额外的执行一次flush操作：

就像注释中所解释的一样，hflush是同步的只能保证能让新reader能看到，但是并不能保证其真正的持久化到了每个datanode中，也即没真的调用posix中的fsync()系统调用。它只是将client端写入的数据刷到每个DataNode的OS缓存(store)中，如果每个副本所在的DataNode同时crash时（例如机房断电）将会导致数据丢失。

hdfs给客户端还提供了另外一种语义hsync:client端所有的数据都发送到副本的每个datanode上，并且datanode上的每个副本都完成了posix中fsync的调用，也就是说操作系统已经把数据刷到磁盘上（当然磁盘也可能缓冲数据）；需要注意的是当调用fsync时只有当前的block会刷到磁盘中，要想每个block都刷到磁盘，必须在创建流时传入Sync标示。

hbase当前选择的是hflush语义。这两种语义都调用的flushOrsync方法，其中hflush调用的isSync传入false,而hsync传入的是true。

这个方法的主要作用就是把还在缓存(buffered )中的数据刷到datanodes中，

其中最终要的几个方法就是flushBuffer()，waitAndQueueCurrentPackket()和waitForAckedSeqno()，调用waitAndQueueCurrentPacket()将当前Package放到发送队列中waitForAckedSeqno()等待发送package的确认包，而其原理和写数据一样，就是把数据封装成chunk在把chunk一个个填充到package，再以pipeline的方式一个个写到datanode再根据是否有sync标识刷盘。