Snowflake Best Practices: Infrastruktur, Tools und Performance für erfolgreiche Cloud-DWH-Projekte

In der heutigen datengetriebenen Welt ist eine effiziente und skalierbare Datenplattform der Schlüssel für erfolgreiche Analysen und datenbasierte Entscheidungen. Traditionell erfolgt dies in einem zentralen on-premise Data Warehouse (DWH). Der Trend geht jedoch hin zu Cloud-DWH-Lösungen, die eine wartungsarme Speicherung als auch eine performante Verarbeitung und Auswertung der Daten ermöglichen.

Snowflake hat sich als eine der führenden Cloud-Datenplattformen etabliert, die es Unternehmen ermöglicht, große Datenmengen flexibel zu verarbeiten, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen. Doch um das volle Potenzial von Snowflake auszuschöpfen, ist es entscheidend, die Umgebung gut zu strukturieren, damit sie zukunftsfähig und sicher ist.

In diesem Artikel zeigen wir, wie man eine gute Snowflake-Architektur aufbaut, von der Einrichtung verschiedener Umgebungen über den Einsatz wichtiger Tools bis hin zum Ressource Monitoring. Diese Best Practices helfen dabei, Datenprozesse effizienter zu gestalten, Kosten zu kontrollieren und die Sicherheit zu gewährleisten. Unabhängig davon, ob bereits Erfahrung mit Snowflake besteht oder die Plattform neu erkundet wird, bietet dieser Leitfaden wertvolle Einblicke für alle.

In unserer Snowflake-Blogreihe haben wir außerdem bereits verschiedene Themen wie Sicherheit, Zugriffsverwaltung, Machine Learning, Snowalert Monitoring behandelt.

Standardisierte Umgebungen: Produktion, Test und Entwicklung

Wie ein klassisches DWH benötigt auch ein Cloud-DWH mehr als nur eine (Produktiv-)Umgebung. Als Standardumgebungen in einem Cloud-DWH empfehlen wir mindestens ein dreistufiges Konzept bestehend aus Entwicklungs-, Test- und Produktivumgebung.

• Produktionsumgebung (PROD): Verarbeiten und monitoren der produktiven Daten im gewählten Rhythmus

• Testumgebung (QA): Testen von ETL-Pipelines, Datenmodellen und neuen Features ohne Risiko für Produktivdaten

• Entwicklungsumgebung (DEV): Entwickeln und experimentieren mit neuen Pipelines, Abfragen, Anforderungen und Optimierungen

Bei der Realisierung der Umgebungen können im Wesentlichen zwei Wege beschritten werden: Jede Umgebung wird jeweils durch

1. einen Snowflake Account repräsentiert

2. eine Datenbank im selben Snowflake Account repräsentiert

Beim ersten Ansatz ist eine starke Trennung zwischen den Umgebungen sichergestellt und jeder Informationsaustausch zwischen den Umgebungen muss aktiv eingerichtet werden. Dieser Ansatz führt zu entsprechendem Mehraufwand (konzeptionell und in der Umsetzung) und sollte daher gute Gründe haben. Das kann beispielsweise die Regulatorik innerhalb einer Bank sein, die eine starke Trennung der Systeme erfordert.

Der zweite Ansatz bietet einen wichtigen Vorteil in Snowflake: Zero Copy Cloning. Mit der Cloning-Funktionalität können die verschiedenen Umgebungen in Snowflake einfach realisiert werden. Das Zero Copy Cloning ermöglicht das Kopieren ganzer Datenbanken, Schemata oder Tabellen in wenigen Sekunden und verbraucht nur bei Änderungen Speicher. Eine Testumgebung sollte dabei möglichst den Zustand der Produktivumgebung beinhalten, während eine Entwicklungsumgebung je nach Entwicklungsaufgabe auch nur aus geklonten Tabellen bestehen kann.

Zero Copy Cloning in Snowflake für ein standardisiertes Umgebungskonzept 

Sehr wichtig bei diesem Ansatz ist jedoch, dass jede Umgebung eigene Rollen/-strukturen erhält, die nur die benötigten Berechtigungen für die jeweiligen Umgebungen umfassen. Zusätzlich könnte es sinnvoll sein, den Entwickler:innen über eine lesende PROD/QA Rolle ebenfalls lesenden Zugriff auf die Produktions- und Testumgebung zu geben, um ihnen das selbständige Klonen benötigter Ressourcen zu ermöglichen. Wenn auch sensible Daten gespeichert werden, so sollten diese jedoch durch Methoden wie Data Masking vor dem Zugriff durch unberechtigte Nutzergruppen / Entwickler:innen geschützt werden.

