2.1 什么是数据工程生命周期

数据工程生命周期包括将原始数据成分转化为有用的最终产品的阶段，可供分析师、数据科学家、机器学习工程师和其他人使用。本章将介绍数据工程生命周期的主要阶段，重点介绍每个阶段的核心概念，并将详细信息留到后面的章节。

我们将数据工程生命周期分为五个阶段（如图2-1所示）：

• 生成

• 存储

• 获取

• 转换

• 服务

我们通过从源系统获取数据并进行存储来开始数据工程生命周期。接下来，我们转换数据，然后继续我们的中心目标，为分析师、数据科学家、ML工程师和其他人提供数据。实际上，随着数据从开始流向结束，存储贯穿整个生命周期——因此，图2-1将存储“阶段”显示为支撑其他阶段的基础。

一般来说，中间阶段——存储、获取、转换——可能会有点混乱。没关系。虽然我们拆分了数据工程生命周期的不同部分，但它并不总是一个整齐、连续的流程。生命周期的各个阶段可能会以有趣和意想不到的方式重复、无序、重叠或交织在一起。

作为基石的是横跨数据工程生命周期多阶段的底层设计（如图2-1所示）：安全、数据管理、DataOps、数据架构、编排和软件工程。没有这些底层设计，数据工程生命周期的任何部分都无法充分发挥作用。

2.1.1 数据生命周期与数据工程生命周期

你可能想知道整体数据生命周期和数据工程生命周期之间的区别。两者之间的区别很微妙。数据工程生命周期是完整数据生命周期的一个子集（如图2-2所示）。完整的数据生命周期涵盖整个生命周期中的数据，而数据工程生命周期则侧重于数据工程师控制的阶段。

2.1.2 生成：源系统

源系统是数据工程生命周期中使用的数据的来源。例如，源系统可以是IoT设备、应用程序的消息队列或事务数据库。数据工程师消费来自源系统的数据，但通常不拥有或控制源系统本身。数据工程师需要对源系统的工作方式、它们生成数据的方式、数据的频率和速度以及它们生成的数据的多样性有一个工作上的理解。

工程师还需要与源系统所有者保持开放的沟通渠道，了解可能破坏管道和分析的更改。应用程序代码可能会更改一个领域中的数据结构，或者应用程序团队甚至可能选择将后端迁移到全新的数据库。

数据工程的一个主要挑战是工程师必须处理和理解令人眼花缭乱的数据源阵列。作为说明，让我们看一下两个常见的源系统，一个非常传统（应用程序数据库），另一个是最近的例子（物联网集群）。

图2-3展示了一个包含多个由数据库支持的应用程序服务器的传统的源系统。随着关系数据库管理系统（Relational Database Management System，RDBMS）的爆炸性成功，这种源系统模式在20世纪80年代开始流行。随着软件开发实践的各种现代演变，应用程序+数据库模式在今天仍然很流行。例如，应用程序通常由许多带有微服务的小型服务/数据库对组成，而不是一个单体。

让我们看一下源系统的另一个例子。图2-4展示了物联网集群：一组设备（圆圈）将数据消息（矩形）发送到中央收集系统。随着传感器、智能设备等物联网设备在野外的增加，这种物联网源系统越来越普遍。

评估源系统：关键工程注意事项

评估源系统时需要考虑很多事情，包括系统如何处理获取、状态和数据生成。以下是数据工程师在启动环境中必须考虑的一组源系统评估问题：

• 数据源的本质特征是什么？它是一个应用程序，还是一个物联网设备集群？

• 数据如何持久化在源系统中？数据是长期保存的，还是临时的并被迅速删除？

• 数据生成的速率是多少？每秒有多少事件？每小时有多少数据量？

• 数据工程师从输出数据中期望什么程度的一致性？如果你对输出数据进行数据质量检查，数据不一致（数据空值、糟糕的格式等）的发生频率是多少？

• 错误发生的频率如何？

• 数据会包含重复项吗？

• 某些数据是否会延迟到达，是否会比同时生成的其他消息晚很多？

• 获取数据的模式是什么？数据工程师是否需要跨多个表甚至多个系统进行连接才能获得数据的全貌？

• 如果数据结构发生变化（例如，添加了一个新列），如何处理并传达给下游利益相关者？

• 应该多久从源系统中提取一次数据？

• 对于有状态系统（例如，跟踪客户账户信息的数据库），数据是否以定期快照或变更数据捕获（Change Data Capture，CDC）的更新事件提供？执行更改的逻辑是什么？如何在源数据库中跟踪这些更改？

