数据库连接器概念

Snowflake Connector for MySQL 和 Snowflake Connector for PostgreSQL 连接器受 连接器条款 的约束。

连接器组件

Snowflake 数据库连接器由一个 Snowflake Native App(从 Marketplace 安装到您的 Snowflake 账户中)和一个运行在您的基础设施内的代理应用程序组成,可以是本地的,也可以是在云中。

  • 代理 直接连接到您的源数据库,跟踪您选择复制的表的更新,并将更改上传到您的 Snowflake 账户。代理需要一次性配置才能连接到 Snowflake 和数据源,并且仅在新版本发布时进行升级。除此之外,它完全通过 Native App 进行控制和配置。

  • Native App 控制复制数据的过程。它们指示代理跟踪哪些表、接收更改并将其合并到您的目标数据库中。您的大部分交互都将通过 Native App 进行。当有新版本可用时,它会自动升级。

这种代理在本地运行的模型是必需的,这样连接器才能安全地访问对外部连接关闭的网络中的源数据库。

一个代理实例始终连接到单个 Native App 实例,而一个 Native App 始终与一个代理一起使用。如果您需要运行多个代理实例,也许是为了从断开连接的网络复制源数据库,则需要安装和配置 Native App 的多个实例。如需帮助,请 联系 Snowflake 支持部门

备注

为了获得最佳性能,请将代理与 Native App 保持在同一版本,并定期升级。目前,Snowflake 可确保所有公开可用的代理版本与 Native App 之间的兼容性。

在内部,连接器依赖于异步、事件驱动的命令交换。Native App 还必须与代理进行通信和协调。这就是为什么您会注意到执行命令和看到该命令的效果之间存在延迟的原因。

数据源、表、日志和目标

在讨论通过连接器的数据流时,我们区分以下阶段:

数据源

保存连接器正在复制的表的数据库。根据数据库引擎的不同,这可以是整个数据库 服务器 或托管在服务器 内部 的数据库之一。

单个连接器实例可以从多个数据源复制,只要代理可以直接连接到所有数据源。

源表

源数据库中的一个特定表,由连接器跟踪更改,然后将其复制到 Snowflake 中。每个数据源可能包含多个源表,这些表由同一连接器实例同时复制。

数据源中源表的直接父级将成为 Snowflake 中相应目标表的架构。

日志

一个 Snowflake 表,由连接器的 Native App 拥有和管理,用于接收和存储应用于源表的每个更改:插入、更新和删除。它是源表数据的实际更改日志,其结构反映了数据库引擎通常如何将更改广播到其副本。

每个源表都有一个单独的日志表。

目标表

您账户中的 Snowflake 表,连接器将数据复制到该表。每个源表都有一个单独的目标表。其列名反映源表中的名称,其类型是源列的相应 Snowflake 类型。

每个目标表还包括包含复制信息的列:_SNOWFLAKE_INSERTED_AT_SNOWFLAKE_UPDATED_AT_SNOWFLAKE_DELETED,分别保存给定行的原始插入、上次更新和删除的时间戳。

目标表预先启用了更改跟踪,以允许创建流。连接器的 Native App 将 OWNERSHIP 授予保留在表上。

快照和增量加载

从新添加的表中复制数据从 快照加载 开始。代理对源表执行单个 SELECT <columns> 语句,之后会将所有记录流式传输到 Snowflake 中的临时表中,然后将它们复制到目标表中。此操作在源数据库上可能会占用大量资源,并且对于大型表通常需要很长时间。您可能需要等待,直到您看到目标表中出现第一条记录。

在以下情况下,还可以重复快照加载以替换以前复制的数据,以将源表与目标同步:

  • 当表的复制由于不支持的数据类型、大小、连接器错误或其他问题而永久失败时。

  • 当复制暂停时,在恢复后,源数据库的更改日志不再包含自上次复制表以来的条目。

初始快照完成后,表的复制将变为 增量加载。代理跟踪源数据库的更改日志,并将这些更改流式传输到相应的日志表中,稍后它们会从该表中合并到目标表中。此读取、流式处理和合并周期可以连续执行,也可以按计划执行。有关这些模式的更多信息,请参阅 后续步骤后续步骤

表复制生命周期

新添加的源表的复制周期从 架构自检 开始。在这里,连接器会发现源表中的列、它们的名称、类型,然后根据 Snowflake 和连接器的限制来验证它们。验证失败将导致此阶段失败,并且周期完成。成功完成架构自检后,连接器将创建一个空目标表。

