CI/CD und DevOps in Snowflake (Teil 1): Ein umfassender Überblick über Features und Tools

Bei DevOps geht es darum, Entwicklung und Betrieb zusammenzubringen, um Software schneller und zuverlässiger zu bauen, zu testen und auszuliefern. Im Mittelpunkt stehen Automatisierung, Zusammenarbeit und ein minimiertes Risiko beim Weg in die Produktion. Die Methodik bündelt Best Practices aus verschiedenen Bereichen mit einem klaren Ziel: alles automatisieren, was sich automatisieren lässt, und sämtliche Prozessschritte abdecken. Code soll so oft wie nötig gebaut, deployt und getestet werden. DataOps überträgt dieses Mindset auf Datenteams. Statt nur Anwendungscode zu verwalten, behandelt DataOps Datenpipelines, Transformationen und Analytics wie Software – versioniert, getestet und automatisiert deployt. Kurz: DevOps für die Datenwelt. Snowflake bringt bereits eine Reihe von Features mit, die sich kombinieren lassen, um automatisierte Datenpipelines zu bauen und Infrastruktur-Deployments zu steuern. Werfen wir einen genaueren Blick darauf.

Declarative Change Management

Eines der ersten Themen, das Sie angehen sollten, ist die Definition Ihrer Snowflake- bzw. Datenbankinfrastruktur als Code. Genau dafür stellt Snowflake das Feature CREATE OR ALTER bereit. Damit lassen sich Snowflake-Objekte deklarativ definieren. Deklarativ heißt: Sie müssen weder Versionierung selbst pflegen noch Änderungen inkrementell anwenden – Sie definieren einfach den gewünschten Zielzustand. Sie geben etwa an, wie ein Tabellenschema, ein Task oder eine View aussehen soll, und Snowflake übernimmt den Rest. Es vergleicht automatisch den aktuellen Zustand mit Ihrer Definition und wendet im Hintergrund nur die nötigen Änderungen an.

CREATE OR ALTER

Mit CREATE OR ALTER schreiben Sie schlicht ein DDL-Skript mit diesem Keyword, und Snowflake stellt sicher, dass das Objekt nach der Ausführung dem definierten Zustand entspricht – ohne es neu erstellen zu müssen. Besonders wichtig ist das bei Objekten wie Tabellen: Würden Sie sie zum Ändern des Schemas (etwa beim Hinzufügen oder Entfernen einer Spalte) löschen und neu anlegen, könnten Daten verloren gehen. CREATE OR ALTER erhält stattdessen den bestehenden Zustand und wendet nur die nötigen Änderungen an.

Im Kern macht CREATE OR ALTER Folgendes:

• Vergleicht das Skript mit dem aktuellen Zustand in der Datenbank
• Generiert die nötigen DDL-Statements, um das Objekt zu aktualisieren
• Führt diese Statements aus

Snowflake unterstützt bereits eine breite Palette an Datenbank- und Account-Objekten, die sich per CREATE OR ALTER definieren lassen, darunter:

• Warehouse
• Database
• Schema
• Table
• View
• Stage
• Role
• Database Role
• Application
• Function
• External Function
• Procedure

⠀…und regelmäßig kommen weitere hinzu!

EXECUTE IMMEDIATE FROM

Ein weiteres starkes DevOps-Feature in Snowflake ist EXECUTE IMMEDIATE FROM. Damit führen Sie SQL-Befehle direkt aus Dateien aus, die in einer internen Stage oder einem GitHub-Repository liegen. Diese Dateien können Standard-SQL-Statements oder Snowflake-Scripting-Blöcke enthalten.

Genau das brauchen wir, um Objekte in Snowflake auszurollen. Statt auf komplexe Import-Mechanismen angewiesen zu sein, legen Sie Ihre DDL-Skripte mit Objektdefinitionen ab und führen sie direkt aus der Stage aus – einfach und effizient. Eine kürzlich hinzugekommene Erweiterung ist die Unterstützung für Jinja-Templates. Damit lassen sich SQL-Skripte und DDL-Definitionen deutlich dynamischer gestalten – über:

• Variablen
• Schleifen
• Bedingungen
• Makros und mehr

Mit Umgebungsvariablen parametrisieren Sie Deployments und wählen die Zielumgebung dynamisch. Schleifen erlauben es, über Benutzer, Warehouses oder beliebige andere Objekte zu iterieren – das vereinfacht Anlage und Pflege erheblich. In Ihren Templates können Sie sogar Inhalte aus anderen Dateien in Stages einbinden. Das eröffnet noch mehr Möglichkeiten.

EXECUTE IMMEDIATE bringt enormen Mehrwert beim Aufbau automatisierter Deployments. Was brauchen wir als Nächstes? Klar ist: Unsere DDL-Skripte gehören unter Versionskontrolle. Man weiß nie, was passiert – Sie brauchen die Möglichkeit, Änderungen rückgängig zu machen, nachzuvollziehen, was geändert wurde, und zu sehen, wer welche Änderung vorgenommen hat. Versionskontrolle sorgt für Transparenz, Nachvollziehbarkeit und Sicherheit Ihrer Deployments.