• 将为下游消费传输数据的数据提供者是谁/什么？

• 从数据源读取会影响其性能吗？

• 源系统是否有上游数据依赖？这些上游系统的特点是什么？

• 是否进行了检查延迟或丢失的数据的质量检查？

数据源产生的数据供下游系统消费，包括人工生成的电子表格、物联网传感器以及网络和移动应用程序。每个来源都有其独特的数据生成量和节奏。数据工程师应该知道来源如何生成数据，包括相关的怪癖或细微差别。数据工程师还需要了解他们交互的源系统的限制。例如，针对源应用程序数据库的分析查询是否会导致资源争抢和性能问题？

源数据最具挑战性的细微差别之一是模式。模式定义了数据的层次结构。从逻辑上讲，我们可以在整个源系统层面考虑数据，深入到各个表，一直到各个字段的结构。从源系统传输的数据模式有多种处理方式。两个流行的选项是无模式和固定模式。

无模式并不意味着没有模式。相反，它意味着应用程序在写入数据时定义模式，无论是写入消息队列、平面文件、blob还是文档数据库（如MongoDB）。建立在关系数据库存储之上的更传统的模型使用数据库中强制执行的固定模式，应用程序写入必须符合该模式。

这些模型中的任何一种都对数据工程师提出了挑战。模式随时间变化；事实上，在软件开发的敏捷方法中鼓励模式演变。数据工程师工作的一个关键部分是在源系统模式中获取原始数据输入，并将其转换为有价值的分析输出。随着源模式的发展，这项工作变得更具挑战性。

我们将在第5章更详细地探讨源系统，我们还将在第6章和第8章分别介绍模式和数据建模。

2.1.3 存储

你需要一个地方来存储数据。选择存储解决方案是在数据生命周期其余部分取得成功的关键，而且出于各种原因，它也是数据生命周期中最复杂的阶段之一。首先，云上的数据架构通常利用多种存储解决方案。其次，很少有数据存储解决方案纯粹用作存储，许多支持复杂的转换查询，甚至对象存储解决方案也可能支持强大的查询功能——例如Amazon S3 Select（https://oreil.ly/XzcKh）。再次，虽然存储是数据工程生命周期的一个阶段，但它经常涉及其他阶段，例如获取、转换和服务。

存储贯穿整个数据工程生命周期，通常发生在数据管道的多个位置，存储系统与源系统、获取、转换和服务交叉。在许多方面，数据的存储方式会影响数据在数据工程生命周期的所有阶段中的使用方式。例如，云数据仓库可以存储数据，在管道中处理数据，并将其提供给分析师。Apache Kafka和Pulsar等流式框架可以同时作为消息的获取、存储和查询系统，对象存储是数据传输的标准层。

评估存储系统：关键工程考虑因素

以下是在为数据仓库、数据湖仓一体、数据库或对象存储选择存储系统时要问的几个关键工程问题：

• 该存储解决方案是否与架构所需的写入和读取速度兼容？

• 存储是否会给下游流程造成瓶颈？

• 你了解这种存储技术的工作原理吗？你是在最佳地利用存储系统还是在做出不自然的行为？例如，你是否在对象存储系统中应用了高速率的随机访问更新？（这是一种具有显著性能开销的反模式。）

• 该存储系统能否处理预期的未来规模？你应该考虑存储系统的所有容量限制：可用存储总量、读取操作率、写入量等。

• 下游用户和进程是否能够在所需的服务等级协定（Service Level Agreement，SLA）中检索数据？

• 你是否正在捕获有关模式演变、数据流、数据血缘等的元数据？元数据对数据的效用有重大影响。元数据代表了对未来的投资，显著提高了可发现性和机构知识，以简化未来的项目和架构变化。

• 这是一个纯存储解决方案（对象存储），还是支持复杂的查询模式（即云数据仓库）？

• 存储系统是模式不可知的（对象存储）吗？是灵活的模式（Cassandra）吗？是强制模式（云数据仓库）吗？

• 你如何跟踪主数据、黄金记录数据质量和数据血缘以进行数据治理？（我们在2.2.2节中对此有更多阐述。）

• 你如何处理法规遵从性和数据主权？例如，你能否将数据存储在某些地理位置而不是其他位置？

了解数据访问频率

并非所有数据都以相同的方式访问。检索模式将因存储和查询的数据不同而有很大差异。这就提出了数据“温度”的概念。数据访问频率将决定数据的温度。

