2014年3月25日，CSDN在线培训：HBase在小米中的应用实践圆满结束，本次培训讲师是来自小米的崔建伟，他表示随着小米业务的逐渐扩展，特别是大数据时代的到来，原有的关系型数据库MySQL已经逐渐无法满足需求，因此向NoSQL迁移是很自然的事情。
CSDN在线培训是专为广大技术从业人员准备的在线实时互动技术培训，邀请各个行业一线技术工程师分享他们工作中遇见的各种问题以及解决方案，同时给大家带来一些新技术、思路、解决方案！
CSDN在线培训以“经典性、实战性、系统性、前瞻性、专业性”的特色课程为主，通过视频授课、文档共享、白板共享、屏幕共享、讲师在线QA等多种形式的学习方法，帮助一线工程师们利用碎片化时间加强实战能力，提升实践水平，并实现与技术高手的沟通与互动。
由于本次培训的时间有限，问答环节有很多问题讲师没有时间进行回复，CSDN特别准备了本次培训QA总结，帮助大家更好的复习和总结此次培训中学到的技术点，让各位学员更快的掌握相关技术要点，少走弯路。以下是整理的一些QA，更多问题可以到CSDN本次活动讨论帖进行互动：http://bbs.csdn.net/topics/390742064。
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
