会议概要
2016年5月24日，HBaseCon2016于加州旧金山市内召开，我（绝顶）和大沙作为speaker参加了这次会议并在40分钟的session里介绍了HBase在阿里搜索场景中的应用及改进。本次会议参会的公司阵容包括谷歌、微软、苹果、FaceBook、阿里巴巴等，是有史以来最豪华的，也从一个侧面反应了HBase的发展前景和影响力。会议的主要session列表如下：
重点议题和内容
下面分别从开场、前沿技术细节和结尾展望等几个方面分别介绍本次会议的重要议题，各位同学可以选择感兴趣的部分进行阅读
开场篇
高大上的展示屏
不到8点，会场已经来了不少人
9点钟开始opening session，Sponsor里最吸引眼球的就是高大上的谷歌
世界范围大量的使用者，影响力堪比麦当劳
快速的版本迭代说明了社区的活跃
来自世界各地的新晋committer显示着社区的开放，我有幸被放在了列表的顶端，也代表了社区对阿里巴巴人员加入的重视（注：@天梧 大神早在2012年就成为了committer，是HBase社区在整个东八区的第一个committer，有必要再强调一下，这是我们的骄傲）
接下来是大会组委会成员对于各自所在公司使用HBase情况的介绍，首当其冲的是苹果，没错，这个追求艺术感的公司也在用HBase，并且从2010年就开始使用了
HBase界老牌强队Yahoo，不过集群规模和我厂比有点儿out了
重新拥抱开源的FaceBook，详细讲述了FB从闭源到重新开源的心路历程。重新拥抱开源的原因？很简单：人多力量大，社区新版本性能远超FB闭源版本
开场至此结束，Apple和FaceBook大厂坐镇，感觉所有参会者精神都为之一振
前沿技术细节篇
并发写WAL replica - 小米
短暂休息后来到了具体的session，作为技术开发人员，我对Development&Internals有更大的兴趣，所以首先来到了国内兄弟公司：小米的会场。作为国内拥有committer最多的公司（国内一共7个committer，小米有4个），小米在HBase上颇有贡献。在他们的session中，最值得关注的是并发写WAL replica的功能实现(HBASE-14790)，该功能可以有效的降低HBase写入的平均响应时间。另外他们还分享了在跨机房备份方面的实践经验和在HBase服务化方面所做的工作
In-Memory Flush/Compaction - Yahoo
第二part的session我选择了Yahoo的In-Memory Flush/Compaction，这个事情2014年的时候天梧和我在集团就讨论过，可惜由于各种原因没有能够实操，而Yahoo完成了相关工作并贡献回社区。目前HBase flush/compaction存在的主要问题有：内存中为了保证写入速度，采取ConcurrentSkipListMap的结构存储数据，该数据结构有大量的索引，直接flush的效率较低（内存256MB flush后可能只有~100MB），而大量小HFile的生成触发的compaction会导致BlockCache的换入换出，对于读写都是热点的数据表来说会造成大量冗余IO。同时，如果对于同一行的数据进行多次插入，例如机器学习或者索引item频繁更新等场景，内存中的冗余数据也会导致查询效率的降低。而In-Memory Flush/Compaction可以解决这些问题。从Yahoo的测试结果来看，该功能可以明显降低读毛刺
午饭后参观了各个公司的卖场，了解了一下各自的产品，细节略过
降低毛刺 && AsyncHBase
下午的第一part，分别听了一下Rocket Fuel对于毛刺的改善，以及Yahoo关于AsyncHBase的介绍。降低毛刺的方案和我们在集团和搜索使用的方案比较类似，主要是利用HDFS的分级存储(Heterogeneous Storage)功能，用不同类型的SSD分别作为HFile/WAL存储和二级缓存。而AsyncHBase的性能不论吞吐量还是RT基本在普通同步客户端的1.5倍
Alibaba Search
下午第二part是我们自己的session，主要介绍了阿里搜索场景下HBase的使用和改进，并分享了我们对于未来挑战和发展的展望。由于我们是参会公司中唯一使用计算存储一体化且集群混布解决方案的公司，并且拥有强大的硬件团队支持，其他参会者对于我们的分享表示了极大的兴趣，并且对于我们所做的工作给予了很高的评价。当然我们并没有透露敏感的具体数据，这个还是要强调一下。由于讲session比较紧张，照片就只有大沙和我的“站台”照，细节有兴趣的话大家可以线下与我讨论。
Off-Heaping read path - Intel
对于Java应用来说，GC是永远的痛，因此offheap几乎是一个必经的过程，下午第3个时间段主要听了一下Intel的committer介绍他们对hbase read path全路径offheap化所做的工作。其中比较有意思的结论主要有两点：java NIO实现性能并不比netty NIO差，优化后的L2 cache(offheap)性能可以媲美L1 cache(on-heap)。注：由于这个ppt的密度较大，拍照很难看清楚，因此特意找到Intel的印度老哥要了原版ppt，如下
G1 GC tuning - HubSpot
全路径上OffHeap很难实现，因此还是需要在降低GC停机时间上下功夫，而G1 GC是大家远观但不敢亵玩了很久的东西。据我所知，阿里启用G1 GC的应用屈指可数，但是在这次会议上我了解到很多公司在线应用中使用了G1 GC，其中就包括FaceBook。使用G1 GC参数调节很重要，因此我专门跑去听这个session。老实说，HubSpot这家公司我真的没听过，但看起来是在实际做事情的，也分享了很多G1 GC参数调节上的经验。下面的相关slides是分享的详细内容，其中的推荐参数我并没有来得及尝试，因此也属于无脑分享，各位看官请谨慎参考。另外，G1 GC比较适合大堆这个基本是共识，但据FB的committer分享，G1 GC比较适合<=31GB或者>=100GB的场景，32G～100G的堆大小还是CMS更适合，这个我也没来得及验证，大家也谨慎参考下
Spark On HBase - Cloudera + Hotonworks
死对头联手的桥段虽然少见但是作为天朝子民还是有幸目睹过，不过这也说明了Spark的火热。Spark On HBase，是在hbase中内置了支持spark的connector。为什么没有放进Spark core里面？据databricks的人说是spark太hot了，要想保证快速迭代不得不把周边的东西踢出core，anyway，hbase内置支持spark将其作为存储，哦耶。
结尾展望篇
Ending session由Salesforce的首席架构师Lars H.给出，一上来就抛出一个问题，HBase的靠山是谁？
答案是：很多！
作为BigTable的始祖，Google怎么看HBase？：BigTable架构的最佳开源实现
谷歌、苹果、FaceBook都来了，怎么能少了微软？
Salesforce怎么看？简单一句话：能干还省钱，性价比高
扯了这么多，HBase到底好在哪里？
事实上，能同时很好支持batch和streaming作业的存储引擎，仅此一家。高吞吐，低延时，如果能很好的结合在线存储弥补故障恢复时间方面的短板，可以形成完美的全场景存储解决方案
未来的挑战？新硬件，多场景下的问题我们正在经历，但是阿里最擅长打组合拳，我们有给力的硬件团队，给力的基础组件（JVM，OS等）支持，给力的业务方愿意敦促和跟随我们一起向着极限的目标努力，这些问题终究会被解决
公司访谈
除了参加HBaseCon2016，此次美国之行还花两天时间专门拜访了Facebook和databricks
在FaceBook主要和rocksdb以及应用团队的tech lead进行了技术上的交流，从中了解到rocksdb并没有做分布式解决方案的计划，在FaceBook内部和HBase也是友好共存关系而不是竞争关系。另外对于流计算中使用rocksdb存储本地状态并使用HBase作为分布式存储的方案，大家也达成了共识。照片方面主要是FaceBook园区内的简单拍摄，风格上和西溪园区比较像，比较free style，让人有一种家的感觉
在databricks主要了解了一下spark在streaming方面的发展动态，得到的消息是spark 2.0主要在API方面准备好，然后2.1作为正式发力的release，会包含spark SQL+streaming等一系列重大改进。由于流计算方面我并非专家，此处就不多说了，发张和Spark-SQL负责人Michael大牛的合影
总结
此次参加HBaseCon2016，了解到了HBase开发前沿的一系列技术和进展，也感受到了HBase社区的活跃以及在业界的广泛使用。与此同时和更多相关领域的同僚建立了联系，有利于今后进行更加深入和广泛的讨论，共同进步。
另外感触很深的一点是，谷歌、微软、FaceBook、苹果，开源的路上我们并不孤独。我们想传达出的一个信息是：阿里并不是一家吝啬给予的公司，我相信我们已经成功了一半。
最后YY一句：拥抱开源，和全世界的牛人在讨论中共同成长，并在过程中不断积累经验，做出适合阿里特定场景的解决方案以及领先世界的创新，这是我作为一个搜索人和HBase开发者的理想，我相信并期待着这个目标的实现。