虚拟化优先还是现代化优先？Snowflake AIM迁移路径建议

上个月有位客户问我一个问题，这个问题现在几乎每周都会以某种形式出现。他们已经决定以 Snowflake 为最终目标。但他们尚未确定的是达到目标的路径。是虚拟化现有的 Teradata 资产，其余的事稍后再操心，还是直接进行现代化改造，从第一天起就原生重建一切。这听起来像是个技术问题。实际上，这更接近一个穿着技术外衣的业务风险问题。

Snowflake 现在将这两条路径打包在一个伞形产品下，他们称之为 Snowflake AIM，即 AI 驱动的现代化和虚拟化（AI-driven Modernization and Virtualization）。这对他们来说是一个明智的举动，因为多年来，这两者感觉像是两个完全不同的供应商在试图解决两个不同的问题。现在它是一个平台，三条现代化路径，全部由运行在 Snowflake CoCo 内部的迁移代理驱动。包括 Teradata 虚拟化、Teradata 之外的数据仓库迁移，以及 Spark 工作负载现代化。但我被问到的问题很少涉及管道细节。几乎总是某种形式的“我到底该选哪一个”。

虚拟化：为自己争取时间而不承担风险

我之前写过一篇关于 AIM 虚拟化机制的文章，所以在这里不再重复架构。对话关键是它产生的结果。您的应用程序继续使用它们已经使用的 SQL。无需重写任何内容。网关实时进行翻译，而 Snowflake 在底层执行实际处理。从业务角度看，这意味着零停机，切换只需重新指向连接字符串，而无需重新平台化应用程序。

我倾向于在三种情况下推荐这条路径，而且我的意见相当一致。首先，当 Teradata 续约截止日期迫在眉睫，且没有足够的准备时间进行负责任的全面重写时。其次，当仓库之上的应用程序过于老旧，或者由某个团队维护但距离遥远，以至于将它们从 Teradata 特有的 SQL 中解耦本身就是一个多季度的项目时。第三，当业务根本无法承受大爆炸式切换的运营风险时，这描述了我合作的大多数受监管行业。虚拟化让您立即摆脱许可和硬件压力，并将曾经关乎存亡的迁移项目变成更接近常规基础设施工作的事情。

现代化：构建您真正想要的版本

现代化则完全是另一回事。在这里，您不是即时翻译，而是转换实际的代码、数据库对象和管道，使它们未来能在 Snowflake 上原生运行。表、视图和存储过程都会被转换，根据目标，您可以落在原生 Snowflake 表或托管 Iceberg 表中，如果开放格式互操作性属于您长期数据策略的一部分，这一点很重要。遗留 ETL 工作流会自动翻译成在 Snowflake 内部运行的 dbt。如果涉及 Spark，AIM 会分析基于 Python、Java 或 Scala 的 Spark 代码，识别使用的 API，对照 Snowpark 和 Snowpark Connect 检查兼容性，并自动生成转换，而不是要求工程团队手动移植。

当目标不仅是逃离遗留平台，而是真正将其抛在脑后时，我会推动客户选择这条路径。如果您的团队希望今后编写和维护 Snowflake 原生 SQL，如果您希望管道以 Snowflake 优先的方式构建，而不是无限期地沿用 Teradata 的习惯用法，那么现代化是诚实的答案。是的，它确实需要重写，但 AI 辅助的转换工具已经缩小了以往使这一选项成本过高的差距。过去需要一队承包商花近两年时间的工作现在可以大幅压缩，不过我要提醒那些期望立竿见影的人。分阶段、按工作负载进行切换仍然是降低风险的正确方式，Snowflake 自己的指南也反映了这一点。

我实际使用的决策框架

抛开营销语言，决策通常归结为我在选择路径前会问每位客户的三个问题。

• 您实际有多少准备时间？如果合同续签或硬件生命周期结束发生在十二个月内，虚拟化能为您赢得喘息空间，而重写则不能。
• 您的应用程序与源平台的 SQL 方言耦合程度如何？紧密耦合、难以触碰的应用程序倾向于虚拟化。您已经控制或计划重建的应用程序倾向于现代化。
• 您希望三年后的数据平台是什么样子？如果最终状态是完全原生的 Snowflake 环境，带有 dbt 管道和 Snowflake 惯用 SQL，现代化能直接带您到达那里。如果最终状态仅仅是离开 Teradata，并有权随时间选择性现代化，虚拟化是更耐心、通常也更现实的起点。

这是我在白板上为客户实际勾勒的比较，去除了所有修饰，只留下在需要做出决定时真正重要的内容。

为什么我很少把这视为二选一

我经常看到的错误是将这视为一个永久的岔路口，好像选择虚拟化就意味着你永远排除了现代化。这不是我建议的方式，也不是平台构建的方式。虚拟化通常是第一步，让你离开燃烧的平台而不会在这个过程中烧毁大楼。现代化成为第二步，在压力解除且团队有余地从容而非被动应对之后，逐工作负载进行。我曾看到不止一个客户并行运行这两种方式，将暂时无法触碰的工作负载虚拟化，同时将可以处理的工作负载现代化，这并没有错。这可以说是运行这种规模迁移的最明智方式。

我要提醒的是，不要仅仅因为现代化听起来更彻底而选择它，或者仅仅因为虚拟化听起来更容易而选择它。这两种直觉都不是策略。正确的选择取决于你的续约时间线、应用层的状态，以及对你组织目前和之后进行重写的意愿的诚实评估。评估正确了，迁移的其余部分往往会自行解决。评估错误了，你要么在一个你没有准备好的重写上浪费一年时间，要么无限期地虚拟化，从未真正现代化任何东西，这只会变成一种带有更好品牌的新技术债务。

我希望这篇博客能帮助你做出正确的决策——何时使用 Snowflake AIM 进行虚拟化，何时进行现代化。 如果你对此有任何疑问，请随时在评论区提问。如果你喜欢这篇博客，请点赞。保持联系以看到更多精彩内容。感谢你的支持。

免责声明：

请注意，本文中表达的观点仅代表我个人，不代表我雇主的观点或意见。

关于 Rajiv Gupta

Rajiv Gupta 是 Kipi.ai 的技术副总裁，六次获得 Snowflake 数据超级英雄称号。他经常撰写和演讲关于 Snowflake、Cortex AI 以及向云原生数据平台的更广泛转变，凭借为企业客户运行迁移和现代化项目的实践经验。

博客： https://medium.com/@rajivgupta780184

YouTube： https://www.youtube.com/c/RajivGuptaEverydayLearning

LinkedIn： https://www.linkedin.com/in/rajiv-gupta-618b0228/

X： https://twitter.com/RAJIVGUPTA780

#Keeplearning #Keepsharing #Everydaylearning #RajivGupta #DataSuperHero

参考资料：-

• https://docs.snowflake.com/en

先虚拟化还是先现代化？我实际上如何建议客户使用 Snowflake AIM 最初发布于 Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science 在 Medium 上，人们通过强调和回应这个故事继续对话。