Snowflake 集成模式：Apache Kafka 与零 ETL 和反向 ETL

Snowflake 是领先的云原生数据仓库。集成模式包括批量数据集成、零 ETL 和使用 Apache Kafka 的近乎实时的数据摄取。这篇博文探讨了不同的方法，并发现了它们的利弊。根据行业建议，建议避免使用反向 ETL 等反模式，而是使用数据流来增强企业架构的灵活性、可扩展性和可维护性。

博客系列：Snowflake 和 Apache Kafka

Snowflake 是领先的云原生数据仓库。它的可用性和可扩展性使其成为数千家公司普遍使用的数据平台。本博客系列探讨了不同的数据集成和引入选项，包括传统的 ETL/iPaaS 和使用 Apache Kafka 的数据流。讨论内容包括为什么点对点零 ETL 只是短期的胜利，为什么反向 ETL 是实时用例的反模式，以及 Kappa 架构和将数据处理“向左”转移到流层有助于以可靠且经济高效的方式构建事务和分析实时和批量用例。

Snowflake：从云原生数据仓库过渡到万物数据云

Snowflake 是领先的基于云的数据仓库平台 （CDW），使组织能够以可扩展且高效的方式存储和分析大量数据。它与 Amazon Web Services （AWS）、Microsoft Azure 和 Google Cloud Platform （GCP） 等云提供商合作。Snowflake 提供完全托管的多集群、多租户架构，使用户能够轻松扩展和管理其数据存储和处理需求。

起源：云数据仓库

Snowflake 提供了一种灵活且可扩展的解决方案，用于在云环境中管理和分析大型数据集。它因其易用性、性能以及通过计算和存储分离处理各种工作负载的能力而广受欢迎。

来源：雪花

报告和分析是主要的用例。

Snowflake 以其简单性和易用性而享有盛誉。它使用 SQL 进行查询，使具有 SQL 技能的用户熟悉它。该平台抽象了传统数据仓库的许多复杂性，从而缩短了学习曲线。

未来：一个“数据云”覆盖一切？

Snowflake 不仅仅是一个数据仓库。产品创新和几次收购加强了产品组合。几家被收购的公司专注于与数据管理领域相关的不同主题，包括搜索、隐私、数据工程、生成式人工智能等。该公司过渡到“数据云”（这是 Snowflake 当前的营销术语）。

引用Snowflake的网站：“数据云是一个全球网络，它将组织连接到对其业务最关键的数据和应用程序。数据云实现了广泛的可能性，从打破组织内部的孤岛到与合作伙伴和客户就内容进行协作，甚至集成外部数据和应用程序以获得新的见解。为数据云提供支持的是 Snowflake 的单一平台。其独特的架构将全球企业连接起来，几乎以任何规模将数据和工作负载整合在一起。

来源：雪花

好吧，我们将看到未来会带来什么。如今，Snowflake的主要用例是云数据仓库，类似于SAP专注于ERP或数据湖和ML/AI上的Databricks。当一家公司试图在单一平台内解决每个问题和用例时，我总是持怀疑态度。从技术和成本的角度来看，一项技术在某些用例中具有最佳优势，但从技术和成本角度来看，会给其他用例带来权衡。

Snowflake 权衡：仅限云、成本等

虽然 Snowflake 是一个功能强大且广泛使用的数据云原生平台，但重要的是要考虑一些潜在的缺点：

• 成本：虽然 Snowflake 的架构允许可扩展性和灵活性，但它也可能导致成本可能高于预期。用户应仔细管理和监控其资源消耗，以避免意外开支。一次又一次地“DBT”所有处于静止状态的数据集会显著增加 TCO。

• 仅限云： 本地和混合架构是不可能的。作为一项基于云的服务，Snowflake 依赖于稳定快速的互联网连接。在互联网连接不可靠或速度缓慢的情况下，用户在访问和处理其数据时可能会遇到困难。

• 静态数据：移动大量数据并重复处理这些数据非常耗时、占用大量带宽且成本高昂。这有时被称为“数据引力”问题，由于物理限制，快速移动大型数据集变得具有挑战性。

