Snowflakes Git-Integration im Detail

Mit der Git-Integration verbinden Sie Ihr Snowflake-Konto nativ mit einer der unterstützten Git-Plattformen (z. B. GitHub, GitLab usw.) und synchronisieren die Inhalte eines Remote-Repositorys mit Ihrem Snowflake-Konto. Für diese Synchronisation nutzt Snowflake einen speziellen Stage-Typ: den sogenannten Repository Stage. Dieser Repository Stage wird mit dem Remote-Git-Repository synchronisiert und ist anschließend ein lokales Repository mit einem vollständigen Klon des Remote-Repositorys – inklusive allem, was dazugehört: Branches, Commits usw.

Damit steht Ihnen ein vollständiger Klon des Repositorys direkt in Ihrem Snowflake-Konto zur Verfügung. Sie können die abgerufenen Dateien in Ihren Snowflake-Anwendungen nutzen oder UDFs bzw. Stored Procedures schreiben, deren Handler-Code in einem Remote-Git-Repository liegt und mit dem Repository Stage synchronisiert wird. So bleibt der Code mühelos versioniert, und der Stage lässt sich aktualisieren, sobald sich das Repository ändert.

Außerdem können Sie jede Datei aus jedem Branch oder Commit direkt in Snowflake verwenden.

Dank dieser Integration vereinfachen Sie den Entwicklungszyklus für Ihren Code spürbar, wenn Sie ihn versioniert halten möchten. Nehmen wir den Handler-Code einer Stored Procedure als Beispiel. Vor der Integration mussten Sie die Versionskontrolle eigenständig und außerhalb von Snowflake organisieren. Sie haben Ihren Handler-Code in VS Code geschrieben und getestet. Nach Abschluss der Entwicklung mussten Sie die Änderungen in ein Remote-Repository committen, um sie zu versionieren. Gleichzeitig mussten Sie den Code in Snowflake ausrollen und eine Stored Procedure mit diesem Code als Handler anlegen.

Das hieß: entweder den Code manuell in einen Snowflake Stage hochladen und anschließend die Stored Procedure anlegen oder die Snowflake CLI nutzen, um Upload und Anlage in einem Rutsch zu erledigen. So oder so – ein zusätzlicher Schritt, der nicht direkt mit Ihrem versionierten Code verknüpft war. Musste der Code angepasst werden, lief der ganze Prozess wieder von vorn: Code entwickeln, ins Repository committen und die Handler-Datei in Snowflake aktualisieren.

Sehen wir uns nun an, wie die native Git-Integration diesen Ablauf strafft. Da Sie den Handler-Code direkt im Repository Stage referenzieren, wird der Handler der Stored Procedure automatisch aktualisiert und bleibt versioniert, sobald Sie Änderungen committen und Ihren Repository Stage synchronisieren. Keine getrennten Einzelprozesse mehr (Versionskontrolle & SP-Updates) – sondern ein einziger, durchgängiger Workflow.

Snowflakes Git-Integration unterstützt Git-Repositorys folgender Plattformen:

• GitHub
• GitLab
• BitBucket
• Azure DevOps
• AWS CodeCommit

In diesem Beispiel schreiben wir einen einfachen Hello-World-Handler für eine Stored Procedure in Python, committen die Änderungen in ein Remote-GitHub-Repository und ziehen den Code per Git-Integration nach Snowflake. Anschließend ändern wir den Handler-Code und sehen, wie einfach sich der SP-Handler-Code dank der Git-Integration in Snowflake aktualisieren lässt. Zuerst ein einfaches Diagramm, das zeigt, was wir bauen werden:

1. Zuerst entwickeln wir den Handler-Code lokal in VS Code und committen ihn in ein GitHub-Repository.
2. Anschließend legen wir in Snowflake einen Repository Stage an, der auf das Remote-Repository verweist. Außerdem brauchen wir ein neues Secret für die Zugangsdaten unseres Git-Kontos.
3. Sobald der Repository Stage in Snowflake steht, synchronisieren wir ihn mit dem Remote-Repository, um den Code nach Snowflake zu bringen.
4. Zum Schluss legen wir in Snowflake eine Stored Procedure an und binden den Handler-Code aus unserem Repository Stage ein.

Gehen wir jeden Schritt im Detail durch.

1. Handler-Code entwickeln

Ich habe eine einfache Handler-Funktion namens hello_world geschrieben und in mein Repository gepusht. Jetzt können wir die nötigen Objekte in Snowflake anlegen und dieses Remote-Repository mit einem neuen Repository Stage in Snowflake verknüpfen.

