ETL作业调度工具TASKCTL的两个重大突破
ETL作业调度工具TASKCTL的两个重大突破
老衲大海 发表于5个月前
ETL作业调度工具TASKCTL的两个重大突破
  • 发表于 5个月前
  • 阅读 183
  • 收藏 3
  • 点赞 1
  • 评论 1

标题:腾讯云 新注册用户域名抢购1元起>>>   

在传统设计理念下,流程图的可视化、作业流的定义设计功能,随着作业量增加,越来越难用,越来越不适用是一个难以避免的问题。就这两个问题,我给大家分享一下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中的表达方式:

TASKCTL批量作业XML文件设计界面截图

(2)TASKCTL流程图本质上是一张有序无环图

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语句、各种函数、属性继承、重载以及自由注释等。

TASKCTL作业批量开发XML代码截图

(2)从配置理念到开发理念

传统作业信息组织是记录式表达,而TASKCTL是用具有一定语法规则的结构化代码来表达。记录采用配置概念,而代码显然采用开发概念。传统为了方便记录的配置,设计了相应的对话框;而TASKCTL,为了方便文本代码的开发,设计了相应的IDE环境。

传统方式,之所以更愿意选择Excel对更多记录的配置,其核心原因是Excel是一个平面文件。相比一个个对话框,平面文件更便于信息浏览、查看、编辑。而TASKCTL信息本身就采用格式代码的方式,本身就是一个平面文件。IDE设计的目的,只是为了更好的管理、设计开发TASKCTL的代码文件。

如果站在另一个纬度,传统Excel方式配置和TASKCTL代码方式开发,都是为了产出一个有规则的文件的话,一个是采用普通文件编辑器编辑,而另一个是采用针对这种规则设计的特殊编辑器(IDE)进行编辑。

TASKCTL作业设计IDE截图

我们知道,JAVA程序的设计,是可以直接通过简单的记事本来完成,但我们还是要采用更强大的eclipes进行开发设计,中间的差距,不言而喻。

共有 人打赏支持
粉丝 2
博文 20
码字总数 13635
评论 (1)
emslkl123
学习学习
×
老衲大海
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: