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

Posted 2020-09-04 博文视点

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

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

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

场景一：小米统计服务

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

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

　　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年。每天晚上的时候，聚合小时级别的数据，这样可以避开高负载的集群时间。聚合粒度与查询效率的关系如下。
　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　聚合粒度与查询效率的关系

3. 部署情况

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

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

　　本文选自《Druid实时大数据分析原理与实践》，点此链接可在博文视点官网查看此书。
　　　　　　　　　　　　　　　　　　　　
　　想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。