中美两国10万级作业调度工具 "TaskCtl" Vs "Control-M" 如何选用

前言：

美方：Control-M ( www.bmc.com) 中方：TASKCTL ( www.taskctl.com )

ETL调度工具中美PK ( TASKCTL VS Control-M)

Control-M

图片源自网络

TaskCtl

图片源自网络

先说说PK方法：这两款软件都宣称企业级调度软件，我们就先从软件企业级特征方面PK，随后从软件功能点进行PK，最后，PK最关键的东东-用户体验！

企业级特征体验PK

说实话，什么是调度的企业级特征，我无法定义，但至少应该有以下几个方面：网络支撑能力、跨平台能力、稳定性、大规模数据支撑能力、数据集中管理、统一应用门户等。我姑且就从这几个方面比较。

1. 网络支撑能力，这主要由软件核心网络架构决定，这两款软件都分别通过EM节点、Server节点、代理节点并以多级的方式进行网络控制；

2. 跨平台能力，TASKCTL只支持unix\linux环境，而Control-M支持各种主流操作系统；

3. 稳定性，这个很无聊，但又不能回避。稳定性不是软件测试就可以搞定的，最终还需实际环境长久的考验。这方面，TASKCTL是不能和Control-M相比的。

4. 大规模数据支撑能力，虽然两款软件都是宣称可以支持10万级的任务，但是，这种能力不是吹出来的，还得需要实际来验证。Control-M一方面以数据库存储数据，另一方面它有实际案例（中国建行)；而TASKCTL作为一支新秀，这种大数据案例方面，肯定没有。另外，从技术的角度，TASKCTL无数据库，面临大规模数据支撑一定会遇到相应的技术困难。

5. 数据集中管理，软件总是离不开数据，调度软件需要管理大量的流程等设计信息。作为一个企业级平台，流程信息的集中管理很必要。Control-M以数据存储数据，而且集中管理；TASKCTL，数据以文件方式存储，似乎也没集中管理，流程信息存储在不同的调度服务节点之上。

6.统一应用门户，这两款软件都是可以单点管理多个调度服务器，企业不同项目均可通过统一客户端进行管理应用。

PK结论：从企业级特征的角度，Control-M具有明显优势。Control-M是一款真正企业级技术平台，而TASKCTL最多只能称准企业级技术平台。如果说Control-M是重量级的调度平台，那么Taskctl就只能是轻量级的调度平台。

功能点PK

