Mir*_*Kim 5 workflow snowflake-cloud-data-platform dbt
我们目前正在实现雪花和 dbt，并希望在开发和生产之间拆分雪花数据库，以便我们在发布新数据模型之前有一个可以测试的数据库。我们计划使用 dbt 来创建未来的所有数据模型。我对工作流程的后勤工作有几个问题：
我们如何保持开发和生产同步？（或者应该是？）我知道雪花有一个克隆功能，您可以重新创建元数据，而无需复制数据。我们应该将产品数据库克隆到开发人员吗？以一天为周期？那些在开发中拥有物化资源的用户会怎么样——他们会丢失这些数据。
我们是否应该让部署到产品成为 CICD 流程的一部分，并且只有完全合并的拉取请求（在雪花开发上测试）才能部署到雪花产品？这会带来太多瓶颈吗？
很想了解人们如何构建工作流程来维护开发和生产雪花环境。
一个常见的实现是拥有特定于用户的开发模式（例如，dbt_lfolsom），每当用户执行任何类型的dbt run;时，这些开发模式都会被写入并覆盖。然后是一个单一的产品模式（例如，analytics），当作业“在生产中”执行时，该模式被写入并覆盖。
“在开发中”运行 dbt 意味着dbt由单个用户（使用 dbt Cloud 或 dbt CLI）执行命令，以便将数据写入专门用于开发的专用模式。
“在生产中”运行 dbt 意味着运行dbt在 dbt Cloud 中配置为作业的命令（或使用其他编排工具）将数据写入特定的“prod”目标模式。
查看这篇关于在生产环境中运行 dbt 的文章。
借助 dbt Cloud，您还可以写入在创建或更新 GitHub PR 时自动创建的 PR 特定架构，这可能是您希望用于 CI/CD 的架构。查看这篇关于选项的文章。
您绝对可以（应该）将生产作业配置为仅在完全合并的代码上运行。
如果出于某种原因，您确实需要 prod 和 dev 成为单独的数据库而不是单独的模式，我认为您可以创建单独的 dbt项目，这些项目使用来自同一 git 远程存储库的代码，但配置为（在 dbt Cloud 中或使用您的profiles.yml）写入不同的雪花数据库。但我认为这是一种非常规的方法，需要做更多的工作。