Von Betriebssystemen zur Datenintelligenz: Die vollständige Evolution von Datenanalysesystemen

Stellen Sie sich vor: Sie stehen in einem geschäftigen Einzelhandelsgeschäft im Jahr 1985. Jedes Mal, wenn ein Kunde etwas kauft, protokolliert die Registrierkasse sofort die Transaktionsinformationen – das Produkt, den Preis, den Zeitstempel. Dies ist der Puls des Geschäfts, das Betriebsritmo. Stellen Sie sich nun vor, Sie versuchen, die folgenden Fragen zu beantworten: „Welche Produkte waren im vergangenen Quartal am besten verkauft?“ Oder „Wie lauten die Umsatztrends in allen unseren Filialen?“ Plötzlich hat das System, das tausende Transaktionen pro Sekunde verarbeiten kann, Schwierigkeiten, Antworten zu geben. Es ist, als würde man einen 100-Meter-Läufer zu einem Marathon laufen lassen – derselbe Läufer, aber ein völlig anderer Wettkampf.

Die grundlegende Spannung zwischen der Aufzeichnung dessen, was gerade passiert, und dem Verständnis dessen, was es bedeutet, hat die Innovation in der Datenverarbeitung seit fünfzig Jahren vorangetrieben. Heute werden wir diese Entwicklung von den frühesten Transaktionsdatenbanken bis hin zu den heutigen AI-gesteuerten Analyseplattformen nachverfolgen, die Fragen in natürlicher Sprache beantworten können. Das Verständnis dieser Entwicklung ist nicht nur eine historische Rückschau, sondern auch eine Roadmap für bessere Architekturentscheidungen heute.

Die zwei Welten der Daten: OLTP und OLAP

Bevor wir uns der Chronologie widmen, sollten wir zunächst den Kernunterschied klären, der alles, was folgt, prägt.

Online Transaction Processing (OLTP)-Systeme sind darauf ausgelegt, den täglichen Betrieb eines Unternehmens zu verwalten. Sie können sich sie wie eine Registrierkasse vorstellen – sie müssen schnell, genau und immer verfügbar sein, um jede Transaktion aufzuzeichnen. Wenn Sie online Waren bestellen, Ihr Profil aktualisieren oder Geld zwischen Konten überweisen, interagieren Sie mit einem OLTP-System.

Andererseits sind OLAP (Online Analytical Processing)-Systeme für Analysen und Berichte konzipiert. Sie sind die umfassenden Berichte, die Buchhalter am Monatsende erstellen, in denen Tausende oder sogar Millionen von Transaktionen zusammengefasst werden, um Muster, Trends und Erkenntnisse aufzudecken. OLTP befasst sich mit der Frage: „Was ist gerade passiert?“, während OLAP sich fragt: „Was bedeutet all das?“

Der grundlegende Unterschied besteht darin:

OLTP-Systeme sind auf schnelles Schreiben vieler kleiner Transaktionen und sofortiges Lesen bestimmter Datensätze optimiert. OLAP-Systeme hingegen sind auf das Lesen riesiger Datenmengen, die Aggregation von Daten und komplexe Berechnungen über mehrere Dimensionen hinweg optimiert. Ein System kann diese beiden Aufgaben nicht effizient gleichzeitig erledigen – genau diese Erkenntnis hat jahrzehntelange Architekturinnovationen angestoßen.

Wichtige Erkenntnis: OLTP behandelt Echtzeitbetriebstransaktionen; OLAP behandelt auf historischen Daten basierende Analyseabfragen. Diese gegensätzlichen Anforderungen haben zu völlig unterschiedlichen Systemdesigns geführt.

Der Aufstieg von OLAP und Data Cubes (1990er Jahre)

In den 1990er Jahren hatten Unternehmen dringend Bedarf an schnelleren Datenanalyseverfahren. Die Lösung kam in Form von speziellen OLAP-Systemen auf den Markt, die ein revolutionäres Konzept einführen: Data Cubes. Diese Systeme speichern keine Rohdaten von Transaktionen mehr, sondern aggregieren Daten in mehreren Dimensionen im Voraus.

