create mobile friendly website
Wie groß ist Big Data

Neue Reihe: Big Data - Informationen neu gelebt

Wie big ist Big Data?

NoSQL, Hadoop, Map Reduce, HDFS, Storm, Hive, Spark,… Eine Vielzahl von Technologien wird im Umfeld von Big Data eingesetzt und wenn man manchen Veröffentlichungen Glauben schenken würde, dann werden durch sie alle unsere Probleme wie durch Zauberhand gelöst. Das ist in der Regel aber nicht der Fall! Durch den unüberlegten Einsatz können leicht Probleme gelöst werden, die es vorher gar nicht gab. Unsere neue Artikelreihe zum Thema Big Data startet mit einem ersten Überblick. In den folgenden Ausgaben werden die einzelne Technologien und Anwendungsfälle genauer beschrieben.

Was ist Big Data überhaupt?

Wenn man nach einer Definition von Big Data sucht, dann stößt man schnell auf das 3V-Modell. Dieses geht auf ein Dokument von Doug Laney aus dem Jahr 2001 zurück [Quelle 1]. Getrieben durch E-Commerce, die fortschreitende Digitalisierung und die sozialen Netzwerke sind die Anforderungen an das Datenmanagement in den drei Dimensionen Volumen (Volume), Vielfalt (Variety) und Geschwindigkeit (Velocity) explodiert. Viele der dadurch entstehenden Probleme können durch den Einsatz von Big-Data-Systemen gelöst werden.

Volumen - Wie big ist Big Data?

Viele Technologien sind aus der Notwendigkeit entstanden, riesige Datenmengen kostengünstig zu speichern und zu verarbeiten. Beim benötigten Speicherplatz wird dabei oft in Terrabyte oder Petabyte gerechnet. Zum Beispiel hat Twitter aktuell 284 Millionen aktive Benutzer die 500 Millionen Tweets am Tag versenden. Zusammen mit Metainformationen – wie Zeit, Geo-Lokation und Absender sowie den Log-Daten der beteiligten Systeme – werden jeden Tag mehr als 12 TB Daten erzeugt und gespeichert [Quelle 2].

Vielfalt - Wie unstrukturiert ist Big Data?

Oft wird davon gesprochen, dass Big-Data-Systeme unstrukturierte Daten speichern und verarbeiten können. Das ist erst einmal richtig. Um die Informationen analysieren zu können muss dann aber wieder Struktur in die Daten gebracht werden. Im Unterschied zu einer klassischen relationalen Datenbank wird die Struktur nicht beim Schreiben definiert sondern oft erst beim Lesen der Daten. Weiter­hin können die Systeme sehr gut mit unterschiedlichen und sich verändernden Strukturen umgehen. So muss nicht jeder eingefügte Datensatz die gleichen Attribute be­sitzen. Ein typisches Beispiel für uneinheitliche Strukturen ist der Produktkatalog großer Online-Händler. Artikel aus verschiedenen Produktkategorien haben oft sehr unterschiedliche Eigenschaften. Die Speicherung und Analyse von Bild-, Video- und Audiodateien erhöht die Vielfalt der Daten nochmals beträchtlich.

Geschwindigkeit - Wie schnell ist Big Data?

„Zeit ist Geld“ hieß es schon lange bevor über Big Data geredet wurde. Aber auch bei der Auswertung großer Datenmengen hat diese Redewendung ihre Berechtigung. Für ein soziales Netzwerk ist es zum Beispiel unerlässlich, dass Nachrichten schnell zugestellt werden. WhatsApp wäre nicht so erfolgreich, wenn die Zustellung einer Nachricht Minuten dauern würde. Ähnliches gilt für die Auswertung der Daten. Die klassische Analyse von Daten mittels einer Batch-Verarbeitung hat zwar noch lange nicht ausgedient, der Bedarf, große Datenmengen innerhalb weniger Millisekunden zu verarbeiten, steigt hingegen rasant an.

Welche technischen Probleme werden gelöst?

Relationale Datenbanken skalieren vertikal in der Regel sehr gut. Mehr Hauptspeicher und CPUs sind oft ein geeignetes Mittel um die Performance zu verbessern. Allerdings sind der vertikalen Skalierbarkeit Grenzen gesetzt. Zum einen durch die maximale Erweiterbarkeit der verfügbaren Rechner und in der Praxis oft sehr viel früher durch den Preis sehr großer Rechner. Auch die horizontale Skalierbarkeit ist in der Regel sehr begrenzt, denn bei steigender Anzahl von Knoten steigt der Verwaltungsaufwand zur Durchführung von ACID-Transaktionen überproportional.

