Die Daten, die wir generieren, teilen sich in strukturierte, semistrukturierte und unstrukturierte Daten auf. Schaut man sich die Verteilung der Datenarten in einem üblichen Unternehmen an, so sind ca. 85% aller gespeicherten Daten unstrukturierte oder semistrukturierte Daten und nur ca. 15% der im Unternehmen verfügbaren Informationen werden als strukturierte Daten gespeichert.

Unter strukturierten Daten​​ versteht man die Daten, die ein vorgegebenes Format haben und in relationalen Datenbanksystemen gespeichert werden können. Beispiele für strukturierte Daten sind Kundendaten in einem CRM-System oder Rechnungsdaten in einem ERP-System. Ein typisches Beispiel für unstrukturierte Daten ​​stellen Office-Dokumente oder Bilder dar. Grundsätzlich besitzen diese Daten natürlich schon eine Struktur, die durch den Dateityp, in dem sie gespeichert sind, vorgegeben wird. So wird eine Word-Datei beispielsweise in einem bestimmten, von Excel unterschiedlichen Format gespeichert. Jede Word-Datei besitzt dabei einen sehr ähnlichen Aufbau.

In diesem Zusammenhang geht es aber darum, dass es innerhalb der Word-Datei keinen wirklichen semantischen Kontext gibt. Anhand des Datentyps kann man nicht entscheiden, ob es sich um eine Rechnung, ein Kapitel aus einem Roman oder ein Kapitel aus diesem Buch handelt. Im Gegensatz dazu weiß man bei einer relationalen Tabelle, welche Inhalte in dieser Tabelle gespeichert sind und in welchem Feld welche Information zu finden ist. Außerdem ist für jedes Feld ein Datentyp klar definiert, so dass das Datenbanksystem jederzeit weiß, ob in der entsprechenden Spalte eine Zahl, ein Datum oder eine Zeichenkette gespeichert werden kann.

Das steht in klarem Gegensatz zu einer Tabellenkalkulation ​wie beispielsweise Excel. In Excel​ kann man natürlich auch eine Tabellenstruktur ähnlich wie in einer relationalen Datenbank erzeugen. Im Gegensatz zu einer relationalen Datenbank ist der Datentyp der einzelnen Felder bzw. Spalten in Excel nicht definiert und wird somit auch nicht vom System überwacht. Wenn Sie beispielsweise eine Spalte erstellen, in der man Umsätze speichern kann, so wird Excel Sie nicht davon abhalten, in diese Spalte einen Text wie beispielsweise »Hallo« einzufügen. (Jeder, der schon mal Excel-Dateien in ein relationales Datenbanksystem importiert hat, weiß, was ich meine.) Daher spricht man auch im Zusammenhang mit Excel von unstrukturierten Daten, da innerhalb der Daten, im Gegensatz zum relationalen Datenbanksystem, keine Struktur erzwungen werden kann.

Neben den strukturierten und den unstrukturierten Daten gibt es noch semistrukturierte Daten. Unter semistrukturierten Daten ​​versteht man Daten, die in einer unstrukturierten Datenquelle wie beispielsweise einer Textdatei gespeichert werden, dort aber eine inhärente Struktur aufweisen. Ein sehr gutes Beispiel für semistrukturierte Daten stellt eine XML-Datei dar. Grundsätzlich ist eine XML-Datei zunächst einmal nichts anderes als eine Textdatei. Innerhalb dieser Textdatei wird eine Struktur mit Hilfe von Elementen und Attributen erzeugt. Ein Element wird durch Tags begrenzt, die wiederum Attribute beinhalten können. Ein einfaches Beispiel für eine XML​-Datei können Sie im folgenden Listing sehen:

<Person PersonId="1">
    <Name>Frank Geisler</Name>
    <Firma>Geisler Datensysteme</Firma>
</Person>

Das Tag <Person> leitet einen Datensatz vom Typ Person ein. Innerhalb des Tags <Person> befindet sich das Attribut PersonId, das einen Schlüsselwert für den Personendatensatz enthält. Im Beispiel hat dieses Attribut den Wert 1. Der Personendatensatz wird durch das schließende Tag </Person> beendet. Alles, was sich zwischen dem öffnenden und dem schließenden Tag befindet, wird dem Personendatensatz zugerechnet. Neben Attributen besteht eine XML-Datei zusätzlich aus Elementen. Ein Beispiel dafür ist das Element <Name>. Alles, was sich zwischen dem öffnenden Tag <Name> und dem schließenden Tag </Name> befindet, wird als Name interpretiert. Neben der eigentlichen XML-Datei, die die Daten enthält, kann man zusätzlich noch eine XML-Schemadatei definieren. In dieser Schemadatei wird der Aufbau der Datendatei beschrieben.

