DLF调度类型之事件驱动调度

        在华为云的DLF服务（现在叫DAYU数据开发）中，有三种pipeline的调度类型：单次调度、周期调度、事件驱动调度。其中单次调度就是直接运行pipeline，周期调度也比较简单，先定义一个运行时间，然后周期运行pipeline。今天主要介绍一下事件驱动调度。

        事件驱动调度，就是借用DIS的通道或者Kafka的topic来作为消息队列，实现消息通知机制。当用户在DLF上提交了一个事件驱动调度的pipeline，DLF会在后台的调度进程中启动一个线程。该线程会周期轮询消息队列，当队列中有新的数据到来时，会触发pipeline执行一次。被触发执行的pipeline也可以获取并使用消息队列中的数据。

        下图展示了事件驱动调度整个业务的处理过程，从图中可以看出，其实事件驱动调度就是使用了生产者消费者模式来实现的一种调度类型。

        事件驱动有两种触发事件类型：DIS、Kafka，下面会详细介绍这两种触发类型的实现逻辑：

（1）DIS

        首先，明确一下DIS中的几个概念：

• 通道：可以简单的理解为一个数据队列；

• App：相当于消费者的一个ID，不同的App代表不同的消费客户端；

• Checkpoint：Checkpoint指消费检查点，客户端消费数据时，Checkpoint记录已消费数据的位置，当重新消费数据时，可根据此检查点继续消费，一个App会拥有一个Checkpoint。如果多个客户端想并行消费DIS的通道且不互相影响，则可以使用不同的App来记录自己的消费位置。

        用户在DLF配置事件驱动任务的时候，需要先选择这个任务监听的DIS通道。当用户提交了这个事件驱动任务时，DLF会根据这个任务名来生成一个App，来作为消费标识。然后，在调度进程中启动一个线程，周期查询（查询周期就是配置中的“事件检测间隔”）这个DIS通道，当检查到DIS通道中有新数据的时候，DLF会从通道中消费出一条数据，触发任务执行，然后提交一次该数据的Checkpoint记录消费位置，下次从这个Checkpoint后一个位置继续消费。

        这时有个问题，仅仅触发任务执行是不够的，下游任务需要知道触发任务的数据内容到底是什么。如果需要在事件驱动任务中使用通道中的数据，可以使用DLF的EL表达式 #{Job.eventData}，这个EL表达式代表的就是触发这次事件驱动任务执行的数据的内容。

        上图中还有个参数“事件处理并发数”，这个参数指的是如果在DIS通道中收到了多条消息，DLF会同时孵化多少任务实例执行。具体逻辑：Jobtracker启动线程每次周期轮询的时候，该线程会先查询这个事件驱动任务处于running状态的实例有多少个，然后用事件处理并发数减去正在running状态的实例个数，就是要孵化的任务实例个数，接下来该线程会去DIS通道中获取相应数量的数据，并孵化任务实例执行。

（2）Kafka

        Kafka事件驱动的实现和DIS很类似，主要概念也基本一致：

• topic：和DIS的通道一样，也是数据队列；

• 消费组ID：类似DIS的App，用来表示不同的消费客户端的ID；

• offset：消费点的位置，类似于DIS的Checkpoint。

        Kafka事件驱动和DIS的事件驱动其实是同样的逻辑：DLF根据事件驱动的任务名来生成消费组ID，然后轮询Kafka的topic，当消费了数据并触发任务执行后，提交offset记录消费位置。

        这里的Kafka使用的是华为云上MRS服务的Kafka组件，目前还不支持对接开源Kafka。因为访问MRS Kafka需要身份认证和网络代理，所以使用Kafka事件驱动需要先创建MRS Kafka连接。

         上面就是DLF的事件驱动的实现逻辑，接下来讲下事件驱动调度相比周期调度的一些优缺点。

优点：

1. 业务解耦，提升性能。在周期调度作业中，如果多个节点间有依赖关系，当上游节点运行的时候，下游节点要等待上游节点跑完才能执行。如果上游业务和下游业务是通过事件驱动关联起来的，那上下游就是互相独立的任务，上游任务可以频繁运行，生成的通知数据会存储在中间队列中，下游任务根据消费的快慢可以自行调节事件处理的并发数，这样就不会出现上游节点运行，下游节点等待的情况。从而达到最佳的性能。

2. 业务灵活，可以实现多个业务系统之间的依赖。当用户有两条业务流，并且这两条业务流分别位于不同的系统，如果想要配置依赖关系的话，那就一个业务系统跑完后，发送一条通知数据到队列中，另一个业务系统就会被触发执行。

3. 实现批流结合。用户有一个流式作业，这个流式作业会源源不断产生新的文件，如果这些新文件想要被批处理作业使用，则可以在流式作业中发送通知到队列中，这样就可以触发批作业来执行。

缺点：

1. 事件驱动调度相比周期调度的配置来说比较复杂，上游任务需要去发送事件，下游任务需要配置事件驱动来消费事件。

2. 事件驱动调度需要借助额外的存储，需要使用DIS或者Kafka来作为消息队列来完成整个事件驱动链路。

        最后总结一下，从上面介绍来看，其实事件驱动调度的思路是很简单朴素的，就是生产者与消费者。主要是怎么掌握这种思路，来解决项目中遇到的各种奇怪场景。