1、系统架构

Druid集群是由不同类型的节点组成的，每个类型的节点被设计用来执行一组特定的任务。不同的节点类型操作香相对独立，并且不同的节点类型之间仅有极少的交互。因此，集群内通讯故障对数据可用性的影响微乎其微。为解决复杂的数据分析问题，不同的节点类型组合在一起形成一个完成的工作体系。

参考震哥的技术分享pdf：
数据摄入时的架构图：

image.png

数据查询时的架构图：

image.png

2、节点类型

数据摄入部分：
Overload：监视MiddleManager进程，并且是数据摄入Druid的控制器。它们负责将提取任务分配给MiddleManagers并且协调Segment发布。

MiddleManager将新数据摄取到集群中，负责从外部数据源读取数据并且发布到新的Druid Segments。

2.1 实时节点：

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

Segment数据文件从制造到传播经历的流程：
（1）实时节点生产出Segment数据文件，并将其上传到DeepStorage中。
（2）Segment数据文件的相关元数据信息被存放到MetaStore（即MySQL）里。
（3）Master节点（即Coordinator节点）从MetaStore里得知Segment数据文件的相关信息后，将其按照规则的设置分配给符合条件的历史节点。
（4）历史节点（即Historical节点）得到指令后会主动从DeepStorage中拉取指定的Segment数据文件，并通过Zookeeper向集群声明其负责提供该Segment数据文件的查询服务。
（5）实时节点丢弃该Segment文件，并向集群声明其不再提供该Segment数据文件的查询服务。

2.2 历史节点：

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

image.png

答案：首先会检查自己的本地缓存（Local Cache）中已存在的Segment数据文件，然后从DeepStorage中下载属于自己但是目前不在自己本地磁盘上的Segment数据文件。无论是哪种查询，历史节点都会首先将相关Segment数据文件从磁盘加载到内存，然后再提供查询服务。

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

======》 引出热数据，温数据，冷数据的概念。

历史节点的高可用性与可扩展性：（Zookeeper的重要性）
新的Historical历史节点被添加后，会通过Zookeeper被协调节点(Coordinator)发现，然后协调节点(Coordinator)将会自动分配相关的Segment给它；原有的历史节点被移除集群后，同样会被协调节点(Coordinator)发现，协调节点会将原本分配给它的Segment重新分配给其余处于工作状态的历史节点。

2.3 查询节点：

查询节点（Broker Node）对外提供数据查询的服务，并且同时从实时节点与历史节点查询数据（即MiddleManager和Historical），合并后返回调用方即客户端。
<1> 缓存的使用（Cache机制）
Druid也使用了Cache机制来提高自己的查询效率，并且提供了两类介质作为Cache以供选择。
外部Cache，比如Redis，Memcached。
本地Cache，比如查询节点或者历史节点的内存作为Cache。
注意：在使用查询节点的内存作为Cache，查询的时候会首先访问Cache，只有当不命中的时候才会去访问历史节点与实时节点以查询数据。

<2> 高可用性
一般Druid集群只需要有一个查询节点即可，但是为了防止出现单个节点失败导致无查询节点可用的情况，通常会多加一个查询节点到集群中。
在集群中有多个查询节点的时候，无论访问哪个查询节点都能得到同样的查询结果。在实践中，也会加一层Nginx。

2.4 协调节点：

Coordinator Node 负责历史节点的数据负载均衡，以及通过规则管理数据的生命周期。

image.png

<1>
对于整个Druid集群而言，并不存在真正意义上的Master节点，因为实时节点和查询节点能自行管理并不听命于任何其他节点；
但是对于历史节点而言，协调节点就是它们的Master节点，因为协调节点将会给历史节点分配数据，完成数据分布在历史节点间的负载均衡。当协调节点不可访问时，历史节点虽然还能向外提供查询服务，但已经不再接收新的Segment数据了。
<2>利用规则管理数据生命周期
利用针对每个DataSource设置的规则（Rule）来加载（Load）或者丢弃（Drop）具体的数据文件，以管理生命周期。可以对一个DataSource按顺序添加多条规则，对于一个Segment数据文件来说，协调节点会逐条检查规则，当碰到当前Segment数据文件符合某条规则的情况时，协调节点会立即命令历史节点对该Segment文件执行这条规则——加载或者丢弃，并停止检查余下的规则，否则会继续检查下一条设置好的规则。
<3>副本实现Segment的高可用性：

Segment高可用性

2.5 索引服务

除了通过实时节点生产出Segment数据文件外，Druid还提供了一组名为索引服务（Indexing Service）的组件同样能够制造出Segment数据文件。
相比实时节点生产Segment数据文件的方式，索引服务的优点：
除了对数据能够使用pull的方式外，还支持push的方式；不同于手工编写数据消费配置文件的方式，可以通过API的编程方式来灵活定义任务配置；可以完成Segment副本数量的控制；能够灵活完成跟Segment数据文件相关的所有操作，如合并、删除Segment数据文件等。