Über unsMediaKontaktImpressum
Harald Erb 24. Januar 2023

Python & SQL: Universalwerkzeuge für alle Datenangelegenheiten?

Python ist bekanntlich schon länger ein fester Bestandteil in der Toolbox von Data Scientists/Data Engineers und interessiert nun verstärkt auch andere Anwenderkreise, die bereits in der Vergangenheit Drag-and-drop- bzw. No-Code-Werkzeugen viel abverlangt und sich darüber hinaus in der Microsoft-Office-Welt an SQL sowie VBA-Programmierung herangewagt haben. Lohnt es sich also, dass Unternehmen zur Steigerung der Datenkompetenz ihrer Mitarbeiter, z. B. bei den sogenannten Power-Usern, neben fundierten Excel- und SQL-Kenntnissen künftig auch den Einsatz von Python für die Datenanalyse fördern?

Data Professionals sind ein kostbares Gut und in vielen Unternehmen übersteigen die täglichen Anforderungen die vorhandenen Ressourcen und die Kapazitäten der Daten-Teams. Gleichzeitig stoßen Datenanalysten an die Grenzen dessen, was Business-Intelligence-Tools für sie tun können und suchen nach Möglichkeiten, weiter fortgeschrittene Analysen durchzuführen. Die Anwendung von Python könnte hier der Schlüssel zum Erfolg sein, weil die Python-Community in den letzten Jahren neue Frameworks und Pakete entwickelt hat, die die Sprache für fortgeschrittene Analysen, Machine Learning und Applikationsentwicklung auch für nicht-professionelle Entwickler zugänglich macht. Populäre Beispiele dafür sind NumPy, eine Open-Source-Python-Bibliothek für numerische Daten [1], Prophet, eine von Facebooks Core-Data-Science-Team veröffentlichte Open-Source-Software für Vorhersagen [2] und H3, ein bei Uber begonnenes Projekt zur Bearbeitung von Geodaten [3].

Zur Beurteilung der Eingangsfrage betrachtet der Artikel drei mögliche Anwendungsbereiche, die man als Data Professional und Python-Neuling näher betrachten sollte:

  • SQL/Python in interaktiven Notebooks einsetzen – wie gut funktioniert diese Kombination? 
  • Programmierung mit Dataframes und verteiltes Prozessieren von Datentransformationen bei umfangreichen Datenbeständen – wie (gut) wird das von heutigen SQL-Datenbanken unterstützt und ist man noch auf einen zusätzlichen Spark-Cluster angewiesen?
  • Was leisten python-basierte Frameworks, wenn es "schnell" eine Idee zu validieren und dafür einen Prototypen zu bauen gilt, z. B. ein Dashboard mit Kommentarfunktion für die neue Umsatzprognose inklusive einer Ansicht zur Überwachung der Performance-Metriken des zugehörigen produktiven Machine-Learning-Modells?

SQL & Python in Notebooks verwenden

Die Verbreitung von Python bei nicht-professionellen Entwicklern ist nicht ohne Beispiel. Ähnlich verhielt es sich bereits mit Business-Analysten, die autodidaktisch lernten, ihre eigenen Excel-Makros zu programmieren. Und mit dem Aufkommen von Self-Service-BI-Tools entwickelt man in den Fachabteilungen wie selbstverständlich eigene Dashboards mit dynamischer Parametereingabe und erprobt fortgeschrittene Visualisierungs- und Storytelling-Techniken. In der nahen Zukunft wird es daher spannend zu beobachten sein, wie stark sich Python in diesen Anwenderkreisen verbreitet.

Aller Anfang ist schwer