2. Secret anlegen

Beginnen wir mit dem Secret. Zur Authentifizierung nutze ich ein Personal Access Token.

3. API-Integration anlegen

Wir brauchen außerdem eine neue API-Integration, um Snowflake mit GitHub zu verbinden. Der Parameter API_ALLOWED_PREFIXES verweist auf die URL meines GitHub-Kontos; für die Authentifizierung verwenden wir das im vorigen Schritt erstellte Secret.

4. Repository Stage anlegen

Nun können wir einen Git Repository Stage anlegen und die zuvor erstellten Werte übergeben. Origin ist unser Git-Repository, das wir anbinden möchten.

5. Repository Stage mit Remote synchronisieren

Der Repository Stage steht – synchronisieren wir ihn jetzt mit dem Remote-Repository.

6. Stored Procedure anlegen

Und das war's! Damit haben wir eine funktionierende Integration zwischen Snowflake und dem Remote-Git-Repository. Unser Stored-Procedure-Handler stammt aus dem Repository Stage, der mit dem Remote-Repository synchronisiert ist. Legen wir die Stored Procedure an:

7. Synchronisation mit dem Remote-Repository

Wie können wir sie testweise ausführen?

Ändern wir nun den Code, um zu sehen, wie unkompliziert sich Updates in Snowflake einspielen lassen. Auch diese Änderungen nehmen wir lokal in VS Code vor und committen sie ins Remote-Repository. Eine kleine Anpassung: Wir wandeln die Nachricht in Großbuchstaben um.

Sobald die Änderungen im Repository committet sind, müssen wir unseren Repository Stage in Snowflake aktualisieren (synchronisieren).

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

Jetzt steht der aktualisierte Handler-Code in Snowflake bereit! Mehr braucht es nicht. Kein Neuanlegen der Procedure, nichts dergleichen. Wir können die Stored Procedure einfach ausführen, um zu prüfen, ob der Code aktualisiert wurde:

8. Automatisches Update bei einem neuen Merge

Das Ganze lässt sich auch automatisieren. Angenommen, Sie arbeiten nach einem gängigen Git-Workflow, bei dem Änderungen in eigenen Feature-Branches entstehen und in den Main-Branch gemergt werden. Wir können einen GitHub-Actions-Workflow bauen, der den Befehl ALTER GIT REPOSITORY beim Mergen des PRs ausführt – so wird der Repository Stage automatisch aktualisiert, sobald neuer Code in den Main-Branch gepusht wird!

Hier ein einfaches Beispiel. Sie können entweder SnowSQL oder SnowCLI verwenden, um das SQL-Statement auszuführen.

TORY command when the PR is merged, so the repository stage is automatically updated every time you push new code into your main branch!

Here is a simple example. You can use either SnowSQL or SnowCLI to run the SQL statement.

name: Deploying Stored procedure updates
env:
  SNOWSQL_ACCOUNT: ${{secrets.SF_ACCOUNT}}
  SNOWSQL_USER: ${{secrets.SF_USER}}
  SNOWSQL_PWD: ${{secrets.SF_PASSWORD}}
  SNOWSQL_DATABASE: ${{ secrets.SF_DATABASE }}
  SNOWSQL_SCHEMA: ${{ secrets.SF_SCHEMA }}
  SNOWSQL_ROLE: ${{ secrets.SF_ROLE }}
  SNOWSQL_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}

on:

Code anzeigen

Und so sieht die Ausgabe des GitHub-Actions-Workflow-Laufs aus:

Nachdem wir das Einrichten der Git-Integration durchgegangen sind, gibt es noch weitere Funktionen, die einen Blick wert sind:

Repositorys in Snowflake verwalten

Unser Beispiel hat nur zwei Operationen rund um Git-Repositorys in Snowflake gezeigt: das Anlegen des Repository Stage und den ALTER-Befehl, um Remote-Updates abzurufen. Sehen wir uns weitere Möglichkeiten an, was Sie mit Ihren Repositorys tun können:

Branches eines Repositorys auflisten

Wir können alle Branches in unserem Repository Stage zusammen mit Pfad und Commit-Hash auflisten.

1SHOW GIT BRANCHES IN snowflake_git_demo;

Dateien eines Repositorys auflisten

Wie bei jedem internen oder externen Stage lassen sich auch die Dateien im Repository Stage mit dem LIST-Befehl auflisten:

1LS @snowflake_git_demo

Repository Stage

Beim Repository Stage können wir Dateien außerdem nach einzelnem Branch-Namen auflisten:

1LS @snowflake_git_demo/branches/main

Einzelner Commit-Hash

