Apache Druid 是一个分布式内存实时分析系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析的问题。Apache Druid 由 Metamarkets 公司（一家为在线媒体或广告公司提供数据分析服务的公司）开发，在2019年春季被捐献给 Apache 软件基金会。

基本特点

Apache Druid 具有以下特点：

• 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
• 实时的数据消费，真正做到数据摄入实时、查询结果实时。
• 高效的多租户能力，最高可以做到几千用户同时在线查询。
• 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
• 极高的高可用保障，支持滚动升级。

应用场景

实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：

• 实时指标监控
• 推荐模型
• 广告平台
• 搜索模型

这些场景的特点都是拥有大量的数据，且对数据查询的时延要求非常高。在实时指标监控中，系统问题需要在出现的一刻被检测到并被及时给出报警。在推荐模型中，用户行为数据需要实时采集，并及时反馈到推荐系统中。用户几次点击之后系统就能够识别其搜索意图，并在之后的搜索中推荐更合理的结果。

Apache Druid 架构

Apache 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 的元信息，以及管理集群各种各样的持久化或临时性数据，例如配置信息、审计信息等等。

E-MapReduce 增强型 Druid

E-MapReduce Druid 基于Apache Druid 做了大量的改进，包括与E-MapReduce和阿里云周边生态的集成、方便的监控与运维支持、易用的产品接口等等，真正做到了即买即用和 7*24 免运维。

E-MapReduce Druid 目前支持的特性如下所示：

• 支持以 OSS 作为 deep storage。
• 支持将 OSS 文件作为批量索引的数据来源。
• 支持从日志服务（Log Service）流式地索引数据（类似于 Kafka），并提供高可靠保证和 exactly-once 语义。
• 支持将元数据存储到 RDS。
• 集成了 Superset 工具。
• 方便地扩容、缩容（缩容针对 task 节点）。
• 丰富的监控指标和告警规则。
• 坏节点迁移。
• 具有高安全性。
• 支持 HA。

一，Druid介绍

Apache Druid是一个实时分析数据库，旨在对大型数据集进行快速切片和分析（“OLAP”查询）。Druid最常用作支持实时接收、快速查询性能和高正常运行时间的用例的数据库。因此，Druid通常用于支持分析应用程序的gui，或者作为需要快速聚合的高度并发api的后端。
OLAP(Online analytical processing)，即联机分析处理。

二，Druid特点：

1，列存储格式。
2，可扩展分布式系统，Druid通常部署在大数集群中，水平扩展能力强。
3，大规模并行处理。Druid可以跨整个集群并行处理一个查询。
4，实时或批量数据导入。Druid可以实时（摄取的数据可以立即用于查询）或成批地摄取数据。
5，自我修复，自我平衡，易于操作。添加或删除服务器，集群将在后台自动重新平衡，而不需要停机。
6，不会丢失数据。一旦Druid接收了您的数据，一个副本就安全地存储在深存储中（通常是HDFS）。
7，支持索引。
8，时序数据库，基于时间分区。
9，预聚合。Druid在数据摄入时可以做一些聚合操作，节省存储空间，提高性能。

三，Druid适合使用场景：

1，插入率非常高，但更新不太常见（最好不更新）。
2，大多数查询是聚合和报告查询（“分组依据”查询）。
3，查询延迟低，为100毫秒到几秒钟。
4，数据需要针对时间进行优化。
5，您可能有多个表，但每个查询只命中一个大的分布式表。查询可能会命中多个较小的“查找”表。
6，快速统计数据。

四，Druid不适合使用场景：

1，对现有记录进行低延迟更新。Druid支持流式插入，但不支持流式更新（更新是使用后台批处理作业完成的）。
2，需要执行join操作。

五，datasource and segment

Datasource：

相当于关系型数据库中的表名。
每一个datasource都被时间划分为chunk（块），比如说按天划分（也有可能会被其它属性进一步划分）。每一个chunk中会包含一个或者多个segment（段）。

"segmentGranularity": "day”

segment：

用于存储数据。
特点:
1,列式存储。每个列单独存储，读取数据时只需要读取需要的列不需要读取整条数据。
2,列分为三种类型
timestamp column （时间戳列）
单位：

iso: ISO8601 with 'T' separator, like "2000-01-01T01:02:03.456"
posix: seconds since epoch
millis: milliseconds since epoch
micro: microseconds since epoch
nano: nanoseconds since epoch
auto: automatically detects ISO (either 'T' or space separator) or millis format
any Joda DateTimeFormat string
    