Python als Programmiersprache für Datenanalysen wurde durch interaktive Umgebungen, wie z. B. Jupyter Notebooks (früher IPython Notebooks), noch attraktiver und ist im wissenschaftlichen Umfeld schon länger bekannt [4]. Diese web-basierten interaktiven Umgebungen bauen u. a. auf dem Kommandozeilen-Interpreter IPython auf und erlauben das Erstellen eines Jupyter-Notebook-Dokuments, das eine geordnete Liste von Eingabe- und Ausgabezellen enthält, um damit Code, einfachen und formatierten Text, Grafik-Plots und diverse Medienformate darzustellen. Während früher Wissenschaftler ihre Notizen, Zeichnungen und Messergebnisse in ihr Labor-Notizbuch gekritzelt haben, können heute auch Business-Analysten mit interaktiven Notebooks von der Fragestellung als Ausgangspunkt bis zum Ergebnis den gesamten Weg ihrer Analyse nachvollziehbar herleiten und dokumentieren. Reviews durch andere Teammitglieder oder gar die Reproduzierbarkeit der gewonnenen Ergebnisse sind nun im Vergleich zu einem fertigen BI-Dashboard viel einfacher möglich. Allerdings war der kombinierte Einsatz von Python und SQL innerhalb eines Notebook-Dokuments anfangs mühsam. Wie beispielhaft in Abb. 1 zu sehen ist, konnten in der Praxis eher nur vorab entwickelte und bereits getestete SQL-Abfragen in Python-Eingabezellen eingebettet und live gegen eine angebundene Datenbank ausgeführt werden. Längere und trotzdem einfach lesbare SQL-Anweisungen bekam man nur dann zu Gesicht, wenn jemand zusätzlich Zeit für deren Formatierung investiert hatte.

Polyglotte Notebooks

Komfortablere Notebook-Alternativen bieten mehr Flexibilität bei der Auswahl der zu verwendenden Kommandozeileninterpreter. Z. B. erlaubt das Konzept von Apache Zeppelin [5], beinahe jede beliebige Sprache oder jedes beliebige Datenverarbeitungs-Backend in die Zeppelin Notebook-Umgebung einzubinden. Derzeit unterstützt Zeppelin viele Interpreter wie Scala (mit Apache Spark), Python (mit Apache Spark), Spark SQL, Hive, JDBC, Markdown, Shell und so weiter – wahrscheinlich schon zu viel Auswahl für nicht-professionelle Entwickler. Einen Eindruck für den einfacheren kombinierten Einsatz von Python und SQL gibt Abb. 2: Hier wird z. B. in einem Notebook-Dokument Python als Standard-Programmiersprache festgelegt. Der Wechsel zum SQL-Interpreter erfolgt in jeder beliebigen Eingabezelle des Dokuments mit Aufruf des Magic Commands %sql und erlaubt so die Weiterarbeit mit ANSI SQL. Zusätzliche Programmierunterstützung bieten Syntax-Highlighting, Autovervollständigung und andere Komfortfunktionen, wie z. B. Datenvisualisierung mit gängigen Diagrammtypen (nicht abgebildet), die leicht konfigurierbar sind. 

Während auf "Werkzeugebene" der Wechsel zwischen Python und SQL nun stark vereinfacht erscheint, bleibt noch die Frage, wie die Übergabe von Zwischenergebnissen erfolgt, wenn ein Dataset schrittweise über mehrere Notebook-Zellen hinweg bzw. in verschiedenen Notebooks bearbeitet wird. Gängige Praxis ist in diesem Fall das Persistieren der Dataframe-Inhalte, z. B. durch Erzeugung von Parquet-Dateien in einem Filesystem (lokal, im Data Lake) und/oder Speicherung in einer Tabelle (externe Tabelle im Data Lake, gemanagte Tabelle im RDBMS) zur späteren Bereitstellung der Daten für nachfolgende Transformationen, Aggregationen etc.

Auf dem Weg zur nahtlosen Integration