访问频率最高的数据称为热数据。热数据通常每天被检索多次，甚至每秒可能被检索几次——例如，在为用户请求提供服务的系统中。应存储此种数据以便被快速检索，其中“快速”与使用情况相关。不冷不热的数据可能会每隔一段时间访问一次——比如，每周或每月。

冷数据很少被查询，适合存储在归档系统中。出于合规目的或在另一个系统发生灾难性故障的情况下，通常会保留冷数据。在“过去”，冷数据将存储在磁带上并运送到远程档案设施。在云环境中，供应商提供专门的存储层，每月存储成本非常低廉，但数据检索的价格很高。

选择存储系统

你应该使用哪种类型的存储解决方案？这取决于你的用例、数据量、获取频率、格式和获取数据的大小——本质上，是前面列出的问题中列出的关键考虑因素。没有放之四海而皆准的通用存储建议，每种存储技术都有其权衡取舍。存在无数种存储技术，你在为数据架构决定最佳选择时很容易不知所措。

第6章将更详细地介绍存储的最佳实践和方法，以及存储与其他生命周期阶段之间的交叉问题。

2.1.4 获取

在了解数据源、所用源系统的特征以及数据的存储方式之后，你需要收集数据。数据工程生命周期的下一阶段是从源系统中获取数据。

根据我们的经验，源系统和获取代表了数据工程生命周期中最重要的瓶颈。源系统通常不在你的直接控制范围内，可能会随机变得无响应或提供质量差的数据。或者，你的数据获取服务可能出于多种原因神秘地停止工作。结果，数据流停止或提供的数据不足以进行存储、处理和服务。

不可靠的源和获取系统会在整个数据工程生命周期中产生连锁反应。但是你的状态很好，假设你已经回答了关于源系统的大问题。

获取阶段的关键工程考虑因素

在准备架构或构建系统时，以下是一些有关获取阶段的主要问题：

• 我正在获取的数据的用例有哪些？我可以重用这些数据而不是创建同一数据集的多个版本吗？

• 系统是否可靠地生成和获取这些数据，这些数据是否在我需要时可用？

• 获取后的数据目的地是什么？

• 我需要多久访问一次数据？

• 数据通常以多大的体积到达？

• 数据的格式是什么？我的下游存储和转换系统可以处理这种格式吗？

• 源数据是否处于良好状态以供直接下游使用？如果是这样，持续多长时间，什么可能导致它无法使用？

• 如果数据来自流媒体源，是否需要在到达目的地之前进行转换？在数据流本身内转换数据的情况下，进行中的转换是否合适？

这些只是你在获取时需要考虑的因素的示例，我们将在第7章中讨论这些问题以及更多内容。接下来，让我们简要地把注意力转向两个主要的数据获取概念：批处理与流处理和推送与拉取。

批处理与流处理

实际上，我们处理的所有数据本质上都是流式传输的。数据几乎总是在其源头不断地产生和更新。批量获取只是一种专门且方便的大块处理数据流的方法——例如，在单个批次中处理一整天的数据。

流式获取使我们能够以连续、实时的方式向下游系统——无论是其他应用程序、数据库还是分析系统——提供数据。在这里，实时（或接近实时）意味着数据在生成后的很短的时间内（例如，不到1秒后）就可以供下游系统使用。符合实时性要求的延迟因领域和要求而异。

批量数据在预定的时间间隔或当数据达到预设大小阈值时被获取。批量获取是一扇单向门：一旦数据被分成批次，下游消费者的延迟就会受到固有的限制。由于遗留系统的局限性，批处理长期以来一直是获取数据的默认方式。批处理仍然是为下游消费提取数据的一种非常流行的方式，特别是在分析和ML中。

然而，许多系统中存储和计算的分离以及事件流和处理平台的普遍存在，使得数据流的连续处理更容易获得并且越来越受欢迎。选择在很大程度上取决于使用情况和对数据实时性的期望。

批量获取与流式获取的关键考虑因素

你应该选择流处理吗？尽管流处理方法很有吸引力，但仍有许多权衡因素需要理解和思考。以下是在确定流式获取是否比批量获取更合适时要问自己的一些问题：

• 如果我实时获取数据，下游存储系统能否处理数据流的速率？

• 我需要毫秒级的实时数据获取吗？或者采用微批处理方法，例如每分钟收集和获取数据？

• 流式获取的用例有哪些？通过实施流处理，我有哪些具体优势？如果我实时获取数据，我可以对这些数据采取什么行动来改进批处理？