Sie können sich einen Data Cube wie eine mehrdimensionale Tabelle vorstellen. Beispielsweise können Sie den Umsatz als Maßstab (d.h. den Wert, den Sie messen möchten) festlegen und drei Dimensionen definieren: Zeit (Jahr, Quartal, Monat), Produkt (Kategorie, Marke, SKU) und geografische Lage (Land, Region, Stadt). Jede Zelle im Cube enthält einen vorausberechneten Wert, wie z.B. „der Gesamtumsatz von Nike-Laufschuhen im dritten Quartal 2023 in Kalifornien“. Das bedeutet, dass Abfragen, die früher Stunden dauerten, jetzt in wenigen Sekunden beantwortet werden können.

Drei Architekturansätze kamen auf:

MOLAP (Multidimensional OLAP)-Systeme wie Hyperion Essbase und IBM Cognos speichern Daten in optimierten mehrdimensionalen Arrays, was unglaubliche Abfrageschnelligkeiten ermöglicht, erfordert aber viel Vorverarbeitung und hat Schwierigkeiten, sehr große Datensätze zu verarbeiten.

ROLAP (Relational OLAP)-Systeme wie MicroStrategy bauen OLAP-Funktionen auf bestehenden relationalen Datenbanken auf, bieten mehr Flexibilität und Skalierbarkeit, haben aber eine langsamere Abfrageleistung.

HOLAP (Hybrid OLAP)-Systeme wie Microsoft Analysis Services versuchen, die besten Eigenschaften beider Welten zu verbinden, indem sie detaillierte Daten in relationalen Tabellen speichern und aggregierte Zusammenfassungen in mehrdimensionalen Cubes.

Die geschäftlichen Treiber waren klar:

Manager und Analysten brauchten Dashboards und Berichte, um datengesteuerte Entscheidungen zu treffen. Tools wie Business Objects, Cognos und Crystal Reports wurden zu den Frontend-Schnittstellen, während die OLAP-Engines die hinteren Berechnungen durchführten.

Wichtige Erkenntnis: OLAP-Data Cubes haben das Problem der Analyseleistung durch die Voraggregation über Dimensionen hinweg gelöst, erfordern aber viel ETL-Verarbeitung und lassen sich schlecht auf moderne Datenmengen skalieren.

Die Data Warehouse-Boomzeit (Ende der 1990er bis Anfang der 2000er Jahre)

Als der Wert von OLAP immer deutlicher wurde, erkannten Organisationen, dass sie ein zentrales Speicherlager brauchten, das speziell für Analysen optimiert ist. Data Warehouses wurden entwickelt – es handelt sich um eine themenorientierte, integrierte, zeitabhängige und nicht flüchtige Datensammlung, die für Business Intelligence konzipiert ist.

Daraus entstand die Standardarchitektur: Extract, Transform, Load (ETL)-Pipelines ziehen Daten aus mehreren Quellsystemen (CRM, ERP, Transaktionsdatenbanken) ab, bereinigen und transformieren sie gemäß geschäftlichen Regeln und laden sie in das Data Warehouse nach einem sorgfältig geplanten Schema.

Zwei Schemata dominierten:

Das Star Schema organisiert Daten um eine zentrale Faktentabelle (z.B. Verkaufstabelle) herum, umgeben von DimensionsTabellen (z.B. Kundentabelle, Produktabelle, ZeitTabelle, Standorttabelle). Diese nicht normalisierte Struktur optimiert die Leseleistung auf Kosten des Speicherplatzes.

Das Snowflake Schema normalisiert die DimensionsTabellen weiter, um Redundanzen zu reduzieren und schafft eine komplexere Struktur, die in einem Diagramm wie ein Schneeflockenmuster aussieht.

