数据管道速查手册

第 6 章 数据转换 数据转换

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在第 3 章定义的 ELT 模式中，一旦数据被输入数据湖或数据仓库（第 4 章），管道的下一步就是数据转换。 数据转换既包括对数据进行非上下文操作，也包括根据业务上下文和逻辑对数据进行建模。

如果管道的目的是产生业务洞察或分析，那么除了任何非上下文转换外，数据还要进一步转换为数据模型。回顾第 2 章，数据模型以可理解和优化的数据分析格式构建和定义数据。数据模型在数据仓库中表示为一个或多个表。

尽管数据工程师有时会在管道中构建非上下文转换，但数据分析师和分析工程师处理绝大多数数据转换已成为一种典型的做法。由于 ELT 模式的出现（他们所需的数据就在仓库中！）以及以 SQL 为主要语言设计的支持工具和框架，这些角色的人员比以往任何时候都更有能力。

本章将探讨几乎每个数据管道都会用到的非上下文转换，以及支持仪表盘、报告和一次性业务问题分析的数据模型。由于 SQL 是数据分析师和分析工程师的语言，因此大多数转换代码示例都是用 SQL 编写的。我在这里提供一些用 Python 编写的示例，以说明在什么情况下使用强大的 Python 库将非上下文转换与数据摄取紧密结合是有意义的。

与第4章和第 5 章中的数据摄取一样，这些代码示例经过了高度简化，旨在作为更复杂转换的起点。要了解如何运行和管理转换与管道中其他步骤之间的依赖关系，请参阅第 8 章。

SQL 兼容性

本章中的 SQL 查询可在大多数 SQL 方言中运行。这些查询使用了有限的特定供应商语法，只需稍加修改或无需修改即可在任何支持 SQL 的现代数据库上运行。

非语境转换

在第 3 章中，我简要地指出了 EtLT 子模式的存在，其中小写t代表一些非上下文数据转换，如以下内容：

• 重复表格中的记录

• 将 URL 参数解析为单个组件

虽然有无数的示例，但通过提供这些转换的代码示例，我希望能涵盖一些非上下文转换的常见模式。下一节将讨论在数据摄取（ETLT）和数据摄取后（ELT）过程中执行这些转换的合理性。

重复表中的记录

尽管并不理想，但在数据仓库的数据表中还是有可能存在重复记录。 出现这种情况有多种原因：

• 增量数据摄取会错误地与之前的摄取时间窗口重叠，并拾取一些在之前的运行中已经摄取的记录。

• 无意中在源系统中创建了重复记录。

• 回填的数据与摄取时加载到表中的后续数据重叠。

无论什么原因，检查和删除重复记录最好使用 SQL 查询。以下每个 SQL 查询都涉及表 6-1 所示数据库中的Orders 表。该表包含五条记录，其中两条是重复的。虽然OrderId 1 有三条记录，但第二行和第四行完全相同。本示例的目的是识别并解决这一重复问题。虽然本例中有两条完全相同的记录，但如果表中有三条、四条甚至更多相同记录的副本，下面代码示例中的逻辑也是有效的。

表 6-1. 有重复订单的订单表

订单号	订单状态	最后更新
1	已被预订	2020-06-01
1	已发货	2020-06-09
2	已发货	2020-07-11
1	已发货	2020-06-09
3	已发货	2020-07-12

如果您想创建一个这样的Orders 表，并在例6-1和例6-2 中使用，下面是实现这一目的的 SQL：

CREATE TABLE Orders (
  OrderId int,
  OrderStatus varchar(30),
  LastUpdated ...