SQL für die Datenanalyse

Kapitel 1. Analyse mit SQL

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Wenn du dieses Buch liest, interessierst du dich wahrscheinlich für die Datenanalyse und die Verwendung von SQL, um sie durchzuführen. Vielleicht kennst du dich mit Datenanalyse aus, bist aber neu in SQL, oder du kennst dich mit SQL aus, bist aber neu in der Datenanalyse. Oder du bist in beiden Bereichen völlig neu. Was auch immer dein Ausgangspunkt ist, dieses Kapitel legt den Grundstein für die Themen, die im Rest des Buches behandelt werden, und stellt sicher, dass wir ein gemeinsames Vokabular haben. Ich beginne mit einer Diskussion darüber, was Datenanalyse ist, und gehe dann auf SQL ein: was es ist, warum es so beliebt ist, wie es im Vergleich zu anderen Tools aussieht und wie es in die Datenanalyse passt. Da die moderne Datenanalyse so eng mit den Technologien verbunden ist, die sie ermöglichen, werde ich abschließend auf die verschiedenen Arten von Datenbanken eingehen, denen du bei deiner Arbeit begegnen könntest, und erläutern, warum sie verwendet werden und was das alles für das SQL bedeutet, das du schreibst.

Was ist Datenanalyse?

Das Sammeln und Speichern von Daten zur Analyse ist eine sehr menschliche Tätigkeit. Systeme zur Überwachung von Getreidevorräten, Steuern und der Bevölkerung gibt es schon seit Tausenden von Jahren, und die Wurzeln der Statistik reichen Hunderte von Jahren zurück. Verwandte Disziplinen wie statistische Prozesskontrolle, Operations Research und Kybernetik entwickelten sich im 20. Es gibt viele verschiedene Bezeichnungen für die Disziplin der Datenanalyse, z. B. Business Intelligence (BI), Analytics, Data Science und Decision Science, und die Praktiker haben eine Reihe von Berufsbezeichnungen. Datenanalyse wird auch von Marketingfachleuten, Produktmanagern, Geschäftsanalysten und einer Vielzahl anderer Personen durchgeführt. In diesem Buch verwende ich die Begriffe Datenanalyst/in und Datenwissenschaftler/in synonym für die Person, die mit SQL arbeitet, um Daten zu verstehen. Die Software, mit der Berichte und Dashboards erstellt werden, bezeichne ich als BI-Tools.

Die Datenanalyse im heutigen Sinne wurde durch die Geschichte der Computertechnik ermöglicht und ist mit ihr verwoben. Sie wurde sowohl von der Forschung als auch von der Kommerzialisierung geprägt und umfasst ein "Who is Who" von Forschern und großen Unternehmen, über die wir im Abschnitt über SQL sprechen werden. Die Datenanalyse verbindet die Leistungsfähigkeit der Informatik mit Techniken aus der traditionellen Statistik. Datenanalyse ist teils Datenermittlung, teils Dateninterpretation und teils Datenkommunikation. Sehr oft dient die Datenanalyse dazu, die Entscheidungsfindung zu verbessern, sowohl bei Menschen als auch zunehmend bei Maschinen durch Automatisierung.

Eine solide Methodik ist entscheidend, aber bei der Analyse geht es um mehr als nur um die richtige Zahl. Es geht um Neugier, das Stellen von Fragen und das "Warum" hinter den Zahlen. Es geht um Muster und Anomalien, um die Entdeckung und Interpretation von Hinweisen darauf, wie sich Unternehmen und Menschen verhalten. Manchmal wird ein Datensatz analysiert, der zur Beantwortung einer bestimmten Frage erhoben wurde, z. B. in einem wissenschaftlichen Umfeld oder bei einem Online-Experiment. Analysiert werden auch Daten, die im Rahmen der Geschäftstätigkeit anfallen, z. B. beim Verkauf von Unternehmensprodukten, oder die zu Analysezwecken erhoben werden, z. B. bei der Nachverfolgung von Benutzerinteraktionen auf Websites und mobilen Apps. Für diese Daten gibt es eine Vielzahl von Anwendungsmöglichkeiten, von der Fehlersuche bis zur Planung von Verbesserungen der Benutzeroberfläche (UI), aber sie kommen oft in einem Format und in einer Menge an, dass die Daten verarbeitet werden müssen, bevor sie Antworten liefern. In Kapitel 2 geht es um die Vorbereitung der Daten für die Analyse, und in Kapitel 8 werden einige ethische und datenschutzrechtliche Fragen erörtert, mit denen alle Datenpraktiker/innen vertraut sein sollten.

Es gibt kaum eine Branche, die nicht von der Datenanalyse berührt wurde: Produktion, Einzelhandel, Finanzwesen, Gesundheitswesen, Bildung und sogar die Regierung haben sich durch sie verändert. Sportmannschaften nutzen Datenanalysen seit den frühen Jahren von Billy Beane als General Manager der Oakland Athletics, der durch Michael Lewis' Buch Moneyball (Norton) berühmt wurde. Die Datenanalyse wird im Marketing, im Vertrieb, in der Logistik, in der Produktentwicklung, im User Experience Design, in Support Centern, im Personalwesen und vielen anderen Bereichen eingesetzt. Die Kombination von Techniken, Anwendungen und Rechenleistung hat zu einer explosionsartigen Entwicklung verwandter Bereiche wie Data Engineering und Data Science geführt.

Die Datenanalyse erfolgt per Definition auf der Grundlage historischer Daten, und es ist wichtig, sich daran zu erinnern, dass die Vergangenheit nicht unbedingt die Zukunft vorhersagt. Die Welt ist dynamisch, und auch Unternehmen sind dynamisch - neue Produkte und Prozesse werden eingeführt, Konkurrenten steigen und fallen, das gesellschaftspolitische Klima ändert sich. Es wird kritisiert, dass Datenanalysen rückwärtsgewandt sind. Das stimmt zwar, aber ich habe erlebt, dass Unternehmen aus der Analyse historischer Daten einen enormen Nutzen ziehen. Die Auswertung historischer Daten hilft uns, die Eigenschaften und das Verhalten von Kunden, Lieferanten und Prozessen zu verstehen. Historische Daten können uns helfen, fundierte Schätzungen und Prognosen zu erstellen, die manchmal falsch, aber oft richtig sind. Vergangene Daten können Lücken, Schwächen und Chancen aufzeigen. Sie ermöglichen es den Unternehmen, zu optimieren, Geld zu sparen und Risiken und Betrug zu verringern. Sie können Unternehmen auch dabei helfen, Chancen zu erkennen, und sie können die Bausteine für neue Produkte sein, die Kunden begeistern.

Hinweis

Heutzutage gibt es nur noch wenige Unternehmen, die keine Datenanalyse durchführen, aber es gibt immer noch einige Ausreißer. Warum nutzen manche Organisationen keine Datenanalyse? Ein Argument ist das Kosten-Nutzen-Verhältnis. Das Sammeln, Verarbeiten und Analysieren von Daten erfordert Arbeit und ein gewisses Maß an finanziellen Investitionen. Manche Organisationen sind zu neu oder zu unüberlegt. Wenn es keinen einheitlichen Prozess gibt, ist es schwer, Daten zu generieren, die konsistent genug sind, um sie zu analysieren. Schließlich gibt es auch ethische Überlegungen. Das Sammeln oder Speichern von Daten über bestimmte Personen in bestimmten Situationen kann geregelt oder sogar verboten sein. Daten über Kinder und Maßnahmen im Gesundheitswesen sind zum Beispiel sensibel, und es gibt umfangreiche Vorschriften für ihre Erhebung. Selbst Unternehmen, die ansonsten datenorientiert arbeiten, müssen auf den Schutz der Kundendaten achten und sich genau überlegen, welche Daten gesammelt werden sollen, wozu sie gebraucht werden und wie lange sie gespeichert werden sollen. Verordnungen wie die Allgemeine Datenschutzverordnung der Europäischen Union (GDPR) und der California Consumer Privacy Act (CCPA) haben die Art und Weise verändert, wie Unternehmen über Verbraucherdaten denken. Wir werden diese Verordnungen in Kapitel 8 ausführlicher behandeln. Als Datenexperten sollten wir uns immer Gedanken über die ethischen Auswirkungen unserer Arbeit machen.

