Deshalb scheitern Big-Data-Projekte

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.