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、Alooma、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 这样的工具只是定期从您的数据仓库中读取，并将更新推送到所需的位置。
这里的核心理念是静止状态下的数据比需要协调的数据更容易维护。随着您组织的成长，您将使用更多服务，这需要更多的协调。普查采用的单一事实来源方法绕开了这个协调挑战，在处理复杂逻辑时，您将领先很多。
假设您了解到保留效果在公司在九十天窗口内最强，并且他们每年支付您超过X金额，并且他们位于三个地理区域之一，并且他们在过去一年提交了X张工单，等等。使用Zapier，您需要与其他应用程序协调，以同步您希望您的客户成功团队优先考虑的客户所需的数据。使用普查（它可以运行DBT作业来计算数据点），您只需要查询数据仓库，并将查询结果推送到工单软件。如果您想将大量数据插入到类似于Tensor Flow的分类器中，并让其仅输出分类器认为您应该优先考虑的客户。
从这个意义上讲，“反向ETL”这个术语有些误导，因为普查并没有转换数据；它只是从数据仓库读取，并告诉其他应用程序他们需要知道的内容；在这种情况下，您的成功团队应该优先考虑哪些客户。
进一步阅读
要了解数据如何在组织中流动的概述，请参阅我们关于现代数据栈的文章。