Wenn ich mit Organisationen zusammenarbeite, sage ich gerne, dass Datenanalyse kein Projekt ist, das zu einem bestimmten Zeitpunkt abgeschlossen wird - es ist eine Lebenseinstellung. Die Entwicklung einer datengestützten Denkweise ist ein Prozess, und die Früchte zu ernten ist eine Reise. Unbekanntes wird bekannt, schwierige Fragen werden so lange bearbeitet, bis es Antworten gibt, und die wichtigsten Informationen werden in Dashboards eingebettet, die taktische und strategische Entscheidungen unterstützen. Mit diesen Informationen werden neue und schwierigere Fragen gestellt, und dann wiederholt sich der Prozess.

Die Datenanalyse ist sowohl für Einsteiger/innen zugänglich als auch schwer zu meistern. Die Technologie kann erlernt werden, insbesondere SQL. Viele Probleme, wie die Optimierung von Marketingausgaben oder die Aufdeckung von Betrug, sind bekannt und lassen sich auf alle Unternehmen übertragen. Jedes Unternehmen ist anders und jeder Datensatz hat seine Eigenheiten, so dass selbst vertraute Probleme neue Herausforderungen mit sich bringen können. Ergebnisse zu kommunizieren ist eine Kunst. Es braucht Zeit, bis man lernt, gute Empfehlungen auszusprechen und ein vertrauenswürdiger Partner für ein Unternehmen zu werden. Meiner Erfahrung nach haben einfache Analysen, die überzeugend präsentiert werden, mehr Wirkung als komplizierte Analysen, die schlecht präsentiert werden. Eine erfolgreiche Datenanalyse erfordert auch eine Partnerschaft. Du kannst großartige Erkenntnisse haben, aber wenn es niemanden gibt, der sie umsetzt, hast du nicht wirklich etwas erreicht. Trotz all der Technologie geht es immer noch um Menschen, und Beziehungen sind wichtig.

Warum SQL?

In diesem Abschnitt wird beschrieben, was SQL ist, welche Vorteile es hat, wie es im Vergleich zu anderen Analysesprachen aussieht und wie SQL in den Analyse-Workflow passt.

Was ist SQL?

SQL ist die Sprache, die für die Kommunikation mit Datenbanken verwendet wird. Das Akronym steht für Structured Query Language und wird entweder wie "Folge" oder durch Aussprechen der einzelnen Buchstaben ausgesprochen, z. B. "ess cue el". Das ist nur die erste von vielen Kontroversen und Ungereimtheiten rund um SQL, die wir sehen werden, aber die meisten Leute werden wissen, was du meinst, egal wie du es aussprichst. Es gibt eine Debatte darüber, ob SQL eine Programmiersprache ist oder nicht. Es ist keine Allzwecksprache, wie es C oder Python sind. SQL ohne eine Datenbank und Daten in Tabellen ist nur eine Textdatei. Mit SQL lässt sich keine Website erstellen, aber es ist eine mächtige Sprache für die Arbeit mit Daten in Datenbanken. In der Praxis kommt es vor allem darauf an, dass SQL dir hilft, die Datenanalyse zu erledigen.

IBM war das erste Unternehmen, das SQL-Datenbanken entwickelte, die auf dem von Edgar Codd in den 1960er Jahren erfundenen relationalen Modell basieren. Das relationale Modell war eine theoretische Beschreibung für die Verwaltung von Daten mithilfe von Beziehungen. Mit der Entwicklung der ersten Datenbanken trug IBM dazu bei, die Theorie voranzutreiben, hatte aber auch kommerzielle Erwägungen, genau wie Oracle, Microsoft und jedes andere Unternehmen, das seitdem eine Datenbank auf den Markt gebracht hat. Von Anfang an gab es Spannungen zwischen der Computertheorie und der kommerziellen Realität. SQL wurde 1987 von der International Organization for Standards (ISO) und 1986 vom American National Standards Institute (ANSI) standardisiert. Obwohl alle großen Datenbanken bei ihrer SQL-Implementierung von diesen Standards ausgehen, verfügen viele über Variationen und Funktionen, die den Benutzern dieser Datenbanken das Leben erleichtern. Der Preis dafür ist, dass es schwieriger wird, SQL ohne Änderungen zwischen verschiedenen Datenbanken zu übertragen.

SQL wird verwendet, um auf Objekte in einer Datenbank zuzugreifen, sie zu bearbeiten und Daten aus ihnen abzurufen. Datenbanken können ein oder mehrere Schemata haben, die für die Organisation und Struktur sorgen und andere Objekte enthalten. Innerhalb eines Schemas sind die Objekte, die am häufigsten für die Datenanalyse verwendet werden, Tabellen, Ansichten und Funktionen. Tabellen enthalten Felder, in denen die Daten gespeichert sind. Tabellen können einen oder mehrere Indizes haben; ein Index ist eine besondere Art von Datenstruktur, mit der Daten effizienter abgerufen werden können. Indizes werden normalerweise von einem Datenbankadministrator definiert. Ansichten sind im Wesentlichen gespeicherte Abfragen, auf die auf die gleiche Weise wie auf eine Tabelle verwiesen werden kann. Funktionen ermöglichen es, häufig verwendete Berechnungssätze oder Prozeduren zu speichern und in Abfragen einfach darauf zu verweisen. Sie werden normalerweise von einem Datenbankadministrator (DBA) erstellt. Abbildung 1-1 gibt einen Überblick über die Organisation von Datenbanken.

Abbildung 1-1. Überblick über die Datenbankorganisation und die Objekte in einer Datenbank

Um mit Datenbanken zu kommunizieren, hat SQL vier Untersprachen für verschiedene Aufträge, die meist für alle Datenbanktypen gleich sind. Die meisten Menschen, die in der Datenanalyse arbeiten, müssen sich die Namen dieser Untersprachen nicht merken, aber sie könnten in Gesprächen mit Datenbankadministratoren oder Dateningenieuren auftauchen, deshalb stelle ich sie kurz vor. Die Befehle arbeiten alle fließend zusammen, und einige können in derselben SQL-Anweisung nebeneinander stehen.

