Neue Herausforderungen bei Big-Data-Projekten

Datenbanken, Dateien, Streams – Daten liegen in den unterschiedlichsten Formaten und auf den verschiedensten Plattformen vor. Der Software-Hersteller MapR ist angetreten, diese Silos aufzubrechen und die Datenhaltung zu vereinheitlichen. Wie das funktioniert und was Unternehmen davon haben, erklärt Ted Dunning, Chief Application Archi­tect bei MapR.

com! professional: Herr Dunning, MapR will mit seiner Converged Data Platform eine einheitliche Umgebung für das Datenmanagement bieten. Warum ist das so wichtig?

Ted Dunning: Das größte Problem für die Unternehmen ist nach wie vor, dass die Datenwelt in Paralleluniversen eingeteilt ist. In der einen Dimension haben wir die relationalen Datenbanksysteme, in der zweiten Dateien in Verzeichnissen und in der dritten Streaming-Ereignisse. Jedes Modell folgt eigenen Gesetzmäßigkeiten, benötigt unterschiedliche Kenntnisse zur Verwaltung und Analyse und hat seine Anforderungen an die Infrastruktur. Mit wachsenden Datenmengen wird die Verwaltung und Integration immer aufwendiger und komplexer.

Hinzu kommt, dass Big-Data-Systeme wie Apache Kafka oder Cassandra, die ja eigentlich für die Verarbeitung großer Datenmengen konzipiert sind, nur sehr bedingt skalieren. Das führt zum Aufbau vieler, wenn nicht sogar Hunderter Cluster – ein Albtraum für jeden Datenmanager.

Dunning: Das Entscheidende an Cloud-Computing ist, dass es die Erwartungshaltung der Anwender verändert hat. Rechenressourcen müssen heute einfach zu konsumieren sein. Dies lässt sich nur erreichen, wenn eine Datenplattform aus standardisierten, austauschbaren Komponenten besteht, die sich im eigenen Rechenzentrum genauso nutzen lassen wie bei Amazon, Microsoft oder Google.

com! professional: Ist das eine der Stärken von MapR?

Dunning: Ja, unsere Lösung läuft auf jedem Computer, in jedem Rechenzentrum und in jeder Cloud – oder einer beliebigen Kombination unterschiedlicher Ressourcen. Da wir MapR von vornherein als verteilte Infrastruktur konzipiert haben, ist die Plattformneutralität quasi eingebaut.

Dunning: Das bieten wir nicht – und können es auch nicht. Wir stellen ja nur die Datenplattform zur Verfügung. Ob und wie die darin verwalteten personenbezogenen Daten geschützt oder ausgewertet werden, hängt letztlich davon ab, wie die Applikation damit umgeht. Was wir allerdings bieten, ist „Security by Design“. Alle Daten werden innerhalb der Plattform durchgängig verschlüsselt, sowohl bei der Übertragung als auch bei der Speicherung.

Dunning: Ja. Sie können auf unserer Datenplattform jederzeit einzelne Bytes in einer Datei überschreiben, um beispielsweise die persönlichen Informationen eines Kunden zu entfernen. Für andere Systeme wie Hadoop oder S3 stellt das eine riesige Herausforderung dar. Einmal geschrieben, lassen sich Daten nicht verändern.

Dunning: In der Regel scheitern diese Vorhaben, weil sie nicht richtig aufgezogen wurden. Die meisten Unternehmen beginnen mit überzogenen Vorstellungen. Natürlich sollte ein gewisser Gewinn mit dem Big-Data-Projekt verbunden sein. Viel wichtiger ist aber, dass es eine sehr hohe Erfolgswahrscheinlichkeit hat. Das heißt, man sollte sich eine begrenzte, realistische Aufgabenstellung suchen, die auch wirklich in der vorgegebenen Zeit zu leisten ist.

War dieses erste Projekt erfolgreich, wird es spannend. Nun haben Sie die Daten und ein Cluster, das bereits abgeschrieben ist, und können viel experimentellere, riskantere Fragestellungen angehen.

Dunning: Solche Zahlen sind schwer zu interpretieren. Was ist ein Projekt? Zählt es als Projekt, wenn das Datenbankteam die nächste Version einer bestehenden Umgebung entwickelt? Dann ist die Zahl sicher richtig. Wenn es aber darum geht, völlig neue Infrastrukturen aufzubauen, sieht das meines Erachtens ganz anders aus.

Ich glaube nicht, dass jemand für ein solches innovatives Vorhaben heute noch ein relationales System kauft. Diese Studien berücksichtigen meist nur herkömmliche Einsatz­szenarien. In neuen Anwendungsfeldern wie dem Internet of Things oder dem vernetzten Fahren geht der Anteil relationaler Systeme gegen null.

Dunning: Man benötigt dafür die richtige Mischung aus Datenbanken, Dateisystemen und Streaming-basierten Verfahren. Manche Daten müssen lokal direkt verarbeitet werden. Ein Controller in einer Maschine oder der Fahrassistent in einem vernetzten Fahrzeug muss schnell reagieren. Die Informationen eines Fahrzeugs reichen nicht aus, es müssen die Daten vieler Einzelelemente zusammenkommen, um die notwendigen Erkenntnisse zu gewinnen.

Dunning: Nein, es ist ein kontinuierlicher Kreislauf. Die Aktionsdaten von heute sind die Trainingsdaten von morgen, die wiederum die Handlungen von übermorgen definieren.

Dunning: Das erste Problem liegt im Alter der Software. Ich vergleiche das gern mit Musik: Die meisten Stücke, die Sie heute hören, sind vor Jahren oder Jahrzehnten geschrieben worden. Die überwiegende Zahl der Programme ist ebenfalls nicht neu, sie sind das, was man Legacy nennt. Wie lassen sich Anwendungen, die in den 1980er-Jahren geschrieben wurden, dazu bringen, mit den neuesten Technologien zusammenzuarbeiten? Wir adressieren diese Herausforderungen, indem wir Standard-Schnittstellen für die Anbindung zur Verfügung stellen. Die zweite Herausforderung ist die Skalierung. Wir bieten dafür Streaming-Prozesse, die es ermöglichen, Hunderte von Rechenzentren oder Dutzende von Cloud-Umgebungen  zu koppeln.

Dunning: Indem wir eine einheitliche Datenplattform zur Verfügung stellen: Jedes Element hat einen Namen, dieselben Sicherheitsmerkmale, dieselben Benutzerrechte. Mehrere Anwender können sich dieselbe Infrastruktur und dieselben Daten teilen.

Dunning: Wir brauchen eine gewisse Variabilität in der Konsistenz, um skalieren zu können. Innerhalb eines Clusters bieten wir eine starke Konsistenz. Snapshots spiegeln den aktuellen Stand aller Dateien innerhalb des Clusters wider, egal ob sie zum Zeitpunkt des Snapshots geschlossen oder geöffnet sind.

Über mehrere Cluster hinweg schwächen wir die Konsistenz ab. Es gibt plattformspezifische Mechanismen, um Daten mit schwächerer Kon­sistenz über die Data Fa­bric zu verschieben. Über Cluster hinweg erhält man so Updates nahezu in Echtzeit.