Druid 在小米公司的技术实践

小编说:自Druid 诞生以来,它凭借着自己优秀的特质,不仅逐渐在技术圈收获了越来越多的知名度与口碑,并且陆续成为了很多技术团队解决方案中的关键一环,从而真正在很多公司的技术栈中赢得了一席之地。

在成为Druid 用户的公司中不乏很多国外赫赫有名的互联网企业,也包含了很多国内同样声名遐迩的知名公司,同时也覆盖了许多朝气蓬勃的创业团队。本文通过对小米公司技术团队对Druid 的实践案例与经验的介绍,让大家对Druid 有更加全面和深入的了解,希望能够帮助你事半功倍地学习Druid 这项年轻的技术。

本文选自《Druid实时大数据分析原理与实践》

小米公司正式成立于2010 年4 月,是一家专注于高端智能手机、互联网电视以及智能家居生态链建设的创新型科技企业。

“让每个人都能享受科技的乐趣”是小米公司的愿景。小米公司应用互联网模式开发产品,用工匠精神做产品,用互联网模式节省了中间环节,致力于让全球每个人都能享用来自中国的优质科技产品。

Druid 在小米公司的技术实践_第1张图片
小米大云平台技术架构示意图

Druid 在数据分析层帮助实时收集海量的事件数据,快速进行商业分析,在多个场景中都有应用。这里介绍Druid 在小米统计产品和小米广告平台中的部分技术实践。

场景一:小米统计服务

小米统计是小米为App 开发者提供的移动应用数据统计服务,帮助开发者通过数据了解应用发展状况、渠道推广效果和用户参与情况等信息,使开发者可以更好地优化体验和运营,促进产品不断发展进步。小米统计的入口是tongji.xiaomi.com,服务界面如下。


Druid 在小米公司的技术实践_第2张图片
小米统计服务界面

实时的数据分析重要需求,在产品发展过程中,也经历了几个技术阶段,这几个阶段并非完全互斥,而是应用于不同的场景和时间。

第一阶段:数据存储在Hadoop 中,通过MapReduce 的脚本进行分析和处理。有一部分复杂的任务会以天为单位被执行,并且最后会将结果写入到如MySQL 的RDBMS 中。

第二阶段:在业务发展过程中MySQL 很快变成了瓶颈,有两个原因,一是数据库的Schema 更改成本高,新业务不断需要增加新列和新表,流程烦琐而且需要进行Schema 设计;二是在进行大量写操作的情况下,数据库的负载增加会导致数据库的读性能下降,而且偶尔有死锁的现象。为了解决这些问题,引入了HBase 作为主要存储数据库,利用HBase 的列族,方便增加数据列。另外,HBase 的可用性也高于MySQL。

第三阶段:为了改进数据的实时性,后期增加了Storm 分布式计算模式,使用Storm 可以方便地进行各种复杂的数据处理,各种聚合和处理需要通过程序实现,增加一个数据维度,改动比较大,需要从上游到下游整体修改。这种方式的优点是可靠性好,数据处理能力强,可以进行各种角度的优化。

第四阶段:小米统计的很多数据查询都是选择一些指标和过滤条件,很多场景类似于传统的数据仓库,因此引入Druid 处理一些标准报告的实时数据查询场景。数据流会依次通过Kaa 和Tranquility,最后进入Druid 集群。Druid 集群最终能提供最近一天的数据查询功能,并且允许用户直接访问。

Druid 在小米公司的技术实践_第3张图片
小米统计数据流

Druid 作为一种实时分析数据库,提升了小米大数据平台和商业产品部门的实时数据分析能力。

场景二:广告平台实时数据分析

Druid 来源于广告业务,小米广告平台也利用Druid 进行实时的数据分析,帮助实时分析线上的各种维度的变化,包括上线部署的实时监控分析、A/B 测试的效果查询、一些细粒度的数据分析。

对广告数据有两条路径进行处理:一条是实时的数据流,通过Druid 处理,主要是针对内部的实时数据分析需求;另一条是通过Mini-batch 方式。

数据的DataSource(数据源)包括:

• 小米广告交易平台(Xiaomi Ad Exchange, MAX):广告流量的调度管理平台。

• 广告平台的计费分析模块:广告主的计费、各种维度数据。

• 广告媒体分析数据:各个广告媒体的请求、展现等数据。

比如对于广告计费分析模块,Druid 会包括实时的广告主计费信息,这些数据用于内部的数据分析,不用于广告主投放平台。广告主投放平台使用Mini-batch 方式,通过可重放的方式更新和聚合数据结果。

在使用Druid 的过程中也会碰到一些问题。

1. 关于查询界面

Druid 的查询语言还不是特别友好,在第一阶段部署Druid 后,我们开发了一套Druid查询接口,主要是满足业务的需求,初期效果还好,但是随着数据源的增加,每次增加数据源都需要额外开发一些界面,增加维度,也需要修改前端工程,因此效率也不高。在后期的工作中,尝试了Pivot 工具,功能使用方便,渐渐代替了自定义的查询界面。

2. 关于查询效率

Druid 的大部分时间性能表现都很好,但是如果进行长时间范围的查询,系统会变得非常慢。为了解决这个问题,对于频繁查询的数据源,可以分为两个部分:一部分是按照分钟级别聚合的数据源,数据保持10 天;另一部分是按照小时级别聚合的数据源,数据保持2年。每天晚上的时候,聚合小时级别的数据,这样可以避开高负载的集群时间。聚合粒度与查询效率的关系如下。

Druid 在小米公司的技术实践_第4张图片
聚合粒度与查询效率的关系

3. 部署情况

Druid 集群每天处理近百亿的事件请求,集群规模为近10 台机器,索引服务和历史节点数量相当,机器的数量随着事件数的增长而增加。当数据源在某时间数据急剧增加时,系统索引文件所占用的CPU 会很高,有时候影响正常的查询性能。

第一阶段,我们尝试在服务层使用流量控制,但是后来放弃了。原因是,数据在1 小时后会有过期机制,因此如果有数据无法进入系统,那么这些数据可能丢失。因此,我们还是尽量让数据进入Druid 系统,虽然偶尔会带来系统的峰值压力。

基于Druid 的架构和数据流如下。

Druid 在小米公司的技术实践_第5张图片
基于Druid 的架构和数据流

“纸上得来终觉浅,绝知此事要躬行”,如同学习其他技术一样,掌握Druid 最好的方法就是实践,因此大家在对Druid 有了一定的认识后应该尽快上手练习,并且争取早日将其应用到自己的实际工作中,在战斗中学习战斗,让在实践中碰到的问题驱动自己对Druid 技术的学习和理解。

《Druid实时大数据分析原理与实践》

《Druid实时大数据分析原理与实践》

腾讯、小米、优酷、云测等互联网公司的一线实践经验,为你解读海量实时OLAP平台!

作者:欧阳辰、刘麒赟、张海雷、高振源 等 著

2017年3月出版 定价:79.00元

购买链接:京东

你可能感兴趣的:(Druid 在小米公司的技术实践)