Druid.io实时大数据原理介绍

Druid.io是“神马”？

Druid.io是一个开源的，分布式的，列式存储的，适用于实时数据分析的OLAP系统。它能够快速聚合、灵活过滤、毫秒级查询、和低延迟数据导入。2011年，MetaMarkets公司为了解决广告交易中海量实时数据的分析问题，在尝试各种SQL和NoSQL方案后，决定自行设计并创建Druid并于2013年开源。Druid被设计成支持PB级别数据量每天处理数十亿流式事件。Druid之所以保持高效有以下几个原因：

1. 数据进行了有效的预聚合或预计算。
2. 数据结果的优化，应用了Bitmap的压缩算法。
3. 可扩展的高可用架构，灵活的支持部署和扩展。
4. 社区的力量，Druid开发和用户社区保持活跃，不断推动Druid完善和改进。

Druid集群介绍

关于Druid的架构，我们先通过其总体设计架构图来做一个概要了解，如下图所示：

1. 实时节点(RealTime Node)：即时摄入数据，以及生成Segment数据文件。
2. 历史节点(Historical Node)：加载已经生成好的数据文件，以供数据查询。
3. 查询节点(Broker Node)：对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后返回给调用方。
4. 协调节点(Coordinator Node)：负责历史节点数据负载均衡，以及通过规则(Rule)来管理数据的生命周期。

集群的外部依赖如下图所示：

1. 元数据库(Metastore)：存储Druid集群的元数据信息，比如Segment的相关信息，一般用MySQL或者PostgreSQL。
2. 分布式协调服务：为Druid集群提供一致性协调服务组件，通常为Zookeeper。
3. 数据文件存储(DeepStorage)：存放生成的Segment数据文件，并提供历史节点下载。对于单节点集群可以是本地磁盘，而对于分布式集群一般是HDFS或NFS。

Druid实时节点

实时节点主要负责即时摄入数据，以及生成Segment文件，其独到的设计使其拥有超强的数据摄入速度。

Segment数据文件从生成到传播需要经历一个完整的流程，步骤如下：

1. 实时节点生产出Segment数据文件，并将其上传到DeepStorage中。
2. Segment数据文件的相关元数据信息被存储到MySQL中。实时节点转存的Segment会在ZooKeeper中新增一条记录
3. Master节点（即Coordinator几点）从MetaStore里得知Segment数据文件的相关元数据信息后，将其根据规则的设置分配符合条件的历史节点。
4. 历史节点得到指令会主动从DeepStorage中拉取指定的Segment数据文件，并通过Zookeeper向集群申明其负责提供该Segment数据文件的查询服务。
5. 实时节点丢弃该Segment数据文件，并向集群申明其不再提供该Segment数据文件的查询服务。

Druid历史节点

历史节点用于负责加载已经生成好的数据文件以提供数据查询。由于Druid的数据文件有不可更改性，因此历史节点的工作就是专注于提供数据查询。

1. Coordinator在ZK与History节点相关联的加载队列路径下创建一个临时记录。
2. 当历史节点发现在Zookeeper中有需要加载的新的记录。它首先检查本地磁盘目录（缓存）中关于新的Segment的信息。如果缓存中没有关于新的Segment的信息，历史节点将下载新的Segment的元数据信息并告知Zookeeper。元数据包含新的Segment在“Deep Storage”中的存储位置，怎样去解压缩和处理新的Segment的信息。
3. 一旦历史节点处理完一个Segment，就公布该Segment可查询。

Druid查询节点

查询节点对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后返回给调用方。Zookeeper维护有关历史和实时的节点信息和它们所能提供服务的Segment。当收某个数据源和时间的查询，代理节点执行查找与查询数据源时间相关的时间轴和检索包含数据查询的节点。代理节点将查询转发到所选节点。

Druid协调节点

协调节点负责历史节点的数据负载均衡，以及通过规则管理数据的生命周期。Druid针对每个DataSource设置规则来加载或者丢弃具体的数据文件，以管理数据生命周期。可以对一个DataSource按照顺序添加多条规则，对于一个Segment数据文件来说，协调节点会逐条检查规则，当碰到当前Segment数据文件符合某条规则的时候，协调节点会立即命令历史节点堆该Segment数据文件执行这条规则——加载或者丢弃，并停止检查余下的规则，否则继续检查下一条规则。

Druid索引服务

除了通过实时节点产生出Segment数据文件外，Druid还提供一组名为索引服务的组件。不同于实时节点的单点模式，索引服务实际包含一组组件，并以主从结构作为其架构方式，其中统治节点（Overlord Node）为主节点，而中间管理者（Middle Manager）为从节点。索引节点服务架构示意图如下所示：

索引服务是主从结构，由三个部分组成：

1. peon组件：在一个单独的jvm中运行单个任务，通过单独的jvm对任务做资源隔离和日志隔离。
2. Middle Manager：用于创建和管理peon的中层管理组件
3. overlord组件：管理任务分配到Middle Manager