ETL工具对比

ETL开发

ETL是英文Extract-Transform-Load的缩写，表示将数据从来源端，经过抽取，转换，加载到目标数据源的过程。

数据抽取

分为全量抽取和增量抽取，数据量达到百万级别建议用增量抽取，小于百万级别可用增量抽取。同时第一次抽取都采用全量抽取。抽取过程中，注意空值处理，字符匹配，以及空格处理，数据错位等等有可能影响最终数据准确性的问题。

数据抽取可以使用ETL工具完成，也可以使用Sqoop完成。目前公司所用的是开源ETL工具kettle，kettle在使用过程中会存在一些缺陷，比方说抽取过后的数据串行，大数据量时抽取速度比较慢。同时任务调度功能方面不支持关闭状态下的调度。

数据转换

数据转换的任务主要进行不一致的数据转换，数据粒度的转换，以及一些商务规则的运算

1）不一致的数据转换

这个过程是一个整合的过程，将不同业务系统的相同的数据类型的数据统一，比方说A系统，和B系统同一个字段，两种取值。这样在抽取过来要将数据统一。

2）数据粒度的转换

业务系统一般存放非常明细的数据，而数仓中的数据是用来分析的，最后的数据一般都是将业务过程的数据按照数仓的粒度进行汇总后的结果。

3）商务规则的计算

公司有很多不同的业务规则，不同的数据指标，这些指标不是简单的相加减就能完成，需要在数仓中将这些指标按照不同的计算公式进行计算。

数据加载

数据加载是ETL的最后一个环节，一般将数据加载到MySQL供BI展示平台使用。

数据采集目前采用的是开源ETL工具kettle，kettle可以采集结构化和非结构化数据，对于结构化数据采集，可选择的技术方案除了有各种ETL工具，还有专门的数据采集工具sqoop。对于日志数据，可以选择Flume进行采集。

如果是实时需求，数据是日志数据，用Flume收集，传入Kafka，如果是关系数据库中的数据，可以选择OGG，canal等技术手段。

目前公司使用的ETL工具是Kettle，且数据开发太过依赖kettle工具，虽然kettle工具对于数据清洗过滤转换等很方便，但是kettle工具的存在局限性

1、自身调度工具功能不足依赖window任务调度，windows任务调度，没有回刷调度功能，自身功能存在缺陷；

2、kettle执行任务不稳定，经常出现访问CDH平台权限受限的问题；

3、后期部署脚本变多，kettle负载会变得很大，不便于部署跟管理基于以上考虑，将脚本执行以及任务调度从kettle中分离，只保留kettle抽取同步数据的功能；

原因一是数据源有多个kettle方便管理数据连接来进行连接，

原因二是kettle方便对原始数据进行清洗过滤转换。

以下是各种主流ETL工具对比，具体选择哪种ETL工具还需考虑公司自身的需要，以及产品与公司、业务场景的契合度。

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