• 流处理方法在时间、金钱、维护、停机时间和机会成本方面是否会比简单地进行批处理花费更多？

• 如果基础设施出现故障，我的流处理管道和系统是否可靠且冗余？

• 哪些工具最适合用例？应该使用托管服务（Amazon Kinesis、Google Cloud Pub/Sub、Google Cloud Dataflow）还是建立自己的Kafka、Flink、Spark、Pulsar等实例？如果我选择后者，谁来管理它？成本和权衡是什么？

• 如果我正在部署ML模型，在线预测和可能的持续训练对我有什么好处？

• 我是从实时生产实例获取数据吗？如果是这样，我的获取过程对此源系统有何影响？

如你所见，流处理似乎是个好主意，但它并不总是直截了当的；额外的成本和复杂性必然会发生。许多出色的获取框架确实可以处理批处理和微批处理获取方式。我们认为批处理是许多常见用例的绝佳方法，例如模型训练和每周报告。只有在确定了可以权衡使用批处理的业务用例之后，才能采用真正的实时流。

推送与拉取

在数据获取的推送模型中，源系统将数据写入目标系统，无论是数据库、对象存储还是文件系统。在拉取模型中，数据是在源系统中检索。推送和拉取范式之间的界限可能非常模糊。数据在数据管道的各个阶段工作时，经常会被推送和拉取。

例如，考虑抽取、转换、加载过程，通常用于面向批处理的获取工作流。ETL的抽取部分阐明了我们正在处理拉取获取模型。在传统的ETL中，获取系统按固定的时间表查询当前源表快照。在本书中，你将了解有关ETL和抽取、加载、转换（Extract，Load，Transform，ELT）的更多信息。

在另一个示例中，考虑通过几种方式实现的连续CDC。每当源数据库中的一行发生更改时，一种常用方法都会触发一条消息。这条消息被推送到一个队列中，获取系统在队列中获取它。另一种常见的CDC方法使用二进制日志，它记录对数据库的每次提交。数据库推送到它的日志。获取系统读取日志但不直接与数据库交互。这几乎不会对源数据库增加额外负载。某些版本的批处理CDC使用拉取模式。例如，在基于时间戳的CDC中，获取系统查询源数据库并提取上次更新以来已更改的行。

通过流式获取，数据绕过后端数据库并直接推送到终端，通常由事件流平台缓冲数据。此模式对于发射传感器数据的IoT传感器队列很有用。我们不是依靠数据库来维护当前状态，而是简单地将每个记录的读数视为一个事件。这种模式在软件应用程序中也越来越受欢迎，因为它简化了实时处理，允许应用程序开发人员为下游分析定制消息，并极大地简化了数据工程师的工作。

我们将在第7章中深入讨论获取的最佳实践和技术。接下来，让我们转向数据工程生命周期的转换阶段。

2.1.5 转换

在获取和存储数据后，你需要对其进行一些操作。数据工程生命周期的下一个阶段是转换，这意味着数据需要从其原始形式转变为对下游用例有用的形式。如果没有适当的转换，数据将处于惰性状态，并且不会以对报告、分析或ML有用的形式出现。通常，转换阶段是数据开始为下游用户消费创造价值的阶段。

在获取后，基本转换立即将数据映射到正确的类型（例如，将获取的字符串数据更改为数字和日期类型），将记录放入标准格式，并删除错误的记录。转换的后期阶段可能会转换数据模式并应用规范化。在下游，我们可以应用大规模聚合来报告或对ML过程的数据进行特征化。

转换阶段的主要考虑因素

在数据工程生命周期内考虑数据转换时，考虑以下内容会有所帮助：

• 转换的成本和投资回报率（Return On Investment，ROI）是多少？相关的商业价值是什么？

• 转换是否尽可能简单和自我隔离？

• 转换支持哪些业务规则？

你可以批量转换数据，也可以在传输过程中进行流式转换。正如2.1.4节所述，几乎所有数据都以连续流的形式开始，批处理只是处理数据流的一种特殊方式。批处理转换非常受欢迎，但鉴于流处理解决方案的日益普及和流数据量的普遍增加，我们预计流式转换的受欢迎程度将继续增长，也许很快就会在某些领域完全取代批处理。

从逻辑上讲，我们将转换视为数据工程生命周期的一个独立领域，但生命周期的实际情况在实践中可能要复杂得多。转换通常与生命周期的其他阶段纠缠在一起。通常，数据在源系统中或在获取传输期间进行转换。例如，源系统可以在将记录转发到获取过程之前，在记录中添加事件时间戳。或者，在将流式传输管道中的记录发送到数据仓库之前，可能会使用其他字段和计算对记录进行“丰富”。转换在生命周期的各个部分无处不在。数据准备、数据整理和清洗——这些转换任务为数据的最终消费者增加了价值。