DQL, die Datenabfragesprache, ist das Hauptthema dieses Buches. Sie wird zum Abfragen von Daten verwendet, was man sich so vorstellen kann, als würde man Code verwenden, um Fragen an eine Datenbank zu stellen. Zu den DQL-Befehlen gehört auch SELECT, das früheren SQL-Benutzern vertraut sein wird, aber das Akronym DQL wird meiner Erfahrung nach nicht häufig verwendet. SQL-Abfragen können so kurz wie eine einzige Zeile sein oder sich über mehrere Dutzend Zeilen erstrecken. SQL-Abfragen können auf eine einzelne Tabelle (oder Ansicht) zugreifen, sie können Daten aus mehreren Tabellen durch Joins kombinieren und sie können auch mehrere Schemata in derselben Datenbank abfragen. SQL-Abfragen können in der Regel nicht datenbankübergreifend abgefragt werden, aber in einigen Fällen können durch geschickte Netzwerkeinstellungen oder zusätzliche Software Daten aus mehreren Quellen, sogar aus Datenbanken unterschiedlichen Typs, abgerufen werden. SQL-Abfragen sind in sich geschlossen und verweisen, anders als Skriptsprachen, nicht auf Variablen oder Ausgaben aus vorherigen Schritten, die nicht in der Abfrage enthalten sind.

DDL, die Datendefinitionssprache, wird verwendet, um Tabellen, Ansichten, Benutzer und andere Objekte in der Datenbank zu erstellen und zu ändern. Sie beeinflusst die Struktur, aber nicht den Inhalt. Es gibt drei gängige Befehle: CREATE, ALTER und DROP. CREATE wird verwendet, um neue Objekte zu erstellen. ALTER ändert die Struktur eines Objekts, z. B. indem eine Spalte zu einer Tabelle hinzugefügt wird. DROP löscht das gesamte Objekt und seine Struktur. DBAs und Dateningenieure sprechen oft von DDLs - das ist eigentlich nur eine Abkürzung für die Dateien oder Codeteile, die das Erstellen, Ändern oder Löschen durchführen. Ein Beispiel dafür, wie DDL im Rahmen der Analyse verwendet wird, ist der Code zur Erstellung temporärer Tabellen.

DCL, die Data Control Language, wird für die Zugriffskontrolle verwendet. Zu den Befehlen gehören GRANT und REVOKE, die eine Erlaubnis erteilen bzw. eine Erlaubnis entziehen. In einem Analysekontext wird GRANT vielleicht benötigt, um einem Kollegen zu erlauben, eine von dir erstellte Tabelle abzufragen. Du könntest auch auf einen solchen Befehl stoßen, wenn dir jemand gesagt hat, dass eine Tabelle in der Datenbank existiert, du sie aber nicht sehen kannst - dann müssen deinem Benutzer möglicherweise GRANT-Berechtigungen erteiltwerden.

DML, die Datenmanipulationssprache, wird verwendet, um auf die Daten selbst einzuwirken. Die Befehle sind INSERT, UPDATE und DELETE. INSERT fügt neue Datensätze hinzu und ist im Wesentlichen der "Ladeschritt" beim Extrahieren, Transformieren und Laden (ETL). UPDATE ändert die Werte in einem Feld und DELETE löscht Zeilen. Du wirst auf diese Befehle stoßen, wenn du selbst verwaltete Tabellen hast - Temp-Tabellen, Sandbox-Tabellen - oder wenn du in der Rolle des Eigentümers und Analysators der Datenbank bist.

Diese vier Untersprachen sind in allen großen Datenbanken enthalten. In diesem Buch werde ich mich hauptsächlich auf DQL konzentrieren. In Kapitel 8 werden wir einige DDL- und DML-Befehle ansprechen, und du wirst auch einige Beispiele auf der GitHub-Seite des Buches sehen, wo sie zum Erstellen und Auffüllen der in den Beispielen verwendeten Daten verwendet werden. Dank dieses gemeinsamen Befehlssatzes wird SQL-Code, der für eine beliebige Datenbank geschrieben wurde, jedem vertraut vorkommen, der mit SQL arbeitet. Allerdings kann es sich beim Lesen von SQL für eine andere Datenbank ein bisschen so anfühlen, als würdest du jemandem zuhören, der die gleiche Sprache wie du spricht, aber aus einem anderen Teil des Landes oder der Welt kommt. Die Grundstruktur der Sprache ist dieselbe, aber die Umgangssprache ist anders, und manche Wörter haben ganz andere Bedeutungen. Die Unterschiede in SQL von Datenbank zu Datenbank werden oft als Dialekte bezeichnet, und Datenbankbenutzer verweisen auf Oracle SQL, MSSQL oder andere Dialekte.

Sobald du dich mit SQL auskennst, kannst du mit verschiedenen Datenbanktypen arbeiten, solange du auf Details wie den Umgang mit Nullen, Datums- und Zeitstempeln, die Division von ganzen Zahlen und die Groß- und Kleinschreibung achtest.

Dieses Buch verwendet PostgreSQL oder Postgres für die Beispiele, obwohl ich versuchen werde, darauf hinzuweisen, wo der Code bei anderen Datenbanktypen sinnvoll anders wäre. Du kannst Postgres auf einem PC installieren, um den Beispielen folgen zu können.

Vorteile von SQL

Es gibt viele gute Gründe, SQL für die Datenanalyse zu verwenden, von der Rechenleistung bis hin zu seiner Allgegenwart in Datenanalysetools und seiner Flexibilität.

Der vielleicht beste Grund, SQL zu verwenden, ist, dass ein Großteil der weltweiten Daten bereits in Datenbanken gespeichert ist. Es ist wahrscheinlich, dass auch dein Unternehmen eine oder mehrere Datenbanken hat. Auch wenn die Daten noch nicht in einer Datenbank gespeichert sind, kann es sich lohnen, sie in eine Datenbank zu laden, um die Vorteile der Speicherung und der Datenverarbeitung zu nutzen, insbesondere im Vergleich zu Alternativen wie Tabellenkalkulationen. Die Rechenleistung ist in den letzten Jahren explodiert, und Data Warehouses und die Dateninfrastruktur haben sich weiterentwickelt, um diese Vorteile zu nutzen. Einige neuere Cloud-Datenbanken ermöglichen es, riesige Datenmengen im Speicher abzufragen, was die Dinge weiter beschleunigt. Die Zeiten, in denen man minuten- oder stundenlang auf die Ergebnisse einer Abfrage warten musste, könnten vorbei sein, auch wenn die Analysten dann vielleicht komplexere Abfragen schreiben.

SQL ist der De-facto-Standard für die Interaktion mit Datenbanken und den Abruf von Daten aus ihnen. Eine breite Palette beliebter Software wird über SQL mit Datenbanken verbunden, von Tabellenkalkulationen über BI- und Visualisierungstools bis hin zu Programmiersprachen wie Python und R (die im nächsten Abschnitt behandelt werden). Aufgrund der verfügbaren Rechenressourcen ist es oft von Vorteil, so viele Datenmanipulationen und Aggregationen wie möglich in der Datenbank durchzuführen. Strategien zum Aufbau komplexer Datensätze für nachgelagerte Tools werden wir in Kapitel 8 ausführlich besprechen.

Die grundlegenden SQL-Bausteine können auf unendlich viele Arten kombiniert werden. Ausgehend von einer relativ kleinen Anzahl von Bausteinen - der Syntax - kann SQL eine breite Palette von Aufgaben erfüllen. SQL kann iterativ entwickelt werden, und es ist einfach, die Ergebnisse während der Entwicklung zu überprüfen. Sie ist zwar keine vollwertige Programmiersprache, aber sie kann eine Menge, von der Umwandlung von Daten über komplexe Berechnungen bis hin zur Beantwortung von Fragen.

