Druid原理分析之“流”任务数据流转过程

本文以kafka indexing service和下图为例，描述流任务中Druid从数据摄取到数据查询的全部流程：

1. 往Druid提交流任务任务后，kafka indexing service根据提交的json描述，将kafka中的原始数据按时间片，维度来进行聚合，生成segment。
2. segment片生成以后，kafka indexing service会将此部分数据注册到Zookeeper，以供Broker查询。
3. 当segment数据文件生成以后，indexing service会将该segment文件保存到Deep Storage（HDFS）中。保存的路径为：/druid/segments/<dataSource>/<intervalStart>_<intervalEnd>/<segmentGenerateTime>/<shardNum>/
4. 将该segment的元数据信息(如descriptor.jon）保存到Druid的元数据存储（如MySQL的druid_segments等表）中。
5. 然后HandOff等待segment加载完成。
6. Coordinator会定时（1分钟或5分钟为一个周期）从元数据存储中加载segment数据信息。以便将segment load到historical节点中。
7. Coordinator会找出新的segment，然后按照一定的策略计算负载后，将这些segment的信息写入Zookeeper的loadQueue中。
8. Historical节点监听Zookeeper，从loadqueue中获取需要加载的segment信息。
9. Hiatorical节点开始从Deep Storage中加载该segment。
10. 加载完成后，historical节点会到Zookeeper上删除loadqueue中该segment的信息，并将该segment在这个historical节点上的信息注册到Zookeeper中。
11. Coordinator监测到该Segment被加载完成，通知Kafka indexing service，该segment handoff 完成。
12. 当client端开始查询时，Druid broker会先到缓存（比如memcache）中检查，上次缓存的结果是否还在（过期时间1分钟）。如果在，直接返回检查结果。如果不在，继续：
13. Broker会根据查询条件去Zookeeper中获取相关segment的位置信息。
14. 如果查询时间范围包括当前时间，Broker会连接kafka indexing service获取实时的数据信息。查询在indexing service上计算完成后，将部分查询结果返回给Broker。
15. 如果查询条件包含已经handoff的segment，Broker会到相关的Historical节点上转发这个查询，Historical节点计算完毕后，将部分查询结果返回给Broker。
16. Broker聚合返回的各部分查询结果，将最后的结果返回给客户端。