通常在数据建模中，业务逻辑是数据转换的一个主要驱动力。数据将业务逻辑转化为可重复使用的元素（例如，一次销售意味着“有人以每个30美元的价格从我这里购买了12个相框，或者总共360美元”）。在这种情况下，有人以每个30美元的价格购买了12个相框。数据建模对于获取一个清晰的和当前的业务流程至关重要。如果不添加会计规则逻辑以便CFO清楚地了解财务状况，那么简单地查看原始零售交易可能没有用。确保采用标准方法以在你的转换中实现业务逻辑。

ML的数据特征化是另一个数据转换过程。特征化旨在提取和增强对训练ML模型有用的数据特征。特征化可能是一门暗黑艺术，它结合了领域专业知识（以确定哪些特征可能对预测很重要）与数据科学方面的丰富经验。对于本书，要点是一旦数据科学家确定了如何对数据进行特征化，特征化过程就可以由数据工程师在数据管道的转换阶段自动化完成。

转换是一个深刻的主题，我们不能在这个简短的介绍中对其进行公正的介绍。第8章将深入探讨查询、数据建模以及各种转换实践和细微差别。

2.1.6 服务

你已经到了数据工程生命周期的最后阶段。现在数据已被获取、存储并转换为连贯且有用的结构，是时候从你的数据中获取价值了。从数据中“获取价值”对不同的用户意味着不同的事情。

当数据用于实际目的时，它才有价值。未使用或未查询的数据只是惰性的。数据虚荣项目是公司的一个主要风险。许多公司在大数据时代追求虚荣项目，在数据湖中收集大量数据集，这些数据集从未以任何有用的方式使用过。云时代正在引发新一波建立在最新数据仓库、对象存储系统和流技术上的虚荣项目。数据项目必须贯穿整个生命周期。如此仔细收集、清洗和存储数据的最终商业目的是什么？

数据服务可能是数据工程生命周期中最令人兴奋的部分。这就是魔法发生的地方。这是ML工程师可以应用最先进技术的地方。让我们看一下数据的一些流行用途：分析、ML和反向ETL。

分析

分析是大多数数据工作的核心。一旦你的数据被存储和转换，你就可以生成报告或仪表板并对数据进行临时分析。虽然过去大部分分析都包含BI，但现在它还包括其他方面，例如运营分析和嵌入式分析（如图2-5所示）。让我们简要介绍一下分析的这些变化。

商业智能。BI通过收集数据来描述企业的过去和当前状态。BI需要使用业务逻辑来处理原始数据。请注意，用于分析的数据服务是数据工程生命周期各个阶段可能会纠缠在一起的另一个领域。正如我们前面提到的，业务逻辑通常在数据工程生命周期的转换阶段应用于数据，但读取逻辑方法越来越流行。数据以干净但相当原始的形式存储，具有最少的后处理业务逻辑。BI系统维护一个业务逻辑和定义的存储库。此业务逻辑用于查询数据仓库，以使报告和仪表板与业务定义保持一致。

随着公司数据成熟度的提高，它将从临时数据分析转向自助服务分析，从而允许业务用户在不需要IT干预的情况下以民主化的方式访问数据。进行自助服务分析的前提是数据足够好，整个组织的人都可以简单地访问它，按照自己的选择对它进行切片和切块，并立即获得洞察力。尽管自助服务分析在理论上很简单，但在实践中却很难实现，主要原因是数据质量差、组织孤岛和缺乏足够的数据技能通常会阻碍分析技术的广泛使用。

运营分析。运营分析侧重于运营的精细细节，促进报告用户可以立即采取行动。运营分析可以是库存的实时视图，也可以是网站或应用程序运行健康状况的实时仪表板。在这种情况下，数据是实时消费的，直接来自源系统或流数据管道。运营分析中的洞察类型与传统BI不同，因为运营分析侧重于当前，不一定关注历史趋势。

嵌入式分析。你可能想知道为什么我们将嵌入式分析（面向客户的分析）与BI分开。在实践中，在SaaS平台上提供给客户的分析带有一组单独的要求和复杂性。内部BI面向的受众有限，一般呈现的统一视图数量有限。访问控制很关键，但并不特别复杂。我们使用少数角色和访问层来管理访问。

