导读：

a、什么场景下会使用到ETL？

b、ETL与ELT的区别是什么？

c、如何快速了解ETL开发流程？

图1

1、ETL介绍

ETL：是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。

ETL：概念通常用在数据仓库，但其对象并不限于数据仓库，什么意思呢？就是只要有涉及到数据搬运都是源到目标的过程，如：数据库迁移(Oracle迁移到MySQL)等。

使用ETL技术可以解决以下相关场景：

1、数据分散在各个系统中需要对数据进行整合，如：（图1）非常形象。

2、数据迁移到不同的环境，如：数据库、操作系统等

3、数据处理效率非常低下，如：有的用Python处理、Java处理等

2、ETL VS ELT

ETL与ELT的最核心区别是：抽取源数据是否需要【转换】后再加载到目标

设计时需要思考的问题如：

1、数据的可追溯性

2、ETL服务器资源

3、数据库服务器资源

4、程序职责边界划分

目前业界互联网80%都是基于ELT开发，传统大型数仓都是基于ETL开发。如下：

1、基于Hadoop体系构建的数据仓库，都是基于开源工具来做数据同步（如：DataX、Sqoop、Kettle等），然后基于同步数据来做相应ETL操作。

2、基于RMDB（Teradata\PostgreSQL\Oracle\DB2\MySQL\SQL Server）构建数据仓库，都是基于ETL工具来开发设计，如：Informatica、DataStage、SSIS、Kettle等。

3、ETL开发流程

图2

数仓ETL开发流程分别为：流程设计、概要设计、逻辑设计、代码实现、任务调度、数据质量

流程设计：是对数据整体链路流程描述说明概要设计：明确数据各环节处理过程逻辑设计：源到目标映射处理关系代码实现：是逻辑代码的具体实施调度任务：任务之间依赖关系与处理流程控制数据质量：监控源与目标是否准确无误

产出：ETL开发设计文档、单元测试用例

3.1、 流程设计

涉及ETL整体流程链路，明确源到目标之间过程描述

数据来源信息

明确数据源相关详细信息，数据库需说明相关信息，如：IP、端口、用户名、密码、表名称；日志需说明相关信息，如：服务器信息、目录、文件名称等

数据处理过程

指源数据处理存储逻辑概念描述，而非指具体处理过程。如：数仓、DataX等

数据目标输出

指数据最终输出目标，目标可能是：Hive、MySQL、ClickHouse、API、File等

3.2、概要设计

基于源数据进行分析，确定数据抽取、装载、问题环节相关策略。

数据探查

数据来源分两类：一类业务数据（DB）;一类行为数据（日志）。两类数据都需要对结构、字段、字段值、字段解释进行探查。

表、日志结构

表结构或日志结构实际是否与文档描述一致，如：业务方说某字段在表中是唯一，但实际表结构并未设置唯一键问题；防止发生少表问题。

字段

实际是否与文档描述一致，防止发生缺少字段、新加字段问题。

字段值

实际检查枚举值、状态值等是否与文档描述一致，防止与业务方描述不一样问题。

解释

表结构、日志结构、字段都应当有具体文档解释说明。

抽取策略

确定数据抽取口径（全量、增量）；明确数据提取频次（如：时、天、周、月）

装载策略

确定源数据到目标表装载策略类型（如：增量、Merge、全量）

问题处理

问题处理方式确定，如：执行时间过长，配置超时告警。执行出失败，邮件告警（默认）。关键核心数据配置【监控中心】电话通知告警。

3.3、逻辑设计

源到目标过程具体字段处理逻辑说明

命名规范

参见：《数仓命名规范》

映射关系

源数据到目标表的字段映射关系

转换规则

源数据到目标表字段处理逻辑

3.4、代码实现

基于逻辑设计编写程序实现具体功能

开发规范

参见：《数仓开发规范》

脚本性能

程序实现需要考虑具体性能问题，性能要求如下：

层名称

性能要求

执行时间段

buf

0~1200s

0:01 ~ 1:00

ods

0~1200s

0:01 ~ 1:00

dim

0~1800s

1:01 ~ 3:00

dwd

0~1800s

1:01 ~ 3:00

dww

0~1800s

3:01 ~ 4:00

ads

0~600s

4:01 ~ 6:00

未能达到性能要求，不能上线生产环境（特殊情况需向研发负责人说明）

引擎策略

根据具体业务要求采使用不同执行引擎，如：MR、Presto、Spark等

单元测试

参见：《脚本测试》

3.5、调度任务

脚本开发完成后在调度系统中指定相应时间让任务运行

命名规范

参见：《调度命名规范》

依赖配置

配置脚本涉及到的所有前置任务依赖

资源控制

合理控制任务并发数让资源合理使用，避免任务与任务之间出现资源争抢。

流程控制

根据具体业务情况控制任务优先级、项目与任务之间关联关系

单元测试

参见：《调度任务测试》

3.6、数据质量

确保数据从源到目标加工过程的准确性、完整性、一致性

命名规范

参见：《数据质量命名规范》

源与目标校验

校验源到目标数据，如：记录数、数值汇总、分维度+记录数+数值汇总校验

数据交叉校验

校验源到多目标、多源到目标、相同指标跨表等数据，如：记录数、数值汇总、分维度+记录数+数值汇总校验

数据趋势校验

校验目标表数据历史趋势情况，如：日、周、月、年周期环比、同比校验

单元测试

参见：《数据质量测试》

4、ETL工具选型

ETL工具调研选型结合项目实际情况，主要考虑如下：

1、ETL工具是否收费（只考虑免费）

2、团队整体技术栈（比如：Java）

3、ETL工具熟练程度

4、工具社区活跃情况

5、工具文档完善程序

通过以上几点考虑，第1点就过滤了一大批收费工具，再经过筛选只剩下两款工具，分别是：DataX与Sqoop两款。它们之间的功能对比如下

功能

DataX

Sqoop

运行模式

单进程多线程

MapReduce

MySQL读写

单机压力大；读写粒度容易控制

MapReduce 模式重，写出错处理麻烦

Hive读写

单机压力大

扩展性好

文件格式

orc支持

orc不支持，可添加

分布式

不支持，可以通过调度系统规避

支持

统计信息

已有一些统计，上报需定制

没有，分布式的数据收集不方便

数据校验

在core部分有校验功能

没有，分布式的数据收集不方便

监控

无

无

社区

社区不活跃

核心部分变动很少

DataX 主要的缺点在于单机运行，而这个问题我们通过分布试调度系统规避，其他方面的功能均优于 Sqoop，最终我们选择了基于 DataX 开发。