Druid-Druid中Coordinator Process

• 基于apache-druid-0.17.0
• Configuration和HTTP endpoints详见官网；

概览

• Druid中Coordinator进程主要是负责Segment的管理和分配。更具体的说，Coordinator进程和Historical进程保持通信，根据Configuration信息加载或者删除Segment。Coordinator进程负责加载新的Segment、删除过期的Segment、管理Segment的复制备份、Segment的负载均衡。
• Coordinator进程会定期运行，时间间隔是依据配置参数druid.coordinator.period（default：PT60S）。当Coordinator进程运行时，在Coordinator进程决定执行某些动作(actions)之前，会评估集群的当前状态。Coordinator进程同 Broker 和Historical进程一样，会将当前集群状态信息维护到zookeeper集群中。Coordinator进程将rules和可用的Segment的信息保存到数据库中。可用的Segment会存储在Segment Table中，并列出集群中应该加载的所有的Segment集合。rules信息存储在Rule Table中，指导Coordinator进程如何处理Segment。
• 在任何未分配的Segment 由Historical进程提供服务之前，每个层的可用Historical进程首先按照容量排序，容量最小的服务器拥有最高的优先级。未分配的Segment总是分配给容量最小的Historical进程，以保持Historical进程之间的平衡。Coordinator进程在为Historical进程分配新的Segment时不直接与它通信;相反，Coordinator进程在Historical进程的负载队列路径下创建一些关于新的Segment临时信息。当 Historical看到这个请求，就会立即加载这个Segment，并开始为这个Segment提供服务。

Coordinator启动命令

org.apache.druid.cli.Main server coordinator

Rules (Segment相关规则)

• Coordinator可以根据一组规则从集群中自动加载和删除Segment。
• 详见 ： Retaining or automatically dropping data
  

清理Segment

• 每次运行时，Coordinator进程都会比较数据库中可用的Segment列表和集群中当前的Segment列表。不在数据库中但仍在集群中提供服务的Segment将被标记并附加到删除列表中。被覆盖的Segments(它们的版本太旧，它们的数据被更新的Segment取代l)也被删除。

Segment可用性

• 如果一个Historical进程重新启动或者因为任何原因变得不可用时，Coordinator将会注意到这个Historical进程已经丢失，并将这个Historical进程服务的所有Segments视为被丢弃。如果有足够的时间，Coordinator可以将Segments重新分配给集群中的其他Historical进程。但是，被删除的每个Segment不会立即被Coordinator丢弃。取而代之的是一个过渡性的数据结构，这个数据结构存储所有带着生存期(lifetime)的已经删除的Segment。(生存期为Coordinator不会分配已经删除的Segment的时间)。因此，如果Historical进程在短时间内变得不可用并再次可用时，则Historical进程将启动并从其缓存保存的Segment，而不会在集群中重新分配这些Segment。

Segment的负载均衡

• 为了确保集群中各个Historical进程之间Segment的均匀分布，Coordinator进程将在Coordinator每次运行时查找每个Historical进程所服务的所有Segment的总大小。对于集群中的每个Historical进程，Coordinator进程将判断出利用率最高的Historical和利用率最低的Historical进程。Coordinator计算两个Historical进程之间的利用率差异百分比，如果结果超过某个阈值，Coordinator则将一些段从利用率最高的Historical进程移动到利用率最低的Historical进程（阈值为可配置项）。要移动的Segment是随机选择的，只有当Coordinator计算出的利用率最高和最低服务器之间的百分比差异已经减小时才会移动。

压缩Segment

• 每次运行时，Coordinator通过合并小的Segment或者切割大的Segment来压缩片段。当您的segment没有做相应的优化时，这些时非常有用的。详见segment-optimization。
• Coordinator首先根据Segment搜索策略(Segment search policy)找到要压缩的Segment。一旦找到这些Segment，Coordinator就发出一个压缩任务来压缩这些Segments。压缩任务同时运行的数量为(sum of worker capacity * slotRatio, maxSlots)。请注意，即使(sum of worker capacity * slotRatio, maxSlots)= 0，如果数据源启用了压缩，也始终会提交至少一个压缩任务。详情见官网：compaction-configuration和compaction-dynamic-configuration
• 压缩任务存在失败原因如下：
  • 如果压缩任务的输入Segment在启动之前被删除或覆盖，则该压缩任务将立即失败。
  • 如果一个高优先级的任务获得一个时间块锁(time chunk lock
    )，该时间块锁的时间间隔与一个压缩任务的时间间隔重叠，则压缩任务失败。
• 一旦压缩任务失败，Coordinator只需再次检查失败任务间隔中的Segments，并在下一次运行时发出另一个压缩任务。

Segment搜索策略

近期Segment优先策略

• 在Coordinator每次运行时，该策略都会按时间块的由早到晚的顺序查找时间块，并检查这些时间块中的段是否需要压缩。如果满足以下所有条件，则需要压缩一组段。
  • 1-Total size of segments in the time chunk is smaller than or equal to the configured inputSegmentSizeBytes.
  • 2-Segments have never been compacted yet or compaction spec has been updated since the last compaction, especially maxRowsPerSegment, maxTotalRows, and indexSpec.
• 案例如下：假如我们有两个数据源：dataSources (foo, bar)

• foo
  • foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION
  • foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION_1
  • foo_2017-09-01T00:00:00.000Z_2017-10-01T00:00:00.000Z_VERSION
• bar
  • bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION
  • bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION_1

• 假如每个Segment为10M且从未压缩过。搜索策略会优先返回两个segment，foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION和foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION_1进行压缩。因为2017-11-01T00:00:00.000Z/2017-12-01T00:00:00.000Z是最近的时间块。
• 如果Coordinator有足够的slots用于压缩任务，搜索策略会继续查找bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION和bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION_1。最后，foo_2017-09-01T00:00:00.000Z_2017-10-01T00:00:00.000Z_VERSION也会被执行，尽管在时间块2017-09-01T00:00:00.000Z/2017-10-01T00:00:00.000Z中只有一个Segment。
• 开始查找的时间点可以按照skipOffsetFromLatest进行配置。此策略将忽略掉在时间段的Segment(最近的Segment的结束时间—skipOffsetFromLatest)。
  这是为了避免压缩任务和实时任务之间的冲突。注意，在默认情况下，实时任务的优先级高于压缩任务。如果压缩任务的时间间隔重叠，Realtime任务将撤销它们的锁，从而导致压缩任务终止。

FAQ

Client是否会永远与 Coordinator 进程保持通信？

• 答：Coordinator不涉及query。
  • Historical进程从不直接与Coordinator进程通信。Coordinator告诉通过Zookeeper告诉Historical进程加载/删除数据，而且Historical进程完全不知道Coordinator。
  • Broker也从不与Coordinator通信。Broker是根据Historical进程写入ZK的元数据来理解数据拓扑，进程完全不知道Coordinator。

Coordinator进程在其他进程之前或之后启动有关系（区别）吗?

• 答：无区别。
• 如果Coordinator没有启动，集群中不会加载新的segment，过期的Segment也不会被丢弃。但是，Coordinator进程可以在任何时候启动，并且在可配置的延迟之后，将开始运行Coordinator任务。
• 这也意味着，如果有一个正在工作的集群，并且所有Coordinator都已停止运行，那么集群将继续运行，它只是不会感知到任何数据拓扑结构的更改。