Veröffentlicht am

Optimistisches Concurrency Control

Trade-Offs bei Transaktionen in relationalen Datenbanken

Optimistisches Concurrency Control als Rettungsanker?

Wer mit Datenbanken arbeitet, verwendet zwangsläufig Transaktionen und muss dabei Trade-Offs berücksichtigen. Optimistisches Concurrency Control ist der Versuch, die Trade-Offs der Datenbank zu mildern. Es lohnt sich, darüber nachzudenken, wenn man den Lesevorgang und den anschließenden Schreibvorgang in zwei unterschiedlichen Datenbanktransaktionen durchführen muss, beispielsweise, weil dazwischen eine langdauernde Benutzerinteraktion stattfindet. 

So funktioniert’s: Wir ergänzen jede Tabelle mit einem zusätzlichen Feld, beispielsweise version int. Die Applikation liest immer auch die Version mit. Und jeder Update wird ergänzt, beispielsweise so:

update test set ... version = version + 1 where version = alte_version; Statt alte_version setzen wir den Wert ein, den wir vorher gelesen haben.

Die Überlegung ist einfach: So können wir sicher stellen, dass wir mit unserem Update-Befehl nicht die Daten verändern, die in der Zwischenzeit eine anderer User verändert hat.

Die Erwartung ist ebenso einfach formuliert: Wir möchten nicht nur keine Updates verlieren, sondern sicher sein, dass es zu keinen Deadlocks und zu keinen blockierten Transaktionen kommt.

Ein weitverbreiteter Irrglaube: Transaktionen der Datenbank kann man nicht umgehen –  Jede Operation in einer Datenbank findet innerhalb einer Transaktion statt – ausnahmslos. Und so wird die Erwartung enttäuscht: In relationalen Datenbanken kann es trotz Optimistischen Concurrency Controls zu blockierten Transaktionen kommen.

Der Artikel untersucht das Optimistische Concurrency Control, illustriert dessen Grenzen mit einem Beispiel und zeigt eine sinnvolle Anwendungsmöglichkeit.

Optimistisches Concurrency Control ist nicht zu verwechseln mit dem Multiversion Concurrency Control (MVCC), das beispielsweise PostgreSQL einsetzt, um ACID-Transaktionen auf Zeilenebene zu verwalten. Wir untersuchen dessen Verhalten im zweiten Beispiel in diesem Artikel.

Optimistisches Concurrency Control – Das Experiment

Wir arbeiten mit PostgreSQL. Das Beispiel lässt sich mit jedem beliebigen relationalen System wiederholen.

Zuerst die Vorbereitungen: Wir arbeiten mit einem Datenbankschema my_database und mit zwei Sessions im PSQL-Client.

Zuerst definieren wir eine einfache Tabelle mit der diskutierten Spalte version. Wir fügen gleich eine Zeile ein:

my_database=> create table test (version int);
CREATE TABLE
my_database=> insert into test values (1);
INSERT 0 1
my_database=>

Der Einfachheit halber belassen wir es dabei und zeigen den Effekt mit dieser einen Tabelle mit einer Zeile und einer Spalte. In einem produktiven Beispiel müssen wir natürlich alle Spalten aufzählen und die vom Update betroffenen Zeilen in der Where-Klausel korrekt auswählen.

Zwei gleichzeitige Sessions mit Optimistischem Concurrency Control

Jetzt haben wir Minimalvoraussetzungen geschaffen, um den Effekt des Optimistischen Concurrency Control zu untersuchen.

Wir haben zwei gleichzeitige Sessions in unterschiedlichen Applikationsprogrammen und zwar diejenige von Alice und diejenige von Bog. Beide arbeiten zur gleichen Zeit mit denselben Daten.

Alice arbeitet mit autocommit, also jedes einzelne Statement wird sofort automatisch committed und sie verwendet Transaction Isolation Level ‘Read Committed’:

my_database=> \echo :AUTOCOMMIT
on
my_database=> SHOW TRANSACTION ISOLATION LEVEL;
transaction_isolation
———————–
read committed
(1 row)
my_database=>

Bob hingegen hat autocommit ausgeschaltet – der Befehl lautet \set AUTOCOMMIT off und auch er verwendet  Read Committed:

my_database=> \echo :AUTOCOMMIT
off

my_database=> SHOW TRANSACTION ISOLATION LEVEL;
transaction_isolation
———————–
read committed
(1 row)
my_database=*>

Zusammenfassend:

  • Beide Sessions verwenden das voreingestellte Transaction Isolation Level von PostgreSQL: Read Committed.
  • Der Unterschied der Sessions liegt im Commit-Verhalten.

Die Grafik zeigt zuerst das Beispiel, das wir anschließend Zeile für Zeile unter die Lupe nehmen. Der Einfachheit halber betrachten wir eine Tabelle test mit genau einer Zeile und genau einer Spalte.

Optimistic Concurrency Control

Gehen wir das Beispiel jetzt Schritt für Schritt durch.

Bob’s Transaktion dauert lange, er führt beispielsweise lange Analysen durch und ganz wichtig – commit erfolgt erst ganz am Schluss nach mehreren Datenbankoperationen. Das mag konstruiert erscheinen, ist in der Praxis oft anzutreffen. Zuerst liest Bob den Inhalt der Tabelle – wir konzentrieren uns nur auf die Spalte ‘Version’, weil diese ja fürs Optimistische Concurrency Controll maßgebend ist, alle anderen Spalten hängen vom jeweiligen Anwendungsfall ab:

my_database=*> select * from test;
version
———
1
(1 row)
my_database=*>

Achtung – kein Commit bei Bob.

Alice kann ungehindert die Daten in derselben Tabelle verändern. Erinnere: Alice verwendet autocommit:

my_database=> update test set version=version+1 where version=1;
UPDATE 1
my_database=>

Das funktioniert wie erwartet. Immerhin hat Bob bisher ja ‘nur’ gelesen.

Bob wiederholt den Lesevorgang:

my_database=*> select * from test;
version
———
2
(1 row)
my_database=*>

Das ist korrekt – Read Committed liefert ja immer immer die letzten, durch commit bestätigten Werte. Die anderen Transaction Isolation Leven werden wir später beleuchten.

Jetzt will Bob die Werte verändern:

my_database=*> update test set version=version+1 where version=2;
UPDATE 1
my_database=*> select * from test;
version
———
3
(1 row)
my_database=*>

Beachte – noch immer kein Commit in Bob’s Transaktion. Zuerst wird der Wert verändert und danach gelesen. Postgres geht davon aus, dass Bob in seiner Transaktion mit den selbst veränderten Werten weiterarbeiten will und liefert diese aus, obwohl sie noch nicht bestätigt wurden. Auch hierzu setzt Postgres auf MVCC.

Jetzt wird Alice wieder aktiv – sie arbeitet noch immer mit autocommit:

Der Effekt des Optimistischen Concurrency Control

Alice führt jetzt eine Veränderung an den Daten mit Hilfe von Optimistischem Concurrency Control durch:

Alice liest zuerst die Werte:

my_database=> select * from test;
version
———
2
(1 row)
my_database=>

Es ist korrekt dass Alice für die Version den Wert 2 erhält: Auch ihre Transaktion funktioniert mit Read Committed und Bob hat die Veränderungen seiner Transaktion ja noch nicht bestätigt. Postgres setzt auch hierzu MVCC ein: lesende und schreibende Transaktionen blockieren einander nicht gegenseitig.

Alice berechnet jetzt eine Veränderung an den Daten und will mit Hilfe der Where-Klausel und dem Versionsfeld sicherstellen, keine Daten anderer Transaktionen zu verändern.

Lassen wir Alice eine extreme Erhöhung des Werts vornehmen – so wird der Effekt des Testbeispiels besser sichtbar – Alice erhöht die Version um 100 und erwartet als Ergebnis 102:

my_database=> update test set version=version+100
where version=2;

Hier bleibt die Transaktion stehen – das funktioniert wie erwartet, denn Bob hat ja noch immer keinen commit gemacht und hält jetzt Schreibsperren auf der Zeile, die Alice verändern möchte. Zwei Transaktionen dürfen nicht gleichzeitig dieselbe Zeile schreiben.

