一款B/S架构的轻量级ETL调度处理工具;支持各类脚本任务程序和扩展;具备可视化图形拖拽设计界面以及可视化任务管理、计划调度、实时监控、消息预警和日志分析;有效弥补了传统ETL工具在调度管理和监控分析方面不足
全部博文(10)
分类: 大数据
2020-06-10 11:01:46
在《批量作业调度技术界的两大困惑》一文中,分别讨论了在传统设计理念下,流程图的可视化、作业流的定义设计功能,随着作业量增加,越来越难用,越来越不适用是一个难以避免的问题。就这两个问题,我给大家分享一下TASKCTL是如何转变思路、如何突破、如何带来一些更理想的效果。同时,我也希望通过此次分享,带来一些抛砖引玉的效果,希望业界更多同仁,就批量调度技术更多的问题,敢于突破,使整个批量调度技术变得更完善、更易用。
第一部分:两大问题的再分析
在传统理念下,流程图可视化与作业流程定义方式不适用这两大问题,并不是孤立的,它们之间是相互影响,并相互恶化的。它们问题的核心都来源于一个共同的设计理念。
以上表格是传统方式对作业信息依赖关系组织的基本形态,作业之间的依赖关系采用属性记录的方式(有些调度设计不是前依赖,而是采用子作业后依赖方式,但本质是一样的)。这种方式,每条作业信息记录都是独立平等的,其中依赖关系只是每个作业的一个属性。我们认为,这种基本信息组织理念,对于小规模的作业信息组织影响不大,但对于大规模作业信息组织,就会影响到流程图展示,作业设计方式的适用性问题。
(二)对作业设计方式的影响:对话框方式不如Excel方式
(1)对话框方式不如Excel方式的原因
首先,是对作业设计方式的影响。从信息组织的记录特征出发,我们很容易想到对话属性框的设计方式。通过每个属性框的输入,完成作业各种属性信息的定义。但当我们面临大量作业信息的编辑时,很快就会发现对话框还不如直接编辑Excel。在Excel中,无论对更多信息的查看、编辑、拷贝、粘贴,都比对话框方便得多。
也许,你会说,我用的不是对话框方式,而是图形拖拽方式设计,很直观的。但实际上,拖拽编辑的直观是表面现象,背后依然是繁琐的对话框方式。这也是很多专业的调度软件,在实际使用场景中,宁愿选择 Excel方式主要原因之一。使用拖拽,可能只有两种情况,一是新手,二是唯一的设计方式(比如ETL工具),你没有更良好的选择。
(2)Excel带来的新问题
如果我们只关注编辑管理效率,相比对话框方式,Excel显然得到很大提升。但Excel的作业设计方式,又带来以下两个难以避免的问题:
第一个问题:脱机方式,与系统不能实时互动。我们采用了excel方式,单从编辑的角度,是提高不少效率。但Excel毕竟是第三方软件,不能与你的系统实时互动,它不能真实理解你每个属性的含义,不能实时检验你的信息,比如重复性,合法性。这一切,可能只有在导入的时候才知道。这些需求需求,你可能说,我可以通过二次开发Excel完成。没错,你可以做到。但我只想说,早知如此,何必当初,你又何必在调度软件里费那么大的力气,设计相应的对话框作业定义功能呢?
第二个问题:作业关系梳理很麻烦。采用excel,由于是脱机的方式,在excel中,我们很难实时直观的知道作业之间的关系,这对于作业间的依赖关系设计、修改,都变得非常困难。
(3)如果Excel方式是好的选择,那我们就应该多点匠心,多点优化。
虽然Excel有以上两个问题,但客观上,它的编辑管理效率比单纯的对话框方式,要高出很多。既然这样,我们为什么不多点匠心,将excel平面表格的方式集成到调度软件当中,这至少会使用户体验度,得到大幅度的提升。
(三)对流程图可视化的影响:线条大量交叉、排版混乱使流程图缺失直观性
(1)关系的自由组织,客观上难以避免凌乱的关系
由于作业之间的依赖关系,采用属性定义的方式,使你可自由定义作业间的多个依赖关系,但随着作业数的增多,你就很难控制这些关系的实际形状。一张蜘蛛网似的关系图,可能就此诞生了。
(2)人工编辑图形,同样难以避免凌乱的关系线条
为了避免凌乱的线条,你可能会想到图形编辑方式。毕竟在图形的向导下,可避免一些复杂的线条。但随着作业数的增多,首先是编辑变得异常困难,其次是在增删改的过程当中,线条的重构,重新排版带来的工作量也是你难以想象。也许,你会想到自动排版,但这种没规则的关系,在作业数多的情况下,其效果可能比你想象的还要糟糕许多。
(四)两个问题相互影响,相互恶化
总之,在这种信息组织理念下,如果采用图形拖拽,对话框方式,也许会减少很多凌乱的线条,使关系变得清晰一些,但这种方式又带来巨大的编辑工作量。如果采用Excel方式以提高编辑工作效率,那一定会给你带来难以接受的关系图。这两种矛盾,在目前设计理念下,是难以协调的。
第二部分:TASKCTL的突破
在TASKCTL理念框架下,不论作业数多少,作业间的关系线条,始终是无交叉、清晰、直观的,而且还没有图形编辑的繁琐。在IDE环境下,设计再多的作业,
也比Excel似的设计,更为快捷、更为高效。而TASKCTL这些突破性的变化,更为理想的效果,主要是因两大理念的转换所带来的。
(一)作业依赖关系组织理念突破
(1)从自由组织理念到结构化组织理念
传统作业间的关系信息组织是自由的,但在TASKCTL中是结构化的,通过串并组的方式组织作业之间的依赖并行关系。
一个传统表达方式:
同样的关系在TASKCTL中的表达方式:
(2)TASKCTL流程图本质上是一张有序无环图
TASKCTL采用这种串并组结构化组织,本质上就不可能具备交叉现象,是一张有序无环图。以下是一张TASKCTL流程图示例。
(3)TASKCTL对有序无环图缺陷的弥补
对于有序无环图这种图形关系表达理念,在大数据领域比较普遍。无论是底层基于资源的任务调度逻辑,还是OOZIE(一款大数据领域的作业流调度工具)业务工作流调度逻辑,都是采用有序无环的关系表达理念。但同时,我们也要知道,这种逻辑管理组织理念,有一种缺陷,就是无法做到一些交叉关系表达。比如以下关系:
在有序无环图表达理念中,上图C到D的关系是无法表达的。不过在TASKCTL,这种关系特殊的处理,可以通过LEAN(强制依赖)以及事件方式进行相应处理。LEAN属性与传统方式理念是一样的,可自由组织依赖关系。只是在TASKCTL中,这种传统方式只是基于串行结构化依赖的一种补充。
在任何一门计算机语言当中,可能都有类似GOTO这样的语句,实现一些灵活的
关系跳转。但我们都知道,为了增强信息的可管理型、可读性,尽量采用结构化语句编写,而GOTO,尽量避免。在TASKCTL中,LEAN就像GOTO一样,作业关系我们尽量用结构化串并组嵌套方式表达,而LEAN这种灵活的表达方式,还是少用为好。
(二)作业整体信息组织理念的突破
(1)从单纯记录信息到结构化,规则化的“代码”信息
在传统作业信息组织方式下,是以每个作业为一个独立的设计单位,而在TASKCTL中,是以一个结构或多个结构为设计单位;传统的焦点是每个作业个体,而TASKCTL更倾向于一个更大的整体。TASKCTL站在一个整体特征的角度,设计了相应的规则,并以XML格式进行表达。实际上,TASKCTL的设计信息更像具有一定语法规则的代码,并引入了很多代码语法理念,比如if语句、各种函数、属性继承、重载以及自由注释等。
(2)从配置理念到开发理念
传统作业信息组织是记录式表达,而TASKCTL是用具有一定语法规则的结构化代码来表达。记录采用配置概念,而代码显然采用开发概念。传统为了方便记录的配置,设计了相应的对话框;而TASKCTL,为了方便文本代码的开发,设计了相应的IDE环境。
传统方式,之所以更愿意选择Excel对更多记录的配置,其核心原因是Excel是一个平面文件。相比一个个对话框,平面文件更便于信息浏览、查看、编辑。而TASKCTL信息本身就采用格式代码的方式,本身就是一个平面文件。IDE设计的目的,只是为了更好的管理、设计开发TASKCTL的代码文件。
如果站在另一个纬度,传统Excel方式配置和TASKCTL代码方式开发,都是为了产出一个有规则的文件的话,一个是采用普通文件编辑器编辑,而另一个是采用针对这种规则设计的特殊编辑器(IDE)进行编辑。
我们知道,JAVA程序的设计,是可以直接通过简单的记事本来完成,但我们还是要采用更强大的eclipes进行开发设计,中间的差距,不言而喻。