hdfs上的append测试

　　hbase在写入数据之前会先写hlog，hlog目前是sequencefile格式，采用append的方式往里追加数据。之前团队的同学测试关闭hlog会一定程序上提升写hbase的稳定性。而在我之前的想象中，hlog的写入速度应该是稳定的。于是写了个append程序专门测试hdfs的append性能。

　　代码如下：

　　FSDataOutputStream stm = fs.create(path, true,
                conf.getInt("io.file.buffer.size", 4096),
                (short)3, blocksize);
　　String a = make(1000);
　　stm.write(a.getBytes());
　　stm.sync();

　　可以看到，append的过程分两步：先write，然后执行sync()，如果不执行sync，理论上会存在丢失数据的风险。

　　由于不清楚是sync不稳定，还是write本身不稳定。所以对打开和关闭sync均做了测试。
图1：打开sync功能

[img]http://dl.iteye.com/upload/attachment/475668/6d613302-af1e-33ff-b1ee-2b64e6764a43.jpg[/img]


图2：关闭sync功能

[img]http://dl.iteye.com/upload/attachment/475652/fb6e3f2a-99a3-314a-bb00-f99a16fc5dc4.jpg[/img]

从图1和图2的结果可以看到打开和关闭sync操作同样不稳定，因此可以判断不稳定因素主要出在write本身上。观察write函数，发现在创建它时需要一个blocksize参数，我的代码中一开始是设置的1MB。于是修改为32MB，绝大部分毛刺消失了。进一步修改为64MB，性能有进一步的提升。如下图
图3：设为32MB

[img]http://dl.iteye.com/upload/attachment/475664/780c9581-e89e-390a-b240-46d2341107e0.jpg[/img]

图4：设为64MB

[img]http://dl.iteye.com/upload/attachment/475666/22891df5-9977-3f53-8c47-00a897e275a6.jpg[/img]

　　这个参数是决定多大的文件在hdfs上可读的。传统的hdfs写文件要满足dfs.block.size大小(默认64MB)才可读。但是在append模式下这个可读的大小是由这里的blocksize决定的。默认值在本地文件系统下由fs.local.block.size决定，在hdfs文件系统下仍由dfs.block.size决定。如果设为1MB，那么hdfs上每append 1MB的大小，就可以读到了。当写入的数据达到这个大小时，会触发namenode执行fsync()操作。而在日志中观察到，每次发生这个操作时，都会造成读响应的变慢。

　　fsync()操作的内容比较多，没有仔细看源码，知道原理的同学联系我吧。

　　从附图中可以看到，append_block_size从1MB提高到32MB，再提高到64MB，都会有一定程序的稳定性改善。再提高就没有用了，因为hlog和dfs.block.size的默认大小都是64MB。不过hbase每1s会强制刷新执行一次fsync，所以会看到hbase在打开日志的情况下每1s会有一次小的响应时间波动

　　结论有两点：
　　1 hdfs的append的确是有一点不稳定的
　　2 修改fs.local.block.size或dfs.block.size可以影响这个不稳定因素。