Klausurzusammenfassung: Big Data Storage

Gemeinsame Lernzusammenfassung aus Slides und Readern der bereitgestellten Unterrichtseinheiten

Fokus: begründete Architekturentscheidungen, klare Abgrenzungen, zentrale Abläufe, Formeln, Diagrammdeutung und typische Prüfungsfallen.

Druckhinweis: Im Browser über Drucken > Als PDF speichern exportieren. Sinnvolle Einstellungen: Papierformat A4, Skalierung 100 %, Browser-Kopf- und Fußzeilen deaktivieren, Hintergrundgrafiken aktivieren.

1. Überblick und Prüfungslogik

Big Data Storage ist keine Produktliste. Die Vorlesung trainiert eine wiederverwendbare Entscheidungskette: Aus Datenform, Zugriffsmuster, Latenzbedarf und Fachrisiko wird eine passende Speicher- oder Verarbeitungsschicht abgeleitet. Eine gute Klausurantwort beginnt deshalb mit der Aufgabe und endet erst dann bei einem Systemnamen.

Prüfungskern: Begründe jede Wahl entlang derselben Kette: Datenform → dominanter Zugriff → Qualitätsziel → Speicher- oder Verarbeitungslogik → begründete Systemwahl Typische Qualitätsziele sind Latenz, Durchsatz, Konsistenz, Verfügbarkeit, Fehlertoleranz, Kosten und Governance.

Die Ebenen bauen aufeinander auf. Wer an der falschen Ebene optimiert, verschiebt das Problem nur.

Quellenumfang: Ausgewertet wurden 40 PDFs mit insgesamt 511 Seiten: jeweils Slides und Reader für UE01-UE05, UE08-UE19, UE21, UE24 und UE26. Nicht im Ordner enthalten waren UE06/UE07, UE20, UE22/UE23 und UE25. Aussagen zu Spark bleiben deshalb auf die in UE24 bereitgestellte Vergleichseinordnung begrenzt.

2. Grundlagen: Datenformen, Workloads und Zugriffsmuster

2.1 Warum Storage früh entschieden wird

Big Data ist nicht nur eine Frage des Volumens. Speicherarchitektur bestimmt, wie Daten abgelegt, verschoben, repliziert und gelesen werden. Sobald Daten auf mehrere Maschinen verteilt werden, entstehen Netzwerklatenz, Koordinationskosten und Ausfallrisiken. Storage ist deshalb Strukturgeber: Er begrenzt die Möglichkeiten der darüberliegenden Ebenen.

Big Data aus Storage-Sicht: Ein Datenproblem wird zum Big-Data-Problem, wenn Menge, Vielfalt oder Entstehungsgeschwindigkeit die bisherigen Speicher-, Transport- oder Zugriffsmuster untragbar machen. Die drei klassischen Treiber sind Volume, Variety und Velocity.

2.2 Datenformen

Datenform	Beispiele	Typische Anforderungen	Wichtige Prüfungsfrage
Tabellarisch	Bestellungen, Rechnungen, Stammdaten	Schema, Schlüssel, Integrität, gezielte Updates	Dominieren transaktionale Einzelzugriffe oder analytische Scans?
Semi-strukturiert	JSON-Dokumente, Events, Logs	Flexible Attribute, Append-Aufnahme, Indexierung ausgewählter Felder	Welche Felder werden gemeinsam gelesen und welche müssen suchbar sein?
Unstrukturiert	Bilder, Videos, Archive, große Binärdateien	Objektablage, Metadaten, Lebenszyklus, günstige Speicherung	Wie werden Objekte adressiert, gefunden und später verarbeitet?

Prüfungsfalle: Datenform allein entscheidet nicht. „Wir haben JSON, also brauchen wir einen Document Store“ ist unvollständig. JSON ist Syntax. Erst das Zugriffsmuster begründet die physische Organisation.

2.3 Zugriffsmuster und physische Konsequenzen

Zugriffsmuster	Typische Frage	Physische Konsequenz	Naheliegende Speicherlogik
Point Lookup	„Gib mir genau Datensatz k.“	Index, Hash-Struktur oder schlüsselnahe Ablage	Transaktionales DBMS, Key-Value Store, HBase
Range Scan	„Lies alle Events im Zeitfenster.“	Sortierung, Range-Partitionierung, sequenzieller Zugriff	Scanfreundliche Ablage, Wide Column, analytische Formate
Append	„Nimm fortlaufend neue Events auf.“	Sequentielles Schreiben, geringe Reorganisation	Log-, DFS- oder Object-Store-nahe Aufnahme
Batch Read	„Verarbeite einen großen Bestand am Stück.“	Durchsatz, Datenlokalität, große Lesebereiche	DFS, Object Store plus Processing Engine

2.4 Workload-Achsen

Achse	Variante	Priorität	Typische Folge
OLTP vs. OLAP	OLTP	Kleine, schnelle, konsistente Transaktionen	Niedrige Latenz, Point Lookups, Updates, starke Regeln
OLTP vs. OLAP	OLAP	Analyse, Aggregation, große Datenbereiche	Scans, Durchsatz, oft denormalisierte oder spaltennahe Ablage
Batch vs. Streaming	Batch	Verarbeitung größerer Pakete zu definierten Zeitpunkten	Sequenzzugriff, Kosten- und Durchsatzoptimierung
Batch vs. Streaming	Streaming	Kontinuierliche Aufnahme und zeitnahe Reaktion	Stabile Ingestion, Event-Modell, Latenzorientierung

Mini-Fall ShopNow: Orders benötigen Point Lookups, Updates und klare Konsistenz. Klick-Events werden fortlaufend angehängt und später im Batch ausgewertet. Produktbilder sind große Objekte mit Metadaten. Eine belastbare Architektur trennt diese Zugriffswelten, obwohl sie zum selben Unternehmen gehören.

3. Partitionierung, Replikation, Konsistenz und CAP

3.1 Partitionierung und horizontale Skalierung

Partitionierung verteilt Daten und Last auf mehrere Knoten. Sie erhöht Kapazität und ermöglicht Parallelität, löst aber weder Replikation noch Konsistenz oder Fehlertoleranz automatisch. Die Sharding-Strategie muss zum dominanten Zugriff passen.

Kriterium	Range-Sharding	Hash-Sharding
Grundidee	Zusammenhängende Wertebereiche bleiben zusammen.	Eine Hashfunktion verteilt Schlüssel gleichmäßiger.
Stärke	Bereichsabfragen und zeitliche Ordnung	Point Lookups und Lastverteilung
Risiko	Hotspots bei monoton wachsenden oder beliebten Bereichen	Schwache Unterstützung für Range Queries
Beispiel	Telemetrie nach Region und Zeitfenster	Sessions nach Session-ID

Hotspot: Eine Partition oder ein Schlüssel erhält überproportional viel Last. Gegenmaßnahmen sind feinere Partitionen, bessere Schlüsselwahl, virtuelle Knoten, Caching oder eine fachliche Aufteilung besonders heißer Schlüssel.

3.2 Consistent Hashing und Rebalancing

Bei klassischem Hashing kann das Hinzufügen eines Knotens große Teile des Datenraums neu zuordnen. Consistent Hashing ordnet Schlüssel und Knoten auf einem Ring an. Ein Schlüssel gehört dem nächsten verantwortlichen Knoten im Uhrzeigersinn. Beim Wachstum wechseln nur begrenzte Ringsegmente ihren Besitzer. Virtuelle Knoten verteilen die Last feiner.

Das Ringmodell begrenzt die Umverteilung beim Hinzufügen oder Entfernen von Knoten. Virtuelle Knoten glätten ungleiche Last.

3.3 Replikation: Nutzen und Preis

Replikation hält denselben logischen Datenbestand in mehreren Kopien. Das verbessert Ausfallschutz, Leseentlastung und regionale Nähe. Jede zusätzliche Kopie erzeugt aber Koordinationsaufwand. Replikation ist nicht dasselbe wie Backup: Sie dient der fortlaufenden Betriebsfähigkeit, nicht primär der nachträglichen Wiederherstellung.

Variante	Write gilt als erfolgreich, wenn ...	Vorteil	Preis
Synchron	die erforderlichen Replikate bestätigt haben.	Aktueller, eindeutiger Sichtstand	Mehr Latenz und Abhängigkeit von Netz und Replikaten
Asynchron	eine primäre Annahme erfolgt ist; Kopien folgen später.	Geringere Schreiblatenz, höhere Verfügbarkeit	Stale Reads und zeitweilige Konflikte

3.4 Konsistenzmodelle und CAP

Strong Consistency bedeutet: Nach einem erfolgreichen Write sehen nachfolgende Reads den aktuellen Stand. Eventual Consistency erlaubt vorübergehend unterschiedliche Sichtstände; ohne neue Writes gleichen sich die Kopien wieder an. Read-Your-Writes ist eine praxisnahe Zwischengarantie: Ein Nutzer sieht zumindest die eigenen Änderungen unmittelbar.

CAP ist keine freie Auswahl von zwei Buchstaben im Normalbetrieb. Es beschreibt die unvermeidbare Priorisierung im Störungsfall einer Netzpartition.

Prüfungsfallen: CAP und ACID liegen auf unterschiedlichen Ebenen. ACID beschreibt Eigenschaften von Transaktionen: Atomarität, Konsistenz im Datenbanksinn, Isolation und Dauerhaftigkeit. CAP beschreibt die Entscheidung eines verteilten Systems bei Kommunikationsstörung. „ACID widerspricht CAP“ ist falsch.

4. Storage-Paradigmen als Vergleichssprache

Ein Storage-Paradigma ist ein Ordnungsversprechen: Wie werden Daten adressiert, welche Struktur liefert das System und welche Operationen sind natürlich? Die konzeptionelle Ebene ist wichtiger als einzelne Produktnamen.

Paradigma	Adressierung	Natürliche Stärke	Typische Grenze	Beispiele für Einsatzfelder
Block Storage	Offset oder Blockadresse	Performante Infrastrukturgrundlage	Keine Fachstruktur, keine Dateisicht	VM-Disks, DB-Volumes, SAN- oder Cloud-Volumes
File Storage	Pfad und Verzeichnis	Vertraute hierarchische Dateiorganisation	Namensraum und Metadaten können skalierungsrelevant werden	Teamdokumente, klassische Freigaben
Object Storage	Objektschlüssel und Metadaten	Große Objektmengen, Archive, Plattformdaten	Keine klassische Dateiillusion, keine reiche Query-Semantik	Data Lakes, Medien, Backups, Exporte
Key-Value	Schlüssel k	Sehr schnelle Direktzugriffe	Beziehungen, Ad-hoc-Filter und Range Queries sind sperrig	Sessions, Cache, Warenkorbzustände
DB-nah	Modell und Query	Strukturierte Fachdaten und gezielte Abfragen	Je nach Modell komplexer und teurer im Betrieb	Transaktionen, Dokumente, Wide Column, Graph

Prüfungsfalle: Ein Object Store ist kein „modernes Dateisystem“ und eine Datenbank kein universeller Speicher. Das Paradigma muss zu Adressierung, Zugriff und Fachmodell passen.

5. NoSQL: Motivation, Familien und Konsistenz

5.1 NoSQL als Antwort auf konkrete Probleme

NoSQL ist weder ein einzelnes System noch eine pauschale Ablehnung relationaler Datenbanken. Die Treiber sind horizontale Skalierung, globale Nähe, hohe Last, flexible Datenformen und teure verteilte Joins. Relationale Systeme bleiben für viele transaktionale Fälle stark. Die Frage lautet: Welche Lastprofile und Modellformen machen andere Antworten plausibel?

Rahmen	Kernidee	Typischer Fit	Preis
ACID	Klare Eigenschaften korrekter Transaktionen	Kritische Buchungen, eindeutige Zustandsänderungen	Starke Koordination kann unter Verteilung teuer werden
BASE	Basically Available, Soft State, Eventually Consistent	Globale Verteilung mit tolerierbaren zeitlichen Abweichungen	Mehr Komplexität bei Sichtbarkeit, Konflikten und Dateninterpretation

Denormalisierung ist eine typische Reaktion auf verteilte Zugriffskosten: Häufig gemeinsam gelesene Informationen werden näher zusammengelegt, um verteilte Joins und Folgezugriffe zu vermeiden. Das ist keine pauschale Regel, sondern eine Workload-Entscheidung.

5.2 NoSQL-Familien im Vergleich

Familie	Modell	Natürliche Stärke	Leitfrage	Typische Grenze
Key-Value	k → v	Sehr schneller Zugriff pro Schlüssel	Ist der Key bereits die Antwort?	Komplexe Struktur bleibt außerhalb des Modells.
Document	Fachlich zusammengehörendes Dokument	Gemeinsames Lesen und Schreiben einer Einheit	Was gehört als Objekt zusammen?	Querbeziehungen und globale Konsistenzpfade werden aufwendig.
Wide Column	Row Key, Column Families, Cells	Geordnete Bereiche und große verteilte Tabellen	Welcher Row Key trägt den Zugriff?	Spontane Kreuzabfragen sind schwierig.
Graph	Knoten, Kanten, Pfade	Beziehungen, Nachbarschaften, Traversierungen	Sind Kanten das eigentliche Fachobjekt?	Einfache Objektwelten brauchen oft kein Graphmodell.

