中美两国10万级做业调度工具 “TaskCtl“ Vs “Control-M“ 到底该如何选用？

前言：

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

中方：TASKCTL ( www.taskctl.com )

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

Control-M

TaskCtl

而国内，在众多的软件中选择TASKCTL，我彷佛没有任何犹豫。该软件虽然没什么名气，但它清新的界面、独特设计、用户体验让我印象太深入。我想，假以时日，TASKCTL必定会有它的江湖地位。好了，赞美的话仍是少说，评价技术要客观，咱们仍是站在客观的立场来一场中美PK!

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

企业级特征体验PK

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

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

2. 跨平台能力，TASKCTL只支持unixlinux环境，而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。

欢迎你们将你的见解留言在评论区与咱们一块儿讨论，咱们将优先选取3-5位精品留言给与无偿使用taskctl 6.0 永久权限，让你近一步亲临了解产品的功能属性同时，更是对咱们国内软件研发群体的支持与确定....