Architecture 设置初始雪花环境的最佳实践-多个URL

我想知道其他人是如何根据DevOps和代码部署的考虑因素以及他们在这方面的经验来设置他们的初始Snowflake环境的。人们是使用多个帐户/URL来简化DevOps和部署，还是使用一个帐户来构建单独的开发、测试和产品数据库？例如：

DEV=

• SourceSystem.Schema.Tables

测试=

• SourceSystem.Schema.Tables

产品=

• SourceSystem.Schema.Tables

你为什么或者为什么不这么做

过去，我在一个帐户下设置环境，如：

单一环境=

• Dev\u SourceSystem.Schema.Tables

• 测试\u SourceSystem.Schema.Tables

• Prod\u SourceSystem.Schema.Tables

---

有趣的是，在您的问题中，您将单独的帐户称为使DevOps更容易。根据我的经验，把所有的东西都放在一个账户中比较容易，原因如下。如果您在RBAC模型中使用了一个好的结构，那么在隔离这些环境方面没有什么区别（假设您不希望为不同的环境提供单独的IP白名单，在这种情况下，这个对话是没有意义的）。同时，如果您随后确保DevOps、ETL等的脚本都只引用模式（没有数据库引用），那么迁移DDL、DML等就像在单独的帐户中一样简单。同时，Snowflake的一个最好的特性是为您的测试生命周期提供零拷贝克隆。这仅在单个帐户中可用。如果使用单独的帐户，则需要将数据从一个环境复制到下一个环境（将存储成本复制或增加两倍，并需要大量的时间消费者和信贷消费者）。零拷贝克隆允许在不同的环境中对数据进行近乎即时的快照

---

根据我与许多Snowflake客户的经验，单个帐户是最常见的，但也有使用多个帐户的客户。这实际上取决于什么对您来说是重要的。

您之前提到过，您在DevOps过程中使用了单帐户方法，但现在已经放弃了。您能否分享一下改变方法可能引发的特定痛点？这是因为每个环境的数据库/架构名称都在变化，所以在数据库之间部署对象很困难吗？

当我们第一次开始使用Snowflake时，也遇到了同样的问题

然而，经过与我们的销售工程师的讨论和大量的原型设计，我们现在已经开发出一种适合我们的方法

我们有一个帐户，每个系统有多个环境

对于用户来说，不同的角色只允许访问相关的环境，所以“dev”角色只允许访问“dev”等。 它比这稍微复杂一些，因为在每个环境中都有多个角色，具有不同的访问级别，但是你明白了——我希望！ 在我们的一些系统中，我们为单个用户强制执行不同的用户帐户，以便环境尽可能地接近独立。这意味着我的开发帐户无法访问允许访问测试或live的角色

只有顶级管理员才有权访问sysadmin（等）角色，这些角色不是默认的

这种方法意味着我们几乎可以立即启动多个开发环境——使用实时数据、测试数据或开发数据

---

我们确实有多个帐户，但每个帐户都运行一个单独的系统（在某些情况下，我们必须对一些数据进行物理分区），我们使用数据共享在不同帐户之间传递公共数据

我们团队的其他成员表示，多个帐户可以提供更好的安全隔离。任何东西都不能意外地指向错误的环境。这是主要的驱动因素。零克隆是我过去使用一个帐户的主要原因，数据共享也是。我所在团队的其他成员认为多个URL更好，因为代码不会意外地指向错误的环境。正确地利用RBAC在单个帐户内完全隔离环境也可以避免任何事故。利用按环境划分的单独用户登录，以及允许跨环境克隆和其他迁移的单个角色，也可以发挥作用。这些都是非常好的响应，感谢他们。您是否看到了一个很好的用例，其中多个环境显然是正确的选择？最好的例子是白名单IP地址，其中客户有限的应用程序和用户通过不同的IP范围（dev VPN和Prod VPN）进行访问，这只能通过单独的帐户实现。