5.3 Key-Value Stores

Key-Value Stores verengen das Modell bewusst auf wenige Operationen: put(k, v), get(k) und delete(k). Diese Einfachheit ermöglicht kurze Zugriffspfade und gut verteilbare Last. Sie ist stark, wenn der Schlüssel bekannt ist, etwa bei Sessions oder Cache-Einträgen.

Grenze: Sobald Range Queries, freie Filter oder Beziehungen dominieren, kippt die Stärke in Mehrarbeit. Zusätzliche Indizes können helfen, aber sie schwächen die ursprüngliche Einfachheit.

5.4 Document Stores

Ein Dokument ist keine Datei, sondern eine fachliche Zugriffseinheit mit eigener Identität und flexibel strukturierten Feldern. Zusammen gespeichert wird, was häufig zusammen gelesen oder geschrieben wird. Einbettung und Referenzierung sind keine Stilfragen, sondern Folgen von Zugriff und Pflege.

Kriterium	Einbettung	Referenz
Gemeinsamer Zugriff	Sehr häufig gemeinsam gelesen	Eher getrennte Zugriffe
Update-Verhalten	Zusammen änderbar	Separat gepflegt oder geteilt
Wachstum	Begrenzt und kontrollierbar	Groß oder dynamisch wachsend

Flexible Dokumente machen Indizes nicht überflüssig. Ohne Index muss eine Anfrage potenziell viele Dokumente prüfen. Indexierung bleibt Teil der Modellierungsentscheidung.

5.5 Wide Column Stores

Wide Column Stores organisieren große Datenbereiche über einen Row Key und Column Families. Wide Rows bündeln viele zusammengehörende Werte; Sparse Columns erlauben unterschiedliche Zellbelegungen. Der Row Key ist die eigentliche Modellentscheidung, weil er Partitionierung, Lesepfad und Hotspot-Risiko prägt.

Beispiel für einen Row Key bei Sensordaten sensor-17#2026-04-16

Der Präfix identifiziert den Sensor, der Zeitanteil begrenzt die Größe einer Wide Row und ermöglicht Bereichszugriffe für ein bestimmtes Zeitfenster.

Schreiboptimierte Systeme nutzen häufig eine LSM-nahe Idee: Neue Werte werden zunächst effizient aufgenommen und später geordnet zusammengeführt. HBase und Cassandra werden in der Vorlesung grob unterschieden: HBase eher mit mastergesteuerter Verwaltung von Regionen, Cassandra eher mit Peer-to-Peer-orientierter Knotenstruktur.

5.6 Quorum, Konflikte und Reparatur

Quorum-Regel R + W > N

N: Anzahl der Replikate.
W: Anzahl der Replikate, die einen Write bestätigen müssen.
R: Anzahl der Replikate, die ein Read abfragt.

Wenn R + W > N gilt, überlappen Read- und Write-Sicht. Beispiel: Für N = 3, W = 2 und R = 2 gilt 2 + 2 > 3.

Quorum ist eine Gestaltungsregel, kein magisches Sicherheitszeichen. Latenzen, Ausfälle, veraltete Replikate und Reparaturmechanismen bleiben relevant. Typische Mechanismen sind Read Repair, spätere Angleichung und Konfliktregeln wie Last-Write-Wins. Diese Regeln sind fachlich nicht neutral: Sie entscheiden, welche Information erhalten bleibt.

Fachrisiko zuerst: Ein Social-Media-Like toleriert meist kurze Verzögerungen. Ein Warenkorb benötigt häufig Read-Your-Writes. Eine Sitzplatzbuchung verlangt engere Garantien, weil doppelte Vergabe direkten Schaden erzeugt.

6. Distributed File Systems und HDFS

6.1 Problemklasse eines DFS

Ein Distributed File System ist keine größere Festplatte und kein großes NAS. Es beantwortet eine andere Problemklasse: große Datenmengen, hoher sequenzieller Durchsatz, Parallelität und Fehlertoleranz über mehrere Knoten. HDFS dient als Grundmodell.

Aspekt	Lokales File System	Distributed File System
Kapazität	An einen Rechner gebunden	Über viele Knoten erweiterbar
Durchsatz	Durch einzelne Maschine begrenzt	Paralleles Lesen und Schreiben möglich
Fehlertoleranz	Ausfall des Hosts ist kritisch	Replikation und Verteilung puffern Ausfälle ab
Verwaltung	Lokale Metadaten und Pfade	Koordinierte Metadaten über verteilte Blöcke

