EMR Druid 探索（一）

什么是 Druid、Druid 使用场景

Druid 是 Metamarkets 公司（一家为在线媒体或广告公司提供数据分析服务的公司）推出的一个分布式内存实时分析系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。现今有一些非常热的 SQL on Hadoop 解决方案或者基于传统数据库技术的 MPP 方案，前者比如 Hive、Impala、Spark SQL、Presto 等，后者比如 Greenplum。这些方案的查询响应速度往往与数据集的规模成正比，查询时延从秒级到天级不等。这对于想要快速验证想法的业务人员来说是个极大的问题。与这些系统不同，Druid 通过预先聚合一些维度来换取速度，查询时延可以控制在秒亚秒级到秒级。这非常适合那些业务数据维度比较固定，又对查询时延要求非常高的场景，比如

实时指标监控

推荐模型

广告平台

搜索模型

这些场景的特点都是拥有大量的数据，且对数据查询的时延要求非常高。例如在广告程序化交易中，广告平台的出价策略来源于广告流量数据的分析，整个过程要求实时，因为市场变动很快，根据第一天的流量计算第二天的出价是没有意义的，这里的联动需要做到秒级。实时指标监控类似，在一些重要的场合，系统问题需要在出现的一刻被检测到并被反馈随后被解决。在推荐系统或者用户行为分析系统中，模型需要在多个维度分析数据提炼用户行为，并及时更新到线上系统。

Druid 特点

亚秒级 OLAP 查询，包括多维过滤、ad-hoc 的属性分组、快速聚合数据等等

实时的数据消费，真正做到数据摄入实时、查询结果实时

高效的多租户能力，最高可以做到几千用户同时在线查询

扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发

极高的高可用保障，支持滚动升级

其中最为亮眼的是第一条与第二条。开源界能够同时做到两者的系统或解决方案并不多见，主要竞争者有 LinkedIn 公司的 Pinot，eBay 公司的 Kylin，以及 Elasticsearch 等。我们下文有专门的对比。

Druid 架构

下图是 Druid 工作层（数据索引以及查询）包含的组件。其中，

Realtime 组件负责数据的实时摄入

Broker 阶段负责查询任务的分发以及查询结果的汇总，并将结果返回给用户

Historical 节点负责索引后的历史数据的存储。数据存储在 deep storage。deep storage 可以是本地，也可以是 HDFS 等分布式文件系统

Indexing service 包含两个组件（图中未画出）
- Overlord 组件负责索引任务的管理、分发
- MiddleManager 负责索引任务的具体执行

working-laryer

下图是 Druid segments（Druid 索引文件）管理层所涉及的组件。其中

Zookeeper 负责存储集群的状态以及作为服务发现组件，例如集群的拓扑信息，overlord leader 的选举，indexing task 的管理等等

Coordinator 负责 segments 的管理，如 segments 下载、删除以及如何在 historical 之间做均衡等等。

Metadata storage 负责存储 segments 的元信息，以及管理集群各种各样的持久化或临时性数据，比如配置信息、审计信息等等

manage-laryer

Druid 与 Pinot、Kylin 对比

三者均是基于预计算换取查询时延。Druid 与 Pinot 是比较类似的，Kylin 是另外一种。Kylin 实际上是一个预聚合生成 cube 的一个系统。它的数据导入并不是实时的，需要设置定时任务做聚合计算，生成 cube，因此它本质上是一个 cube 生成与管理系统。cube 是一个数据的多维立方体，当维度增多之后 cube 体积会迅速增大。但是在不同的维度间切换视角、或是执行上卷、下钻等操作会非常省时。

Druid 与 Pinot 都是 lambda 架构，既可以通过批处理历史数据，又可以通过流实时处理数据。下表列出了两者在主要维度上的对比

	Pinot	Druid
发起者	LinkedIn	MetaMarkets
发布年份	2015	2011
架构	lambda 架构	lambda 架构
存储方式	列存	列存
索引类型	inverted/start tree/bitmap	inverted
消费数据格式	avro/csv/json(historical), Kafka(realtime)	json/csv/tsv/regex(any custom data format), stream(rest), Kafka
组件管理	Zookeeper+Helix	Zookeeper
文档支持	一般	好
SQL 支持	PQL	Druid SQL
JDBC	不支持，但其java api 类似于jdbc	通过 avatica jdbc driver 支持

Druid 与 Elasticsearch 对比

Elasticsearch (ES) 是一个基于 Lucenen 的搜索引擎系统，原先主要应用于搜索领域，后来加入了聚合等特性，支持了更多的查询类型，从而变成了一个 NoSQL 的数据库。它是从搜索引擎而来，因此具有一些搜索引擎所具有的特点，同时由于其基于搜索的设计，也导致了一些场景下的短板。

ES 的优点主要在于

可以处理海量的数据同时查询时延得到保证 这一点与搜索引擎是类似的

支持全文检索 这一点对于文档型数据非常重要，对于这一类型数据，ES 可以说非常适合

支持聚合查询 通过 ES 提供的聚合接口，用户可以实现多维度的聚合查询

支持明细查询 ES 存储了原始文档的正排信息，查询后可以将原始文档原文输出

支持join join 是很多场景不可避免的，也是很多实时分析系统（如 Druid、Kylin）不具备的，因此支持 join 就是一个很大的优势

良好的扩展性和高可用 不同于 Hadoop 生态系统的很多 master-slave 架构，ES 各节点是全同的，只是在运行时会有一个节点被选举出来做 leader 做一些轻量化的工作。当一个 leader 挂掉后，另外一个就会选举出来

提供了ELK一体化工具 这是一个日志分析场景的一套工具，Logstash 负责数据接入，ES 负责数据分析，Kibana 负责数据展现

Schema free 数据可以事先不定义 schema 导入 ES，ES 会自动生成 schema，本质上仍然属于 “schema on write”。

ES 的缺点有

数据导入非实时 ES 不支持实时索引，但是 ES 支持近实时索引作为弥补。

数据膨胀 相对于原始文档，默认配置下 ES 索引后数据是膨胀的，ES 存储了文档的倒排信息和正排信息，有时还要存储文档本身。

不支持SQL ES 官方目前没有支持，其查询语言是一套自定义的 DSL。

Range 查询性能较差 这是由其技术基础决定的

Druid 与 ES 是两种技术上完全不同的方案。前者基于数据的预计算换取查询时延，后者则是完全基于倒排索引。Druid 相对于 ES 的优势在于

实时数据索引与查询

更适合传统数仓领域的结构化数据，相比 ES 更适合半结构化数据

更加方便的数据源接入，包括 Kafka、Flink 等接入数据，与 Hadoop 生态融合更好

Range 查询性能更佳

由于两者都具有鲜明的特点，因此针对具体场景选择哪种方案就不存在什么选择困难。对于半结构化的日志分析，ELK 可能更好一些。对于结构化的数据又有实时性的要求的话，Druid 是更好的选择。

Druid 性能

Druid 具有高超的性能。主要体现在：一，很高的水平扩展能力，能够处理极大的数据集；二，预聚合带来的自然加速优势；三，基于内存的计算保证了计算的速度；四，从 deep storage 到磁盘再到内存形成了一个多级缓存架构，热数据能够快速被处理。

下表列出了 Metamarkets 公司 Druid 集群的一些性能指标

每天处理 1000 亿的事件，100TB 的流式数据

超过 100 PB 的原始数据

超过 50000 亿的总数据

上千用户的每秒查询峰值

数万个处理器核