Broker是Druid中一种类型的节点,在分布式集群部署环境中,它用来路由查询。它能够知晓ZK中存储的关于segment在集群节点分布的meta信息,以便于将查询路由至正确的节点。同时,broker还承担着合并节点查询结果的任务。在启动时,实时节点会向ZK注册自己,并上报其提供服务的segment信息。
启动命令
io.druid.cli.Main server broker
转发查询(Forwarding Queries)
大多数的Druid查询会包含一个interval字段用于指明需要查询的数据时间范围。Druid segment分布于整个集群,它们被分片后存储某些时间段的数据。想象一个简单的datasource,它有7个segment,每个segment包含一个星期中某一天的数据。任何一个查询大于两天数据的查询请求都会定位到多个segment上。这些segment很可能是分布在集群的多个节点上,因此查询也会涉及到对多个节点的请求。
为了确定将查询路由到哪些节点,Broker首先会对ZK中存储的信息做分析汇总。ZK中存储了历史节点、实时节点和他们分别服务的segment信息。针对ZK中存储的每一个datasource,Broker建立了一个segment和服务它们的节点的(时间表)timeline。当接收到一个查询请求时,broker会去时间表中查询包含请求中指定datasource和interval数据的节点信息,从而将请求路由到这些节点上。
缓存
Broker节点维护了一个基于LRU策略的缓存空间,其缓存了每个sgement的数据。它有两种实现方式,一是实现为每个Broker节点的私有本地缓存;而是利用memcached等外部分布式缓存组件实现跨节点缓存共享。Broker每次收到一个请求后,它首先会将其映射到一组segment上面,这组segment的子集的数据有可能已经存在于缓存中,Broker可以直接从缓存中拉取。对于数据不在缓存中的节点,Broker会把请求路由到相应的历史节点上。一旦历史节点返回了查询结果,Broker就会将这些结果数据存储在缓存中。实时节点的segment不会被缓存,因此对于实时数据的查询肯定会被路由到实时节点上,究其理由,实时数据是一直在变动的,所以基于缓存数据的查询是不可靠的。
HTTP Endpoints
Broker为交互暴露了几个HTTP的接口:
GET
/status
返回Druid的版本信息、加载扩展、使用内存、全部内存和节点的其他有用的信息。
/druid/v2/datasources
返回可查询的datasource列表
/druid/v2/datasources/{dataSourceName}
返回指定datasource的维度和指标信息。同时,可以使用可选参数"full",来获取intervals列表和这些interval包含的维度和指标信息。也可以通过"interval"参数来查询确定的某个interval的信息。
如果没有指定interval,将会使用基于当前时间的一个默认interval,它包含当前时刻之前的一段时间。这个interval的长度使用 ISO8601 format格式指定,对应设置参数为:druid.query.segmentMetadata.defaultHistory
/druid/v2/datasources/{dataSourceName}/dimensions
返回这个datasource的维度
/druid/v2/datasources/{dataSourceName}/metrics
返回这个datasource的指标
/druid/v2/datasources/{dataSourceName}/candidates?intervals={comma-separated-intervals-in-ISO8601-format}&numCandidates={numCandidates}
根据给定的datasource和intervals,返回segment列表和所在的节点信息。如果"numCandidates"未指定,将会返回每个interval包含的segment所在的所有节点信息。
/druid/broker/v1/loadstatus
返回一个标志,指明Broker是否获取了ZK中所有segment的信息。通过这个接口可以知道在比如重启的场景下,Broker是否能接受查询请求。
POST
/druid/v2/candidates/
根据指定的查询,返回包含服务地址的segment信息列表。