HBase 在阿里搜索中的应用

 中国企业数据治理联盟（www.chinaedg.com/）

点击》主数据管理     企业数据治理     信息资源规划      数据安全管理   

  HBase 在阿里搜索的历史、规模和服务能力

  历史：阿里搜索于 2010 年开始使用 HBase，从最早到目前已经有十余个版本。目前使用的版本是在社区版本的基础上经过大量优化而成。社区版本建议不要使用 1.1.2版本，有较严重的性能问题，1.1.3 以后的版本体验会好很多。

  集群规模：目前，仅在阿里搜索节点数就超过 3000 个，最大集群超过 1500 个。阿里集团节点数远远超过这个数量。

  服务能力：去年双11，阿里搜索离线集群的吞吐峰值一秒钟访问超过 4000 万次，单机一秒钟吞吐峰值达到 10 万次。还有在 CPU 使用量超过 70% 的情况下，单 cpu core 还可支撑 8000+ QPS。

　　HBase 在阿里搜索的角色和主要应用场景

　　角色：HBase 是阿里搜索的核心存储系统，它和计算引擎紧密结合，主要服务搜索和推荐的业务。

　　上图是 HBase 在搜索和推荐的应用流程。在索引构建流程中，会从线上 MySQL 等数据库中存储的商品和用户产生的所有线上数据，通过流式的方式导入到 HBase 中，并提供给搜索引擎构建索引。

　　在推荐流程中，机器学习平台 Porshe 会将模型和特征数据存储在 HBase 里，并将用户点击数据实时的存入 HBase，通过在线 training 更新模型，提高线上推荐的准确度和效果。

　　应用场景一

　　索引构建

　　淘宝和天猫有各种各样的的线上数据源，这取决于淘宝有非常多不同的线上店铺和各种用户访问。

　　如图所示。在夜间，我们会将数据从 HBase 批量导出，供给搜索引擎来构建全量索引。而在白天，线上商品、用户信息等都在不停的变化，这些动态的变化数据也会从线上存储实时的更新到HBase并触发增量索引构建，进而保证搜索结果的实时性。中翰软件专注数据治理11年http://www.jobhand.cn/

　　目前，可以做到端到端的延时控制在秒级，即库存变化，产品上架等信息在服务端更新后，迅速的可在用户终端搜索到。

　　索引构建应用场景抽象图

　　整个索引构建过程可以抽象成一个持续更新的流程。如把全量和增量看做是一个 Join，线上有不同的数据源且实时处于更新状态，整个过程是长期持续的过程。这里，就凸显出 HBase 和流式计算引擎相结合的特点。

　　应用场景二

　　机器学习

　　这里举一个简单的机器学习示例：用户想买一款三千元的手机，于是在淘宝按照三千元的条件筛选下来，但是没有中意的。之后 ，用户会从头搜索，这时就会利用机器学习模型把三千块钱左右的手机排在搜索结果的靠前位置，也就是用前一个搜索结果来影响后一个搜索结果的排序。

　　分析线上日志

　　如上图，分析线上日志。归结为商品和用户两个纬度，导入分布式、持久化消息队列，存放到 HBase 上。随线上用户的点击行为日志来产生数据更新，对应模型随之更新，进行机器学习训练，这是一个反复迭代的过程。

　　HBase 在阿里搜索应用中遇到的问题和优化

　　HBase 架构分层

　　在说问题和优化之前，先来看 HBase 的架构图，大致分为如下几个部分：

　　HBase 的架构图

　　首先是 API，一些应用程序编程接口。RPC，这里把远程过程调用协议分为客户端会发起访问与服务端来处理访问两部分。MTTR 故障恢复、Replication 数据复制、表处理等，这些都是分布式管理的范畴。中间 Core 是核心的数据处理流程部分，像写入、查询等，最底层是 HDFS(分布式文件系统)。

　　HBase 在阿里搜索应用中遇到的问题和优化有很多，下面挑选近期比较重点的五方面进行展开。

　　RPC 的瓶颈和优化

　　异步与吞吐

　　GC 与毛刺

