HBase 作为淘宝全网索引构建以及在线机器学习平台的核心存储系统, 是阿里搜索基础架构的重要组成部分. 本文我们将介绍 HBase 在阿里搜索的历史, 规模, 应用的场景以及在实际应用当中遇到的问题和优化.
HBase 在阿里搜索的历史, 规模和服务能力
历史: 阿里搜索于 2010 年开始使用 HBase, 从最早到目前已经有十余个版本. 目前使用的版本是在社区版本的基础上经过大量优化而成. 社区版本建议不要使用 1.1.2 版本, 有较严重的性能问题, 1.1.3 以后的版本体验会好很多.
集群规模: 目前, 仅在阿里搜索节点数就超过 3000 个, 最大集群超过 1500 个. 阿里集团节点数远远超过这个数量.
服务能力: 去年双十一, 阿里搜索离线集群的吞吐峰值一秒钟访问超过 4000 万次, 单机一秒钟吞吐峰值达到 10 万次. 还有在 CPU 使用量超过 70% 的情况下, 单 CPU core 还可支撑 8000+ QPS.
HBase 在阿里搜索的角色和主要应用场景
很多初学者, 对大数据的概念都是模糊不清的, 大数据是什么, 能做什么, 学的时候, 该按照什么线路去学习, 学完往哪方面发展, 想深入了解, 想学习的同学欢迎加入大数据学习 qq 群: 458345782, 有大量干货 (零基础以及进阶的经典实战) 分享给大家, 并且有清华大学毕业的资深大数据讲师给大家免费授课, 给大家分享目前国内最完整的大数据高端实战实用学习流程体系.
角色: HBase 是阿里搜索的核心存储系统, 它和计算引擎紧密结合, 主要服务搜索和推荐的业务.
HBase 在搜索和推荐的应用流程
如上图, 是 HBase 在搜索和推荐的应用流程. 在索引构建流程中会从线上 MySQL 等数据库中存储的商品和用户产生的所有线上数据通过流式的方式导入到 HBaes 中, 并提供给搜索引擎构建索引. 在推荐流程中, 机器学习平台 Porshe 会将模型和特征数据存储在 HBase 里, 并将用户点击数据实时的存入 HBase, 通过在线 training 更新模型, 提高线上推荐的准确度和效果.
应用场景一: 索引构建. 淘宝和天猫有各种各样的的线上数据源, 这取决于淘宝有非常多不同的线上店铺和各种用户访问.
索引构建应用场景
如上图, 在夜间我们会将数据从 HBase 批量导出, 供给搜索引擎来构建全量索引. 而在白天, 线上商品, 用户信息等都在不停的变化, 这些动态的变化数据也会从线上存储实时的更新到 HBase 并触发增量索引构建, 进而保证搜索结果的实时性.
目前, 可以做到端到端的延时控制在秒级, 即库存变化, 产品上架等信息在服务端更新后, 迅速的可在用户终端搜索到.
索引构建应用场景抽象图
如上图, 整个索引构建过程可以抽象成一个持续更新的流程. 如把全量和增量看做是一个 Join, 线上有不同的数据源且实时处于更新状态, 整个过程是长期持续的过程. 这里, 就凸显出 HBase 和流式计算引擎相结合的特点.
应用场景二: 机器学习. 这里举一个简单的机器学习示例: 用户想买一款三千元的手机, 于是在淘宝按照三千元的条件筛选下来, 但是没有中意的. 之后 , 用户会从头搜索, 这时就会利用机器学习模型把三千块钱左右的手机排在搜索结果的靠前位置, 也就是用前一个搜索结果来影响后一个搜索结果的排序.
分析线上日志
如上图, 分析线上日志, 归结为商品和用户两个纬度, 导入分布式, 持久化消息队列, 存放到 HBase 上. 随线上用户的点击行为日志来产生数据更新, 对应模型随之更新, 进行机器学习训练, 这是一个反复迭代的过程.
HBase 在阿里搜索应用中遇到的问题和优化
HBase 架构分层. 在说问题和优化之前, 先来看 HBase 的架构图, 大致分为如下几个部分:
HBase 的架构图
首先是 API, 一些应用程序编程接口. RPC, 这里把远程过程调用协议分为客户端会发起访问与服务端来处理访问两部分. MTTR 故障恢复, Replication 数据复制, 表处理等, 这些都是分布式管理的范畴. 中间 Core 是核心的数据处理流程部分, 像写入, 查询等, 最底层是 HDFS(分布式文件系统).HBase 在阿里搜索应用中遇到的问题和优化有很多, 下面挑选近期比较重点的 RPC 的瓶颈和优化, 异步与吞吐, GC 与毛刺, IO 隔离与优化, IO 利用这五方面进行展开.
问题与优化一: RPC 的瓶颈和优化
RPC Server 线程模型
PPC 服务端的实际问题是原有 RpcServer 线程模型效率较低, 如上图, 可以看到整个过程通常很快, 但会由不同的线程来处理, 效率非常低. 基于 Netty 重写之后, 可以更高效的复用线程, 实现 HBase RpcServer. 使得 RPC 平均响应时间从 0.92ms 下降到 0.25ms, 吞吐能力提高接近 2 倍.
问题与优化二: 异步与吞吐
RPC 的客户端存在的实际问题是流式计算对于实时性的要求很高, 分布式系统无法避免秒级毛刺, 同步模式对毛刺敏感, 吞吐存在瓶颈. 优化手段就是基于 netty 实现 non-blocking client, 基于 protobuf 的 non-blocking Stub/RpcCallback 实现 callback 回调, 当和 flink 集成后实测吞吐较同步模式提高 2 倍.
问题与优化三: GC 与毛刺
如上图, 这部分的实际问题是 PCIe-SSD 的高 IO 吞吐能力下, 读 cache 的换入换出速率大幅提高, 堆上的 cache 内存回收不及时, 导致频繁的 CMS gc 甚至 fullGC. 优化手段是实现读路径 E2E 的 offheap, 使得 Full 和 CMS gc 频率降低 200% 以上, 读吞吐提高 20% 以上.
如上图, 是线上的一个结果, QPS 之前是 17.86M, 优化之后是 25.31M.
问题与优化四: 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 利用
HDFS 写 3 份副本, 通用机型有 12 块 HDD 盘, SSD 的 IO 能力远超 HDD. 如上图, 实际问题是单 WAL 无法充分使用磁盘 IO.
如上图, 为了充分利用 IO, 我们可以通过合理映射对 region 进行分组, 来实现多 WAL. 基于 Namespace 的 WAL 分组, 支持 App 间 IO 隔离. 从上线效果来看, 全 HDD 盘下写吞吐提高 20%, 全 SSD 盘下写吞吐提高 40%. 线上写入平均响应延时从 0.5ms 下降到 0.3ms.
开源 & 未来
为什么要拥抱开源? 其一, 试想如果大家做了优化都不拿出来, 认为这是自己强于别人的优势, 结果会怎样? 如果大家把自己的优势都拿出来分享, 得到的会是正向的反馈. 其二, HBase 的团队一般都比较小, 人员流失会产生很大的损失. 如把内容贡献给社区, 代码的维护成本可以大大降低. 开源一起做, 比一个公司一个人做要好很多, 所以我们要有贡献精神.
未来, 一方面, 阿里搜索会进一步把 PPC 服务端也做异步, 把 HBase 内核用在流式计算, 为 HBase 提供嵌入式的模式. 另一方面, 尝试更换 HBase 内核, 用新的 DB 来替代, 达到更高的性能. 很多初学者, 对大数据的概念都是模糊不清的, 大数据是什么, 能做什么, 学的时候, 该按照什么线路去学习, 学完往哪方面发展
来源: http://www.jianshu.com/p/945197e0d17e