6.2 HDFS-Grundarchitektur

Der NameNode verwaltet Metadaten und Platzierungswissen. Der große Datenstrom läuft direkt über die DataNodes.

Rolle	Aufgabe	Typischer Denkfehler
Client	Startet Lese- und Schreibvorgänge	Wird fälschlich als interner Clusterknoten gelesen.
NameNode	Verwaltet Namensraum, Blöcke und Speicherorte	Wird für den eigentlichen Datenspeicher gehalten.
DataNode	Speichert Blöcke und transportiert Daten	Wird nur als passive Festplatte verstanden.

6.3 Read Path und Write Path

Pfad	Ablauf	Warum relevant?
Write Path	Client meldet neuen Block → NameNode plant DataNodes → Client schreibt in Replikationskette → Bestätigungen laufen zurück.	Replikation und Rack Awareness sind bereits Teil des Schreibpfads.
Read Path	Client fragt Blockorte beim NameNode → Client liest Blockdaten direkt von geeigneten DataNodes.	Metadaten- und Datenpfad sind getrennt; der NameNode wird vom großen Datenstrom entlastet.

6.4 Fehlertoleranz und Grenzen

Heartbeats machen Ausfälle sichtbar. Block Reports halten das Metadatenbild über die reale Blockverteilung aktuell. Replikation ermöglicht Lesbarkeit und Neuaufbau trotz DataNode-Ausfall. Rack Awareness verteilt Kopien so, dass der Ausfall eines Racks nicht alle Replikate trifft.

Datenlokalität ist ein Leistungsprinzip: Rechenlogik soll möglichst nahe an bereits gespeicherten Blöcken ausgeführt werden. Für sehr große Datenmengen ist Netztransport häufig teurer als lokale Berechnung.

HDFS-Anti-Patterns: Sehr viele kleine Dateien belasten Metadatenverwaltung. Niedrige Einzellatenz, viele Random Writes und transaktionale Point Lookups passen ebenfalls schlecht. HDFS ist für robusten Durchsatz großer Dateien gebaut.

7. Object Stores, Data Lake und Lakehouse

7.1 Objektmodell und API

Object Stores organisieren Daten als Objekte mit Schlüssel, Payload und Metadaten in einem Bucket. Der Namespace ist logisch flach; Pfadbestandteile sind häufig Teil des Schlüssels, aber keine klassischen Verzeichnisse. Die kleine API ist bewusst einfach:

PUT → GET → LIST → DELETE

LIST ist nützlich, aber nicht kostenlos. Anwendungen sollten nicht voraussetzen, dass beliebige Verzeichnisillusionen dieselben Eigenschaften wie ein lokales Dateisystem besitzen. Ein guter Objektschlüssel strukturiert Nutzung, Auffindbarkeit und Lifecycle.

Durability vs. Availability: Durability beschreibt, wie unwahrscheinlich Datenverlust ist. Availability beschreibt, ob ein Dienst erreichbar und nutzbar ist. Ein System kann sehr dauerhafte Speicherung bieten und trotzdem zeitweise nicht erreichbar sein.

7.2 DFS und Object Store vergleichen

Kriterium	DFS / HDFS	Object Store
Modell	Datei- und Blocklogik	Objekt- und API-Logik
Zugriff	Dateisystemnah, pfadorientiert	Schlüssel- und API-orientiert
Stärke	Compute-Nähe, Batch-Logik, Datenlokalität	Plattformspeicher, Skalierung, Entkopplung, Wirtschaftlichkeit
Grenze	Small Files, Plattformoffenheit, enge Kopplung	Dateiillusion, bestimmte Pfaderwartungen, keine eigene Verarbeitung

7.3 Data Lake und Lakehouse

Ein Data Lake ist ein Architekturprinzip: Rohdaten werden zentral und offen abgelegt, sodass verschiedene Teams und Engines später darauf zugreifen können. Speicher und Compute werden entkoppelt. Ein Lakehouse verbindet diese offene Speicherbasis mit mehr Tabellenlogik, Struktur und Governance. Es ist keine dritte Speichergrundform, sondern eine stärker organisierte Architektur auf Lake-naher Basis.

Die Entkopplung von Storage und Compute ist eine Plattformentscheidung, kein Selbstzweck.

8. Hadoop-Ökosystem und MapReduce