　　IO 隔离与优化

　　IO 利用

　　问题与优化一

　　RPC 的瓶颈和优化

　　实际问题：

　　原有 RpcServer 的线程模型效率较低

　　优化手段：

　　Netty 可以更高效的复用线程

　　基于 Netty 实现 HBase RpcServer

　　线上效果：

　　Rpc 平均响应时间从 0.92ms 下降到 0.25ms

　　Rpc 吞吐能力提高接近 2 倍

　　问题与优化二

　　异步与吞吐

　　实际问题：

　　流式计算对于实时性的要求很高

　　分布式系统无法避免秒级毛刺

　　同步模式对毛刺敏感，吞吐存在瓶颈

　　优化手段：

　　基于 ne_y 实现 non-blocking client

　　基于 protobuf 的 non-blockingStub/RpcCallback 实现 callback 回调

　　线上效果：

　　和 flink 集成后实测吞吐较同步模式提高 2 倍

　　问题与优化三

　　GC与毛刺

　　实际问题：

　　PCIe-SSD 的高 IO 吞吐能力下，读 cache 的换入换出速率大幅提高

　　堆上的 cache 内存回收不及时，导致频繁的 CMS gc 甚至 fullGC

　　优化手段：

　　实现读路径 E2E 的 odeap

　　线上效果：

　　Full 和 CMS gc 频率降低 200% 以上

　　读吞吐提高 20% 以上

　　如上图，是线上的一个结果，QPS 之前是 17.86 M，优化之后是 25.31 M。

　　问题与优化四

　　IO隔离与优化

　　HBase 本身对 IO 非常敏感，磁盘打满会造成大量毛刺。在计算存储混合部署环境下，MapReduce 作业产生的 shuffle 数据和 HBase 自身 Flush/Compaction 这两方面都是大 IO 来源。

　　如何规避这些影响呢?利用 HDFS 的 Heterogeneous Storage 功能，对 WAL(write-ahead-log) 和重要业务表的 HFile 使用 ALL_SSD 策略、普通业务表的 HFile 使用 ONE_SSD 策略，保证 Bulkload 支持指定 storage policy。同时，确保 MR 临时数据目录(mapreduce.cluster.local.dir)只使用 SATA 盘。

　　HBase 集群 IO 隔离后的毛刺优化效果

　　对于 HBase 自身的 IO 带来的影响，采用 Compaction 限流、Flush 限流和 Per-CF flush 三大手段。上图为线上效果，绿线从左到右分别是响应时间、处理时间和等待时间的 p999 数据，以响应时间为例，99.9% 的请求不会超过 250ms。

　　问题与优化五

　　IO 利用

　　单 WAL 无法充分使用磁盘 IO

　　HDFS 写 3 份副本、通用机型有 12 块 HDD 盘、SSD 的 IO 能力远超 HDD。如上图，实际问题是单 WAL 无法充分使用磁盘 IO。

　　合理映射对 region 进行分组

　　如上图，为了充分利用 IO，我们可以通过合理映射对 region 进行分组，来实现多 WAL。基于 Namespace的WAL 分组，支持 App 间 IO 隔离。从上线效果来看，全 HDD 盘下写吞吐提高 20%，全 SSD 盘下写吞吐提高 40%。线上写入平均响应延时从 0.5ms 下降到 0.3ms。

　　开源&未来

　　为什么要拥抱开源?其一，试想如果大家做了优化都不拿出来，认为这是自己强于别人的优势，结果会怎样?如果大家把自己的优势都拿出来分享，得到的会是正向的反馈。其二， HBase 的团队一般都比较小，人员流失会产生很大的损失。如把内容贡献给社区，代码的维护成本可以大大降低。开源一起做，比一个公司一个人做要好很多，所以我们要有贡献精神。

　　未来，一方面，阿里搜索会进一步把 PPC 服务端也做异步，把 HBase 内核用在流式计算、为 HBase 提供嵌入式的模式。另一方面，尝试更换 HBase 内核，用新的 DB 来替代，达到更高的性能。中翰软件专注数据治理11年http://www.jobhand.cn/