Und schließlich ist SQL relativ leicht zu erlernen, mit einer begrenzten Menge an Syntax. Du kannst die grundlegenden Schlüsselwörter und die Struktur schnell erlernen und dann im Laufe der Zeit dein Handwerk bei der Arbeit mit verschiedenen Datensätzen verfeinern. Die Anwendungsmöglichkeiten von SQL sind praktisch unbegrenzt, wenn man die Vielfalt der Datensätze in der Welt und die möglichen Fragen, die an die Daten gestellt werden können, berücksichtigt. SQL wird an vielen Universitäten gelehrt, und viele Menschen eignen sich die Kenntnisse auch im Job an. Selbst Mitarbeiter/innen, die noch keine SQL-Kenntnisse haben, können geschult werden, und die Lernkurve ist möglicherweise einfacher als bei anderen Programmiersprachen. Das macht die Speicherung von Daten zur Analyse in relationalen Datenbanken zu einer logischen Wahl für Unternehmen.

SQL vs. R oder Python

SQL ist zwar eine beliebte Sprache für die Datenanalyse, aber sie ist nicht die einzige Wahl. R und Python gehören zu den beliebtesten Sprachen, die für die Datenanalyse verwendet werden. R ist eine Statistik- und Grafiksprache, während Python eine Allzweckprogrammiersprache ist, deren Stärken in der Arbeit mit Daten liegen. Beide sind quelloffen, können auf einem Laptop installiert werden und haben aktive Gemeinschaften, die Pakete oder Erweiterungen entwickeln, die verschiedene Aufgaben der Datenmanipulation und -analyse bewältigen. Die Entscheidung zwischen R und Python würde den Rahmen dieses Buches sprengen, aber im Internet gibt es viele Diskussionen über die jeweiligen Vorteile der beiden Sprachen. Hier werde ich sie zusammen als Alternativen zu SQL betrachten.

Ein großer Unterschied zwischen SQL und anderen Programmiersprachen ist der Ort, an dem der Code ausgeführt wird, und damit auch die verfügbare Rechenleistung. SQL wird immer auf einem Datenbankserver ausgeführt und nutzt alle Rechenressourcen aus. Für die Analyse werden R und Python in der Regel lokal auf deinem Computer ausgeführt, sodass die Rechenressourcen durch die lokal verfügbaren Ressourcen begrenzt sind. Natürlich gibt es viele Ausnahmen: Datenbanken können auf Laptops laufen, und R und Python können auf Servern mit mehr Ressourcen ausgeführt werden. Wenn du nicht nur die einfachsten Analysen an großen Datensätzen durchführst, ist es eine gute Option, die Arbeit auf einen Datenbankserver mit mehr Ressourcen zu verlagern. Da Datenbanken normalerweise so eingerichtet sind, dass sie ständig neue Daten erhalten, ist SQL auch eine gute Wahl, wenn ein Bericht oder ein Dashboard regelmäßig aktualisiert werden muss.

Ein zweiter Unterschied besteht darin, wie die Daten gespeichert und organisiert werden. Relationale Datenbanken organisieren die Daten immer in Zeilen und Spalten innerhalb von Tabellen, sodass SQL diese Struktur bei jeder Abfrage voraussetzt. R und Python bieten eine größere Vielfalt an Möglichkeiten, Daten zu speichern, z. B. Variablen, Listen und Wörterbücher. Diese bieten mehr Flexibilität, allerdings um den Preis einer steileren Lernkurve. Um die Datenanalyse zu erleichtern, verfügt R über DataFrames, die ähnlich wie Datenbanktabellen sind und Daten in Zeilen und Spalten organisieren. Das Paket pandas macht Datenrahmen in Python verfügbar. Auch wenn andere Optionen verfügbar sind, bleibt die Tabellenstruktur für die Analyse wertvoll.

Schleifen sind ein weiterer wichtiger Unterschied zwischen SQL und den meisten anderen Programmiersprachen. Eine Schleife ist eine Anweisung oder eine Reihe von Anweisungen, die wiederholt wird, bis eine bestimmte Bedingung erfüllt ist. SQL-Aggregationen führen implizit eine Schleife über den Datensatz aus, ohne dass zusätzlicher Code erforderlich ist. Wir werden später sehen, wie die fehlende Möglichkeit, Schleifen über Felder zu ziehen, zu langen SQL-Anweisungen führen kann, wenn Daten gepivotet oder unpivotet werden. Auch wenn es den Rahmen dieses Buches sprengen würde, haben einige Anbieter Erweiterungen für SQL entwickelt, wie z. B. PL/SQL in Oracle und T-SQL in Microsoft SQL Server, die Funktionen wie Schleifenbildung ermöglichen.

Ein Nachteil von SQL ist, dass sich deine Daten in einer Datenbank befinden müssen,¹ R und Python hingegen können Daten aus lokal gespeicherten Dateien importieren oder auf Dateien zugreifen, die auf Servern oder Websites gespeichert sind. Das ist für viele einmalige Projekte sehr praktisch. Eine Datenbank kann auf einem Laptop installiert werden, aber das bedeutet einen zusätzlichen Aufwand. Umgekehrt ermöglichen es Pakete wie dbplyr für R und SQLAlchemy für Python, in diesen Sprachen geschriebene Programme mit Datenbanken zu verbinden, SQL-Abfragen auszuführen und die Ergebnisse in weiteren Verarbeitungsschritten zu verwenden. In diesem Sinne können R oder Python eine Ergänzung zu SQL sein.

R und Python verfügen beide über ausgefeilte statistische Funktionen, die entweder eingebaut oder in Paketen verfügbar sind. Obwohl SQL zum Beispiel über Funktionen zur Berechnung von Durchschnitt und Standardabweichung verfügt, können Berechnungen von p-Werten und statistischer Signifikanz, die für die Analyse von Experimenten benötigt werden (siehe Kapitel 7), nicht mit SQL allein durchgeführt werden. Neben anspruchsvollen Statistiken ist maschinelles Lernen ein weiterer Bereich, der besser mit einer dieser anderen Programmiersprachen angegangen werden kann.

Wenn du entscheidest, ob du SQL, R oder Python für eine Analyse verwendest, solltest du das berücksichtigen:

• Wo befinden sich die Daten - in einer Datenbank, einer Datei oder auf einer Website?

• Wie hoch ist das Datenvolumen?

• Wo gehen die Daten hin - in einen Bericht, eine Visualisierung, eine statistische Analyse?

• Muss sie mit neuen Daten aktualisiert oder aufgefrischt werden? Wie oft?

• Was verwendet dein Team oder deine Organisation und wie wichtig ist es, die bestehenden Standards einzuhalten?

Es gibt immer wieder Diskussionen darüber, welche Sprachen und Tools sich am besten für die Datenanalyse oder Data Science eignen. Wie bei vielen anderen Dingen auch, gibt es oft mehr als einen Weg, eine Analyse durchzuführen. Programmiersprachen entwickeln sich weiter und werden immer beliebter, und wir haben das Glück, in einer Zeit zu leben und zu arbeiten, in der es so viele gute Möglichkeiten gibt. SQL gibt es schon seit langem und wird wahrscheinlich auch in den nächsten Jahren beliebt bleiben. Das oberste Ziel ist es, das beste verfügbare Werkzeug für die jeweilige Aufgabe zu nutzen. Dieses Buch wird dir helfen, das Beste aus SQL für die Datenanalyse herauszuholen, unabhängig davon, was du sonst noch in deinem Werkzeugkasten hast.

SQL als Teil des Datenanalyse-Workflows