Die Transaktion steht ziemlich lange still. Ich habe die Zeit nicht gemessen und auch nicht nachgelesen, wie lange es dauert, bis ein Timeout auftritt. Sicher kann ich berichten, dass ich den berühmten Kaffe trinken war und sich bis zu meiner Rückkehr nichts bewegt hat – mehrere Minuten waren es sicher – untragbar für einen produktiven Mehrnutzerbetrieb.

Die Situation kann aufgelöst werden, indem Bob endlich commit sagt:

my_database=*> commit;
COMMIT
my_database=>

Jetzt geht auch Alices Transaktion zu Ende. Erwartungsgemäss wird der Update nicht durchgeführt – immerhin wurde ja der Wert in Version von Bob verändert und Alice findet keine Zeile mehr mit version=2. Das anschließende Select-Statement findet den Wert, den Bob hinterlassen hat.

my_database=> update test set version=version+100
where version=2;
UPDATE 0
my_database=> select version from test;
version
———
3
(1 row)
my_database=>

Die Arbeit von Alice wurde also in der Datenbank nicht festgehalten. Alice muss ihre Transaktion nochmals durchführen – ein gut geschriebenes Applikationsprogramm wird sie dabei unterstützen und in einer verständlichen Systemmitteilung auch den Grund erklären, so dass Alice versteht, warum sie doppelt Arbeiten muss. Je nach Anwendungsfall wird das Programm die Transaktion vielleicht automatisch wiederholen können. Ob in unserem Beispiel Alice das Endergebnis verstehen würde? Immerhin erwartet sie 102 und erhält aber 3…

MVVC und Snapshot Isolation

In unserem Beispiel führten wir bisher mit der Spalte Version eine Art selbstgebautes Concurrency Control ein – diese wird auch Optimistisches Concurrency Control genannt.

PostgreSQL verwendet MVCC – Multiversion Concurrency Control. Damit wird garantiert, dass lesende Transaktionen keine schreibenden behindern und umgekehrt. Dazu führt Postgres verschiedene Versionen (Snapshots)  ein- und derselben Zeile und merkt sich, welcher Transaktion welche Version der Zeile ausgeliefert wurde.

Die folgende Grafik zeigt das Verhalten von PostgreSQL mit Hilfe desselben Beispiels, doch diesmal ohne die Where-Klausel, also mit reinem MVCC ohne den von der Applikation ergänzten Zusatz des Optimistischen Concurrency Control.

Die Session-Einstellungen für Alice und Bob lassen wir unverändert: Alice verwendet autocommit, Bob nicht und beide arbeiten mit dem Transaction Isolation Level ‘Read Committed’.

Diesmal hat unsere Tabelle eine einige Spalte zahl int und eine einzige Zeile.

Multiversion Concurrency Control MVCC

Die allerletzte Zeile zeigt den einzigen Unterschied: Alice erwartete zwar den Wert 102 – immerhin sah sie den Wert 2, bevor sie sich entschloss, diesen um 100 zu erhöhen. Nach dem Commit ihrer Transaktion, sieht sie aber den Wert 103.

Aus Sicht der Datenbank ist der Wert 103 jedoch der korrekte: Die Datenbank hat einen “Lost Update” verhindert, und die Erhöhung der Transaktion von Bob mit einbezogen.

Ob Alice als Person das auch so sieht, steht auf einem anderen Blatt geschrieben.

Die Grenzen des MVCC – der Einsatz des Optimistischen Concurrency Control

Unser bisheriges Beispiel zeigte, dass MVCC ausreichend ist und der Aufwand des Optimistischen Concurrency Control überflüssig.

Jetzt verändern wir das Beispiel und wir arbeiten mit einer neuen Tabelle:

create table test (stadt varchar(20), land varchar(20));

Der Einfachheit halber bleiben wir bei einer einzelnen Zeile:

Der Ablauf ist gleich, wie im vorherigen Beispiel. Doch diesmal werden andere Felder verändert. Aus Sicht der Datenbank ist alles in Ordnung: nur bestätigte Werte werden ausgeliefert und keine Transaktion überschreibt die Werte einer anderen Transaktion.

Inhaltlich jedoch ist alles schief gelaufen und die Datenbank enthält jetzt sinnlose Daten – die ewige Stadt liegt ja nicht in der Schweiz.

Diese Situation hätte mit Optimistischem Concurrency Control verändert werden können.

  1. In der Tabelle Test das Feld ‘version int’ ergänzen.
  2. Beim Insert der Version den Wert 1 geben
  3. Beim jedem Update konsequent Version um 1 erhöhen

Was wäre passiert:

  1. Beim Insert wäre Version auf 1 gesetzt worden
  2. Bob hätte Version auf 2 gesetzt
  3. Alice hätte Version = 1 gelesen
  4. Bob hätte Version 2 bestätigt
  5. Alice hätte ihr Update mit where version=1 versucht und hätte keine Zeile verändert.
  6. Das Applikationsprogramm hätte das erkannt und Alice gemeldet und einen benutzerfreundlichen Dialog gestartet.

select for update – die Datenbank arbeiten lassen

Bisher gingen wir davon aus, dass wir gute Gründe haben, den Lese- und Schreibvorgang bei Alice in zwei verschiedenen Datenbanktransaktionen ablaufen zu lassen. Die Datenbank geht immer davon aus, dass wir als Anwenderinnen und Anwender wissen, was wir tun, und unterstützt uns dabei.

Und selbstverständlich bietet uns eine moderne Datenbank wie PostgreSQL auch die notwendigen Bordmittel, ohne den Overhead des Optimistischen Concurrency Controls zu arbeiten.

Das folgende Beispiel zeigt, wie es geht:

Was wurde verändert:

  • Alice schaltet autocommit aus. Bob hatte ja autocommit immer ausgeschaltet.
  • Jede schreibwillige Transaktion liest die später zu schreibenden Daten mit select for update.

Mit select for update versieht die Datenbank die betroffenen Daten schon beim Lesen mit einer Schreibsperre.

So wird erreicht, dass Alice die von Bob veränderten Daten nicht zu sehen bekommt, bis Bob diese bestätigt hat und so wird Alice auch auf inhaltlich korrekten und konsistenten Daten arbeiten.

Auswirkungen fürs Applikationsprogramm

Select for update und der anschließende Update müssen in ein- und derselben Transaktion stattfinden. Auch wenn dazwischen ein Benutzer eine lange Denkpause einlegt. Die betroffenen Daten bleiben solange gesperrt für Veränderungen anderer Transaktionen, können aber noch gelesen werden.

Eine Transaktion ist immer an eine Datenbanksession gebunden. Handelt es sich beim Applikationsprogramm um eine Webanwendung, dann muss die Datenbanksession korrekt den jeweiligen Requests und Responses zugeordnet werden, was wiederum bedeutet, dass die Datenbanksession im zugehörenden Serverseitigen Web-Sessionobjekt gehalten werden muss.

Ist das nicht möglich, dann ist Optimistisches Concurrency Control ein Ausweg, der jedoch Disziplin seitens der Entwickler erfordert, die konsequent die Spalte ‘Version’ nachführen müssen.

Gesperrte Einheiten

Viele moderne relationale Datenbanken arbeiten standardmäßig mit Row-Level-Locking. Ist das nicht der Fall, dann werden größere Einheiten gesperrt, beispielsweise eine Datenbank-Seite oder die ganze Tabelle.

Beim Page-Level-Locking werden sämtliche Zeilen gesperrt, die sich auf derselben Datenbank-Seite befinden, wie die von der Transaktion tatsächlich verarbeitete Zeile. Wieviele Zeilen das sind, und welche, können wir nicht wissen. In dem Fall kann es aus Sicht der Benutzer zu unerklärlichen Wartezeiten und unerklärlichen Deadlocks kommen.

Table-Level-Locking ist sehr ungünstig für einen Mehrnutzerbetrieb und wird meistens nur für Wartungsarbeiten verwendet.

Andere Transaction Isolation Level

