可视化任务开发之任务调度总结

背景

最近一直在做数据开发方面的工作，对于可视化的任务开发如何去落地，想得比较多。最后发现，我们还是要选择一个好一点的调度框架。今天就梳理下之前工作中使用的一些中间件的任务调度机制，以加深对调度系统的理解。总结的比较浅显，欢迎拍砖。

单机任务调度

单机模式下，典型的任务调度算法DAG，还是相当简单的。构建任务执行有向无环图。以多线程的方式，来进行任务调度。

以上面的图为例，任务2，3依赖任务1，任务4依赖任务2，3，任务5依赖任务4。单机模式下，任务间的数据传递，我们一般直接是将数据放到内存中，直接以方法调用的方式，进行数据传递。一般都是进程间的数据流转，方便且快捷。这样做有如下两个问题：

1、机器内存是有限的，传递数据量较大时候，此方案不可行。

2、存在数据丢失的问题。每个环节数据都是直接放到内存中的，如果某个环节失败，整个链路的数据都会丢失。

3、可扩展性差，当任务节点很多的时候，单机性能有上限。分布式计算能解决可扩展问题，相应的调度机制也相当复杂。

Kettle集群调度方式

一个典型的ETL任务流程如下：

每个步骤为一个step，一个step中会有输入输出，kettle抽象出RowSet，step间是通过RowSet来进行数据的传递的。org.pentaho.di.trans.step.BaseStep类里面的inputRowSets和outputRowSets两个属性：

思想其实就是类似于JDBC中的ResultSet的机制，流式的思想，实现是通过批量的传递数据。另外，Kettle任务的调度支持集群方式调用。但是其集群模式比较轻量级，或者说是不完备的。Kettle集群采用主从结构，不具备自动切换主从的功能。所以一旦主节点宕机，整个系统不可用。Master节点负责整个job任务的执行，并负责调度，将每个step分发到指定的slave节点上进行执行。job的转换节点上，可以配置是否等待远程服务器上transform是否执行完成。基本就是同步异步的配置功能。Kettle通过Carte进行远程调度，节点之间是通过http协议进行数据的传输的，简洁不高效。截图如下：

Nifi集群调度方式

Nifi也是ETL开源产品中比较优秀的项目，其设计的理念与kettle有很大的不同。更接近于流式数据处理的机制。先来看下Nifi的整体架构：

借助于ZK，解决了主节点的单点问题，而且增加了一个协调节点，类似于Flink的job manager节点、kafka的协调节点。相比于Kettle的集群模式，已经相当完备了。来看一个最简单的ETL过程：

只有简单的两个步骤，从界面上就可以看出来，其设计的理念和kettle是完全不一样的。step直接增加了一个队列环节，通过队列解耦两个step的交互。已经非常接近流式处理的思想了。

Flink调度

最后我们来看下Flink的调度是如何来做的。较Nifi的实现方式，Flink在这方面做得非常好。节点之间的通信，直接借助于Actor System，充分利用网络传输高吞吐优势，数据不会落盘以避免昂贵的IO操作。另外，在资源隔离方面：以slot的方式对资源（内存）进行隔离，而且还引入了checkpoint的机制，完善了异常处理机制。

此方案应该是最完善的机制了，要啥有啥。

可视化数据开发思路

一种是基于Flink SQL的API方式来实现，可视化数据开发。但是，整体的开发工作量比较大。一切皆是SQL，整体灵活性欠缺。另一种方式就是采用传统的方式，比如：kettle、streamset、nifi这样的ETL工具的方式。kettle是CS结构，streamset目前已经闭源。可视化数据开发，基于Nifi进行二次开发，绝对是个比较好的选择！