Aus Sicht von Analysten wäre allerdings eine noch einfachere Datenübergabe wünschenswert. Hersteller analytischer Arbeitsumgebungen tragen solchen Anforderungen bereits Rechnung und machen ihre Notebook-Systeme in dieser Hinsicht komfortabler. Beispielsweise, indem in einer Notebook-Zelle die Ergebnismenge einer ausgeführten SQL-Abfrage automatisch in einem oder mehreren Dataframes abgespeichert wird. Als Datenanalyst bekommt man damit in beliebig nachfolgenden Notebook-Zellen direkten Zugriff auf bereits gewonnene Zwischenergebnisse und arbeitet unterbrechungsfrei weiter. Die Vorteile liegen auf der Hand: allgemeine Zeitersparnis und man kann sich unmittelbar dem nächsten Analyseschritt widmen. Abb. 3 illustriert beispielhaft mögliche Optionen: In einer sog. "SQL-Zelle" eines Hex-Notebooks wählt ein Analyst eine (vorher eingerichtete) Datenbankverbindung und führt eine SQL-Abfrage aus [6]. Das von der Datenbank zurückgegebene Ergebnis könnte nun entweder in demselben Notebook mit einer anderen SQL-Zelle verknüpft oder, wie in diesem Fall, automatisch als Dataframe query_result_6 gespeichert werden. Im weiteren Verlauf findet der Inhalt von Dataframe query_result_6 in einer vom Hex Notebook-System bereitgestellten Visualisierungskomponente Verwendung (Balkendiagramm in Abb. 3) und wird später ein weiteres Mal in einer Python-Zelle verwendet. Da in Hex Dataframe-Objekte auf Basis der Pandas Softwarebibliothek zum Einsatz kommen, können Analysten in einer Python-Zelle unmittelbar weitere Datenmanipulationen und Analyseschritte vornehmen [7]. Und es funktioniert auch der Rückweg, d. h. das Ergebnis-Dataframe einer Python-Zelle lässt sich in einer im Notebook nachfolgenden SQL-Zelle ebenfalls referenzieren und mittels SQL-Anweisung abfragen. Im Hintergrund prozessiert Hex Dataframe-SQL-Abfragen mit Hilfe von DuckDB, einer prozessintegrierten SQL-OLAP-Datenbank [8]. Die SQL-Syntax ist dabei der von PostgreSQL sehr ähnlich und erfordert also keine besonderen Kenntnisse.

Python – der erweiterte Analysten-Werkzeugkasten im Einsatz

Die Möglichkeit, Notebook-Zellen zu verketten und dabei zwischen SQL und Python wechseln zu können, gibt Analysten nun die Freiheit, zu entscheiden, wann welches Werkzeug zum Zuge kommt. "Das beste Tool für die jeweilige Teilaufgabe" sollte dabei die Devise sein. Wie bei Business-Intelligence-Werkzeugen auch, ist der Einsatz von Standardkomponenten jederzeit vorzuziehen, wie z. B. bei der Datenvisualisierung. Wenn sich also mit den Bordmitteln eines Notebooks einfach und zufriedenstellend ein lesbares Balkendiagramm erstellen lässt, muss man für diesen Zweck nicht unbedingt Python-Code schreiben. Gehen die Analyseanforderungen einmal darüber hinaus oder ist der Einsatz spezieller Algorithmen vorgesehen, ist ein Griff in den erweiterten Werkzeugkasten – namens Python – vermutlich die Lösung. Als Fortsetzung des in Abb. 3 begonnenen Analysewegs veranschaulicht Abb. 4 den weiteren Fortgang. Im Rahmen der explorativen Datenanalyse kam zum Beispiel für die Erzeugung eines Boxplot-Diagramms die Datenvisualisierungsbibliothek Seaborn in einer Python-Zelle zum Einsatz [9]. Mit den vom Hersteller bereitgestellten Standard-Diagrammtypen wäre diese Darstellung wahrscheinlich gar nicht oder nur mit Tricks möglich gewesen.

Betritt man als Business-Analyst die Welt des maschinellen Lernens, so zeigt sich schnell die Mächtigkeit von Python als Programmiersprache und des zugehörigen Ecosystems mit seiner großen Auswahl an Softwarebibliotheken. Abb. 4 zeigt exemplarisch, wie im weiteren Verlauf mit den anfangs schon erwähnten Bibliotheken Pandas, NumPy und matplotlib Zeitreihen visualisiert und ein Dataset für das anschließende ML-Modell-Training mit der Bibliothek Prophet präpariert werden. Diese Art von Aufgaben lässt sich mit ein paar Codezeilen sehr effektiv umsetzen und macht den komplementären Anwendungsbereich von Python im Vergleich zu SQL deutlich.

Handle (Notebooks) with care

Aber es ist auch Vorsicht geboten: Trotz aller Kommentar- und Formatierungsfunktionen können Notebooks irgendwann doch zu unübersichtlich geraten, wenn sie beispielsweise zu viele Code-Zellen enthalten oder in einer Python-Zelle zu viele Teilschritte ausgeführt werden. Die eingeschränkte Modularität ist bei Notebooks generell ein Nachteil, dem erfahrene ETL-Entwickler und Data Engineers mit Auslagerung wiederverwendbarer Code-Teile in separate Python-Dateien begegnen. Bei der Anlage eines neuen Notebooks erfolgt typischerweise zu Beginn der Import dieser Hilfsdateien mit den gesammelten nützlichen Hilfsfunktionen, so dass ein Mindestmaß an Code-Standardisierung und damit Zeitersparnis für alle Beteiligten realisierbar ist. Und auch bei Notebooks spielen Qualitätssicherung, Versionierung, Zugriffssicherheit etc. eine zunehmend wichtigere Rolle, je unternehmenskritischer sie werden – genauso wie bei offiziellen Standardreports, Pflichtmeldungen, bedeutenden Data-Pipelines usw. Am Ende gilt auch hier für jede Organisation, die richtige Balance zwischen agilen Datenexperimenten und Produktivbetrieb bei dem Einsatz dieser Technologie zu finden.

