Suchen

Tools und Workflows zur Datenspeicherung in der Cloud, Teil 1

Datenbanken und Data Warehouses unter AWS

Seite: 2/2

Firma zum Thema

Data Warehousing mit RedShift

Zwar kann man auch Data Warehouse-Lösungen auf AWS-Instanzen betreiben, interessanter ist hier aber allemal der von AWS als verwaltetes Data Warehouse bereitgestellte Dienst AWS RedShift. Der Einsatz von RedShift empfiehlt sich insbesondere dann, wenn ScaleOut zwingend benötigt wird.

Konfiguration einer Data-Warehouse-Infrastruktur unter RedShift.
Konfiguration einer Data-Warehouse-Infrastruktur unter RedShift.
(Bild: Drilling / AWS Germany GmbH)

Obwohl es sich auch bei Data Warehouses prinzipiell um relationale Datenbanken handelt, unterstützt RedShift einen horizontalen ScaleOut auf bis zu 128 Knoten vom Typ ds2.8xlarge mit 244 Gigabyte RAM und einer maximalen Cluster-Kapazität von 2 Petabyte. Im Detail hängt die maximale Anzahl von RedShift-Knoten vom Knotentyp ab.

Prinzipiell unterstützt RedShift bis zu 100 Datenbanken pro Konto, 100 Tabellen pro Datenbank und 20.000 Partitionen pro Tabelle. Im Gegensatz zu herkömmlichen SQL-Datenbanken sind die Daten hier spaltenweise gespeichert. Dies ist allein schon deshalb sinnvoll, weil man beim Reporting mit überwiegend lesenden Zugriffen rechnet.

Darüber hinaus lassen sich die Daten sehr effizient aggregieren, da die spaltenweise Speicherung z. B. für Summenbildung und Aggregationen optimiert ist, und extrem hoch komprimieren. Red Shift kann die Daten optional verschlüsseln und ist als relationale Datenbank kompatibel mit vielen bekannten BI-Tools, weil man über gängige ODBC-/ JDBC-Treiber (konkret wird der Postgres-Treiber verwendet) auf die Daten zugreift.

Elastic Map Reduce

Aufgrund der schnellen und einfachen Verfügbarkeit von Map Reduce auf AWS – z. B. in Form des Services Elastic Map Reduce (EMR) – und weil Hadoop z. B. mittels HiveQL auch Quasi-SQL-Abfragen unterstützt, nutzt eine wachsende Anzahl von AWS-Anwendern auch Hadoop als Data-Warehouse-Lösung bzw. für Analytics-Aufgaben. Dies ist zwar durchaus möglich, allerdings wurde Hadoop keineswegs zu diesem Zweck entwickelt oder in irgendeiner Weise optimiert.

Hadoop ist eine verteilte Rechen-Engine (Compute) und wird primär eingesetzt, um komplexe Berechnungen auf großen Datenmengen auszuführen, bzw. für komplexe ETL-Jobs. Allerdings lässt sich Hadoop durchaus hervorragend als Vorverarbeitungsstufe für RedShift verwenden.

Ein klassischer Use Case hierfür wäre das Bereinigen bzw. Aufbereiten von Webserver-Logs für die nachfolgende Analyse in RedShift. Diese Art von vorheriger Bereinigung mittels Map Reduce ist sinnvoll, weil in Webserver-Logs im Normalfall keine einheitlichen Daten stehen, was sie prinzipiell erstmal ungeeignet für Data Warehouse macht. Hier mischen sich z. B. verschiedene Arten von Fehlermeldungen mit unterschiedlichsten Typen von Log-Einträgen, was sich mit EMR gut bereinigen, bzw. normieren lässt.

Das auf Hadoop basierende Elastic Map Reduce erlaubt eine Vorverarbeitung großer Datenmengen.
Das auf Hadoop basierende Elastic Map Reduce erlaubt eine Vorverarbeitung großer Datenmengen.
(Bild: Drilling / AWS Germany GmbH)

Ein EMR-Cluster ist in der AWS Management Console schnell erstellt. Nach einem Klick auf „Create Cluster“ legt man meine Cluster-Namen fest, bestimmt ein S3-Bucket für das Logging und wählt dann bei „Software configuration“ die gewünschten im EMR-Cluster bereitzustellenden „Applications“. Vier vorkonfigurierte Sets sehen hier bereit, man kann aber mit einem Klick auf „Go to advanced configuration“ auch eine gezielte Auswahl treffen. Bei „Hardware configuration“ legt man die Cluster-Größe fest. Der Wert bei „Number of instances“ versteht sich immer als „1 master + n core“-Nodes.