• 分析：Snowflake 最初是作为云数据仓库开始的。它从来都不是为运营用例而构建的。为有关 SLA、延迟、可扩展性和功能的工作选择正确的工具。没有一个多面手。

• 定制限制：虽然 Snowflake 提供了广泛的功能，但在某些情况下，用户可能需要高度专业化或自定义配置，而这些配置在平台内不容易实现。

• 第三方工具集成：尽管 Snowflake 支持各种数据集成工具并提供自己的市场，但在某些情况下，特定的第三方工具或应用程序可能未完全集成，或者至少未针对 Snowflake 进行优化。

这些权衡表明了为什么许多企业（必须）将 Snowflake 与其他技术和 SaaS 相结合，以构建可扩展但具有成本效益的企业架构。虽然上述所有权衡都是显而易见的，但随着数据集和分析查询的增长，成本问题是我最近从客户那里听到的明显头号问题。

Snowflake 集成模式

如今，每个中间件都提供了一个 Snowflake 连接器，因为它在市场上占有一席之地。让我们来探讨一下不同的集成选项：

1. 与 ETL、ESB 或 iPaaS 的传统数据集成

2. 数据仓库中的 ELT

3. 使用专用产品进行反向 ETL

4. 数据流（通常通过行业标准的 Apache Kafka）

5. 通过直接可配置的点对点连接实现零 ETL

1. 传统数据集成：ETL、ESB、iPaaS

ETL 是大多数人考虑与数据仓库集成的方式。企业在几十年前就开始采用 Informatica 和 Teradata。方法今天仍然是一样的：

ETL 在过去意味着批处理。ESB（企业服务总线）通常允许近乎实时的集成（如果数据仓库能够做到这一点），但由于底层 API（= HTTP/REST）或消息代理基础设施，存在可扩展性问题。

iPaaS（集成平台即服务）与 ESB 非常相似，通常来自相同的供应商，但在公共云中提供完全托管的服务。通常不是云原生的，而是刚刚部署在 Amazon EC2 实例中（所谓的传统中间件的云清洗）。

2. ELT：数据仓库内的数据处理

许多 Snowflake 用户实际上只摄取原始数据集，并在数据仓库中进行所有转换和处理。

DBT 是大多数数据工程师最喜欢的工具。这个简单的工具使简单的 SQL 查询能够直接执行，从而一次又一次地重新处理静态数据。虽然 ELT 方法对于数据工程师来说非常直观，但对于支付 Snowflake 账单的业务部门来说，它的成本非常高。

3. 反向 ETL：“实时批处理”——什么？！

顾名思义，反向 ETL 将 ETL 的故事发生了逆转。这意味着将数据从云数据仓库移动到第三方系统中，以“使数据具有可操作性”，正如这些解决方案的营销所说：

不幸的是，反向 ETL 是一个巨大的 ANTI-PATTERN 来构建实时用例。而且它不具有成本效益。

如果将数据存储在数据仓库或数据湖中，则无法再实时处理数据，因为它已经是静态存储的。这些数据存储是为索引、搜索、批处理、报告、模型训练以及在存储系统中有意义的其他用例而构建的。但是，您无法从静态存储中实时使用动态数据：

相反，请考虑仅将（正确的）数据输入数据仓库以进行报告和分析。实时用例只能在实时平台（如 ESB 或数据流平台）中运行。

4. 数据流：Apache Kafka 实现实时和批量，数据一致性

数据流是一个相对较新的软件类别。它结合了：

• 针对分析和运营工作负载的大规模实时消息传递。

• 一个事件存储，用于长期持久化，真正实现生产者和消费者的解耦，以及历史数据在保证顺序上的可重放性。

• 大规模实时数据集成。

• 用于实时和历史数据的无状态或有状态数据关联的流处理。

• 数据治理，实现整个数据流的端到端可见性和可观察性

事实上的数据流标准是 Apache Kafka。

Apache Flink 正在成为流处理的事实标准，但 Kafka Streams 是另一个优秀且被广泛采用的 Kafka 原生库。