8.1 Komponenten sauber trennen

Komponente	Aufgabe	Nicht verwechseln mit ...
HDFS	Verteilte Speicherung von Rohdaten, Zwischen- und Endergebnissen	Verarbeitungslogik
YARN	Ressourcen, Container und Laufzeitplätze koordinieren	Datenhaltung
MapReduce	Batch-Verarbeitung als geordneter Datenfluss	Speicher oder Ressourcenplanung
Metastore	Tabellen-, Schema- und Partitionssicht über Dateien	Eigene physische Datenhaltung

8.2 MapReduce als Batch-Paradigma

Die Shuffle-Phase ist die teure Mitte: Verteilung ist nicht kostenlos, weil zusammengehörige Schlüssel über das Netz neu zusammengeführt werden müssen.

Beispiel Fehlercodes zählen: Map liest Logblöcke lokal und erzeugt Paare wie (404, 1). Shuffle bringt gleiche Codes zusammen. Reduce summiert die Werte zu Gesamtzahlen. Das passt gut, weil die Eingaben groß, bereits vorhanden und klar gruppierbar sind.

MapReduce ist stark für klare, abgeschlossene Batch-Probleme. Es ist schwach bei interaktiver Reaktion, vielen Iterationen und flexiblen Rückkopplungen. Spark wird in den bereitgestellten Unterlagen als flexiblere Processing Engine eingeordnet: reichere Arbeitspläne statt einer starren Pipeline. Spark ist aber kein Speicher.

9. Systemvergleich und Architekturwahl

9.1 Vergleichsraum

System	Rolle	Typische Stärke	Typische Grenze	Prüfungssatz
HDFS	Verteilte Speicherbasis	Große Dateien, Batch-Nähe, Datenlokalität	Nicht für schnellen Einzeldatenzugriff	„HDFS passt, wenn robuste verteilte Speicherung großer scanlastiger Dateien dominiert.“
Object Store	Lose gekoppelte Plattform-Speicherbasis	Offene Nutzung, Skalierung, Wirtschaftlichkeit	Keine eigene Verarbeitung oder Fachlogik	„Der Object Store passt, wenn Storage und Compute entkoppelt werden sollen.“
MapReduce	Batch-Processing	Klare Map-Shuffle-Reduce-Pipeline	Sperrig bei reicheren Verarbeitungswegen	„MapReduce passt zu einer großen, abgeschlossenen und gut gruppierbaren Batch-Aufgabe.“
Spark	Flexiblere Processing Engine	Reichere Arbeitspläne und mehrstufige Analyse	Kein Speicher und keine Antwort auf jede Zugriffsfrage	„Spark passt besser, wenn die Analyse eine flexible Folge mehrerer Verarbeitungsschritte verlangt.“
HBase	Zugriffsnaher Wide Column Store	Gezielte Zugriffe auf große strukturierte Datenmengen	Nicht primär für freie Großanalyse	„HBase liegt näher, wenn gezielter Zugriff über Schlüssel oder Bereiche dominiert.“

9.2 Entscheidung in vier Schritten

Aufgabe benennen: Speicherung, Analyse, gezielter Zugriff oder Plattformbasis?
Kriterium nennen: Zugriffsmuster, Latenz, Konsistenz, Datenform, Flexibilität, Kosten oder Governance?
System einordnen: Speicherbasis, Processing Engine, Ressourcensteuerung oder zugriffsnahes System?
Passung und Grenze begründen: Warum trägt die Wahl den Workload besser als eine plausible Alternative?

Eine reale Architektur kann mehrere Systeme kombinieren. Mehr Systeme sind nur dann sinnvoll, wenn tatsächlich verschiedene dominante Teilaufgaben vorliegen.

CampusShop: Tägliche Berichte sind ein Analyseproblem: Rohdatenbasis plus MapReduce oder Spark. Das schnelle Nachschlagen einzelner Bestellungen ist ein Zugriffsproblem: HBase liegt näher. Die stärkere Antwort sucht nicht ein System für alles, sondern ordnet Rollen sauber zu.

10. Klausurstrategie und Musterantworten

10.1 Operatoren lesen

Operator	Erwartung	Gute Antwortform
Einordnen	Rolle, Ebene oder Kategorie sichtbar machen	Kategorie nennen und kurz mit Aufgabenbezug absichern
Vergleichen	Zwei Gegenstände entlang derselben Kriterien gegenüberstellen	Gemeinsames Kriterium, Unterschied, Konsequenz
Begründen	Entscheidung aus Aufgabe und Kriterium ableiten	Aufgabe benennen, Kriterium nennen, Passung sprachlich herstellen
Skizzieren	Wenige Kernkomponenten mit klaren Beziehungen zeigen	Rollen beschriften, Daten- und Metadatenpfad unterscheiden

