Hbase写操作产生的木桶效应

生产环境中hbase的写存在木桶效应，具体体现在hbase写入数据缓慢，在参数优化极好的情况下，仍然没有解决问题。经过多次的排查，产生问题的原因有2个：

1.网络问题

某个节点的网卡出现不明显故障，造成该节点网速传输速度下降。

2.异构设备磁盘硬件I/O

有时候很多利旧设备不舍得丢弃，大数据集群又是一个廉价的高性能的分布式计算平台，只要是能开机的物理机都可以并入集群，但是，随之带来的问题就是磁盘IO会严重影响集群的性能，不过现在通过技术手段已经能够解决此类问题，比较常用的方式就是：设备分组。

那么hbase为什么会出现木桶效应呢？首先我们都知道往hbase写入数据的时候，是先写入WAL的，写入成功后再写入memstore。

原来在Table创建的时候，有一个参数可以设置，是否每次写Log日志都需要往集群里的其他机器同步一次，默认是每次都同步，同步的方式有2种：Pipeline，n-Way Writes。

Pipeline是指datanode接收数据后，再传给另外一台datanode，是一种串行的方式； 

n-Way Writes是指多datanode同时接收数据，最慢的一台结束就是整个结束

差别在于一个延迟大，一个并发高。

那么从2个同步方式中可以看出，如果在同步时，其中某个节点的性能出现问题，从而会导致整个集群出现严重的写延迟，这就是木桶效应的主要原因。

题外话：

hbase的日志有.logs和.oldlogs。.logs保存的是所有Regionserver上当前在写入的HLog，.oldlogs是过期日志，通过hbase.master.logcleaner.ttl参数可以设置定期清理这个过期日志，默认是10分钟