Dataframe-style-Coding mit analytischen SQL-Datenbanken

Wie in den vorangegangenen Notebook-Beispielen bereits gezeigt, können Datenanalysten bei ihrer Arbeit mit einem Notebook-Client – genau wie mit jedem anderen SQL-Editor – eigene SQL-Abfragen direkt gegen eine leistungsfähige Datenbank ausführen und damit sehr große Datenbestände analysieren oder auch verändern. Für interaktive Datenanalysen mit Python wurde im vorherigen Abschnitt bereits Pandas erwähnt, eine der meistgenutzten Open-Source-Bibliotheken für Python, die aufgrund intuitiver Datenstruktur und umfangreicher APIs zum De-facto-Standard für Datenanalysten und im Bereich Data Science geworden ist. Pandas nutzt In-Memory-Verarbeitung und ist ideal für kleine bis mittelgroße Datenmengen (niedriger Gigabyte-Bereich). Die Fähigkeit von Pandas, große Datenmengen zu verarbeiten, ist jedoch aufgrund von Out-of-Memory-Fehlern eingeschränkt. Abb. 5 gibt eine solche Situation wieder, die im Rahmen einer Simulation mit einem Jupyter-Notebook (Python-Kernel) entstanden ist.

SQL und Python mit einem leistungsfähigen Server-Backend nutzen

Die Motivation für den Einsatz von leistungsstarken Server-Backends hat sich grundsätzlich nicht verändert: Die Verarbeitungszeiten für Datentransformationen, Aggregationen, Kundensegmentierung etc. dauern zu lange oder sind aufgrund zu hohen Datenvolumens überhaupt nicht möglich. Während für die Verarbeitung von SQL-basierten Jobs in der Regel eine analytische Datenbank zur Verfügung steht, muss dagegen für Python/Pandas eine Alternative gefunden werden, die z. B. eine vergleichbare Nutzererfahrung für die Arbeit mit Dataframes bietet. Zu Pandas gibt es eine Reihe von Alternativen, eine davon ist Apache Spark, eine andere könnte die im Einsatz befindliche Data-Warehouse-Datenbank sein, sofern diese über eine entsprechende Client-API für Python verfügt.

Im Umfeld dateibasierter Data Lakes war und ist bis heute noch Apache Spark als Compute Engine für verteiltes Rechnen Bestandteil sog. "Big-Data-Plattformen". Zu typischen Spark-Anwendungsfällen gehören dabei die Aufbereitung bzw. Analyse großer Datenmengen, bei denen das zu prozessierende Dataset auf alle zugehörigen Rechnerknoten eines Spark Compute Clusters verteilt und parallel verarbeitet wird. Die Verbindung zu Python stellt PySpark als Schnittstelle zu Apache Spark her [10]. PySpark eignet sich gut für die Verarbeitung großer Datenmengen, das Erlernen der neuen PySpark-Syntax und das Refactoring des Codes von Pandas zu PySpark kann aber etwas mühsam sein. Abhilfe ist hier aber in Sicht: Mit Spark-Version 3.2 und höher steht die Pandas-API für Spark zur Verfügung und ermöglicht damit verteiltes Prozessieren mit Spark bei gleichzeitiger Nutzung der vertrauten Pandas-Syntax [11].

