【.com原稿】名利双收的李宇是WOTA全球架构与运维技术峰会的分享嘉宾。现任阿里巴巴搜索事业部高级技术专家，HBase开源社区PMC。提交者。开源技术爱好者，主要关注分布式系统设计、大数据基础平台建设等领域。连续3年基于HBase/HDFS设计开发存储系统应对双十一访问压力，具有丰富的大规模集群生产实践经验。HBase作为淘宝全网索引构建和在线机器学习平台的核心存储系统，是阿里巴巴搜索基础设施的重要组成部分。在本文中，我们将介绍HBase在阿里搜索的历史、规模、应用场景，以及在实际应用中遇到的问题和优化。阿里搜索HBase的历史、规模、服务能力：阿里搜索从2010年开始使用HBase，最早已经有十多个版本。目前使用的版本是在社区版本的基础上进行了大量优化。社区版建议不要使用1.1.2版本，性能问题比较严重，1.1.3之后的版本体验会好很多。集群规模：目前仅阿里就有3000多个搜索节点，1500多个***集群。阿里集团节点数量远超这个数量。服务能力：去年双11，阿里搜索离线集群峰值吞吐量超过4000万次/秒，单机峰值吞吐量达到10万次/秒。另外，当CPU使用率超过70%时，单CPU核心可以支持8000+QPS。HBase在阿里搜索中的作用及主要应用场景：HBase是阿里搜索的核心存储系统。它与计算引擎紧密结合，主要服务于搜索和推荐业务。HBase在搜索和推荐中的应用流程如上图所示，就是HBase在搜索和推荐中的应用流程。在索引构建过程中，用户产生的所有存储在在线MySQL等数据库中的在线数据，都会以流的方式导入到HBaes中，提供给搜索引擎构建索引。在推荐过程中，机器学习平台Porshe会将模型和特征数据存储在HBase中，并将用户点击数据实时存储在HBase中，通过在线训练更新模型，提高在线推荐的准确性和效果。应用场景一：指数构建。淘宝和天猫拥有多种在线数据源，取决于淘宝有许多不同的在线商店和各种用户访问。索引构建的应用场景如上图所示。晚上，我们将从HBase中批量导出数据，提供给搜索引擎建立全量索引。白天，线上的商品和用户信息都在不断变化，这些动态变化也会从线上存储实时更新到HBase，并触发增量索引构建，从而保证搜索结果的实时性。目前端到端延迟可以控制在秒级，即库存变化、商品上架等信息在服务端更新后，可以在用户端快速查询到。索引构建应用场景抽象图如上图所示，整个索引构建过程可以抽象为一个不断更新的过程。例如，全量和增量量可以看作是一个join。网上有不同的数据源，它们是实时更新的。整个过程是一个长期连续的过程。这里着重强调一下HBase与流式计算引擎相结合的特点。应用场景二：机器学习。这里有一个简单的机器学习例子：用户想买一部3000元的手机，于是在淘宝上按照3000元的条件筛选，但是没有他喜欢的。之后，用户将从头开始搜索。此时会利用机器学习模型，将价值3000元左右的手机排在搜索结果的前列，即利用之前的搜索结果影响后面搜索结果的排名。在线日志分析如上图所示，在线日志的分析可以归结到产品和用户两个纬度，导入分布式和持久化的消息队列，存储在HBase上。随着在线用户的点击行为日志产生数据更新，相应的模型也随之更新，用于机器学习训练。这是一个迭代过程。HBase在阿里搜索应用中遇到的问题及HBase架构分层优化。在谈问题和优化之前，我们先来看一下HBase的架构图，大致分为以下几个部分：HBase的架构图首先是API，一些应用编程接口。RPC，这里的远程过程调用协议分为两部分：客户端发起访问，服务端处理访问。MTTR故障恢复、Replication数据复制、表处理等，都在分布式管理的范围内。中间核心是写入、查询等数据处理过程的核心部分，最底层是HDFS（分布式文件系统）。HBase在阿里搜索应用中遇到的问题和优化有很多。下面选择五个方面重点关注RPC瓶颈与优化、异步与吞吐量、GC与故障、IO隔离与优化、IO利用率。问题及优化一：RPC瓶颈及RPCServer线程模型的优化PPC服务器实际存在的问题是原有的RpcServer线程模型效率低下。如上图所示，可以看到整个过程通常很快，但是会被不同的线程处理。非常低效。基于Netty改写后，可以更高效的复用线程，实现HBaseRpcServer。平均RPC响应时间从0.92ms降低到0.25ms，吞吐量几乎翻了一番。问题与优化2：异步和吞吐量RPC客户端的实际问题是流计算对实时性要求高，分布式系统无法避免秒级毛刺，同步模式对毛刺敏感，导致吞吐量瓶颈。优化方法是基于netty实现非阻塞客户端，基于protobuf的非阻塞Stub/RpcCallback实现回调。与Flink集成时，实测吞吐量是同步模式下的两倍。问题及优化3：GC和glitches如上图所示。这部分的实际问题是在PCIe-SSD的高IO吞吐量下，读缓存的换入换出率大大增加，堆上的缓存内存没有及时回收，导致频繁的CMSgc甚至fullGC。优化方式是实现E2E读路径的offheap，使Full和CMSgc频率降低200%以上，读吞吐量提升20%以上。如上图所示，是线上的结果。优化前QPS为17.86M，优化后为25.31M。问题与优化4：IO隔离与优化HBase本身对IO非常敏感，磁盘满了会出现很多毛刺。在计算存储混合部署环境中，MapReduce作业产生的shuffle数据和HBase自身的Flush/Compaction都是大I/O的来源。如何避免这些影响？利用HDFS的HeterogeneousStorage功能，对重要业务表的WAL（write-ahead-log）和HFiles使用ALL_SSD策略，对普通业务表的HFiles使用ONE_SSD策略，保证Bulkload支持指定的存储策略。同时确保MR临时数据目录（mapreduce.cluster.local.dir）只使用??SATA磁盘。HBase集群IO隔离后的glitch优化效果对HBase本身的IO有影响，采用Compaction限流、Flush限流、Per-CFflushing三种方式。上图为在线效果。绿线从左到右分别是响应时间、处理时间和等待时间的p999数据。以响应时间为例，99.9%的请求不会超过250ms。问题及优化5：IO使用HDFS写3份，通用机型有12个HDD盘，SSD的IO能力远超HDD。如上图所示，实际问题是单个WAL无法充分利用磁盘IO。如上图所示，为了充分利用IO，我们可以通过合理映射对region进行分组，实现多个WAL。基于命名空间的WAL分组支持App之间的IO隔离。从线上效果来看，所有HDD盘的写入吞吐量提升了20%，所有SSD盘的写入吞吐量提升了40%。平均在线写入响应延迟从0.5ms下降到0.3ms。开源&我们为什么要在未来拥抱开源？首先，想象一下，如果每个人都进行了优化但没有表现出来，认为这是自己比别人的优势，会发生什么？如果每个人都分享自己的长处，他们就会得到积极的反馈。第二，HBase团队普遍比较小，人员流失会造成很大的损失。如果将内容贡献给社区，代码的维护成本可以大大降低。一起做开源比在一个公司单独做要好很多，所以一定要有贡献精神。未来，阿里搜索一方面将PPC服务器进一步做成异步，使用HBase核心进行流式计算，同时为HBase提供嵌入式模型。另一方面，尝试更换HBase内核，更换新的DB，以达到更高的性能。让我们一起期待2017年8月4日在深圳举行的HBaseConAsia，我们不见不散！！！以上内容是根据绝顶先生在WOTA2017《大数据系统架构》环节的演讲内容整理而成。【原创稿件，合作网站转载请注明原作者和出处为.com】
