Umzug von Snowflake
Herüberziehen — mit dem Beweis, dass die Zahlen stimmen
Ein Warehouse wechselt man nicht an einem Wochenende, sondern wenn man sicher ist. lavalake bringt dafür einen Werkzeugkasten mit: Er liest Ihren Snowflake-Bestand, übersetzt Definitionen, übernimmt Ihre dbt-Modelle — und lässt beide Systeme so lange parallel rechnen, bis Zeile für Zeile belegt ist, dass dasselbe herauskommt.
- Bestand
- Tabellen und Sichten, direkt aus Snowflake gelesen
- Übersetzung
- Tabellen- und Sichtdefinitionen als Vorschlag
- dbt
- manifest.json oder rohes SQL
- Nachweis
- Parallellauf mit Zeilenzahl und Prüfsumme
- Verbindung
- Snowflake als registrierte Datenquelle, lesend
Erst sehen, was überhaupt da ist
Der erste Schritt ist eine Bestandsaufnahme: Der Werkzeugkasten meldet sich an Ihrer Snowflake-Anlage an und listet Tabellen und Sichten auf. Damit steht am Anfang keine Schätzung, sondern eine Liste — die Grundlage, um Aufwand und Reihenfolge zu planen.
Übersetzen statt abtippen
Aus einer Snowflake-Tabelle wird ein fertiger Vorschlag für die Tabelle im See, aus einer Sicht ein SQL-Vorschlag. Ihre dbt-Modelle kommen ebenfalls mit: Der Werkzeugkasten liest die `manifest.json` oder die rohen SQL-Dateien und baut daraus einen Übernahmeplan.
| Schritt | Was dabei herauskommt |
|---|---|
| Bestand auflisten | Tabellen und Sichten der Quelle, auf einen Blick. |
| Tabelle übersetzen | Ein Vorschlag für die Zieltabelle, mit übertragenen Typen. |
| Sicht übersetzen | Ein SQL-Vorschlag; Snowflake-eigene Syntax wird zur Prüfung ausgewiesen. |
| dbt übernehmen | Ein Plan über alle Modelle, mit Reihenfolge und Abhängigkeiten. |
| Parallellauf | Zeilenzahl und Prüfsumme beider Systeme, nebeneinander. |
Parallel rechnen, bis es belegt ist
Das ist der Teil, der einen Umzug entscheidbar macht. Beide Systeme rechnen dieselbe Abfrage, der Werkzeugkasten stellt Zeilenzahl und Prüfsumme gegenüber. Sie sehen schwarz auf weiß, wo Ihre Plattform dasselbe Ergebnis liefert — und wo noch etwas zu tun ist. Umgeschaltet wird, wenn diese Liste stimmt, nicht wenn ein Termin es verlangt.
Ein Umzug scheitert selten an der Technik. Er scheitert daran, dass niemand beweisen kann, dass die neue Zahl die richtige ist.
Sie entscheiden, was übernommen wird
Jeder Schritt liefert einen Vorschlag, den Sie ansehen. Angelegt wird über dieselben bestätigungspflichtigen Wege wie alles andere in der Plattform, und jede Aktion steht im revisionssicheren Protokoll. So bleibt zu jedem Zeitpunkt nachvollziehbar, was übernommen wurde — und von wem.
Was Sie danach haben
- Offene Formate auf eigenem Speicher: Apache Iceberg statt eines proprietären Tabellenformats.
- Kosten, die von Hardware abhängen statt von Abfragen.
- Dieselben Modelle, dieselben Kennzahlen — nur auf Ihrer Infrastruktur.
- Einen belegten Abgleich, den Sie in der Revision vorlegen können.
Wo das in der Plattform sitzt
Dasselbe Bild wie auf der Startseite: eine Plattform, ein Rechtemodell, ein Speicher.
- Zugang: Konsole (SPA) · SQL-Worksheet · Dashboards · KI-Assistent · MCP-Server – alles hinter einem Reverse-Proxy
- Identität & Governance: Keycloak OIDC · Token Exchange nach RFC 8693 · Row-Access- und Masking-Policies · WORM-Audit · Lineage
- Compute: Trino unter Ihrer Identität · Leistungsklassen S, M und L im Compose-Stapel
- Katalog & Tabellenformat: Apache Iceberg mit Nessie: ACID · Time Travel · Branching · Schema Evolution · offen für Spark, Flink, Trino
- Storage & Index: S3-kompatibel (MinIO, Ceph, NetApp StorageGRID, Dell ECS) · PostgreSQL mit pgvector als Vektorindex
Sehen, statt nachzulesen
In einer halben Stunde zeigen wir die Plattform an Ihren Fragen – Ingestion, Rechte, Suche, Agent. Ohne Folien.
Live-Demo buchen