Druid Coordinator Nodes

Druid的Coordinator 节点主要负责segment的管理以及为historical节点分配segment。Coordinator节点会告诉historical节点去加载新的数据、删除过时的数据、备份数据、移动数据以达到负载平衡。

为提供一个稳定一致的视图，Coordinator节点使用一个多版本并发控制交换协议（multi-version concurrency control swapping protocol）来管理不可变的segment。

Coordinator 节点会选举出一个leader，leader节点会决定哪一个节点来执行具体的协调工作。此外，Coordinator节点还维护着一个zookeeper链接，用于获取集群的状况信息，通过对比期望的状况信息，来判断集群的健康情况。同时，还维护一个到MySql的链接，用于存储一些配置和操作参数信息。比如记录一个表中所有可被historical节点查询的segment列表，这个表可以被任意改写。在mysql中还有一个规则表（rule table）用来记录segment是怎样创建（created）、删除（deleted）和备份的。

 

规则表

规则表定义了怎样从Druid集群中加载或删除一个segment，也定义了一个segment怎样被分配不同的historical节点层（tier）以及每层应该存在多少个segment副本。比如，一个用户可以使用规则来加载最近一个月数据的segment进入hot tier（热点层），加载最近一年的segment进入cold tier。

对于real-time节点刚创建好的segment，Coordinator节点根据相匹配的规则告诉historical节点来从深存储中加载该segment。

负责均衡

在生产环境中，通常会存在一个查询请求需要加载几十或上百的segment的情况，由于historical节点资源的限制，需要将这些segment均匀的分散到集群的不同节点上来达到平衡。此外，druid还提供了一个基于代价（cost-base）查询优化器，它可以根据segment的数据源、使用频率和大小，生成一个最优的查询路径。

副本

为提高segment的容错性，可以设置一定数量的segment副本，这样在某个historical节点变得不可用了，可以加载其它节点副本来供查询。

可用性

Coordinator 节点依赖Zookeeper和Mysql为提供一致性协调服务和segment相关的元数据信息。比如依赖zookeeper来判断某个historical节点是否在集群中存活，依赖mysql保存一些操作管理信息和segment的元数据信息（segment的位置、segment是否存在集群中）。如果依赖的zookeeper或mysql变得不可用了，那么Coordinator节点将停止新segment的分配和过时segment的删除。但historical节点当前持有的segment仍可以供查询的。