不管是大数据领域，还是传统的基础数据领域，为了解决数据的流转问题，都需要各种类型，适应异构环境的小程序来做支撑，通常我们称之为ETL作业。
一想到做数据仓库项目，大家的第一反应就是去选型各种ETL工具。我个人觉得并不是所有的应用场景都需要ETL工具。之前接触过一个银行的数据仓库项目。他们是采用datastage做文本抽取，用oracle 存储过程做数据转换，还有一部分shell脚本做文件到达、磁盘清理和控制逻辑转发的功能。然后用datastage的 sequence job 做业务翻牌控制。
这样来看，他们的作业类型就相对单一。但datastage本身不太稳定，也满足不了他们的调度控制逻辑需求。所以他们采用了shell脚本来做一部分比较复杂的调度控制。
到最后datastage只作了一个文本抽取的功能。随着该银行业务系统的不断扩建和增加，作业数规模越来越大。更主要的矛盾表现在ETL作业本身的管理成本上。
他们意识到，能不能管理好这么多系统的作业，才是这些数据项目成功实施的关键。因此他们选用了国内的一款专业的ETL调度工具，来管理十几个系统和上万个作业。至于datastage的文本抽取作业，都被逐步改造为shell脚本来做了。
到最后￥80w采购的datastage基本上就闲置了。 实际上就是十几个系统和上万个shell脚本程序、oracle存储过程以及ftp作业，的调度监控管理问题。
所以，我觉得如果作业类型单一、环境简单的场景，就没有必要用专门的ETL工具。作业数上规模的情况下，采购一款专业的ETL调度工具才是必要的。
如果企业内部作业类型过多、异构环境复杂、技术人员水平参差不齐的情况下，采用专业的ETL工具就有必要了，因为它降低了技术门槛。也许简单的拖拽就能完成复杂的功能。
另外说一句，作业类型多、异构环境多从另一方面说明企业的IT管理不够规范（或许是历史原因）！在我看来ETL工具如同鸡肋 “食之无肉，弃之有味”