dimension columns（纬度列）

单位：

string, long, float, or double.

默认单位是string，其它单位需要明确说明，格式：{“name”: “page”, “type”: “double”}。string类型的默认会创建bitmap，其它类型不能创建。

metric columns（度量列）
针对特定列进行预聚合运算

"metricsSpec": [
  { "type": "count", "name": "count" },
  { "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" },
  { "type": "doubleSum", "name": "bytes_deleted_sum", "fieldName": "bytes_deleted" }
]

type：聚合类型
name：聚合结果列名
fieldName：针对的列

segment命名规则：

datasource_intervalStart_intervalEnd_version_partitionNum
dataSourceName_开始时间_截止时间_版本好_分区号

备注： segmentname反应到文件系统中是一个文件夹名字，没有分区的话就没有分区号，时间都是0时区，北京时间是东八区，比0时区早八小时。

sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0
sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_1
sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_2

对一个时间区间内所有的segments更新是原子操作，全部写成功后查询才会读取高版本数据。多个时间区间之间的更新操作不是原子操作，更新数据时最好不要跨区间。更新成功后低版本数据会很快被清理。

segment文件大小规划

建议1:每个segment文件大小在300MB-700MB范围内。
建议2:每个segment文件建议包含的数据条数为500万条。

建议2 优先于建议1 ，指定数据条数能直接控制查询时一个线程处理的数据量。

查询数据的时候，历史数据节点中每个线程负责查询一个segment，如果segment太大不利于查询的并行度；如果segment太小，线程池中线程之间的调度会花费大量额外时间。

下一篇: Druid服务介绍

Druid的由来

随着大数据分析需求的爆炸性增长，很多公司都经历过将以关系型商用数据库为基础的数据平台，转移到一些开源生态的大数据平台，例如Hadoop 或Spark 平台，以可控的软硬件成本处理更大的数据量。Hadoop 设计之初就是为了批量处理大数据，但数据处理实时性经常是它的弱点。例如，很多时候一个MapReduce 脚本的执行，很难估计需要多长时间才能完成，无法满足很多数据分析师所期望的秒级返回查询结果的分析需求。为了解决数据实时性的问题，大部分公司都有一个经历，将数据分析变成更加实时的可交互方案。其中，涉及新软件的引入、数据流的改进等。数据分析的几种常见方法如下图。

大数据分析的发展路程：

1. 使用Hadoop/Spark 的MR 分析。
2. 将Hadoop/Spark 的结果注入RDBMS 中提供实时分析。
3. 将结果注入到容量更大的NoSQL 中，例如HBase 等。
4. 将数据源进行流式处理，对接流式计算框架，如Storm，结果落在RDBMS/NoSQL 中。
5. 将数据源进行流式处理，对接分析数据库，例如Druid、kyllin 等。

Druid的特点

Druid 具有如下技术特点。

• 数据吞吐量大。

• 支持流式数据摄入和实时。

• 查询灵活且快。

• 社区支持力度大。

Druid的架构

架构预览

Druid本身包含以下四个节点和一个服务

1. 实时节点(RealTime Node) 即时摄入实时数据，并且生成Segment文件
2. 历史节点(Historical Node)加载已经生成好的数据文件，以供数据查询使用
3. 查询节点(Broker Node) 对外提供数据查询服务，并且从实时节点和历史节点汇总数据，合并后返回
4. 协调节点(Coordinator Node)负责历史节点的数据的负载均衡，以及通过规则管理数据的生命周期
5. 索引服务(Indexing Service)有不同的获取数据的方式，更加灵活的生成segment文件管理资源。

数据结构

与Druid架构相辅相成的是基于DataSource和Segment的数据结构。

DataSource的结构：与传统的关系型数据库相比较DataSource可以理解为表，包含下面几点

• 时间列 表明每行数据的时间值
• 维度列 表明数据的各个维度信息
• 指标列 需要聚合的列的数据

Segment 结构：Datasource是指的逻辑概念，Segment指的是实际的物理存储格式，Druid通过Segment实现了横纵向切割操作。Druid将不同的时间范围内的数据存放在不同的Segment文件块中，通过时间实现了横向切割，同时，Segment也面向列进行数据压缩存储，这边是纵向切割。

架构详情

实时节点

实时节点主要负责即时摄入实时数据，以及生成Segment文件。