第二个阶段是 快照加载,连接器将源表中的所有可用数据复制到目标表中。此阶段的失败也将完成该周期,并且不会复制更多数据。成功完成后,源表中的整个数据集将在目标表中可用。

最后,该表移动到 增量加载,其中连接器继续跟踪源表中的更改,并将其复制到目标表中。这将一直持续,直到从复制中删除该表。如果失败,此阶段将永久停止源表的复制,直到问题得到解决。

有关如何确定表当前处于哪个复制阶段的说明,请参阅 监控 Snowflake Connector for MySQL监控 Snowflake Connector for PostgreSQL

备注

要恢复失败表的复制,请在修复导致失败的问题后,从复制中删除该表,然后再次添加它。有关详细信息,请参阅 为 Snowflake Connector for MySQL 配置复制监控 Snowflake Connector for PostgreSQL

从源到目标的数据流

连接器以不同方式将数据从源表移动到目标表,具体取决于它是执行快照加载还是增量加载。有关更多信息,请参阅 快照和增量加载

快照加载流

  1. 代理对源表执行 SELECT <columns> FROM <source table>,并使用 Snowflake 的 Snowpipe Streaming 将这些记录插入到一个名为快照表的临时表中,该表存储在连接器的 Native App 中。

  2. 一旦快照表中存在所有可用行,Native App 就会运行一个任务,通过 INSERT INTO <destination table> (SELECT <columns> FROM <snapshot table>) 将它们复制到目标表中。

  3. 将所有行复制到目标表中后,将删除快照表。复制的表已准备好继续进行增量加载。

增量加载流

  1. 源数据库将源表的更改发布到其更改日志中。具体机制取决于源数据库的类型,但通常这些列表逐行插入、更新和删除。

  2. 代理实时读取这些更改日志,并将这些逐行更改插入到相应的日志表中。

  3. 合并任务实时检测日志中的新条目,并将它们合并到目标表中:插入新记录、更新或软删除现有记录。合并任务还会将这些更改的时间戳添加到 数据源、表、日志和目标 中所述的列中。

在计划复制模式下,读取源数据库的更改日志、将这些更改移动到 Snowflake 中以及将它们合并到源数据库中 不是 连续执行的,而是按固定计划执行。有关详细信息,请参阅 连续复制与计划复制

连续复制与计划复制

新添加的数据源的默认复制模式为 连续。在此模式下,连接器旨在尽快复制数据更改。对于经常更改的数据源,这是最佳模式,在这种情况下,您需要在 Snowflake 中以低延迟提供该数据。

您可以将数据源更改为在 计划 模式下复制,在该模式下,数据将按固定计划从源分批复制到目标表中。对于不经常更改的数据源,或者当您打算减少 Credit 消耗,并且不需要数据在 Snowflake 中以低延迟可用时,这是最佳模式。

备注

复制模式可以 按数据源设置,并将统一影响为该数据源配置的所有表。不支持为每个表设置不同的模式或计划。

运行连续复制时,增量加载永远不会报告为“已完成”。在计划模式下,在将每批数据合并到目标表后,增量加载将报告为已完成。计划模式下的“批次”包含上一次计划运行与下一次计划运行开始之间的所有更改日志条目。

仓库类型

连接器需要两个仓库才能运行:

  • 运营仓库,有时称为 Ops 仓库,用于执行连接器的命令和控制操作。此仓库由设置向导自动创建,其最佳大小为 XS。

  • 计算仓库 用于执行将数据从日志移动到目标表的合并任务。此仓库可以通过设置向导创建,也可以手动创建。其最佳大小和类型取决于复制的规模。

需要进行上述区分,以确保及时执行操作查询,而不会与移动大量数据的查询一起排队。这也意味着运营仓库 不能 在连接器实例之间重复使用,并且不应与账户中的其他工作负载共享。

反过来,计算仓库 可以 与其他连接器实例和工作负载共享。但请记住,共享此仓库可能会导致目标表中显示的数据出现延迟。

重要

在连续模式下工作时,运营仓库将 永远不会 挂起,这将导致它即使没有复制任何数据也消耗 Credit。要启用自动暂停,请将 所有 数据源的复制模式更改为计划复制。有关详细信息,请参阅 连续复制与计划复制

语言: 中文