Die Regeln für eine gültige XML-Datei​ sind strenger als die Regeln für eine HTML-Datei. Während die meisten Browser fehlenden End-Tags gegenüber recht tolerant sind, dürfen bei einer XML-Datei diese Tags nicht fehlen. Bei XML-Dateien gibt es zwei Validierungsstufen, die Stufe wohlgeformt und die Stufe gültig. Eine XML-Datei wird als wohlgeformt bezeichnet, wenn es zu jedem öffnenden Tag auch ein entsprechendes schließendes Tag gibt. Entspricht die Struktur der XML-Datei der im Schema definierten Struktur, so ist diese XML-Datei bezogen auf das Schema gültig.

Der Übergang zwischen strukturierten, semistrukturierten und unstrukturierten Daten ist fließend. Relationale Datenbanksysteme sind heutzutage in der Lage, strukturierte Daten als semistrukturierte Daten auszugeben, semistrukturierte Daten zu interpretieren oder auch innerhalb der Datenbank abzuspeichern. Vielen der unstrukturierten Daten, wie beispielsweise Word- oder Excel-Dateien, liegen semistrukturierte Datenmodelle zugrunde. Eine Word-Datei im Format .docx ist nichts anderes als ein ZIP-Container​, das heißt, wenn Sie das Dateisuffix in .zip umbenennen, können Sie eine Word-Datei genau wie eine Archivdatei öffnen. Im ZIP-Container finden Sie dann eine Vielzahl von XML-Dateien. In moderneren Office-Versionen (ab 2007) ist es möglich, neben dem XML-Schema, das den Aufbau und die grafische Gestaltung der Office-Datei beschreibt, auch ein eigenes XML-Schema anzulegen, über das man den Inhalt der Office-Datei näher beschreiben kann. So wird aus einer unstrukturierten Datei eine semistrukturierte Datei.

Alle oben beschriebenen Datenarten können natürlich unabhängig voneinander erstellt, verwaltet und gespeichert werden. Die Krux an dieser Stelle ist aber, dass die Datenarten nicht voneinander unabhängig sind, das heißt, strukturierte Informationen, die über einen Kunden in der relationalen Datenbank eines CRM-Systems gespeichert wurden, stehen in Beziehung zu unstrukturierten Präsentationen, die für den Kunden erstellt, oder Briefen, die an den Kunden geschrieben wurden. Informationen zu einem bestimmten Produkt des Unternehmens werden im ERP-System des Unternehmens gespeichert, gleichzeitig gibt es aber im Internet Twitter-Tweets, die mit diesem Produkt in Beziehung stehen.

Auch wenn es sicherlich schön wäre, die Neuerungen, die sich bei der Datenverarbeitung ​ergeben, rein auf die Software, die die Daten verarbeitet, zu reduzieren, ist dies nicht möglich, da Daten nicht im luftleeren Raum erzeugt und verarbeitet werden. Seitdem Daten elektronisch verarbeitet wurden, gab es immer Wechselwirkungen zwischen der eigentlichen Datenverarbeitung und der Entwicklung in anderen Bereichen der IT. So müssen heute bei der Betrachtung der Datenverarbeitung neben den zusätzlichen Möglichkeiten, die Datenbankmanagement-Systeme bieten, auch andere Fortschritte und Paradigmenwechsel in der IT betrachtet werden. So sind beispielsweise die Kosten für Speicherplatz in den vergangenen dreißig Jahren rapide gesunken. Während man 1981 noch ca. 300.000 Dollar für ein Gigabyte Speicherplatz bezahlen musste, kostet dieselbe Speichermenge 2012 gerade noch 0,10 Dollar.