10.2 Musterantworten

Aufgabe: Ordnen Sie HBase ein.

HBase ist ein zugriffsnaher Wide Column Store. Es passt zu großen strukturierten Datenmengen, wenn gezielte Zugriffe über Row Keys oder begrenzte Bereiche dominieren. Für freie Großanalyse ist eine Processing Engine näherliegend.

Aufgabe: Vergleichen Sie MapReduce und Spark im Hinblick auf Flexibilität.

MapReduce bildet eine feste Pipeline aus Map, Shuffle und Reduce. Das ist stark für klar strukturierte Batch-Probleme. Spark ist flexibler, wenn mehrere Operatoren und aufeinanderfolgende Verarbeitungsschritte gebraucht werden. Spark ist deshalb nicht pauschal besser, sondern für reichere Analyseabläufe passender.

Aufgabe: Begründen Sie Object Store statt HDFS für eine Rohdatenplattform.

Ein Object Store passt besser, wenn Storage als offene, wirtschaftliche Plattformbasis dienen soll und mehrere Engines unabhängig darauf zugreifen. HDFS liegt näher, wenn compute-nahe Batch-Verarbeitung mit Datei- und Blocklogik im Vordergrund steht.

Aufgabe: Erläutern Sie die CAP-Entscheidung bei einer Sitzplatzbuchung.

Bei einer Netzpartition ist Partition Tolerance gesetzt. Da doppelte Vergabe fachlich teuer ist, sollte das System eher Konsistenz priorisieren und notfalls Anfragen blockieren, statt widersprüchliche Buchungen verfügbar zu halten.

10.3 Schwache Antworten verbessern

Schwach	Warum schwach?	Tragfähig
„Spark ist besser, weil es moderner ist.“	Kein Kriterium, kein Aufgabenbezug	„Spark passt besser, wenn eine flexible Folge mehrerer Verarbeitungsschritte benötigt wird.“
„JSON bedeutet Document Store.“	Syntax wird mit Modell und Speicher verwechselt	„Ein Document Store liegt nahe, wenn ein flexibles Fachobjekt häufig als Einheit gelesen und geschrieben wird.“
„HDFS skaliert, also passt es.“	Skalierung ohne Workload ist zu grob	„HDFS passt für große, scanlastige Dateien und batchnahe Verarbeitung; schnelle Point Lookups sprechen dagegen.“

11. Lerncheckliste und mögliche Klausurfragen

11.1 Lerncheckliste

Ich kann aus Datenform und Zugriffsmuster eine Speicherlogik ableiten.
Ich kann Point Lookup, Range Scan, Append und Batch Read mit physischen Folgen erklären.
Ich kann OLTP von OLAP sowie Batch von Streaming unterscheiden.
Ich kann Range- und Hash-Sharding vergleichen und Hotspots erklären.
Ich kann Consistent Hashing, virtuelle Knoten und Rebalancing einordnen.
Ich kann synchrone und asynchrone Replikation sowie Strong, Eventual und Read-Your-Writes vergleichen.
Ich kann CAP korrekt auf den Partition-Fall beziehen und ACID davon trennen.
Ich kann Block, File, Object, Key-Value und DB-nahe Paradigmen unterscheiden.
Ich kann Key-Value, Document, Wide Column und Graph vom Workload her begründen.
Ich kann die Quorum-Regel R + W > N anwenden und ihre Grenze erklären.
Ich kann HDFS-Rollen, Read Path, Write Path, Datenlokalität und Small-Files-Problem erklären.
Ich kann Object Stores von Dateisystemen unterscheiden und Data Lake sowie Lakehouse einordnen.
Ich kann HDFS, YARN, MapReduce und Metastore sauber trennen.
Ich kann Map, Shuffle und Reduce an einem Beispiel erläutern.
Ich kann HDFS, Object Store, MapReduce, Spark und HBase entlang derselben Kriterien vergleichen.
Ich beginne Klausurantworten mit Aufgabe und Kriterium, nicht mit einem Produktnamen.

11.2 Mögliche Klausurfragen

