DevOps com Snowflake¶

Projetos DCM (recomendado)¶

Os Projetos DCM (projetos de gerenciamento de alterações de banco de dados) fornecem uma abordagem declarativa de infraestrutura como código para gerenciar seu ambiente Snowflake. Em vez de escrever scripts imperativos que especificam cada etapa, você define o estado de destino desejado para seus objetos. O Snowflake compara essas definições com o estado atual e determina as alterações necessárias.

Um projeto DCM consiste em:

• Um arquivo de manifesto (manifest.yml) que especifica os destinos de implantação, as funções de proprietário e as configurações de modelo para cada ambiente.

• Arquivos de definição (arquivos SQL em sources/definitions/) que contêm instruções DEFINE para seus objetos Snowflake, GRANT para controle de acesso e ATTACH para expectativas de qualidade de dados.

O exemplo a seguir mostra um arquivo de definição que cria infraestrutura para várias equipes usando o modelo Jinja2:

{% for team in teams %}

  DEFINE DATABASE {{team.name}}_DB;

  DEFINE WAREHOUSE {{team.name}}_WH
    WITH
      warehouse_size = '{{team.wh_size}}'
      auto_suspend = 300;

  DEFINE ROLE {{team.name}}_ADMIN;

  GRANT OWNERSHIP ON DATABASE {{team.name}}_DB TO ROLE {{team.name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team.name}}_WH TO ROLE {{team.name}}_ADMIN;

{% endfor %}

Para obter a documentação completa sobre projetos DCM, incluindo como configurar seus arquivos de projeto, gerenciar vários ambientes e automatizar implantações, consulte Snowflake DCM Projects.

Projetos dbt no Snowflake¶

Os projetos dbt no Snowflake permitem que você implante e execute projetos dbt Core como objetos Snowflake nativos. Você define transformações SQL em modelos dbt, as implanta como um objeto DBT PROJECT com controle de versão e as executa com o Snowflake SQL ou a Snowflake CLI. Você pode agendar execuções com tarefas do Snowflake e integrar a implantação em pipelines CI/CD.

Para obter mais informações, consulte Projetos dbt no Snowflake.

Alternativa: CREATE OR ALTER com scripts com controle de versão¶

Para alterações de objetos individuais fora de um projeto DCM, você pode usar o comando CREATE OR ALTER <objeto>, que cria o objeto ou o altera para corresponder à definição especificada pelo comando. Ao usar este comando a partir de um arquivo com controle de versão em um repositório remoto, você pode reverter as alterações para uma versão anterior executando uma versão anterior do arquivo.

CREATE OR ALTER TABLE vacation_spots (
  city VARCHAR,
  airport VARCHAR,
  avg_temperature_air_f FLOAT,
  avg_relative_humidity_pct FLOAT,
  avg_cloud_cover_pct FLOAT,
  precipitation_probability_pct FLOAT
) data_retention_time_in_days = 1;

from snowflake.core import Root
from snowflake.core.table import PrimaryKey, Table, TableColumn

my_table = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"].fetch()
my_table.columns.append(TableColumn(name="city", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="airport", datatype="varchar", nullable=False))
my_table.columns.append(TableColumn(name="avg_temperature_air_f", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_relative_humidity_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="avg_cloud_cover_pct", datatype="float", nullable=False))
my_table.columns.append(TableColumn(name="precipitation_probability_pct", datatype="float", nullable=False))

my_table_res = root.databases["my_db"].schemas["my_schema"].tables["vacation_spots"]
my_table_res.create_or_alter(my_table)

Planejar com projetos DCM¶

Os projetos DCM usam um modelo de planejamento e implantação. O comando PLAN compara seus arquivos de definição com o estado atual de sua conta e produz uma lista de alterações propostas sem modificar nada.

É possível executar um plano usando a Snowflake CLI:

snow dcm plan --target PROD

Ou usando SQL:

EXECUTE DCM PROJECT my_db.my_schema.my_project
  PLAN
  USING CONFIGURATION PROD
FROM
  '@my_stage/my_project/';

Revise a saída para confirmar as criações, alterações e descartes esperados antes de prosseguir com a implantação.

Ações do GitHub¶

Você pode usar o GitHub Actions para automatizar os trabalhos que constituem um pipeline CI/CD.