Das führt natürlich dazu, dass es heutzutage recht kostengünstig ist, sehr große Datenmengen anzulegen und zu speichern. Auf der anderen Seite haben die Fortschritte bei der Prozessortechnik sowohl durch höhere Taktraten wie auch durch eine immer effektivere Parallelisierung (inzwischen sind Prozessoren mit mehreren Kernen Standard in Smartphones) dazu geführt, dass die gigantischen Datenmengen, die erzeugt und gespeichert werden, auch verarbeitet und ausgewertet werden können. Durch Virtualisierung und Cloud Computing ist der Aufbau und die Handhabung von IT-Systemen wesentlich vereinfacht worden. Möchte man einen neuen Datenbankserver bereitstellen, muss dieser nicht mehr aufwändig auf einer extra dafür beschafften Hardware installiert werden, sondern kann bequem im Rechenzentrum als virtuelle Maschine instanziiert werden. So sinkt die Zeit, bis ein neuer Datenbankserver genutzt werden kann, von Wochen, in denen der Server bestellt, zusammengebaut und installiert werden musste, auf wenige Minuten, die der Virtualisierungscluster benötigt, um das gewünschte System zur Verfügung zu stellen.

All diese Fortschritte, die es in der IT gegeben hat, führen dazu, dass wir mit Daten heute anders umgehen und diese auch anders verwalten müssen. Ein neuer Trend, der sich vor diesem Hintergrund ergeben hat, wird als Big Data ​bezeichnet. Eine Datenquelle, die unter den Begriff Big Data fällt, muss in Bezug auf die zu verwaltenden Daten die folgenden drei Charakteristika erfüllen:

• eine sehr große Datenmenge

• eine sehr hohe Änderungsgeschwindigkeit

• eine sehr große Variabilität der Daten

Der Umgang mit großen Datenmengen ist heutzutage nichts Außergewöhnliches mehr. Jedes Data Warehouse von mittelgroßen bis großen Unternehmen kann schnell ein Datenvolumen von mehreren Terabyte umfassen und moderne Datenbankmanagement-Systeme sind, die entsprechende Hardware vorausgesetzt, leicht dazu in der Lage, mit einer derartigen Datenmenge umzugehen. Was Big Data neben der großen Datenmenge aber auszeichnet, ist sowohl die hohe Änderungsgeschwindigkeit wie auch die große Variabilität der Daten. In einem klassischen Data Warehouse sind diese beiden Kriterien nicht gegeben. Üblicherweise werden die Daten über Nacht oder höchstens mehrmals am Tag in das Data Warehouse geladen, das heißt, es geht hier um Daten, die sich maximal im Stundenrhythmus ändern können. Bei Big-Data-Projekten geht es um Datenänderungen im Minuten- oder sogar im Sekundentakt. Auch die große Variabilität der Daten ist in einem klassischen Data Warehouse nicht gegeben. Natürlich können in einem Data Warehouse sehr viele Daten zu unterschiedlichsten Themen abgespeichert werden. Die Struktur der Daten ist aber durch das relationale Schema des Data Warehouses vorgegeben und ändert sich über die Zeit gesehen nicht grundlegend.

In der englischsprachigen Literatur findet man in Bezug auf die Eigenschaften einer Big-Data-Datenquelle auch oft den Begriff »three Vs«. Damit sind Volume (Datenmenge), Velocity (Änderungsgeschwindigkeit der Daten) und Variety (Varianz der Daten) gemeint.

Ziel eines Big-Data-Projekts ist es immer, Unternehmen dazu in die Lage zu versetzen, eine ungeheuer große Datenmenge mit der richtigen Geschwindigkeit zu sammeln, zu speichern, zu verwalten und zu verarbeiten, damit zur richtigen Zeit die richtigen Informationen zur Verfügung stehen und ausgewertet werden können. Heutzutage sind Unternehmen in der Lage, so viele Daten aus so vielen unterschiedlichen Datenquellen zu verarbeiten wie noch nie in der Geschichte zuvor. War die Datenverarbeitung früher oft auf das eigene Unternehmen beschränkt, ist es heutzutage möglich, sehr viele öffentliche Datenquellen über das Internet in die eigene Datenverarbeitungsstrategie einzubeziehen und entsprechende Auswertungen zu erzeugen. Die ungeheure Datenmenge sieht auf den ersten Blick wie eine vielversprechende Goldmine aus. Wie jede andere Goldmine besteht aber auch ein Big-Data-Projekt aus wenig Gold und vielen anderen Dingen. Unerlässlich ist es, das wertvolle Gold vom Rest zu trennen. Wichtige Fragen, die ein Unternehmen, das eine Big-Data-Strategie aufbauen möchte, beantworten muss, sind:

