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仍可以供查询的。

你可能感兴趣的:(druid,druid,coordinator,node)