数仓 ETL 系统：给强大的“心脏”配上“超级流水线”

​​​​摘要：在数据仓库平台建设过程中，数据的加载、卸载，各层数据模型之间的数据流转，业务规则的实现等等数据加工过程都会以 ETL 任务的方式实现。

本文分享自华为云社区《给强大的“心脏”配上“超级流水线”-GaussDB(DWS)数据仓库平台ETL系统建设方案》，原文作者： babu1801 。

一、前言

在数据仓库平台建设过程中，数据的加载、卸载，各层数据模型之间的数据流转，业务规则的实现等等数据加工过程都会以 ETL 任务的方式实现。 构建 ETL 子系统是数据仓库系统实施的一个非常重要的环节，在仓库平台建设过程中搭建一个完整、标准的 ETL 子系统是数据仓库平台建设的基础性目标之一。

ETL 是 Extraction（数据抽取），Transform（数据转换）和 Loading（数据加载）这三个数据处理动作的缩写，也是早期数据仓库建设的数据流转处理顺序，因此形成的专用术语沿用至今。但是随着作为数据仓库核心的数据库引擎技术的不断发展，ETL 模式也在不断发展和改变，逐渐形成了 E-L-T，E-T-L-T 等不同形式。对于 GaussDB DWS 为代表的 MPPDB 数据仓库平台，则多以 ELT 或是 ETLT 模式为主来构建 ETL 子系统。

二、ETL 子系统逻辑参考架构

ETL 子系统的建设目的是将企业中的分散、零乱、标准不统一的异构数据源的业务数据整合到一起，进行必要的清洗和转换，形成高质量的统一的数据模型，或者是便于用户查询，分析和探索的维度模型。

图 1 数据仓库子系统参考架构

​

2.1 数据抽取(Extraction)

数据抽取是从数据仓库的上游系统（通常是核心系统，业务系统或外部系统）进行全量或增量数据抓取的过程。而随着企业内部信息底层架构的完善和数据平台功能的划分，不同平台通常采用松耦合的方式进行关联。传统中下游系统直接到上游系统进行数据抽取的这种方式并不符合当前技术的发展趋势。一方面，下游系统直接到上游系统进行数据抽取操作牵涉到权限的开放管理，增加了上游系统的数据安全风险。另一方面，本身数据抽取操作也应当在业务系统自身正常业务完成后的时间窗口进行，以避免数据抽取时对正常作业流程的资源竞争。因此数据抽取这个环节的操作，通常是上下游系统进行接口协商，由上游系统按照接口规范进行数据卸载操作。或者对于更成熟的企业，会构建统一的数据交换平台来完成企业内部统一的数据抽取/卸载工作。

对于数据仓库平台来说，数据抽取的工作更多的是形成统一的接口规范。

2.2 数据转换(Transform)

广义上的数据转换包括数据清洗，数据关联加工，数据标准化处理，数据汇总聚合等操作。大部分基于业务规则和数据模型的数据转换操作在 MPPDB 数据库内实现比在数据库外的 ETL 服务器上进行实现效率更高。而这种转换操作在数据库内通过 SQL 实现 T 过程，也比通过 ETL 工具实现 T 过程更具有标准化和开放性，适合业务人员参与 T 过程的开发，校验。

2.3 数据加载(Loading)

对于数据仓库而言，不仅仅是数据加载，还包括数据卸载，也就是 Loading 和 Unloading 过程。典型的场景就是在数据到达的高峰期进行大量的文件加载入库的操作。而库内数据加工完成后，及时地进行数据卸载操作，形成接口文件推送给下游系统。所以高效地批量数据加载和卸载操作是数据仓库 ETL 系统要面对的主要挑战之一。而随着客户对实时数据仓库的需求越来越普遍，数据库和消息队列，数据流组件之间的实时数据加载和卸载的技术则是当前 ETL 系统构建时面临的又一个技术挑战。

三、ETL 子系统的两种实现架构

依托 GaussDB(DWS)数据库构建 ETL 系统一般有两种实现方式：重 ETLServer 方案和 MPPDB 方案。如下图

图 2 两种架构示意图

​

3.1 重 ETL Server 方案

这种方案借助专业化的 ETL 软件：Informatica,DataStage, Kettle 等软件，采用分布式的/基于共享存储的 ETL 服务器集群方式部署 ETL 软件。在执行 ETL 任务的时候，数据从 MPPDB 读取出来，数据处理过程在 ETL 服务器完成，处理完结果再推送到数据库服务器，其中有些操作可以通过 SQL Push down 在数据库内完成。

这种方案的特点在于整个 ETL 开发和部署过程图形化操作和脚本化操作方式结合，基于工具过程的开发也可以对 ETL 过程进行基于元数据的血缘分析，影响性分析；作业自动化编排，调度方面 ETL 工具的功能弱于专业的调度软件。

