我想知道其他人是如何在考虑DevOps和代码部署以及他们这样做的经验的情况下设置其初始Snowflake环境的。人们是在使用多个帐户/ URL来简化DevOps和部署，还是使用一个帐户并构建单独的DEV，TEST和PROD数据库？例如：
DEV = http://mydevaccount.east-us-2.azure.snowflakecomputing.com
测试 = http://mytestaccount.east-us-2.azure.snowflakecomputing.com
PROD = http://myprodaccount.east-us-2.azure.snowflakecomputing.com
为什么或为什么不这样做？
过去，我在一个帐户下拥有设置环境，例如：
单个环境 = http://mysnowflakeaccount.east-us-2.azure.snowflakecomputing.com
开发 _SourceSystem.Schema.Tables
测试 _SourceSystem.Schema.Tables
产品 _SourceSystem.Schema.Tables
答案 0 :(得分：3)
有趣的是，您引用单独的帐户可以简化问题中的DevOps。以我的经验，将所有内容都存储在一个帐户中会更容易，这就是原因。如果您在RBAC模型中使用良好的结构，则在隔离这些环境方面没有任何区别（假设您不希望针对不同的环境使用单独的IP白名单，在这种情况下此讨论是没有意义的）。同时，如果您随后确保所有DevOps，ETL等脚本仅引用架构（无数据库引用），则迁移DDL，DML等就像在单独的帐户中一样容易。同时，Snowflake的最佳功能之一是零复制克隆，可满足您的测试生命周期。仅在单个帐户中可用。如果使用单独的帐户，则需要将数据从一种环境复制到另一种环境（将存储成本以及大量的时间消耗和信贷消耗都复制或增加了两倍）。零拷贝克隆可让您近乎即时地将数据快照复制到其他环境。
根据我与许多Snowflake客户的经验，单个帐户是最常见的，但是有些客户也使用多个帐户。这真的取决于对您而言重要的事情。
答案 1 :(得分：1)
您提到您先前在DevOps流程中使用了单帐户方法，但已不再使用它。您能否分享可能触发哪种特定痛点来改变方法？难道是由于每个环境中数据库/模式名称的更改而导致在数据库之间部署对象的努力吗？
答案 2 :(得分：1)
当我们第一次使用Snowflake时，我们遇到了同样的问题。
但是，在与我们的销售工程师进行讨论并进行了许多原型设计之后，我们现在已经开发出了一种对我们有效的方法。
我们拥有一个帐户，每个系统具有多个环境。
对于用户，有不同的角色仅允许访问相关环境-因此“ dev”角色仅允许访问“ dev”等。 比这稍微复杂一点，因为在每个环境中有多个角色具有不同的访问级别，但是您知道了-我希望！ 在我们的某些系统中，我们为单个用户强制使用不同的用户帐户，以使环境尽可能接近分开。这意味着我的开发帐户无法访问允许访问测试或实时访问的角色。
只有最高级别的管理员有权访问sysadmin（等）角色，而这些角色不是默认角色。
这种方法意味着我们几乎可以立即使用实时数据，测试数据或开发数据来启动多个开发环境。
我们确实有多个帐户，但是每个帐户运行一个单独的系统（在某些情况下我们必须对某些数据进行物理分区），并且我们使用数据共享在不同帐户之间传递通用数据。