Arquivos e modelos dos DCM Projects¶

Mapear entre definições e objetos de projeto¶

Os arquivos de definição dos DCM Projects não são estritamente vinculados a um objeto de DCM project específico. Você pode usar o mesmo conjunto de definições para implantar em vários projetos, seja em contas Snowflake diferentes ou fazendo referência a perfis de configuração distintos. Por exemplo, os mesmos arquivos de definição em uma ramificação do repositório podem ser implantados em ambas as contas DEV e PROD, como mostrado na figura a seguir.

Da mesma forma, você pode executar um objeto de DCM Projects referenciando arquivos de definição de diferentes caminhos. Por exemplo, a automação de CI/CD pode implantar definições da ramificação principal, e você pode executar manualmente um PLAN dos arquivos de definição locais no mesmo projeto para verificar como as definições divergem da implantação mais recente. Você também pode usar essa abordagem para implantações manuais específicas de outras ramificações ou caminhos locais.

Macros¶

Arquivos de macros são todos os arquivos SQL localizados na pasta macros e suas subpastas. Eles só podem conter macros.

Um exemplo de uma estrutura de diretórios de um DCM project com arquivos de macros é:

My_dcm_project
 |_ manifest.yml
 |_ sources
    |_ definitions
       |_ my_definitions.sql
    |_ macros
       |_ my_global_macros.sql

Semelhante às funções nas linguagens de programação regulares, as macros ajudam a organizar as partes do código usadas com frequência em funções reutilizáveis, o que evita a repetição e segue o princípio DRY (Don’t Repeat Yourself). As macros nos DCM Projects funcionam da mesma forma que as macros Jinja2, com as seguintes exceções:

• Local dedicado para arquivos de macros na pasta macros.

• As macros definidas em arquivos de macros ficam automaticamente visíveis em outros arquivos de origem. A tag import do Jinja não é permitida.

• A definição duplicada de uma macro com o mesmo nome é detectada e rejeitada.

Comentários de modelo¶

Nos comandos SQL, você pode adicionar -- antes do código para transformar a linha em comentário. O Jinja ainda processa as variáveis no código SQL, mas deixa os comentários SQL.

Por exemplo, o seguinte código Jinja:

-- hello {{ project_owner_role }}

É renderizado como:

-- hello DCM_DEVELOPER

Os comandos transformados em comentários não são executados em SQL. Você pode usar comentários de modelo para depurar a modelagem Jinja sem afetar seu código SQL.

Para ignorar o código Jinja durante a renderização, adicione # entre colchetes de abertura e fechamento, como mostrado no exemplo a seguir:

{# This Jinja comment will not appear in the rendered output. #}

Configurações¶

Ao usar modelos em suas definições de objeto, você tem as seguintes opções:

• Atribuir valores a variáveis em tempo de execução.

• Definir diferentes perfis de configuração em templating: configurations: no manifest.yml. Cada destino pode fazer referência a uma configuração por meio de templating_config. Consulte Configurações de modelagem de projeto para obter mais detalhes.

  Se os perfis de configuração forem definidos e um destino fizer referência a um deles por meio de templating_config, a configuração será aplicada automaticamente ao usar esse destino. Para exemplos, consulte Planejar um DCM project.

  O principal caso de uso dos perfis de configuração nos DCM Projects é para apontar ambientes diferentes. Os perfis de configuração permitem que você faça o seguinte:

  • Implante o mesmo código em vários ambientes.

  • Teste o código de produção em um ambiente que não seja de produção em escala reduzida.

  • Mantenha vários ambientes isolados na mesma conta.

  Nem todas as configurações de modelagem precisam ser referenciadas por um perfil de destino. Você pode manter configurações não usadas para alternar a configuração de modelagem em seu destino entre uma e outra.

• Definir valores padrão compartilhados em templating: defaults: para evitar a repetição de variáveis comuns nas configurações. Consulte Configurações de modelagem de projeto para obter mais detalhes.

• Substituir variáveis específicas por valores únicos em tempo de execução usando o sinalizador --variable na CLI.

As variáveis são resolvidas com uma hierarquia de três níveis: padrões globais < variáveis de configuração < variáveis de execução em tempo de execução.

Dicionários¶

A modelagem dos DCM Projects oferecem suporte a dicionários como valores de variáveis, permitindo uma configuração estruturada para implantações complexas multilocatário ou de vários recursos.

Ao agrupar os detalhes de configuração relacionados em dicionários, você obtém:

• Controle granular: aplique configurações específicas, como tamanhos de warehouse, políticas de retenção e concessões, a recursos individuais sem escrever uma lógica exclusiva para cada variação.

• Bases de código mais limpas: substitua scripts repetitivos embutidos em código por loops dinâmicos que se adaptam conforme a configuração.

• Escalabilidade: integre novas equipes ou recursos adicionando entradas à sua configuração, em vez de refatorar pipelines de implantação.

templating:
  defaults:
    user: "GITHUB_ACTIONS_SERVICE_USER"
    wh_size: "X-SMALL"
  configurations:
    PROD:
      env_suffix: ""
      project_owner_role: "DCM_PROD_DEPLOYER"
      teams:
        - name: "Marketing"
          wh_size: "MEDIUM"
          data_retention_days: 14
          needs_sandbox_schema: true
        - name: "Finance"
          wh_size: "X-LARGE"
          data_retention_days: 90
          needs_sandbox_schema: false
        - name: "HR"
          data_retention_days: 30
          needs_sandbox_schema: false

-- loop through team dictionaries
{% for team in teams %}
    {% set team_name = team.name | upper %}

    -- inject dictionary values directly into object properties
    define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}
        comment = 'using JINJA dictionary values'
        data_retention_time_in_days = {{ team.data_retention_days }};

    -- pass the name to your macro
    {{ create_team_roles(team_name) }}

    define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.PRODUCTS(
        ITEM_NAME varchar,
        ITEM_ID varchar,
        ITEM_CATEGORY array
    )
    data_metric_schedule = 'TRIGGER_ON_CHANGES';

    {% if team_name == 'HR' %}
        define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.EMPLOYEES(
            NAME varchar,
            ID int
        )
        comment = 'This table is only created in HR';
    {% endif %}

    -- use dictionary booleans to deploy optional infrastructure
    {% if team.needs_sandbox_schema | default(false) %}
        define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}_SANDBOX
            comment = 'Sandbox schema defined via dictionary flag'
            data_retention_time_in_days = 1;
    {% endif %}

{% endfor %}