Viele relationale Datenbanken verwenden Read Committed als das Standard-Transaction Isolation Level. Den Effekt haben wir im Beispiel gesehen: Bob’s Transaktion erhält die Werte gezeigt, die Alice verändert hat. Alice jedoch kann keine Werte verändern, solange Bob’s Transaktion die Schreibsperren nicht freigibt. Dieses Verhalten ist oft wünschenswert.

Mit Repeatable Read könnte Bob erreichen, dass seine Transaktion bei wiederholtem Lesen derselben Daten jeweils dieselben Werte gezeigt erhält – eigene Änderungen inklusive. Bob könnte jedoch keine Änderungen vornehmen, wenn Alice inzwischen Änderungen an denselben Daten vorgenommen hat.

Zusätzlich würde Bob bei wiederholtem Lesen die Effekte von Insert- und Delete-Statements bemerken, die Alice inzwischen vorgenommen hat: Würde Alice Zeilen eingefügt haben, die auf die Where-Klauseln von Bob’s wiederholtem Select antworten, dann würde Bob diese zu sehen bekommen. Man spricht in diesem Zusammenhang von Phantomen.

Mit Serializable wird das Verhalten von Repeatable Read noch verschärft. Da könnte Alice keine Änderungen vornehmen, wenn Bob die Daten gelesen hat. Mit diesem Transaction Isolation Level treten oft ungewünschte Blockaden und gar Deadlocks auf, gerade dann, wenn Transaktionen, wie diejenige von Bob vorhanden sind.

Read Uncommitted ist die vierte Möglichkeit. Je nach Datenbanksystem werden dabei tatsächlich Sperren umgangen und noch unbestätigte und damit möglicherweise inkonsistente Werte geliefert.

Setzt man mit PostgreSQL die Transaktion von Alice auf Read Uncommitted und führt unsere Beispiele durch, dann wird man dasselbe Verhalten beobachten, wie mit Read Committed. PostgreSQL behandelt Read Uncommitted gleich wie Read Committed und verhindert damit einen ungewollt inkonsistenten Zustand der Daten.

Fazit

Es führt kein Weg daran vorbei: Ein Applikationsprogramm muss vorsehen, dass eine Transaktion wiederholt werden muss.

Der Einsatz von Optimistischem Concurrency Control ist eine Notlösung, wenn eine Transaktion zwischen dem Lesen und anschließenden Schreiben nicht aufrecht erhalten werden kann.

Verlässlicher ist es, sich auf die Werkzeuge der Datenbank zu verlassen und mit select for update zu arbeiten. Dank MVCC ist in modernen Datenbanken das Transaction Serialisation Level ‘Read Committed’ die beste Wahl für Anwendungen mit User-Interaktionen.

Problematisch wird es, wenn komplexe Transaktionen Daten wiederholt lesen, Berechnungen vornehmen und Daten schreiben aufgrund der Ergebnisse der Berechnungen. Bob’s Transaktion simuliert dieses Verhalten. Solche Transaktionen benötigen unter Umständen Repeatable Read oder gar Serializable als Isolation Level und behindern damit den reibungslosen Mehrnutzerbetrieb.

Empfehlungen für Transaktionen in Relationalen Datenbanken

Allgemeine Empfehlungen zum Transaktionshandling möchte ich nur sehr oberflächlich abgeben:

  • Kenne deine Datenbank;
  • Kenne deine Applikation und alle anderen Applikationen auf denselben Datenbanktabellen;
  • Halte alles so einfach, wie möglich;
  • Entkopple Abhängigkeiten in den Daten;
  • Verwende Standard-Verfahren der Datenbank;
  • Halte alle Transaktionen kurz;
  • Lagere Analysen aus in Data Warehouses oder Date Lakehouses;
  • Erwäge NoSQL-Datenbanken.

NoSQL Datenbanken

Auch in nicht-relationalen Datenbanken finden alle Operationen innerhalb einer Transaktion statt. Doch anders als bei relationalen Datenbanken finden wir in NoSQL-Datenbanken viele unterschiedliche Ausprägungen des Transaktionsverhaltens vor.

Durch die nicht-relationale Datenorganisation werden auch Abhängigkeiten verringert – mit dem Preis, dass Redundanz eingeführt wird und Daten inhaltlich inkonsistent werden können. Die Verantwortung über die inhaltliche Datenintegrität bleibt in den Händen der Entwicklerinnen und Entwickler der Applikationen.

In unserem Beispiel blieb die eine Session stehen, weil beide Sessions ja als READ COMMITTED-Transaktionen liefen. Mit einer geeigneten NoSQL-Datenbank können wir mit der gezeigten Art des Optimistischen Concurrency Control arbeiten, ohne dass es zu blockierten Sessions kommt.

Doch auch bei NoSQL-Datenbanken gilt: Man kenne die Datenbank – denn diese ‘Freiheit’ kommt mit einem Trade-Off, den man kennen sollte, bevor man ihn eingeht. Welches der Trade-Off ist hängt ab von vom Datenbankprodukt und von der eigenen Applikation.

Veröffentlicht am

Virtuelle Maschinen vernetzen (Tutorial)

Virtuelle Maschinen vernetzen (Tutorial)

Eine eigene Cloud auf dem Laptop – das ist praktisch, gerade wenn man Big-Data-Systeme kennen lernen will. Dazu vernetzen wir mehrere virtuelle Maschinen.

Das folgende Tutorial zeigt eine Schritt für Schritt Anleitung zum Aufsetzen und Klonen einer einzelnen virtuellen Maschine mit VirtualBox.

Danach erläutert es die Konzepte zum Vernetzen der virtuellen Maschinen.

Das Tutorial ist ein Auszug aus dem (kostenfreien) eBook Cluster aus Virtuellen Maschinen. Dieses zeigt schrittweise den Aufbau eines VirtualBox-Clusters mit ausführlicher Anleitung zum Vernetzen der einzelnen Instanzen. 

Wir arbeiten mit einem Mini-Cluster aus drei virtuellen Maschinen. Die Limitierung besteht in den Ressourcen des Host-Rechners, also unseres Laptops. Je mehr virtuelle Maschinen wir aufsetzen können, umso besser können wir die Big-Data-Welt kennen lernen.

Wichtigste Eigenschaften Virtueller Maschinen

Dank Virtualisierungstechnologien können wir auf dem Laptop zusätzlich zu allen Apps eine Umgebung installieren, die die Hardware und das Betriebssystem des Laptops nutzen, sich jedoch verhalten wie ein eigenständiger Rechner mit einem separaten Betriebssystem.

Hier eine schematische Darstellung einer Laptop-Cloud mit fünf virtuellen Maschinen:

Die layer der Virtualisierung
Ein Cluster basierend auf virtuellen Maschinen. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files.

Der Laptop dient als Gastgeber, also Host. Und so ist die Rede vom Host-Betriebssystem.

Darauf installieren wir die Virtualisierungssoftware – genauer den Hypervisor. Innerhalb dieses Hypervisors installieren wir anschließend virtuelle Maschinen mit einem eigenen Betriebssystem. Man spricht vom “Gast”, englisch “Guest”. So kann man die beiden Betriebssysteme unterscheiden: Host und Gast. Ein Host kann mehrere Gäste haben. Vorausgesetzt, unser Laptop verfügt über genügend Rechenkapazität. Ein Beispiel: Der Host läuft mit Windows und der Gast läuft mit Linux.

Auf der schematischen Darstellung oben, sind drei virtuelle Maschinen, also “Gäste” dargestellt. Für den Trainings-Cluster werden wir für jede virtuellen Maschine eine eigene statische IP-Adresse konfigurieren.

Der Hypervisor virtualisiert auf Hardware-Ebene. Die virtuellen Maschinen sind vollständig voneinander isoliert und der Hypervisor enthält unter anderem als eine Art “Router”, weist den virtuellen Maschinen IP-Adressen zu und stellt die TCP-IP-Verbindung dazwischen her.

Jede virtuelle Maschine hat also ein eigenes Betriebssystem, ein eigenes Filesystem und eine eigene Installation der Tools und Apps, die wir kennenlernen wollen.

Wie jeder Computer, kann auch eine virtuelle Maschine gestartet und gestoppt werden. Es wird dann jeweils das betreffende Gast-Betriebssystem gestartet resp. gestoppt.