总体来说，对这两款软件，我认为从功能的角度，不论是核心调度功能，应用功能，扩展功能，它们都不相上下。只是实现方式有些不一样而已。我们以核心调度功能举例。调度核心功能主要是由任务执行条件判断能力所决定。Control-M条件判断主要通过资源条件、执行计划计划、自定义条件(Condition）三个方面来确定；而TASKCTL通过资源条件、执行计划、结构条件(串并结构、循环结构等)、容错条件、依赖、互斥、自定义条件(Condition）等多方面来决定。两个软件共同点，都是通过自定义条件来扩展及完善条件判断体系；而不同点，Control-M更为抽象，TASKCTL更具体。

如果非要说功能的区别，我认为是Control-M具有文件传输功能(但该功能已经超出调度的范畴)，TASKCTL没有；TASKCTL有流程调试功能，Control-M没有。

PK结论：如果只站在ETL调度及其应用功能点的角度，这两款软件各有千秋，PK结果平分秋色。

用户体验PK

说到用户体验，我毫不犹豫投TASKCTL一票。该软件独特设计带来独特的用户体验是Control-M无法相比的。

用户体验，是软件设计的核心理念，一款软件不仅仅是功能的完整，友好的用户体验才是王道。我记得我曾经的项目领导就非常强调用户体验，功能是功能，体验是体验。他经常拉UI工程师、美工一起讨论用户体验的问题。很久以来，我深受该领导的影响，认为体验的重点就在于UI，好的美工，好的布局，好的操作流程，我想很多朋友也同意我的观点。但接触TASKCTL后，我的看法却有了很大的改观，发现自己的认识太过局限，好的体验不仅仅在界面那一亩三分地，而更多来自好的架构，好的机制，为了好的体验，不惜创新，甚至勇于突破。但突破创新是要付出一定的代价，而且体验于创新不能本末倒置， 就像taskctl的官方网站所说，创新不是目的，而更好的应用才是根本。

那么，我们就来看TASKCTL怎么通过一系列的创新设计优化它的用户体验。

关注焦点：TASKCTL的创新、关键用户场景、与Control-M的对比。

先说TASKCTL几个关键的创新

1. 无数据设计，无数据技术并不新鲜，但在专业调度技术平台领域，该软件是唯一。

2. 流程的开发理念，流程设计的核心内容就是定义各种调度的目标任务，以及各种任务的控制策略，比如依赖、并行、执行计划等。传统采用配置方式，这种方式的本质就是通过设计各种数据表存储设计的各种信息，比如任务基本信息，控制信息等，应用时通过设计各种对话框来填充这些信息，这种方式称为配置方式。而TASKCTL采用开发方式，将流程的信息代码化，像开发程序一样开发流程。应用时通过类似VS一样的集成环境来设计流程。

3. 客户端脱机应用模式，不论国内专业调度软件还是国外专业Control-M，客户端的应用必须连接服务端；而TASKCTL客户端可以脱机应用，即无需连接服务端，就是完成除真实调度以外的所有操作体验。

4. 插件机制，专业调度平台支持不同类型的任务是基本的。Control-M通过行命令进行扩展，而TASKCTL明确提出驱动插件机制，通过不同驱动插件来扩展不同任务的支持。

5. 多种形式的应用系统，TASKCTL的调度应用，不仅有Admin、Designer、Monitor三个图形客户端软件，而且还有与之匹配的三个支付客户端软件。不论桌面客户端，还是后台字符界面客户端，都是完整的应用体系。Control-M虽然有后台字符界面，但该应用体系不完整，也不能完全与前台桌面客户端对应。

关键应用场景

用户体验一定落地到具体应用场景才有意义，调度的最重要的应用场景包括：

1. 安装部署应用场景，安装部署是软件应用的首要场景。

2. 流程设计应用场景，对于调度应用来说，该场景可能是最主要应用场景，通过该场景，我们告诉了调度平台该干什么活、怎么干活。

3. 运行监控应用场景，不用多说，该场景是客户最关心的，因为，我们需要要知道调度平台干活究竟干的怎么样了。

4. 查询应用场景，我们经常都很无聊，总是回忆过去，看看我们曾经做过些什么。

现在，我们来看看TASKCTL的创新在以上应用场景中,相比Control-M怎样出色发挥。

1.流程图展示效果

Control-M

TaskCtl

软件的容易，是因为掌握了技术，都容易实现指定的业务功能。软件的困难，是实现了某种功能，但它并不一定适用。不论是各种耳熟能详ETL工具中的调度，还是很多专业调度平台，都具有流程图的展示。但如果说谁的流程图更实用，我认为TASKCTL的流程图最具实用性。很多软件只是停留在能画流程图的层面，而TASKCTL不仅可以画流程图，它为了美观且清新的展示，它为了方便查询、定位、切换等操作，提供了八大技巧功能。

虽然我说的很肯定，但仁者见仁，每个人都有自己的看法。不过，你一一比对TASKCTL这八大特征就会明白，而且，你一定要记住，流程图的根本目的，不是为了画图，也不是为了设计，而是为了直观的展示，为了通过图形，快速了解你的流程是什么‘样子‘。

Control-M图形展示，虽然有一定技巧，但与TASKCTL相比，它的技巧似乎还少了许多；另外，在大型图面前，TASKCTL无线条交错且规则的展示特征，是Control-M跨不过去的坎。

2.安装部署应用场景

Control-M即便您熟悉，环境搭建没有半天你别想搞定。而TASKCTL无论你否熟悉，按《TASKCTL 新手体验》操作，10分钟搞定。TASKCTL不论是桌面客户端，还是服务端，安装几乎傻瓜化，基本操作就是，下一步，y, 回车。TASKCTL安装的简洁一方面归功于软件的外围接口设计简洁以及安装包自身的设计，另一方面就要归功于无数据库设计了。

3.流程设计应用场景

在该场景的不一样的应用我认为是TASKCTL最不一样的地方。总体来说，不论是Control-M采用对话框定义配置的方式，还是TASKCTL采用代码设计方式，它们都可以实现流程的设计，但Control-M的方式缺乏一定的实际可操作性，而Taskctl的方式不但方便，而且还简单、快捷。

在一个调度应用中，任务是成百上千的，试想一下，通过Control-M定义一千个任务，我们肯定会在不同对话框中来回点击保存切换，而每个任务可能又有很多属性，可以预见，这种操作使实际应用变得有些困难。而实际应用中，很多项目使用Control-M时，都没采用软件提供的配置方式，而是通过电子表格来定义。因为电子表格毕竟是平面文档，很多信息就在一个地方编辑即可，从而避免众多的对话框点击切换操作。采用电子表格相对对话框还有一个好处，就是信息搜索定位也方便了很多。

这种现象说明了以下几个事实：面对流程设计应用场景时，在大流程面前，Control-M理论上有完整的实现方案，但实际却缺乏可操作性，项目宁可采用与之无关的电子表格，也不使用Control-M自身的方案，让Control-M的方案形同虚设。

接下来，我们说说TASKCTL，它采用代码方式设计流程。代码本身就是通过文本来承载，加之在代码基础上设计一个成熟的代码集成开发设计环境，使流程的设计编辑管理变得非常方便。对于集成开发环境理念，大家就非常熟悉了。图形方式代码方式可以任意切换，就看个人的喜好。也许有人认为，集成开发环境，看似很好，但代码方式，虽然易编辑，但代码的学习成本高，没配置的好理解。不错，这的确是关键问题。但可惜的是，TASKCTL的代码只能算准代码，虽有一定的语法特征，但总体很易懂，很易掌握，我本人不到半天就可以使用了。

另外，通过TASKCTL的流程代码设计出同等功能的流程信息规模，我认为是最少的，至少比Control-M少。从TASKCTL官方资料透露，TASKCTL的流程信息量与Control-M相比，只是Control-M的1/5，甚至更少。对于这个数字，我认为不准确，Control-M流程信息从设计的角度不好统计其规模，但我还是坚信TASKCTL的是最简洁的，因为它还有代码自身的特殊机制以及插件机制来保证。至于这些机制怎么保证流程信息设计更少，更简洁，在此我不多说了，等有机会，再和大家交流。

4.监控应用场景

TaskCtl

Control-M

对这个应用场景，除了一些不一样的操作技巧以外，我认为整体上TASKCTL并没有什么出色亮点。但完整的后台客户端应用系统，让技术人员有更多的选择。

5.查询应用场景

对于这个场景，我认为是TASKCTL设计中最神不知、鬼不觉而又绝对有意为之的。如果你是技术人员，你一定喜欢。

这个惊喜归功于TASKCTL的脱机应用机制，也就是说你可以不依赖服务器，轻松带着你的’流程‘到处走。不论何时，你都很轻松知道你的流程是什么样子。回家，看看，改改；白天上班，不论是办公室、会议室、休息间，你都很方便与同事讨论讨论你的流程；离开项目，你可以将流程悄悄的带走。当有一天，打开TASKCTL客户端，你可以看到你曾经设计的各个流程，届时，你心里一定很自豪吧。

这些，看似与调度无关，但是不是又很实用呢？

那看看Control-M是否可以做到呢？我的回答是，理论上可以，但实际不可能。你只要想想，连服务端是不是很方便就知道了。也许除了项目现场可以方便连接，其它地方，还是洗洗睡吧！

最后想说

非常感谢你能看到这里。PK归PK，结论归结论，选择归选择，每个人心中都有自己的选择，我的选择是面对超大型项目（10000个任务以上），ETL调度还是Control-M，而中小型项目，我可能要选择TASKCTL。