Nachdem ich nun erklärt habe, was SQL ist, einige seiner Vorteile erörtert und es mit anderen Sprachen verglichen habe, wollen wir uns nun der Frage zuwenden, wie SQL in den Prozess der Datenanalyse passt. Am Anfang der Analyse steht immer eine Frage, z. B. wie viele neue Kunden gewonnen wurden, wie sich die Umsätze entwickeln oder warum manche Nutzer/innen lange dabei bleiben, während andere einen Dienst ausprobieren und nie wiederkommen. Sobald die Frage formuliert ist, überlegen wir, woher die Daten stammen, wo sie gespeichert werden, wie die Analyse aussehen soll und wie die Ergebnisse dem Publikum präsentiert werden sollen. Abbildung 1-2 zeigt die einzelnen Schritte des Prozesses. Die Abfragen und die Analyse stehen im Mittelpunkt dieses Buches, aber ich werde auch kurz auf die anderen Schritte eingehen, um die Abfragen und die Analyse in einen breiteren Kontext zu stellen.

Abbildung 1-2. Schritte im Prozess der Datenanalyse

Erstens werden Daten von Quellsystemen erzeugt, ein Begriff, der jeden menschlichen oder maschinellen Prozess umfasst, der Daten von Interesse erzeugt. Daten können von Menschen per Hand erzeugt werden, z. B. wenn jemand ein Formular ausfüllt oder sich während eines Arztbesuchs Notizen macht. Daten können auch maschinell erzeugt werden, z. B. wenn eine Anwendungsdatenbank einen Kauf aufzeichnet, ein Event-Streaming-System einen Website-Klick oder ein Marketing-Management-Tool eine geöffnete E-Mail aufzeichnet. Quellensysteme können viele verschiedene Arten und Formate von Daten generieren. In Kapitel 2 werden sie und die Auswirkungen der Art der Quelle auf die Analyse ausführlicher behandelt.

Der zweite Schritt ist das Verschieben der Daten und ihre Speicherung in einer Datenbank für die Analyse. Ich verwende die Begriffe Data Warehouse, also eine Datenbank, die Daten aus dem gesamten Unternehmen in einem zentralen Speicher zusammenfasst, und Data Store, der sich auf jede Art von Datenspeicherung bezieht, die abgefragt werden kann. Andere Begriffe, auf die du vielleicht stößt, sind Data Mart, der typischerweise eine Untergruppe eines Data Warehouse oder ein enger gefasstes Data Warehouse ist, und Data Lake, ein Begriff, der entweder bedeutet, dass die Daten in einem Dateispeichersystem oder in einer Datenbank gespeichert sind, aber ohne den Grad der Datenumwandlung, der in Data Warehouses üblich ist. Die Bandbreite der Data Warehouses reicht von klein und einfach bis hin zu riesig und teuer. Eine Datenbank, die auf einem Laptop läuft, reicht aus, um die Beispiele in diesem Buch nachzuvollziehen. Wichtig ist, dass du die Daten, die du für eine Analyse brauchst, an einem Ort zusammen hast.

Hinweis

Normalerweise ist eine Person oder ein Team dafür verantwortlich, Daten in das Data Warehouse zu bringen. Dieser Prozess wird ETL genannt, oder Extrahieren, Transformieren, Laden. Beim Extrahieren werden die Daten aus dem Quellsystem gezogen. Beim Transformieren wird optional die Struktur der Daten geändert, die Datenqualität bereinigt oder die Daten aggregiert. Beim Laden werden die Daten in die Datenbank geladen. Dieser Prozess kann auch ELT genannt werden, was für Extrahieren, Laden, Transformieren steht. Der Unterschied besteht darin, dass die Daten nicht erst transformiert werden, bevor sie geladen werden, sondern dass alle Daten geladen und dann transformiert werden, normalerweise mit SQL. Vielleicht hörst du im Zusammenhang mit ETL auch die Begriffe Quelle und Ziel. Die Quelle ist der Ort, wo die Daten herkommen, und das Ziel ist der Bestimmungsort, d.h. die Datenbank und die darin enthaltenen Tabellen. Selbst wenn SQL für die Umwandlung verwendet wird, kommt eine andere Sprache wie Python oder Java zum Einsatz, um die einzelnen Schritte zusammenzufügen, die Planung zu koordinieren und Warnmeldungen auszugeben, wenn etwas schief läuft. Es gibt eine Reihe kommerzieller Produkte und Open-Source-Tools, so dass die Teams ein ETL-System nicht von Grund auf neu erstellen müssen.

Sobald sich die Daten in einer Datenbank befinden, ist der nächste Schritt die Durchführung von Abfragen und Analysen. In diesem Schritt wird SQL eingesetzt, um die Daten zu untersuchen, zu profilieren, zu bereinigen, zu formen und zu analysieren. Abbildung 1-3 zeigt den allgemeinen Ablauf des Prozesses. Beim Erkunden der Daten geht es darum, sich mit dem Thema vertraut zu machen, wo die Daten erzeugt wurden und in welchen Datenbanktabellen sie gespeichert sind. Beim Profiling werden die eindeutigen Werte und die Verteilung der Datensätze im Datensatz überprüft. Das Bereinigen umfasst das Korrigieren falscher oder unvollständiger Daten, das Hinzufügen von Kategorisierungen und Markierungen sowie die Behandlung von Nullwerten. Beim Shaping werden die Daten in den Zeilen und Spalten angeordnet, die für die Ergebnismenge benötigt werden. Bei der Analyse der Daten werden die Ergebnisse auf Trends, Schlussfolgerungen und Erkenntnisse überprüft. Obwohl dieser Prozess als linear dargestellt wird, verläuft er in der Praxis oft zyklisch, z. B. wenn beim Shaping oder der Analyse Daten entdeckt werden, die bereinigt werden sollten.

Abbildung 1-3. Schritte innerhalb der Abfragen und Analysen des Analyse-Workflows

Die Präsentation der Daten in einer endgültigen Ausgabeform ist der letzte Schritt im gesamten Arbeitsablauf. Geschäftsleute freuen sich nicht über eine Datei mit SQL-Code; sie erwarten, dass du Grafiken, Diagramme und Erkenntnisse präsentierst. Kommunikation ist der Schlüssel zur Wirkung von Analysen, und dafür brauchen wir eine Möglichkeit, die Ergebnisse mit anderen zu teilen. In anderen Fällen musst du vielleicht anspruchsvollere statistische Analysen durchführen, als dies mit SQL möglich ist, oder du möchtest die Daten in einen Algorithmus für maschinelles Lernen (ML) einspeisen. Glücklicherweise verfügen die meisten Berichts- und Visualisierungstools über SQL-Konnektoren, mit denen du Daten aus ganzen Tabellen oder vorbereiteten SQL-Abfragen einlesen kannst. Auch statistische Software und Sprachen, die häufig für ML verwendet werden, haben in der Regel SQL-Konnektoren.

Analyse-Workflows umfassen eine Reihe von Schritten und beinhalten oft mehrere Tools und Technologien. SQL-Abfragen und -Analysen sind das Herzstück vieler Analysen und darauf werden wir uns in den folgenden Kapiteln konzentrieren. In Kapitel 2 geht es um die Arten von Quellsystemen und die Arten von Daten, die sie erzeugen. Der Rest dieses Kapitels befasst sich mit den Arten von Datenbanken, auf die du bei deinen Analysen wahrscheinlich stoßen wirst.

Datenbanktypen und wie man mit ihnen arbeitet