Könnte man Kapazität und Rechenleistung der schon vorhandenen Data-Warehouse-Datenbank nutzen und trotzdem, abhängig von der Art der Aufgabenstellung, mit SQL und Python sowie dem Werkzeug der Wahl (Notebook oder einer anderen integrierten Entwicklungsumgebung) arbeiten, hätte dies einige Vorteile:

  • Nahe an den Daten arbeiten: Der Datentransfer zwischen Clients und Backend könnte stark reduziert bzw. ganz eliminiert werden – damit sinken Aufwände für Verwaltung und Synchronisierung von lokalen Datenkopien.
  • Datenbank-Performance nutzen: Ressourcenintensive Operationen wie Sortieren, Aggregieren, Filtern, Umkodieren und Sampling von sehr großen Datenbeständen übernimmt der Server. Beruht das Data-Warehouse-System auf einer cloud-nativen Architektur, ist im Bedarfsfall "Performance-on-Demand" beziehbar – Elastizität, Skalierbarkeit und sekundengenaue Abrechnungsmodelle mancher Anbieter erlauben schon heute Ad-hoc-Einsätze dieser Art zu bezahlbaren Preisen.
  • Data Freshness: Aktualisierte Datenbestände sind im Data Warehouse gleichermaßen für SQL- und Python-Datenanalysen und -entwickler sofort verfügbar.
  • Sicherheit und Data Governance: Ist mit vorhandenen Datenbankfunktionen (z. B. feingranulare Role Based Access Controls, Data Masking, zeilen-/spaltenbasierte Filter) leichter beherrschbar und auditierbar.

Im vorangegangenen Abschnitt wurde schon die beschränkte Verwaltung von wiederverwendbaren Code-Modulen, standardisierten Hilfsfunktionen etc. angesprochen. Entsprechend leitet sich daraus für Datenbanksysteme die Forderung ab, wiederverwendbaren Python-Code serverseitig ausführen zu können. Beispielsweise in Form von benutzerdefinierten Funktionen (UDFs) oder Stored Procedures, die idealerweise mit SQL aufrufbar sind. Damit wäre eine End-to-end-Datenverarbeitung bis hin zum Trainieren und produktiver Nutzung python-basierter Machine-Learning-Modelle innerhalb der Datenbank möglich.

Ein Implementierungsbeispiel: Die Snowpark-API (Python)

Snowflake ist eine nahezu tuningsfreie und wartungsfreie Datenplattform, die als Software-as-a-Service (SaaS) bereitgestellt wird und nicht auf bekannten Datenbanktechnologien wie PostgreSQL oder Big-Data-Softwareplattformen wie Hadoop basiert. Stattdessen kombiniert sie eine von Grund auf neu entwickelte SQL-Query-Engine [12] mit einer cloud-nativen Architektur und bietet mit einer einzigen Plattform die Möglichkeit, sowohl moderne Data-Warehouse-Implementierungen als auch Data-Lake- bzw. Machine-Learning-Anwendungsfälle und datenintensive Applikationen umzusetzen und zu betreiben. Aus Anwendersicht stellt sie die für den unternehmensweiten Einsatz benötigten Funktionen einer analytischen Datenbank sowie zahlreiche Serverless Features bereit, die das Datenmanagement insgesamt vereinfachen helfen.

Mit Blick auf die Kombination von SQL und Python lässt sich Snowflake folgendermaßen einordnen:

  • SQL-Unterstützung: By Design kann Snowflake zu 100 Prozent via SQL bedient werden und bietet eine umfassende Unterstützung für ANSI SQL, ACID-Transaktionen sowie SQL-Erweiterungen für das Traversieren, Flattening und die Handhabung semistrukturierter Daten. 
  • Extensibility Framework: Snowpark wird als Erweiterung eingeführt, um eine polyglotte Plattform zu schaffen, um die Lücke zwischen Data Engineers, Data Scientists, Anwendungsentwicklern und den MLOps- und DevOps-Teams, die sie unterstützen, zu schließen [13]. Im Kern geht es bei Snowpark darum, dass alle Beteiligten die Programmiersprache und die Tools ihrer Wahl nutzen, ohne dabei auf vertraute Programmierkonstrukte wie Dataframes verzichten zu müssen.

Näher betrachtet, bietet die Snowpark-Bibliothek eine API für Datenabfragen und -verarbeitung für Scala, Python und Java an, um die Daten an Ort und Stelle in dem von Snowflake verwalteten Cloud-Storage-Layer mit der eigenen SQL-Compute-Engine prozessieren zu können.