GIT-Integration

Snowflake bietet zudem eine native Git-Integration, mit der Sie Ihren Code in einem Remote-Repository ablegen und mit einer internen Stage synchronisieren. So stehen sämtliche Dateien direkt in Snowflake zur Ausführung bereit. Die Git-Integration ist aktuell zwar – bis auf wenige Ausnahmen – read-only, schließt aber eine weitere Lücke auf dem Weg zu einer vollständig automatisierten Deployment-Pipeline.

Probieren wir die GIT-Integration zusammen mit EXECUTE IMMEDIATE aus und führen ein Skript zur Anlage von Usern aus dem Repository aus:

1: Datei users.sql anlegen

CREATE USER joe;
GRANT ROLE developer TO USER joe;

2: Änderungen ins Repository committen:

git add users.sql
git commit -m "Adding new user"
git push

3: Updates aus dem Remote-Repository in die Snowflake-Repository-Stage holen

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

4: Code aus der Datei in Snowflake ausführen

1EXECUTE IMMEDIATE FROM @snowflake_git_demo/branches/main/sql/users.sql;

Das Thema haben wir in einem eigenen Blogpost ausführlich behandelt. Dort finden Sie einen umfassenden Überblick über die Git-Integration von Snowflake samt Schritt-für-Schritt-Anleitung. Sie erfahren:

• Was die Git-Integration von Snowflake ist
• Warum sie ein so spannendes Feature ist
• Wie Sie sie nutzen, um einen Handler einer Stored Procedure unkompliziert zu deployen
• Welche Operationen innerhalb von Snowflake unterstützt werden
• Aktuelle Einschränkungen
• Verschiedene Use Cases für die Git-Integration

Wir wissen nun, wie wir unsere Infrastruktur als Code definieren, ausführen und versionieren. Was fehlt noch? Das letzte Puzzleteil ist die Orchestrierung – und dabei gibt es zwei zentrale Perspektiven:

1. Die Snowflake-Perspektive – wie Sie sich verbinden, die richtigen Dateien auswählen und die Queries ausführen 2. Die Prozess-Perspektive – wie Sie alles zu einer eigenständigen Pipeline bündeln, die durch unterschiedliche Events ausgelöst wird

Konzentrieren wir uns zunächst auf die Snowflake-Perspektive. Die Prozessseite nehmen wir uns im nächsten Teil vor, wenn wir eine komplette Pipeline von Grund auf aufbauen.

SnowSQL

Das ist der ursprüngliche Snowflake-CLI-Client, mit dem sich viele Aufgaben aus der UI erledigen lassen – Queries ausführen, Objekte verwalten, Daten importieren und exportieren und vieles mehr. Er läuft auf allen gängigen Betriebssystemen und bietet verschiedene Authentifizierungsmethoden. SnowSQL war über viele Jahre das Tool der Wahl, vor allem bei Admins, doch es ist Zeit für den Umstieg: Snowflake CLI ist der neue Standard und sollte künftig die erste Wahl sein, da bestimmte Funktionalitäten in SnowSQL möglicherweise nicht mehr ergänzt werden.

Snowflake CLI

Dabei handelt es sich um ein Open-Source-Projekt, das ursprünglich aus der Community entstand, inzwischen aber vollständig von Snowflake gepflegt wird. Die CLI dient in erster Linie als Entwicklerschnittstelle, um verschiedene Arten von Code in Snowflake zu verwalten – darunter Stored Procedures, Funktionen, Native und Streamlit Apps, Snowpark, Snowpark Container Services, Git-Repositories und vieles mehr. Sie deckt ein breites Spektrum an Use Cases ab, die das Code- und Infrastrukturmanagement in Snowflake vereinfachen. Aus DevOps-Sicht erlauben beide CLI-Tools das Ausführen von Queries in Snowflake – die Wahl ist daher oft Geschmackssache. In unserem Fall nutzen wir den CLI-Client, um uns mit Snowflake zu verbinden und folgende Aktionen auszuführen:

• Synchronisieren der Git-Stage mit dem Remote-Repository
• Deployen des Codes per EXECUTE IMMEDIATE, um Infrastrukturobjekte wie Rollen, Warehouses, Datenbanken und mehr anzulegen

Wir haben die wesentlichen Bausteine behandelt, die Snowflake im DevOps-Umfeld mitbringt. Durch deren Kombination lassen sich robuste, automatisierte Pipelines für die Verwaltung Ihrer Snowflake-Infrastruktur aufbauen. Die nativen Funktionen sind jedoch nicht die einzige Option – es gibt zahlreiche starke Alternativen. Werfen wir einen Blick auf die wichtigsten, um das Bild abzurunden.

Terraform