• »Wie kann ein Unternehmen mit den ungeheuren Datenmengen in sinnvoller Art und Weise umgehen?«

• »Wie kann man Daten auswerten, in denen es keine einfach auszumachenden Muster gibt, die der aktuellen Geschäftsstrategie entsprechen?«

Da Big Data keine neue Technologie, sondern die Kombination aus bisher verwendeten Techniken darstellt, werden wir untersuchen, wie sich die Datenverarbeitung entwickelt hat. Schaut man sich die Geschichte der Datenverarbeitung an, kann man drei unterschiedliche Stufen ausmachen, die sich aus den jeweiligen technischen Randbedingungen ergeben haben. In der ersten Stufe ging es darum, Datenstrukturen zu erstellen, mit denen man Daten sinnvoll verwalten konnte. Auf der zweiten Stufe ging es um das Web und die Verwaltung von Inhalten. Bei der dritten Stufe geht es schließlich um die Verwaltung von Big Data.

Unter dem Begriff »Big Data« versteht man keine einheitliche Technologie, sondern die Kombination aus alten und neuen Technologien, die dabei helfen soll, Erkenntnisse auf Basis einer sehr großen Datenmenge zu erlangen. Big-Data-Projekte zeichnen sich dadurch aus, dass man eine große Menge unterschiedlicher Daten in der richtigen Geschwindigkeit im richtigen Zeitintervall analysiert, um Echtzeitanalysen realisieren zu können. Auf Basis der Echtzeitanalyse können dann die entsprechenden Aktionen unternommen werden, um auf die Erkenntnisse aus der Echtzeitanalyse zu reagieren. Wie bereits oben beschrieben haben die Datenmengen, die Big-Data-Projekten zugrunde liegen, die folgenden, gemeinsamen Charakteristiken: Umfang, Geschwindigkeit und Variabilität.

Wie stark die einzelnen Charakteristiken bei verschiedenen Big-Data-Projekten ausgeprägt sind, hängt immer sehr stark von den Anforderungen des Projekts ab. So gibt es beispielsweise Big-Data-Projekte, die mit relativ kleinen Datenmengen agieren, die aber sehr unterschiedlich sind und sich sehr schnell ändern. Genauso gut sind Big-Data-Projekte denkbar, bei denen sich die Daten nicht sehr stark ändern und relativ gleichförmig sind, es aber eine ungeheure Menge dieser Daten gibt.

In Abbildung 14.4 wird verdeutlicht, in welchem Spannungsverhältnis die Daten eines Big-Data-Projekts stehen.

Manche Experten fügen diesen drei Punkten einen weiteren, vierten Punkt hinzu: die Relevanz (engl. Veracity – Aufrichtigkeit). Bei dieser Eigenschaft geht es darum, wie relevant die Daten, die im Big-Data-Projekt ausgewertet werden sollen, für das Unternehmen sind. Sind diese Daten nicht relevant, macht es auch keinen Sinn, sie in einem Big-Data-Projekt zu verarbeiten. Wichtig ist, dass die Daten identifiziert werden, die für das Analyseziel des Projekts relevant sind. Diese Daten können in allen erdenklichen Formen wie beispielsweise E-Mails, Inhalten in sozialen Medien, Texten usw. vorkommen. Um eine umfassende Analyse zu ermöglichen, müssen im Rahmen eines Big-Data-Projekts Daten aus strukturierten, semistrukturierten und unstrukturierten Datenquellen vereinigt werden.

Bei Big-Data-Projekten ​gibt es, wie in anderen Projekten auch, einen Projektzyklus. Big-Data-Projekte werden heutzutage genau wie andere Software- oder IT-Projekte nicht linear, sondern iterativ entwickelt, das heißt, man beginnt mit dem Projekt, stellt eine erste Version fertig und baut, basierend auf dieser Version, die nächste Version des Projekts auf.

Der Projektzyklus von Big-Data-Projekten teilt sich in die Phasen Datensammlung, Datenorganisation, Datenintegration, Datenanalyse und eine aus der Datenanalyse abgeleitete Handlung auf. Dieser Projektzyklus wird in der Regel mehrfach durchlaufen.

