Eines der gefragtesten Themen ist die Migration von on-premises Data Warehouses in die Cloud. Die Migration dieser zentralen Datenspeicher eines Unternehmens birgt viele Vorteile mit sich. Die Ressourcen können in der Regel vom pay-as-you-go Prinzip der Cloud und der flexiblen Skalierbarkeit der Ressourcen profitieren. Doch zu aller Beginn einer jeden Reise steht die Frage: Wohin soll es eigentlich gehen? Um diese Frage zu beantworten, werden zumeist PoCs geplant und durchgeführt, um die versprochenen Fähigkeiten des Ziels zu validieren. In diesem Blogbeitrag werden insbesondere Eckpfeiler eines PoCs mit Snowflake thematisiert. Der Fokus soll hierbei auf generellen Strukturen und allgemeingültigen Denkansätzen liegen.
Die Planung
Jeder kennt es wahrscheinlich. Die nur kurze Evaluation eines Tools oder einer Technologie zieht sich in die Länge, da während des PoCs weitere interessante Features entdeckt wurden oder der Zeitraum von Beginn an zu ambitioniert gewählt worden ist. Die häufigste Ursache dieses Phänomens ist eine verbesserungswürdige Planungsphase zu Beginn und auch PoCs mit Snowflake können diesem Phänomen unterliegen. Aus diesem Grund bietet es sich an, sich einen erfahrenen Partner zu suchen, der einen durch den PoC leitet. Wir von saracus empfehlen zumeist eine zweiwöchige intensive Planungsphase. In dieser Planungsphase können, je nach aktuellem Stand der Cloudinfrastruktur, Grundlegende Themen wie die Netzwerkanbindung von Snowflake und das Berechtigungskonzept thematisiert, die aktuelle Infrastruktur und das derzeitige Ökosystem evaluiert, sowie User-Stories für den PoC konstruiert und vorbereitet werden.
Zu Beginn dieser zweiwöchigen Planungsphase hat es sich bewährt, drei Workshops durchzuführen. In diesen erarbeiten wir zusammen mit dem Kunden aktuelle Probleme, Herausforderungen und erste Lösungsansätze, teilen unsere Best Practices und führen einen technischen Deep-Dive mit dem Projektteam durch und erarbeiten einen sogenannten „Future State“ der Daten-Infrastruktur und vergleichen diesen mit dem Status Quo. Insbesondere der zweite Workshop, in welchem wir Best Practices und Deep-Dive-Informationen aus unseren Projekten teilen, können Einarbeitungszeiten verkürzen und die Zeit bis zum Go-Live reduzieren.
User-Stories und How-To
Nachdem die oben angeführten grundlegenden Thematiken wie die Erarbeitung einer Infrastruktur abgearbeitet sind, gilt es User-Stories zu konzipieren. Es empfiehlt sich – natürlich – möglichst realitätsnahe User-Stories zu erstellen, wie beispielsweise die Datenbelieferung eines bestimmten Fachbereichs oder eines einzelnen Use-Cases sowie dessen Reporting. Im Optimalfall können hier „echte“ Daten in ggfls. verfremdeter Form verwendet werden. Dies ist insbesondere bei der Arbeit mit semi-strukturierten Daten interessant. Konzipiert man sich einen eigenen Musterdatensatz, so läuft man eher Gefahr, dass diese Daten „zu sauber“ sind. Snowflakes Fähigkeit, semistrukturierte Daten zu verarbeiten, ist zwar schnell, doch kann auch schnell langsamer werden. Je uneinheitlicher das Schema der Daten wird, desto schlechter wird das Pruning auf einzelne Keys und somit die Gesamtperformance. Auch der Vergleich von verschiedenen Datentypen kann zu spannenden Ergebnissen führen. Die Verarbeitung von XML ist beispielsweise unter gewissen Umständen erheblich langsamer als die Verarbeitung von JSON. Dies hat zur Folge, dass sich Änderungen in der Bereitstellung der Quelldaten rentieren können.
In Summe lässt sich für die User-Stories festhalten, dass im Optimalfall die komplette Datenbelieferung einzelner Use-Cases simuliert wird. Dies beginnt mit der Beladung des Data Warehouses und endet mit der Verarbeitung durch den Endnutzer im Report oder ML-Modell. An dieser Stelle eröffnet sich zumeist ein Problem, sofern dieses in der Planungsphase übersehen wurde. Welches Tool soll bzw. kann denn überhaupt Daten effektiv nach Snowflake laden und transformieren? Welches Tool kann die Daten aus Snowflake am Ende verarbeiten, visualisieren und für eine finale Auswertung aufbereiten? Wo wird dieses Tool zur Verfügung gestellt?
Architekturen im Wandel
Insbesondere die erste Frage ist die häufigste Frage, die wir hören, wenn es um das Thema Migration zu Snowflake geht. Viele der alten und bewährten Anbieter am Markt verfolgen immer noch und nahezu ausschließlich den ETL-Ansatz zur Datenbewirtschaftung. Dies hat zur Folge, dass Daten zunächst aus einem System extrahiert werden, dann mittels der dem Tool zur Verfügung stehenden Ressourcen transformiert und schlussendlich in ein Zielsystem geladen werden. Dieser Ansatz widerspricht jedoch jeglichen Best Practices zur Datenhaltung in Snowflake. Nicht nur werden die sehr performanten Compute-Ressourcen von Snowflake nicht verwendet, sondern auch die Daten aus dem Staging-Layer von Snowflake physisch heruntergeladen, was zu einem erhöhtem Netzwerktraffic sowie den damit einhergehenden Kosten führt. Aus diesem Grund werden klassische ETL-Tools in der Regel durch moderne ELT-Tools wie Matillion oder dbt ersetzt. Diese Tools verwenden als Compute-Ressource die Warehäuser von Snowflake, um eine performante Datenverarbeitung zu gewährleisten.
Die Evaluation des BI-Tools oder des Data Science Stacks stellt sich zumeist einfacher dar: Dank des weitreichenden Partnernetzwerks von Snowflake können die meisten Tools über optimierte Konnektoren an das neue Data Warehouse angebunden werden. Sollte allerdings vereinzelt ein Anbieter nicht im Partnernetzwerk zu finden sein, so können generische Treiber zur Verbindung genutzt werden. Diese sind zwar nicht out-of-the-box optimiert, ermöglichen aber die Verbindung zu nahezu jedem Tool. Nichtsdestoweniger gibt es auch bei der Evaluation des Zusammenspiels zwischen Snowflake und BI-Tool bzw. Data Science Stacks ein paar Dinge zu beachten. Auch hier gilt, dass die meisten Tools die Daten aktiv aus Snowflake laden möchten. So arbeitet Microstrategy zum Beispiel am liebsten auf seinen eigenen Cubes und Tableau auf den eigenen Flatfiles.
Sollten diese Tools on-premises gehostet sein, so kann der Datendurchsatz spürbar im Firmennetzwerk sein, andere Applikationen blockieren und mit nicht zu vernachlässigen Kosten verbunden sein. Auch hier bietet sich die Modernisierung des Stacks an und die Migration in die Cloud – zumindest mittel bis langfristig. Durch die Migration können Latenzen geringgehalten werden und Ressourcensparend gearbeitet werden. All diese Problemstellungen können allerdings durch eine gute Planungsphase abgefangen werden. So würden genau diese Überlegungen in unseren Workshops aufgegriffen und in der Zielarchitektur festgehalten werden.
Die User-Stories, die während der zweiten Phase durchgespielt werden, stellen also eine End-2-End Datenbelieferung dar, welche Realitätsnahe Use-Cases abbildet. Genauso wie die Planungsphase dauert diese Phase des PoCs circa 2 Wochen. Neben den angesprochenen unterschiedlichen Dateiformaten und der Verarbeitung von semi-strukturierten Daten können auch weitere Variationen des Prozesses durchgespielt werden. Hier können beispielsweise alternative Beladungen über die Snowpipe oder External Tables vertestet werden und so Snowflake-spezifische Features im Detail evaluiert oder aber Snowpark als Snowflake-native alternative zum eigenen Spark-Cluster erprobt werden.
Zusammenfassung
Im Allgemeinen ist das Verproben von Snowflake kein Hexenwerk. Durch das weitreichende Partnernetzwerk können nahezu alle ETL‑, BI- und Data-Science-Tools an das moderner Data Warehouse angeschlossen werden. Die eigentliche Fragestellung, mit der man diese Technologie evaluieren sollte, ist „Wie gut funktioniert das?“, sodass man eigentlich eher von einem „Proof of Value“ sprechen müsste. Da on-premises Data Warehouses häufig die Möglichkeiten fehlen mit der Performance von Snowflake im Bereich Big Data zu konkurrieren, empfehlen wir außerdem die Evaluation eines weiteren Data Warehouses wie Googles BigQuery oder Amazons Redshift, um nicht nur einen Vergleich zwischen on-premises und cloud-native, sondern auch zwischen cloud-nativen Lösungen zu haben. Ähnlich wie Snowflake überzeugen beides als SAAS-Plattformen, bringen jedoch ihre jeweils eigenen Stärken und Schwächen mit. Durch eine gute Planungsphase, die im Optimalfall auf bereits gelernten Erfahrungen und Best Practices fundiert ist, kann die Ausführungsphase schnell und effizient bearbeitet werden.
An dieser Stelle ein wenig Eigenwerbung zu unseren kommenden „Snowflake-Monaten“. Wir verweisen gerne auf unser Webinar zu dem Thema „How to PoC Snowflake“, in welchem das Thema das Artikels noch einmal aufgegriffen werden. Weiterhin vergleichen wir in unserem Webinar „Snowflake vs. Redshift“ die beiden Kontrahenten miteinander. Außerdem bieten wir kostenlose Snowflake Basic und Advanced Webinare an, in welchen wir Snowflake und seine Eigenarten vorstellen sowie Best Practices und Lösungen präsentieren. Die beiden letztgenannten Webinare sind auch als ausführliches Seminar buchbar, welche erheblich detaillierter sind. Zu guter Letzt laden wir Sie herzlichst zu unserem Snowflake Day am 19.10. ein!
