Druid架构分析（四）

29 Dec 2016

Broker作为真正对外提供服务的节点，并不“拥有”数据。Broker Node查询Realtime Nodes和Historical Nodes的数据并在需要的时候将结果集合并。

查询过程概述

• Client发送Http请求给查询节点，Broker Node将查询条件——根据interval找到相关的Segment，进而通过元数据存储及zookeeper(存储节点状态)找到包含这些Segment的Realtime Node 和 Historical Node
• Realtime Node 和 Historical Node 分别对查询进行处理，并返回结果。
• Broker Node将返回的结果合并，返回给Client

关于查询的一些细节

查询结果的缓存 Broker Node内部维护了一个LRU Cache，这个缓存可以是Local memory，也可能是一个分布式Cache。对于每次的查询请求，Broker Node会现在Cache中查找是否缓存了该Segment的结果。如果存在则避免重复计算。如果结果不存在则Broker会将请求转发给Historical Node和Real-time Node。返回结果后Broker Node将Historical Node的结果缓存。 由于实时节点的数据不停变化，所以Cache这部分数据没有意义。从某种意义上说Cache可以在Historical Node失败的情况下。起到一个暂时持久化的作用（仅针对已有过的查询请求）。

关于Broker Node可用性 Broker Node本身可以多点部署，所以可用性问题不大。不过考虑到zookeeper作为整个Druid的状态持久化的存储，一旦zookeeper失联该如何处理？Broker Node会利用其最后Cache的集群状态，来转发查询请求。所以即便是zookeeper不可用了。Druid还是能够坚持一段时间的。

查询组件丰富  虽然Druid并没有类似关系数据库的查询计划，但是其内部的查询组件非常丰富。下面简单列一下：

• Filter用来筛选各种维度，类似于SQL中的谓词。包含有：selector Filter，Search Filter,Regex Filter。以及自定义的JavaScript Filter——本质上是吧计算下推到数据的一种方式。可以简单的理解成UDF。
• Aggregator。用于聚合运算，类似于SQL中的聚合函数。各种常见的count，sum，max，min。值得一提的是可以在数据写入的时候就指定Aggregator。