Snowflake 迁移策略

我们知道，迁移整个数据平台并非易事，需要考虑许多不同的技术和模式，描述项目和流程，规划和设计目标状态，同时还要保持当前的日常运营和业务决策。

我们的经验包括将各种系统迁移到 Snowflake。为了确保您的业务能够照常运行，我们会在 Snowflake 迁移中考虑您当前的运营活动。

列一个清单

以下因素使清点成为关键步骤

• 它有助于确定 Snowflake 迁移的范围。
• 它有助于查找必要的项目。
• 它有助于描述数据量和活动。
• 弄清楚需要迁移什么，无论是“直接迁移”还是“重新架构”，都是至关重要的一步。以下是一些需要考虑的事项。
• 源 数据源会影响或决定数据摄取工具的可用选项。其他数据库、数据湖、SaaS 程序（如 Salesforce）、Access 数据库、SharePoint 和 Excel 电子表格是一些示例。

目标

• 确定依赖关系是考虑目标的一种有效方法。尽管有时会被忽略，但这一领域对于保持业务运营不间断至关重要。
• 数据从当前数据平台流向其目标。目标是确定这些目标——可能包括用于将数据复制到 Access 数据库以供最终用户使用的提取过程、用于 机器学习 或 数据科学 的数据湖，或用于运营系统的反向 ETL 模式——是否需要 Snowflake 平台的支持。

与源一样，确定所有者是关键步骤。目标的所有者将有助于确保

• 数据为业务用户进行了适当的结构化和格式化。
• 提供了必要的访问权限，使数据能够顺畅流动。
• 符合服务级别协议和任何其他要求。

数据库对象

这些包括数据库、存储过程、表、模式和作业（如 SQL Server Agent 作业）。在清点数据库对象时，经常会发现不再使用或因现有系统限制而出于性能原因正在使用的模式、表和其他数据库对象。由于此过程，新的 Snowflake 环境的范围可能需要更少 .^{}

从数据库获取统计信息，包括活动、表大小以及每天进行的更改次数，是另一个要素。这有助于正确确定 Snowflake 数据仓库的大小以获得最佳性能。

作业和摄取管道

这个特定的清单项目可用于映射数据库对象并协助决定如何加载它们。我们还可以通过它了解数据在哪里、如何以及是否在摄取过程中混合。

为了更好地确定 Snowflake 数据仓库的大小，我们会收集有关正在处理的数据量、管道的频率以及执行的操作类型（例如增量更新）的数据，这与我们处理数据库对象的方式相同。根据所使用的设备或工具，可能无法轻松获得其中一些精确值，但没关系，因为估计或近似值仍然有助于确定大小。

转换

用于执行转换的 SQL 代码几乎肯定无法在当前系统到 Snowflake 之间按原样运行。在这种情况下，phData Toolkit 将非常有用。我们使用 SQL Translation（以前称为 SQLMorph）工具将多种 SQL 方言翻译成 Snowflake 特有的 SQL。

报告

这项练习的目的是找出数据的使用方式。最终，我们希望知道哪些报告涵盖在 Snowflake 迁移中，以及使用的工具以及它们的使用方式。为了确保 数据完整性 得到维护，并且数据是消费者期望的数据，这些报告还可以用于特定的数据验证。

选择方法

在我们清楚了解现有情况并对迁移范围有一定了解后，我们将制定达到目标状态的策略。通常，这需要确定迁移是“直接迁移”（尽可能保持目标状态与源状态接近，同时使用 Snowflake），还是需要重新设计摄取和转换模式以消除技术债务和复杂性。

上述方法的注意事项如下

直接迁移与重新设计或重构

直接迁移策略涉及将工作和输出重定向到 Snowflake，而基本保持管道和任务的当前状态。因此，此方法的优点在于能够进行真实的“一对一”比较，并实现更短的 Snowflake 路径。

重构技术旨在优化 Snowflake 上的流程，旨在简化或消除管道瓶颈。它甚至使用不同的数据模型来进一步利用数据潜力。此方法提供了平台的长期视角，因为它允许为未来的用例和 Snowflake 优化进行规划。