Zunächst muss geklärt werden, welche Daten überhaupt gesammelt werden sollen und wie die Datensammlung erfolgen soll. Ist klar, welche Daten gesammelt werden, muss als Nächstes überlegt werden, wie diese Daten organisiert werden sollen. Wichtig in diesem Schritt ist es, dass man auch die erwartete Datenmenge abschätzt und sich überlegt, wie die Daten aus den unterschiedlichen Datenquellen miteinander in Beziehung gebracht werden können. Nur wenn man datenquellenübergreifende Beziehungen in einem Big-Data-Projekt ermitteln kann, kann sich aus der Datenanalyse echter Mehrwert für das Unternehmen ergeben. Daher ist es notwendig, dass man die Daten anhand einer eingeschränkten Datenmenge validiert, um herauszufinden, ob die Kombination der Daten aus den unterschiedlichen Datenquellen überhaupt Sinn ergibt und ob man die ursprüngliche Fragestellung mit dieser Kombination beantworten kann.

Neben den eigentlichen Daten muss man sich auch über die Art der Daten Gedanken machen. Handelt es sich bei den Daten beispielsweise um vertrauliche Daten wie Kundendaten oder Daten, die dem Datenschutz unterliegen, muss man entsprechende Sicherheitsmechanismen implementieren oder die für die Analyse verwendeten Daten anonymisieren. Nachdem man die Daten organisiert hat, muss man sich nun Gedanken über die Datenintegration machen, das heißt, sich überlegen, wie man die Daten in das Big-Data-Projekt integrieren möchte und wie häufig diese Datenintegration stattfinden soll (einmal am Tag? Jede Stunde? Alle 10 Minuten?). Neben der eigentlichen technischen Integration macht es an diese Stelle auch Sinn, sich schon einmal zu überlegen, wie die Daten analysiert werden sollen, um sie entsprechend vorbereiten zu können. Als nächster Schritt steht die Analyse der Daten an. Hierbei werden entsprechend der Aufgabenstellung Informationen aus den Rohdaten gewonnen. Zum Schluss wird eine aus der Analyse abgeleitete Handlung durchgeführt, wie beispielsweise eine Aktie gekauft oder ein Buch empfohlen. Während eines Big-Data-Projekts bekommen alle Beteiligten sowohl aus der IT als auch aus der Fachabteilung ein besseres Verständnis für die Daten und die Auswertungsmöglichkeiten, weshalb es nicht verwunderlich ist, dass nach einem vollen Projektzyklus der nächste Zyklus ansteht, in dem man sich überlegt, wie man das Datenmodell weiter verbessern kann.

Eine wichtige Frage, die man sich direkt am Anfang des Big-Data-Projekts stellen sollte, ist, was überhaupt das Ziel des Projekts ist, das heißt, auf welche Fragestellung es eine Antwort liefern soll. Ist das Ziel erst einmal festgelegt, so ergeben sich die durchzuführenden Schritte und die Architektur des Big-Data-Projekts meist von selbst.

Neben den funktionalen Anforderungen an ein Big-Data​-Projekt ist auch erforderlich, die richtige technische Architektur zu entwickeln. Gerade bei sehr großen Datenmengen ist es wichtig, dass die gewählte technische Architektur auch die Anforderungen an die gewünschte Reaktionsgeschwindigkeit des Systems erfüllen kann. Damit diese Anforderungen erreicht werden können, muss das System technisch, d.h. von der Rechenleistung und Speicherkapazität her, entsprechend ausgelegt werden. Einige Analysen müssen gegebenenfalls in Echtzeit durchgeführt werden, wohingegen bei anderen eine gewisse Menge an historischen Daten vorgehalten werden muss. Wird das Big-Data-System als Basis für eine Echtzeitanalyse verwendet, muss man sich auch Gedanken über die Redundanz des Systems machen, um Ausfallzeiten durch Systemfehler möglichst zu vermeiden. Betrachtet man die Leistung eines Big-Data-Systems, sollte man sich die folgenden Fragen stellen, um abzuschätzen, wie es dimensioniert werden muss.

• Müssen vom System Echtzeitdaten oder Quasi-Echtzeitdaten verarbeitet werden?

• Welche Datenmenge soll vom System aktuell und in Zukunft verwaltet werden?

• Wie präzise müssen die verwalteten Daten sein?

• Wie risikoreich ist das Big-Data-Projekt, das heißt, kann es sich das Unternehmen leisten, wenn das System für eine bestimmte Zeit ausfällt?

• Welchen gesetzlichen Regularien unterliegen die verwalteten Daten?