Wenn du mit SQL arbeitest, arbeitest du auch mit Datenbanken. Es gibt eine Reihe von Datenbanktypen - Open Source oder proprietär, Zeilenspeicher oder Spaltenspeicher. Es gibt On-Premises-Datenbanken und Cloud-Datenbanken sowie hybride Datenbanken, bei denen ein Unternehmen die Datenbanksoftware auf der Infrastruktur eines Cloud-Anbieters betreibt. Es gibt auch eine Reihe von Datenspeichern, die gar keine Datenbanken sind, aber mit SQL abgefragt werden können.

Datenbanken sind nicht alle gleich; jeder Datenbanktyp hat seine Stärken und Schwächen, wenn es um die Analysearbeit geht. Im Gegensatz zu den Werkzeugen, die in anderen Bereichen des Analyse-Workflows verwendet werden, hast du vielleicht nicht viel Einfluss darauf, welche Datenbanktechnologie in deinem Unternehmen eingesetzt wird. Wenn du dich mit der Datenbank auskennst, kannst du effizienter arbeiten und die speziellen SQL-Funktionen nutzen, die sie bietet. Vertrautheit mit anderen Datenbanktypen hilft dir, wenn du an einem Projekt zum Aufbau oder zur Migration eines neuen Data Warehouse arbeitest. Vielleicht möchtest du für persönliche, kleinere Projekte eine Datenbank auf deinem Laptop installieren oder dir aus ähnlichen Gründen eine Instanz eines Cloud-Warehouses zulegen.

Datenbanken und Datenspeicher sind seit ihrer Einführung ein dynamischer Bereich der Technologieentwicklung. Seit der Wende zum 21. Jahrhundert haben einige Trends die Technologie in einer Weise vorangetrieben, die für Datenpraktiker/innen heute wirklich spannend ist. Erstens ist das Datenvolumen durch das Internet, mobile Geräte und das Internet der Dinge (IoT) unglaublich gestiegen. Im Jahr 2020 prognostizierte IDC, dass die weltweit gespeicherte Datenmenge bis 2025 auf 175 Zettabyte anwachsen wird. Dieses Ausmaß an Daten ist kaum vorstellbar, und nicht alle davon werden in Datenbanken zur Analyse gespeichert. Es ist nicht ungewöhnlich, dass Unternehmen heute Daten in der Größenordnung von Terabytes und Petabytes haben, eine Größenordnung, die mit der Technologie der 1990er Jahre und früher unmöglich zu verarbeiten gewesen wäre. Zweitens sind die Kosten für die Speicherung und Verarbeitung von Daten gesunken, und mit der Einführung der Cloud ist es für Unternehmen billiger und einfacher geworden, diese riesigen Datenmengen zu sammeln und zu speichern. Der Computerspeicher ist billiger geworden, was bedeutet, dass große Datenmengen in den Speicher geladen, Berechnungen durchgeführt und Ergebnisse zurückgegeben werden können, ohne dass die Festplatte gelesen und beschrieben werden muss, was die Geschwindigkeit erheblich erhöht. Drittens hat das verteilte Rechnen die Aufteilung von Arbeitslasten auf viele Rechner ermöglicht. Dadurch kann ein großer und einstellbarer Teil der Rechenleistung auf komplexe Datenaufgaben ausgerichtet werden.

Datenbanken und Datenspeicher haben diese technologischen Trends auf unterschiedliche Weise kombiniert, um sie für bestimmte Arten von Aufgaben zu optimieren. Es gibt zwei große Kategorien von Datenbanken, die für die Analysearbeit relevant sind: Zeilenspeicher und Spaltenspeicher. Im nächsten Abschnitt stelle ich sie vor, erkläre, was sie miteinander verbindet und was sie voneinander unterscheidet, und erkläre, was das alles für die Analyse der in ihnen gespeicherten Daten bedeutet. Zum Schluss stelle ich dir einige weitere Arten von Dateninfrastrukturen vor, die du neben Datenbanken kennenlernen kannst.

Row-Store-Datenbanken

Zeilenspeicherdatenbanken - auch transaktionale Datenbanken genannt - sind so konzipiert, dass sie Transaktionen effizient verarbeiten können: INSERTs, UPDATEsund DELETEs. Beliebte Open-Source-Datenbanken sind MySQL und Postgres. Auf der kommerziellen Seite sind Microsoft SQL Server, Oracle und Teradata weit verbreitet. Obwohl sie nicht wirklich für Analysen optimiert sind, waren Row-Store-Datenbanken einige Jahre lang die einzige Option für Unternehmen, die Data Warehouses aufbauen. Durch sorgfältiges Tuning und Schemadesign können diese Datenbanken für Analysen genutzt werden. Sie sind auch deshalb so attraktiv, weil die Kosten für Open-Source-Optionen niedrig sind und weil sie den Datenbankadministratoren, die sie pflegen, vertraut sind. Viele Unternehmen replizieren ihre Produktionsdatenbank mit der gleichen Technologie, um den ersten Schritt zum Aufbau einer Dateninfrastruktur zu machen. Aus all diesen Gründen ist es wahrscheinlich, dass Datenanalysten und Datenwissenschaftler irgendwann in ihrer Karriere mit Daten in einer Row-Store-Datenbank arbeiten werden.

Wir stellen uns eine Tabelle als Zeilen und Spalten vor, aber die Daten müssen für die Speicherung serialisiert werden. Eine Abfrage sucht auf der Festplatte nach den benötigten Daten. Festplatten sind in einer Reihe von Blöcken mit einer festen Größe organisiert. Das Durchsuchen der Festplatte benötigt sowohl Zeit als auch Ressourcen. Deshalb ist es wichtig, den Anteil der Festplatte, der für die Abfrageergebnisse durchsucht werden muss, zu minimieren. Row-Store-Datenbanken gehen dieses Problem an, indem sie Daten in einer Zeile serialisieren. Abbildung 1-4 zeigt ein Beispiel für die zeilenweise Speicherung von Daten. Bei einer Abfrage wird die gesamte Zeile in den Speicher eingelesen. Dieser Ansatz ist schnell, wenn zeilenweise Aktualisierungen vorgenommen werden, aber er ist langsamer, wenn Berechnungen über viele Zeilen hinweg durchgeführt werden und nur ein paar Spalten benötigt werden.

Abbildung 1-4. Zeilenweise Speicherung, bei der jede Zeile zusammen auf der Festplatte gespeichert wird

Um die Breite der Tabellen zu reduzieren, werden Zeilenspeicherdatenbanken in der Regel in der dritten Normalform modelliert. Dies ist ein Datenbankentwurfsansatz, der darauf abzielt, jede Information nur einmal zu speichern, um Duplikate und Inkonsistenzen zu vermeiden. Das ist effizient für die Transaktionsverarbeitung, führt aber oft zu einer großen Anzahl von Tabellen in der Datenbank, die jeweils nur wenige Spalten haben. Um solche Daten zu analysieren, sind unter Umständen viele Joins erforderlich, und für Nicht-Entwickler/innen kann es schwierig sein zu verstehen, wie alle Tabellen zueinander in Beziehung stehen und wo ein bestimmter Datensatz gespeichert ist. Bei der Analyse geht es in der Regel darum, die Daten zu denormalisieren oder an einem Ort zusammenzufassen.

