HBase读写优化N条实用技巧

2019独角兽企业重金招聘Python工程师标准>>>

最近spark跑的很慢，主要时间在scan hbase上。来来回回调试了挺长时间，最后确定瓶颈在AWS EBS的磁盘I/O(跑spark时IOPS爆到1500)，所以实际上也没有太多调优可以做。倒是调试过程中看了许多文章和资料，我觉得值得记录一下。

中间废话略多，不爱看直接跳文章最后一句。

网上HBASE/Hadoop调优的文章非常多，这里列一些我觉得值得留作reference的：

• 应用层：hbase性能调优
• Infra层：HBase 管理，性能调优
• HBase操作最佳实践

笼统的说，无论什么样的数据库，数据库查询调优大致也就有这么几件可以做的事情：

• 缓存
• 索引
• 减少I/O
• 提高I/O效率

缓存

Hbase操作中scanner.setCaching可以设置每次RPC请求返回的记录条数，默认是1，应该考虑设置。

全表扫描关掉cacheBlock，因为在全表scan的过程中不会使用刚刚读取的东西。

索引

HBASE里最接近传统数据库索引的概念应该是Bloom Filter。Bloom Filter可以通过告诉系统哪些StoreFile根本不用查来用来优化Get，对带条件或指定列的Scanner也有帮助。

Bloom filter有ROW和ROWCOL两种，ROWCOL的方式可以对scan生效，但是存储消耗更大。

• 任何类型的get（基于rowkey或row+col）Bloom Filter的优化都能生效，关键是get的类型要匹配Bloom Filter的类型

• row+col+qualify的scan可以去掉不存在此qualify的storefile，也算是不错的优化了，而且指明qualify也能减少流量，因此scan尽量指明qualify。

减少I/O

少读有时是最简单有效的优化：

• 批量读写
• 减少scan的family和qualifier

• 使用filter
• 用尽量小的Family名字

我的理解是每个scan的result是会带有family和qualifier名字的。举个例子，如果family名字是"family",5个列，5000万行数据，scan表的时候你大概load的"family"这个词大概有1个G。

很多文章提到了压缩对读取性能的提升，即减少了磁盘读写，又减少了网络传输。

开启lzo或者snappy压缩，压缩会消耗一定的CPU，但是，磁盘IO和网络IO将获得极大的改善，大致可以压缩4~5倍；

还有文章提到了使用Avro序列对象再做存储，虽然这样不能在序列化的对象上使用Filter，但是同样是大幅降低了磁盘读写和存储空间。

除了正常的应用程序对HBASE的使用，一个潜在的I/O是Hadoop的replication。

考虑调低或关闭replication ./bin/hadoop dfs -setrep -R -w 2 /

另一个潜在的I/O是Hbase的region split和compaction。默认策略当region的大小超过10G时就会split。当一个region中的StoreFile太多时Hadoop就会做Compaction。我的感觉compaction对I/O影响非常大，经常会导致spark在scan时timeout。

Major Compaction可以手动或自动触发，然而由于它会引起很多的IO操作而引起性能问题，因而它一般会被安排在周末、凌晨等集群比较闲的时间。

提高I/O瓶颈

AWS EBS很方便，但是不强大，毕竟是网络虚拟硬盘。提高IOPS方法倒是很多，用IOPS优化的卷或者多挂磁盘做RAID(准确的说是做JBOD就好)。

• 不要用网络虚拟硬盘（然而臣妾做不到啊）
• Master做1+0Raid，Slave做JBOD
• 不要用SSD！SSD同效率成本大概是HDD的2.5倍
• 控制在1个instance 8核不超过8个磁盘，每磁盘IOPS=100左右

更宏观的思考

回过头来想，既然全表scan hbase，那肯定是个离线任务，既然是离线任务，又为何要纠结性能。

当然这次的问题出发点来自于Spark报Timeout的错：

Tue Jul 12 09:46:46 UTC 2016, null, java.net.SocketTimeoutException: 

最后其实把Hadoop的Timeout时间从2分钟设置成10分钟就好了。

当然即使是离线任务也不可以恣意的慢，当数据库足够大时，离线任务的执行时间也可能超过一个特定的可忍受的线。应用程序应该考虑如何让全表这样的操作分解成周期更短的操作，以便于磁盘的I/O能更均匀的时间分布。

确实有意思的一个话题是如何scale out磁盘：如果把磁盘I/O看成和CPU一样的资源，就会有在特定需要的时候scale out的需求。当然，闲置的磁盘相对便宜，所以现在没有人会像管理CPU或instance一样去管理它。而且磁盘不同于CPU和内存这些资源，对它的使用总是伴随着对其上数据的使用，于是资源的初始化难度大很多。

当然，AWS EBS虽不强大，但是价格实惠童叟无欺，1TB的Amazon EBS Throughput Optimized HDD (st1) 磁盘一个月大概350块，所以如果HBASE读写有性能问题：

花千吧块钱多加几块硬盘吧！

转载于:https://my.oschina.net/princeicelk/blog/719734