Terraform ist wohl das mit Abstand verbreitetste Tool für diesen Zweck. Sie definieren damit Ihre Snowflake-Objekte als Code und verwalten sie genauso wie jede andere Cloud-Infrastruktur. Wer mit Infrastructure as Code (IaC) bereits vertraut ist, wird es als logische Erweiterung empfinden. Für viele Teams ist Terraform die erste Wahl – vor allem, wenn Sie es ohnehin schon für Ihre Cloud-Infrastruktur einsetzen. Den Einsatz auf Snowflake auszudehnen, ist dann nur konsequent. Der offizielle Snowflake-Provider hat sich über die Jahre deutlich weiterentwickelt und ist kürzlich General Available geworden. Die Unterstützung für neue Objekte wird kontinuierlich ausgebaut. Wenn Sie tiefer in Terraform mit Snowflake einsteigen möchten, lohnt sich ein Blick in unseren dedizierten Blogpost dazu.

Permifrost

Permifrost ist ein Open-Source-Tool, das speziell für das Management von Berechtigungen in Snowflake per Code entwickelt wurde. Das Python-basierte Tool ermöglicht es, Rollen, Grants und Ownership in YAML-Dateien zu definieren. Berechtigungen per Code zu verwalten, ist skalierbarer und kontrollierter, als sie manuell in der UI zu konfigurieren oder rohe SQL-Grants zu schreiben. Permifrost verfolgt beim Management von Snowflake-Berechtigungen einen deklarativen Ansatz. Sein Einsatzbereich ist allerdings begrenzt: Es kümmert sich ausschließlich um Berechtigungen und Rollen und übernimmt weder das Anlegen noch das Löschen von Objekten. Damit ist es weniger umfassend als andere Alternativen.

Titan

Titan ist ein weiteres Open-Source-Tool, um Snowflake-Infrastruktur als Code zu deployen. Es ist in Python geschrieben und will einige Schwächen von Terraform ausgleichen. So erlaubt es beispielsweise das dynamische Wechseln zwischen Rollen (z. B. SECURITYADMIN vs. SYSADMIN), arbeitet mit Python-basierten Definitionen (Sie müssen also keine neue Sprache oder Syntax lernen) und unterstützt SQL. Außerdem kommt es ohne State-Dateien wie bei Terraform aus.

Allerdings nutzt Titan Namen als eindeutige Identifier – wer eine Ressource umbenennt, legt damit eine neue an. Und weil Titan sich noch in aktiver Entwicklung befindet, ist die Unterstützung mancher Ressourcen möglicherweise eingeschränkt.

Noch ein kurzer Hinweis: Das Projekt wird im Wesentlichen von einer Person gepflegt, die sich derzeit auf andere Geschäftsfelder konzentriert. Das sollten Sie bei Ihrer Evaluierung im Hinterkopf behalten.

Schema change

Das letzte Tool ist vielleicht das älteste. Es ist Python-basiert und arbeitet imperativ – Änderungen werden also als Reihe von Modifikationen (ALTER-Statements) auf die ursprünglichen Objekte angewendet. Dafür müssen Sie versionierte Skripte pflegen und die Historie der angewendeten Änderungen mitführen. Schema Change wendet dann nur die Änderungen an, die im Vergleich zur Historie neu sind. Legen Sie etwa eine Tabelle mit Schema Change an und müssen später eine Spalte hinzufügen, entfernen oder andere Anpassungen vornehmen, schreiben Sie ein ALTER-Skript mit einer neuen Versionsnummer.

Schema Change arbeitet mit zwei Skriptarten: versioned und repeatable. Repeatable-Skripte werden bei jedem Tool-Lauf ausgeführt (sofern eine Änderung erkannt wurde). Das eignet sich gut für Views, da deren Neuerstellung nicht als destruktive Änderung gilt. Ein weiteres zentrales Konzept in Schema Change ist die Historie der ausgeführten Skripte, die in einer Datenbanktabelle abgelegt wird.

Fassen wir die Vor- und Nachteile dieser alternativen Tools in einer Tabelle zusammen.

Wie die Tabelle zeigt, hängt die richtige Tool-Wahl von verschiedenen Faktoren ab – etwa davon, welche Aspekte Sie automatisieren möchten (Infrastruktur, Berechtigungen oder nur SQL-Skripte), von Ihrem bestehenden Know-how oder von Plattformanforderungen. Jedes Tool kann in unterschiedlichen Szenarien die passende Wahl sein.

Zusammengefasst haben wir uns die nativen DevOps-Features von Snowflake sowie weitere am Markt verfügbare Alternativen angesehen und damit einen umfassenden Überblick über DevOps-Aktivitäten in Snowflake gegeben. Im nächsten Beitrag steigen wir in eine Schritt-für-Schritt-Anleitung zur Umsetzung ein!

Tomáš Sobotík·Senior Data Engineer & Snowflake SME bei Norlys

Tomas ist seit Langem Snowflake Data SuperHero und ausgewiesener Snowflake-Experte. Seine umfangreiche Erfahrung in der Datenwelt reicht über ein Jahrzehnt zurück. In dieser Zeit war er als Snowflake Data Engineer, Architekt und Admin in Projekten unterschiedlichster Branchen und Technologien tätig. Tomas ist ein zentrales Mitglied der Community, das sein Wissen aktiv teilt und andere inspiriert. Außerdem ist er O'Reilly-Instructor und leitet Live-Online-Trainings.