Python & SQL: Universalwerkzeuge für alle Datenangelegenheiten?

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.

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. 

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.

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.

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].