Para autenticar com segurança, a Snowflake recomenda o uso da federação de identidade de carga de trabalho (workload identity federation, WIF) com o OpenID Connect (OIDC) em vez de credenciais estáticas, como senhas ou chaves privadas. Com o WIF OIDC, o GitHub Actions solicita um token de curta duração do provedor OIDC do GitHub, e o Snowflake verifica o token diretamente. Nenhum segredo de longa duração é armazenado em seu repositório.

Para configurar o WIF OIDC, crie um usuário de serviço do Snowflake que confie no provedor OIDC do GitHub:

CREATE USER github_deployer
  TYPE = SERVICE
  DEFAULT_ROLE = deployer_role
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = 'https://token.actions.githubusercontent.com'
    SUBJECT = 'repo:<owner>/<repo>:environment:<environment_name>'
  );

Para obter mais informações sobre como configurar a declaração do assunto e a WIF em geral, consulte Federação de identidades de carga de trabalho.

O exemplo a seguir mostra um fluxo de trabalho que usa o WIF OIDC e os projetos DCM para planejar e implantar alterações no push para a ramificação main:

name: Deploy DCM project to production

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Set up Snowflake CLI
        uses: snowflakedb/snowflake-cli-action@v2
        with:
          use-oidc: true
          cli-version: "3.11"

      - name: Plan DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm plan --target PROD --save-output -x

      - name: Deploy DCM project
        env:
          SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
        run: snow dcm deploy --target PROD -x

Para obter mais informações sobre como configurar CI/CD com a Snowflake CLI, incluindo métodos alternativos de autenticação, consulte Integração de CI/CD com Snowflake CLI.

Perfis de conexão para direcionamento de ambiente¶

Com os projetos DCM, você pode definir vários destinos de implantação em seu arquivo manifest.yml. Cada destino mapeia para uma conta (ou banco de dados) Snowflake, objeto de projeto, função de proprietário e configuração de modelo específicos. É possível implantar os mesmos arquivos de definição em todos os ambientes com configurações específicas do ambiente aplicadas por meio de perfis de configuração.

targets:
  DEV:
    account_identifier: MYORG-MYACCOUNT_DEV
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_DEV
    project_owner: DEV_DEPLOYER
    templating_config: DEV

  PROD:
    account_identifier: MYORG-MYACCOUNT_PROD
    project_name: MY_DB.MY_SCHEMA.MY_PROJECT_PROD
    project_owner: PROD_DEPLOYER
    templating_config: PROD

templating:
  configurations:
    DEV:
      wh_size: "X-SMALL"
    PROD:
      wh_size: "LARGE"

Para padrões corporativos, como configurações de vários projetos e colaboração em equipe, consulte Casos de uso corporativos dos DCM Projects.

Avançado: parametrização Jinja para scripts personalizados¶

Os projetos DCM têm compatibilidade nativa com modelos Jinja2 em arquivos de definição. É possível usar variáveis ​​de modelo, loops, condições, macros e dicionários para tornar suas definições reutilizáveis ​​em diferentes ambientes. Os valores das variáveis ​​vêm de perfis de configuração no manifest.yml ou de substituições em tempo de execução.

Para obter detalhes sobre modelos de DCM, consulte Arquivos e modelos dos DCM Projects.

Você também pode parametrizar scripts SQL independentes (fora de projetos DCM) usando Jinja2 com EXECUTE IMMEDIATE FROM. A Snowflake CLI também permite que você passe variáveis ​​de ambiente para scripts Python.

Para alterar um destino de implantação, por exemplo, você substitui o nome do banco de dados de destino por uma variável Jinja, como {{ environment }} em scripts SQL ou uma variável de ambiente em scripts Python. Essa técnica é mostrada nos exemplos de código SQL e Python a seguir:

CREATE OR ALTER TASK {{ environment }}.my_schema.my_task
  WAREHOUSE = my_warehouse
  SCHEDULE = '60 minute'
  AS select pi();

import os
from snowflake.core import Root, CreateMode
from datetime import timedelta
from snowflake.core.task import Task

my_task = Task(
    name="my_task",
    warehouse="my_warehouse",
    definition="select pi()",
    schedule=timedelta(minutes=60)
)
root = Root(Session.builder.getOrCreate())
tasks = root.databases[os.environ["environment"]].schemas["my_schema"].tasks
tasks.create(my_task, mode=CreateMode.or_replace)