Viele Big Data Systeme sind von Haus aus verteilte Systeme. Sie skalieren sowohl vertikal als auch horizontal sehr gut. Während zum Beispiel ein Oracle RAC Cluster mit zwölf Knoten schon sehr groß ist, sind mehrere hundert Knoten in einem Big Data System nicht ungewöhnlich.

Die Systeme bestehen dabei oft aus vielen relativ günstigen Rechnern mit lokalen Festplatten. Auf große und teure Storage-Systeme wird vollständig verzichtet. Um die Verfügbarkeit der Systeme zu erhöhen und dem Verlust von Daten durch einen Defekt vorzubeugen werden alle Daten redundant im Cluster gespeichert. Dadurch kann auch die Verarbeitung der Daten beschleunigt werden, denn parallele Prozesse können auf mehrere Knoten verteilt werden. Ausfälle einzelner Knoten sind bei einem großen Cluster unvermeidlich. Diese werden aber akzeptiert und das System stellt beim Ausfall eines Knotens sicher, dass die Daten und die aktuell laufenden Prozesse im Cluster neu verteilt werden.

Womit können die Probleme gelöst werden?

Es gibt eine riesige Auswahl an Technologien im Umfeld von Big Data. Während dieser Artikel einen ersten Überblick gibt, werden in den nächsten Teilen dieser Reihe einige Technologien genauer betrachtet. Den Anfang machen NoSQL-Datenbanken [1-4]. Diese gibt es für verschiedene Einsatzzwecke. Sie dienen in vielen großen Systemen als Ergänzung zu einer relationalen Datenbank, können diese aber unter bestimmten Voraussetzungen auch vollständig ersetzen. Ein kurzer Überblick folgt in den nächsten Abschnitten.

Eine weitere wichtige Komponente in vielen Big-Data-
Systemen ist Apache Hadoop. Dabei handelt es sich nicht um ein einzelnes Produkt. Vielmehr ist es eine Sammlung von unterschiedlichen Open-Source-Projekten, die auf­einander aufbauen. Zentrale Komponenten sind dabei das verteilte Hadoop-Dateisystem (HDFS) und das darauf aufsetzende MapReduce-System zur parallelen Verarbeitung riesiger Datenmengen.

Als letzte Komponente werden die Stream-Processing-Systeme Storm und Spark Streaming kurz vorgestellt. Dabei handelt es sich um verteilte Systeme zur Verarbeitung von Datenströmen in Echtzeit.

NoSQL-Datenbanken

Ursprünglich wurde der Begriff NoSQL für Datenbanken verwendet, die nicht relational waren und auch kein SQL unterstützt haben. Im Lauf der Zeit hat sich einiges geändert und SQL-fähige NoSQL-Datenbanken (zum Beispiel Apache Cassandra) entstanden. Heutzutage steht der Begriff für „Not only SQL“. NoSQL-Datenbanken können wie folgt kategorisiert werden (siehe Abbildung 1):

  • Key-Value
  • Spaltengruppenorientiert
  • Dokumentenorientiert
  • Graphen

CAP-Theorem

Eine wichtige Eigenschaft von Big-Data-Systemen ist die Speicherung riesiger Datenmengen. Wie bereits erwähnt, wird dies durch die horizontale Verteilung der Daten in einem Cluster realisiert. Damit sind aber auch Einschränkungen verbunden. In einem verteilten System ist es laut dem CAP-Theorem nicht möglich die drei Eigenschaften Konsistenz (Consistency), Verfügbarkeit (Availability) und Parti­tionstoleranz gleichzeitig zu garantieren [Quelle 3]. Es muss immer auf eine dieser Eigenschaften verzichtet werden (siehe Abbildung 2). Aus diesem Grund sind verteilte
Datenbanken auch nicht ACID-fähig.

Welche Eigenschaften unterstützt werden, ist von Datenbank zu Datenbank verschieden. Bei einigen Systemen hat der Entwickler sogar Einfluss auf die unterstützten Eigenschaften und kann sich entscheiden, ob zum Beispiel die Verfügbarkeit oder die Konsistenz garantiert werden soll. Nicht verteilte (No)SQL-Datenbanken (wie zum Beispiel Neo4J) haben diese Einschränkungen nicht und können somit auch ACID unterstützen.

