ETL、ELT 和逆向 ETL
如何将来自多个源的数据引入您的数据仓库，然后通过将洞察推送到可利用的地方来实现数据的操作化。
我们将广泛讨论如何将您收集的所有数据置于可以利用的位置。这里的想法是为您提供一些词汇和基本概况，了解这“ELT 字母汤”到底是什么。
具体来说，我们将讨论数据的提取、转换和加载。随着组织的发展，您将添加更多数据源，虽然您可以单独分析这些数据孤岛（例如报告收入），但最终您会希望整合这些数据，并将其放在一个可以基于其做出决策的地方。
我们将从一个问题开始，即*如何将数据转换为便于查询的结构 (ETL)*，然后讨论*如何利用您获得的答案 (逆向 ETL)*，并在此过程中深入探讨所涉及的工具。
提取、转换、加载
首先，我们绕道定义术语并区分 ELT 和 ETL。广义上讲，这些术语指的是为在数据仓库或数据集市中进行分析而准备数据，但具体来说，这些字母代表：
- 提取 (Extract)：从您的应用程序和您使用的其他服务中获取数据。
- 转换 (Transform)：清理、筛选、格式化、聚合、组合、丰富数据，并通常组织数据，以便更轻松地在数据库中创建模型（例如对客户进行建模）。
- 加载 (Load)：将数据存储到数据仓库中（或者在逆向 ETL 的情况下，推送到第三方服务）。
ETL 与 ELT
更复杂的是，当人们说 ETL 时，通常指的是 ETL 或 ELT，或两者兼而有之。这些首字母缩略词（您读出每个字母；是 E.T.L.，而不是“ettle”）指的是从源获取数据、对其进行处理并将其存储在某个地方以便人们查询的通用过程。ETL 和 ELT 之间的关键区别在于，ETL 的数据转换步骤发生在数据仓库外部。
过去，您会使用单个工具，如 Informatica，来提取、转换和加载数据到您的数据仓库中，但随着世界向 ELT 范式发展，您会看到更多专门用于该过程每个部分的工具。
典型的 ETL 管道
数据源 -> 分布式处理软件，如 Hadoop、Spark 或 Informatica -> 数据仓库，如 Redshift、BigQuery 或 Snowflake。
运行在服务器集群上的 Hadoop、Spark 或 Informatica 作业在将数据加载到数据仓库之前，会清理、丰富、聚合和组织数据。
典型的 ELT 管道
数据源 -> 提取工具，如 Fivetran -> 数据仓库（Redshift、BigQuery、Snowflake） -> 在数据仓库中由 DBT 等软件定义和调度的转换作业。
随着数据仓库的改进，越来越多的人直接提取数据，并将原始、未经转换的数据加载到数据仓库中。一旦进入数据仓库，他们就会对其进行转换，将原始数据组织成更容易分析的表：例如，收集记录的事实表和收集聚合数据的汇总表。
总的来说，世界正朝着 ELT 方法发展，主要有三个原因：
- 数据仓库技术已改进；它们现在可以处理传统上由 Hadoop 集群等完成的计算工作。
- 您还可以将原始数据存储在数据仓库中，这使得您将来可以进行不同的转换，以回答关于数据的新问题。
- 数据仓储成本也大大降低了（这是一件好事）。
何时优先选择 ETL
话虽如此，ETL 仍然有很好的用例（Metabase 公司同时使用这两种方法）。当您满足以下条件时，ETL 是一个不错的选择：
- 您有特别复杂的数据转换（有时称为转换），
- 或者您希望在将数据加载到数据仓库之前对其运行机器学习，
- 或者您需要更改数据格式以满足数据库规范。
从 ETL 到逆向 ETL 的数据流示例
让我们简化一下，假设您只从三个来源收集数据：
现在，假设您想知道*客户支持如何影响留存率*。要分析这种影响，您需要审查来自 Stripe 的订阅数据，并将其与 Zendesk 的支持数据进行比较。
提取数据
尽管您*可以*自行开发数据提取工具，但通常您会希望使用一项服务来为您处理这种复杂性（例如跟进每个 API、调度作业、处理错误等等）。
在评估提取工具时，您会希望寻找具备以下选项的工具：
- 拥有您需要的所有连接器。一旦选择了一个工具，请务必在评估其他相关工具时考虑其连接器库。例如，如果您选择了 Fivetran，之后又发现自己在寻找电子邮件营销平台，请考虑选择 Fivetran 支持的平台。
- 能够增量提取数据（而非简单的批处理）。您可能不需要实时数据，但您可能希望在几分钟内而不是每天一次地获取更新。
- 不更改数据，或至少不要显著更改。您应该负责转换数据，而不是提取服务。
该领域有很多选择：Airbyte、Peliqan、Fivetran、Segment、Singer 和 Stitch。
将数据加载到数据仓库
在此上下文中，“加载”仅表示将数据放入存储（有时称为数据槽）。这个数据存储可以是标准的事务型数据库，如 PostgreSQL 或 MySQL，也可以是与 Presto 等查询引擎搭配使用的简单文件系统，如 S3，或者是为分析查询优化的数据仓库，如 BigQuery、Redshift 或 Snowflake。
数据仓库的概述超出了本文的范围，因此我们只会将您引向“您应该使用哪种数据仓库？”。对于本文，您可以更广义地（理想情况下）将数据仓库视为您的单一真相来源。
转换数据
有许多不同的方法可以清理、筛选、格式化、丰富或以其他方式转换您的数据，包括将其与其他数据结合。您也可以汇总数据，例如确定某个过程的开始和停止时间以计算其持续时间。
在 ELT 的世界中，您会希望使用一个与数据仓库配合的工具，来获取原始数据，对其进行转换，然后将转换后的数据插入到数据仓库中的其他表中。这样，您就可以在同一个数据仓库中保留从各种来源提取的原始数据，以及这种经过清理、可用于建模和分析的数据。
在评估数据转换工具时，您会希望软件具备以下特点：
- 以 SQL 作为其主要语言。坚持使用一种语言会更简单，而且大多数数据库都理解 SQL。
- 允许您对 SQL 进行版本控制。如果您更改了查询并发现数据不正确，您会希望回滚到该查询的先前版本，以找出问题所在。
- 可以测试您的代码，例如，确认输出中的所有 ID 都是唯一的。
- 允许您记录这些作业，理想情况下应捕获字段数据和沿袭（以便您了解数据的来源）。
现在您对数据有了洞察，如何利用它呢？
回到我们关于客户支持是否能提高留存率的例子。假设您了解到，在客户年度订阅期的最后九十天内关闭支持工单可以显著提高留存率。那么您接下来要做的是，在 Zendesk 中标记那些即将结束年度订阅的客户提交的帮助工单，并可能在他们的续订日期临近时联系他们，看看您是否能帮助他们充分利用您的服务。
有几种方法可以将此洞察整合到您的帮助工单系统中：
- 您可以手动运行报告以查看哪些公司即将续订，在 Zendesk 中添加一列显示客户是否为
UP_FOR_RENEWAL，并优先处理这些工单。 - 构建一个自定义工具，每晚运行，然后使用 Zendesk 的 API 更新 Zendesk 中的列。
- 使用 Zapier 等工具协调 Stripe 和 Zendesk 之间的数据。
- 使用 Census 等工具将此数据点从您的数据仓库推送到相关应用程序（在本例中为 Zendesk）。
逆向 ETL，或数据操作化
典型的逆向 ETL 管道
逆向 ETL 是将数据仓库中已清理和组织好的数据，发送到您的团队使用的工具（例如 Salesforce、Zendesk 或营销平台）的过程，以便他们在日常工作中可以使用这些数据。
数据可以通过两种主要方式从您的数据仓库推送到其他工具：一是通过监听应用程序中的事件并更新其他应用程序以保持同步，二是通过将数据直接从单一真相来源推送到相关应用程序。
我们强烈推荐单一真相来源方法，因为它大大降低了保持应用程序与所需数据同步的复杂性。Zapier 等工具需要努力使您的各种应用程序保持同步，而 Census 等工具只需定期从您的数据仓库读取数据，并将更新推送到需要的地方。
这里的重要思想是，静态数据比您需要协调的数据更容易维护。随着组织的发展，您将使用更多的服务，这将需要更多的协调。Census 所采用的单一真相来源方法避开了协调挑战，在处理复杂逻辑时具有显著优势。
假设您了解到，当公司在九十天窗口期内，并且每年支付给您超过 X 金额，并且位于三个地理区域之一，并且在过去一年中提交了 X 数量的工单等等，此时留存效果最强。使用 Zapier，您需要与其他应用程序协调以同步所需数据，从而筛选出您希望客户成功团队优先处理的客户。使用 Census（它可以运行 DBT 作业来计算数据点），您只需查询数据仓库，并将查询结果推送到帮助工单软件。同样，如果您想将大量数据插入到像 Tensor Flow 分类器这样的工具中，让它直接输出分类器认为您应该优先处理的客户，也是如此。
从这个意义上讲，“逆向 ETL”这个术语有点用词不当，因为 Census 并没有转换数据；它只是从数据仓库中读取数据，并告诉其他应用程序它们需要知道什么；在本例中，即您的成功团队应该优先处理哪些客户。
请查看 Census、Hightouch 和 Zapier。
延伸阅读
有关数据如何在组织中流动的概述，请查看我们关于现代数据栈的文章。