实时节点通过firehose进行数据的摄入，firehose是Druid实时消费模型。比如通过kafka消费，就是kafkaFireHose。 同时，实时节点的另外一个模块Plumer，用于Segment的生成，并且按照指定的周期，将本周期内生成的所有数据块合并成一个

Segment文件从制造到传播要经历一个完整的过程。

1. 实时节点生产出Segment文件，并且存到文件系统中。
2. Segment文件的MetaStore存放到Mysql等其他外部数据库中
3. Master通过Mysql中的MetaStore，通过一定的规则，将Segment分配给属于它的节点。
4. 历史节点得到Master发送的指令后会从文件系统中拉取属于自己的Segment文件，并且通过zookeeper，告知集群，自己提供了此块Segment的查询服务
5. 实时节点丢弃Segment文件，并且声明不在提供此块文件的查询服务
   

历史节点

历史节点再启动的时候，会优先检查自己的本地缓存中是否已经有了缓存的Segment文件，然后从文件系统中下载属于自己，但还不存在的Segment文件，无论是何种查询，历史节点首先将相关的Segment从磁盘加载到内存。然后在提供服务。

可以看出，历史节点的查询效率受内存空间富余成都的影响很大，内存空间富余，查询时需要从磁盘加载数据的次数减少，查询速度就快，反之，查询时需要从磁盘加载数据的次数就多，查询速度就相对较慢，因此，原则上历史节点的查询速度与其内存大小和所负责的Segment数据文件大小成正比关系

查询节点

在常规情况下，Druid集群直接对外提供查询的节点只有查询节点，而查询节点会将从实时节点与历史节点查询到的数据合并后返回给客户端，因此查询节点便是整个集群的查询中枢。

Druid使用了Cache机制来提高自己的查询效率。Druid立功了两类介质作为Cache以供选择，

• 外部cache，比如Memcached
• 内部Cache，比如查询节点或历史节点的内存

如果用查询节点的内存作为Cache，查询的时候会首先访问其Cache，只有当不命中的时候才会去访问历史节点和实时节点查询数据

协调节点

对于整个Druid集群来说。其实并没有真正意义上的Master节点，因为实时节点与查询节点能自行管理并不听命于任何其他节点，但是对于历史节点来说，协调节点便是他们的Master，因为协调节点将会给历史节点分配数据，完成数据分布在历史节点之间的负载均衡。历史节点之间是相互不进行通讯的，全部通过协调节点进行通讯。

利用规则管理数据的生命周期：Druid利用针对每个DataSoure设置的规则来加载或者丢弃具体的文件数据，来管理数据的生命周期，可以对一个DataSource按顺序添加多条规则，对于一个Segment文件来说，协调节点会逐条检查规则，当碰到当前Segment文件负责某条规则的情况下，协调节点会立即命令历史节点对该文件执行此规则，加载或者丢弃，并停止余下的规则，否则继续检查。

索引服务

除了通过实时节点生产Segment文件之外，druid还提供了一组索引服务来摄入数据，相比较于实时节点，索引服务的优点是能够有不同的获取数据的方式，支持pull和push；可以通过API编程的方式来配置任务；可以更加灵活地使用资源；灵活地操作Segment文件等。

索引服务的主从架构

索引服务包含一组组件，并以主从结构作为架构方式，其统治节点 Overload node 为主节点。而中间管理者Middle Manager 为从节点

Overload node：作为索引服务的主节点，对外负责接收任务请求，对内负责将任务分解并下发到从节点即Middle Manager 上，Overload node 有两种运行模式

• 本地模式（默认）：，此模式主节点不仅需要负责集群的调度，协调分配工作，还需要负责启动苦工（Peon）来完成一部分具体的任务
• 远程模式 ：此模式下，主从节点分别运行在不同的节点上，主节点只负责协调分配工作，不负责完成任务，并且提供rest服务，因此客户端可以通过 HTTP POST 来提交任务

Middle Manager 与苦工：Middle Manager 即是 Overload node 的工作节点，负责接收Overload node 分配的任务，然后启动相关的Peon来完成任务 这种模式和yarn的架构比较类似

• Overload node 相当于Yarn的ResourceManager，负责资源管理和任务分配
• Middle Manager 相当于Yarn的NodeManager ，负责管理独立节点的资源，并且接收任务
• Peon 相当于Yarn的Container ，启动在具体节点上具体任务的执行