几乎没有哪个数据概念比ETL（提取-转换-加载）更具争议性了，ETL是主宰了数十年企业操作的准备技术。ETL在20世纪70年代开发的时候，在大规模数据仓库和存储库时代大放异彩。企业数据团队将数据集中，在其上层增加了报告系统和数据科学模型，并启用了向商业智能（BI）工具的自助服务访问。然而，在云服务、数据模型和数字化流程的时代，ETL显得陈旧了。

在Google上进行“ETL还有没有相关性/需求/已经过时/死掉？”等搜索会得到很多结果。原因在于，企业数据团队在为不同员工角色和业务功能广泛使用数据的准备工作上感到沉重压力。ETL不容易扩展以处理云中存储的大量历史数据。它也不能提供快速执行决策所需的实时数据。此外，为了提供带有数据的应用程序，构建自定义API导致了巨大的管理复杂性。现代企业拥有500到1000个数据管道，这在他们寻求转换数据和为用户提供BI工具自服务访问时并不罕见。然而，这些API正处于不断演变中，因为当他们提取的数据发生变化时，必须重新编程。很明显，对于许多现代数据需求来说，这个过程太脆弱了，比如边缘使用案例。

此外，应用能力也有所发展。源系统提供业务逻辑和工具来加强数据质量，而消费应用程序则实现数据转换并提供一个健壮的语义层。因此，团队不那么有动力构建点对点接口来批量移动数据、转换它，并将其加载到数据仓库中。

两种创新技术指出了在最小化转换负担的同时实现数据民主化的道路。零ETL不需要移动数据就能使数据可用，而反向ETL则在数据可用时立即将其推送到需要的应用程序。

零ETL减少了数据移动和转换需求

零ETL优化了小数据集的移动。通过数据复制，数据以当前状态移动到云中，以用于数据查询或实验。

但如果团队根本不想移动数据怎么办？

数据虚拟化将服务从最终用户中抽象出来。当用户从单一来源查询数据时，输出会被推回给他们。而通过查询联邦，用户可以查询多个数据源。工具结合结果并向用户展示集成的数据结果。

这些技术之所以称为零ETL，是因为不需要构建管道或转换数据。用户在现场处理数据质量和聚合需求。

零ETL非常适合对近期数据进行特定分析，因为在历史数据上执行大型查询可能会损害操作性能并增加数据存储成本。例如，许多零售和消费品包装品公司的高管在需求高峰期间，如节假日，使用零ETL查询日常交易数据以关注营销和销售策略。

Google Cortex提供了加速器，使零ETL在SAP企业资源规划系统数据上可用。其他公司，如世界上最大的零售商之一和一个全球食品和饮料公司，也采纳了零ETL流程。

零ETL的收益包括：

• 提供访问速度：使用零ETL流程为自助查询提供数据比使用传统ETL流程节省了40-50%的时间，因为无需构建管道。
• 减少数据存储需求：使用数据虚拟化或查询联邦时，数据不会移动。用户只需要存储查询结果，从而减少存储需求。
• 带来成本节约：与传统ETL相比，使用零ETL流程的团队在数据准备和存储成本上节省了30-40%。
• 提升数据性能：由于用户只查询他们想要的数据，数据传输速度快了25%。

为了开始使用零ETL，团队应该评估哪些用例最适合这种技术，并确定他们需要执行它的数据元素。他们还应该配置他们的零ETL工具指向期望的数据来源。团队随后提取数据，创建数据资产，并将其暴露给下游用户。

使用反向ETL按需向应用程序提供数据

反向ETL技术简化了向下游应用程序的数据流程。团队不再使用REST API或端点并编写脚本来拉取数据，而是利用反向ETL工具将数据及时且完整地推送到业务流程中。

使用反向ETL具有以下优势：

• 减少时间和努力：对于关键用例使用反向ETL减少了20-25%获取数据所需的时间和努力。一家领先的游轮公司利用反向ETL进行数字营销活动。
• 提升数据可用性：团队有更大的把握他们能够访问关键任务所需的数据，因为90-95%的目标数据会准时到达。
• 降低成本：反向ETL流程减少了对API的需求，这些API需要特定的编程技能并增加了管理复杂性。结果，团队减少了20-25%的数据成本。

为了开始使用反向ETL，数据团队应该评估需要即时数据的用例。接下来，他们确定数据交付的频率和量级，并选择适合处理这些数据量的工具。然后，他们将数据仓库中的数据资产指向它们的目的地消费系统。团队应该以一个数据加载进行原型测试以衡量效率，并扩大流程。

要成功处理数据，请使用多样的准备技术

零ETL和反向ETL工具为团队提供了服务数据给用户和应用程序的新选择。他们可以分析因素，例如用例需求、数据量、交付时间框架和成本驱动因素，以选择最佳选项来交付数据，无论是传统ETL、零ETL还是反向ETL。

合作伙伴通过提供洞察来支持这些努力，洞察哪些技巧和工具最适合满足功能和非功能需求，提供加权评分卡，用获胜工具进行价值证明（POV），然后将工具操作化以适应更多用例。

通过零ETL和反向ETL，数据团队实现了他们的目标，即在需要时为用户和应用程序赋能以数据，从而在避开转换头疼问题的同时驱动成本和性能收益。