Für Python als favorisierte Sprache für Data-Science- und Machine-Learning-Workloads stellt Snowflake mit Snowpark eine Pandas und PySpark ähnliche API zur Datenbearbeitung bereit. Während früher ausschließlich Snowflake’s Connector für Python in Notebooks und andere Entwicklungsumgebungen integrierbar war und Datenanalysten darüber nur voll ausformulierte SQL-Abfragen zur serverseitigen Verarbeitung zu Snowflake schicken konnten, macht die clientseitige Snowpark-Dataframe-API insgesamt den Entwicklungs-/Analyseablauf interaktiver, erlaubt lesbareren Code zu schreiben und vereinfacht das Debugging. Abb. 6 zeigt das Prinzip, wie mit der Snowpark-Client-API (z. B. mit einem Notebook genutzt) eine Dataframe-Operation in eine korrespondierende SQL-Anweisung übersetzt und diese via Push-Down in der Snowflake-Datenbank ausgeführt wird. Die Ausführung aller Snowpark-Operationen findet im sog. "Lazy-Modus" statt und reduziert auf diesem Weg die zu übertragende Datenmenge zwischen Anwender-Client und dem Snowflake-Backend.

Schließlich stellt sich die Frage, ob sich überhaupt der Einsatz einer Datenbank für die Arbeit mit Python lohnt. Überzeugende Ergebnisse liefern z. B. typische Aufgaben im Data Engineering, wenn es gilt, einen Datensatz für ein ML-Modell-Training vorzubereiten. Der Code-Ausschnitt in Abb. 7 wendet zu Illustrationszwecken eine "Missing-Data"-Technik an und vervollständigt ein Dataset mit 1 Mrd. Datenzeilen mit einer Snowpark-Dataframe-Operation, die eine Imputation für alle fehlenden numerischen Datenpunkte ausführt. Auf einem handelsüblichen Laptop mit 16 GB Hauptspeicher war eine vergleichbare Operation mit einer lokal installierten Python-Laufzeitumgebung nicht ausführbar, in Snowflake konnte diese Aufgabe dagegen mit einem XXL-dimensionierten Warehouse (Compute Engine) in deutlich weniger als einer Minute erledigt und das vervollständigte Dataset in einer neuen Tabelle abgespeichert werden. Ähnlich typische Feature-Engineering-Operationen, wie "One-Hot-Encoding" oder Datennormierung funktionierten gleich gut.

Snowpark ist aber mehr als eine schönere Art, Abfragen zu schreiben. Eigene Python-Programmlogik lässt sich als benutzerdefinierte Funktion (UDF) deklarieren und dann in Dataframe-Operationen verwenden. Für die serverseitige Ausführung der UDF kümmert sich die Snowpark-Client-API um die Serialisierung des benutzerdefinierten Codes und überträgt die gesamte Logik nach Snowflake, so dass der zugehörige Python-Bytecode in einer abgesicherten Python-Sandbox (Laufzeitumgebung) gehostet wird, die eng in die Snowflake-Query-Engine integriert ist. Auf ähnliche Weise lassen sich in Snowflake auch benutzerdefinierte Tabellenfunktionen (UDTF) und Stored Procedures erstellen und damit z. B. ein vollständiger Machine-Learning-Workflow mit State-of-the-Art-Python-ML-Bibliotheken umsetzen [14].

Hohe Entwicklungsflexibilität bringt auch viel Verantwortung mit sich: So gibt es eine Reihe von Best Practices rund um die Verwaltung der für ein Python-Projekt erforderlichen Python-Pakete inklusive ihrer Paketabhängigkeiten untereinander. Anaconda, eine Distribution für Python (und R), ist hier hilfreich, denn es vereinfacht die Paketverwaltung und -bereitstellung erheblich [15]. Mit Snowpark für Python installiert Snowflake vorab die beliebtesten Python-Pakete aus dem Anaconda-Standard-Channel (abrufbar über den dedizierten Anaconda-Snowflake-Channel [16]) in der Snowflake-Python-Laufzeitumgebung und nutzt zudem den integrierten Conda-Paketmanager, um die Abhängigkeiten der Python-Pakete untereinander zu verwalten. Und wie bei jedem Datenprojekt auch, spielen Sicherheits- und Governance-Themen eine wichtige Rolle: Aktuell verbieten die mit Snowpark in der Snowflake Processing Engine eingesetzten Python-Laufzeitumgebungen standardmäßig den externen Netzwerkzugriff, um gängigen Sicherheitsbedenken wie der Datenexfiltration entgegenzuwirken. Alles in allem dürfte für Python-Neulinge die Bedienung einer vorkonfigurierten und sicheren Python-Laufzeitumgebung deutlich einfacher sein als die Erstellung und Verwaltung eigener Container mit einem entsprechend abgestimmten Python-Setup, bei dem man sich selbst um Absicherung, Upgrades, etc. kümmern muss.

