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