Tabellen haben in der Regel einen Primärschlüssel, der die Eindeutigkeit erzwingt - mit anderen Worten, er verhindert, dass die Datenbank mehr als einen Datensatz für dieselbe Sache erstellt. Tabellen haben oft eine id Spalte, die eine automatisch aufsteigende Ganzzahl ist, wobei jeder neue Datensatz die nächste Ganzzahl nach der zuletzt eingefügten erhält, oder einen alphanumerischen Wert, der durch einen Primärschlüsselgenerator erzeugt wird. Es sollte auch eine Reihe von Spalten geben, die zusammen die Zeile eindeutig machen; diese Kombination von Feldern wird als zusammengesetzter Schlüssel oder manchmal auch als Geschäftsschlüssel bezeichnet. In einer Personentabelle könnten z. B. die Spalten first_name, last_name und birthdate zusammen die Zeile eindeutig machen. Social_security_id wäre auch ein eindeutiger Bezeichner, zusätzlich zu der person_id Spalte.

Tabellen haben optional auch Indizes, die das Auffinden bestimmter Datensätze und die Verknüpfung dieser Spalten beschleunigen. Indizes speichern die Werte des oder der indizierten Felder als einzelne Daten zusammen mit einem Zeilenzeiger. Da die Indizes kleiner sind als die gesamte Tabelle, können sie schneller durchsucht werden. Normalerweise wird der Primärschlüssel indiziert, aber auch andere Felder oder Feldgruppen können indiziert werden. Bei der Arbeit mit Zeilenspeicherdatenbanken ist es nützlich zu wissen, welche Felder in den von dir verwendeten Tabellen indiziert sind. Häufige Verknüpfungen können durch das Hinzufügen von Indizes beschleunigt werden, daher lohnt es sich, zu untersuchen, ob Analyseabfragen lange dauern. Indizes gibt es nicht umsonst: Sie beanspruchen Speicherplatz und verlangsamen das Laden, da bei jeder Eingabe neue Werte hinzugefügt werden müssen. DBAs indizieren vielleicht nicht alles, was für die Analyse nützlich sein könnte. Abgesehen vom Berichtswesen ist die Analysearbeit vielleicht nicht routinemäßig genug, um sich um die Optimierung von Indizes zu kümmern. Explorative und komplexe Abfragen verwenden oft komplexe Verknüpfungsmuster, und es kann sein, dass wir einen Ansatz verwerfen, wenn wir einen neuen Weg zur Lösung eines Problems finden.

Die Modellierung von Sternschemata wurde unter anderem entwickelt, um Datenbanken mit Zeilenspeichern für analytische Workloads freundlicher zu machen. Die Grundlagen dafür sind in dem Buch The Data Warehouse Toolkit beschrieben,² in dem empfohlen wird, die Daten als eine Reihe von Fakten- und Dimensionstabellen zu modellieren. Faktentabellen stellen Ereignisse dar, wie z. B. Transaktionen im Einzelhandel. Dimensionen enthalten Deskriptoren wie den Kundennamen und die Produktart. Da die Daten nicht immer genau in die Kategorien von Fakten und Dimensionen passen, gibt es eine Erweiterung, das sogenannte Schneeflockenschema, in dem einige Dimensionen eigene Dimensionen haben.

Column-Store-Datenbanken

Column-Store-Datenbanken kamen zu Beginn des 21. Jahrhunderts auf, obwohl ihre theoretische Geschichte genauso weit zurückreicht wie die der Row-Store-Datenbanken. Column-Store-Datenbanken speichern die Werte einer Spalte zusammen, anstatt die Werte einer Zeile zusammen zu speichern. Dieses Design ist für Abfragen optimiert, die viele Datensätze, aber nicht unbedingt alle Spalten lesen. Beliebte Column-Store-Datenbanken sind Amazon Redshift, Snowflake und Vertica.

Column-Store-Datenbanken sind dank Komprimierung effizient bei der Speicherung großer Datenmengen. Fehlende Werte und sich wiederholende Werte können durch sehr kleine Markierungswerte anstelle des vollständigen Wertes dargestellt werden. Anstatt z.B. "Vereinigtes Königreich" tausend- oder millionenfach zu speichern, speichert eine Column-Store-Datenbank einen Ersatzwert, der nur sehr wenig Speicherplatz benötigt, zusammen mit einem Lookup, das den vollständigen Wert "Vereinigtes Königreich" speichert. Column-Store-Datenbanken komprimieren Daten auch, indem sie Wiederholungen von Werten in sortierten Daten ausnutzen. Die Datenbank kann z. B. die Tatsache speichern, dass der Markierungswert für "Vereinigtes Königreich" 100 Mal wiederholt wird, was noch weniger Speicherplatz beansprucht als die 100-malige Speicherung dieser Markierung.

Column-Store-Datenbanken erzwingen keine Primärschlüssel und haben keine Indizes. Wiederholte Werte sind dank der Komprimierung kein Problem. Daher können Schemata für Analyseabfragen maßgeschneidert werden, da alle Daten an einem Ort zusammengefasst sind und nicht in mehreren Tabellen liegen, die miteinander verbunden werden müssen. Ohne Primärschlüssel können sich jedoch leicht doppelte Daten einschleichen. Deshalb ist es wichtig, die Quelle der Daten zu kennen und die Qualität zu überprüfen.

Aktualisierungen und Löschungen sind in den meisten Column-Store-Datenbanken teuer, da die Daten für eine einzelne Zeile verteilt und nicht gemeinsam gespeichert werden. Bei sehr großen Tabellen kann es eine Schreibschutzrichtlinie geben, so dass wir auch etwas darüber wissen müssen, wie die Daten erzeugt werden, um herauszufinden, welche Datensätze verwendet werden sollen. Das Lesen der Daten kann auch langsamer sein, da sie vor der Anwendung von Berechnungen entkomprimiert werden müssen.

Column-Store-Datenbanken sind im Allgemeinen der Goldstandard für schnelle Analysen. Sie verwenden Standard-SQL (mit einigen anbieterspezifischen Variationen), und in vielerlei Hinsicht unterscheidet sich die Arbeit mit ihnen nicht von der Arbeit mit einer Zeilenspeicherdatenbank, was die Abfragen angeht, die du schreibst. Die Größe der Daten spielt eine Rolle, ebenso wie die Rechen- und Speicherressourcen, die der Datenbank zugewiesen wurden. Ich habe schon Aggregationen über Millionen und Milliarden von Datensätzen in Sekundenschnelle ausgeführt. Das wirkt wahre Wunder für die Produktivität.

Tipp

Es gibt ein paar Tricks, die du beachten solltest. Da bestimmte Arten der Komprimierung auf Sortierung beruhen, verbessert es die Leistung, wenn du die Felder kennst, nach denen die Tabelle sortiert ist, und sie zum Filtern von Abfragen verwendest. Das Verbinden von Tabellen kann langsam sein, wenn beide Tabellen groß sind.

Letzten Endes werden manche Datenbanken einfacher oder schneller zu bearbeiten sein, aber es gibt nichts, was dich daran hindert, die Analysen in diesem Buch durchzuführen. Wie bei allen anderen Dingen auch, solltest du ein Werkzeug verwenden, das für die Datenmenge und die Komplexität der Aufgabe geeignet ist, damit du dich auf die Erstellung aussagekräftiger Analysen konzentrieren kannst.

Andere Arten von Dateninfrastruktur