Python-basierte Frameworks für Business-Applikationen

Fachanwender wissen oft sehr genau, manchmal auch besser als professionelle Entwickler, welche Erkenntnisse für ihre Geschäftsbereiche am hilfreichsten sind und wie diese im Alltag am besten genutzt werden können. Bietet man den – zu Anfang dieses Artikels schon thematisierten – sog. Power-Usern einer Fachabteilung nun Möglichkeiten zum schnellen Prototyping oder zum Bauen einfacher datengetriebener Applikationen an, so könnte dies der schnellste Weg hin zur gebrauchstauglichen Umsetzung analytischer Use Cases sein. Der Bedarf an Plattformen oder Frameworks zur schnellen Applikationsentwicklung (Rapid Application Development, RAD) ist schon seit vielen Jahren vorhanden, Abb. 8 zeigt dazu eine Auswahl für bekannte Technologien und unterschiedliche Programmiersprachen.

Im Datenbankumfeld gibt es mit Oracle Application Express (kurz: Oracle APEX) bereits seit ca. 2004 eine Plattform, die Oracle (seit kurzem) der Low-Code-Anwendungsentwicklung zuordnet [17]. Im Kern ermöglicht Oracle APEX die einfache Entwicklung und Bereitstellung von Webanwendungen ohne Code mit der Oracle-Datenbank. Stellen sich Anforderungen komplexer dar, ist in Oracle APEX die Erweiterung der Low-Code-Objekte über ein deklaratives Framework möglich. Mit diesem Framework können Entwickler eigene Geschäftslogik definieren und entsprechend erweiterte Benutzeroberflächen erstellen. Der APEX-Werkzeugkasten reicht dabei von SQL, PL/SQL, HTML, JavaScript oder CSS bis hin zur Integration von APEX-Plug-ins. APEX ermöglicht also, je nach Bedarf und Kenntnissen, von No-Code über Low-Code bis hin zu Pro-Code zu gehen.

Während Oracle APEX universell für operative als auch analytische Anwendungsfälle einsetzbar ist, greifen  Datenanalysten und Data Scientists, die R als Programmiersprache für statistische Berechnungen und Grafikerstellung präferieren, für ihre prototypischen Anwendungen eher auf das Shiny-Framework von RStudio zurück [18]. Ziel ist dabei, die eigenen Arbeitsergebnisse mit nichttechnischen Kollegen zu teilen, damit diese über eine Webanwendung z. B. ein Machine-Learning-Modell bedienen, einen Forecast neu ausführen bzw. Berechnungen samt zugehöriger Visualisierung aktualisieren können. Technisch gesehen ist Shiny ein R-Paket, mit dem sich interaktive Webanwendungen direkt aus R-Code heraus erstellen lassen. Die funktionale "Anreicherung" des R-Codes ist mit CSS-Themes, HTML-Widgets und JavaScript-Actions optional möglich. Der Einsatz ist dabei flexibel wählbar, z. B. als eigenständige bereitgestellte Webanwendung, als Dashboard oder eingebettet in ein R-Markdown-Dokument.

Die Programmiersprache Python steht hier eher noch am Anfang, doch es ist zu erwarten, dass im Laufe der Zeit vermehrt python-basierte Werkzeuge und Frameworks speziell für nicht-professionelle Entwickler entstehen werden. Im Data-Science-Umfeld gibt es allerdings schon einige Frameworks wie plotly Dash, Kivy, Django und daneben gewinnt auch Streamlit an Popularität [19]. Streamlit ist eine python-basierte Open-Source-Softwarebibliothek und ermöglicht es, ähnlich wie bei Shiny für R, sehr schnell Webanwendungen zu erstellen und für Browser und mobile Endgeräte bereitzustellen. Eine Streamlit-App kann, z. B. wie in Abb. 9 gestaltet, dabei auch direkt mit einer angebundenen Datenbank interagieren und SQL-Abfragen auf großen Datenbeständen ausführen lassen [20].

Schlussbetrachtung: SQL + Python = eine starke Kombination

