EMR Druid 探索（一）

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 负责索引任务的具体执行

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

• Zookeeper 负责存储集群的状态以及作为服务发现组件，例如集群的拓扑信息，overlord leader 的选举，indexing task 的管理等等
• Coordinator 负责 segments 的管理，如 segments 下载、删除以及如何在 historical 之间做均衡等等。
• Metadata storage 负责存储 segments 的元信息，以及管理集群各种各样的持久化或临时性数据，比如配置信息、审计信息等等

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 的优势在于

1. 实时数据索引与查询
2. 更适合传统数仓领域的结构化数据，相比 ES 更适合半结构化数据
3. 更加方便的数据源接入，包括 Kafka、Flink 等接入数据，与 Hadoop 生态融合更好
4. Range 查询性能更佳

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

Druid 性能

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

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

• 每天处理 1000 亿的事件，100TB 的流式数据
• 超过 100 PB 的原始数据
• 超过 50000 亿的总数据
• 上千用户的每秒查询峰值
• 数万个处理器核