Images von virtuellen Maschinen können auch von einem Laptop auf einen anderen kopiert oder verschoben werden, mehrheitlich unabhängig vom Host-Betriebssystem der Laptops.

Wir werden mit Laptops arbeiten, um den Trainings-Cluster aufzubauen. Virtualisierung ist nicht auf Laptops beschränkt, sondern findet sehr viel Verbreitung bei Cloud-Providern. Dort werden virtuelle Server aufgebaut, verwaltet, vermietet.

Eine einzelne VirtualBox einrichten und klonen

Wer mit virtuellen Maschinen arbeiten will, kann unter verschiedenen Anbietern auswählen. Gerade im Ausbildungsbereich ist VirtualBox sehr beliebt, weil viele fürs Kennenlernen notwendige Funktionalitäten in der kostenlosen Version erhältlich sind. Wer in einem Produktionssystem virtualisieren möchte, wird nicht um eine Evaluation der verschiedenen Anbieter herumkommen. Für unser Big Data Training ist die Virtualisierung lediglich Mittel zum Zweck, so dass wir das Vorgehen mit VirtualBox zeigen.

Notwendige Vorkenntnisse

Für dieses Kapitel des Big Data Labors braucht man Administratorrechte auf dem eigenen Laptop (oder PC). Das Tutorial führt Schritt für Schritt durch den Installationsprozess, setzt jedoch voraus, dass der Leser mit Software-Installationen vertraut ist.

Grundlegende Kenntnisse mit Linux auf Ebene Kommandozeile werden für das Big Data Labor ebenfalls vorausgesetzt. Die Kommandos werden gezeigt und kurz erklärt.

Laptop-Ressourcen als Voraussetzung zum vernetzen virtueller Maschinen

Um mit dem Big-Data-Labor arbeiten können, brauchen wir einen Laptop (oder PC) mit genügend freien Kapazitäten. Hier eine Empfehlung:

  • min 16 GB RAM
  • min 100 GB freier Speicherplatz auf der Harddisk
  • 64-bit Prozessor
  • Internetverbindung.

Starker Prozessor um mehrere virtuelle Maschinen zuz vernetzen

Der Prozessor des Laptops muss Virtualisierung ermöglichen. Gerade in kostengünstigeren Laptops können Prozessoren verbaut sein, die Virtualisierung nicht unterstützen. Diese Seiten können weiter helfen, je nach Hersteller des Prozessors: Intel-Prozessoren  oder AMD-Prozessoren.

Die neuen Mac mit M1 und M2 Prozessoren basieren auf der ARM-Prozessor-Architektur. Die neueste Version von VirtualBox unterstützt auch diese Architekturen.

Im Zweifelsfall geht Probieren über Studieren.

Voraussetzung für die Virtualisierung im BIOS

Auch wenn der Prozessor Virtualisierung ermöglicht, dann ist sie nicht unbedingt aktiviert.

Der Task-Manager in Win 10 & 11 zeigt, ob die Möglichkeit zur Virtualisierung aktiviert wurde.

Ob die Virtualisierung auf einem Windows-Laptop möglich ist, lässt sich einfach herausfinden: Wir öffnen den Task-Manager (Strg-Alt-Del) und verzweigen dort auf die Registerkarte “Leistung”. Hier können wir ablesen, ob Virtualisierung möglich ist.

Wir können es auch einfach drauf ankommen lassen, und die erste virtuelle Maschine erstellen. Zu einem gewissen Zeitpunkt während des Vorgangs, wird eine entsprechende Fehlermeldung angezeigt. Diese macht darauf aufmerksam, dass im BIOS die Virtualisierung aktiviert werden soll.

Einblick in die BIOS-Konfiguration eines HP Rechners mit aktivierter Virtualisierung.

Wie man das BIOS aktiviert, hängt vom Hersteller des Laptops ab. Das Bild rechts zeigt als Beispiel die entsprechenden Einstellungen auf einem HP-Laptop.

 

Wenn wir dies mit unserem Laptop zum ersten Mal machen, dann wird nur eine Internetrecherche weiterhelfen. Wir suchen Beispielsweise nach Hersteller, Produktbezeichnung des Laptop, BIOS. In der Regel wird es darauf hinauslaufen, dass der Laptop neu gebootet werden muss und dass während des Bootvorgangs, noch bevor das Betriebssystem geladen wird, eine bestimmte, vom Hersteller definierte Tastenkombination gedrückt werden muss.

Wir sehen anschließend die BIOS Einstellungen. Diese Verändern wir nur sehr gezielt und mit größter Vorsicht. Normalerweise navigiert man in diesen Einstellungen mit den Pfeil- und Tab-Tasten. Wir suchen eine Einstellung, die beispielsweise den Begriff “Virtualisation Technology” enthält und wir sorgen dafür, dass diese eingeschaltet ist. Die Einstellungen müssen gespeichert werden und der Laptop muss neu gebootet werden.

Gast-Betriebssystem für die virtuelle Maschine herunterladen

Ubuntu-Server-Betriebssystem herunterladen: https://www.ubuntu.com/download/server Wichtig: Die weitere Anleitung bezieht sich auf Ubuntu. Bei Mac ist die zur Prozessorarchitektur passende Version zu wählen.

Als vorbereitenden Schritt laden wir ein Image des Gast-Betriebssystem herunter. In diesem Tutorial verwenden wir Ubuntu Server. Eine kurze Google Suche lässt uns die Download-Seite finden.

Wir laden die Software herunter und speichern das File vorerst auf der Festplatte des Laptops. Wir werden in einem späteren Installationsschritt die Datei verwenden.

Server Namen der vernetzten virtuellen Maschinen

Die einzelnen virtuellen Server werden Server-Namen brauchen. In diesem Tutorial nennen wir sie “pi-200”, “pi-201”, etc. Die Namensgebung kann beliebig sein, sollte jedoch der Einfachheit halber eine Nummerierung enthalten.

Virtualisierungssoftware – ohne sie läuft nichts

Die aktuelle Version von VirtualBox herunterladen

Als erstes laden wir die Software für VirtualBox auf den Laptop herunter.

Auf dieser Seite erscheint immer sehr prominent die Download-Möglichkeit für die Software. Zum Zeitpunkt der Erstellung des Tutorials war gerade die Version 6.0 aktuell. Die Folgeversionen verhalten sich analog.

Wir klicken auf die grüne Schaltfläche – oder auf das Icon auf künftigen Seiten, das dieser Schaltfläche entspricht.

Die Software muss auf dem Host-Betriebssystem laufen. Hier ist also das Betriebssystem des Laptops auszuwählen. Bei Mac zusätzlich die Prozessorarchitektur beachten.

Auf der nächsten Seite wird die Software für verschiedene Host-Betriebssysteme angeboten. Hier wählen wir das Betriebssystem aus, das auf unserem Laptop installiert ist.

Anschließend wird die Virtualisierungssoftware heruntergeladen. Wir speichern sie auf dem Laptop und installieren sie mit den Standardeinstellungen.

VirtualBox – eine erste virtuelle Maschine

Blick in eine neue Installation des Virtualbox Managers.

Wir starten die VirtualBox-Software und verschaffen uns einen Überblick über die Menu Optionen.

Als nächstes konfigurieren wir eine virtuelle Maschine. Wir klicken dazu auf “Neu”. Dazu können wir die entsprechende Menüoption oder auch die große Schaltfläche auf der Übersichtsseite verwenden.

Wir werden jetzt durch den Installationsprozess geführt.

Die virtuelle Maschine benennen und das Gast-Betriebssystem auswählen. Hier Linux sowie die im vorherigen Schritt heruntergeladene Ubuntu-Version auswählen.

Als erstes braucht die virtuelle Maschine einen eigenen Namen. Dazu verwenden wir die im Kapitel “Vorbereitung Server Namen” bestimmten Namen. Für dieses Tutorial fangen wir an mit pi-200.

Als Betriebssystem wählen wir Linux, weil die Big-Data-Software unter Linux läuft.

Wir können anschliessend die gewünschte Linux-Version auswählen. Für dieses Tutorial nehmen wir Ubuntu 64-bit. Wir können auch eine andere Version nehmen. 64-bit sollte es schon sein, die neueren Laptops haben ja 64-bit-Prozessoren und auch die Big-Data-Software geht von 64-bit aus.