我们已经完成了这两种迁移，并发现了一些在确定哪种策略最佳时需要考虑的因素。对于有严格日期截止日期（如硬件寿命终结）或出于合规原因要求系统之间数据必须匹配（如执行相同的转换逻辑）的迁移，建议采用直接迁移方法。

在这种情况下，我们建议查看我们 phData 工具箱中的 SQL Translation。它可以轻松地在方言之间转换 SQL，而无需更改任何逻辑。如果直接迁移的考虑因素不适用，我们建议使用重构策略。为实现长期未来用例，简化当前架构并可能开发新的数据模型。

摄取管道

正如我们在直接迁移策略中所讨论的，管道被重定向到 Snowflake 并基本得以保留。根据管道中的操作以及工具如何处理处理，可能需要一些调整才能将源 SQL 方言转换为 Snowflake 特有的 SQL。

另一方面，重构管道可以包括简化各种工作流以及分离摄取和转换操作。我们建议对摄取管道使用 ELT 方法，即将原始数据加载到 Snowflake 中，以确保其与源层非常相似，主要的变化是数据类型转换。

我们的合作伙伴 Fivetran 对这种策略非常了解。他们极大地简化了数据摄取过程，让您可以专注于为您的公司增加价值。这是因为他们的 HVR 技术提供了可靠的近实时数据摄取，以及他们拥有众多用户友好型连接器的 SaaS 产品。

从此，Snowflake 中的转换开始。

转换

了解转换在哪里执行是清单练习的一个方面。在这里，我们决定是将现有任务重定向到 Snowflake（例如，债务）还是解耦以转移这些活动。

Matillion 提供了一种 GUI 优先的云原生方法来开发转换管道。这两种技术都提供了构建转换管道的出色方法，可确保您的公司获得可靠且有价值的数据。

报告

关于报告技术，有几点需要考虑。所涉及的技术将影响方法的选择。某些技术通过在报告中修改连接方面提供更大的灵活性，使得直接迁移策略成为可能。

还应考虑最终数据模型以及它是否会偏离当前结构。为了利用新设计，现有报告将需要重建，因为最终模型正在发生变化。

数据模型

让我们来讨论一下新的 Snowflake 平台用于组织数据的方法和模型。

选择数据仓库架构除了迁移之外，还支持并促进了公司。这些策略都有优缺点，选择通常基于组织的需要以及每个计划的潜在好处。

可用的数据模型如下

数据仓库方法

创建信息架构

信息架构文档详细介绍了 Snowflake 环境的组织、结构、标签、安全和共享。我们的经验表明，通过在架构设计上做到具体，可以确保成功迁移到目标状态。

从传统平台迁移数据到 Snowflake 的最佳方法是：在确定了最初的技术和操作考虑因素后，迁移计划中的四个主要过程是数据提取、传输、上传和验证。

步骤 1：有效地从原始系统提取信息

挑战：遗留数据压缩率低、特定表的长时间运行过程或资源争用，以及源系统上可建立的并发连接数量有限，这些都常常阻碍有效提取。

最佳方法

• 仅从辅助或只读实例提取信息以减少吞吐量。如果没有可用的只读实例，您可以从生产环境加载备份文件到较低环境并从中提取。
• 使用遗留系统的原生提取器并将提取的数据存储在暂存服务器或 NFS 上，可以加快提取过程。
• 选择适合数据集的文本分隔符工具，以防止在提取过程中数据损坏。

步骤 2：将信息传输到云端

挑战：网络带宽有限或在高峰和非高峰时段吞吐量波动很大，都会阻碍快速数据传输。大量数据也可能影响每次重复的数据传输速率。数据损坏是文件传输的风险，特别是对于大文件。

最佳方法

在分析阶段进行概念验证，以确定高峰、非高峰和周末时间的最佳吞吐量窗口。选择可用带宽的最大值而不是总容量，因为多个项目有时会共享网络带宽。

如果您有大量数据、速度慢且总体时间紧迫（这可能需要额外的组织许可），请考虑基于设备的即时数据传输。