SQL-Kenntnisse sind seit Jahren bei Datenanalysten in Unternehmen und anderen Organisationen weit verbreitet und gehören auch heute zum Repertoire von Data Scientists, auch wenn sie bei der Auswahl von Werkzeugen und Programmiersprachen flexibel sind und gerne auf Python zurückgreifen. Zahlreiche moderne Softwarebibliotheken, neue Werkzeuge, robuste und sichere Integrationsmöglichkeiten mit Datenbanken/Datenplattformen zeigen das Einsatzpotential von Python im Bereich Datenanalyse und Massendatenverarbeitung deutlich auf.

In diesem Artikel wurden verschiedene Anwendungsbereiche besprochen, bei denen SQL und Python zusammengenommen als universell einsetzbare Werkzeuge sehr viel erreichen können und auch der Zugang für Python-Neulinge lohnend sein sollte:

  • Reproduzierbare Datenexperimente: Motivation und Ansatzpunkt ist hier, die Datenkompetenz von Datenanalysten und sonstigen interessierten Power-Usern, den Umgang mit SQL zu stärken und um die Anwendung von Python zu erweitern. Denkbar begleitende Maßnahmen wären die Vermittlung von Methodenwissen, z. B. zu Storytelling oder zur Durchführung von Datenexperimenten (Analyse -> Hypothese -> Design von Experimenten -> erforderliche Daten sammeln -> Evaluation).
  • Dataframe-style-Coding & Data Engineering mit Datenbanken (ohne Spark-Cluster): Idee/Ziel ist, die verfügbare Performance/Skalierbarkeit von Datenbanksystemen und Datenplattformen zu nutzen, die einen Transparency Layer oder Bibliotheken für clientseitig erzeugten Python-Code anbieten, der per "SQL-Pushdown" auf dem Server ausgeführt wird. Ist dies der Fall und Data Engineers können trotzdem mit einer Pandas- und PySpark-ähnlichen API ihre Aufgaben erledigen, sind auf der administrativen Seite Personalaufwände durch verringerte Infrastrukturkomplexität und vereinfachte Governance erzielbar.
  • Applikationsentwicklung/-prototyping: In funktionsübergreifenden Teams versucht man neben den technischen Mitgliedern (IT-Entwicklung und -Betrieb, intern/extern Beschäftigte) auch die Teammitglieder von der Fachseite verstärkt in den Wertschöpfungsprozess einzubeziehen. Dabei geht es oft auch um die schnellere Konkretisierung und Validierung neuer (technischer) Ideen, Innovationen, Analyse-Konzepte, etc. durch "Proof-of-Value-Applikationen" oder um die gemeinschaftliche Entwicklung komplexer Dashboards anstelle umfangreicher und oft zu theoretischer Anforderungskataloge. Entsprechend sollten Fachseite und IT zusammenarbeiten und eine eventuell gewachsene Schatten-IT in eine Quelle der Innovation und Dynamik verwandeln, die No-Code-, Low-Code- und Pro-Code-Ansätze gleichermaßen unterstützt [21].

Das Thema dieses Artikels behandelt einen Aspekt, den man mit Datenkompetenz im Allgemeinen in Verbindung bringen kann. Eine offene Unternehmenskultur statt Elitewissen sowie eine moderne und reaktionsschnelle Datenarchitektur unterstützen den effektiven Einsatz von SQL und Python bei (nahezu) allen Datenangelegenheiten – automatisch funktioniert es allerdings nicht. Zur Datenkompetenz gehört auch generelles Know-how, wie man zu Beginn der Wertschöpfungskette Daten richtig erfasst und sammelt, sowie eine Beurteilung über die Vertrauenswürdigkeit der Datenquelle. Je nach Datenqualität sind in der nachfolgenden Verarbeitungsphase geeignete Verfahren zur Datenauswahl, -speicherung, -bereinigung usw. anzuwenden, ineffizientes Datenmanagement kann dagegen hohe Mehraufwände und damit Zusatzkosten verursachen. Auf dem Weg zu vertrauenswürdigen Erkenntnissen oder messbar erfolgreichen Datenprodukten sind noch viele Dinge zu beachten, die neben Technik und neuen Programmiersprachen zu erlernen sind.

Autor

Harald Erb

Harald Erb arbeitet als Sales Engineer für Snowflake Computing und unterstützt Unternehmen bei der Einführung ihres elastischen Cloud-Data Warehouses.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben