ETL工具对比-CSDN博客

ETL开发

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

数据抽取

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

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

数据转换

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

1不一致的数据转换

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

2数据粒度的转换

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

3商务规则的计算

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

数据加载

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

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

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

目前公司使用的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映射
特性	数据实时性	实时	非实时	支持实时但是主流应用都是基于时间戳等方式做批量处理实时同步效率未知	实时	定时
	应用难度	低	高	高	中	高
	易用性	高	低	低	低	低
	稳定性	高	低	中	中	中
其他	实施及售后服务	原产实施和售后服务	开源软件需自客户自行实施、维护	主要为第三方的实施和售后服务	分为开源版和企业版企业版可提供相应服务	阿里开源代码需要客户自动实施、开发、维护