Festlegen, wie viel RAM die virtuelle Maschine verwenden darf.
Größe des RAM auf dem Laptop spielt dabei eine wichtige Rolle.

Auf der folgenden Seite, legen wir fest, mit wie viel RAM die virtuelle Maschinen arbeiten darf.

Dabei spielt die Größe des RAM auf dem Laptop eine wichtige Rolle. Der virtuellen Maschine wird vom Laptop nicht mehr RAM zur Verfügung gestellt, als wir hier konfigurieren.

1GB, also 1024 MB sollten es mindestens sein. Diese Größe ist für einen Produktivbetrieb viel zu gering, für die ersten Kennenlernschritte jedoch mindestens ausreichen. Wir werden mindestens 3 virtuelle Maschinen benötigen und auch darauf achten, dass für das Host-System genügend RAM übrig bleibt.

Festlegen, wie viel Platz die virtuelle Maschine auf dem Gast-Rechner benötigen wird. Die Größe der Festplatte des Laptops, sowie der verfügbare Platz, spielen dabei eine wichtige Rolle.

 

 

Für die weiteren Schritte, übernehmen wir jeweils die Standard-Optionen.

Für die weiteren Optionen wählen wir vorerst die Standardeinstellungen und schließen die Konfiguration mit “Erzeugen” ab.

Die Standard-Vorgabe für die virtuelle Festplatte kann übernommen werden. 8 GB reichen gut für erste Tests. – für erweiterte Tests empfehle ich 20 GB.

Auf der nächsten Seite konfigurieren wir die Größe der Festplatte, sowie deren Name. Wir wollen ja nicht wirklich mit Big-Data arbeiten, also brauchen wir keine große Festplatte. Hier sollten wir aufpassen, dass genügend freier Festplattenplatz auf dem Laptop vorhanden ist. Wir werden ja mindestens 3 virtuelle Maschinen benötigen und alle werden auf dem Laptop diesen Platz verbrauchen.

Blick in den VirtualBox-Manager. Die neu konfigurierte VM erscheint links, die Konfiguration kann im Hauptbereich (rechts) eingesehen und verändert werden.

Die neu konfigurierte virtuelle Maschine ist jetzt im linken Bereich zu sehen.

Internes Netzwerk

Bevor wir loslegen, versehen wir die virtuelle Maschine mit einer weiteren Netzwerkkarte, damit wir mehrere VMs untereinander vernetzen können.

Mit VirtualBox geht das am Einfachsten, indem wir ein internes Netzwerk bilden. Dazu definieren wir für jede virtuelle Maschine eine zweite (virtuelle) Netzwerkkarte. Diesmal öffnen wir die Registerkarte “Adapter 2”.

Internes Netzwerk für das Cluster definieren
  • Wir aktivieren den Adapter.
  • Wählen aus, dass er an ein Internes Netzwerk angeschlossen sein soll.
  • Und geben dem Netzwerk einen Namen – hier bigdata.
  • Anschließend speichern wir mit OK.

Diesen Vorgang wiederholen wir für alle virtuellen Maschinen, die wir für das Cluster definieren und vergeben dabei immer denselben Netzwerknamen.

VirtualBox wird ein (virtuelles) Netzwerk mit diesem Namen zur Verfügung stellen.

Virtuelle Maschine starten und Gast-Betriebssystem installieren

Wir können sie starten, indem wir auf den grünen Pfeil klicken.

Die virtuelle Maschine ist erst in VirtualBox konfiguriert, doch das Gast-Betriebssystem ist noch nicht installiert. Beim ersten Starten wird diese Installation nun vorgenommen. Dies dauert eine Weile – wir nehmen uns also genug Zeit.

Das Betriebssystem wird erst beim ersten Starten der virtuellen Maschine installiert. Der Pfad zum vorher heruntergeladene Image muss hier angegeben werden.

Als Erstes werden wir gefragt, wo sich das Image des Gast-Betriebssystem befindet.

Spätestens jetzt müssen wir das Betriebssystem herunterladen (siehe Abschnitt “Gast-Betriebssystem herunterladen“). Und wir wählen die heruntergeladene Datei aus und klicken auf “Starten”.

Jetzt wird in der virtuellen Maschine das Ubuntu-Betriebssystem installiert. Die Installationsschritte sind identisch mit einer Installation direkt auf einer Hardware, nur dass wir eine virtualisierte Umgebung verwenden. Die Navigation erfolgt mit den Pfeiltasten, den Tabulatortasten, mit Enter oder mit Esc.

Es ist praktisch, wenn Ubuntu englisch eingestellt ist. Die bisher verfügbare Dokumentation ist ja auf Englisch verfasst.

Wir werden nach der Sprache gefragt. Big-Data-Software ist oft so neu, dass es noch keine deutschen Beschreibungen gibt. Wählen wir hier “English” aus, dann wird das installierte Betriebssystem zu den Produktbeschreibungen sprachlich passen. Wählen wir eine andere Sprache aus, dann werden wir später immer wieder übersetzen müssen.

Wichtig: Die Tastatur korrekt installieren.

Anders verhält es sich in Bezug auf die Tastatur, also das Keyboard. Hier konfigurieren wir das Layout derjenigen Tastatur, die wir einsetzen. Die gängigsten Tastaturen stehen zur Auswahl. Verwenden wir jedoch ein anderes Tastaturlayout, z.B. German Switzerland, dann  hilft die Option “Identify Keyboard” weiter. Diese führt durch einen Konfigurationsprozess, während dem man aufgefordert wird, verschiedene Tasten auf der Tastatur zu betätigen. Das Installationsprogramm ermittelt damit das passende Tastaturlayout. Wir kontrollieren noch und wenn alles in Ordnung ist, wählen wir anschließend “Done” aus.

Als nächstes konfigurieren wir die Netzwerkkarten. Für enp0s3 hat die automatische Konfiguration geklappt. Mit dieser Netzwerkkarte werden wir von der VM aus via Heimnetzwerk aus dem Internet Software herunterladen können.

Bei enp0s8 besteht Handlungsbedarf, die Konfiguration des internen Netzwerks muss manuell vorgenommen werden. Die folgende Abbildung zeigt die Abfolge der Auswahlen und Eingaben.

 

Bei enp0s8 muss die Konfiguration manuell vorgenommen werden. Navigieren mit Tab, Leerschlag und Enter.

In den nächsten Schritten übernehmen wir die Default Einstellungen:

In den weiteren Schritten übernehmen wir die Default-Einstellungen.

Bis wir schließlich nach Usernamen, Servernamen und Passwort gefragt werden.

Konfigurieren der Zugangsdaten für Ubuntu. Passwort nicht vergessen…

Als Name und Username geben wir beispielsweise “pi” ein.

Als Server-Name empfiehlt es sich, denselben Namen zu verwenden, den wir auch für die virtuelle Maschine in VirtualBox vergeben haben – im Falle dieses Tutorials ist es pi-200.

Das Passwort muss wiederholt werden. Wir werden es bei jedem Login verwenden und behandeln es mit der gebührenden Sorgfalt.

Wir brauchen keine vorkonfigurierten Pakete.

Vorkonfigurierte Pakete verwenden wir nicht, wählen also gleich “Done” aus.

Die Installation wird anschließend ausgeführt. Das kann eine kleine Weile dauern.

Am Ende werden wir aufgefordert, das Installationsmedium zu entfernen. Diese Meldung ist im Falle der Installation in eine virtuelle Maschine nicht weiter zu beachten und wir beantworten sie mit “Enter”.

Die Installation wurde ausgeführt und wir können einloggen. Login-Name und Passwort wurden während der Installation ausgewählt.

Jetzt wird der Server gebootet und der Login-Prompt erscheint.

Es kann vorkommen, dass nach dem ersten Anzeigen des Login-Prompts mit etwas Verspätung noch weitere Meldungen angezeigt werden. Wird die Enter-Taste gedrückt, dann erscheint der Login-Prompt wieder.

Username ist pi (wie während der Installation vergeben) und auch das Passwort haben wir während der Installation vergeben.

