您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
HBase 在阿里搜索中的应用实践
 
作者:李钰 来源:www.sohu.com 发布于:2017-7-14
203 次浏览     评价:      
 

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并触发增量索引构建,进而保证搜索结果的实时性。

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

索引构建应用场景抽象图

整个索引构建过程可以抽象成一个持续更新的流程。如把全量和增量看做是一个 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 来替代,达到更高的性能。

   
 订阅
  捐助
相关文章

我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
 
相关文档

数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
相关课程

高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号