为啥要用etl工具？自己手动写脚本然后运行不是也可以么？

Posted 2023-05-09

参考技术A 成品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，后期才付费（服务费与培训费）

总之不管是用工具还是自己写脚本，要全盘考虑，根据各自项目大小，成本，愿意付出哪部分，适合的才是最佳滴！ 参考技术B 首先要理解 "etl" ,"etl工具" ,"etl调度工具" 这三者的概念区别
"脚本"对应的是etl领域中的"任务"实例
"etl工具"通常对应的是对etl领域中"任务调度"的工具

也有一些工具,比如微软的ssis也自称为etl工具,事实上在国内大型etl项目中:如银行项目,是不会采用ssis来做项目的,通常是国外专业的etl调度工具提供商,如control-m ,datastage等.

当然,国内也有优秀的调度产品 "taskctl" ,可以了解下!它提出了几个新的概念:
从根本上解决了现今市场ETL调度产品中"流程监控表达困难"的窘境!

同时它是无数据库的产品.从部署实践角度来说,显得非常方便.降低了部署运行环境的难度(在某些ETL调度产品,部署运行环境困难也是一个很恼火的事情)

首次采用了流程"编程概念",实现了调度流程的快速开发.(在某些ETL调度产品中,都是采用设置的方法来配置流程的.也许几十几百个可以慢慢配置.但是如果涉及到上千上万个任务,就显得捉襟见肘了)

为什么要用etl工具?就相当于上面举taskctl这个例子,是从"量变到质变"的过程!

参考资料：http://wenku.baidu.com/view/0c3767e8f8c75fbfc77db234.html

本回答被提问者采纳 参考技术C 其实的确是不一定要使用ETL工具的。如果是比较规范的数据，自己用脚本语言写ETL比使用工具要迅速与容易维护得多。特别是可以Python/Perl等写个针对自己公司的ETL库包，后面完成新的ETL其实是很容易的。ETL工具，说白了，主要是给不那么熟悉编程的人用的 参考技术D ETL工具可以跑批调度设置管理和监控，设置调度作业所对应的处理脚本

系统设计与架构笔记:ETL工具开发和设计的建议

最近项目组里想做一个ETL数据抽取工具，这是一个研发项目，但是感觉公司并不是特别重视,不重视不是代表它不重要，而是可能不会对这个项目要求太高，能满足我们公司的小需求就行，想从这个项目里衍生出更多的东西估计难。昨天领导让我写写自己的见解，今天写了点，不过说见解还真不敢，所以取了个名字叫建议了，今天把这个文档贴到自己博客里和大伙分享分享。

　　贴文档之前，我想很多朋友估计并不熟悉ETL，如果接粗过数据挖掘一定对ETL很熟悉了，ETL是数据挖掘里非常重要的一环，具体什么是ETL，大家看下面这段文字：

     ETL(Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程)作为BI/DW（Business Intelligence）的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，约占整个项目的60%～80%，这是国内外从众多实践中得到的普遍共识。
     ETL是数据抽取（EXTRACT）、转换（TRANSFORM）、清洗（CLEANSING）、装载（LOAD）的过程。是构建 数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

　　我们所要做的ETL工具不是针对数据仓库，说白了就是要个安全稳定的数据库数据导出导入工具。下面就是我写的文档，希望童鞋们看了后请多多指教。

1.1.  概述

如图1-1：

ETL工具共分为三大模块：ETL核心模块、日志模块和WEB模块。

1.1.1.   ETL核心模块

ETL核心模块是整个ETL工具的核心，它主要的功能是根据事先定义好的规则将源数据库的数据抽取到目标数据库。其主要工作流程是：

数据抽取-->数据转换-->数据清洗-->数据加载

ETL工具里的配置数据库必须包含两个方面的数据：

1. 元数据：元数据主要是指源数据、目标数据库以及可以用于抽取的表、字段等等信息，还有一些相关函数的定义等等。
2. ETL任务信息：ETL任务在我们ETL工具里称作job，job是指一个将数据从源数据库导出，并且按照一定规则导入到目标数据库的过程，ETL任务信息就是指一个job的相关配置信息。

1.1.2.   日志模块

良好的系统最重要的特征之一就是它的差错、容错以及能正确提供系统运行信息的特性。所以日志模块是每个系统必不可少的部分，它设计的优劣直接关系到系统后期维护的成本。

ETL工具里的日志模块，我个人认为应该包含如下的部分：

1. 程序运行信息。这个主要是用log4j在代码里记录。
2. ETL任务（即job）运行失败的日志信息。一切因为程序所抛出的异常所引起的失败都要记录在log4j的运行日志里，如果能精确提炼出的常见异常，最好能记录在数据库的日志表，便于快速查找错误信息（这个在有WEB系统时候可以做）。
3. 审计日志。审计日志是带有一定业务需求的日志，这个是否要记录看实际的需求。
4. 错误告警。一般而言ETL抽取数据的操作都是一件漫长的事情，ETL开发人员不可能长时间坚守在系统旁边，所以当系统运行出错能在第一时间通知到相关负责人是很有必要。Log4j里有邮件通知的功能，用起来也不太难，可以考虑在日志模块加入告警的功能。

1.1.3.   WEB模块

当我们开发好了ETL工具后我们需要一个入口，告诉我们设计的ETL工具你具体做什么样的任务。WEB模块的作用就是给用户操作的入口，我个人认为WEB模块包含以下功能：