Leiten Sie für Orders, Events und Produktbilder jeweils eine passende Speicherlogik aus dem Zugriffsmuster ab.
Vergleichen Sie Range-Sharding und Hash-Sharding. Wann entstehen Hotspots?
Erläutern Sie CAP für einen Zahlungsdienst und für einen globalen Produktkatalog.
Vergleichen Sie ACID und BASE. Warum ist keiner der beiden Rahmen pauschal „besser“?
Begründen Sie, wann ein Key-Value Store ungeeignet wird.
Entwerfen Sie einen Row Key für Sensordaten und erläutern Sie mögliche Hotspots.
Berechnen und interpretieren Sie für N = 5, R = 3, W = 3, ob eine Read-Write-Überlappung vorliegt.
Skizzieren Sie HDFS-Write-Path und -Read-Path. Welche Aufgabe erfüllt der NameNode?
Warum sind Small Files für HDFS problematisch?
Vergleichen Sie HDFS und Object Store entlang von Modell, Zugriff, Performance, Kosten und Governance.
Erläutern Sie die MapReduce-Pipeline am Beispiel einer Fehlercode-Aggregation.
Ordnen Sie HDFS, Object Store, MapReduce, Spark und HBase in eine Architektur für Reporting und schnellen Kundenzugriff ein.

12. Abdeckung der bereitgestellten Unterrichtseinheiten

Folie/Kapitel	Inhalt	In Zusammenfassung enthalten?	Wo behandelt?
UE01 Slides + Reader	Kursüberblick, Storage-Perspektive, Big-Data-Stack, Workloads	Ja	Kapitel 1 und 2
UE02 Slides + Reader	Datenformen, Zugriffsmuster, Ableitung der Speicherlogik	Ja	Kapitel 2
UE03 Slides + Reader	Partitionierung, Range- und Hash-Sharding, Hotspots, Consistent Hashing	Ja	Kapitel 3.1 und 3.2
UE04 Slides + Reader	Replikation, Strong/Eventual Consistency, Read-Your-Writes, CAP, ACID-Abgrenzung	Ja	Kapitel 3.3 und 3.4
UE05 Slides + Reader	Block, File, Object, Key-Value und DB-nahe Storage-Paradigmen	Ja	Kapitel 4
UE08 Slides + Reader	NoSQL-Motivation, ACID, BASE, Denormalisierung, Familien	Ja	Kapitel 5.1 und 5.2
UE09 Slides + Reader	Key-Value API, Hashing, Ringmodell, virtuelle Knoten, Konflikte	Ja	Kapitel 3.2 und 5.3
UE10 Slides + Reader	Document Stores, Einbettung, Referenzen, Indizes, Grenzen	Ja	Kapitel 5.4
UE11 Slides + Reader	Wide Column, Row Keys, Column Families, Sparse Columns, LSM-Idee, HBase/Cassandra	Ja	Kapitel 5.5
UE12 Slides + Reader	Konsistenzmodelle, Quorum, Konfliktlösung, Reparatur, Fachrisiko	Ja	Kapitel 5.6
UE13 Slides + Reader	NoSQL-Vergleich und Use Cases	Ja	Kapitel 5.2 bis 5.6
UE14 Slides + Reader	DFS-Motivation, Anforderungen, HDFS-Grundbild, Datenlokalität	Ja	Kapitel 6.1 und 6.2
UE15 Slides + Reader	HDFS-Rollen, Metadatenpfad, Write Path, Read Path, Rack Awareness	Ja	Kapitel 6.2 und 6.3
UE16 Slides + Reader	HDFS-Fehlertoleranz, Heartbeats, Block Reports, Small Files, Grenzen	Ja	Kapitel 6.4
UE17 Slides + Reader	Object Stores, Bucket, Objekt, Metadaten, API, Durability und Availability	Ja	Kapitel 7.1
UE18 Slides + Reader	DFS vs. Object Store, Data Lake, Lakehouse, Entkopplung von Storage und Compute	Ja	Kapitel 7.2 und 7.3
UE19 Slides + Reader	Hadoop-Ökosystem: HDFS, YARN, MapReduce, Metastore	Ja	Kapitel 8.1
UE21 Slides + Reader	MapReduce als Batch-Paradigma, Map, Shuffle, Reduce, Datenlokalität	Ja	Kapitel 8.2
UE24 Slides + Reader	Vergleich von HDFS, Object Store, MapReduce, Spark und HBase	Ja	Kapitel 9
UE26 Slides + Reader	Klausurtraining: Einordnen, Vergleichen, Begründen	Ja	Kapitel 10 und 11