2014年3月25日，CSDN在线培训：HBase在小米中的应用实践圆满结束，本次培训讲师是来自小米的崔建伟，他表示随着小米业务的逐渐扩展，特别是大数据时代的到来，原有的关系型数据库MySQL已经逐渐无法满足需求，因此向NoSQL迁移是很自然的事情。
Q：部署集群是用Hadoop还是CDH？
目前使用的是HBase社区的0.94分支。
Q：小米基础平台组都做哪些事情？
负责小米的存储和计算平台开发。
Q：Hive性能不及自己写的MapReduce吧？
Hive的优点在于用类SQL的方式进行大数据分析和处理，学习成本比较低。Hive转化的MR作业会做优化，有时甚至比自己写的MR作业更高效。也有HQL语句写的不好而导致效率低下的例子，需要具体分析转换后的MR作业逻辑。
Q：我有个HBase集群，有读和写操作。写操作每天都有峰值，每次平稳运行一个月时间后查询就会非常慢。我的问题是为什么每次碰到这种情况重启不能解决问题？但经过手动compaction和split后就解决了这个问题。帮忙分析一下吧。
查询慢的原因可能很多。Compaction会合并HFile，真删除数据、删除过期数据，对于查询效率的提高作用很大；Split Region之后，会触发Region的Compact，因此也能帮助提高查询效率。一般来讲重启集群对于查询效率的提高没有直接关系。另外HBase的读性能应该主要与内存和硬盘的比例有关，硬盘读延时较大。你们的数据访问是完全随机的还是访问最近写入的数据更多？如果是访问近期写入数据更多，一般命中内存概率很大，读效率不会随数据量增长而很快下降；如果是完全随机读，数据量变大后，需要从硬盘读的比例同步变大，读性能下降可能比较明显，读性能差的时候ioutil可能很高吧。
Q：你们在使用HBase的时候遇到过的最大难题是什么，是怎么一点一点解决的？
应该遇到过很多难题，比如高可用性、性能方面。主要是通过输入了解代码，优化实现，加入更多的调试信息明确问题以及故障总结等方式来逐渐解决。
Q：在使用HBase的过程中gc是怎么优化的？
结合gc log重点关注Xmn/SurvivorRatio/MaxTenuringThreshold以及并发gc线程数即可，gc靠tuning参数只能缓解问题，最终还是得关注从代码层面减少内存垃圾和碎片。
Q：你们现在用的jdk的版本是多少？
1.6.3x，未正式使用1.7。
Q：之前讲到了多个集群浪费的问题，想问问小米在节能方面做了哪些工作？
对于离线业务，建设大的离线集群让业务共享资源。统计cpu/磁盘的利用率，寻找优化的可能。
Q:二级索引在HBase怎么实现？
局部二级索引会借助于同region跨行事务的原子性，Key Delimiter Prefix Region Split Policy的Split Policy；全局二级索引会基于全局跨行事务（我们实验了全局二级事务，原理同google percolator）。
Q：能否介绍下HBase compaction优化方面？
compaction方面我们规划了一些优化工作，参见：https://issues.apache.org/jira/browse/HBase-9528
Q：如果集群的region个数已经达到5000个，每次上下线时间较长，不知道小米对region上线时间有没有优化？
对于集群升级，我们会做rolling_update；每台升级关闭region server前，会通过脚本将上面的region move到其它region server，这个过程中region 在内存的数据会flush，减少后面HLog replay的时间。另外，后面也会做region server并发restart。
Q：小米集群每台机器的配置都是一样的，都有哪些典型配置（CPU核数、内存、硬盘、硬盘转速）？
某些读多写少的业务尝试过ssd。机器典型的配置参见PPT的page5。采用定制机器还是购买厂家如联想、华为等的机器。
Q:小米的结构化存储服务有什么优势？
基于HBase，具有高可扩展性和高可用性；同时支持服务器端和客户端两种模式的访问。
Q：目前你们公司的集群响应速度怎么样？能大概介绍一下吗？
随机速度在2到5ms左右；随机读速度在3-10ms左右。
Q：HBase的实时读取不是很好，有什么改进的方案吗？
读性能主要是看缓存命中率，只要这个命中率高实时读性能还是不错的，我们优化了HBase的block cache淘汰算法，对热点数据的命中率也会有帮助。当读请求击穿到HDFS层面或是更下面的物理磁盘层面，那实际的读性能就可能取决于底层磁盘IO能力了，目前在HDFS我们实现了Hedged Read特性可以优化读请求的时延，还有个多block reader在开发计划中，而在OS的缓存命中率上我们还没开展相关的分析和优化指导工作。
Q:Hadoop 2中的Yarn对HBase是否有性能上的影响？如果配合spark可以吗？
第一个问题，是指在Yarn上运行HBase，还是MR处理HBase数据？前者没有实践，后者和MR1应该没有明显差异。
第二个问题，目前Spark支持运行在Yarn上，也可以处理HBase的数据，但Spark0.9.0对于安全集群(Kerberos)支持的不够完善。
Q：运维监控时数据是怎么采集和存储的？
集群指标通过jmx上报，我们通过程序定期采集，然后存储到OpenTsdb。
Q：请问在HLog的新写模型下，还可以保证强一致性吗？
可以保证，writeHandler会等待底层的AsyncSyncer sync的maxTxid大于自身的txid后才会返回。
Q：请问小米当时 在选择数据库的时候，有没有考虑过MongoDB？为什么最后选择了HBase而弃用MongoDB？
HBase在Scalability、Reliability、Fault Tolerance上有优势，更适合大规模数据场景下使用。
Q：问一个关于HBase版本的问题。一个单元的版本数量如果过多，会不会造成读取性能下降？比如存储一万版本？（这样的需求来自于我需要在一个单元中，存储一个IDLIST。）
如果一行是一次rpc读回，如果行太大，可能会影响到读性能；目前我们更倾向于瘦长型的行。
原文链接：http://www.csdn.net/article/2014-04-01/2819083-HBase-Hadoop