Eigene Rollenstrukturen für jede Umgebung 

Insgesamt sollen durch die Isolation der Umgebungen und Rollenkonzepte Datenverluste und Produktionsprobleme vermieden werden.

Architektur und Organisation: Größe, Ressource Monitoring Rollenstrukturen und Zugriffskontrolle

Bezüglich der Größe eines Snowflake-Warehouses kann zwischen mehreren Varianten (XS bis 6X-Large) gewählt werden. Ein XS-Warehouse entspricht der Standardgröße und ist für viele Unternehmen zum Einstieg ausreichend. Es wird empfohlen, die Wahl der richtigen Warehouse-Größe experimentell vorzunehmen. Dabei soll mit der kleinsten Warehouse-Größe begonnen werden und vergrößert dann nach Bedarf. Große Warehouses sind nicht unbedingt pauschal teurer, da sie auch eine schnellere Bearbeitung der Aufgaben ermöglichen. In der Folge kann das Warehouse auch früher abgeschaltet werden. Weitere Best Practices finden sich hier zum Nachlesen.

Bei allen Warehouses sollte die “Auto-Suspend” (Warehouse abschalten) und “Auto-Resume” (Warehouse starten) Funktion aktiviert sein. In der Regel startet ein Warehouse in weniger als einer Sekunde aus dem “Suspended” Zustand, sodass die Wartezeit bei einer Abfrage mit Warehouse-Kaltstart in den meisten Fällen akzeptabel sein sollte. Die Leerlaufzeit, nach der ein Warehouse automatisch beendet wird, ist standardmäßig auf 10 min eingestellt. Die 10 min stellen jedoch einen Kompromiss aus verschiedenen Use-Cases dar, der nicht unbedingt optimal ist. In vielen Fällen ist es aus Kostengründen ausreichend, wenn das Warehouse bereits nach 60 sec Inaktivität ausgeschaltet wird. Das wichtigste Argument dagegen, ist der Warehouse-Cache, der die Daten von abgefragten Tabellen zwischenspeichert, wenn die Speichergröße dies zulässt. Abfragen, die die zwischengespeicherten Tabellen verwenden und nicht bereits durch den Result-Cache beantwortet wurden, können dadurch wesentlich schneller bearbeitet werden. In der Regel rechtfertigt die schnellere Antwortzeit nicht die zusätzlichen Kosten eines Warehouses mit viel “unnötiger” Leerlaufzeit.

Eine weitere Empfehlung ist die Einrichtung mindestens eines Warehouses für jeden der folgenden Aufgabentypen innerhalb eines DWHs: Dataloading (ELT), Transformations (ELT), Reporting, Machine Learning/AI und Development (Entwicklungsaufgaben). Diese Trennung ist sinnvoll, da die Anforderungen dieser Aufgabentypen oft unterschiedlich sind und eine gegenseitige Beeinflussung vermieden werden sollte. Es kann und sollte in diesen Gruppen weiter untergliedert werden, falls unterschiedliche Anforderungen an Performance oder Parallelität zu berücksichtigen sind.

Generell hat man die Möglichkeit die eigene Snowflake Instanz in Azure, Google Cloud und AWS betreiben zu lassen. Ist eine der Plattformen bereits im Einsatz (z.B. Azure im Rahmen von Office 365), empfiehlt es sich die auch als Basis für ein Snowflake-DWH zu wählen.

Neben den bereits erwähnten Rollenstrukturen sollte in Snowflake auch ein Sicherheitskonzept implementiert werden. Über die Zugriffsverwaltung und Sicherheitsmechanismen (z. B. MFA) haben wir in anderen Blogartikeln bereits ausführlich berichtet und Best Practices empfohlen.

