TL;DR:
Cloud-Infrastruktur stellt einen zentralen Bestandteil moderner Datenlösungen dar. Zum verlässlichen und nachhaltigen Betrieb sind eine Reihe wiederkehrender administrativer Aufgaben erforderlich, wie z. B. Rechte- und Rollenmanagement oder Verwaltung von externen Datenanbindungen. Mit dem SnowForm-Modul für das Snowflake-Ökosystem bieten wir für genau diese Art von Administration ein frei verfügbares Terraform-Modul, das repetitive Aufgaben in der Plattform-Verwaltung leicht nachvollziehbar übernimmt.
Snowflake hat sich als Industriestandard für Datenlösungen etabliert, weit über reines Data-Warehousing und die Nutzung als Data Lake hinaus. Insbesondere Snowpark eröffnet hierbei Möglichkeiten, das python-basierte Ökosystem für Machine-Learning-Anwendungen in der Snowflake-Plattform zu nutzen und auch komplexe Data-Science-Anwendungsfälle zügig zur Produktionsreife zu bringen. Gleichzeitig verwaltet Snowflake im Hintergrund viel der erforderlichen Infrastruktur, weswegen Teams aus Anwendungsentwicklern ohne umfassende Kenntnisse/Fähigkeiten im Bereich des Cloud Engineerings auskommen können.
Diese grundlegende Flexibilität bzgl. Features in Kombination mit den reduzierten Aufgaben in der Account-Administration ermöglicht es, kleine bis mittelgroße Teams mit eigenen Accounts auszustatten, um spezifische Anwendungen individuell auszugestalten.
Wird solch ein Ansatz in einem Unternehmen verfolgt, ergeben sich eine Reihe von wiederkehrenden Herausforderungen, von denen alle so betriebenen Accounts betroffen sind.
Grundsätzliche Infrastruktur, DB-Strukturen
Zunächst ist es sinnvoll, organisationsweite Sicherheitsstandards zu etablieren, damit der unternehmensweite Snowflake-Kosmos keinen Sicherheitslücken ausgesetzt ist. Ein entsprechendes Sicherheitskonzept kann grundsätzlich Regeln zu Usern, z. B. Verwaltung über AAD/EntraID, Synchronisation mit IAM-Systemen, Multi-Faktor-Authentifizierung, Standards für technische User usw. enthalten.
Als grundlegendes Werkzeug, um Strukturen in den jeweiligen Snowflake-Accounts zu verwalten, hat sich Terraform (bzw. OpenTofu) als das dominierende Tool im Bereich Infrastructure as Code (IaC) etabliert. Seine Konfigurationsdateien bieten eine deklarative Methode zur Verwaltung und Bereitstellung von Cloud-Infrastruktur, einschließlich spezifischer Snowflake-Objekte und Integrationen mit externen Hyperscaler-Ressourcen (wie S3/GS Buckets).
Eine nachhaltige Account-Architektur beinhaltet eine Unterteilung in verschiedene Entwicklungsumgebungen, (z. B. DEV, STAGING & PROD) und ein Sternschema mit jeweils eigenen Schichten zur Datenaufbereitung/‑anreicherung (z. B. RAW, PROCESSED, EXPORT & ARTIFACTS).
Rechte- und Rollenmanagement
Rechtekonzept
Um generell Least-Privileges- und Need-to-Know-Prinzipien zu etablieren, ist ein granulares Berechtigungs- und Daten-Management für all diese Umgebungen erforderlich, wobei auch hier wiederkehrende Strukturen über alle Accounts hinweg geschaffen werden sollten (z. B. READ-, READ-&WRITE- & FULL-Rechte auf einzelne Datenbanken).
Die Vergabe solcher Berechtigungen erfolgt nachvollziehbar und einfach über ein Identity- & Access-Management (IAM)- System gekoppelt mit einem Role-Based-Access-Control (RBAC)-Mechanismus. IAM-verwalteten Nutzer:innen können so einzelne RBAC-Rollen (z. B. Consumer & Developer) zugewiesen werden. Diese Rollen werden in Snowflake dann mit den entsprechenden Privilegien versehen. In Kombination könnte sich so beispielsweise eine Rolle für eine:n Anwendungsentwickler:in in der STAGING-Umgebung ergeben, der/die dort Read- & Write-Access zu den Datenbankobjekten über alle Schichten hinweg benötigt. Für einen Business-Reporting-Use-Case hingegen wird eher lesender Zugriff auf die PROD-Daten erforderlich sein.
Um diese Berechnungen entsprechend zu verteilen, haben wir als ersten Schritt snowform_access_roles als Terraform-Modul entwickelt. Dieses Modul ermöglicht es, Rollen mit Privilegien auszustatten, auf eine hierarchische Art und Weise, iterativ für die angegebenen Schichten. Hieraus ergibt sich eine zentrale Rechteverwaltung, die schnelle Anpassungen und Ergänzungen erlaubt. Das entsprechende Modul kann in einem individuellen Snowflake-Infrastruktur-Repo einfach angebunden werden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
module "access_roles" { source = "https://github.com/inovex/snowform_access_roles/local" db = snowflake_database.db schemas = [ { name = "YOUR_SCHEMA_1" }, { name = "YOUR_SCHEMA_2" } ] depends_on = [ snowflake_database.db, snowflake_schema.your_schema_1, snowflake_schema.your_schema_2 ] providers = { snowflake.useradmin = snowflake.useradmin snowflake.sysadmin = snowflake.sysadmin snowflake.securityadmin = snowflake.securityadmin } } |
Schemata können gesammelt in der Konfiguration als Liste angegeben werden. Im Deployment iteriert Terraform zunächst über die angegebenen Konfigurationen und erstellt eine Map aller kombinierbaren Objekte:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
variable "schemas" { description = “The data layers for which the access roles are defined.” type = list(object({ name = string } ) ) default = [ { name = "YOUR_SCHEMA_1" }, { name = "YOUR_SCHEMA_2" } ] ] } locals { schema_map = { for schema in var.schemas : schema:name => schema} } |
Mittels eines for-loops (for_each) werden für diese dann einheitliche Ressourcen angelegt und an die Rollen vergeben (hier am Beispiel einer Reader-Rolle):
|
1 2 3 4 5 |
resource "snowflake_account_role" “r” { for_each = local.schema_map provider = snowflake.useradmin name = “${var.db.name_${each.value.name}_R” } |
Genauso wird anschließend über eine Sammlung erforderlicher Berechtigungen für die einzelnen Rollen iteriert und diesen zugewiesen, einschließlich den Berechtigungen für zukünftige Objekte.
Datasharing
Ein weiteres, zentrales Konzept des Snowflake-Datenmanagements zielt darauf ab, Daten einfach mit anderen Accounts zu teilen. Hierfür hat Snowflake das Konzept der Listings und Datashares entwickelt. Vereinfacht ausgedrückt stellen Shares eine Sammlung von Views für einen Konsumenten-Account bereit, inhaltlich identisch zu den dahinterstehenden Datenquellen aus dem Provider-Account, der als Data Owner fungiert.
Insbesondere im Falle einer unternehmensweiten Architektur, bestehend aus einer Reihe kleinerer Teams mit eigenen Accounts und Datenprodukten, ist es wünschenswert, diese Daten mit geringem Aufwand und nachvollziehbar in andere Accounts einzubinden. Genau diese Anbindung machen wir durch das Modul snowform_import_listing möglich.
In einem Zwei-Schritt-Prozess werden zunächst Datenbanken für die jeweiligen Shares angelegt, auf die dann automatisiert die benötigten Privilegien an die zuvor bereitgestellten Rollen vergeben werden. Hierdurch können geteilte Daten einfach in den Konsumenten-Accounts verwaltet werden. Neue Datenquellen können als Variablen lediglich mit dem Namen des Shares und der neu anzulegenden Datenbank ergänzt werden.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
module "snowflake_shared_databases" { source = "github.com/inovex/snowform_import_listing.git?ref=0.0.2" providers = { snowflake.sysadmin = snowflake.sysadmin } snowflake_shares = [ { database_name = "IMPORTED_DB_NAME" share_name = "YOUR_ORG.SOME_ACCOUNT.SHARE_NAME” }, ] account_roles = [ "ANALYST_ROLE", "DATA_ENGINEER_ROLE", ] } |
Organisation von Shares
Eine besondere Herausforderung entsteht in solch besagter Architektur mit vielen kleinen Accounts und geteilten Daten: Eine zunehmende Anzahl geteilter Datenbanken führt zu einer geringen Übersichtlichkeit für Entwickler:innen und Analyst:innen, wenn sie Daten in einer großen Auswahl von Datenbanken suchen müssen. Kommen die Daten von verschiedenen Providern und werden gleichzeitig für einen gemeinsamen Anwendungsfall verwendet, halten wir es für sinnvoll, diese Daten logisch zu gruppieren. Mit dem Modul snowform_logical_import_layer wird genau diese logische Organisation von geteilten Daten in Konsument:innen-Accounts möglich. Im Kern besteht dieses Modul aus einer Reihe von Schemata, zu denen die vorliegenden geteilten Views, nach fachlicher Zugehörigkeit aggregiert, eingeteilt werden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
module "logical_import_layer" { source = "github.com/inovex/snowform_logical_import_layer.git?ref=1.0.0" # Map source objects to logical layer targets source_to_target_mappings = { "X.YOUR_SCHEMA_1.TABLE_V3" = { target_database = "LOGICAL_PRODUCT_DATA" target_schema = "PRODUCT_DATA" target_name = "PRODUCT_MASTER" } "Y.YOUR_SCHEMA_1.TABLE_V1" = { target_database = "LOGICAL_PRODUCT_DATA" target_schema = "PRODUCT_DATA" target_name = "MATERIAL_UNITS" } |
Praktische Anwendungsfälle
Den praktischen Nutzen im Data Engineering demonstrieren wir bei dmTECH, dem Tochterunternehmen der dm-drogerie markt GmbH & Co. KG. Als Technologieunternehmen von dm entwickelt und betreibt dmTECH digitale Produkte und IT-Lösungen sowohl für dm-Kundinnen und-Kunden, als auch für die Teams in den dm-Märkten und im dialogicum. Im Umfeld des Enterprise Resource Planning (ERP) arbeiten eigenverantwortliche Produktteams an unterschiedlichsten Use Cases und Prozessen. Die Teams verantworten dabei jeweils ihre eigenen Produkte und entwickeln passgenaue Lösungen für die vielfältigen Anforderungen des Unternehmens. In vielfältigen Fachbereichen ermöglicht uns SnowForm, die grundlegende Infrastruktur zügig aufzusetzen, sodass wir anschließend unseren Fokus auf die Entwicklung verschiedener Anwendungsfälle bis zur Produktionsreife legen können. Zur Implementierung fachlicher Logik, bestehend aus einer Mischung von ETL- und ML-Prozessen, bietet sich natürlich eine Spark-Implementierung wie Snowpark an, mit den bekannten Vorzügen eines Python-basierten Ökosystems.
KI-gestütztes Artikel-Matching
So haben wir einen LLM-Ansatz zum Vergleich ähnlicher, aber nicht identischer Artikel entwickelt. Für Menschen mit Domänenwissen sind ähnliche Produkte verschiedener Hersteller, allein über die Artikelinformationen, einfach zu vergleichen. Für einen Algorithmus ist jedoch die Auswahl des bestmöglichen Paares zwischen mehreren, sehr ähnlichen Artikeln häufig mit hoher Unsicherheit verbunden. Eine Kombination aus Snowflakes Arctic-Modell, einem zusätzlich angebundenen OpenAI-Modell, sowie einem fachlich definierten Regelwerk ermöglicht es uns, passende Artikel-Matchings zu identifizieren.
Datenqualitätsplattform für Stammdaten
Ein weiterer Anwendungsfall, an dem wir aktiv arbeiten, ist eine Datenqualitäts-Plattform für Stammdaten. Mit einem Snowflake-Account binden wir sämtliche Stammdaten aus dem ERP-System an und bauen daraus Datenprodukte, die unternehmensweit geteilt werden. Parallel etablieren wir einheitliche Datenqualitätsprüfungen und Auswertungen, um die Datenqualität kontinuierlich zu sichern. Besonders interessant ist der Einsatz von Machine Learning, um komplexe oder sogar unbekannte Datenqualitätsprobleme zu entdecken und automatische Korrekturen für die Datenmassenpflege vorzubereiten.
Optimierung der Supply Chain
Ein Snowflake-Account als zentrale Anlaufstelle für analytischen Anwendungsfälle, die sich mit der Optimierung der logistischen Supply Chain bei dm befassen, ist ein weiteres Beispiel. Hier ist besonders spannend, dass viele verschiedene Teams mit unterschiedlichsten Bedürfnissen entlang der Supply Chain von dem Account mit Daten versorgt werden, als auch die Möglichkeit haben, auf dedizierten Warehouses, in dedizierten Schemata eigenständig zu arbeiten. Mithilfe von SQL oder Snowpark werden auf dem Account von Ad-Hoc-Analysen, über einfache Automatisierungen (z. B. mithilfe von Tasks oder externen Tools) bis hin zu komplexen, hochautomatisierten Prozessen eine große Bandbreite an Use Cases umgesetzt und betrieben.
Fazit und Ausblick: Der Weg zur Self-Service-Plattform
Ein wichtiger Aspekt bei all diesen Beispielen ist die Gestaltung eines Teils unseres Snowflake-Accounts als Self-Service-Plattform, um die Fachbereiche zu befähigen, schneller und direkter mit den Daten zu arbeiten. Die parallele Umsetzung all dieser Aspekte in jeweils einem domänenspezifischen Snowflake-Account war mit unseren kleinen Teams nur dadurch möglich, dass wir umfangreiche Grundlagen zu Rollenverwaltung und Snowflake Shares durch Terraform-Module automatisiert und abstrahiert haben.
Eine von uns bereits verwendete Erweiterung ermöglicht darüber hinaus Daten von außerhalb des Snowflake-Kontexts anzubinden. Über sogenannte ‚externe Stages‘, also Snowflake-Objekte, die auf Speicherbuckets in Azure oder GCP weisen, holen wir Daten aus anderen Domänen ab, um sie in unseren Use-Cases zu verwenden. Da es sich hierbei ebenfalls um eine Liste regelmäßig wiederkehrender (Snowflake-) Ressourcen handelt, liegt es auf der Hand, auch diese in Zukunft zu modularisieren.
