兑吧：从自建HBase迁移到阿里云HBase实战经验

摘要： 业务介绍 兑吧集团包含兑吧网络和推啊网络，兑吧网络是一家致力于帮助互联网企业提升运营效率的用户运营服务平台，提供积分商城和媒体运营服务。推啊网络是一家互动式广告平台，经过多年的探索与实践，首创了全新的移动广告模式，实现了广告主、媒体、用户多方共赢。

业务介绍
兑吧集团包含兑吧网络和推啊网络，兑吧网络是一家致力于帮助互联网企业提升运营效率的用户运营服务平台，提供积分商城和媒体运营服务。推啊网络是一家互动式广告平台，经过多年的探索与实践，首创了全新的移动广告模式，实现了广告主、媒体、用户多方共赢。在推啊的广告场景中，广告主可获得更好的投放效果，媒体方能得到更好的流量变现效率，受众端具有更好的用户体验，目前推啊已经服务超过15000家媒体，阿里云hbase主要服务于"推啊"的广告业务。

"推啊"的整体业务流程如下图：

整体产品架构
广告平台基础架构完善，能有效支持业务，其中核心数据平台为公司所有业务提供强有力的数据支撑。其中整个数据平台根据处理业务不同大致分为3个模块：

离线统计模块：对数据进行离线统计，提供报表和相应的后台数据分析
实时统计模块：实时数据主要用来对接算法，用于统计用户的实时行为，比如对不同广告的曝光，点击等行为，要求快速计算响应，所以我们采用低延迟的流式计算
实时OLAP分析模块：多维实时分析，定位是提供分钟粒度的统计数据，主要用于任意维度和指标的统计
HBase在"推啊"使用场景
HBase在推啊主要用于流式数据统计，存储用户画像的相关数据，属于实时统计模块中主要存储。
实时统计时，对用户的行为数据根据不同维度不同指标进行统计，比如会记录用户在不同广告上的曝光，点击，参与等数据，也会记录用户的相应属性，比如用户对哪类广告比较感兴趣，用户的年龄，性别，职业，爱好等特征。这些数据全部存储在HBase集群中。

为什么从物理HBase迁移到阿里云HBase
最开始我们是物理机房自建HBase，选择阿里云HBase主要出于以下几个考虑：

云HBase服务基本免运维。减轻运维和系统调优压力，由阿里云hbase专家团队提供专业的运维服务。
HBase基础设施重要性高。HBase作为底层存储系统，一旦出现系统故障，排查周期长，难度高，短时间内难以解决，直接影响到线上系统的稳定性，在这方面阿里云Hbase能提供强大的技术支撑，阿里云有国内最强大的内核团队，据了解阿里目前有3个pmc，6个committer，是中国拥有最多HBase committer的公司。
云HBase服务好。在使用Hbase上有任何疑问都可以直接咨询阿里云Hbase同学，他们响应及时，服务周到，能给出专业的建议。
整个迁移实战过程
根据我们业务的发展，从3个阶段阐述下阿里云hbase的使用情况以及遇到的问题

阶段一：承担数据集市作用，分解业务访问压力
这个阶段我们的数据中心是搭建在自己的IDC机房里，使用CDH 的hadoop来搭建的集群，所有的组件包括hive，JStorm，Druid等都安装在一个集群里，JStorm计算时会使用hadoop自带的HBase用来计算和统计数据，计算完成后，会将成品数据写入到阿里云的HBase上，业务系统会访问阿里云的HBase来获取计算好的数据，这样做的原因主要从2个方面考虑：

业务系统使用的是阿里云的ecs服务器，和IDC机房是通过专线连通的，跨公网传输，占用带宽，网络质量无法保证。
不希望业务系统直接访问IDC机房中的HBase集群，主要是担心并发高，会拉高整个集群的负载，影响到集群中的其它业务。
这个阶段的HBase配置是4核8G 2节点 100G 4 2 SSD，大概同步20%的业务数据给线上系统使用， 数据量大概在200G左右，查询QPS在500左右，单条查询平均耗时在2ms
阶段二：全面迁移，云HBase替换线下物理机HBase
这阶段我们将IDC的hadoop集群迁移到阿里云上，新买了阿里云的HBase集群用来替换原先CDH中的HBase集群。IDC机房迁移到阿里云主要基于以下几点来考虑：

IDC机房里因为所有的组件都部署在相同服务器上，会导致资源间相互竞争，各组件运行相互影响的情况，对组件所使用的资源进行隔离，但发现效果不理想。
我们核算了下，发现在5年内IDC自建机房的费用比用阿里云的服务器要贵很多。
迁移到阿里云后，我们所有的系统和服务都处于同一个内网环境，网络质量要比原先的走公网专线更有保障。
这个阶段hbase的配置是8核32G 4节点 200G 4 4 SSD存储，预估支撑20万的qps访问，目前大概存储了600G数据，集群的qps在峰值时能达到10万左右。

阶段三：优化改造，保障极致读取时延
由于HBase基于java虚拟机原生机制问题，业务系统在读取HBase数据时，由于GC会导致读取抖动到100-200ms，对于广告推荐系统来说，一次广告推荐要求在200ms内完成，这样的抖动显然是不能接受的，咨询过阿里云HBase同学后，我们对系统进行了如下改造：

业务上增加延迟控制，读取HBase超过100ms，直接断开，业务上走降级方式，随机推荐广告。
业务拆分，新买一个HBase集群，只开放给对延迟要求高的业务使用。将一些对延迟要求高的业务迁移过去，迁移后，延迟抖动从原先的千分之二，降低到万分之六，延迟情况得到改善。
另外据阿里HBase的同学介绍，阿里云近期会推出的HBase 2.0，在架构级别做了优化，会从根本上解决由于Java GC机制导致的延迟抖动，非常期待。

总结
总体来说，阿里云HBase是非常优秀的。也感谢阿里云技术同学，帮我们解决了底层系统的运维和性能调优，保证了底层系统的稳定，使我们可以更加专注的服务业务，帮助业务发展的更快。
原文链接