Die mitgebrachte Elastizität (via Auto-Suspend) und der Pay-per-Use-Ansatz von Snowflake können für viele Anwender:innen aber auch schnell teuer werden. Es werden zwar Kosten eingespart, da keine Server benötigt werden und sich Mitarbeiter:innen weniger mit dem Betrieb beschäftigen müssen. Eine falsche Konfiguration kann jedoch zu ungenutzten Ressourcen und überdimensionierter Rechenleistung führen. Dieser Kostenfalle kann durch ein Ressource Monitoring entgegengewirkt werden. Der Verbrauch von Credits kann auf Account- oder Warehouse-Ebene überwacht werden und bei Erreichen eines bestimmten Limits wird schließlich eine Warnung oder sogar ein Abbruch der laufenden Abfragen ausgelöst. Es ist sinnvoll, für jedes Warehouse einen eigenen Ressourcen Monitor anzulegen, um etwaige Kostenausreißer frühzeitig zu bemerken und deren Ursache zu analysieren. Dabei sollte jedes Warehouse einen sich täglich zurücksetzenden Ressourcen Monitor erhalten, um über ungewöhnliche Ausreißer noch innerhalb eines Tages informiert zu werden. Es ist ausreichen, wenn der Ressourcen Monitor zunächst nur vor einer eventuellen Überschreitung warnt und nicht auch Abfragen abbricht bzw. blockiert. Das kann bei kritischen Prozessen wie bei ETL-Jobs oder dem Berichtswesen sehr problematisch sein. Bei einem Warehouse für weniger kritische Prozesse (z.B. Entwicklungsaufgaben) sollte auch ein Abbruchlimit definiert werden, um unbeabsichtigten Kostenspitzen zu vermeiden. Häufig erfolgt die Budgetplanung für ein DWH auf monatlicher Basis und nach Umgebungen getrennt. In diesem Fall ist ein Ressourcen Monitor je Umgebung und nach Umgebung separierte Warehouses für den gesamten Account auf Monatsbasis ebenfalls sinnvoll. Ein Ressourcen Monitor für PROD würde dann eine Budgetgrenze für alle Warehouses definieren, die für Produktionssysteme verwendet werden. Entsprechendes gilt für QA und DEV.

Darüber hinaus bietet Snowflake mit der Time Travel Option die Möglichkeit, ältere Zustände einer Datenbank, einer Tabelle oder eines Schemas wiederherzustellen. Dies ist z.B. hilfreich, wenn man den Zustand vor der Ausführung einer Query sehen/wiederherstellen möchte. Das kann gravierende Fehler umfassen, wie die Verarbeitung und Historisierung fehlerhafter Quelldaten, bei denen der Datenzustand von vor der Nachtverarbeitung wiederhergestellt werden muss. Es kann aber auch bei einfachen Fehlern helfen, z.B. wenn während der Entwicklung zu viele Datensätze gelöscht wurden und der Fehler schnell korrigiert werden soll.

Wie in einem on-premise DWH empfiehlt sich auch in einem Cloud DWH eine einheitliche Namenskonvention für Datenbanken, Schemata, Tabellen und Rollen, um den Überblick zu behalten. Hier haben wir die folgenden Empfehlungen (Quelle):

• Datenbanken: PROD_DB | QA_DB | DEV_DB

• Schemata:

  • RAW - Rohdaten aus den Quellsystemen (z.B. das Delta aus bestimmten Quelltabellen)

  • STAGING - Bereinigung, Validierung und erste Transformation der Rohdaten

  • CORE - zentrales DWH als Dimensionsdatenmodell (Fakten und Dimensionen) oder als Data Vault Datenmodell

  • ANALYTICS - Speziell aufbereitete Daten für Berichte, Dashboards und allgemeine Datenanalyse

  • ML_MODELS - Speziell aufbereitete Daten für Machine Learning / KI

• Tabellen:

  • Raw | Staging: Namen von Tabellen (und Spalten) sollten sich an den Quellsystemen orientieren. Um Konflikte bei verschiedenen Quellen aber gleichen Tabellennamen in den Quellsystemen zu vermeiden, sollte das Quellsystem als Präfix ergänzt werden: RAW.SALES_Customer, RAW.SAP_Customer, …

• Rollen (Rollenkonzept):

  • Sicherheitsrollen (Sie werden nicht direkt an User vergeben, sondern nur anderen Rollen zugewiesen): PROD_READ | PROD_WRITE | PROD_EXEC | PROD_FULLACCESS (Ownership) | QA_READ | …

  • Technische Rollen:

    • PROD_LOADING | PROD_TRANSFORMING | PROD_REPORTING 

    • QA_LOADING | QA_TRANSFORMING | QA_REPORTING 

    • DEV_LOADING | DEV_TRANSFORMING | DEV_REPORTING 

  • Umgebungsrollen: PROD_SYSADMIN | QA_SYSADMIN | DEV_SYSADMIN | PROD_SECURITYADMIN | QA_SECURITYADMIN | DEV_SECURITYADMIN

  • Funktionale Rollen: PROD_DATAENGINEER, PROD_DATAANALYST, PROD_DATASCIENTIST, QA_DATAENGINEER, …