基于 ETL 工具方案对于 ETL 开发过程来说需要专业的开发人员，要对 ETL 工具本身有很深入的了解，从这方面来说，过于专业化的工具门槛不利于企业内部的业务专家和分析人员介入 ETL 开发过程。而 ETL 方面对于软硬件的投入成本也是需要纳入考量的一个问题。

3.2MPPDB 方案

• 本方案中 ETL 服务器轻量化，生产环境一般提供主备服务器避免单点故障即可。主要特点如下：

• 利用 MPPDB 并行处理引擎，海量数据 ETL 处理效率更高。

• ETL 过程 SQL 模板化，快速开发和迭代的过程代价低；

• 汇总层和集市层的 ETL 处理逻辑一般和业务规则强相关，SQL 标准对于业务人员开发门槛低

• 与第三方 ETL 服务器解耦，通过工具封装，可以避免过度依赖某一个 ETL 工具；

• 需要对 ETL 脚本模板进行定制化封装式开发，为运维，优化，数据治理等过程提供底层数据。

3.3 简单对比

重 ETL Server 方案适合基于文件的数据清洗类 ETL 工作：对于字符集的转换处理；按照接口规范对接口数据的预处理（判断文件大小，记录行数等文件信息和属性方面的数据质量检查）；文件的分组，拆分，压缩，解压缩等；以及延伸出去的文件监控和传输功能。

MPPDB 方案实际上就是基于 SQL 的实现方案，适合数据规范化处理：如业务编码转换，业务逻辑主键生成，符合业务规范的数据转换处理；数据转换处理：汇总，聚合，过滤，关联，拆分，转换等。

四、GaussDB(DWS)ETL 系统实现要点

对于 GaussDB(DWS)而言，大多数场合下推荐采用 MPPDB 方案。实现这种方案实际上要实现 ETL SQL 模板的封装，把 ETL 开发过程与外部 ETL 调度系统的结合进行分层处理。通过模板方式实现与调度软件，和操作系统的接口封装，把 SQL 实现业务的模块封装在 GSQL 工具中，开放给业务人员和开发人员，令其聚焦在业务实现本身，而不用在意外部环境对于 ETL 过程操作的影响。

4.1 基于 MPPDB 的 ETL 环境逻辑视图

图 3 逻辑视图

​

• ETL 调度

数据仓库平台的 ETL 作业系统是一种后台非交互方式运行的批量数据处理系统。ETL 作业调度是将数据仓库系统中运行的各种后台作业自动化，并监视和控制作业的运行。使用调度软件实现作业调度。作业可以分布在多个服务器平台上，能够设定作业定义、依赖关系、顺序关系、工作组关系等，方便地对作业进行自动调度、运行和管理。

调度监管平台可以图形方式动态监视和控制作业的运行，对作业执行中出现的错误/警告提供详细的信息。

• ETL 脚本封装

GSQL 是执行 SQL 的工具，但是与调度软件之间的结合还有一定的功能缺失，如参数解析，日志解析，异常处理等，所以需要对 GSQL 进行必要的封装，提高和调度软件之间的契合度。

• gsql 模板

对加工处理的 etl 过程进行抽象，总结，形成算法模板。

指定必要的输入参数，设定会话启动的公共参数，为后续的优化和跟踪埋点打桩。

• 调用形式

调度工具->Python 或其他脚本工具模板->GSQL->{.gsql}

4.2GSQL 封装

图 4 GSQL 封装示意图

​

增加封装的必要性：

GSQL 和调度软件解耦：调度软件都具备调用 Python/Perl/Shell 脚本的能力，通过脚本封装，把 GSQL 和调度软件解耦，降低 GSQL 和调度软件的适配兼容性风险；

封装模板需要考量的功能点：

• 调度命令到 GSQL 运行命令的转换：

调度命令相对简单，和业务逻辑相关：如业务子系统代码，算法模板代码，数据日期等；

GSQL 的运行参数不需要或不应当暴露在调度系统接口下：如登录密码，verbose 参数等级等与业务无关的或者为了便于运维，性能跟踪的额外参数；

• 登录密码加密解密：

GSQL 登录密码不允许明文存储，需要密文方式保存在 ETL 服务器上，执行时候也需要避免出现在后台命令行中被 ps 指令查看到；

• 异常处理：

GSQL 脚本运行出错后的异常处理功能：如重跑，告警通知等；

• 运行日志解析：

GSQL 的运行日志解析：针对 GSQL 脚本中不同语句，不同事务的执行时间解析跟踪，错误，告警代码的解析跟踪，为性能分析提供最详细的底层数据；

五、小结

本文对数据仓库构建 ETL 子系统进行了初步介绍，说明了当前较为主流的两种 ETL 子系统实现架构，比对 MPPDB 数据库的 ETL 架构进行了对比说明。最后对 GaussDB(DWS)下的 ETL 子系统的实现要点进行了梳理，重点对 etl 实现的逻辑视图以及 GSQL 封装的功能要点进行了阐述。在今后的篇章，作者会对 gsql 的具体封装实现的最佳实践做个更为详细的介绍。

点击关注，第一时间了解华为云新鲜技术~