• Wie vertraulich sind die verwalteten Daten?

Schauen wir uns vor dem Hintergrund dieser Fragen einmal die Architektur eines Big-Data-Systems in Abbildung 14.6 an.

Auf der linken und rechten Seite befinden sich die Datenströme, an die unser Big-Data-System angebunden ist. Diese Anbindung an den Rest der Welt ist extrem wichtig, da eine der herausragenden Eigenschaften eines Big-Data-Systems die Integration von Daten aus vielen unterschiedlichen Datenquellen ist. Eine der Grundvoraussetzungen ist, dass alle anzubindenden Datenquellen über eine offene Schnittstelle oder eine API (Application Programmers Interface) verfügen. Beachten Sie, dass neben den Schnittstellen, die zwischen dem Big-Data-System und der restlichen Welt existieren, auch die Schichten innerhalb des Big-Data-Systems durch offene Schnittstellen voneinander getrennt sind. Ohne Datenintegration kann es kein Big-Data-System geben.

Neben der Datenintegration stellt die physische Infrastruktur eine wichtige Grundlage des Big-Data-Systems dar. Ohne eine verlässliche physische Infrastruktur hätten Big-Data-Projekte heutzutage nicht den Stellenwert, den sie besitzen. Da man in einem Big-Data-Projekt eine nicht vorhersehbare oder gut abschätzbare Datenmenge verwaltet, ist es unerlässlich, dass die physische Infrastruktur robust und elastisch genug ist, diese Datenmenge zu verwalten. Elastisch bedeutet in diesem Zusammenhang, dass das Big-Data-System flexibel genug sein muss, zusätzliche Server einzubinden, wenn die Datenmenge dies erforderlich macht. Auf der anderen Seite muss es aber auch möglich sein, dass Server aus dem System wieder entfernt werden können, wenn die zu verarbeitende Datenmenge absinkt. Eine solche Elastizität wird durch die Verwendung einer hochparallelen virtuellen Umgebung erzielt, in der virtuelle Server je nach Bedarf erzeugt und wieder vernichtet werden können.

Um die Vorteile der parallelen Verarbeitung bei Big-Data-Projekten ausnutzen zu können, basiert Big Data auf dem Modell der verteilten Datenverarbeitung, das heißt, die Daten, die verarbeitet werden müssen, sind räumlich voneinander getrennt. Unter Umständen kann es sich hierbei nicht nur um eine räumliche Trennung innerhalb eines Rechenzentrums, sondern auch um eine geografische räumliche Trennung handeln. Die voneinander getrennten Daten werden durch das Netzwerk, die Verwendung von verteilten Dateisystemen und andere Big-Data-Analysetools und -Anwendungen miteinander verbunden.

Da man in Big-Data-Projekten mit einer großen Datenmenge aus unterschiedlichsten Datenquellen arbeitet, ist es notwendig, das System redundant auszulegen. Dabei kann die Redundanz auf vielen unterschiedlichen Ebenen realisiert werden. Die für die Redundanz benötigte Infrastruktur wird heutzutage in einem Cloud-Szenario realisiert. Dabei bedeutet Cloud​ an dieser Stelle eine stark virtualisierte Infrastruktur, bei der sowohl das Netzwerk als auch die Server virtualisiert werden, um eine möglichst große Unabhängigkeit der Systeme von der zugrunde liegenden Hardware zu realisieren. Die Cloud kann entweder unternehmensintern als private Cloud oder bei einem Hosting-Anbieter als öffentliche Cloud betrieben werden.

Je nachdem welche Daten verwaltet werden sollen, kommt das eine oder das andere oder eine Kombination der unterschiedlichen Cloud-Ansätze zum Einsatz. Der Aufbau einer privaten Cloud ist teuer, zeitlich aufwändig und erfordert Spezialisten-Know-how, hat aber den Vorteil, dass das Unternehmen selbst darüber bestimmen kann, wo die Daten räumlich gespeichert werden, was gerade im Zusammenhang mit dem deutschen Datenschutz sehr wichtig ist. Nutzt man die öffentliche Cloud, hat man keine Kontrolle darüber, wo die Daten gespeichert werden. Viele Hosting-Provider bieten im Zusammenhang mit Cloud-Szenarien Georedundanz an, das heißt, die Daten werden in unterschiedlichen, auf dem Globus verteilten Rechenzentren gespeichert. Außerdem weiß man nicht, welche anderen virtuellen Systeme auf derselben Hardware betrieben werden und welche Anforderungen diese an die Rechenleistung der Systeme haben.

