有奖讨论： ETL 工具 VS SQL 代码

fireboy201

我认为没可比性。ETL工具关键在于用。
我遇到的很多项目，ETL工具的用途鸡肋。就算项目有ETL工具，也很少一部分任务用ETL工具，大部分用脚本，sql，存储过程。
倒是我认为一款专业的调度工具应用就很大，不论是项目开发阶段，还是运维阶段，都很有意义。而且，专业调度工具的作用，也不是你在项目中开发些代码可以替代的。

oracle_cj

这个帖子讨论的挺不错，想在项目里面二者兼用，存在的意义不一样。。。。

ZouYao

SQL代码更方便灵活
ETL直观易于维护

worngend

看需求，看项目成本

henry_fan

SQL的效率高，数据处理容易控制，但是后期维护实在不方便.etl更能节省开发量

kongbolin

ETL用来控制流程，即使在ETL里面也是一样用sql/SP ，ETL的便利在于他帮我们封装了后台代码，简单的几个控件拖来拖去就能实现功能。但是有时候ETL不能提供最高效的后台代码结构，所以开发人员也可以嵌入自己的代码。

gh_95533

前些天同事遇到11gbug，创建数据链无法抽取数据，我就设置kettle抽取的

little蜜蜂

成品 ETL 工具与手工写脚本之比较
一、灵活性来讲:ETL 工具比较灵活,需要在此平台上设置规则定义,前期是需要工 具先前必须已有支持功能,如果需要扩展,要 ETL 工具源厂商开发。而自己写脚本只需先 前好好调研需求,自己写能实现的功能即可。俗话说得好“求人不如求己”哈哈哈!
二、难易度:ETL 工具相对上手比较容易,工程师只需具备两个必要条件:1 、对数 据库熟悉 2、对客户的业务逻辑了解。手动写脚本呢?不仅要具备操作 ETL 工具的条件, 还要必须有一定技术水平。
三、后期管理与维护:ETL 工具非常容易,这点上是用工具的最给力的优势。可能也是 ETL 工具诞生的缘由吧!原因:人力少不说,如有新的需求,只需稍加改动,图形配置定 义即可。而手工编码呢?较难。需要重又开发写程序,随着数据信息的日积月累,􏰀日数据 的递增,更新。开发的速度赶不上需求的更新,严重到先前开发架构不合理甚至于有可能推 倒重来的风险。如果取中间,既有图形配置有兼具脚本开发功能,有款中国的 Beeload/ BeeDI
四、性能和效率:这方面取决于多方面如:1、硬件:服务器 CPU 内存 2、数据库类 型 数据类型 3、网络状况 4 、ETL 工具的配置 设计。。。。。整体来说 工具属于较高 范畴,各家成熟 ETL 不一致、各有千秋。手工写脚本就要看编程者的水平啦!因人而异, 如果直接在数据库上写存储过兴许比任何一家成品工具高得多。在性能上,工具当属老美的 informatica IBM 的 DS
五、开发周期:工具只需操作上源厂商负责培训,再把客户目前需求了解透彻,周期很 短,上线见效快。手工编码不仅需要把客户(当前)需求了解透彻,未来需求也要有所预测, 再进行开发。这样周期就不得而知了。
六、工作􏰁:从上述些显然保守点得出:ETL 工具属中等,手工编码属较重。写好程序 还需大􏰁测试工具,不断修正 BUG 与完善。成熟工具已把这些工具先前做过了,即使有, 也是可以容忍个别,源厂商可以分担修正。
七、投入成本价格:ETL 工具前期成本投入较多,钞票先付。后期维护成本相对低。编写 脚本,先期投入人力(工程师的工薪)中期大􏰁测试人力,后期维护人力(工程师的工薪) 看似相对较低。貌似不要票子的开源滴 ETL 工具 Kettle,后期才付费(服务费与培训费)
总之不管是用工具还是自己写脚本,要全盘考虑,根据各自项目大小,成本,愿意付出 哪部分,适合的才是最佳滴!

赛科大数据培训

我觉得抽取、清洗、简单的转换操作可以通过etl工具实现，较复杂的业务逻辑还是通过SP实现比较好，这样易于维护

赛科大数据培训

我觉得抽取、清洗、简单的转换操作可以通过etl工具实现，较复杂的业务逻辑还是通过SQL实现比较好，这样易于维护、成本低