Auf dem Prompt werden wir im Folgenden Kommandos zur Administration des Servers eingeben.

Tipps:

  • Ist die Anzeige zu klein, dann hilft die Menu Option der Virtual Box weiter.
  • Es empfiehlt sich, die Ubuntu Pakete gleich zu updaten. Folgende beiden Befehle tun dies:
sudo apt-get update
sudo apt-get upgrade

Mit sudo können alle Befehle mit Root-Rechten ausgeführt werden. Beim ersten Mal wird man nach dem Passwort gefragt. Gemeint ist das Passwort für den aktuellen User, das wir während der Installation wählten und auch zum Einloggen verwenden.

Alle weiteren Prompts sind mit Y zu beantworten.

Wir fahren den virtuellen Server herunter mit:

sudo shutdown -h now

Klonen einer virtuellen Maschine

Wir stellen sicher dass die virtuelle Maschine heruntergefahren ist und können sie jetzt klonen. Das ist der einfachste Weg, eine Reihe identisch installierter virtueller Maschinen zu erstellen.

Die erste virtuelle Maschine ist jetzt konfiguriert. Sie kann geklont werden. Mit Rechtsklick erscheint das entsprechende Kontext-Menu.

Dazu rechtsklicken wir auf den Namen der virtuellen Maschine in der linken Spalte im VirtualBox Manager. Im Kontext-Menu wählen wir “Klonen”.

Angaben zum Klonen – die Namen vergeben wie im Kapitel “Vorbereitung: Server Namen” bestimmt.

Wir vergeben den Klonen passende Namen. Für das Big-Data-Labor benötigen wir mindestens 2 Klone erstellen. Wenn der Laptop es zulässt, können es auch mehr sein. Dieses Tutorial wird mit 5 virtuellen Maschinen arbeiten. Der Vorgang des Klonens wird entsprechend oft ausgeführt und die Nummerierung in der Namensgebung wird hochgezählt.

Der erste Klon erhält also den Namen: PI-201

Wir wählen die Option “verknüpfter” Klon und können dadurch Speicherplatz sparen.

Und wir lassen dem Klon neue (virtuelle) MAC-Adressen zuweisen.

Wir klicken auf Klonen und der Vorgang wird ausgeführt.

Das wird wie oben ausgeführt, mehrfach wiederholt. Dabei vergeben wir der Reihe nach die Namen, die wir im Kapitel “Vorbereitung: Server Namen” ausgewählt haben.

Sobald alle virtuellen Maschinen erstellt wurden, können wir sie gruppieren.

Um die Administration zu vereinfachen, fassen wir die virtuellen Maschine in eine Gruppe zusammen.

Dazu selektieren wir sie in der linken Spalte des VirtualBox Managers und rufen mit der rechten Maustaste das Kontext-Menu auf.

Hier wählen wir die Funktion “Gruppieren” aus.

Für den späteren Gebrauch ist es praktisch, die Gruppe auch gleich aussagekräftig zu benennen.

Rechtsklick auf den Gruppennamen zeigt ein Kontextmenu. Hier erhalten wir die Möglichkeit, die Gruppe zu benennen. Beispielsweise “Big Data Labor

Die virtuellen Maschine einer Gruppe können gleichzeitig gestartet und gestoppt werden.

Wir können eine Gruppe auswählen und auf Starten klicken. Der Virtual Box Manager startet dann alle virtuellen Maschinen der Gruppe.

Das Stoppen funktioniert analog.

Netzwerktopologie für das Cluster aus virtuellen Maschinen

Das folgende Bild visualisiert die Netzwerktopologie, die wir mit den virtuellen Maschinen errichten werden.

Netzwerktopologie virtuelle Maschinen

Netzwerktopologie des virtuellen Big-Data-Clusters

Üblicherweise liegt zwischen dem Internet und dem hausinternen LAN eine Router mit einer Firewall. Der Laptop verbindet sich mit dem hausinternen LAN und erhält üblicherweise eine dynamische IP Adresse.

Die VirtualBox errichtet auf dem Laptop auch eine virtuelle Firewall mit einem DHCP-Router. Die virtuellen Maschinen verbinden sich mit dieser NAT Schnittstelle.

Wie geht es weiter? Cluster aus virtuellen Maschinen

Klone die virtuelle Maschine, so dass du mindestens zwei Instanzen hast. Je mehr desto besser. Ein Laptop mit den genannten Ressourcen kann auch fünf oder mehr virtuelle Maschinen gleichzeitig starten.

Das Laptop wird dadurch ziemlich stark ausgelastet. Auch hier: Probieren geht über Studieren – letztendlich ist die Anzahl möglicher Instanzen eine Frage der freien Kapazitäten auf dem Laptop.

Das Tutorial dieser Seite ist ein Auszug aus dem ausführlichen Schritt-für-Schritt-Tutorial: Cluster aus Virtuellen Maschinen.

Cluster aus Virtuellen Maschinen

Mit Hilfe dieses Tutorials sparst du stundenlanges Recherchieren und Ausprobieren.

Erfahre wie du mit Virtual Box eine Cloud in deinem Laptop baust.

€ 14.70
(Schweiz: zzgl. 7.7% MWSt)

PDF-Ausgabe ca. 55 Seiten.

  •  

Veröffentlicht am Schreib einen Kommentar

Aufbau einer Enterprise Search Plattform

Die Anforderungen an eine Enterprise Search sind schnell spezifiziert: Wir wollen eine Suchmaske mit einem Eingabefeld, einer Vorschlagsfunktion während des Tippens und einer Ergebnisliste, in der das wichtigste Dokument zuoberst steht.

GUI Enterprise Search
Wir wollen eine einfache Suchmaske mit einem einzigen Eingabefeld, einer Vorschlagsfunktion während des Tippens und einer Ergebnisliste, in der das wichtigste Dokument zuoberst steht.

Wir sind verwöhnt von Google und Co. Die Messlatte für die Standards liegt hoch. Jahrzehntelange Forschung und Entwicklung stehen hinter diesen Suchsystemen.

Wer eine Enterprise Search aufbauen will, muss sich auf eine längere Entwicklungszeit einstellen.

Der Aufbau einer Unternehmensweiten Suche ist mehr als ein Integrationsprojekt. Dokumente liegen in unterschiedlichen Systemen und sollen mit wenigen Klicks in einer einfachen Suchmaske auffindbar sein. Natürlich steht das beste Dokument ganz oben in der Trefferliste und die Trefferliste ist maßgeschneidert auf den Suchenden.

Ein ehrgeiziges Projekt. Hier die wichtigsten Aspekte, die es zu beachten gilt:

Autorin: Ursula Deriu

Datenquellen und Mengengerüst

Die Dokumente liegen oft verstreut auf vielen unterschiedlichen Systemen. Sharepoint, Confluent, Filesysteme, CMS-Systeme, Document Management Systeme, Archivsysteme – der Phantasie sind keine Grenzen gesetzt.

Es lohnt sich, zu Projektstart, eine Liste zu erstellen mit

  • den einzelnen Datenquellen,
  • jeweils der ungefähren Anzahl Dokumente,
  • den Fileformaten,
  • den Aktualisierungshäufigkeiten und dem geschätzten Wachstum
  • und den Authentifizierungsmethoden.

Diese Liste  wird helfen, ein passendes System zu evaluieren.

Im Verlauf des Projekts werden die Dokumente aus allen Systemen ausgelesen . Die Enterprise Search Plattform braucht Zugriff auf alle Systeme und muss mit einer Vielzahl von Authentifizierungsmechanismen zurechtkommen.

Auch erwarten wir, dass die Suchmaschine mit den Änderungen der Dokumente synchron ist.

Je nach Quellsystem wird diese Herausforderung anders zu lösen sein.

Fazit

Unternehmensweite Suche – die Anforderungen sind schnell formuliert. Der Aufbau eines Suchsystems jedoch ist sehr anspruchsvoll und aufwändig und benötigt vielfältige Skills.

Laufender Betrieb und Unterhalt

Jedes System muss gepflegt werden. Verteilte Systeme sind aufwendiger.

Die Daten müssen aktuell gehalten werden – vielleicht sogar in Echtzeit.