步骤 3：将数据上传到 Snowflake 数据

云挑战是第三步。如果客户订阅中提供了对象存储，您可以使用它作为外部阶段将数据上传到 Snowflake；如果没有，您将需要使用内部阶段。由于遗留平台上的数据量快速增长而导致的冻结期或切换窗口缩短，可能会影响初始迁移后的增量数据同步。此外，错误大小的集群会提高您的信用消费率。

最佳方法

为获得最大吞吐量，请使用原生 Snowflake 数据加载器实用程序。为及时检测数据加载问题，请利用 Snowflake 原生加载器的错误处理功能。

为经济高效地加载数据，请使用独立的数据仓库。配置具有自动暂停和恢复功能的自动扩展策略，并根据您的数据量调整仓库大小。设置计算、信用额度限制和通知触发器，然后在 Snowflake 账户上创建资源监控。

为使用原生加载器获得最佳吞吐量，请将文件大小限制在 100 到 250 MB 之间。为了减少文件和子文件夹的数量，请将暂存区的数据划分为逻辑路径。加载文件后，使用 copy 或 delete 命令中的 purge 选项将其从 Snowflake 暂存区中删除。

步骤 4：验证迁移的数据

挑战：手动认证和验证耗时且容易出错。团队必须投入更多时间和精力来评估数据的质量。

最佳方法

使用参照完整性测试来确保表之间的数据级关系完好，并使用基于校验和的验证来确认文件在传输过程中没有损坏。

改进报告和分析工具，以确保它们在新环境中正常运行。重定向分析和报告测试本身也需要严格的测试。经过验证的高质量数据对于 AI/ML 工作负载和报告至关重要。

生成验证结果的文本报告并保存，以备将来进行额外研究或实施纠正措施。

使用数据迁移工具创建数据迁移框架

数据和分析可以通过多种方式迁移到现代云数据平台，例如 Snowflake。

数据迁移工具的四步迁移方法如下

使用遗留平台的原生提取器检索数据。将数据存储在暂存服务器或 NFS 上，并使用分隔文本或其他适当的数据格式（如前述最佳实践中所述，最好进行压缩）。通过触发由元数据输入触发的原生提取脚本，使用您首选的语言创建一个通用框架，该框架可以处理多个表和业务场景。或者，您可以在数据量较小且迁移窗口较长的情况下，使用数据迁移工具和 JDBC 驱动程序提取数据。

验证您迁移的数据

该工具通过加快将数据传输到 Snowflake 目标来促进历史数据迁移。对于有严格迁移截止日期的企业，例如，由于许可证过期而必须进行时间敏感数据迁移的公司，节省时间可能非常可观。

在许可证过期前 14 个月，一家中欧银行必须将其庞大的财务和监管数据仓库从其 RDBMS 迁移出来，并且数据必须按原样传输。该银行使用数据迁移工具从非生产环境中迁移了超过 300 TB 的历史数据。由于数据量巨大，团队使用了数据迁移工具与原生平台工具的交互来完成任务。

使数据迁移尽可能顺利

仔细的数据管理对于数据驱动型组织的成功至关重要，这一点在将企业数据仓库平台迁移到 Snowflake 等云平台时尤为重要。

Snowflake 迁移步骤

1. 系统设置：在 Snowflake 系统中设置数据库、角色和虚拟仓库。
2. 模式迁移：将数据库模式从当前系统迁移到 Snowflake。这可能需要将数据类型和结构转换为 Snowflake 兼容格式。
3. 代码迁移：更新或重写存储过程、SQL 查询和其他代码，以使其与 Snowflake 兼容。
4. 测试：彻底测试新环境，以确保数据完整性、性能和可靠性。
5. 优化：根据测试结果，调整仓库大小和聚类键等性能参数。
6. 部署：从旧系统切换到新的 Snowflake 环境。这可能涉及一段时间内同时运行两个系统。
7. 监控和维护：始终监控系统的功能和安全性，并根据需要进行调整。

Snowflake 迁移优势