Zwischen der privaten und der öffentlichen Cloud gibt es noch ein Szenario, bei dem eine private Cloud beim Hosting-Provider installiert wird. Hierdurch haben Unternehmen den Vorteil, dass sie die Infrastruktur nicht selbst betreiben müssen, auf der anderen Seite aber volle Kontrolle über den Ort der Daten und die Auslastung der physischen Maschinen haben.

Neben diesen drei Modellen sind auch hybride Cloud-Modelle im Einsatz, bei denen ein Teil der Daten in der privaten Cloud und ein Teil der Daten in der öffentlichen Cloud gespeichert werden.

Manchmal wird auch die komplette Big-Data-Anwendung virtualisiert. Dabei bezieht man als Anwender nur den Dienst und hat keine Ahnung, wie die dahinterliegende Infrastruktur aussieht. Sie können sich das so vorstellen, als wenn Sie Ihre E-Mail-Adresse bei einem Mailprovider haben. Sie greifen auf Ihre E-Mails über einen Browser zu und haben keine Ahnung, welche Server in welcher Konstellation dazu benötigt werden, Ihnen den E-Mail-Dienst zur Verfügung zu stellen. In diesem Fall spricht man auch von Software As a Service (SaaS). So können Unternehmen kurzfristig Analysemöglichkeiten für Big-Data-Anwendungen zur Verfügung gestellt werden. Über den SaaS-Ansatz kann man Geld sparen, schneller mit dem Projekt starten und ist nicht für die Infrastruktur verantwortlich, die für die Bereitstellung des Dienstes benötigt wird.

Je wichtiger eine Big-Data-Anwendung für ein Unternehmen wird, desto wichtiger wird es auch, diese Big-Data-Anwendung gegen unberechtigten Zugriff zu sichern. Verarbeitet man beispielsweise Kundendaten, ist es unabdingbar, dass man die gesetzlichen Bestimmungen zur Verarbeitung dieser Daten einhält und die Daten entsprechend schützt. Eine Security-Infrastruktur ist somit zentraler Bestandteil einer Big-Data-Strategie und sollte direkt beim Projektstart bedacht werden und nicht erst, nachdem das Projekt bereitgestellt wurde.

Bei der Zusammenstellung der Datenquellen für ein Big-Data-Projekt ist es erforderlich, alle operationalen Datenquellen, in denen sich Daten befinden, die für die Analyse benötigt werden, zu berücksichtigen, um ein vollständiges Bild des zu analysierenden Sachverhalts zu bekommen. Früher gab es operationale Daten hauptsächlich in strukturierten Datenquellen, die beispielsweise durch ein ERP- oder CRM-System gefüllt wurden. Heutzutage befinden sich aber immer mehr operationale Daten auch in unstrukturierten Datenquellen wie beispielsweise Word-Dokumenten oder Webseiten. Auch diese Datenquellen müssen bei der Big-Data-Strategie beachtet werden.

Neben den klassischen Datentypen findet man daher in Big-Data-Projekten neue Datentypen, wie beispielsweise Dokumente, geografische Daten, Graphen und Spaltendatentypen. Der Oberbegriff für Datenbanken, die diese Datentypen enthalten, ist NoSQL-Datenbanken​ (manchmal auch als Not-only-SQL-Datenbanken bezeichnet).

Alle operationalen Datenquellen, unabhängig davon, ob es sich um SQL- oder NoSQL-Datenbanken oder Content-Management-Systeme handelt, haben einige Gemeinsamkeiten:

• Die Daten in den Datenquellen werden konstant aktualisiert, da mit den Datenquellen gearbeitet wird. Bei den Aktualisierungen kann es sich um die Aktualisierung eines Datensatzes in einer Datenbank oder der Überarbeitung eines Word-Dokuments handeln.

• Die Datenquellen sind für die Aufzeichnung der täglichen Tätigkeiten im Unternehmen wichtig.

• Damit die Datenquellen einen umfassenden Überblick über die Vorgänge im Unternehmen geben können, müssen strukturierte mit unstrukturierten Daten in Beziehung gebracht werden.