Die Texte und Dokumente werden von Menschenhand erstellt und der Kreativität sind keine Grenzen gesetzt.

Wir brauchen Qualitätssichrungsmechanismen die bemerken, wenn neue Formate erfunden wurden, die in der Datenkonvertierung noch nicht erkannt werden.

  • Abo: Data Engineering und Analytics
  •  

Veröffentlicht am Schreib einen Kommentar

Daten in die Cloud: Der Trend wird zum Sog

Cloud Data Engineering

Da geh’ ich lieber in die Cloud, da ist alles schon vorhanden” – die Vorstellung ist verlockend:

Nie mehr installieren, deployen, upgraden, administrieren  und sich ausschließlich aufs Wesentliche konzentrieren.

Einige kritische Gedanken zum Sog in die Cloud.

Autorin: Ursula Deriu

Cloud ist nicht gleich Cloud

Da gibt es Hyperscaler, wie Google, Amazon, Azure, Alibaba – habe ich einen ausgelassen?

Und so wie es am Himmel nicht nur große Wolken gibt, so gibt es in der Cloud auch kleine Anbieter. Das Angebot ist so vielfältig wie die Wolkenformationen am Himmel.

Oft wird unterschieden zwischen IaaS, PaaS und SaaS. Dabei bedeutet “aaS” so viel wie “as a Service” – gemeint ist der Service des Cloud-Anbieters.

Also Infrastruktur (I), Platform (P), Software (S) as a Service.

Und weil’s so schön tönt, sind ganz viele neue aaS dazu gekommen: DBaaS (Datenbank), DaaS (Desktop), FaaS (Function), RaaS (Robot) – der Fantasie sind keine Grenzen gesetzt.

Daten sammeln und analysieren

Bleiben wir bei den Daten,schließlich geht’s hier um Data Engineering und Analytics.

Noch vor zehn Jahren hieß es: “Sammle jetzt Daten und werte sie später aus”.

Diese Sammelwut führte zu Datenfluten.

Jetzt gehen wir dazu über, gezielt Daten zu sammeln und auszuwerten. Wir hoffen, die Fluten so einzudämmen.

Mittlerweile haben wir ja auch bessere Tools und gereiftere Erkenntnisse über unsere Anforderungen und Möglichkeiten.

Herausforderung Infrastruktur

Doch ein Faktor ist oft eine Spaßbremse: Die Infrastruktur.

Wo lagern wir all die Daten? Und wie können wir aus diesen Daten innert nützlicher Frist Erkenntnisse gewinnen?

Wir denken an große Datenmengen und diese benötigen viel Speicherplatz und schnelle Maschinen. Verteiltes Rechnen ist angesagt und dazu benötigen wir Rechenzentren (RZ).

Cloud-RZ – eine Herkulesaufgabe

Ein RZ zu organisieren ist anspruchsvoll: Je nach Größe reicht ein Raum oder man benötigt ein ganzes Gebäude.

Zur Risikominimierung möchten wir vielleicht alles redundant halten – also zwei Gebäude, identisch ausgestattet, am besten an unterschiedlichen Standorten.

  • Der Zugang muss gesichert sein, im Extremfall wie auf dem Flughafen mit Personen-Scanner, Gepäckkontrolle, Leibesvisitation und mindestens mit Ausweiskontrolle.
  • Türen sind mit Batches zu sichern.
  • Bei Einbruch wird Alarm ausgelöst und darauf verlässlich reagiert.
  • Brandschutz ist angesagt – die Low-Cost-Variante ist ein einfacher Rauchmelder. Doch damit sichert man kein großes RZ:
  • Automatisch schließende Brandschutztüren, Gase, die den Brand löschen und den Menschen nicht ersticken und natürlich den heißen Draht zur Feuerwehr, die zur Brandbekämpfung auch die Sicherheitskontrolle passieren muss.
  • Stromausfall muss abgesichert werden, Notstromgeneratoren müssen sofort anspringen, am besten noch, bevor der Strom endgültig ausfällt.
  • Computer dürfen nicht überhitzen, ein Kühlsystem muss sorgfältig geplant werden.
  • Was tun mit der Wärme, wie kann sie sinnvoll genutzt werden?
  • Die Internetanbindung muss schnell und zuverlässig sein.
  • All diese Infrastruktur muss überwacht und gepflegt werden.

Eine Herkulesaufgabe – noch bevor wir den ersten Server aufstellen.

Netzwerk im Cloud-RZ

Server stapeln wir in Racks, diese sind verkabelt mit Strom und Internet. Das Rechnernetzwerk mit Swiches und Routern muss sorgfältig geplant und ausfallsicher konzipiert werden.

Server im Cloud-RZ – langfristig denken

Ist es aufgestellt, dann können wir endlich Server aufstellen, verkabeln und in Betrieb nehmen.

Wie werden wir in ein paar Jahren vorgehen, wenn die Server veraltet sind und ausgetauscht werden sollen?

Ein Konzept dazu sollten wir in der Tasche haben und austesten, bevor wir produktiv gehen.

Software in der Cloud

Jetzt können wir anfangen, an die Software zu denken:

Betriebssysteme, Cluster-Management und die eigentliche Software: Verteilte Filesysteme, Datenbanken, Analytics Engines. Je nachdem, was wir vorhaben.

Und wie gehen wir vor, um neue Releases der Software einzuspielen?

RZ herunterfahren, Release einspielen, Daten migrieren, austesten und RZ hochfahren?

Das war so im letzten Jahrhundert – heute ist 7×24 angesagt, unterbruchsfrei und selbstverständlich mit den neuen Releases.

Eigene Server in der Cloud

Wir mieten beispielsweise nur die RZ-Infrastruktur und wir bringen eigene Server.

Dann sind wir auch selbst verantwortlich für den Unterhalt der Server. Das ist beruhigend, denn die Server gehören uns selbst: wenn wir Cloud-Anbieter wechseln wollen, dann ziehen wir um mit den Servern, bauen sie auf beim neuen Anbieter.

Ein gigantischer Akt – immerhin soll unsere Dienstleistung 7×24 zur Verfügung stehen.

Cloud für Data Analytics

Stoppen wir hier und denken wir wieder über die Cloud für Data Analytics nach.

Beim Hyperscaler gibt es alles einzukaufen:

Nur die Infrastruktur, oder die Plattform oder gar fix fertig konfigurierte Systeme.

Kleinere Player bieten einen Teil der Palette an und glänzen mit kundennahem Service.

Cloud-Plattform mieten

Oder wir mieten die Plattform: Dazu können wir bei vielen Anbietern wählen, ob wir ganze Server oder einzelne virtuelle Maschinen haben wollen. Selbstverständlich mit dem Betriebssystem unserer Wahl und ans Internet angebunden. Auf der Plattform deployen wir unsere Software selbst und lagern unsere Daten.

Und wenn wir eines fernen Tages den Anbieter wechseln wollen? Dann mieten wir halt unsere Server beim neuen Anbieter, installieren dort unsere Software und transferieren unsere Daten.

Das können wahre Datenfluten sein.

Und den Transfer lassen sich die Anbieter zahlen, besonders gut, beim ausgehenden Transfer.

Fazit

“Da geh’ ich lieber in die Cloud, da ist alles schon vorhanden” – bei näherem Hinschauen ein Trugschluss:

Ja, es ist vieles vorhanden, doch es entbindet uns nicht davon, die Zusammenhänge zu begreifen.

Ob Arbeit und Kosten tatsächlich weniger werden, muss sorgfältig evaluiert werden.

Die Preislandschaft und das Wording sind nicht normiert – ein genauer Vergleich ist schwierig.

Dennoch – der Trend in die Cloud wird zum Sog in die Cloud.

Die Cloud wird uns zunehmend beschäftigen.

Die Cloud bringt neue Berufe

Eine Komponente sind die Personalkosten – der Cloud-Anbieter nimmt uns Vieles ab und zahlt die Spezialisten selbst. Und wir zahlen den Cloud-Anbieter.

Nicht umsonst gibt es jetzt Cloud-Engineers, also Spezialistinnen und Spezialisten, die für ein Unternehmen die Cloud organisieren.

