Snowflake releases

Snowflake 致力于为用户提供无缝、始终最新的体验，同时通过快速开发和持续创新提供不断增长的价值。

为了履行这一承诺，我们每周都会部署新版本。这使我们能够定期通过新功能、增强功能和修复的形式提供服务改进。部署在后台透明地进行，用户不会遇到停机或服务中断问题，并且始终可以确保在最新版本上运行并访问最新功能。

本主题描述了我们每周发布版本的流程，包括为 Enterprise Edition 和更高版本账户申请 24 小时抢先体验的选项，以启用额外的版本测试（如果需要）。

Release types (weekly)

Snowflake 每周都会部署两个计划/预定的版本：

完整版本:

完整版本可能包括以下任意内容：

  • 新功能

  • 功能增强或更新

  • 修复

  • 行为变更（请参阅本主题的下一部分）

此外，完整版本还包括每周更新的 Snowflake 版本说明文档。请参阅 Snowflake server release notes and feature updates。

完整版本可能在一周中的任意一天部署，但我们通常不计划在周五发布完整版本，以缓解非工作时间可能遇到的问题。

补丁发布:

补丁发布仅包含修复。请注意，如果某一周的完整版本发布严重延迟或延长，该周预定/计划的补丁发布可能会被取消。

此外，我们在完整版本发布期间或完成之后（根据需要）部署补丁版本，以解决遇到的任何问题。

Behavior changes (monthly)

Each month --- except for November and December --- Snowflake selects one of the weekly full releases for the month to introduce behavior changes. The weekly release selected for the behavior changes may vary, but is typically the 3rd or 4th release for the month.

所谓行为变更，是指对现有行为进行的任何改动，这些改动可能返回与之前行为不同的结果，可能会影响客户的代码或工作负载。这些行为变更将以捆绑包的形式提供，并遵循特定的命名规范：

YYYY_NN

其中 YYYY 是年份，NN 是该年份内的版本序号。例如 2022_06，这是 2022 年推出的第 6 个行为变更捆绑包。

有关更多详细信息，请参阅 行为变更管理。

Bundle lifecycle

行为变更捆绑包生命周期由以下两个时期组成：

测试期（第 1 个月）:

该捆绑包里引入了“默认禁用”。在此期间，您可以选择在一个或多个账户中 启用 捆绑包。通常，您会选择指定用于开发或 QA（质量保证）的账户，这样一来，您就可以测试更改但又不影响您的生产账户。

选择退出期（第 2 个月）:

该捆绑包从“默认禁用”更改为“默认启用”。在此期间，您可以选择 禁用 账户中的捆绑包。这让您可以推迟捆绑包中的变更（通常针对生产账户），同时进行任何必要的调整以减轻变更的影响。

During these two periods, Snowflake doesn't override the setting for a given bundle. For example, if you disable a bundle during the testing period, we do not enable it at the beginning of the opt-out period.

在选择退出期结束时，Snowflake 会在所有账户中启用捆绑包中的行为变更，此时该捆绑包将被视为“正式启用”。从此时起，您将无法启用或禁用该捆绑包。但是，您仍然可以通过联系 Snowflake 支持部门 请求暂时禁用捆绑包中的个别行为变更。

Behavior change documentation

包含行为变更捆绑包的版本还包括以下文档（除了版本的 版本说明 外）：

  • 即将推出和最近实施的捆绑包变更的列表。请参阅 Behavior change announcements。

  • 每个行为变更的描述。每个捆绑包的登录页面上都会列出行为变更。

  • 即将实施和最近实施的非捆绑变更的列表。请参阅 Unbundled behavior changes。

Pre-release testing and validation

在 Snowflake，版本质量是重中之重。每个版本在得到部署之前，都会经过一整套验证测试，其中包括：

  • 定期构建测试。

  • 持续的工作负载和性能测试。

此外，在将任何客户账户移至版本之前，将执行以下验证：

  • 在所有受支持的云平台上对内部账户进行全面回归测试。

  • 模拟执行精选的受影响客户工作负载（例如，针对客户数据的查询），并且侧重于那些最有可能因版本变更而受到影响的工作负载。

Staged release process

After a full release has been deployed, Snowflake doesn't move all accounts to the release at the same time. Accounts are moved to the release using a three-stage approach over multiple days. Accounts are moved to the full release in the following order, based on their Snowflake Edition:

第 1 天:

第 1 阶段（抢先体验）适用于指定 Enterprise 版（或更高版本）账户。

第 1 天或第 2 天:

第 2 阶段（常规访问）适用于 Standard 版本账户。

第 2 天:

第 3 阶段（最终）适用于 Enterprise 版（或更高版本）账户。

通常，抢先体验阶段和最终阶段之间的最短时间为 24 小时，但也可能更短或更长。这种分阶段方法使 Snowflake 能够监控账户移动活动，并对可能发生的任何问题做出响应。它还允许指定 Enterprise 账户进行抢先体验测试（请参阅本主题的下一部分）。

备注

这种分阶段方法仅适用于完整版本。对于补丁版本，所有账户都会在同一天移动。

In addition, if issues are discovered while moving accounts to a full release or patch release, the release might be halted or rolled back. In most cases, the follow-up to a halted or rolled-back release is completed within 24-48 hours.

Early access to full releases

如果您有多个 Enterprise Edition（或更高版本）账户，您可以将其中一个或多个账户用于抢先体验，以利用完整版抢先体验和最终阶段之间的这段时间。如果您为开发/测试和生产维护单独的账户，这可能特别有用。

要指定抢先体验账户，请联系您的 Snowflake 客户代表。

After you have designated an account for early access, you can implement a testing framework similar to the following:

  1. 使用 CURRENT_VERSION （或返回类似结果的 UDF ）来验证您的抢先体验账户何时可利用完整版本。

  2. 使用您的抢先体验账户来测试生产环境的工作负载与完整发布版本的兼容性。

  3. 如果遇到任何问题，请通知 Snowflake 支持部门，他们可以与您合作，防止这些问题干扰您的其他账户。

小技巧

不要求也不建议所有拥有 Enterprise Edition 账户的组织都进行抢先体验。Snowflake 在部署期间进行的严格版本测试和监控通常足以防止大多数问题。抢先体验主要面向希望确保其生产账户不会受到完整版本影响的组织。

语言: 中文