• Die Datenquellen müssen so skalierbar sein, dass sie für mehrere Tausend Anwender eine konsistente Datenbasis darstellen können. Das können transaktionale E-Commerce-Systeme, CRM-Systeme oder Callcenter-Anwendungen sein.

Neben den operationalen Datenquellen eines Unternehmens kommen inzwischen aber immer mehr Daten von außerhalb oder von Maschinen innerhalb des Unternehmens. Zu den Daten von außerhalb zählen die, die in den diversen sozialen Medien entstehen. Wenn ein Unternehmen ein Produkt vermarktet, möchte es beispielsweise im Rahmen seiner Marketingstrategie einen Überblick darüber haben, wie das Produkt von Kunden bei Twitter oder Facebook aufgenommen wird.

Werden in einem Produktionsbetrieb Maschinen eingesetzt, ist es heutzutage üblich, dass darin zahlreiche Sensoren verbaut wurden, um alle möglichen Betriebsparameter der Maschine zu messen. Früher konnten die meisten Unternehmen die Datenmenge, die von diesen Sensoren geliefert wurde, weder speichern noch verarbeiten. Selbst wenn Unternehmen in der Vergangenheit in der Lage waren, die Daten zu speichern, hatten sie nicht die Werkzeuge, sie weiterzuverarbeiten.

Das hat sich heutzutage grundlegend geändert und es stehen Techniken zur Verfügung, mit denen man Datenmengen verarbeiten kann, die früher nur von Supercomputern bewältigt werden konnten. Durch die gesunkenen Preise im Hardwarebereich ist das Betreiben von verteilten Systemen gebräuchlich geworden. Eine Tatsache, die sicherlich die Entwicklung von Big Data vorangetrieben hat, ist, dass Unternehmen wie Yahoo!, Google oder Facebook Strategien entwickeln mussten, wie man mit den riesigen Datenmengen, die die Dienste dieser Unternehmen erzeugen, umgehen kann.

Vor diesem Hintergrund wurden neue Technologien entwickelt, mit denen man riesige Datenmengen nahezu in Echtzeit speichern, verarbeiten und analysieren kann. Besonders bekannt sind in diesem Zusammenhang die Technologien MapReduce, Hadoop und Big Table.

Map Reduce​ wurde von Google entwickelt, um Funktionen effizient auf eine sehr große Datenmenge in der Batchverarbeitung anzuwenden. Die »Map«-Komponente verteilt dabei die Aufgaben auf viele Systeme und verwaltet diese Verteilung so, dass die Last verteilt wird und fehlertolerant gearbeitet werden kann. Nachdem die Arbeit auf den einzelnen Knoten ausgeführt wurde, wird die »Reduce«-Komponente verwendet, die Ergebnisse der Einzelknoten zu aggregieren, um ein Ergebnis zurückzuliefern.

Big Table​ wurde ebenfalls von Google entwickelt und stellt ein verteiltes Speichersystem für große Mengen strukturierter Daten dar. Die Daten werden in Tabellen gespeichert, die aus Zeilen und Spalten bestehen. Im Gegensatz zu einer traditionellen relationalen Datenbank handelt es sich bei den Tabellen, die in Big Table gespeichert werden, um ein dünn besetztes, persistentes und verteiltes multidimensionales Speicherkonstrukt, das dazu gedacht ist, große Datenmengen auf viele Server zu verteilen.

Hadoop ​ist ein auf Apache basierendes Software-Framework, das Map Reduce und Big Table implementiert. Mit Hadoop kann man Map Reduce auf große Cluster verteilen, die aus Standardhardware bestehen. Es ist die technische Grundlage für die von Yahoo! bereitgestellten Dienstleistungen und wurde so entwickelt, dass die Datenverarbeitung auf viele Knoten verteilt werden kann, um Berechnungen zu beschleunigen und Wartezeiten zu verkürzen. Hadoop besteht aus zwei Hauptkomponenten. Zum einen aus einem hoch skalierbaren verteilten Dateisystem, in dem man mehrere Petabyte Daten speichern kann, und zum anderen aus einer stark skalierbaren Map Reduce Engine, die notwendige Berechnungen auf sehr viele Knoten verteilen kann.

Hier finden Sie Wiederholungsfragen, mit denen Sie die Gelegenheit haben, sich noch einmal Gedanken über den Stoff des Kapitels zu machen. Die Lösungen zu diesen Aufgaben finden Sie im Anhang A.14.