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

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

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

3. 部署情况

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