1LS @snowflake_git_demo/commits/<<add_my_commit_hash>>

Dateien nach Tag-Namen auflisten

1LS @snowflake_git_demo/tags/tag_name

Eigenschaften des Repository Stage prüfen

Wie bei vielen anderen Snowflake-Objekten gibt es auch für Repository Stages die Befehle SHOW und DESCRIBE. Sie liefern nützliche Metadaten: wo Ihr Repository Stage liegt (Datenbank- und Schema-Name), welches Origin das Remote-Repo hat, welche API-Integration die Verbindung zwischen Git und Snowflake herstellt und wie das Secret heißt, das die Zugangsdaten für die Remote-Git-Verbindung enthält.

Code aus einem Repository ausführen

Dateien im Repository abzulegen ist praktisch – aber was ist mit dem Ausführen des Codes? Schon einmal darüber nachgedacht? Snowflake bietet den Befehl EXECUTE IMMEDIATE FROM, mit dem sich SQL-Code direkt aus Dateien ausführen lässt. Sie können Ihre Konto-Konfiguration (User, Rollen, Warehouse-Anlage) als SQL-Dateien im Repo ablegen und dank dieses Befehls direkt aus der Datei ausführen:

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

Code aus dem Repository in ein Worksheet kopieren

Sie können den Code aus Dateien im Repository Stage auch in Ihre Worksheets kopieren – sowohl aus .sql- als auch aus .py-Dateien. Anschließend lässt sich der Code in Snowsight-Worksheets bearbeiten oder ausführen. Navigieren Sie einfach zur gewünschten Datei und wählen Sie die Option Copy into worksheet.

Wenn Sie Änderungen zurück ins Repository schreiben möchten, müssen Sie das in Ihrer lokalen Kopie tun – Repositorys sind in Snowflake derzeit nur lesbar. Ausnahme sind Notebooks, die auch zurückschreiben können. Zurückschreiben ins Repository ist also ausschließlich aus Notebooks möglich. Weitere Einschränkungen des Features zum Zeitpunkt dieses Artikels:

• Nur Lesezugriff – siehe oben
• Nur öffentlicher Internetzugriff. Repositorys hinter einem privaten Netzwerk sind nicht erreichbar.
• Der Repository Stage lässt sich nicht über Data Sharing teilen.
• Sie können keinen Repository Stage innerhalb eines Application Package anlegen.
• Sie können keinen Repository Stage innerhalb einer Native App auf Kundenseite anlegen.
• Der Zugriff auf Dateien im Repository Stage kann langsamer sein als auf Dateien in einem internen Snowflake Stage. Nicht für Data-Ingestion-Szenarien einsetzen.
• Submodule werden derzeit nicht unterstützt.

Das End-to-End-Beispiel hat einen möglichen Anwendungsfall der Git-Integration in Snowflake gezeigt: den Code Ihrer Procedures/UDFs in einem Remote-Repository versioniert zu halten. Das ist aber längst nicht der einzige Use Case.

Die Git-Integration ist auch dann entscheidend, wenn Sie Ihr Konto nach DevOps-Prinzipien verwalten. Sie können die Definitionen Ihrer Snowflake-Objekte (Datenbanken, Warehouses, User, Rollen usw.) als SQL-Dateien mit CREATE- oder ALTER-Anweisungen in einem Remote-Repository pflegen und im Rahmen Ihrer CI/CD-Pipelines ausführen. Dank Repository Stages haben Sie eine Kopie dieser Definitionen direkt in Snowflake verfügbar und können den Code dort unmittelbar ausführen – ganz ohne externen Runner zum Deployen dieser Objekte!

Ein weiterer Anwendungsfall sind Native Apps oder Streamlit-Apps, deren Code nativ an Remote-Repositorys angebunden sein kann. Und nicht zuletzt: Wenn Sie Snowflake für Datentransformationen nutzen – DAGs mit Tasks oder Dynamic Tables – können Sie die Pipeline-Definitionen versioniert halten und nahtlos mit Repository Stages und der Snowflake-Umgebung verzahnen.

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

Tomas ist langjähriger Snowflake Data SuperHero und ausgewiesener Snowflake-Experte. Seine Erfahrung in der Datenwelt umfasst mehr als ein Jahrzehnt – als Snowflake Data Engineer, Architect und Admin in unterschiedlichsten Projekten quer durch Branchen und Technologien. Tomas ist ein zentrales Mitglied der Community, teilt sein Wissen aktiv und inspiriert andere. Zudem ist er O'Reilly-Trainer und leitet Live-Online-Trainings.