Die Unternehmens-Data Warehouses von Teradata, Netezza und Vertica brachten wichtige Innovationen ein. Sie verwendeten Spaltenorientierte Speicherung anstelle der zeilenorientierten – dies revolutionierte die Datenanalyse. Beim Berechnen des Durchschnittspreises von Milliarden von Verkaufseinträgen ermöglicht die spaltenorientierte Speicherung, dass Sie nur die Preisspalte von der Festplatte lesen und alle anderen Daten ignorieren können. Dies erhöht die Datenkompression erheblich (ähnliche Werte können gut zusammengefasst werden) und beschleunigt die Abfragen.

Sie implementierten auch die Massively Parallel Processing (MPP)-Architektur, die Daten und Abfragen auf mehrere zusammenarbeitende Knoten verteilt. Jetzt können Sie durch Hinzufügen mehrerer Maschinen zu einem Cluster horizontal skalieren.

Aber auch diese Methode hat ihre Grenzen. Das Schema muss im Voraus definiert werden (Schema-on-Write), was es teuer macht, neue Datenquellen hinzuzufügen oder die Geschäftlogik zu ändern. Die Hardware-Skalierbarkeit ist immer noch begrenzt, und die Kosten für diese Systeme betragen Hunderttausende oder sogar Millionen von Dollar.

Wichtige Erkenntnis: Data Warehouses konzentrieren Analysen durch spaltenorientierte Speicherung und MPP-Verarbeitung, sind aber immer noch teuer, unflexibel und an die Hardware gebunden.

Das Zeitalter von Big Data und Hadoop (Ende der 2000er bis 2010er Jahre)

Dann hat das Internet alles verändert. Unternehmen wie Google, Yahoo und Facebook wurden von einer Flut neuer Daten überschwemmt: Webserver-Logs, Klickströme, Sensordaten, Social-Media-Beiträge, Bilder, Videos. Diese Daten waren nicht mehr die strukturierten Transaktionsdaten, die sich schön in Datenbanktabellen einfügen lassen, sondern ungeordnet, halbstrukturiert und in einer bisher nicht gekannten Menge.

Die traditionellen Data Warehouses konnten diese Situation nicht bewältigen. Sie waren dafür konzipiert, strukturierte Daten mit einem bekannten Schema zu speichern, nicht um Roh-Logdateien oder JSON-Dokumente zu verwalten. Auch aus wirtschaftlicher Sicht war es nicht machbar – man konnte sich einfach nicht genug Teradata-Lizenzen leisten, um Petabyte an Web-Crawler-Daten zu speichern.

Google veröffentlichte Artikel, in denen es über seine internen Systeme berichtete: GFS (Google File System) für verteilte Speicherung und MapReduce für verteilte Berechnungen. Diese Systeme inspirierten die Entstehung der Open-Source-Hadoop-Ökosystem, das wiederum die Grundlage für die „Big Data“-Bewegung wurde.

Hadoop brachte zwei revolutionäre Konzepte ein:

HDFS (Hadoop Distributed File System) verteilt Daten auf allgemeiner Hardware und repliziert sie automatisch für die Fehlertoleranz. Sie können Hunderte von kostengünstigen Maschinen anstelle von teurer spezieller Hardware verwenden, um Petabyte an Daten kostengünstig zu speichern.

MapReduce ermöglicht es Ihnen, parallele Berechnungen zu schreiben, die automatisch auf allen Maschinen ausgeführt werden. Das Framework kümmert sich um alle Komplexitäten bei der Aufgabenverteilung, Fehlerverwaltung und Ergebnisaggregation.

Projekte wie Apache Hive fügten auf der Grundlage von MapReduce SQL-ähnliche Abfragefunktionen hinzu, sodass Analysten Daten in einem Data Lake mit einer vertrauten Syntax abfragen konnten. Impala und Presto (heute Trino) boten schnellere und interaktivere SQL-Engines. Spark wurde mit seinem in-Memory-Berechnungsmodell zu einer flexibleren und leistungsfähigeren Alternative zu MapReduce.

