Druid架构分析（五）

31 Dec 2016

Coordinator作为指挥Historical Node节点的大脑而存在。

Coordinator Node

  Coordinator Node周期性的将集群中的状态与预期的状态对比来做决策，它是以Active-StandBy的模式运行，Leader的选举通过zookeeper来完成。在Druid 集群中 Historical Node的所有数据的管理都是由Coordinator Node发起。包括： 加载新数据，数据复制，数据的超期淘汰，及在多个Historical Node中间进行load balance。Druid利用了类似MVCC协议来管理immutable segment。

  Segment的layout信息在MySQL中保存——既Historical包含了哪些segment。MySQL还保存了一些规则信息， 包括超期淘汰的信息（通常是一个时段）也属于规则的一部分，规则决定Segment该如何在集群中分布。 数据分布规则会直接影响后续的查询性能及整个集群的IO平衡，同时还需要考虑的是如何充分利用多磁盘的带宽，还要兼可用性，比如——存在多个副本的存储系统，不能有2个副本同时落在同一个节点。在分布式系统中数据分布的方式主要有两种，range分布与hash分布。hash分布更有利于点查询，range则更有利于scan操作。

  关于元数据管理 整个集群的数据状态都依赖于已存在的元数据，从另一个侧面来说元数据存储能力决定了整个系统的最大数据容量。 Druid中的元数据存储在MySQL中，如果数据规模到了一定程度MySQL这种存储就会有一定得压力。不过MySQL作为存储承担的角色， 并不像在一般的OLTP系统那样所以并不会有太大问题。对比Hadoop 2.X中的元数据存储要复杂的多。造成这种差别的原因， 很可能是因为2个系统的侧重点不同，Druid并不是一个以存储为单一feature的系统。简单的回顾一下Hadoop NameNode的元数据存储方式， 当HDFS客户端在进行写操作的时候比如（创建文件或移动文件），这些操作会首先记录在EditLog中，记录在EditLog中的每一个操作称作一个事务， 然后更新内存中的image，内存中的的image只用于对客服端提供读服务，EditLog仅仅在数据恢复的时候起作用， 与关系数据库类似的处理手段，NameNode会定期的对内存中的image文件打checkpoint，在磁盘上形成FsImage文件， 在数据恢复的时候，会把FsImage文件加载进内存，然后会把EditLog中大于FsImage事务ID的回放到文件系统。

  Load balance 为了避免存储及计算上的热点，Druid尽量让Segment分散在集群的不同Historical Node节点上。 具体的也跟Druid的查询方式有关，Druid中的Balancer定期的整理Segment的分布，Balancer的策略是基于cost-based optimization算法， 算法的大概意思是这样的：我们知道时序数据的查询方式都是以时间为主要查询维度，且以scan操作为主（查询一段时间范围的数据）， 如果两个Segment的时间跨度越接近，就越容易被同一个查询所覆盖，同样的如果某几个Segment来自同一个DataSource也容易被同一个查询所覆盖。 Druid Balancer会尽量让被一个查询所覆盖的Segment尽量在集群中分散开。以便能够最大化利用集群的计算能力。具体实现涉及到很多细节， 比如：Segment的时间段是否有重叠等等。