• 可伸缩性：Snowflake 的架构使其易于扩展存储和处理能力。
• 性能：提高并发性和查询性能。
• 安全性：强大的安全功能包括基于角色的访问控制和数据加密。

挑战

• 数据传输：大量数据的移动可能需要一些时间。
• 成本：虽然 Snowflake 可能经济高效，但迁移过程可能涉及相关费用。

迁移工具

• SnowSQL：Snowflake 中用于 SQL 查询的内置命令行工具。
• Snowpipe：用于持续、自动的数据摄取。
• 第三方工具：用于 ETL 过程，例如 Matillion、Talend 和 Azure Data Factory。

最佳实践

增量迁移：为降低风险，请考虑分阶段迁移。

• 迁移后通过数据验证来验证数据完整性。
• 利用 Snowflake 的性能调整工具，例如聚类键和物化视图。
• Snowflake 迁移可以带来可伸缩性、性能和灵活性等优势，但要实现无缝迁移，需要仔细规划。

将数据、应用程序和流程从旧系统迁移到 Snowflake 的云平台需要经过仔细考虑的迁移方法。Snowflake 迁移中采用的主要策略如下：

1. 直接迁移（重新托管）

• 描述：这是最直接的方法，涉及将当前数据和流程移动到 Snowflake，而无需进行任何更改。目标是在 Snowflake 中复制现有环境。
• 何时应用：最适合不需要进行大规模重构，并且希望快速迁移且修改很少的企业。
• 优点：优点包括迁移速度更快、成本更低、干扰更少。
• 缺点：它可能无法充分利用 Snowflake 的高级功能，例如其可伸缩性和性能优化。

2. 调整和优化（重构）

• 描述：为了利用 Snowflake 的独特设计，此方法涉及将数据和应用程序迁移到 Snowflake，同时优化查询、数据结构和过程。
• 何时应用：最适合希望利用 Snowflake 的内置聚类、分区和缓存功能，同时提高速度并降低成本的企业。
• 优点：充分利用 Snowflake 的功能，提高性能，具有成本效益。
• 缺点：耗时更长，需要了解 Snowflake 的架构。

3. 重构

• 描述：为了有效利用 Snowflake 的潜力，此方法会完全重写数据架构。一种实现方式是解构旧的单体数据系统，构建为更分布式和可伸缩的架构。
• 何时使用：最适合寻求云原生数据架构的企业，特别是那些拥有高度复杂或分散的遗留系统的企业。
• 优点：优化云原生架构的优势，实现更好的可伸缩性和数据治理。
• 缺点：更复杂且成本更高，迁移时间更长。

4. 混合迁移

• 描述：此方法涉及将部分数据迁移到 Snowflake，同时将某些应用程序或数据保留在当前环境中。目标通常是保留用于运营数据库的遗留系统，同时利用 Snowflake 处理特定工作负载，例如分析。
• 何时使用：最适合那些不希望进行完全迁移但有特定 Snowflake 用例（包括分析或机器学习）的企业。
• 优点：优点包括更高的灵活性、逐步采用和更低的风险。
• 缺点：双环境会使事情复杂化，并且可能存在数据同步问题。

5. 分阶段迁移

• 描述：在分阶段迁移中，工作负载和数据会逐步迁移，通常根据业务部门或职能进行。这使得团队能够逐步适应 Snowflake。
• 何时使用：最适合那些需要逐步培训员工并希望尽量减少中断的企业。
• 优点：风险较低，有更多时间进行培训和测试，对业务的影响较小。
• 缺点：迁移时间较长，可能存在协作困难。

结论

总之，我们可以得出结论，迁移到 Snowflake 具有多种优势，包括提高数据处理性能、降低成本和增强可伸缩性。无论是快速的直接迁移、更优化的迁移、完整的重构、分阶段的方法还是混合配置，迁移的成功都取决于所选的方法。为了使更改顺利进行，仔细的规划至关重要，包括全面的评估、数据准备和验证。通过将迁移策略与贵公司的目标和可用资源相匹配，您可以充分利用 Snowflake。这将实现更有效的数据管理和提供业务价值的见解。