Eine wachsende Zahl von Zertifizierungslehrgängen bereichern die Wahlmöglichkeiten – Gerade bei den Hyperscalern, deren Cloud-Angebot so unüberschaubar vielfältig ist, dass man einen Lehrgang absolviert, um sich darin zurechtzufinden.

Software für Data Analytics in der Cloud

Oder wir mieten die Software, fix fertig konfiguriert, einsatzbereit, und mit Security-Groups abgesichert. Dabei denken wir an Umgebungen für Development, Integration und Produktion.

Die Daten lagern wir ebenfalls in der Cloud.

Auch in dem Szenario bedeutet ein Anbieterwechsel einen kostspieligen Datentransfer.

Und sämtliche unsere Programme müssen migriert und getestet werden. Es wäre ein Riesenzufall, wenn der neue Anbieter exakt dieselbe Software und dieselbe Konfiguration anbieten würde, mit der wir unsere Programme, Skripte und Auswertungen entwickelt haben.

Cloud-Anbieter und Cloud-Strategie auswählen und Cloud-Lösung implementieren, das sind anspruchsvolle Aufgaben. Sie sind sorgfältig zu planen und zu evaluieren.

  • Abo: Data Engineering und Analytics
  •  

Veröffentlicht am

Von Data Warehouse zum Data Lakehouse

Data Lakehouse: Die Bezeichnung ist eine Zusammensetzung aus Data Warehouse und Data Lake, denn diese beiden Konzepte standen Pate. Date Lakehouses eröffnen ungeahnte Perspektiven.

Autorin: Ursula Deriu

Data Warehouse und ETL – die klassische Lösung

Data Warehouses (DWH) sind ein wichtiges Werkzeug für der Data Analysts. Aus verschiedenen Systemen werden Daten extrahiert, in ein vordefiniertes Format transformiert und danach ins DWH geladen. ETL – so heißt diese Verarbeitungskette also extract-transform-load.

Data Warehouses  wurden in den 90er Jahren modern. Ein Data Warehouse ist optimiert für die Analyse wohl-strukturierter Daten.

Ziel der Datentransformation ist das Star-Schema mit Fakten und Dimensionen. Sind die Daten sauber vereinheitlicht, dann gelingen die wertvollsten Datenanalysen.

Aus den 90ern stammen auch die Grenzen der DWHs:  Sie skalieren vertikal. Die Festplatte wächst  mit dem Datenvolumen. RAID-Systeme helfen, die Festplattenkapazität zu vergrößern.

Doch was tun, wenn selbst das RAID-System an seine Grenzen stößt?

Klassisches Data Warehouse
Daten werden aus den Quellsystemen extrahiert, in der Staging Area ins vordefinierte Star-Schema transformiert und anschließend zur Auswertung ins Data Warehouse geladen.

Data Lakes

Nicht zuletzt dank des WWW brachen Daten in Fluten über uns her und schwemmten neue Technologien zum Speichern und Analysieren an: verteilte Daten Systeme, wie beispielsweise HDFS, das Hadoop Distributed Filesystem.

Ein Data Lake – das ist die Bezeichnung für die Menge der Daten in einem verteilten Big-Data-Filesystem.

Vergleichbar mit allen Daten auf unserem Laptop, aber halt in Big-Data-Dimension.

Zu Beginn der 10er Jahre lautete das Credo:  Zuerst sammeln, dann analysieren. Die Fluten fassen, was wir damit tun, finden wir später heraus.

Datenanalyse im verteilten System

Es entstanden neue Tools, um Daten in verteilten Systemen zu analysieren.  Das Spezielle an den Tools:

Die Programme werden zu den Daten getragen – die Analyse wird verteilt auf die einzelnen Rechner des verteilten Systems. Grundlage ist MapReduce. Hochkomplexe Systeme – entwickelt von tragfähigen Open Source Communities.

Apache Spark ist ein gutes Beispiel:

Apache Spark-Architektur
Spark unterstützt Python, R, Scala, Java und SQL
  • Das Programm zur Datenanalyse wird im Spark-Driver in einen Ausführungsplan umgewandelt.
  • Die Programme zur Analyse werden an die Worker geschickt.
  • Auf jedem Worker liegt ein Teil der Daten.
  • Der Driver koordiniert die oft komplexe Ausführung der verteilten Analyse und bereitet das Endergebnis auf.

Bei jeder Datenanalyse werden die Rohdaten zuerst transformiert und danach analysiert.

Es sind hochkomplexe Systeme und mittlerweile werden sie gerne dort eingesetzt, wo riesige Datenmengen schnell analysiert werden.

Es gibt eine ganze Reihe von Tools, die auf verteilten Systemen arbeiten. In den letzten 10 Jahren wurden sie laufend perfektioniert und die Reise ist noch nicht zu Ende.

ELT

Doch die Realität holt uns auch hier ein: zuverlässige Analyseergebnisse erzielen wir nur auf sauber bereinigten Daten. In einem Data Lake werden die Daten immer wieder transformiert – ein unnötiger Overhead.

Die Verarbeitungskette heißt jetzt ELT – extract-load-transform: Man hole die Daten aus dem Quellsystem, lade sie zuerst in den Data Lake und transformiere sie on demand für die jeweilige Analyse und das immer wieder für jede Analyse.

Data Lakehouses und ELT

Der Bedarf ist erkannt: Data Lakes haben zu wenig Struktur, wir benötigen ähnliche Eigenschaften wie bei Data Warehouses:

  • Katalog mit Metadaten
  • Struktur und Governance
  • Bereinigte Daten in kontrollierten Formaten
ELT im Data Lakehouse
ELT im Data Lakehouse - stark vereinfachte Darstellung.

Anders als ETL in klassischen Data Warehouses wird ELT in Data Lakes/Data Lakehouses gar in Echtzeit ermöglicht:  Analyse Ergebnisse liegen also nahezu sofort vor. Und wir sind nicht beschränkt auf SQL sondern können Machine Learning Modelle nahtlos einbinden.

Data Warehouses vs. Data Lakehouses

Data Lakehouses ist also nicht einfach alter Wein in neuen Schläuchen. Die Tabelle zeigt die markantesten Unterschiede:

Klassisches
Data Warehouse
Data Lakehouse
Skalierbarket vertikal (RAID) horizontal – verteilte Filesysteme
Datenvolumen GB-TB TB – PB – ZB
Datenformat proprietär offen
Analytics Engine proprietär – auch SQL Open Source – auch SQL
Machine Learning (KI) nein ja
Echtzeit ETL / ELT nein ja
Technologische Reife hoch jung – in Entwicklung

Die Grenzen verwischen – das Wording ist unklar – was beispielsweise ist ein Cloud Data Warehouse? Die Marketing Abteilungen sind kreativ.

Die wichtigste Eigenschaft: Data Lakehouses arbeiten mit offenen Dateiformaten. Sind die Daten einmal transformiert, beispielsweise in ein Parquet-Format oder ein Delta Lake-Format, dann sind viele unterschiedliche Tools in der Lage, sie zu analysieren.

Neue Perspektiven für Data Lakes

Offene Systeme sind gefragt. Und so entstehen neue Cloud Dienstleistungen mit den folgenden Eigenschaften.

  • Offene Datenformate für Tabellen, Texte, Bilder, Videos etc
  • Offene Schnittstellen
  • Metadatenkataloge
  • Governance
  • Nochvollziehbarkeit der Veränderungen: Data Lineage – wann wirkte was wie auf den Daten, um zum aktuellen Zustand und Ergebnis zu gelangen.

Dem Data Lake werden also Data Warehouse Eigenschaften verpasst und so entsteht ein Data Lakehouse.

Die Vorteile der Cloud

Ein neuer Schub an Entwicklungen steht uns bevor.

Und da alles Cloud basiert ist, soll es einfach werden, mit einem Klick und gezückter Kreditkarte den Service eines anderen cloudbasierten Providers auf den wohlpräparierten Daten im Lakehouse wirken zu lassen.

Beispielsweise das ultimativ gute Machine Learning Modell eines anderen Cloud Anbieters.

  •  

  • Abo: Data Engineering und Analytics
  • Abo: Data Engineering und Analytics