Casos de uso corporativos dos DCM Projects¶
Este tópico aborda como usar os DCM Projects em ambientes corporativos, por exemplo, gerenciar vários projetos, trabalhar com diversos ambientes e colaborar em projetos.
Quando usar vários projetos DCM¶
Para decidir se e como dividir um DCM project em vários projetos, considere a propriedade e a modelagem.
Propriedade¶
Cada projeto tem uma função de proprietário capaz de implantar todos os objetos definidos. As concessões permitem o gerenciamento de acesso granular de objetos individuais dentro do projeto. Entretanto, se grupos de usuários diferentes forem responsáveis pela implantação de alterações em um projeto, a prática mais comum é dividir um DCM project de acordo com isso.
O resultado a seguir é um exemplo de cenário:
O administrador da plataforma implanta um banco de dados e um warehouse, cria a função de administrador da equipe e concede privilégios CREATE ao administrador da equipe para um conjunto definido de tipos de objetos dentro desse banco de dados, bem como acesso a um conjunto definido de integrações no nível da conta.
O administrador da equipe agora pode decidir como organizar esquemas e tabelas dinâmicas nesse banco de dados, ajustar as frequências de atualização e conceder acesso de leitura mais granular a cada membro da equipe.
Veja a solução abaixo:
O administrador da plataforma implanta a infraestrutura de alto nível para a equipe e concede ao administrador da equipe o privilégio para criar projetos DCM project no respectivo banco de dados.
Agora o administrador da equipe também pode se beneficiar dos DCM Projects criando um ou mais projetos no banco de dados da equipe para gerenciar tabelas e concessões aos membros da equipe.
Variáveis de modelo¶
Se um DCM project define um intervalo de objetos que são e devem permanecer em grande parte semelhantes, em geral, o mais adequado é defini-los uma vez como modelo parametrizado.
O resultado a seguir é um exemplo de cenário:
A equipe da plataforma implanta um banco de dados para cada equipe regional na organização.
Com o tempo, é esperado que novas regiões sejam adicionadas.
Todas as regiões requerem basicamente a mesma configuração de esquema, tabelas de destino, funções e warehouse.
As alterações no modelo de banco de dados devem ser aplicadas a todas as equipes, por exemplo, adicionando uma função somente leitura.
Veja a solução abaixo:
É possível executar um único conjunto de definições em um loop para cada equipe regional listada no perfil do manifesto.
Quando mais elementos do modelo começam a divergir e o número de condições de modelagem aumenta, pode se tornar mais fácil de ler e manter projetos DCM separados com suas definições de objetos individuais.
Usar os DCM Projects com vários ambientes¶
O diagrama a seguir mostra um fluxo de trabalho típico para implantar um DCM project em vários ambientes.
Contas separadas ou bancos de dados separados¶
O Snowflake geralmente recomenda a configuração de cada ambiente como uma conta Snowflake separada. Isso garante a separação completa da infraestrutura de produção de qualquer desenvolvimento experimental e garante o acesso restrito do desenvolvedor aos dados de produção.
Entretanto, com um gerenciamento de acesso cuidadoso, você pode gerenciar com sucesso vários ambientes em uma conta Snowflake. Isso é mais fácil quando os bancos de dados estão claramente separados e pode se tornar mais desafiador quando há objetos e integrações no nível da conta envolvidos.
O benefício de uma configuração de conta única é a capacidade de clonar facilmente a infraestrutura e os dados de produção para testar as alterações antes de implantá-las em produção. No entanto, copiar partes dos dados e da infraestrutura de produção para uma conta diferente, por exemplo, por meio de compartilhamentos de dados internos da organização, pode ser mais caro.
Impacto sobre a modelagem do DCM project¶
Nomes de objetos distintos para cada ambiente são um requisito para as configurações de conta única, por exemplo, para manter EMEA_DB e EMEA_ADMIN separados de EMEA_DB_DEV e EMEA_ADMIN_DEV. A Snowflake também recomenda essa prática para configurações de várias contas. Os nomes modelados permitem que várias instâncias de entidades, como EMEA_DB_DEV_JOHN e EMEA_DB_DEV_MARY, coexistam para um desenvolvimento independente e criem e destruam rapidamente ambientes sandbox para testar soluções diferentes.
Isso se aplica a todos os objetos no nível da conta, como bancos de dados, funções e warehouses. Em seguida, você precisa aplicar esses nomes modelados a todos os nomes totalmente qualificados dos objetos aninhados.