Dieses Zeitalter brachte das Konzept des Data Lakes ein – ein zentrales Speicherlager, das alle Daten in Rohform speichert und ein Schema-on-Read anstelle eines Schema-on-Write verwendet. Sie können zuerst Daten aufnehmen und erst später überlegen, wie Sie sie nutzen möchten.

Aber Hadoop hatte erhebliche Grenzen bei OLAP-Aufgaben. Abfragen dauerten oft Minuten oder sogar Stunden. Es unterstützte keine Transaktionen oder Updates – man konnte nur Daten hinzufügen. Der Betriebskomplexität war enorm, und es brauchte ein großes Team, um den Cluster am Laufen zu halten.

Wichtige Erkenntnis: Hadoop hat die Speicherung und Verarbeitung von Big Data mit allgemeiner Hardware möglich gemacht, aber seine hohe Latenz und Betriebskomplexität machen es ungeeignet für interaktive Analysen.

Cloud Data Warehouses und die Trennung von Berechnung und Speicherung (2010er Jahre)

Als die Beliebtheit von Hadoop ihren Höhepunkt erreichte, entstanden eine neue Generation von Cloud-native Data Warehouses mit einer völlig anderen Architektur. Snowflake (veröffentlicht 2014), Google BigQuery und Amazon Redshift haben die Form von Data Warehouses in der Cloud neu definiert.

Der Durchbruch lag in der vollen Trennung von Berechnung und Speicherung. Traditionelle Data Warehouses koppelten beide eng miteinander – die Daten wurden auf derselben Maschine gespeichert, die die Abfragen verarbeitete. Dies führte zu einem Dilemma: Sollte man genug Kapazität kaufen, um die Spitzenlasten an Abfragen zu bewältigen (die meisten Zeit werden die Ressourcen verschwendet), oder genug für die durchschnittliche Last (die Leistung sinkt in den geschäftigen Zeiten)?

Cloud Data Warehouses lösten dieses Problem, indem sie alle Daten in kostengünstigen und dauerhaften Objektspeichern (z.B. S3, Google Cloud Storage und Azure Data Lake Storage) speichern und Compute-Cluster nach Bedarf starten. Brauchen Sie einen großen Bericht? Skalieren Sie einfach auf 100 Knoten hoch, führen Sie die Abfrage in wenigen Minuten aus und reduzieren Sie dann die Größe. Sie zahlen nur für die Berechnungen, wenn die Abfrage läuft, und die Kosten für die statische Speicherung sind sehr niedrig.

Snowflake war der erste, der das Konzept einer wirklich elastischen „Multi-Cluster Shared Data“-Architektur einführen. BigQuery ging noch einen Schritt weiter und nutzte ein Serverless-Modell, bei dem Benutzer nicht einmal Cluster konfigurieren müssen – sie müssen nur SQL-Anweisungen schreiben, und Google weist automatisch die Ressourcen zu.

Diese Systeme brachten auch andere Vorteile mit sich:

Cloud-Ökonomie: Die nutzungsbasierte Preismodell bedeutet, dass Start-ups auf große Vorinvestitionen verzichten können und dennoch Zugang zu Unternehmensanalysediensten haben.

Augenblickliche Elastizität: Skalieren Sie die Berechnungskapazität in Sekunden je nach Arbeitslast hoch oder runter.

Nullverwaltung: Es ist keine Hardwareverwaltung erforderlich, Backups, Updates und Optimierungen werden automatisch durchgeführt.

Datenfreigabe: Teilen Sie Datensätze einfach und sicher zwischen Organisationen.

Dank Innovationen in der spaltenorientierten Formatierung, fortschrittlichen Kompression und intelligenten Abfrageoptimierung ist die Leistung auch hervorragend. Cloud Data Warehouses können Petabyte an Daten in Sekunden scannen.

Wussten Sie das?

Snowflake wurde von mehreren Data Warehouse-Experten aus Oracle gegründet, die sich die Frage stellten: „Was wäre, wenn wir ein Data Warehouse