DevOps mit Snowflake¶

DCM-Projekte (empfohlen)¶

DCM-Projekte (Database Change Management-Projekte) bieten einen deklarativen Infrastruktur-as-Code-Ansatz für die Verwaltung Ihrer Snowflake-Umgebung. Anstatt imperative Skripte zu schreiben, die jeden Schritt spezifizieren, definieren Sie den gewünschten Zielzustand Ihrer Objekte. Snowflake vergleicht diese Definitionen mit dem aktuellen Stand und ermittelt die erforderlichen Änderungen.

EinDCM-Projekt besteht aus:

• Einer Manifest-Datei (manifest.yml), die Bereitstellungsziele, Eigentümerrollen und Konfigurationsvorlagen für jede Umgebung angibt.

• Definitionsdateien (SQL-Dateien unter``sources/definitions/``), die DEFINE-Anweisungen für Ihre Snowflake-Objekte, GRANT-Anweisungen für die Zugriffssteuerung undATTACH-Anweisungen für Datenqualitätserwartungen enthalten.

Das folgende Beispiel zeigt eine Definitionsdatei, die mithilfe von Jinja2-Vorlagen die Infrastruktur für mehrere Teams erstellt:

{% 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 %}

Eine vollständige Dokumentation zu DCM-Projekten, einschließlich Einrichten Ihrer Projektdateien, Verwalten mehrerer Umgebungen und Automatisieren von Bereitstellungen, siehe Snowflake DCM Projects.

dbt-Projekte in Snowflake¶

Mit dbt-Projekten in Snowflake können Sie `dbt-Core-<https://www.getdbt.com/>`__-Projekte als native Snowflake-Objekte bereitstellen und ausführen. Sie definierenSQL-Transformationen in dbt-Modellen, stellen diese als versioniertes DBTPROJECT-Objekt bereit und führen sie mit Snowflake-SQL oder der Snowflake-CLI aus. Sie können Ausführungen mit Snowflake-Aufgaben planen und die Bereitstellung in CI/CD-Pipelines integrieren.

Weitere Informationen dazu finden Sie unter dbt-Projekte in Snowflake.

Alternative: CREATE OR ALTER mit versionierten Skripten¶

Für einzelne Objektänderungen außerhalb eines DCM-Projekts können Sie den CREATE OR ALTER <objekt>-Befehl verwenden, der das Objekt erstellt oder es so verändert, dass es mit der vom Befehl angegebenen Definition übereinstimmt. Wenn Sie diesen Befehl von einer versionierten Datei in einem Remote-Repository aus verwenden, können Sie Änderungen auf eine frühere Version zurücksetzen, indem Sie eine frühere Version der Datei ausführen.

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)

Mit DCM-Projekten planen¶

DCM-Projekte verwenden ein Erst-Planen-dann-Bereitstellen-Modell. Der PLAN-Befehl vergleicht Ihre Definitionsdateien mit dem aktuellen Status Ihres Kontos und erstellt eine Liste der vorgeschlagenen Änderungen, ohne etwas zu ändern.

Sie können einen Plan mithilfe der Snowflake-CLI ausführen:

snow dcm plan --target PROD

Oder mit SQL:

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

Überprüfen Sie die Ausgabe, um die erwarteten Erstellungen, Änderungen und Löschungen zu bestätigen, bevor Sie mit der Bereitstellung fortfahren.

GitHub Actions¶

Sie können GitHub-Aktionen verwenden, um die Jobs zu automatisieren, die eine CI/CD-Pipeline bilden.

Um sich sicher zu authentifizieren, empfiehlt Snowflake die Verwendung der Workload Identity Federation (WIF) mit OpenID Connect (OIDC) anstelle von statischen Anmeldeinformationen wie Kennwörtern oder private Schlüssel. Mit WIFOIDC fordern GitHub-Aktionen ein kurzlebiges Token vom OIDC-Anbieter von GitHub an und Snowflake überprüft das Token direkt. In Ihrem Repository werden keine langlebigen Geheimnisse gespeichert.

Um WIFOIDC einzurichten, erstellen Sie einen Snowflake-Dienstbenutzer, der dem OIDC-Anbieter von GitHub vertraut:

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>'
  );

Weitere Informationen zum Konfigurieren des Subjektanspruchs und von WIF im Allgemeinen siehe:doc:/user-guide/workload-identity-federation.

Das folgende Beispiel zeigt einen Workflow, der WIF OIDC- undDCM-Projekte zur Planung und Bereitstellung von Änderungen an Push an den``main``-Zweig verwendet:

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

Weitere Informationen zum Einrichten vonCI/CD mit der Snowflake-CLI, einschließlich alternativer Authentifizierungsmethoden, siehe Integration von CI/CD mit Snowflake CLI.

Verbindungsprofile für Umgebungs-Targeting¶

Mit DCM-Projekten können Sie in Ihrer manifest.yml-Datei mehrere Bereitstellungsziele definieren. Jedes Ziel ist einem bestimmten Snowflake-Konto (oder einer Datenbank), einem Projektobjekt, einer Eigentümerrolle und einer Vorlagenkonfiguration zugeordnet. Dieselben Definitionsdateien können in allen Umgebungen bereitgestellt werden, wobei umgebungsspezifische Einstellungen über Konfigurationsprofile angewendet werden.

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"

Für Enterprise-Muster wie z. B. Multi-Projekt-Setups und Teamzusammenarbeit siehe:doc:/user-guide/dcm-projects/dcm-projects-enterprise.

Erweitert: Jinja-Parallelisierung für benutzerdefinierte Skripte¶

DCM-Projekte unterstützen nativ Jinja2-Vorlagen in Definitionsdateien. Sie können Vorlagenvariablen, Schleifen, Bedingungen, Makros und Wörterbücher verwenden, um Ihre Definitionen in verschiedenen Umgebungen wiederverwenden zu können. Die Variablenwerte stammen aus Konfigurationsprofilen in der manifest.yml oder von Laufzeitüberschreibungen.

Weitere Informationen zu DCM-Vorlagen finden Sie unter DCM Projects-Dateien und -Vorlagen.

Sie können auch eigenständige SQL-Skripte (außerhalb von DCM-Projekten) unter Verwendung von Jinja2 mit EXECUTE IMMEDIATE FROM parametrisieren. Sie können auch mit der Snowflake-CLI Umgebungsvariablen an Python-Skripte übergeben.

Wenn Sie z. B. ein Bereitstellungsziel ändern möchten, ersetzen Sie den Namen der Zieldatenbank durch eine Jinja-Variable wie {{ environment }} in SQL-Skripten oder eine Umgebungsvariable in Python-Skripten. Diese Technik wird in den folgenden SQL- und Python-Codebeispielen gezeigt:

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)