Druid Kafka索引服务的Task动态伸缩

 

一、Kafka Indexing Service 运行原理

1、简介

   Kafka Indexing Service 是 Druid 推出的利用 Druid 的索引服务实时消费 Kafka 数据的插件。该插件会在 Overlord 中启动一个 supervisor，supervisor 启动之后会负责创建task、调度task到Middlemanager中运行，并管理监控整个task的生命周期，而这些 task会连接到Kafka集群消费topic数据，并完成索引创，用户需要做的就是准备一个数据消费格式文件，之后通过 REST API 手动启动 supervisor，一个数据源对应一个supervisor。

 

2、KafkaSupervisor启动过程

 

3.  KafkaSupervisor 重要数据结构

    KafkaSupervisor用于消费kafka的task的数量是由用户提交数据消费格式文件中的taskCount进行配置的，一个task可能消费一个或多个kafka partition,partition的编号被哪个task消费存在这样的一个映射关系：Id = partition % taskCount，用户可以通过配置文件中的replicas 为一个task设置多个副本，这样几个副本会消费相同的partition， 由于副本机制，KafkaSupervisor有了一个TaskGroup的概念，TaskGroup中的task消费的partition相同。

 

 

     Kafka索引任务存在两种状态, reading 状态和publish状态，当task读取数据到达duration配置的时间，则进行publish状态，publish也会持续completionTimeout 时间，当task进入publish状态的时候立马又创建下一轮的任务开始从上一轮的task消费到的位置开始reading，这么一直不停地交错进行。Supervisor 也维护这两个队列用于存放两种状态的task，并且还维护一个全局的kafka 分区与offset的映射关系表：

 

   

       

由上可见Kafka Task 的数量是固定的，一旦某一个KafkaSupervisor需要修改task的数量，都必须手动重新提交KafkaSupervisor进程，而此刻KafkaSupervisor就先停止再重新启动，停止过程会kill所有的正在运行的task。

 

二、  实践中出现的问题

    1、动态伸缩的需求造成高昂的人力成本

   Supervisor在运行期间无法更改taskCount，如果到了流量高峰期，task消费不过来，导致Lag突增，目前的手动停止supervisor,并更改配置文件，由于现在的datasource数量比较多，不断重新修改配置文件重新启动造成比较大的人力成本消耗。

    2、资源的浪费

    为了避免流量高峰期的延迟，如果把taskCount设置成流量高峰期的值，到了流量低峰期的时候会造成资源的浪费。下图表明，该数据源的kafka流量在一天之内有很长时间处于低峰期，也有处于高峰期：

 随着业务需求日益旺盛，datasource不断递增，手动运维成本越来越高，实现一个可自动化调整的taskCount的新特效变得非常有意义。

根据观察发现， Lag和CPU的关系紧密：