本文根据刘博宇老师在2018年5月11日【第九届中国数据库技术大会】现场演讲内容整理而成。
讲师简介：
刘博宇，滴滴出行高级软件开发工程师，就职于滴滴基础平台大数据架构部。负责Druid集群维护与研发工作。
摘要：
Druid是一款支持数据实时写入、低延时、高性能的OLAP引擎，具有优秀的数据聚合能力与实时查询能力。在大数据分析、实时计算、监控等领域都有特定的应用场景，是大数据基础架构建设中重要的一环。Druid在滴滴承接了包括实时报表、监控、数据分析、大盘展示等应用场景的大量业务，作为大数据基础设施服务于公司多条业务线。本次演讲我们将介绍Druid的核心特性与原理，以及在滴滴内部大规模使用中积累的经验。
分享大纲：
1、Druid特性简介
2、Druid在滴滴的应用
3、Druid平台化建设
4、展望
正文：
一、Druid特性简介
Druid是针对时间序列数据提供的低延时数据写入以及快速交互式查询的分布式OLAP数据库。其两大关键点是：首先，Druid主要针对时间序列数据提供低延时数据写入和快速聚合查询;其次，Druid是一款分布式OLAP引擎。
针对第一个特点来看，Druid与典型的TSDB，比如InfluxDB、Graphite、OpenTSDB的部分特性类似。这些时序数据库具备一些共同特点，一是写入即可查，通过内存增量索引让数据写入便可查询;二是下采样或RDD，通过下采样或类似于RDD的操作减少数据量，而Druid在数据写入时就会对数据预聚合，进而减少原始数据量，节省存储空间并提升查询效率;三是可能会支持Schema less，在InfluxDB中，用户可任意增加tag，InfluxDB可对新增tag进行聚合查询，但Druid在这点上与InfluxDB略有差异，Druid需要预先定义Schema 。Druid的Schema数据打包在最后形成的数据文件中，数据文件按照时间分片，也就是说过去和未来数据的Schema可以不同，而不同schema的数据可以共存。所以，虽然Druid不是schema less的，但是Schema调整也是比较灵活。
另外，Druid作为一个OLAP数据库。OLAP数据库需要支持类似上卷、切块、切片、下钻等操作，但不适合明细查询。对于类似根据某主键ID定位唯一数据的任务，OLAP数据库并不能友好支持。常用的OLAP数据库实现方式以下几种：1)数据检索引擎，比如ES;2)预计算加KV存储实现，比如Kylin;3)SQL on Hadoop 引擎，比如 Presto、SparkSQL。
接下来，我们就以上中实现进行对比。首先是数据检索引擎的代表ES，ES可以存储结构化和非结构化数据，同时具备明细查询和聚合查询能力，由于其自身是一个数据检索引擎，其索引类型并不是针对聚合分析设计的，所以聚合查询方面开销较大;其次，ES不但要保存所有的原始数据，还需要生成较多的索引，所以存储空间开销会更大，数据的写入效率方面会比Druid差一些。
与ES相比，Druid只能处理结构化数据，因为它必须预定义Schema;其次，Druid会对数据进行预聚合以减少存储空间，同时对数据写入和聚合进行优化。但是，由于进行了预聚合，所以Druid抛弃掉了原始数据，导致其缺少原始明细数据查询能力。如果业务方有需求，可以关闭预聚合，但会丧失Druid的优势。
其次是预计算 + kv存储方式 ，KV存储需要通过预计算实现聚合，可以认为Key涵盖了查询参数，而值就是查询结果，由于直接从KV存储进行查询，所以速度非常快。缺点是因为需要在预计算中处理预设的聚合逻辑，所以损失了查询灵活性，复杂场景下的预计算过程可能会非常耗时，而且面临数据过于膨胀的情况;由于只有前缀拼配一种索引方式，所以在大数据量的复杂过滤条件下，性能下降明显;且缺少聚合下推能力。
与预计算+KV存储方式相比，Druid 是使用Bitmap索引的列式存储，查询速度肯定不如KV存储快; 但是由于使用内存增量索引，增量预聚合的模式，写入即可查，无需等待预计算生成Cube，所以实时性更强;其次，Druid可针对任意维度组合过滤、聚合，查询更加灵活;最后，Scatter & Gather模式支持一定的聚合下推。
最后是SQL on Hadoop， 这类引擎的SQL支持通常很强大，且无冗余数据，不需要预处理。缺点是因为其直接通过计算引擎对Hadoop上的文件进行操作，所以响应速度较慢且QPS相对较低。
与SQL on Hadoop方式相比，Druid的SQL支持有限，但在逐渐完善;必须预定义维度指标。其优势在于可达到亚秒级响应，并发较高。