五种主流ETL工具对比

1 、简介

DataPipeline ：隶属于北京数见 科技 有限公司，是一家企业级批流一体数据融合服务商和解决方案提供商，国内实时数据管道技术的倡导者。

通过平台和技术为企业客户解决数据准备过程中的各种痛点，帮助客户更敏捷、更高效、更简单地实现复杂异构数据源到目的地的实时数据融合和数据管理等综合服务。

从而打破传统 ETL 给客户灵活数据应用带来的束缚，让数据准备过程不再成为数据消费的瓶颈。

Kettle：是一款国外开源的ETL工具，纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定。Kettle 中文名称叫水壶，该项目的主程序员MATT 希望把各种数据放到一个壶里，然后以一种指定的格式流出。

Informatica：是全球领先的数据管理软件提供商。

在如下Gartner魔力象限位于领导者地位：数据集成工具魔力象限、数据质量工具魔力象限、元数据管理解决方案魔力象限、主数据管理解决方案魔力象限、企业级集成平台即服务（EiPaaS）魔力象限。

Talend ：是数据集成解决方案领域的领袖企业，为公共云和私有云以及本地环境提供一体化的数据集成平台。Talend的使命是致力于帮助客户优化数据，提高数据可靠性，把企业数据更快地转化为商业价值。

以此为使命，Talend的解决方案将数据从传统基础架构中解放出来，提高客户在业务中的洞察力，让客户更早实现业务价值。

DataX ：是阿里巴巴集团内被广泛使用的离线数据同步工具 / 平台，实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。开源地址：https://github.com/alibaba/DataX

2 、成本

软件成本包括多方面,主要包括软件产品, 售前培训, 售后咨询, 技术支持等。

开源产品本身是免费的，成本主要是培训和 咨询，所以成本会一直维持在一个较低水平。

商业产品本身价格很高，但是一般会提供几次免费的咨询或支持，所以采用商用软件最初成本很高，但是逐渐下降。

手工编码最初成本不高，主要是人力成本，但后期维护的工作量蠢樱会越来越大。

3、适用场景

DataPipeline： 主要用于各类数据融合、数据交换场景，专为超大数据量、高度复杂的数据链路设计的灵活、可扩展的数据交换平台；

Kettle： 面向数据仓库建模传统ETL工具；

Informatica： 面向数据仓库建模传统ETL工具；

Talend：面向数据仓库建模传统ETL工具；

DataX ：面向数据仓库建模传统ETL工具

4、使用方式

DataPipeline： 全流程图形化界面，应用端采用B/S架构，Cloud Native为云而生，所有 *** 作在浏览器内就可以完成，不需要额外的开发和生产发布；

Kettle： C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环境，线上生产环境没有界面，需要通过日志来调试、 debug，效率低，费时费力；

Informatica： C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环带昌丛境；学习成本较高，一般需要受过专业培训的工程师才能使用；

Talend：C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环境；

DataX ：DataX是以脚本的迅凯方式执行任务的，需要完全吃透源码才可以调用，学习成本高，没有图形开发化界面和监控界面，运维成本相对高

5、底层架构

DataPipeline： 分布式集群高可用架构，可以水平扩展到多节点支持超大数据量，架构容错性高，可以自动调节任务在节点之间分配，适用于大数据场景；

Kettle：主从结构非高可用，扩展性差，架构容错性低，不适用大数据场景；

Informatica： schema mapping非自动；可复制性比较差；更新换代不是很强，支持分布式部署；

Talend：支持分布式部署；

DataX ：支持单机部署和集群部署两种方式

6、CDC机制

DataPipeline： 基于日志、基于时间戳和自增序列等多种方式可选；

Kettle：基于时间戳、触发器等；

Informatica： 基于日志、基于时间戳和自增序列等多种方式可选；

Talend：基于触发器、基于时间戳和自增序列等多种方式可选；

DataX ：离线批处理

7、对数据库的影响

DataPipeline： 基于日志的采集方式对数据库无侵入性；

Kettle：对数据库表结构有要求，存在一定侵入性；

Informatica： 基于日志的采集方式对数据库无侵入性；

