六种 主流ETL 工具的比较(DataPipeline，Kettle，Talend，Informatica，Datax ，Oracle Goldengate)

• 六种 主流ETL 工具的比较(DataPipeline，Kettle，Talend，Informatica，Datax ，Oracle Goldengate)

比较维度产品		DataPipeline	kettle	Oracle Goldengate	informatica	talend	DataX
设计及架构	适用场景	主要用于各类数据融合、数据交换场景，专为超大数据量、高度复杂的数据链路设计的灵活、可扩展的数据交换平台	面向数据仓库建模传统ETL工具	主要用于数据备份、容灾	面向数据仓库建模传统ETL工具	面向数据仓库建模传统ETL工具	面向数据仓库建模传统ETL工具
	使用方式	全流程图形化界面，应用端采用B/S架构，Cloud Native为云而生，所有操作在浏览器内就可以完成，不需要额外的开发和生产发布	C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环境，线上生产环境没有界面，需要通过日志来调试、debug，效率低，费时费力	没有图形化的界面，操作皆为命令行方式，可配置能力差	C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环境；学习成本较高，一般需要受过专业培训的工程师才能使用；	C/S客户端模式，开发和生产环境需要独立部署，任务的编写、调试、修改都在本地，需要发布到生产环境；	DataX是以脚本的方式执行任务的，需要完全吃透源码才可以调用，学习成本高，没有图形开发化界面和监控界面，运维成本相对高。
	底层架构	分布式集群高可用架构，可以水平扩展到多节点支持超大数据量，架构容错性高，可以自动调节任务在节点之间分配，适用于大数据场景	主从结构非高可用，扩展性差，架构容错性低，不适用大数据场景	可做集群部署，规避单点故障，依赖于外部环境，如Oracle RAC等；	schema mapping非自动；可复制性比较差；更新换代不是很强	支持分布式部署	支持单机部署和集群部署两种方式
功能	CDC机制	基于日志、基于时间戳和自增序列等多种方式可选	基于时间戳、触发器等	主要是基于日志	基于日志、基于时间戳和自增序列等多种方式可选	基于触发器、基于时间戳和自增序列等多种方式可选	离线批处理
	对数据库的影响	基于日志的采集方式对数据库无侵入性	对数据库表结构有要求，存在一定侵入性	源端数据库需要预留额外的缓存空间	基于日志的采集方式对数据库无侵入性	有侵入性	通过sql select 采集数据，对数据源没有侵入性
	自动断点续传	支持	不支持	支持	不支持，依赖ETL设计的合理性（例如T-1），指定续读某个时间点的数据，非自动	不支持，依赖ETL设计的合理性（例如T-1），指定续读某个时间点的数据，非自动	不支持
	监控预警	可视化的过程监控，提供多样化的图表，辅助运维，故障问题可实时预警	依赖日志定位故障问题，往往只能是后处理的方式，缺少过程预警	无图形化的界面预警	monitor可以看到报错信息，信息相对笼统，定位问题仍需依赖分析日志	有问题预警，定位问题仍需依赖日志	依赖工具日志定位故障问题，没有图形化运维界面和预警机制，需要自定义开发。
	数据清洗	围绕数据质量做轻量清洗	围绕数据仓库的数据需求进行建模计算，清洗功能相对复杂，需要手动编程	轻量清洗	支持复杂逻辑的清洗和转化	支持复杂逻辑的清洗和转化	需要根据自身清晰规则编写清洗脚本，进行调用（DataX3.0 提供的功能）。
	数据转换	自动化的schema mapping	手动配置schema mapping	需手动配置异构数据间的映射	手动配置schema mapping	手动配置schema mapping	通过编写json脚本进行schema mapping映射
特性	数据实时性	实时	非实时	实时	支持实时，但是主流应用都是基于时间戳等方式做批量处理，实时同步效率未知	实时	定时
	应用难度	低	高	中	高	中	高
	是否需要开发	否	是	是	是	是	是
	易用性	高	低	中	低	低	低
	稳定性	高	低	高	中	中	中
其他	实施及售后服务	原厂实施和售后服务	开源软件，需自客户自行实施、维护	原厂和第三方的实施和售后服务	主要为第三方的实施和售后服务	分为开源版和企业版，企业版可提供相应服务	阿里开源代码，需要客户自动实施、开发、维护