Datenbanken sind nicht die einzige Möglichkeit, Daten zu speichern, und es gibt immer mehr Möglichkeiten, Daten zu speichern, die für die Analyse und den Betrieb von Anwendungen benötigt werden. Dateispeichersysteme, manchmal auch Data Lakes genannt, sind wahrscheinlich die wichtigste Alternative zu Datenbanklagern. NoSQL-Datenbanken und suchbasierte Datenspeicher sind alternative Datenspeichersysteme, die eine geringe Latenzzeit für die Anwendungsentwicklung und die Suche in Protokolldateien bieten. Obwohl sie in der Regel nicht Teil des Analyseprozesses sind, werden sie zunehmend Teil der Dateninfrastruktur von Unternehmen, weshalb ich sie in diesem Abschnitt ebenfalls kurz vorstellen werde. Ein interessanter Trend ist, dass, obwohl diese neueren Infrastrukturen zunächst darauf abzielten, sich von den Grenzen der SQL-Datenbanken zu lösen, viele von ihnen schließlich eine Art SQL-Schnittstelle zur Abfrage der Daten implementiert haben.

Hadoop, auch bekannt als HDFS (für "Hadoop distributed filesystem"), ist ein Open-Source-Dateispeichersystem, das sich die ständig sinkenden Kosten für Datenspeicherung und Rechenleistung sowie verteilte Systeme zunutze macht. Dateien werden in Blöcke aufgeteilt und von Hadoop auf ein Dateisystem verteilt, das auf den Knoten oder Computern eines Clusters gespeichert ist. Der Code zur Ausführung von Operationen wird an die Knoten gesendet, die die Daten parallel verarbeiten. Der große Durchbruch von Hadoop war die Möglichkeit, große Datenmengen kostengünstig zu speichern. Viele große Internetunternehmen mit riesigen, oft unstrukturierten Datenmengen sahen darin einen Vorteil gegenüber den Kosten und der begrenzten Speicherung in herkömmlichen Datenbanken. Die ersten Versionen von Hadoop hatten zwei große Nachteile: Zum Abrufen und Verarbeiten der Daten waren spezielle Programmierkenntnisse erforderlich, da sie nicht SQL-kompatibel waren, und die Ausführungszeit der Programme war oft recht lang. Inzwischen ist Hadoop ausgereift, und es wurden verschiedene Tools entwickelt, die einen SQL- oder SQL-ähnlichen Zugriff auf die Daten ermöglichen und die Abfragezeiten verkürzen.

In den letzten Jahren wurden weitere kommerzielle und Open-Source-Produkte auf den Markt gebracht, die die Vorteile einer günstigen Speicherung und einer schnellen, oft speicherinternen Datenverarbeitung nutzen und gleichzeitig SQL-Abfragen ermöglichen. Einige von ihnen ermöglichen es dem Analysten sogar, eine einzige Abfrage zu schreiben, die Daten aus mehreren zugrunde liegenden Quellen liefert. Das ist spannend für alle, die mit großen Datenmengen arbeiten, und es ist eine Bestätigung dafür, dass SQL auf dem Vormarsch ist.

NoSQL ist eine Technologie, die eine Datenmodellierung ermöglicht, die nicht streng relational ist. Sie ermöglicht eine Speicherung und Abfrage mit sehr geringer Latenzzeit, was für viele Online-Anwendungen entscheidend ist. Zu dieser Klasse gehören die Speicherung von Schlüssel-Wert-Paaren und Graphdatenbanken, die in einem Knoten-Kanten-Format speichern, sowie Dokumentenspeicher. Beispiele für diese Datenspeicher, von denen du in deinem Unternehmen vielleicht schon gehört hast, sind Cassandra, Couchbase, DynamoDB, Memcached, Giraph und Neo4j. Früher wurde NoSQL damit beworben, dass es SQL überflüssig macht, aber in letzter Zeit wird das Akronym eher als "nicht nur SQL" vermarktet. Um Daten, die in einem NoSQL-Schlüsselwertspeicher gespeichert sind, zu analysieren, müssen sie in der Regel in ein traditionelles SQL-Datawarehouse verschoben werden, da NoSQL nicht für die gleichzeitige Abfrage vieler Datensätze optimiert ist. Graphdatenbanken werden z. B. für die Netzwerkanalyse eingesetzt, und Analysen können mit speziellen Abfragesprachen direkt in ihnen durchgeführt werden. Die Tool-Landschaft entwickelt sich jedoch ständig weiter, und vielleicht werden wir eines Tages in der Lage sein, diese Daten auch mit SQL zu analysieren.

Zu den suchbasierten Datenspeichern gehören Elasticsearch und Splunk. Elasticsearch und Splunk werden oft für die Analyse von maschinell erzeugten Daten, wie z. B. Logs, verwendet. Diese und ähnliche Technologien haben keine SQL-Abfragesprachen, aber wenn du SQL kennst, kannst du sie oft verstehen. Einige Datenspeicher wie Elasticsearch haben erkannt, wie verbreitet SQL-Kenntnisse sind, und haben daher Schnittstellen für SQL-Abfragen hinzugefügt. Diese Tools sind für die Anwendungsfälle, für die sie entwickelt wurden, nützlich und leistungsfähig, aber für die Arten von Analyseaufgaben, die in diesem Buch behandelt werden, sind sie in der Regel nicht gut geeignet. Wie ich meinen Lesern im Laufe der Jahre erklärt habe, sind sie hervorragend geeignet, um die Nadel im Heuhaufen zu finden. Den Heuhaufen selbst können sie nicht so gut vermessen.

Unabhängig von der Art der Datenbank oder einer anderen Technologie zur Speicherung von Daten ist der Trend eindeutig: Auch wenn die Datenmengen wachsen und die Anwendungsfälle komplexer werden, ist SQL immer noch das Standardwerkzeug für den Datenzugriff. Die große Anzahl an Nutzern, die überschaubare Lernkurve und die Leistungsfähigkeit für analytische Aufgaben sorgen dafür, dass selbst Technologien, die versuchen, sich von SQL zu entfernen, wieder zurückkommen und es übernehmen.

Fazit

Datenanalyse ist eine spannende Disziplin mit einer Reihe von Anwendungen für Unternehmen und andere Organisationen. SQL hat viele Vorteile für die Arbeit mit Daten, insbesondere mit Daten, die in einer Datenbank gespeichert sind. Das Abfragen und Analysieren von Daten ist Teil eines größeren Analyse-Workflows, und es gibt verschiedene Arten von Datenspeichern, mit denen ein Datenwissenschaftler arbeiten kann. Nachdem wir nun die Grundlagen für die Analyse, SQL und Datenspeicher gelegt haben, wird der Rest des Buches die Verwendung von SQL für die Analyse im Detail behandeln. Kapitel 2 konzentriert sich auf die Datenaufbereitung, beginnend mit einer Einführung in die Datentypen und dann weiter zu Profiling, Bereinigung und Formung von Daten. In den Kapiteln 3 bis 7 werden Anwendungen der Datenanalyse vorgestellt, wobei der Schwerpunkt auf der Zeitreihenanalyse, Kohortenanalyse, Textanalyse, Erkennung von Anomalien und der Analyse von Experimenten liegt. Kapitel 8 behandelt Techniken zur Entwicklung komplexer Datensätze für die weitere Analyse in anderen Tools. Kapitel 9 schließt mit Überlegungen dazu, wie sich verschiedene Analysemethoden kombinieren lassen, um neue Erkenntnisse zu gewinnen, und listet einige zusätzliche Ressourcen auf, die dich auf deinem Weg zur Analyse unterstützen.

¹ Es gibt einige neuere Technologien, die SQL-Abfragen auf Daten ermöglichen, die in nichtrelationalen Quellen gespeichert sind.

² Ralph Kimball und Margy Ross, The Data Warehouse Toolkit, 3. Aufl. (Indianapolis: Wiley, 2013).