1. 元数据管理：主要是向配置数据库定义源数据库和目标数据库的相关信息,例如：数据库的url，用户名，密码，相关的表以及表里字段信息等等。这些信息很重要，如果没有这些信息，整个ETL作业就是无源之水，根本无法进行。
2. ETL任务的配置信息：即job的配置信息，这个就是定义我们ETL的抽取过程，例如ETL需要抽取的源数据库是那个，抽取那张表那些字段，按照什么规则转化数据，清洗数据，最终导入到那个目标数据库等等。
3. 查看日志信息：这个功能可选，查看日志信息主要是提高系统的友好程度，便利系统运行信息的查看。
4. 用户管理：这个功能暂时可选，因为我们所开发的ETL工具主要是内部使用，没有太大必要做复杂的权限管理，但是简单的用户信息管理做做应该还是必要的。

整个WEB模块也是可选的，如果人力和时间不够是没必要做一个web系统，ETL入口我们可以手动的配置任务信息。（假如真的做了WEB模块，对ETL后台的设计和开发要求也会更高）。

1.2.  关于技术开发的一点建议

我之前看过大家写的ETL需求文档，大家考虑的非常全面，这里我暂时有两个技术建议， 建议如下：

1.2.1.   Xml技术

Xml技术在企业级系统开发和互联网开发中使用十分广泛，xml使用的场景也是非常的多，其中一个特点非常适合我们在ETL工具开发中使用到，那就是它可以存储复杂的富有变化的数据结构。而我们定义ETL任务信息（job配置信息）就是一个复杂的富有变化的数据。大家看下面的例子：

<?xml version="1.0" encoding="UTF-8"?>
<Job>
    <Id>流水号</Id>
    <Extract>
        <JDBCSource>
            <Url>…</Url>
            <Username>…</UserName>
            <Password>…</Password>
        </JDBCSource>
        <JDNISource>…</JNDISource>
        <Table>…</Table>
        <Columns>
        <Column>…</Column>
        <Column>…</Column>
        …
        </Columns>
        <Where>…</Where>
        <Commit>…</Commit>
        <OrderBy>…</OrderBy>
        <FilePath></FilePath>
    </Extract>
    <Transform>
<Columns>
        <Column>
                    <SrcColumn>        <!-- 抽取的原字段-->
                    </SrcColumn>
                    <Methods>
                        <Method id="1">    <!-- 第一次转换-->
                            <Function>...</Function>
                        </Method>
                        <Method id="2">    <!-- 第二次转换-->
                            <Function>...</Function>
                        </Method>
                    </Methods>
                    <DesColumn>        <!-- 加载的目标字段-->
                    </DesColumn>                       
         </Column>
        <Column>...</Column>
</Columns>
<SouceFilePath>...</SourceFilePath>
<TargetFilePath>...</TargetFilePath>
<Commit>...</Commit>        <!--每一批次的处理条数 -->
</Transform>    <Load>        <JDBCSource>            <Url>…</Url>            <Username>…</UserName>            <Password>…</Password>        </JDBCSource>        <JDNISource>…</JNDISource>        <Table>…</Table>        <Columns>        <Column>…</Column>        <Column>…</Column>        …        </Columns>        <Commit>…</Commit>        <LoadFilePath></LoadFilePath>    </Load></Job>

　　这是一个job配置信息demo，如果我们把这些数据用数据库来存储解析起来一定是非常复杂，数据库的表结构不适合表现出程序里复杂的数据结构。

　　在这里我们不应该把XML当做配置文件看待，而是当做一种数据存储的介质，其作用主要是便于我们读写数据。

既然对xml有读写操作，因此使用digester解析xml的技术远远不够，这里我建议使用xmlbeans，xmlbeans对于读写xml更加的简便，关于xmlbeans的学习参考如下：

Xmlbeans的使用：

http://blog.163.com/pqg_iloveyou/blog/static/33351875200761811255619/

xsd的学习资料：

http://www.w3school.com.cn/schema/schema_example.asp

xmlbeans官网：

http://xmlbeans.apache.org/

xsd在eclipse开发起来十分的简便。

使用xmlbeans维护xml的成本也会比较低。

1.2.2.   Spring Batch技术

对于spring batch技术我现在还不是特别熟悉，到底能不能被我们使用还需要考察和研究，但现在我知道的它的几个特点很符合我们ETL工具开发的场景：

1. spring batch批量处理框架，我们的抽取数据的过程就是一个批量的过程，因此spring batch是适合我们现在应用的场景。
2. 我们抽取的数据先是存储在临时文件，现在规定的临时文件的格式是csv，而spring batch正好有批量操作csv文件的功能，这个也很符合我们应用的场景。

1.3.  总结

因为本人以前做过和ETL工具类似的项目，因此这里大胆的提出一点自己的建议，仅供参考。

不过我在概述里画的系统结构图希望大家可以好好看看，也许还有很多不合理的地方，这需要大家集体智慧进行改进，我个人觉得系统的整体架构设计十分重要，我在看需求分析时候虽然感觉大家写的很全面，但是很难对系统整体结构有一个清晰认识，究其原因是需求里缺乏对系统的整体架构设计的部分，我个人觉得系统整体设计很重要很有必要，整体架构设计会给我们带来很多好处：

1. 整体架构设计会给我们需要做哪些功能有一个清晰的认识，这个认识会避免开发的时候遗漏了功能。
2. 整体架构能清晰表现出各个功能模块的关系，做过开发的人应该都会有这样的体会，模块之间的交互的地方很容易产生问题，而且交互产生的问题也是很难查找定位的，整体架构设计会让我们清晰认识到模块交互关系，利于我们做模块之间交互的开发。
3. 整体架构能清晰体现出模块之间的边界在哪里，这个很重要，不清晰模块之间的边界，很容易在把A模块的功能写到了B模块中，最终导致系统的不稳定。
4. 整体架构的设计能给项目开发的分工做参考，更合理的安排工作，提高生产效率。