2023 年 12 月，研究公司 Forrester 发布了《The Forrester Wave™： Streaming Data Platforms， Q4 2023》。在此处免费获取报告。该报告探讨了 Confluent 和 AWS、Microsoft、Google、Oracle 和 Cloudera 等其他供应商提供的功能。同样，2024 年 4 月，IDC 发布了 IDC MarketScape for Worldwide Analytic Stream Processing 2024。

与批处理相比，数据流在从技术角度来看合适的地方或增加业务价值的地方支持实时数据处理。但数据流也连接到非实时系统，如Snowflake，用于报告和批量分析。

Kafka Connect 是开源 Kafka 的一部分。它无需额外的 ETL 工具即可大规模实时提供数据集成功能。流式处理系统（如 IoT 或其他消息代理）的本机连接器和从 Oracle 或 Salesforce CRM 等数据库使用的变更数据捕获 （CDC） 连接器将更改作为事件实时推送到 Kafka 中。

5. 零 ETL：点对点集成和意大利面条架构

零 ETL 是指一种数据处理方法。ETL 过程被最小化或消除。如上文所述，传统的 ETL 过程涉及从各种来源提取数据，将其转换为可用格式，并将其加载到数据仓库或数据湖中。

在零 ETL 方法中，数据以原始形式直接从数据源引入到数据湖中，而无需预先进行大量转换。然后，这些原始数据以其原生格式可用于分析和处理，使组织能够根据需要或实时执行转换和分析。通过消除或最小化传统的 ETL 管道，组织可以减少数据处理延迟，简化数据集成，并更快地获得见解和做出决策。

从 Salesforce CRM 到 Snowflake 的零 ETL

一个具体的 Snowflake 示例是与 Salesforce 的双向集成和数据共享。GA'ed 的功能最近实现了“零 ETL 数据共享创新，可减少摩擦并使组织能够在销售、服务、营销和商务应用程序中快速呈现强大的洞察力”。

到目前为止，理论。如果这个集成模式听起来很神奇，为什么我把这个集成模式放在最后而不是放在我的列表中的第一位？

意大利面条架构：集成和数据混乱

几十年来，您可以使用 CORBA、SOAP、REST/HTTP 和许多其他技术进行点对点集成。结果是意大利面条式建筑：

来源：Confluent

在意大利面式架构中，代码依赖项通常以一种方式纠缠在一起并相互连接，这使得在不产生意外后果的情况下进行更改或添加新功能变得具有挑战性。这可能是由于糟糕的设计实践、缺乏文档或技术债务的逐渐积累造成的。

意大利面条建筑的后果包括：

1. 维护挑战：开发人员很难在不引入错误或意外副作用的情况下理解和修改代码库。

2. 可扩展性问题：架构可能难以适应需求的增长或变化，从而导致性能瓶颈或不稳定。

3. 缺乏敏捷性：对系统的更改变得缓慢而繁琐，从而抑制了组织对不断变化的业务需求或市场需求做出快速响应的能力。

4. 更高的风险：架构的复杂性和脆弱性增加了软件错误、系统故障和安全漏洞的风险。

因此，如果您关心公司在数据一致性、上市时间和成本效益方面的中期和长期成功，请不要构建零代码点对点意大利面条架构。

Snowflake 和 Kafka 集成模式的短期和长期影响

使用 Snowflake 的零 ETL 听起来很有吸引力。但前提是您需要点对点连接。大多数信息在许多应用程序中都与此相关。使用 Apache Kafka 的数据流可实现真正的解耦。仅引入一次事件，并独立地从具有不同通信模式（实时、批处理、请求-响应）的多个下游应用程序使用。多年来，这在遗留集成中一直是一种常见的模式，例如，大型机卸载。Snowflake 很少是数据的唯一端点。

仅当您使用哑管道（Kafka、ETL 工具、零 ETL 或任何其他代码）将数据引入到单个数据仓库或数据湖（如 Snowflake）时，才需要反向 ETL 模式。Apache Kafka 允许您避免 Revere ETL。它使架构更具性能、可扩展性和灵活性。有时，由于组织或历史原因，反向 ETL 是无法避免的。没关系。但是，不要设计一个企业架构，在其中摄取数据只是为了以后逆转它。大多数时候，反向 ETL 是一种反模式。