前言：
美方：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 永恒权限，让你近一步亲临理解产品的功能属性同时，更是对咱们国内软件研发群体的反对与必定 ….