Polyglott Persistence

Vor allem die fehlende Unterstützung von ACID-Trans­aktionen führt dazu, dass eine NoSQL-Datenbank alleine oft nicht ausreicht, um ein Problem zu lösen. In einem E-Commerce-System kann der Produktkatalog zum Beispiel problemlos in einer dokumentenorientierten Datenbank ver­waltet werden. Die Bestellungen und Bezahlvorgänge der Kunden würde man allerdings in einer relationalen Datenbank speichern. Für diese gleichzeitige Nutzung unterschiedlicher Datenbanken hat sich der Begriff „Polyglott Persistence“ durchgesetzt. Da eine zweite Datenbank zusätzliche Komplexität in ein System bringt, sollte die Entscheidung wohl überlegt sein. Sobald erhebliche Aufwände dadurch entstehen, dass man ein Problem mit der falschen Datenbank lösen will, sollte man nochmal in seinem Werkzeugkasten nach einem geeigneteren Werkzeug suchen.

Apache Hadoop

Der Kern von Apache Hadoop besteht aus dem verteilten Hadoop Filesystem (HDFS) und dem MapReduce-System zur parallelen Verarbeitung der gespeicherten Daten. HDFS speichert alle Daten in relativ großen Blöcken (>= 64 MB) redundant im Cluster. MapReduce wiederum ist ein Programmiermodell für die Verarbeitung dieser Daten. Es abstrahiert vom physikalischen Lesen, Schreiben und Versenden der Daten im verteilten Hadoop-System. Weiterhin kümmert es sich automatisch um die Aufteilung von Jobs in einzelne Tasks und deren parallele Ausführung im Cluster.

Hadoop-Distributionen

Das Hadoop-Ökosystem besteht nicht nur aus HDFS und MapReduce. Zusätzlich zu diesem Kern gibt es noch viele weitere Open-Source-Projekte, in denen weitere Komponenten für Hadoop entwickelt werden. Einige davon sind in der Abbildung 3 aufgelistet. Allerdings werden diese Komponenten mehr oder weniger unabhängig voneinander weiterentwickelt. Um Probleme mit Inkompatibilitäten zu vermeiden oder wenigstens zu verringern empfiehlt es sich, auf eine vorgefertigte Hadoop-Distribution zurück­zugreifen. Wie auch im Linux-Umfeld gibt es Hersteller, die aus den verschiedenen Komponenten ein vollständiges System zusammenstellen. Dies wird dann oft um Installations- und Management-Tools erweitert und zusammen mit Supportverträgen angeboten. Die bekanntesten Anbieter von Hadoop-Distributionen sind Cloudera, Hortonworks und MapR.

Abfragesprachen

MapReduce-Jobs sind im Wesentlichen Programme, die in einer höheren Programmiersprache wie zum Beispiel Java implementiert sind und anschließend als Batch Job ausgeführt werden. Das ist auf der einen Seite extrem flexibel, da jeder Datentyp analysiert und verarbeitet werden kann. Für ad-hoc- oder Standardabfragen ist es aber eine große Hürde immer erst ein Programm schreiben zu müssen. Eine Abfragesprache, wie z.B. SQL, wäre hier sehr hilfreich.

Für dieses Problem gibt es verschiedene Lösungen. Die zwei bekanntesten sind Pig und Hive. Beide gehören standardmäßig zu den bekannten Hadoop-Distributionen. Während Pig die eigene Sprache PigLatin für Abfragen verwendet, werden Hive-Abfragen in SQL formuliert. In beiden Fällen wird im Hintergrund ein MapReduce-Job gestartet. Das ist für eine Batch-Verarbeitung in der Regel völlig in Ordnung. Für interaktive Abfragen, bei denen innerhalb von wenigen Sekunden eine Antwort erwartet wird, sind MapReduce-Jobs aber zu träge. Dieses Problem wird aktuell von mehreren Projekten angegangen. So gibt es die Stinger-Initiative, die sich um die Weiterentwicklung von Hive kümmert. Andere Projekte sind Impala von Cloudera und Spark SQL.

Stream Processing