Talend：有侵入性；

DataX ：通过sql select 采集数据，对数据源没有侵入性

8、自动断点续传

DataPipeline：支持；

Kettle：不支持；

Informatica：不支持；

Talend：不支持；

DataX ：不支持

9、监控预警

DataPipeline：可视化的过程监控，提供多样化的图表，辅助运维，故障问题可实时预警；

Kettle：依赖日志定位故障问题，往往只能是后处理的方式，缺少过程预警；

Informatica：monitor可以看到报错信息，信息相对笼统，定位问题仍需依赖分析日志；

Talend：有问题预警，定位问题仍需依赖日志；

DataX ：依赖工具日志定位故障问题，没有图形化运维界面和预警机制，需要自定义开发

10、数据清洗

DataPipeline：围绕数据质量做轻量清洗；

Kettle：围绕数据仓库的数据需求进行建模计算，清洗功能相对复杂，需要手动编程；

Informatica：支持复杂逻辑的清洗和转化；

Talend：支持复杂逻辑的清洗和转化；

DataX ：需要根据自身清晰规则编写清洗脚本，进行调用（DataX3.0 提供的功能）

11、数据转换

DataPipeline：自动化的schema mapping；

Kettle：手动配置schema mapping；

Informatica：手动配置schema mapping；

Talend：手动配置schema mapping；

DataX ：通过编写json脚本进行schema mapping映射

12、易用性、应用难度、是否需要开发

DataPipeline： 有非常容易使用的 GUI，具有丰富的可视化监控，易用性低，难度低，不需要开发；

Kettle： GUI+Coding，易用性低，难度高，需要开发；

Informatica： GUI+Coding，有GUI，但是要专门的训练，易用性低，难度高，需要开发；

Talend：GUI+Coding，有 GUI 图形界面但是以 Eclipse 的插件方式提供，易用性低，难度中，需要开发；

DataX：需要完全吃透源码才可以调用，学习成本高，没有图形开发化界面和监控界面，易用性低，难度高，需要开发

13、技能要求

DataPipeline： *** 作简单，无技术要求；

Kettle： ETL设计, SQL, 数据建模 ；

Informatica： ETL设计, SQL, 数据建模；

Talend：需要写Java；

DataX：需要写json脚本

14、数据实时性

DataPipeline：支持异构数据源的实时同步，速度非常快；

Kettle：不支持实时数据同步；

Informatica：支持实时，效率较低；

Talend：支持实时处理，需要购买高级版本，价格贵；

DataX ：支持实时

15、技术支持

DataPipeline：本地化原厂技术支持；

Kettle：开源软件，需客户自行实施、维护；

Informatica：在美国，主要为第三方的实施和售后服务；

Talend：在美国，分为开源版和企业版，企业版可提供相应服务；

DataX：阿里开源代码，需要客户自动实施、开发、维护

文章为自己学习整理后的成果，如有错误的地方，欢迎提出已作出及时修正。

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。

数据仓库是枣芹为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

ETL是将昌岩睁业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，耐岁目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据， ETL是BI（商业智能）项目重要的一个环节。

扩展资料：

ETL与ELT：

ETL所描述的过程，一般常见的作法包含ETL或是ELT（Extract-Load-Transform），并且混合使用。通常愈大量的数据、复杂的转换逻辑、目的端为较强运算能力的数据库，愈偏向使用ELT，以便运用目的端数据库的平行处理能力。

ETL（orELT）的流程可以用任何的编程语言去开发完成，由于ETL是极为复杂的过程，而手写程序不易管理，有愈来愈多的企业采用工具协助ETL的开发，并运用其内置的metadata功能来存储来源与目的的对应（mapping）以及转换规则。

工具可以提供较强大的连接功能（connectivity）来连接来源端及目的端，开发人员不用去熟悉各种相异的平台及数据的结构，亦能进行开发。当然，为了这些好处，付出的代价便是金钱。

对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。

从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。

再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。

在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。

也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。

哪种方式更好，也是需要看启好使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。

用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使悄锋铅用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。

用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分基念层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。

所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。

ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。

控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是 DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。

数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。

有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。

我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。

---