Druid架构详解(1)

Druid的节点类型分为：Overload、MiddleManager、Coordinator、Historical 、Broker。

 Druid架构

Overload和MiddleManager主要负责数据摄入（对于没有发布的segment,MiddleManage也提供查询服务）；

Coordinator和Historical负责历史数据的查询；Coordinator:是Historical的master节点

Broker节点主要负责接收Client查询请求，拆分子查询给MiddleManager和Historical节点;

索引服务

Druid提供一组支持索引服务(Indexing Service)的组件，也就是Overload和MiddleManager节点。索引服务是一种高可用的分布式服务，用于运行跟索引相关的任务，索引服务是数据摄入创建和销毁Segment的主要方式（还有一种方式是采用实时节点的方式，不常用）。索引服务支持以pull和push的方式摄入外部数据。

索引服务采用的是主从架构，Overload为主节点，MiddleManager是从节点。索引服务架构如下图所示：

索引服务

索引服务由三部分组件组成：

1）用于执行任务的Peon(劳工)组件；

2）用于管理Peon的MiddleManager组件和分配任务给MiddleManager的Overload组件；

3）MiddleManager和Overload组件可以部署在相同节点也可以跨节点部署，但是Peon和MiddleManager是部署在同一个节点上的。

索引服务架构和Yarn的架构很像：

Overload节点相当于Yarn的ResourceManager,负责集群资源管理和任务分配。

MiddleManager节点相当于Yarn的NodeManager,负责接收任务和管理本节点的资源。

Peon节点相当于Yarn的Container,执行节点上具体的任务。

Overload节点

Overload作为索引服务的主节点，对外负责接收索引任务，对内负责将任务分解并下发给MiddleManager。

Overload有两种运行模式：

（1）本地模式(local mode)：默认模式。本地模式下的Overload不仅负责任务协调工作，还会负责启动一些peon来完成具体的任务。

（2）远程模式(remote mode)：该模式下，Overload和MiddleManager运行在不同的节点上，它仅负责任务的协调工作，不负责完成具体的任务。

Overload提供了一个UI客户端，可以用于查看任务、运行任务和终止任务等。

http://:/console.html

http://:/druid/indexer/v1/task  //提交任务

http://:/druid/indexer/v1/task /{task_id}/shutdown  //杀死任务

MiddleManager节点

MiddleManager是执行任务的工作节点，MiddleManager会将任务单独发给每个单独JVM运行的Peon（因为要把资源和日志隔离），每个Peon一次只能运行一个任务。

Coordinator节点

Coordinator是Historical的master节点，它主要负责管理和分发Segment。具体工作：告知Historical加载或删除Segment、管理Segment副本以及负载Segment在Historical上的均衡。

Coordinator是定期运行的，并且运行间隔可以通过配置参数配置。每次Coordinator运行都会通过Zookeeper获取当前集群状态，通过评估集群状态来采取适当的操作（比如均衡负载Segment）。Coordinator会连接数据库（MetaStore）,数据库中存储了Segment信息和规则（Rule）。Segment表中列出了需要加载到集群的所有Segment，Coordinator每次运行都会从Segment表来拉取Segment列表并与当前集群的Segment对比，如果发现数据库中不存在的Segment，但是在集群中还有，就会把它从集群中删掉；规则表中定义了如何处理Segment，规则的作用就是iwm可以通过配置一组规则，来操作集群加载Segment或删除Segment。

Historical节点加载Segment前，会进行容量排序，那个Historical节点的Segment最少，则它就具有最高的加载权。Coordinator不会直接于Historical节点通信，而是将Segment信息放到一个队列中，Historical节点去队列取Segment描述信息，并且加载该Segment到本节点中。

Coordinator提供了一个UI界面，用于希纳是集群信息和规则配置：

http://:.

Historical节点

Historical节点负责管理历史Segment,Historical节点通过Zookeeper监听指定的路径来发现是否有新的Segment需要加载(Coordinator通过分配算法指定具体的Historical)。上面通过Coordinator知道，当有新的Segment需要加载的时候，Coordinator会将其放到一个队列中。当Historical节点收到有新的Segment时候，就会检测本地cache和磁盘，查看是否有该Segment信息。如果没有Historical节点会从Zookeeper中拉取Segment相关的信息，然后下载。Historical加载Segment

Broker节点

Broker节点是负责转发Client请求的，Broker通过zookeeper能够知道那个Segment在那些节点上，Broker会将查询转发给相应节点。所有节点返回数据后，Broker会将所有节点的数据进行合并，然后返回给Client 。

Broker会有一个LRU(高速缓存失效策略)来缓存每个Segment的结果。这个缓存可以是本地缓存，也可以借助外部缓存系统(比如memcached),第三方缓存可以在所有broker中共享Segment结果。当Broker接收到查询请求后，会首先查看本地是否有对应的查询数据，对于不存在的Segment数据，会将请求***给Historical节点。

Broker查询：不会缓存实时数据，因为实时数据处于不可靠状态。

Peon节点

Peon在单个JVM运行单个任务，MiddleManager负责为任务创建Peon。