Auch für die Verarbeitung von Datenströmen in Echtzeit gibt es geeignete Lösungen. Genutzt werden diese zum Beispiel bei der automatisierten Analyse von Daten aus sozialen Netzwerken (z.B. Twitter Feeds). Ein weiterer typischer Anwendungsfall ist die Überwachung von Transaktionen zur Erkennung von Betrugsversuchen. Verbreitete Systeme sind Apache Storm und Apache Spark Streaming. Mit beiden kann sehr leicht ein horizontal skalierbares und hoch verfügbares System aufgebaut werden.

Im Gegensatz zu Haddoop oder NoSQL-Datenbanken können aber weder Storm noch Spark Streaming Daten speichern. Als Persistenzschicht wird in der Regel eine verteilte NoSQL-Datenbank verwendet. Einige der Hadoop-Distributionen enthalten bereits Storm und/oder Spark und bieten damit eine etwas leichtere Installation, Integration und Überwachung dieser Komponenten.

Fazit

Wie bereits eingangs erwähnt, gibt dieser Artikel zunächst einen Überblick über das Thema Big Data und die eingesetzten Technologien. Für die ersten eigenen Gehversuche bietet es sich an, eine der verfügbaren Hadoop-Distributionen zu installieren oder aber eine fertige virtuelle Maschine zu verwenden. Beides ist kostenlos bei den großen Hadoop-Distributoren erhältlich. Für einen tiefergehenden Einblick werden in den nächsten Ausgaben der ORDIX® news weitere Artikel zu Big-Data-Technologien folgen.

Gerne begrüßen wir Sie auch zu unserem eintägigen Seminar „Big Data: Informationen neu gelebt“ [5] in dem wir Ihnen einen umfassenden Überblick über die ver­schiedenen Technologien und deren Einsatzmöglichkeiten geben. Oder aber unsere Experten kommen zu Ihnen, um ganz konkret über Ihre Anforderungen und deren Um­setzung zu sprechen.

Olaf Hein
(

Die ORDIX AG - dafür stehen wir

Innovative Technologien und wachsende Anforderungen im IT-Umfeld prägen unser Geschäft. Für unsere Kunden bieten wir maßgeschneiderte, intelligente IT-Lösungen mit einem pragmatischen Ansatz, entwickelt nach aktuellen Standards und Zertifizierungen. Wir stellen uns jederzeit den Herausforderungen, die durch die zunehmende Digitalisierung entstehen und unterstützen unsere Kunden, wenn es beispielsweise um Themen wie Java EE, Datenbanken, Virtualisierung, Security, Big Data, Storage und Backup und Recovery geht.

Unser Kerngeschäft umfasst das komplette Dienstleistungsspektrum „ORDIX® best practice“ rund um die IT-Beratung, Softwareentwicklung, Service, Training und Projektmanagement.

News und Pressemitteilungen

ORDIX sucht Nachwuchs auf der hobit 2017
Mit der hobit 2017 hat die ORDIX AG vom 24. bis 26.01.2017 das erste Mal an der Darmstädter Ausbildungsmesse teilgenomme...
Weiterlesen ...
Duales Studium bei der ORDIX AG – Dein Weg in die IT!
Du bist gerade mit Deinem Abitur fertig, wissbegierig und möchtest den ersten Grundstein für Deine berufliche Zukunft l...
Weiterlesen ...

Abbildungen

Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum

Impressum der ORDIX® news 1/2015

Links

Reihe "NoSQL vs. SQL - Hype oder echte Alternative?"
[1] Teil I: Was sind NoSQL-Datenbanken?“
[2] Teil II: Oracle NoSQL“
[3] Teil III: CouchDB - Time to Relax”
[4] Teil IV: HBase – Spaltenorientiert“
[5] Seminarempfehlung:
Big Data: Informationen neu gelebt

Quellen

[1] Laney, Doug: „3-D Data Management: Controlling Data Volume, Velocity and Variety“, 2001
[2] Twitter: https://about.twitter.com/company
http://de.slideshare.net/kevinweil/analyzing-big-data-at-twitter-web-20-expo-nyc-sep-2010
[3] Wikipedia „CAP-Theorem“

Bildnachweis

© unplash.com | Juskteez | Stars
© fotolia.de | mindscanner | Word Cloud "Big Data"
© sxc.hu | pipp | notebook
© freepik.com | Technology background with planet
© freepik.com | Infographic chart