使用嵌入式分析，报告的请求率以及相应的分析系统负担会急剧上升，访问控制明显变得更加复杂和关键。企业可能正在为成千上万或更多的客户提供单独的分析和数据。每个客户都必须看到他们的数据，而且只能看到他们的数据。公司的内部数据访问错误可能会导致程序审查。客户之间的数据泄露将被视为严重违反信任，导致媒体关注和客户大量流失。要最大限度地减少与数据泄露和安全漏洞相关的爆炸半径。在你的存储中以及任何可能发生数据泄露的地方应用租户级或数据级安全。

机器学习

机器学习的出现和成功是最激动人心的技术革命之一。一旦组织达到高水平的数据成熟度，他们就可以开始识别适合机器学习的问题并开始围绕它组织实践。

数据工程师的职责在分析和机器学习方面有很大的重叠，而且数据工程、机器学习工程和分析工程之间的界限可能很模糊。例如，数据工程师可能需要支持有助于分析管道和机器学习模型训练的Spark集群。他们可能还需要提供一个系统来协调跨团队的任务，并支持跟踪数据历史和血缘的元数据和编目系统。设置这些责任范围和相关的报告结构是一个关键的组织决策。

特征存储是最近开发的一种结合了数据工程和机器学习工程的工具。特征存储旨在通过维护特征历史和版本、支持团队之间的特征共享，以及提供基本的操作和编排功能（例如回填）来减轻机器学习工程师的操作负担。在实践中，数据工程师是支持机器学习工程的特征存储的核心支持团队的一部分。

数据工程师应该熟悉机器学习吗？这当然有帮助。无论数据工程、机器学习工程、业务分析等之间的操作边界如何，数据工程师都应该保持对其团队的操作知识。优秀的数据工程师熟悉基本的机器学习技术和相关数据处理要求、公司内模型的用例，以及组织各个分析团队的职责。这有助于保持有效的沟通并促进合作。理想情况下，数据工程师将与其他团队合作构建任何一个团队都无法独立开发的工具。

本书不可能深入介绍机器学习。如果你有兴趣了解更多信息，可以使用不断增长的书籍、视频、文章和社区生态系统。我们在2.4节将提供一些建议。

以下是针对机器学习的服务数据阶段的一些注意事项：

• 数据质量是否足以执行可靠的特征工程？质量要求和评估是与使用数据的团队密切合作制定的。

• 数据是否可发现？数据科学家和机器学习工程师能否轻松找到有价值的数据？

• 数据工程和机器学习工程之间的技术和组织边界在哪里？这个组织问题具有重要的架构含义。

• 数据集是否正确代表了基本事实？是否存在偏见？

虽然机器学习令人兴奋，但我们的经验是，公司往往过早地投入其中。在将大量资源投入机器学习之前，请花时间建立坚实的数据基础。这意味着在数据工程和机器学习生命周期中建立最佳系统和架构。通常最好在转向机器学习之前先培养分析能力。许多公司已经因为在没有适当基础的情况下采取举措而破灭了机器学习梦想。

反向ETL

反向ETL长期以来一直是数据中的一个实际现实，被视为一种我们不喜欢谈论或用名字来表示的反模式。反向ETL从数据工程生命周期的输出端获取经过处理的数据，并将其反馈回源系统，如图2-6所示。实际上，这种流程是有益的，而且通常是必要的。反向ETL允许我们进行分析、评分等，并将这些反馈回生产系统或SaaS平台。

营销分析师可能会使用其数据仓库中的数据在Microsoft Excel中计算出价，然后将这些出价上传到Google Ads。这个过程通常是完全手动的和原始的。

在我们撰写本书时，一些供应商已经接受了反向ETL的概念并围绕它构建了产品，例如Hightouch和Census。反向ETL作为一种实践仍处于初期阶段，但我们怀疑它会一直存在。

随着企业越来越依赖SaaS和外部平台，反向ETL变得尤为重要。例如，公司可能希望将特定指标从其数据仓库推送到客户数据平台或CRM系统。广告平台是另一个日常用例，如Google Ads示例。预计在反向ETL中我们会看到更多活动，其中数据工程和ML工程都有重叠。

关于反向ETL一词是否会继续存在尚无定论。这种做法可能会演变。一些工程师声称我们可以通过在事件流中处理数据转换并根据需要将这些事件发送回源系统来消除反向ETL。实现跨企业广泛采用这种模式是另一回事。要点是，转换后的数据需要以某种方式返回到源系统，最好是与源系统相关联的正确沿袭和业务流程。