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 | |
|---|---|---|
| 发起者 | 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 亿的总数据
- 上千用户的每秒查询峰值
- 数万个处理器核
