[repost ]HBase in 2013

original:http://yanbohappy.sinaapp.com/?p=434 2013年马上就要过去了，总结下这一年HBase在这么一年中发生的主要变化。影响最大的事件就是HBase 0.96的发布，代码结构已经按照模块化release了，而且提供了许多大家迫切需求的特点。这些特点大多在Yahoo/Facebook/淘宝/小米等公司内部的集群中跑了挺长时间了，可以算是比较稳定可用了。 1，Compaction优化 HBase的Compaction是长期以来广受诟病的一个feature，很多人吐槽HBase也是因为这个特征。不过我们不能因为HBase有这样一个缺点就把它一棒子打死，更多的还是希望能够驯服它，能够使得它适应自己的应用场景。根据业务负载类型调整compaction的类型和参数，一般在业务高峰时候禁掉Major Compaction。在0.96中HBase社区为了提供更多的compaction的策略适用于不同的应用场景，采用了插件式的架构。同时改进了HBase在RegionServer端的存储管理，原来是直接Region->Store->StoreFile，现在为了支持更加灵活多样的管理StoreFile和compact的策略，RS端采用了StoreEngine的结构。一个StoreEngine涉及到StoreFlusher, CompactionPolicy, Compactor, StoreFileManager。不指定的话默认是DefaultStoreEngine，四个组件分别是DefaultStoreFlusher, ExploringCompactionPolicy, DefaultCompactor, DefaultStoreFileManager。可以看出在0.96版之后，默认的Compaction算法从RatioBasedCompactionPolicy改为了ExploringCompactionPolicy。为什么要这么改，首先从compaction的优化目标来看：compaction is about trading some disk IO now for fewer seeks later，也就是compaction的优化目标是执行Compaction操作能合并越多的文件越好，如果合并同样多的文件产生的IO越小越好，这样select出来的列表才是最优的。 主要不同在于： RatioBasedCompactionPolicy是简单的从头到尾遍历StoreFile列表，遇到一个符合Ratio条件的序列就选定执行compaction。对于典型的不断flush memstore形成 StoreFile的场景是合适的，但是对于bulk-loaded是不合适的，会陷入局部最优。 而ExploringCompactionPolicy则是从头到尾遍历的同时记录下当前最优，然后从中选择一个全局最优列表。 关于这两个算法的逻辑可以在代码中参考对应的applyCompactionPolicy()函数。其他CompactionPolicy的研究和开发也非常活跃，例如Tier-based compaction (HBASE-6371,来自Facebook) 和stripe compaction(HBASE-7667) 吐槽：HBase compaction为什么会问题这么多，我感觉缺少了一个整体的IO负载的反馈和调度机制。因为compaction是从HDFS读数据，然后再写到HDFS中，和其他HDFS上的负载一样在抢占IO资源。如果能有个IO资源管理和调度的机制，在HDFS负载轻的时候执行compaction，在负载重的时候不要执行。而且这个问题在Hadoop/HDFS里同样存在，Hadoop的资源管理目前只针对CPU/Memory的资源管理，没有对IO的资源管理，会导致有些Job受自己程序bug的影响可能会写大量的数据到HDFS，会严重影响其他正常Job的读写性能。 http://blog.cloudera.com/blog/2013/12/what-are-hbase-compactions/ http://www.slideshare.net/cloudera/hbasecon-2013-compaction-improvements-in-apache-hbase 2，Mean Time To Recovery/MTTR优化 目前HBase对外提供服务，Region Server是单点。如果某台RS挂掉，那么直到该RS上的所有Region被重新分配到其他RS上之前，这些Region是的数据是无法访问的。对这个过程的改进主要包括： HBASE-5844 和 HBASE-5926：删除zookeeper上Region Server/Master对应的znode，这样就省的等到znode 30s超时才发现对应的RS/Master挂了。 HBASE-7006： Distributed Log Replay，就是直接从HDFS上读取宕机的WAL日志，直接向新分配的RS进行Log Replay，而不是创建临时文件recovered.edits然后再进行Log Replay HBASE-7213/8631： [...]



via WordPress http://blog.newitfarmer.com/big_data/big-data_store/hbase/13854/repost-hbase-in-2013#utm_source=rss&utm_medium=rss&utm_campaign=repost-hbase-in-2013