Beispiel für ein kombiniertes EMR- und RedShift-Einsatzszenario.
Beispiel für ein kombiniertes EMR- und RedShift-Einsatzszenario.
(Bild: Drilling / AWS Germany GmbH)

Auf diese Weise sind zusammen mit EMR und RedShift verschiedene Datenverarbeitungs-Workflows vorstellbar. So könnte man im Webserver-Log-Beispiel EMR gut für die Vorverarbeitung nutzen, indem man die Massendaten als Ergebnis des EMR-Laufs für das spätere Reporting bzw. für die Nutzung von BI-Tools an RedShift weiterleitet. Dabei ist es aber durchaus möglich, parallel direkt auf dem EMR-Cluster Analysen abzugreifen, quasi während der Vorverarbeitung.

NoSQL

Der Hauptgrund für den Einsatz von NoSQL-Datenbanken ist massives ScaleOut. Da NoSQL-Datenbanken auf einem verteilten, hoch skalierbaren Cluster laufen, sind sie immer erste Wahl, wenn man mehr als einen Knoten braucht (Standard bei relationalen Datenbanken). Dabei bleiben Durchsatz und IOPS gleichbleibend hoch, wobei die Zugriffszeit auf bei 150.000 IOPS und wachsender Clustergröße wegen der verteilten Speicherung sehr niedrig bleibt.

Mehr aus Entwicklersicht punktet NoSQL-Datenbanken mit Ihrem flexiblen Schema. Das Schema darf allerdings nur relativ einfach sein, kann dann aber auch im laufenden Betrieb geändert werden, d. h. das Datenmodell sieht flexible Attribute vor. Dafür ist der Funktionsumfang stark eingeschränkt. Im der Regel handelt es sich um mehr oder weniger einfache Key-Value-Stores.

Während man sich bei einer relationalen Datenbank sehr stark auf ein bestimmtes Schema festlegt (Tabellen, Spalten), hat man in NoSQL sehr viele unterschiedliche Entitäten und vor allem sehr unterschiedliche Eigenschaften für jede einzelne Entität. Daher eignen sich NoSQL-Datenbanken immer gut, wenn sich das Schema häufig ändert. Der dritte Grund für den Einsatz von NoSQL ist die extrem niedrige Latenz. Wenn man niedrige Latenz im 1stelligen ms-Bereich braucht, geht kein Weg an NoSQL vorbei, ein Wert der mit relationalen Datenbanken zumindest bei größeren Transaktionsvolumen nicht zu machen ist.

Der größte Nachteil von NoSQL ist, dass sie die ACID-Prinzipien nicht erfüllen und daher Transaktionen nicht möglich sind. Von Anfang an kennen NoSQL-Datenbanken allerdings mit BASE (Basicly Available, Soft State, Eventually Consistency) ein ähnliches Konzept.

  • BA bedeutet, dass die Verfügbarkeit der Datenbank über die Konsistenz gewertet wird, d. h. Verfügbarkeit bleibt auch bei Ausfall von Einzelkomponenten gewahrt bleiben.
  • Soft State impliziert, dass NoSQL keinen harten Transaktionszustand kennt.
  • Eventually Consitant heißt, dass man einmal geschriebene Daten auch irgendwann lesen kann, aber nicht notwendigerweise sofort. Moderne NoSQL-Datenbanken bieten heute aber auch vollkommen transaktionale Schreiboperationen, also volle Konsistenz, allerdings meist aber nur für einzelne Objekte.

Out of the box ist DynamoDB unter AWS schnell konfiguriert.
Out of the box ist DynamoDB unter AWS schnell konfiguriert.
(Bild: Drilling / AWS Germany GmbH)

Auch NoSQL-Datenbanken wie Cassandra, CouchDB, MongoDB etc. lassen sich unter AWS DIY auf Basis von EC2-Instanzen betreiben. Einfacher ist wie immer das Verwenden einer von AWS verwalteten NoSQL-Datenbank wie „DynamoDB“ mit einem provisionierten Durchsatz von bis zu 150.000 Schreiboperationen pro Sekunde bei niedrigster Latenz im einstelligen Millisekunden-Bereich, was dadurch gewährleistet wird, dass die Datenbank bei Bedarf in Hintergrund dynamisch skaliert und die Daten selbst immer auf SSDs liegen.

(ID:45385338)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist