Snowflake & Snowpark Python

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 1 von 17. Der größte Bottleneck bei Big Data ist selten Storage. Das eigentliche Problem entsteht, wenn du riesige Datasets über das Netzwerk verschieben musst, nur um deinen Compute Layer zu erreichen. Die Snowflake-Architektur umgeht dieses Problem vollständig. Leute denken oft, Snowflake sei nur eine on-premise relationale Datenbank, die per Lift and Shift in die Cloud geschoben wurde, oder ein traditioneller Hadoop-Cluster, den du babysitten musst. Es ist keins von beidem. Snowflake ist ein komplett self-managed Service, der nativ für die Cloud gebaut wurde. Du installierst keine Software. Du konfigurierst keine Hardware. Die komplette Maintenance, das Management und das Tuning werden für dich im Hintergrund erledigt. Um zu verstehen, wie das funktioniert, schau dir die hybride Architektur an. Snowflake kombiniert ein Shared-Disk-Setup mit einem Shared-Nothing-Setup. In einem traditionellen Shared-Disk-Design greifen alle Compute Nodes auf ein zentrales Data Repository zu. In einem Shared-Nothing-Design hat jeder Compute Node seinen eigenen lokalen Chunk an Daten, den er verarbeitet. Snowflake nimmt sich das Beste aus beiden Welten. Es behält ein einziges zentrales Storage Repository, auf das alle Compute Nodes zugreifen können, aber es nutzt unabhängige Massively Parallel Processing Cluster, um die eigentlichen Queries gegen diese Daten auszuführen. Dieses hybride Modell unterteilt sich in drei verschiedene Layer. Der erste ist der Database Storage Layer. Wenn du Daten in Snowflake lädst, wirft es nicht einfach Raw-Files in einen Cloud Bucket. Es reorganisiert diese Daten in ein internes, optimiertes, komprimiertes Columnar-Format. Snowflake managt alle Aspekte davon, wie diese Daten gespeichert werden. Du kannst nicht direkt auf den Raw Storage zugreifen, du interagierst damit nur über SQL-Queries. Der zweite Layer ist das Query Processing. Hier passiert die eigentliche Arbeit mit dem, was Snowflake Virtual Warehouses nennt. Ein Virtual Warehouse ist einfach ein unabhängiger Compute Cluster. Weil Compute strikt vom zentralen Storage Layer getrennt ist, können mehrere Virtual Warehouses exakt dieselben Daten gleichzeitig abfragen. Sie konkurrieren nicht um Ressourcen und sie blockieren sich nicht gegenseitig. Hier ist die wichtigste Erkenntnis: Du kannst deine Compute-Power sofort skalieren, ohne ein einziges Byte an Daten zu verschieben. Stell dir einen Finanz-Report zum Monatsende vor, der eine massive Datenaggregation erfordert. Normalerweise müsstest du Tabellen auf einen größeren Server migrieren, um den komplexen Workload zu bewältigen. In Snowflake fährst du einfach ein größeres Virtual Warehouse hoch, lässt den schweren Report in wenigen Minuten durchlaufen und schaltest das Warehouse wieder ab, wenn du fertig bist. Die zugrundeliegenden Tabellen bewegen sich nie. Der dritte Layer, der alles zusammenhält, sind die Cloud Services. Das ist das Gehirn der Plattform. Es ist eine Sammlung von Services, die alles im gesamten System koordinieren. Sie kümmern sich um die User Authentication, managen die Infrastruktur, parsen eingehende Queries und optimieren Execution Paths. Sie managen auch Metadaten und tracken genau, wo bestimmte Daten im Storage Layer liegen, damit Queries effizient laufen können, ohne alles zu scannen. Das wichtigste Takeaway ist, dass Performance-Skalierung in Snowflake nur ein Schalter am Compute Cluster ist, während die riesigen Datentabellen komplett stationär bleiben. Wenn dir die Serie gefällt und du die Show unterstützen willst, findest du uns, indem du auf Patreon nach DevStoriesEU suchst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 2 von 17. Was wäre, wenn du reines Python schreiben könntest, das aber als hochoptimiertes, verteiltes SQL ausgeführt wird? Genau diesen Paradigmenwechsel behandeln wir heute mit einer Einführung in Snowpark. Traditionell bedeutete die Arbeit mit großen Datensätzen in Python, Daten aus deiner Datenbank zu ziehen. Du schreibst eine Query, ziehst die Daten über das Netzwerk in den lokalen Memory oder einen externen Processing Cluster, lässt deine Transformationen laufen und pushst die Ergebnisse dann zurück. Dieser Ansatz erzeugt Netzwerk-Bottlenecks, erhöht die Infrastrukturkosten und bringt Sicherheitsrisiken mit sich, weil Daten aus einer kontrollierten Umgebung herausbewegt werden. Snowpark kehrt dieses Modell um. Anstatt die Daten zum Compute zu bewegen, pusht Snowpark das Compute runter zu den Daten. Ein häufiges Missverständnis ist, dass Snowpark eine externe Processing Engine ist. Viele glauben, sie müssten einen separaten Compute Cluster hochfahren und verwalten, nur um Python-Code auszuführen. Ist es aber nicht. Snowpark-Berechnungen laufen direkt in Snowflake. Du nutzt genau dieselben virtuellen Warehouses, die auch deine Standard-SQL-Queries ausführen. Du musst keine neue Infrastruktur provisionieren oder warten. Wenn du Code mit der Snowpark Python API schreibst, interagierst du mit einem DataFrame-Objekt. Das fühlt sich sehr ähnlich an wie die Arbeit mit vertrauten Python-Data-Tools. Du chainst Operationen zusammen und definierst, wie deine Daten selektiert, gefiltert, gruppiert oder aggregiert werden sollen. Die Snowpark Library führt diese Operationen jedoch nicht lokal aus. Stattdessen übersetzt sie deine Python-DataFrame-Operationen nativ in komplexe SQL-Konstrukte. Snowflake verarbeitet diese SQL Statements dann mit seiner Standard Execution Engine. Hier ist der entscheidende Punkt. Snowpark verwendet Lazy Evaluation. Wenn du deinen DataFrame definierst und verschiedene Transformationen anwendest, werden tatsächlich keine Daten bewegt oder verändert. Die Snowpark API erstellt lediglich einen logischen Plan. Sie zeichnet deine Absicht Schritt für Schritt auf. Die eigentliche Execution wird erst getriggert, wenn du eine bestimmte Action aufrufst, zum Beispiel wenn du das System anweist, die finalen Ergebnisse zurückzugeben oder sie in eine neue Tabelle zu schreiben. Dieses Lazy-Evaluation-Modell in Kombination mit der nativen SQL-Übersetzung reduziert den Datentransfer drastisch. Stell dir ein Szenario vor, in dem du als Data Engineer die Aufgabe hast, eine Milliarde Zeilen Transaktionsdaten zu filtern, um ein paar spezifische Anomalien zu isolieren. Du schreibst deine Filterlogik in einem lokalen Python-Skript. Weil die Execution verzögert wird, bis die Action aufgerufen wird, hat die API Zeit, die gesamte Chain von Operationen zu optimieren und in eine einzige, hocheffiziente SQL-Query zu übersetzen. Die eigentliche Filterung findet vollständig in Snowflake statt. Die Datenbank übernimmt das ganze Heavy Lifting. Die einzigen Daten, die über das Netzwerk zu deiner lokalen Maschine wandern, sind das finale, kleine Subset an Anomalien. Du hast gerade eine Milliarde Zeilen mit Python-Syntax verarbeitet, ohne einen einzigen Raw Record in deinen lokalen Memory zu ziehen. Der wahre Vorteil hier ist, dass die Developer Experience nativ in Python bleibt, während du die Database Engine für das nutzt, was sie am besten kann. Du schreibst Python, aber Snowflake führt SQL aus. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 3 von 17. Connection-Boilerplates sind oft ein Sicherheits-Albtraum, voll mit hardcodierten Passwörtern und verstreuten Environment Variables. Du willst deinem Team ein lokales Command Line Tool geben, aber du darfst Credentials auf keinen Fall in den Code packen. Die Lösung: Eine Session sauber über die nativen Configuration Features von Snowpark aufbauen. Jedes Snowpark-Script beginnt mit der Erstellung eines Session-Objekts. Das ist deine aktive Verbindung zur Snowflake-Umgebung. Es kapselt deine Authentication, dein Target Warehouse und deinen Context. Um sie zu bauen, nutzt du das Builder-Objekt der Session-Klasse. Der direkteste Weg ist, ein Dictionary zu übergeben. Du erstellst ein Python-Dictionary mit Keys für Account, User, Password, Role, Database und Warehouse. Dieses Dictionary übergibst du an die configs-Methode des Session-Builders und rufst danach die create-Methode auf. Die Logik fließt direkt von deinem Dictionary ins Snowflake-Backend. Aber Credentials in einem Python-Script zu hardcoden, ist ein massives Sicherheitsrisiko. Das macht diesen Ansatz für geteilte Tools unbrauchbar. Um Credentials aus deinem Code zu verbannen, setzt Snowpark auf eine Standard-Config-Datei namens connections.toml. Diese Datei legst du entweder in deiner Project Root ab oder in einem versteckten Snowflake-Verzeichnis in deinem User Home Folder. Die TOML-Datei enthält Connection Blocks. Du kannst einen Default Block, einen Dev Block und einen Prod Block definieren, jeder mit seinen eigenen Connection-Parametern. Hier ist der entscheidende Punkt. Wenn du eine TOML-Datei nutzt, wird dein Python-Code extrem vereinfacht. Du übergibst überhaupt kein Dictionary mehr. Du rufst einfach die get oder create Methode auf dem Session-Builder auf. Snowpark scannt automatisch die Standardverzeichnisse, findet deine TOML-Datei, liest den Default Block und instanziiert die Session. Wenn du eine bestimmte Environment willst, übergibst du den Connection-Namen an die configs-Methode, bevor du die Session erstellst. Dein Code bleibt clean und die Credentials bleiben sicher auf der lokalen Maschine. Wir können unser Command Line Tool sogar noch weiter absichern. Selbst mit einer TOML-Datei willst du vielleicht nicht, dass Developer permanente Passwörter lokal speichern. Du kannst Passwörter komplett eliminieren, indem du browserbasiertes Single Sign-On nutzt. In deiner TOML-Datei lässt du den Password Key einfach weg. Stattdessen fügst du einen Key namens authenticator hinzu und setzt seinen Value auf externalbrowser. Wenn dein Script den Schritt zur Session-Erstellung erreicht, pausiert die Execution. Snowpark fängt den Prozess ab und öffnet automatisch den Default Web Browser des Users. Es leitet den Developer zum Identity Provider deiner Organisation weiter. Der Developer loggt sich ganz normal ein und erfüllt dabei alle Multi-Factor Authentication Anforderungen. Sobald der Identity Provider den Login bestätigt, sendet er ein temporäres Authentication Token zurück an einen lokalen Port, auf dem Snowpark lauscht. Das Script empfängt das Token, baut die sichere Snowflake Session auf und die Python Execution läuft weiter. Dein CLI Tool hat jetzt vollständig authentifizierten Zugriff auf Snowflake, ohne dass jemals ein Passwort deine Config-Dateien oder deinen Source Code berührt. Das sicherste Credential ist das, welches deinen Code niemals berührt. Und wenn du die Authentication an den Browser delegierst, bleiben deine lokalen Scripts sicher und können sich voll und ganz auf die Daten konzentrieren. Ich möchte mir kurz einen Moment nehmen, um dir fürs Zuhören zu danken – das hilft uns sehr. Hab einen tollen Tag!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 4 von 17. Du willst eine schnelle Data Transformation testen, aber deine lokale Python-Umgebung ist mal wieder kaputt. Deine Connection Strings sind veraltet, und du hast gerade zwanzig Minuten mit der Authentifizierung verschwendet. Was wäre, wenn du Code gegen eine voll konfigurierte Environment direkt in deinem Browser schreiben könntest – mit Zero Setup? Genau dieses Problem lösen die Python Worksheets in Snowsight. Python Worksheets sind ein nativer Code Editor, der direkt in das Snowflake Web Interface integriert ist. Sie ersparen dir den Stress der lokalen Environment-Konfiguration. Stell dir vor, du baust einen Prototyp für ein schnelles Data Cleaning Script auf Live-Daten. Anstatt eine IDE zu öffnen und Credentials zu verwalten, öffnest du einfach einen Browser-Tab und fängst sofort an, Code zu schreiben. Die Execution Logic basiert auf einem festgelegten Entry Point. Du schreibst kein loses, prozedurales Skript. Snowflake braucht eine bestimmte Funktion, um deinen Code zu triggern. Standardmäßig ist das eine Handler-Funktion namens main. Diese Funktion nimmt ein einziges Argument, nämlich das aktive Session-Objekt. Da du bereits im Snowflake Interface eingeloggt bist, übernimmt das System die Authentifizierung automatisch und übergibt eine Live-Session direkt an deine main-Funktion. Mit dieser Session kannst du Tabellen lesen, Queries ausführen und Daten mit Standard-Snowpark-Methoden manipulieren. Hier ist der entscheidende Punkt in Sachen Dependencies. Du erwartest vielleicht, ein Terminal zu öffnen und pip zu nutzen, um deine Libraries zu installieren, aber so funktionieren Worksheets nicht. Du verwendest pip überhaupt nicht. Snowflake integriert sich nativ mit dem Anaconda Repository. Im Worksheet Interface findest du ein spezielles Packages-Dropdown-Menü. Du suchst einfach nach der Library, die du brauchst, wie pandas oder scikit-learn, wählst die Version aus, und Snowflake stellt sie sofort für dein Execution Environment bereit. Das deckt Inputs und Setup ab. Wie sieht es mit Outputs aus? Deine Handler-Funktion muss einen Wert zurückgeben, und du konfigurierst in den Worksheet Settings, wie Snowflake diesen Wert interpretiert. Du wählst hauptsächlich zwischen zwei Return Types: Table oder String. Wenn du den Return Type auf Table setzt, muss deine main-Funktion einen Snowpark DataFrame zurückgeben. Snowflake nimmt diesen DataFrame und rendert ihn als sauberes, interaktives Grid im Results Panel. Das ist perfekt, um den Output deines Data Cleaning Scripts zu überprüfen. Wenn du den Return Type auf String setzt, muss deine Funktion einen skalaren Textwert zurückgeben. Das nutzt du, wenn du eine Statusmeldung, ein als Text gecastetes numerisches Aggregat oder einen JSON Payload zurückgeben willst. Dein Code muss mit den Worksheet Settings übereinstimmen. Wenn du das Worksheet so konfigurierst, dass es eine Table erwartet, deine Funktion aber einen String zurückgibt, schlägt die Execution fehl. Die wahre Stärke von Python Worksheets liegt nicht im Bauen riesiger Multi-File-Applications. Sie liegt in der Möglichkeit, Transformation Logic in Sekunden sicher gegen Production-Scale-Daten zu validieren, ohne jemals eine lokale Maschine zu konfigurieren. Danke fürs Zuhören. Ich hoffe, du hast etwas Neues mitgenommen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake und Snowpark Python, Folge 5 von 17. Wenn du ein DataFrame instanziierst, das eine Milliarde Zeilen repräsentiert, wie viel Arbeitsspeicher verbraucht das auf deinem Laptop? Fast null. Der Grund dafür liegt in den Kernmechanismen, wie Snowpark DataFrames konstruiert werden. Ein Snowpark DataFrame ist kein Container, der deine Daten enthält. Es ist einfach eine logische Referenz auf Daten, die in Snowflake liegen. Wenn du ein DataFrame in deinem Python-Code definierst, konstruierst du einen Query Plan. Das basiert auf einem Konzept namens Lazy Evaluation. Bei der Lazy Evaluation verzögert Snowpark die Ausführung des zugrundeliegenden SQLs, bis du explizit eine Action triggerst, die ein finales Ergebnis erfordert. Bis dieser Trigger passiert, ist jedes DataFrame, das du baust, nur ein leichtgewichtiges Set von Instructions. Der primäre Weg, um diese Instructions aufzubauen, ist die session dot table Methode. Du übergibst den Namen einer existierenden Snowflake Table oder View als String. Du kannst nur den Table-Namen angeben, oder einen fully qualified Namen inklusive Database und Schema. Ein häufiger Fehler von neuen Usern ist die Annahme, dass der Aufruf von session dot table die Table-Inhalte in ihre lokale Python-Umgebung herunterlädt, ähnlich wie Pandas funktioniert. Das tut es nicht. Wenn du session dot table auf ein zehn Terabyte großes Transaction Log richtest, kommt die Python-Funktion in Millisekunden zurück. Es wandern keine Daten über das Netzwerk. Das DataFrame-Objekt registriert diese spezifische Table lediglich als Root Node deines Execution Plans. Ein anderer Ansatz ist die session dot sql Methode. Die benutzt du, wenn du ein DataFrame mit einem raw SQL String definieren willst. Das ist besonders nützlich, wenn du eine bestehende Query hast, die du portieren willst, oder wenn du eine bestimmte initiale Extraktion lieber in SQL ausdrücken möchtest. Genau wie bei der table Methode, sendet das Übergeben einer Query an session dot sql die Query nicht zur sofortigen Execution an Snowflake. Es erstellt ein DataFrame, das den Output dieser spezifischen Query repräsentiert. Du kannst dir das wie das Definieren einer Inline View vorstellen. Der dritte Mechanismus ist die session dot create dataframe Methode. Diese funktioniert anders, weil sie mit Daten startet, die bereits auf deiner lokalen Maschine liegen. Du kannst dieser Methode eine Python List, ein Dictionary oder ein Pandas DataFrame übergeben. Wenn sie ausgeführt wird, nimmt Snowpark diese lokalen Daten, lädt sie zu Snowflake hoch und packt sie in eine Temporary Table. Die Methode gibt dann ein Snowpark DataFrame zurück, das auf diese neue Temporary Table zeigt. Hier ist der entscheidende Punkt. Weil die session dot create dataframe Methode Daten physisch von deiner Maschine zu Snowflake bewegt, hängt ihre Performance komplett von der Größe deines lokalen Datasets und deiner Netzwerkverbindung ab. Du nutzt das, um kleine Lookup Tables oder Konfigurationsparameter in Snowflake zu pushen, damit sie mit deinen größeren Datasets interagieren können. Du kannst Snowpark die Column-Namen und Datentypen aus deinen lokalen Objekten ableiten lassen, oder du kannst explizit ein Schema mit einem Snowpark StructType-Objekt definieren, um Präzision sicherzustellen. Jedes Mal, wenn du ein Snowpark DataFrame konstruierst, unabhängig von der Methode, definierst du eine Beziehung zu Daten, anstatt die Daten selbst abzurufen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 6 von 17. Du schreibst zehn komplexe DataFrame-Operationen nacheinander, aber das System führt nicht zehn separate Queries aus. Stattdessen verzögert es die Ausführung und baut im Hintergrund ein perfekt optimiertes SQL Statement zusammen. Heute geht es um die Transformation von DataFrames. Wenn du einen DataFrame transformierst, erstellst du quasi ein Rezept dafür, wie deine Daten geformt werden sollen. Um dieses Rezept zu bauen, brauchst du einen zuverlässigen Weg, um auf die zugrunde liegenden Datenspalten zu verweisen. Das machst du mit einer Funktion namens col. Du übergibst den Namen einer Spalte als String an diese Funktion, und sie gibt ein Column-Objekt zurück. Dieses Objekt verwendest du dann in anderen Methoden, um Expressions zu bauen, zum Beispiel um zu prüfen, ob ein Spaltenwert einer bestimmten Zahl oder einem Text-String entspricht. Schauen wir uns ein konkretes Szenario an. Du hast zwei DataFrames. Der eine enthält Kundenprofile, der andere Transaktionsdatensätze. Du möchtest wertvolle User identifizieren und sie mit ihren letzten Käufen verknüpfen. Wenn du das in reinem SQL schreiben würdest, hättest du am Ende vielleicht eine große, verschachtelte Query, bei der du die Logik von innen nach außen lesen musst. Mit DataFrames nutzt du Method Chaining, um die Logik von oben nach unten zu schreiben. Zuerst nimmst du deinen Kunden-DataFrame und rufst die filter-Methode auf. Innerhalb dieses filters nutzt du die col-Funktion, um auf die Spending-Tier-Spalte zu zeigen, und legst fest, dass sie deinem Top-Tier entsprechen muss. Direkt nach diesem filter hängst du eine select-Methode an. Du nutzt die col-Funktion erneut, um anzugeben, dass du nur die Customer-ID und die E-Mail-Adresse behalten willst. Jede Transformation gibt einen neuen DataFrame zurück, sodass du die nächste Anweisung direkt an das Ende der vorherigen anhängen kannst. Der zweite Teil davon ist nun, die Transaktionsdaten reinzuholen. Du rufst die join-Methode auf deinem gefilterten Kunden-DataFrame auf. Du übergibst den Transaktions-DataFrame als erstes Argument. Dann legst du die Bedingung für den join fest, zum Beispiel den Abgleich der Customer-ID-Spalte aus beiden Datensätzen. Du kannst auch den Typ des joins definieren, wie einen inner join oder left join. Die Logik liest sich sequenziell. Du filterst, du nutzt select und du joinst. Hier ist der entscheidende Punkt. Während Python diese Chain von Methoden liest, fasst Snowpark die eigentlichen Daten gar nicht an. Transformationen werden lazy evaluiert. Der DataFrame dient einfach als Blueprint. Er protokolliert jeden filter, jedes select und jeden join, den du anforderst, aber er führt sie nicht Schritt für Schritt aus. Diese verzögerte Ausführung erlaubt es dem Framework, deine gesamte Sequenz von Operationen anzuschauen und zu optimieren, bevor überhaupt etwas läuft. Die Ausführung wird erst getriggert, wenn du schließlich ein konkretes Ergebnis anforderst. Dafür musst du eine Action-Methode aufrufen. Wenn du ein kleines Sample der Daten in deinem Terminal ausgeben willst, rufst du die show-Methode auf. Wenn du die vollständig verarbeiteten Ergebnisse zurück in deinen lokalen Python-Memory herunterladen willst, rufst du die collect-Methode auf. In dem Moment, in dem du collect aufrufst, übersetzt Snowpark deinen Blueprint in eine einzige, effiziente SQL Query und sendet sie an Snowflake. Du hast den Vorteil, dass du Schritt für Schritt lesbares Python schreibst, während die Datenbank-Engine die Daten trotzdem in einem hochoptimierten Durchlauf verarbeitet. Das war's für diese Folge. Wir hören uns beim nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 7 von 17. Du baust eine Data Pipeline und brauchst plötzlich eine komplexe String-Manipulation oder eine ungewöhnliche mathematische Umrechnung. Du musst diese Logik nicht von Grund auf in Python schreiben. Die Datenbank kann das bereits. Hier kommen System Functions ins Spiel. Snowflake hat hunderte von integrierten System Functions, die in hochoptimiertem C++ geschrieben sind. Diese übernehmen alles, vom Parsen von Text bis zur Berechnung von Standardabweichungen. Mit Snowpark kannst du diese nativen SQL-Funktionen direkt aus deinem Python-Code aufrufen. Du bekommst die gewohnte Python-Struktur, aber das Heavy Lifting passiert komplett innerhalb von Snowflake. Die eigentlichen Daten verlassen den Server nie, um in deiner lokalen Python-Umgebung verarbeitet zu werden. Um darauf zuzugreifen, importierst du das Modul snowflake dot snowpark dot functions. Dieses Modul enthält direkte Python-Wrapper für die meisten Standard-SQL-Operationen. Wenn du Text in Großbuchstaben umwandeln musst, rufst du einfach die upper Funktion aus diesem Modul auf und übergibst ihr dein Column-Objekt. Im Hintergrund übersetzt Snowpark deinen Python-Code in die entsprechende SQL-Syntax und pusht ihn zur Ausführung runter in die Datenbank. Das deckt die meisten Use Cases ab. Aber was passiert, wenn Snowflake eine neue SQL-Funktion veröffentlicht, oder du eine spezielle System Function brauchst, für die es noch keinen expliziten Python-Wrapper im Modul gibt? Du musst nicht auf das nächste Release der Snowpark Library warten, um sie zu nutzen. Das ist der Teil, auf den es ankommt. Du kannst eine spezielle Methode namens call_function nutzen, um jede Snowflake System Function über ihren exakten SQL-Namen aufzurufen. Stell dir ein Szenario vor, in dem du eine Tabelle mit Millionen von Rows hast, die Winkelmessungen in Grad enthalten, und dein nachgelagertes Machine Learning Model braucht sie in Radiant. Anstatt eine Custom-Python-Mathe-Transformation zu schreiben, die all diese Rows in den Memory zieht, überlässt du der Database Engine die Arbeit. Du importierst call_function. Dann rufst du sie auf, indem du den String-Namen radians als erstes Argument übergibst. Das zweite Argument ist das Column-Objekt, das du transformieren willst. Snowpark pusht das sofort als native SQL-radians-Operation für dein gesamtes Dataset runter. Sie wird mit der Geschwindigkeit von kompiliertem C++ Code ausgeführt, und du brauchst dafür genau eine Zeile Python-Code. Die call_function Methode ist flexibel. Wenn die zugrundeliegende SQL-Funktion mehrere Inputs erfordert, übergibst du sie einfach nacheinander nach dem Funktionsnamen. Diese Inputs können andere Column-Objekte sein, oder auch Literal Values, wie ein bestimmter String oder eine Zahl. Snowpark mappt deine Python-Argumente direkt auf die erwarteten SQL-Parameter. Dieses Design hält deinen Code clean und maximiert gleichzeitig die Performance. Du verlierst nicht den Zugriff auf die rohe Power der nativen Snowflake SQL-Funktionen, nur weil du in einer anderen Sprache schreibst. Indem du System Functions nutzt, behandelst du Python als Orchestrator und lässt die Database Engine genau das tun, wofür sie gebaut wurde. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 8 von 17. Eine bestehende pandas-Pipeline zu skalieren, bedeutete bisher, den gesamten Code zu verwerfen und in einem Distributed Framework wie Spark neu zu schreiben. Was wäre, wenn du ein hundertmal größeres Dataset verarbeiten könntest, indem du lediglich ein einziges Import Statement änderst? Genau das ist die Idee hinter pandas on Snowflake. pandas ist der universelle Standard für Data Manipulation in Python. Es ist ausdrucksstark, lesbar und fest in der Arbeitsweise von Data Engineers und Data Scientists verankert. Das Problem ist, dass pandas grundsätzlich durch Single-Node Execution eingeschränkt ist. Es erfordert, dass all deine Daten in den lokalen Memory passen. Sobald dein Dataset deinen Laptop oder deine Cloud Instance übersteigt, stößt Standard-pandas an seine Grenzen. pandas on Snowflake stellt einen kompletten Paradigmenwechsel für diese Legacy Pipelines dar. Es fungiert als Zero-Friction Migration Tool. Angenommen, du hast ein bestehendes Python Script, das tägliche Transaction Logs bereinigt und aggregiert. Es funktioniert einwandfrei mit zehn Gigabyte Daten, doch plötzlich sollst du ein Terabyte verarbeiten. Um das zu skalieren, musst du deine Logik nicht in SQL umschreiben. Du musst nicht einmal die spezifische Syntax der Standard Snowpark DataFrame API lernen. Du änderst lediglich eine Zeile ganz oben in deinem File. Du entfernst den Standard Import pandas as pd. Du ersetzt ihn durch import snowflake.snowpark.modin.pandas as pd. Hier wird es interessant. Oft herrscht Verwirrung darüber, wie das die Daten eigentlich verarbeitet. Viele Entwickler gehen davon aus, dass es sich einfach um Standard-pandas handelt, das über eine Live Connection Millionen von Rows auf ihre lokale Machine herunterlädt, um sie zu verarbeiten. Das ist falsch. Wenn du diesen speziellen Modin Import verwendest, werden keine Daten auf deine Machine heruntergeladen. Stattdessen fängt diese Library jeden pandas Command ab, den du in deinem Script schreibst. Wenn du einen Filter, ein Group-by und eine Mean Aggregation chainst, übersetzt die zugrunde liegende Engine diese exakte Sequenz in eine optimierte Snowflake SQL Query. Sie transpiliert deine pandas Syntax in SQL und übermittelt dieses SQL anschließend an die Snowflake Compute Engine. Die Operation wird vollständig innerhalb deines Snowflake Warehouses ausgeführt. Deine lokale Machine ist lediglich für die Orchestrierung der Commands zuständig. Die Hauptarbeit wird auf Snowflake Cluster verteilt. Dadurch erhältst du die exakte Developer Experience von pandas, aber unterstützt durch eine massiv parallele Datenbank. Diese Umstellung löst gleich zwei große organisatorische Probleme. Erstens eliminiert es das Data Egress Problem. Da die Operationen in die Datenbank gepusht werden, verlassen deine Raw Data niemals den sicheren Snowflake Perimeter. Zweitens spart es Monate an Developer Retraining. Dein Team schreibt weiterhin die gewohnten DataFrames, Joins und Aggregationen, die es bereits perfekt beherrscht. Sie führen sie einfach in der Cloud aus, anstatt auf dem lokalen Prozessor. Die wahre Stärke von pandas on Snowflake liegt darin, dass es die Sprache, mit der du deine Data Transformations beschreibst, von der Engine entkoppelt, die sie tatsächlich ausführt. Wenn dir diese technischen Deep Dives helfen, kannst du die Show unterstützen, indem du auf Patreon nach DevStoriesEU suchst. Das war’s für diese Folge. Danke fürs Zuhören und viel Spaß beim Coden!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 9 von 17. Dein Code ist jetzt smart genug, um genau zu wissen, wann er den Memory deines Laptops nutzen und wann er einen Cloud-Cluster hochfahren soll. Das ist das Kernkonzept hinter pandas auf Snowflake: Hybrid Execution. Wenn du Standard-pandas nutzt, läuft jede Operation im Memory deiner lokalen Maschine. Wenn du ein riesiges Dataset lädst, stürzt dein Prozess ab. Die Snowpark pandas API löst das, indem sie deine pandas-Commands auf SQL mappt und sie im Snowflake Warehouse ausführt. Aber nicht jede pandas-Funktion hat ein direktes SQL-Äquivalent. Bestimmte Operationen, wie Plotting oder das Anwenden von spezifischen Custom Python Functions, erfordern zur Ausführung die eigentliche lokale pandas-Library. Die Herausforderung ist, nahtlos zwischen der Cloud-Engine und deiner lokalen Environment zu wechseln, ohne Gigabytes an Raw Data über das Netzwerk zu ziehen. Hybrid Execution managt diese Transition dynamisch. Es ist ein Execution Model, das komplett darauf ausgelegt ist, die Data Transfer Costs zu minimieren. Wenn du ein Script mit der Snowpark pandas API ausführst, agiert die Engine als intelligenter Router. Ihr Default Behavior ist es, die Daten in der Cloud zu behalten. Sie übersetzt deinen Code in SQL Queries und führt sie über Snowflake Compute aus. Lass uns ein praktisches Szenario durchgehen. Du startest mit einer Table, die zehn Millionen Rows enthält. Du schreibst eine Zeile Code, um ungültige Records herauszufiltern, und dann gruppierst du die Daten, um einen Durchschnitt zu berechnen. Bis zu diesem Punkt übersetzt die Engine deine Filter- und Aggregation-Commands direkt in SQL. Das Snowflake Warehouse übernimmt das Heavy Lifting. Deine lokale Maschine lädt nicht eine einzige Row von diesem riesigen Dataset herunter. Die Aggregation reduziert diese zehn Millionen Rows auf eine Summary Table von genau sieben Rows. Für deinen nächsten Schritt schreibst du einen Command, um diese sieben Rows in einen Chart zu plotten. Plotting ist von Natur aus eine lokale Operation. Die Snowflake Database Engine kann keinen Chart für dich zeichnen. Hier ist die entscheidende Erkenntnis. Die Engine erkennt, dass der Plotting-Command eine Transition zum lokalen pandas-Backend erfordert. Weil die Engine deine Operationen intelligent verarbeitet, schaut sie sich den State deiner Daten genau an, bevor die lokale Operation angefragt wird. Sie weiß, dass die vorherige Aggregation in nur sieben Rows resultiert. Anstatt also die ursprünglichen zehn Millionen Rows auf deinen Laptop zu ziehen, um die Aggregation lokal zu verarbeiten, lässt sie Snowflake die Berechnungen in der Cloud abschließen. Dann triggert sie einen Download von genau diesen finalen sieben Rows in deinen lokalen Memory. Sobald die Daten in deiner lokalen Environment ankommen, übernimmt Standard-pandas. Die lokale Library führt den Plot-Command mit diesen sieben Rows aus. Alle nachfolgenden Operationen, die du auf dieser spezifischen Data Structure ausführst, laufen weiterhin lokal, weil die Daten die Network Boundary bereits überquert haben. Das System isoliert die rechenintensive Data Manipulation innerhalb der Cloud-Infrastructure. Es verzögert den Network Transfer, bis eine Operation zwingend eine lokale Execution erfordert. Bis diese Anforderung auftritt, haben deine Data Manipulation Steps das Dataset normalerweise auf einen Bruchteil seiner ursprünglichen Größe reduziert. Du behältst die API-Syntax, die du bereits kennst, aber du vermeidest den Network Bottleneck komplett. Das entscheidende Feature von Hybrid Execution ist nicht nur, dass sie auf den lokalen Memory zurückfällt, sondern dass sie die Payload in der Cloud strategisch verkleinert, bevor sie den Sprung macht. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake und Snowpark Python, Folge 10 von 17. Was wäre, wenn du eine PostgreSQL-Datenbank direkt aus deinem Snowflake Python Script abfragen könntest? Normalerweise braucht man für den Datentransfer von einer operativen Datenbank zu Snowflake einen externen Middleman. Du richtest ein Extraction Tool auf einem separaten Server ein, verwaltest Credentials, stagest Files und schedulst Jobs, nur um deine Daten für die Analyse vorzubereiten. Das direkte Ingesting externer Daten über Snowpark Python löst dieses Problem, indem der Middleman komplett entfällt. Dieser Ansatz ermöglicht es dir, deine Data Architecture zu vereinfachen. Durch die Nutzung von External Network Access in Snowflake kann dein Python Code direkt auf andere Systeme zugreifen. Du kannst Standard Python DB-API Libraries oder JDBC Driver verwenden, um direkt aus einer Snowpark Stored Procedure oder einer User-Defined Table Function eine Connection zu externen Datenbanken herzustellen. Stell dir ein konkretes Szenario vor. Du hast eine Legacy On-Premise PostgreSQL Inventory Datenbank und musst diese Inventory Daten mit deinen Live Snowflake Customer Tables joinen. Anstatt eine komplexe Ingestion Pipeline aufzusetzen, schreibst du eine Snowpark Python Stored Procedure. Innerhalb dieser Procedure nutzt du einen Standard Postgres DB-API Connector. Du übergibst deinen Connection String, der auf Credentials verweist, die von Snowflake sicher verwaltet werden. Du öffnest die Connection, führst ein Standard SQL Select Statement gegen die externe PostgreSQL-Datenbank aus und fetchst das Result Set. Sobald die Daten in deiner Python Function in Memory sind, yieldest du die Rows einfach an Snowflake zurück oder konvertierst sie direkt in einen Snowpark DataFrame. Deine externen Inventory Daten stehen dir nun als natives Snowflake Object zur Verfügung, bereit, um in einer einzigen Query mit deinen Customer Tables gejoint zu werden. Die Logik fließt vom externen operativen System direkt in dein Analytical Environment – sicher und ohne zwischengeschaltete Staging Server. Damit sind relationale Inputs abgedeckt. Was ist mit semi-strukturierten Data Sources, wie Nested Files, die in einer Stage abgelegt werden? Snowpark bietet auch spezifische Tools zum Parsen komplexer Formate. Ein Paradebeispiel ist der XML RowTag Reader. Wenn du ein unhandliches XML File ingesten musst, brauchst du keine Custom Parsing Logic zu schreiben, um durch den gesamten Document Tree zu navigieren. Stattdessen gibst du einen Row Tag an. Das ist das spezifische XML Element, das einen einzelnen Record repräsentiert. Du rufst die Read Method deiner Snowpark Session auf, setzt das Format auf XML und übergibst den Row Tag Parameter. Snowflake scannt das Document, identifiziert jede Instanz dieses Tags und extrahiert sie als einzelne Row in einem DataFrame. Die komplexe Hierarchie ober- und unterhalb dieses Tags wird geflattet oder in Columns gepackt, abhängig von deinem Schema. Es verwandelt ein Nested Text Document in einem Schritt in eine saubere, querybare Table. Hier ist die wichtigste Erkenntnis. Egal, ob du eine JDBC Connection zu einer uralten On-Premise Datenbank öffnest oder einen Row Tag Reader auf ein Nested XML File anwendest – du konsolidierst deine Ingestion Logic innerhalb der Data Platform. Du verwandelst Integrationsprobleme in einfache Code Execution Probleme. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 11 von 17. Wie führst du custom Python String-Parsing-Logik über Milliarden von Zeilen aus, ohne die Daten zu verschieben? Die Antwort liegt im Erstellen von skalaren UDFs, also User-Defined Functions. Standard-SQL-Funktionen decken die meisten alltäglichen Data Transformations ab. Wenn Standard-SQL an seine Grenzen stößt, springen Python-UDFs nahtlos ein. Wenn du es mit stark angepassten Regeln zu tun hast, wie zum Beispiel dem Schreiben einer komplexen Regular Expression, um unsaubere E-Mail-Adressen zu parsen, wird reines SQL schnell unlesbar oder unmöglich. Skalare UDFs lösen dieses Problem, indem sie dich plain Python-Logik schreiben und nativ in der Snowflake Compute Engine ausführen lassen. Eine skalare Funktion verarbeitet einfach eine Input-Row und gibt genau einen Output-Value zurück. Um deinen Python-Code zu deployen, nutzt du Snowpark, um die Funktion zu registrieren. Wenn du die Logik nur für dein aktuelles Script brauchst, erstellst du eine anonyme UDF. Am einfachsten geht das mit dem at-UDF Decorator. Zuerst schreibst du eine Standard-Python-Funktion. Nennen wir sie extract email domain. Darin nutzt du das Standard-Python-Regex-Modul, um den Text-String zu parsen und die gematchte Domain zurückzugeben. Direkt über der Function Definition platzierst du den at-UDF Decorator. Wenn dein Script ausgeführt wird, serialisiert Snowpark diese Python-Funktion automatisch, pusht sie auf den Server und gibt eine Referenz auf ein UDF-Objekt zurück. Du kannst dieses Objekt nun in deine DataFrame Column Operations übergeben und deinen custom Parser auf riesige Tabellen anwenden, als wäre es ein natives Database Feature. Alternativ kannst du den Decorator weglassen und deine Python-Funktion explizit in die session dot udf dot register Methode übergeben. Beide Methoden erzeugen ein temporäres Objekt in der Database Engine. In dem Moment, in dem sich deine Snowpark Session schließt, wird die anonyme UDF komplett gedroppt. Hier wird es interessant. Wenn deine neue Parsing-Logik wertvoll ist, willst du sie wahrscheinlich mit anderen Usern teilen oder für downstream SQL-Pipelines verfügbar machen. Um das zu erreichen, erstellst du eine benannte, permanente UDF. Mit derselben register Methode fügst du ein is permanent Flag hinzu, das auf true gesetzt ist, und übergibst einen String-Wert für den name Parameter. Dieser Name bestimmt, wie die Funktion in der Datenbank aufgerufen wird. Wenn du eine UDF permanent machst, braucht Snowflake einen physischen Ort, um deinen Python-Code zu persistieren, damit er auch lange nach dem Disconnect deiner Session verfügbar bleibt. Deshalb musst du auch einen stage location Parameter übergeben. Dieser zeigt auf eine existierende interne Snowflake Stage. Snowpark wird die kompilierten Python-Files direkt in diese Stage uploaden und sicher speichern. Sobald die Registrierung abgeschlossen ist, kann jeder mit den richtigen Database Permissions deine custom Python-Logik direkt aus einer Standard-SQL-Query aufrufen. Beim Erstellen einer UDF verlässt sich Snowpark normalerweise auf Python Type Hints, um zu verstehen, welche Data Types die Funktion akzeptiert und zurückgibt. Wenn deine Funktion einen String erwartet und einen String zurückgibt, fügst du diese Standard Type Hints zur Python Definition hinzu, und Snowpark mappt sie automatisch auf die entsprechenden Snowflake Data Types. Die wahre Stärke der skalaren UDF ist nicht nur die Möglichkeit, Python zu schreiben, sondern die Möglichkeit, dieses Python im Distributed Memory der Database Engine auszuführen, was die Network Latency für das Herausziehen von Daten zur Verarbeitung komplett eliminiert. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake und Snowpark Python, Folge 12 von 17. Third-Party Python Packages in einer Datenbank auszuführen, bedeutete früher Dependency Hell. Du hast am Ende komplexe Docker Container gebaut, nur um ein Array an eine Math Function zu übergeben. Heute brauchst du dafür genau eine Zeile Code. In dieser Folge geht es um Dependency Management für UDFs. Wenn du eine User-Defined Function, kurz UDF, schreibst, existiert deine Logik selten im luftleeren Raum. Du brauchst Libraries. In einem traditionellen Setup bedeutet das Verschieben deines Python Codes dorthin, wo die Daten liegen, dass du auch dein gesamtes Environment umziehen musst. Du machst dir Gedanken über pip Installs, Compiler Dependencies und darüber, den Server exakt wie deine lokale Maschine zu halten. Snowflake vermeidet diesen Albtraum automatisch durch eine Built-in Integration mit dem Anaconda Channel. Der Snowflake Anaconda Channel hostet Tausende von pre-built, pre-compiled Python Packages, die garantiert in der Snowflake Execution Environment funktionieren. Um sie zu nutzen, installierst du nichts manuell. Du deklarierst einfach, was deine Function braucht. Wenn du deine UDF mit dem Python Decorator definierst, fügst du einen Parameter namens packages hinzu. Diesem Parameter übergibst du eine Liste von Strings mit den Namen der Libraries, die du brauchst. Nehmen wir ein konkretes Szenario. Du willst ein Machine Learning Model nutzen, um Rows direkt in einer Snowflake Query zu scoren. Deine Prediction Function verlässt sich auf scikit-learn und pandas. Direkt über deiner Python Function fügst du den UDF Decorator hinzu und setzt die packages Liste so, dass sie die Strings scikit-learn und pandas enthält. Du baust keinen Container und du führst keinen Package Manager aus. Wenn du diese UDF aufrufst, provisioniert Snowflake ein sicheres Environment, zieht genau diese Packages aus dem Anaconda Channel und führt deinen Code aus. Wenn du ein bestimmtes Release brauchst, kannst du die Version pinnen, indem du zwei Gleichheitszeichen und die Versionsnummer direkt in den String einfügst, genau wie in einem Standard Python Requirements File. Das deckt externe Libraries ab. Der zweite Teil davon ist dein eigener Custom Code. Nicht alles, was du schreibst, gehört auf Anaconda. Oft hast du Helper Functions oder Custom Business Rules, die in einem separaten Python File geschrieben sind. Snowflake handhabt diesen First-Party Code über deine aktive Session. Du rufst eine Methode namens add import auf dem Session Object auf. Du übergibst den Pfad deines Custom Files an add import. Das kann ein lokales Python File auf deinem Laptop sein, ein File, das bereits in einer Snowflake Stage liegt, oder ein Zip-Archiv, das ein tieferes Directory von Modulen enthält. Wenn du deine UDF registrierst, schnappt sich Snowflake die von dir angegebenen Files und lädt sie hoch. Zur Runtime extrahiert Snowflake diese Files und platziert sie direkt im System Path des isolierten Environments, das deine UDF ausführt. Innerhalb deines Main Function Codes nutzt du einfach Standard Python Import Statements, um deine Custom Module reinzuholen, genau so, als lägen sie lokal im selben Ordner. Du kannst diese beiden Ansätze frei kombinieren. Du deklarierst deine externen Requirements über den packages Parameter und injizierst deine internen Module mit add import. Snowflake baut den Execution Context auf, indem es die Anaconda Binaries sicher mit deinen Custom Staged Files zusammenführt, bevor auch nur eine einzige Row an Daten verarbeitet wird. Hier ist der entscheidende Punkt. Indem Dependencies auf diese Weise gehandhabt werden, entkoppelt Snowflake deinen funktionalen Code komplett von der Infrastruktur, die für seine Ausführung nötig ist. So kannst du ein sicheres, verteiltes Execution Environment definieren, für das du nichts weiter als eine Liste von Namen und File Paths brauchst. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 13 von 17. Was machst du, wenn deine Python-Funktion eine ganze Ergebnistabelle anstelle eines einzelnen Werts zurückgeben muss? Standard User-Defined Functions sind zwar super, aber sie sind strikt darauf beschränkt, einen einzigen skalaren Wert pro Input Row zurückzugeben. Wenn du einen einzelnen Input in mehrere Outputs aufteilen musst, baust du eine User-Defined Table Function, oder kurz UDTF. Der Unterschied ist fundamental. Eine Standardfunktion gibt einen Wert zurück. Eine UDTF gibt eine Relation zurück. Das bedeutet, sie liefert eine tabellarische Struktur, die du abfragen, filtern oder mit anderen Tabellen joinen kannst, genau als wäre es eine physische Tabelle in deiner Datenbank. Stell dir ein konkretes Szenario vor: Du hast eine Tabelle mit einer Spalte, die stark verschachtelte, custom JSON Application Logs enthält. Jede Row enthält einen riesigen Log-Entry, aber dieser einzelne Entry könnte fünf, zehn oder fünfzig verschiedene System-Events enthalten, die tief im JSON versteckt sind. Du musst diese Daten programmatisch normalisieren. Du willst einen JSON-String übergeben und eine strukturierte Tabelle zurückbekommen, in der jedes einzelne Event in eine eigene Row extrahiert wird. Um eine UDTF in Snowpark Python zu bauen, schreibst du keine Standalone-Funktion. Du schreibst eine Python-Klasse. Diese Klasse fungiert als Handler für die Table Function und orchestriert die Logik mit bis zu drei spezifischen Methoden. Die erste ist die Initialization-Methode. Diese ist optional. Snowflake führt sie einmal pro Partition aus, bevor irgendwelche Rows verarbeitet werden. Wenn dein Log-Parser eine komplexe Regular Expression kompilieren oder ein custom State Dictionary initialisieren muss, machst du das hier, damit die Setup-Kosten nur einmal pro Daten-Batch anfallen. Die zweite ist die Process-Methode. Das ist die einzige obligatorische Methode in der Klasse. Snowflake ruft sie für jede einzelne Input Row auf. In unserem Logging-Szenario empfängt die Process-Methode den JSON-String, entpackt das Array von Events und iteriert darüber. Hier passiert die Konvertierung. Anstatt einen finalen Wert zurückzugeben, yieldet die Process-Methode Tuples. Jedes Tuple, das sie yieldet, wird sofort zu einer neuen Row in deiner Output-Tabelle. Wenn ein JSON-Log-String zwölf Events enthält, yieldet die Process-Methode zwölf separate Tuples, und Snowflake macht daraus zwölf verschiedene Output Rows. Die dritte ist die End-Partition-Methode. Diese ist ebenfalls optional. Snowflake triggert sie, nachdem alle Rows in der aktuellen Partition durch die Process-Methode gegangen sind. Du nutzt das typischerweise, wenn du State über die Partition hinweg aggregierst und eine finale Summary Row yielden musst, oder einfach um Memory und Ressourcen aufzuräumen. Wenn du diese Handler-Klasse in Snowpark registrierst, musst du dein Output-Schema explizit deklarieren. Weil eine UDTF eine Tabelle zurückgibt, muss die Database Execution Engine die genauen Column-Namen und Datentypen der Tuples kennen, die du yieldest, bevor die Query überhaupt läuft. Hier ist die wichtigste Erkenntnis: UDTFs schließen die Lücke zwischen komplexer Python-Logik und relationalen Datenbank-Operationen. Sie erlauben es dir, unordentliches, prozedurales Data Unnesting in einem sauberen Table Interface zu wrappen, das der Rest deiner Application nativ abfragen kann. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 14 von 17. Hör auf, für einen externen Orchestration Server zu bezahlen, nur um Python-Skripte auszuführen, die Snowflake sagen, was es tun soll. Wenn du Stored Procedures schreibst, bringst du diesen Control Flow direkt in die Datenplattform. Oft werden Stored Procedures mit User-Defined Functions, oder UDFs, verwechselt. Eine UDF ist nicht für die Orchestration gedacht. UDFs geben Werte innerhalb einer Query zurück und transformieren Daten Zeile für Zeile. Stored Procedures sind da komplett anders. Sie führen ganze Skripte aus, lassen mehrere Queries laufen und kümmern sich um den prozeduralen Control Flow. Du nutzt sie, um Tasks zu orchestrieren, nicht um Spaltenwerte zu berechnen. Um eine Stored Procedure in Snowpark Python zu erstellen, schreibst du eine Standard-Python-Funktion. Die wichtigste Voraussetzung ist das erste Argument dieser Funktion. Es muss immer ein Snowpark Session Objekt sein. Diese Session ist deine aktive Verbindung zur Datenbank. Wenn deine Procedure läuft, nutzt sie diese Session, um SQL Statements auszuführen, DataFrames zu bauen und Daten zu lesen oder zu schreiben. Um Snowflake zu sagen, dass diese Funktion eine Stored Procedure ist, packst du den sproc Decorator direkt über deine Funktionsdefinition. Der Decorator dient als Configuration Layer. Du nutzt ihn, um den Return Type deiner Procedure und alle Third-Party Python Packages anzugeben, die dein Code zum Laufen braucht. Wenn du den Registrierungscode ausführst, nimmt Snowpark deine Python-Funktion, verpackt sie zusammen mit ihren Dependencies und registriert sie in Snowflake. Von da an lebt die Logik in der Datenbank und wird auf Snowflake Compute ausgeführt. Denk mal an eine nächtliche Data Pipeline. Dein Prozess muss eine temporäre Tabelle erstellen, Rohdaten hineinladen, eine Reihe von mehrstufigen Transformationen durchführen und am Ende die temporären Objekte aufräumen. Wenn du das von einem externen Server aus laufen lässt, sendet dein Python-Code einen Befehl über das Netzwerk, wartet darauf, dass Snowflake fertig wird, bekommt das Ergebnis zurück und sendet den nächsten Befehl. Wenn du genau dieselbe Python-Logik als Stored Procedure schreibst, wird das komplette Skript innerhalb von Snowflake ausgeführt. Es nutzt das Session Objekt, um die Tabellenerstellungen und DataFrame-Transformationen nativ durchzugehen. Es gibt null Network Latency zwischen der Orchestration-Logik und den Daten, die sie manipuliert. Auch wenn eine Stored Procedure nicht wie eine UDF einen Wert pro Zeile zurückgibt, liefert sie trotzdem einen einzelnen Wert, wenn das Skript durchgelaufen ist. Du definierst diesen Return Type, wenn du den sproc Decorator einrichtest. Oft ist das ein einfacher String, der den Erfolg bestätigt, ein Integer für die Anzahl der verarbeiteten Zeilen, oder sogar ein tabellarisches Ergebnis, das ein Execution Log zeigt. Du hast verschiedene Möglichkeiten, wie du diesen Code deployen kannst. Du kannst eine anonyme Procedure dynamisch in einem Python-Skript definieren und ausführen, wenn du sie nur für eine einzelne Session brauchst. Für automatisierte Pipelines registrierst du sie als permanentes Objekt. Snowflake speichert die Definition, sodass jeder autorisierte User, jede externe Application oder jeder geplante Task sie später aufrufen kann. Hier ist die wichtigste Erkenntnis. Eine Snowpark Python Stored Procedure zu schreiben bedeutet, dass du Snowflake als Application Runtime behandelst, und nicht nur als Storage Layer. Du verlagerst das Gehirn deiner Orchestration direkt neben die Daten, die sie kontrolliert. Wenn dir die Show gefällt und du unsere Arbeit unterstützen möchtest, findest du uns, wenn du auf Patreon nach DevStoriesEU suchst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 15 von 17. Terabytes an geschützten Daten auf einen externen Machine Learning Server zu übertragen, ist langsam, teuer und riskant. Du verbringst Stunden damit, Daten über das Netzwerk zu pushen, und dein Security-Team wird nervös, wo sie am Ende landen. Was wäre, wenn stattdessen das Compute zu den Daten käme? Genau das ist die Grundidee hinter dem Training von ML-Modellen in Snowflake. Mit Snowpark Python kannst du Single-Node Machine Learning Modelle über Stored Procedures direkt in deinem Data Warehouse trainieren. Die Daten verlassen dabei nie den Snowflake-Perimeter. Das löst das Data-Gravity-Problem. Anstatt Millionen von Zeilen in eine separate Cloud-Instanz zu extrahieren, führst du dein Trainingsskript genau dort aus, wo die Daten aktuell liegen. Um ein Machine Learning Modell zu trainieren, musst du den Datensatz in den Memory laden. Ein Standard Virtual Warehouse in Snowflake ist für parallele SQL-Queries optimiert, nicht dafür, riesige Datensätze im System-RAM zu halten. Wenn du versuchst, einen komplexen Algorithmus auf einem Standard-Warehouse auszuführen, läufst du wahrscheinlich in Out-of-Memory-Errors und der Prozess crasht. Um das zu handhaben, brauchst du ein anderes Compute-Profil. Snowflake bietet speziell für diesen Task Snowpark-optimized Warehouses an. Diese Warehouses bieten im Vergleich zu Standard-Instanzen bis zu sechzehnmal mehr Memory pro Node. Lass uns ein konkretes Szenario durchgehen. Du musst ein scikit-learn Random Forest Modell auf einem riesigen Kundendatensatz trainieren. Du startest, indem du eine Python Stored Procedure schreibst. Wenn du diese Procedure registrierst, gibst du die benötigten Python-Packages an, wie scikit-learn, pandas und joblib. Snowflake provisioniert diese Dependencies automatisch über seinen integrierten Anaconda-Channel. Außerdem legst du fest, dass die Procedure auf deinem Snowpark-optimized Warehouse läuft. Innerhalb der Procedure nutzt du das Snowpark Session-Objekt, um deine Trainingsdaten-Query zu definieren. Dann rufst du die Methode auf, um diesen Snowpark Dataframe in einen Standard pandas Dataframe zu konvertieren. Diese Aktion zieht die Query-Results direkt in den physischen Memory der Warehouse-Node. Weil du das optimierte Compute provisioniert hast, gibt es reichlich RAM, um den gesamten Datensatz auf einmal im Speicher zu halten. Als Nächstes initialisierst du dein Random Forest Modell und rufst die fit-Methode auf, wobei du den pandas Dataframe übergibst. Der Warehouse-Prozessor verarbeitet den Trainingszyklus exakt so, wie er es auf einem dedizierten Machine Learning Server tun würde. Sobald das Modell fertig trainiert ist, hast du einen trainierten Algorithmus, der im temporären Memory der Execution Environment liegt. Du musst ihn für zukünftige Predictions persistieren, bevor die Stored Procedure beendet ist. Hier kommt Serialization ins Spiel. Du nutzt eine Library wie joblib, um das Modell zu verpacken. Du nimmst das trainierte Modell-Objekt im Memory und schreibst es in eine Datei, wodurch ein Artefakt entsteht. Dann weist du die Stored Procedure an, diese neu erstellte Datei direkt in eine interne Snowflake Stage zu schreiben. Eine Stage fungiert als sicherer Storage-Ordner, der an deinen Snowflake-Account gebunden ist. Hier ist die wichtigste Erkenntnis: Deine Stored Procedure fungiert als sicherer Container, der deine Raw-Tables mit Standard Python Machine Learning Libraries verbindet. Indem du die Pipeline komplett innerhalb von Snowflake hältst, reduzierst du deine Network Latency auf null, umgehst alle Data Egress Operationen und behältst strikte Access Controls bei – und das alles, während du exakt denselben Python-Trainingscode schreibst, den du bereits kennst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 16 von 17. Wie verarbeitest du unstrukturierte Dateien im Gigabyte-Bereich innerhalb einer User-Defined Function, ohne deine Memory-Limits zu sprengen? Wenn du versuchst, große Dateien als statische Dependencies einzubinden, versucht das System, alles im Voraus herunterzuladen, und dein Code stürzt ab. Die Lösung dafür ist Dynamic File Access mit SnowflakeFile. Um zu verstehen, warum das wichtig ist, schau dir an, wie der Dateizugriff in Snowpark normalerweise funktioniert. Normalerweise nutzt du den imports-Parameter, um eine Datei an deine Funktion zu binden. Dieser statische Ansatz ist super für kleine Konfigurationsdateien oder ein spezielles Machine-Learning-Model, weil die Datei ins Compute Warehouse heruntergeladen wird, bevor die Execution beginnt. Aber at scale stößt das an seine Grenzen. Wenn deine Pipeline Hunderte von riesigen Server-Logfiles oder hochauflösenden PDFs verarbeiten muss, die in einer Snowflake-Stage gespeichert sind, ist das statische Herunterladen extrem langsam und garantiert dir einen Out-of-Memory Error. Hier kommt die SnowflakeFile-Klasse ins Spiel. Sie befindet sich im Modul snowflake dot snowpark dot files und ermöglicht es deiner Funktion oder Stored Procedure, Dateien zur Runtime direkt von einer Stage aus zu öffnen. Du bindest die Datei nicht während der Erstellung der Funktion. Stattdessen akzeptiert deine Funktion die File Location als ganz normales String-Argument. Wenn du die Funktion in deiner SQL-Query oder Dataframe-Operation aufrufst, übergibst du diese Location. Innerhalb des Python-Codes rufst du die open-Methode der SnowflakeFile-Klasse auf und übergibst ihr den File-Location-String. Außerdem gibst du den Read Mode an, wobei du Standard-Python-Konventionen nutzt, wie r für Text oder r b zum Lesen von Bytes. Hier ist der entscheidende Punkt. Der Aufruf von open lädt die Datei nicht. Er liefert ein File-like Object, das die Daten streamt. Die Datei bleibt auf der Stage, und du ziehst die Daten durch eine Network Pipe. Wenden wir das mal auf das Log-Processing-Szenario an. Du hast eine Datenbanktabelle, in der jede Zeile eine Scoped URL enthält, die auf ein anderes großes Logfile auf einer internen Stage zeigt. Du übergibst diese URL-Spalte an deine Funktion. Innerhalb der Funktion öffnest du den Stream und schreibst einen Standard-Loop, um die Datei Zeile für Zeile zu lesen. Während dein Code jede Zeile auswertet, um Error-Codes oder Timestamps zu extrahieren, wirft Python die vorherigen Zeilen aus dem Memory. Du kannst ein 50-Gigabyte-Logfile parsen, während deine Funktion in jeder beliebigen Millisekunde immer nur eine einzige Textzeile im Memory hält. Genau das gleiche Konzept funktioniert auch für Binary Files. Wenn du Text aus großen PDFs extrahierst, öffnest du die Datei im Binary Mode und übergibst den resultierenden Stream direkt an eine Python-PDF-Parsing-Library. Die Library liest den Byte-Stream sequenziell, ohne dass das gesamte Dokument im System-Memory liegen muss. SnowflakeFile kümmert sich auch automatisch um die Security Boundary. Wenn du eine dynamisch generierte Scoped URL an deine Funktion übergibst, gewährt Snowflake Read Access auf genau diese Datei, und zwar nur für die Dauer der Query. Dieser läuft sofort ab, wenn die Query beendet ist. Das Streamen dynamisch angegebener Dateien hält deinen Memory Footprint unabhängig von der Dateigröße flach. So kann sich dein Compute Warehouse komplett auf das Processing der Daten konzentrieren, anstatt nur zu versuchen, sie im Memory zu halten. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Snowflake & Snowpark Python, Folge 17 von 17. Du würdest niemals Backend-Application-Code ohne Unit-Tests deployen, warum werden Data-Pipelines dann so oft einfach auf gut Glück in Production gepusht? Snowpark ändert das, indem es deine Data-Logik modular macht. Dadurch kannst du sie endlich wie normale Software testen. Das Testen von Snowpark Python bringt die Disziplin des Software Engineerings ins Data Engineering. Mit Snowpark kannst du deine Transformation Logic aus monolithischen Skripten in standalone Python-Funktionen auslagern. Da diese Funktionen einen DataFrame als Input nehmen und einen DataFrame als Output zurückgeben, kannst du sie mit Standard-Python-Frameworks testen. PyTest ist die gängigste Wahl. Um Snowpark-Code auszuführen, brauchst du eine aktive Session. Anstatt Authentifizierungsdaten in jeden einzelnen Test einzubetten, definierst du eine Session-Fixture. Das machst du in einer dedizierten Konfigurationsdatei namens conftest.py, die von PyTest automatisch erkannt wird. In dieser Datei schreibst du eine Setup-Funktion, die eine Connection zu Snowflake herstellt, das Session-Objekt zurückgibt und die Session nach Abschluss der Tests schließt. Du dekorierst diese Funktion als PyTest-Fixture. Jetzt kann jeder Test in deinem Projekt eine aktive Session anfordern, indem er sie einfach über ihren Namen in den Argumenten der Testfunktion abfragt. Wenden wir das auf ein konkretes Szenario an. Du hast eine komplexe Custom-DataFrame-Transformation, die inaktive User herausfiltert, einen Risk-Score berechnet und Spaltennamen standardisiert. Du musst diese Logik validieren, bevor du die Pipeline in Production deployst. Du beginnst damit, einen Test zu schreiben. Der erste Schritt in diesem Test ist das Erstellen eines Input-DataFrames, der ein paar Zeilen sorgfältig ausgewählter Mock-Daten enthält. Du definierst die exakten Spaltennamen und Zeilenwerte, die nötig sind, um die spezifischen Edge Cases in deiner Logik zu triggern. Mithilfe deiner Session-Fixture konvertierst du diese rohen Mock-Daten in einen Snowpark DataFrame. Als Nächstes übergibst du diesen Mock-Input-DataFrame an deine Transformationsfunktion. Die Funktion wendet deine Business-Logik an und gibt den tatsächlichen Output-DataFrame zurück. Nun musst du verifizieren, dass die Logik genau das getan hat, was sie tun sollte. Du erstellst in deinem Test einen zweiten Mock-DataFrame, der diesmal das exakt erwartete Ergebnis repräsentiert. Das ist der entscheidende Punkt. Du musst den tatsächlichen DataFrame mit dem erwarteten DataFrame vergleichen. Du kannst jedoch nicht einfach einen Standard-Python-Equality-Check auf die DataFrame-Objekte selbst anwenden, da diese lediglich Referenzen auf Query Plans sind. Stattdessen musst du die Daten vergleichen, die sie enthalten. Du rufst die collect-Methode sowohl für den tatsächlichen als auch für den erwarteten DataFrame auf, um die Ergebnisse als Listen von Row-Objekten zurück in den Memory zu laden. Da verteilte Datenbanken die Reihenfolge von Result Sets nicht garantieren, sofern sie nicht explizit angewiesen werden, kann der direkte Vergleich zweier Listen von Rows fehlschlagen, selbst wenn die Daten korrekt sind. Um das zu beheben, sortierst du beide Listen von Rows, bevor du assertest, dass sie gleich sind. Wenn die sortierten tatsächlichen Daten mit den sortierten erwarteten Daten übereinstimmen, geht dein Test durch. Indem du kleine, kontrollierte Datensätze durch isolierte Transformationsfunktionen leitest, fängst du logische Fehler lokal ab, bevor sie jemals eine Production-Tabelle berühren. Das isoliert deine Pipeline-Komponenten und macht deinen Data-Engineering-Workflow so zuverlässig wie traditionelle Softwareentwicklung. Damit endet unsere Reihe zu Snowpark Python. Ich ermutige dich, die offizielle Snowflake-Dokumentation zu erkunden, diese Tests mal hands-on zu schreiben oder devstories.eu zu besuchen, um Themen für unsere zukünftigen Serien vorzuschlagen. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!