返回 登录
4

Druid 在小米公司部分技术实践

阅读3705

引言:Druid作为一款开源的实时大数据分析软件,自诞生以来,凭借自己优秀的特质,不仅逐渐在技术圈收获了越来越多的知名度与口碑,并且陆续成为了很多技术团队解决方案中的关键一环,从而真正在很多公司的技术栈中赢得了一席之地。
   本文通过对小米公司技术团队对Druid 的实践案例与经验的介绍,让大家对Druid有更加全面和深入的了解,希望能够帮助你事半功倍地学习Druid 这项年轻的技术。
   本文选自《Druid实时大数据分析原理与实践》。

  小米公司正式成立于2010 年4 月,是一家专注于高端智能手机、互联网电视以及智能家居生态链建设的创新型科技企业。
  “让每个人都能享受科技的乐趣”是小米公司的愿景。小米公司应用互联网模式开发产品,用工匠精神做产品,用互联网模式节省了中间环节,致力于让全球每个人都能享用来自中国的优质科技产品。
           [图1
                     小米大云平台技术架构示意图

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

场景一:小米统计服务

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

  实时的数据分析重要需求,在产品发展过程中,也经历了几个技术阶段,这几个阶段并非完全互斥,而是应用于不同的场景和时间。
  第一阶段:数据存储在Hadoop 中,通过MapReduce 的脚本进行分析和处理。有一部分复杂的任务会以天为单位被执行,并且最后会将结果写入到如MySQL 的RDBMS 中。
  第二阶段:在业务发展过程中MySQL 很快变成了瓶颈,有两个原因,一是数据库的Schema 更改成本高,新业务不断需要增加新列和新表,流程烦琐而且需要进行Schema 设计;二是在进行大量写操作的情况下,数据库的负载增加会导致数据库的读性能下降,而且偶尔有死锁的现象。为了解决这些问题,引入了HBase 作为主要存储数据库,利用HBase 的列族,方便增加数据列。另外,HBase 的可用性也高于MySQL。
  第三阶段:为了改进数据的实时性,后期增加了Storm 分布式计算模式,使用Storm 可以方便地进行各种复杂的数据处理,各种聚合和处理需要通过程序实现,增加一个数据维度,改动比较大,需要从上游到下游整体修改。这种方式的优点是可靠性好,数据处理能力强,可以进行各种角度的优化。
  第四阶段:小米统计的很多数据查询都是选择一些指标和过滤条件,很多场景类似于传统的数据仓库,因此引入Druid 处理一些标准报告的实时数据查询场景。数据流会依次通过Kaa 和Tranquility,最后进入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年。每天晚上的时候,聚合小时级别的数据,这样可以避开高负载的集群时间。聚合粒度与查询效率的关系如下。
            【图4】
                       聚合粒度与查询效率的关系

3. 部署情况

  Druid 集群每天处理近百亿的事件请求,集群规模为近10 台机器,索引服务和历史节点数量相当,机器的数量随着事件数的增长而增加。当数据源在某时间数据急剧增加时,系统索引文件所占用的CPU 会很高,有时候影响正常的查询性能。
  第一阶段,我们尝试在服务层使用流量控制,但是后来放弃了。原因是,数据在1 小时后会有过期机制,因此如果有数据无法进入系统,那么这些数据可能丢失。因此,我们还是尽量让数据进入Druid 系统,虽然偶尔会带来系统的峰值压力。
基于Druid 的架构和数据流如下。
             【图5】
                       基于Druid 的架构和数据流

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

  本文选自《Druid实时大数据分析原理与实践》,点此链接可在博文视点官网查看此书。
                    图片描述

评论