Werkzeuge und Plugins für die Entwicklung und Administration

Bei der Entwicklung und Verwaltung eines produktiven Snowflake-DWH ist es nicht ratsam, innerhalb von privaten Worksheets zu arbeiten. Stattdessen wird die Integration von Git und VS Code empfohlen. VS Code bietet als Extension einen Konnektor zu Snowflake, sodass Queries aus VS Code heraus ausgeführt werden können. In Kombination mit der Git Extension erhält man zusätzlich ein Versionskontrollsystem für Worksheets, um SQL-Skripte und Pipelines zu verfolgen und Änderungen koordiniert zu verwalten.

Git und VS Code als Werkzeuge für die Entwicklung

Drittanbieter-Tools und der Snowflake Marketplace für mehr FunktionalitÄT

Snowflake bietet mit einer Vielzahl von 3rd Party Partnern und Technologien eine Reihe von zusätzlichen Funktionalitäten, die für ein initiales Cloud-DWH zwar nicht notwendig jedoch in der ersten Ausbaustufe von Vorteil sind. Die unserer Meinung nützlichsten Tools sind:

• dbt: Das Open-Source-Tool vereinfacht den ELT-Prozess, indem es SQL-Skripte in einer datenbankfreundlichen Umgebung verwaltet und transformiert. In Kombination mit Snowflake ermöglicht dbt, SQL-basierte Transformationen direkt in der Cloud-Datenbank durchzuführen, Versionierung und Tests für Datenmodelle einzusetzen sowie den gesamten ELT-Prozess effizienter und skalierbarer zu gestalten.

• Apache Airflow: Die Open-Source-Plattform dient der Automatisierung und Überwachung von Workflows, die den ETL-Prozess steuern und orchestrieren. In Verbindung mit Snowflake kann Airflow eingesetzt werden, um Datenpipelines zu planen, zu überwachen und komplexe Datenladeprozesse in Snowflake zu automatisieren, wodurch die Datenverarbeitung effizienter und flexibler wird.

• Microsoft Power BI: Die BI-Plattform ermöglicht es, Daten zu visualisieren, Berichte zu erstellen und Analysen durchzuführen. In Verbindung mit Snowflake kann Power BI direkt auf die in Snowflake gespeicherten Daten zugreifen, um Echtzeit-Dashboards und interaktive Berichte zu erstellen, die auf den aktuellen Daten in der Cloud-Datenbank basieren.

Beispiele für Snowflake 3rd Party Partner und Technologien

Zusätzlich gibt es noch einen Snowflake Marketplace, wo man sich kostenlos externer Datenquellen wie z.B. Wetter und BIP bedienen kann, um noch mehr aus den eigenen Daten herauszuholen. Auch hier lohnt sich ein Blick, vor allem wenn man über das reine Monitoring der eigenen Daten und KPIs hinausgeht und auch Benchmarking und Prognosen betreiben möchte.

Fazit und Ausblick

Bei unserem Kunden Babyone haben wir bereits erfolgreich ein Snowflake-Projekt mit den oben beschriebenen Best Practices durchgeführt. Einen guten Überblick bietet hier der passende Vortrag auf dem Navigate Kongress.

Wenn Sie auch den Weg in die Cloud wagen möchten oder sich generell mit einem Data Warehouse beschäftigen, sprechen Sie uns gerne an. Wir bieten auch Schulung in den Themenfeldern Grundlagen von Data Warehousing und Cloud Data Warehouse an.

Die Autor:innen

Vitali Prenger ist bei der viadee IT-Unternehmensberatung als Systementwickler in der Anwendungsentwicklung tätig. Auch im Bereich des maschinellen Lernens hat er einige Erfahrung sammeln können und lernt selbst immer mehr dazu. Nebenbei beschäftigt er sich gerne mit Themen wie Internetsicherheit sowie Wirtschafts- und Finanzpolitik. 

Sina Nordlohne ist Beraterin bei der viadee IT-Unternehmensberatung. Hier beschäftigt sie sich mit den Themen Business Intelligence, Data Warehouse und SAS-Entwicklung, besonders im Bereich Banken und Finanzdienstleister.

Haben wir Ihr Interesse geweckt? Melden Sie sich gerne bei uns.