Big Data. Sonderdruck für. Kreativität aus rohen Daten. Eine technologische Revolution. Objektivierung des Bauchgefühls

Transkript

1 Heft 9 Titelbild: Jer Thorp Big Data Sonderdruck für Kreativität aus rohen Daten Eine technologische Revolution Objektivierung des Bauchgefühls bt

2 Big-Data-Tools Ideen und Konzepte im Umgang mit Big Data The Big Data Developer Big Data = MapReduce + NoSQL + Sharding. Wenn das Ihr mentales Bild ist und Sie eine gesunde Portion Sarkasmus vertragen können, lesen Sie weiter. In diesem Artikel werden Ihnen grundsätzliche Ideen und Konzepte im Umgang mit großen Daten vermittelt und die damit verbundenen Problemfelder aufgezeigt. Autor: Pavlo Baron Vorab sei gesagt: In diesem Artikel werden keine Toolvergleiche angestellt, weil sie nur zu Missverständnissen und Flammenkriegen führen. Sie können nach dem Durchlesen des Artikels hoffentlich selbst entscheiden, welches Tool bzw. welchen Ansatz Sie wann wählen sollten. Und mit ein bisschen Recherche finden Sie auch die entsprechenden Tools. Die technische Seite des Big- Data-Hypes ist auf der einen Seite voller Geheimnisse und Missinterpretationen und auf der anderen Seite der konkreteste und meist diskutierte Aspekt, was Big Data betrifft. Klar, man hat bereits Unmengen von mit dem Big-Data-Etikett gelabelten Tools zur Verfügung, weiß allerdings nicht so recht, was man damit tun soll. Die existierenden Tools müssen also überhaupt erst Probleme finden, die sie lösen sollen. Aber sie sind so cool, dass man sie unbedingt ausprobieren möchte. Weitere Informationen zum vorliegenden Artikel finden Sie auch unter [1]. 2 bt

3 highscalability.com Woher kommt diese Toolbegeisterung? Natürlich von den Artikeln auf Internetseiten wie highscalability.com und dergleichen. In regelmäßigen Abständen schmeißt dort ein weiterer Facebook-Übernahmekandidat mit mehr als zweifelhaftem Geschäftsmodell eine Liste von coolen Tools aufs elektronische Papier, die das Herz eines jeden Technikers im Nu höher schlagen lässt. Und in einem Nebensatz wird auch noch erwähnt, dass alles, was man eingesetzt hat, natürlich Open Source ist und per se ganz ohne Lizenzkosten daherkommt. Diese Aussage wird keinen aufmerksamen, kostengetriebenen Entscheider kalt lassen, und da haben wir den Salat. Die Kürze des jeweiligen Blog-Posts tut ihr Übriges: Es entsteht das Gefühl, dass alles so leicht ist, dass man es auch selber hinbekommen kann. Ab hier gibt es drei Wege in Abhängigkeit von der Unternehmensart: 1. Man setzt die besagten Tools sofort ein und ersetzt damit die gesamte bisherige Toollandschaft. Dieses Verhaltensmuster trifft auf mittellose Start-ups zu, deren Geschäftsmodell einzig und alleine im ständigen Wechsel der Tools besteht. Diese Firmen lehnen Java oder.net grundsätzlich ab, weil diese sie in diesem Tempo massiv einschränken würden. 2. Man erprobt die Tools in der zwanzigsten Inkarnation des Projekts unter dem Basiscodenamen Ach, lasst uns doch bewerten, ob wir diese drakonischen Oracleund Hardwarekosten loswerden, das bei jeder erneuten Wiederholung einzig und alleine dem Zweck dient, den Beweis zu erbringen, dass alles beim Alten bleiben muss. Die für das Projekt verwendeten Datenvolumina würden sich problemlos in einer unindizierten Textdatei wohlfühlen und stellen lediglich die schmerzfreie Spitze eines gigantischen, unantastbaren Eisbergs dar. Vor allem der über Jahre gewachsene Mittelstand neigt zu einem solchen Verhalten. 3. Man schaltet auf Sarkasmus um: Woher sollen wir denn große Daten haben? Wir sind ja nur eine der größten Europäischen Banken. Bei uns passt alles nach wie vor in die Oracle-Datenbanken. Dieses Verhalten gilt ab der Unternehmensgröße, bei der Oracle oder SAP persönlich anrufen und um Termine bitten, und in denen das Dreijahresbudget die meistverwendete Skalierungsstellschraube darstellt anstelle der vertikalen, horizontalen oder diagonalen Skalierung. Es dürfte offensichtlich sein, dass in allen drei Fällen nicht wirklich etwas Verwertbares, Produktives entsteht außer Selbstbeschäftigung natürlich. Aber man hat das Gefühl, mit der Zeit zu gehen oder zumindest nicht ganz die neuesten Entwicklungen zu verschlafen, ganz gleich, ob sie einen tatsächlich betreffen oder nicht. EDV, CS und das alles Ja, noch vor einigen Jahren sah die Welt der elektronischen Datenverarbeitung (für die Jüngeren unter Ihnen: EDV) ganz einfach aus: Speichere alle Arten von Daten in einem Hot-Standby-Oracle-Koloss, greife darauf mit ein paar fetten, über Jahre gewachsenen Enterprise- Java-Anwendungen zu und drehe diese Daten in dem mit jedem auch nur erdenklichen Datentopf per ODBC bt

4 verheirateten Cognos so lange herum, bis sie um Gnade winseln. Und plötzlich kommt so ein Facebook-Rotzbub um die Ecke und verdient Geld mit nichts. Und das macht er mit Tools, deren Namen und Anzahl jeden Konzernsoftwareportfoliomanager in den Wahnsinn und den vorgezogenen Ruhestand treiben würden. Auf die IT-Öffentlichkeit wirkt sich der Erfolg von Amazon, Google und Co. vor allem in Form von technologischen Trittbrettfahrern und massiven Verunsicherungen aus. Während die besagten Unternehmen sich die besten Computerwissenschaftler ins Haus holen und riesige Forschungsabteilungen unterhalten, um aus ihrer Technik das letzte Quäntchen Leistung herauszupressen, vereinfachen die besagten Trittbrettfahrer die Wissenschaft enorm und reduzieren sie auf belanglose Toollisten, die sie voller Stolz auch gleich auf highscalability.com veröffentlichen und damit die IT-Welt total verunsichern. Da ist eh schon ständig die Rede von diesem ganzen Big-Data-Zeug, von dem man nicht so recht weiß, mit welchem Besteck man es am besten essen soll, und dann gießen sie noch weiteres Öl ins Feuer der allgemeinen Verzweiflung und legen Zahlen und Tools an den Tag, von denen man nur träumen kann und die man im Übrigen auch selbst gerne hätte. Und in diesem Spannungsfeld entstehen gut und gerne saloppe Aussagen, die einen ambitionierten Techniker mit Neigung zur fundierten Wissenschaft bis zum Herzinfarkt erschaudern lassen. Es ist meine Pflicht, diese Aussagen etwas auseinander zu sortieren und mit einer entsprechenden Portion gesundem Menschenverstand (und natürlich Sarkasmus wie denn sonst?) zu relativieren. Wie normale Daten, bloss grösser Das menschliche Wesen neigt generell dazu, in messbaren Größen zu denken und Dinge größentechnisch zu vergleichen und zu sortieren. Bereits im frühesten Alter ist es ein beliebtes Lernspiel, zwei Gegenstände hinsichtlich ihrer Größe zu bewerten und eine Schwarz- oder Weißentscheidung zu treffen. Das geht auch ganz gut mit Schubladendenken einher. Was ich mir in den letzten Monaten alles anhören durfte, war ungefähr in der Klasse von Big Data hat nicht jeder, die meisten haben nur Medium Data oder Big Data sind halt eben wie normale Daten, bloß größer. Dabei geht es um Teraund Petabytes von Daten. Petabytes das hört sich so richtig männlich an. Das klingt dann schon nach viel, viel größer als mickrige, altbackene Gigabytes, oder? Wenn Sie unbedingt nach einer Vergleichsabgrenzung der großen Daten vom Rest streben, kann ich Ihnen das Leben mit folgender Definition ganz leicht machen: Petabytes von Daten, die auf unterschiedlichen Kontinenten stündlich neu aufschlagen und komplexe Relationen aufweisen, die sofort während ihres Eintreffens hinsichtlich jedweder Anomalien untersucht und in grafische Management-Dashboards inklusive Business- Forecast-Korrektur gegossen werden müssen das ist Big Data. Alles darunter ist Mickey-Mouse-Data. Es geht bei Big Data nicht um die Größe, obgleich dieser Marketingname etwas Größentechnisches impliziert. Es geht darum, dass Sie entweder bereits riesige, unverarbeitete und kaum strukturierte Datenmengen im Unternehmen und dessen unmittelbarer Umgebung haben und diese anzapfen müssen, oder Sie können diese Daten ansammeln und anreichern bzw. erheben jede Art von Daten, die in irgendeiner Beziehung zu Ihrem Geschäftsmodell steht. Für die elektronische Verarbeitung von diesen Datenarten mit den damit verbundenen, unkontrollierbaren Mengen gelten eigene Gesetze. Auch hier werde ich nicht selten mit der Aussage konfrontiert Ach, Daten sind Daten. Egal, wie groß das sind dieselben Prinzipien. Das stimmt so natürlich ganz und gar nicht. Betrachten wir doch zunächst einmal die Speicherung. Datenspeicherung = Datenbank Jede Art von Storage kann irgendwo als Datenbank bezeichnet werden. Daten können auf eine Diskette passen (für die Jüngeren unter Ihnen: so groß wie ein ipod, kann so viel speichern wie ein Sandkorn), oder sie liegen auf vielen Festplatten in einem großen Schrank. Das Problem eines jeden physischen Datenträgers, egal wie groß oder klein er ist, ist dessen limitierte Gesamtkapazität. Man kann die Hardwareschränke schon sehr weit ausbauen, aber irgendwo ist Schluss mit deren Skalierung. Und an dieser Stelle, wenn man mit großen Datenmengen zu rechnen hat, ist weite (vorgesehene) Skalierung erforderlich. Gezwungenermaßen baut man dabei auf die Verteilung, um eine theoretisch unbegrenzte Anzahl einzelner Maschinen zu einem großen, verteilten Speicher zu kombinieren. Dieser Weg ist unausweichlich, denn es gibt noch keine Datenbank namens Schwarzes Loch, die unproportional viele Daten bezogen auf ihre eigene Größe aufnehmen kann. SQL vs. NoSQL Man könnte natürlich versuchen, in eine etwas andere, emotionalere Richtung hin zu argumentieren: Das gilt nur für SQL es skaliert nämlich hinten und vorne nicht. Und ist altes, langweiliges Zeug. NoSQL dagegen skaliert wie die Hölle und ist cool. Das ist auch eine interessante, allerdings etwas unqualifizierte Betrachtung. Zunächst einmal hat die Abfragesprache SQL wenig mit der Skalierbarkeit zu tun, außer vielleicht hinsicht- 4 bt

5 lich der Lesbarkeit und der Anzahl der Codezeilen. Und NoSQL sollte man eher als Bewegung, nicht als konkrete Implementierung auffassen. Der NoSQL-Bewegung schließen sich sowohl Nutzer als auch Produkthersteller an, um bei der Datenpersistenz nicht nur auf die RDBMS und die damit verbundenen Unzulänglichkeiten einer Allzweckwaffe zu bauen, sondern auf die Alternativen, die auf die speziellen Use Cases bzw. Datenarten zugeschnitten sind und den Anspruch der Allseitigkeit größtenteils erst gar nicht erheben. Allerdings erhält auch bei den so genannten NoSQL- Stores das Thema Verteilung eine zentrale Bedeutung, die an dem Entwickler gar nicht vorbeigehen kann. Abhängig von dem gewählten Store existieren dazu Strategien und diverse Stellschrauben, die eine optimale Anpassung an die eigenen Use Cases erlauben. An dieser Stelle kommt das berühmte CAP-Theorem ins Spiel, das die Grundlage für die betagten Stellschrauben liefert. Man nehme 2 von 3? CAP [2] ist einfach: Man nehme zwei von drei. Das ist fast schon ein Vorurteil und eine derart gefährliche Vereinfachung eines komplexen Sachverhalts, dass ihr Schatten sämtliche Vorzüge eines NoSQL-Data-Store im Nu überdecken kann, sofern ein solcher Store überhaupt in Frage kommt. Bei den verteilten Systemen jedweder Art ist das einzige, wovon man sicher ausgehen kann, die Tatsache, dass Teile dieses Systems früher oder später ausfallen werden und Sie keine Ahnung haben werden, was da vor sich geht. Das heißt, dass das P aus dem CAP-Theorem eine unverzichtbare, von vornherein vorgesehene und implementierte Konstante ist. Das gegeben, schiebt man den Regler zwischen C und A, und das nicht nur schwarz oder weiß, also entweder C oder A, sondern mit diversen Grautönen dazwischen in Abhängigkeit von den eigenen Use Cases und pro Use Case ggf. unterschiedlich. Sharding versteckt die Komplexität der Verteilung Tja. Verteilung als solche ist eines der komplexesten Gebiete der Computerwissenschaft. Sie ist niemals transparent, egal, wie glänzend die Fassade sein mag. Alles, was man bisher getan oder gesehen hat, verblasst regelrecht im Vergleich zu der Verteilung. Es sei denn, man hat die Menge mit sieben Broten gefüttert und kann auf dem Wasser laufen. Kann man so etwas nicht, kann man sich leicht die Zähne daran ausbeißen. Und überhaupt: Das mit dem Sharding stimmt so nicht ganz, weil man sich damit ein paar harte und schwer lösbare Probleme ins Haus holt. Das erste typische Problem kommt dadurch zustande, dass die Daten nun auf unterschiedlichen Maschinen liegen und das Traversal durch Relationen diverse Hops beinhaltet. Sollte unterwegs einer der Hops plötzlich nicht verfügbar sein, ist das Traversal umsonst. Und ansonsten ist es bei diversen Hops auch nicht sonderlich performant. Das Problem haben sowohl die Graphendatenbanken als auch sonstige Data Stores. Denn selbst wenn die Daten nicht direkt relational abgelegt werden Relationen kommen auf logischer Ebene zustande und müssen in der Anwendungslogik simuliert/kompensiert werden. Ein anderes Problem mit dem Sharding ist das naive Hashing. Hashes werden in Abhängigkeit von der Anzahl der Knoten im System berechnet. Kommen neue Knoten hinzu oder verschwinden welche, müssen die Daten, sofern überhaupt noch verfügbar, im System fast komplett umgeschoben werden es kommt also zum teuren Rehashing. Das naive Hashing sollte unbedingt gemieden werden, was allerdings beim besten Willen keine triviale Angelegenheit ist. Die Kompromisse müssen also zwischen der Verfügbarkeit und der Datenkonsistenz, aber auch zwischen der Lese-, Schreib- und Suchgeschwindigkeit gemacht werden. Und diese Kompromisse sind wirklich, wirklich hart. MapReduce für die schnelle Suche Ein weiterer Aspekt, der am meisten unterschätzt wird, ist die aufgeweichte, also eventuelle Konsistenz. Man sollte unbedingt wissen, dass sie nur auf eine bestimmte Gruppe von Use Cases passt. Dort, wo gezwungenermaßen Transaktionen erforderlich sind, kann man auf die eventuelle Konsistenz nur dann bauen, wenn man seinen Job unbedingt schnell loswerden möchte. Bei einem Geldtransfer von einem Konto auf ein anderes kann man sich z. B. nicht einmal für eine Millisekunde Inkonsistenz zwischen den beiden erlauben. Denn man kann davon ausgehen, dass diese Millisekunden für Betrug ausgenutzt werden. Man kann diese Betrachtung natürlich gerne auf den Security Officer abwälzen und sich voll und ganz auf die Umsetzung konzentrieren, an der Tatsache selbst wird sich dadurch aber nichts ändern. Man kann natürlich durchaus gegenargumentieren, dass man gar kein Geld zum Transferieren, dafür aber Unmengen von Daten besitzt. Diese Daten könne man doch einfach auf NoSQL werfen, das wird schon seine Arbeit erledigen. Mal abgesehen davon, dass auch hier wieder NoSQL mit einer konkreten Implementierung verwechselt wird, ist es an und für sich etwas blauäugig, Daten, die wahrscheinlich essenziell für das Überleben des Unternehmens sind, irgendwo hinzuwerfen und zu hoffen, dass das Zielding schon irgendwie seinen Job machen wird. Bei diesem Werfen kann aber in einem verteilten System so einiges schiefgehen, und die Problemlösung wird dann in bt

6 einem gewissen Maße, in Abhängigkeit von dem gewählten Ansatz und Data Store, dem Entwickler überlassen. Und auch diese Problemlösung ist verdammt hart. Nehmen Sie doch einfach mal folgendes als Beispiel: Sie wollen auf einen Knoten schreiben, der ist aber nicht mehr ansprechbar. Sie wollen ersatzweise auf einen anderen schreiben, der hat aber konkurrierende Daten und kann nicht mehr mit dem Rest des Systems sprechen. Was tun? Das Problem wird häufig zum Client geschoben, möge doch der die resultierenden Konflikte auflösen. Wie tun Sie es, wenn Sie sich nicht sicher sein können, dass nicht noch irgendwo alternative Daten liegen, die Ihrer Konfliktlösung im Wege stehen? Das ist ja auch nur eines von vielen Beispielen, was schiefgehen könnte, und deren Menge ist nicht deterministisch. Wir sollten uns jetzt aber ein bisschen über die Bereitstellung großer Daten unterhalten. Es ist eine Sache, diese Daten zu sammeln, aber eine völlig andere, sie einem entsprechend großem Nutzerkreis zur Verfügung zu stellen. Datenbank als Flaschenhals Das mag dann der Fall sein, wenn man in dem Standard- Stack einer 08/15-Java-Enterprise-Anwendung denkt. Das beliebte Gegenmittel, fast schon das Gegengift dabei ist es, den eingehenden Traffic infrastrukturell soweit herunterzuschrauben bzw. zu verengen, dass die dahinterstehenden Server noch irgendwie mithalten können. Sofern einen aber Millionen gleichzeitiger Verbindungen und Anfragen plagen, die um Daten betteln, muss man leicht umdenken. Denn in diesem Fall kommt es erst gar nicht bis zu der Datenbank: Bereits die allererste Meile, also die Strecke vom User zum ersten Server inklusive, wird zum Flaschenhals mutieren. Man kann sich hier nicht wirklich erlauben, den Verkehr zu drosseln, denn man will ja diese Zugriffszahlen haben. Der Preis dafür sind Pakete und Verbindungen, die in Warteschlangen enden oder gar komplett abgelehnt werden, um Überlast zu vermeiden. Und alles nur, weil man die Daten nicht schnell genug in beide Richtungen durch die erste Meile bringt. Glauben Sie mir, das Falscheste, was Sie auf ein solches Problem werfen können, ist eine weitere Ladung Sexy-Hardware. Egal, wie teuer sie ist und wie glänzend die dazugehörigen Werbeprospekte inklusive der Kürze der korrespondierenden Hersteller-Nasdaq-Kürzel sein mögen. Aber unter derart hoher Last wird diese schöne Hardware anfangen zu krepieren. Festplatten werden brennen, Kabel qualmen, Boards und Karten schmelzen. Und das alles wird sich in biblischem Ausmaß zu Feuerbällen hochheizen. Es geht schlicht und ergreifend nicht darum, wie sexy die Hardware ist. Es geht einzig und alleine darum, wie schnell und wie transparent man sie für den unterbrechungsfreien Betrieb einsetzen kann. C10K-Server for the win! Um die erste Meile so aufnahmefähig, stabil, unterbrechungsfrei und performant wie möglich zu halten, ist, in Abhängigkeit von der Abstraktionsdicke und dem Overhead am Server, eine beachtliche Menge Netzwerkinfrastruktur erforderlich, die schnell sehr viel Geld kosten kann. Um dem Problem zu begegnen und diese Infrastruktur größentechnisch vertretbar zu halten, ist es erforderlich, aus den Servern der ersten Meile so viel wie möglich herauszuholen. Das bedeutet, man muss sie an das Limit heran utilisieren, um weitere Last über Scale- Out abzunehmen. An dieser Stelle kommen die so genannten C10K- Problem-lösenden Server [3] in den Sinn. Oder besser gesagt, Technologien, mit deren Hilfe man solche Server bauen kann. Der Witz dabei ist der, dass die Aufnahme der vielen, also mehr als parallelen Requests, nicht über weitere Threads oder OS-Prozesse auf der Maschine erfolgt, sondern auf einem einzigen Thread, aber ohne Overhead und nachrichtenorientiert, bei voller Kernel- Unterstützung. Denn man kann sich auf der Maschine fast blind darauf verlassen, dass auf einem herkömmlichen *nix-system der Kernel allemal schlauer ist und näher an der Maschine, als jeder Entwickler, der versucht, um diesen herum zu abstrahieren. Die wahren Herrscher des Internets Allerdings ist es im Falle der ersten Meile und weiter Verteilung großer Daten auch so eine Sache. Den Server haben wir nun vielleicht performant. Was ist aber mit der Strecke vom User zum Server? Was ist, wenn die User aus der ganzen Welt kommen? Allein schon die Physik und die räumliche Entfernung spielen hier eine große Rolle; diese Aspekte lassen sich beim besten Willen nicht wegdenken. Dinge brauchen einfach Zeit, um von A nach B zu kommen. Das gilt ebenso für das Sonnenlicht wie für elektrische oder Lichtsignale bzw. Wellen jeder Form. Die Latenz der Strecke zwischen dem User und dem Server entscheidet über den Wettbewerbsvorteil. Wenn ich mir Videos von tollen Autos im Web ansehe, neige ich eher dazu, mich für eines davon zu interessieren, wenn das Video ruckelfrei kommt. Ruckelt es dabei aber, bin ich schnell von der Seite weg. Und daran kann nicht einmal diese Monsterindustrie etwas ändern; das ist das Webverhalten von Menschen. Also, was tun? Die besagte Latenz lässt sich durch die Kürzung der physikalischen Strecke zwischen dem Nutzer und dem Content verringern. Das Internet wird nicht von Google regiert, sondern von Unternehmen wie Akamei, die an guten Tagen mehr als die Hälfte der gesamten Internetinfrastruktur fahren. Allgemein lässt sich meine Empfehlung auf die so genannten Content Delivery Networks 6 bt

7 (CDN) [4] beziehen: Sie müssten Ihren dynamischen Content irgendwie als Snapshots einfrieren können; also statisch vorberechnen und zu CDN herausschieben. CDN hat seine Infrastruktur direkt vor der Haustür Ihres Nutzers, also im nahegelegenen Backbone-RZ. Und für Ihre Nutzer ist das CDN fast schon transparent, es sei denn, sie kennen sich technisch mit DNS und generell mit Internetprotokollen aus, was die meisten leider nicht tun. CDN hilft einem also, die viele Last von den Servern beliebter Webpräsenzen fernzuhalten und nur im Falle des Content-Update oder der allerletzten Livedatenabfrage die Server zu befragen. Man nutzt damit die gesamte Infrastruktur (je nach Vertrag, versteht sich), die dem heutigen Internet zugrunde liegt. Alles in die Wolken! Sie können aber in diesem Zusammenhang natürlich auch an Cloud Computing denken. Es stehen einem doch unendliche Ressourcen zur Verfügung, endlose grenzenlose Skalierbarkeit und das bei voller Kostenkontrolle und ganz ohne eigene lästige Hardware. Das Herz eines CFO schlägt nicht bei sexy Hardware schneller, sondern bei einer weiteren Möglichkeit, CapEx in OpEx zu verwandeln. Leider hat der Umgang mit den großen Daten einige Implikationen auf Ihre Cloud-Strategie. Virtualisierung von Datenbanken und I/O generell ist halt so eine Sache. Und je nachdem, für welche Cloud-Angebotsvariante bzw. -Infrastruktur Sie sich entscheiden, kann es Ihnen schnell passieren, dass die eigentlichen Daten nicht direkt nahe an den virtuellen Rechnern liegen, die sie verarbeiten. Damit wird das Prinzip der Data Locality verletzt, bei dem die Strecke vom Prozessor zu den Daten möglichst kurz sein sollte. Und wenn die virtuellen Cloud-Systeme oder Datenfragmente umgezogen werden, steht zudem Ihre ganze Welt still. Computation Grids und Data Grids sind halt unterschiedliche Dinge, waren es immer und werden es wohl für immer bleiben, und daran ändert sich auch mit dem neuen Label Cloud Computing nicht wirklich viel. Man kann natürlich auch, je nach Cloud-Anbieter und eigener Portmoneedicke, die Nähe der Daten zu den virtuellen Maschinen bzw. kürzere Stop-the-World- Phasen erzwingen, indem man höhere Rechnungen bezahlt. Ob es sich lohnt, ist eine andere Frage. Cloud- Angebote im Zusammenhang mit großen Daten rentieren sich aus meiner Sicht dann, wenn man es nicht eilig hat, aber nicht, wenn man unter Zeitdruck steht und Wert auf extrem hohen Durchsatz bei der Datenauslieferung an den Nutzer legt. Die Cloud-Anbieter werden Ihnen aber wahrscheinlich auch etwas anderes erzählen. Doch wir haben ja noch gar nicht über die eigentliche Verarbeitung von Daten gesprochen. MapReduce = Verarbeitung grosser Daten Je nachdem, wie groß Ihr Vorwissen in Bezug auf Map- Reduce ist, werden Sie vielleicht wissen, dass die beiden Basisphasen der MapReduce-basierten Datenverarbeitung eben Map und Reduce heißen. Und vielleicht werden Sie auch wissen, dass die eigentlich aufwändigste, teuerste und langsamste dieser beiden Phasen Split heißt. Jedes komplexe MapReduce-Tool wird zu verarbeitende Daten in einer speziell aufbereiteten, gesplitteten Form in einer Art Dateisystem erwarten, um überhaupt loslegen zu können. Aber Ihre Daten werden mit der allerhöchsten Wahrscheinlichkeit zunächst woanders liegen. In einem RDBMS, einer Logdatei oder irgendwo in einem verteilten Data Store. Diese Daten sind ggf. riesig, und sie müssen nun von A nach B. Sehen Sie hier Potenzial für tierisch viel Aufwand beim Transfer? Lange Transferzeiten? Ich schon. Sie können natürlich ganz schlau sein und Ihre Daten bereits zum Zeitpunkt der Entstehung in das MapReduceeigene Dateisystem schreiben. So sparen Sie sich den aufwändigen Split. Ja, das ist eine gängige Praxis. Doch an dieser Stelle kommt ein weiteres potenzielles Problem: Was, wenn Sie während der Map-Phase die zu verarbeitenden Daten suchen müssen, also nicht alles per se verarbeiten wollen? Sie werden wahrscheinlich antworten: Dann indiziere ich halt die Daten mit einer Search Engine oder Bibliothek, dann können sie schnell gefunden werden. Natürlich, das ist die Voraussetzung. Doch es ist sehr schwer, den entstehenden Index so zu splitten, dass dessen Teile bei den dazugehörigen Daten liegen und somit von den gleichen Prozessoren angezapft werden, die auch die Daten lokal holen. Denn wenn man den Index auf einem Knoten befragen muss, um von einem anderen gefundene Daten zu holen, ist es zum einen langsam und zum anderen fehleranfällig, denn einer der beiden Knoten kann ja auch mal nicht da sein. Aber was ist eigentlich mit der Datenanalyse? Das ist doch genau das, worauf Big Data marketingtechnisch nicht zuletzt von den BI-Herstellern reduziert wird, um Geschäfte aufrechtzuerhalten. MapReduce überall Die Standardantwort auf jede gestellte und ungestellte Frage im Bereich großer Daten scheint zumindest aus der Marketingperspektive MapReduce zu sein. Man hat sogar das Gefühl, MapReduce sei die Lösung aller Probleme in der IT, oder ein supermoderner Kaffeeautomat, der die Brühe völlig ohne Reststoffe in höchster Qualität auspressen kann. MapReduce wird auf alles geworfen, was nicht schnell genug abstürzen kann, aber das ist falsch. Alleine das Prinzip setzt Verteilung voraus, und wo Verteilung bt

8 ist, da sind auch Netze. Und wo Netze sind, erhöht jeder Millimeter der Kabelstrecke die Unzuverlässigkeit und die Latenz des Ganzen. Wenn Sie vor dem Problem stehen, Daten fast in Echtzeit zu analysieren, währen sie auf Sie zufliegen, haben Sie keine Zeit, diese Daten zu speichern; geschweige denn auf mehrere Systeme zu verteilen, um sie danach zu analysieren. Wenn Sie ein System Abb.1: Aspekte von Big Data zur automatischen Überwachung von Patientengesundheit in einem Krankenhaus bauen, haben Sie es mit sehr vielen Events von Sensoren zu tun. Sie haben Nanosekunden Zeit, zu entscheiden, ob ein Patient kurz vor dem Herzstillstand steht. Da ist keine Zeit zum Speichern von Daten mit nachträglicher Analyse. Denn sonst müssen Sie, wie es aktuell der Fall ist, die Schwester nachts prophylaktisch alle 15 Minuten zur Überprüfung zum Patienten schicken und ihn durch den Schlafentzug an der schnellen Genesung hindern. Wenn Sie in Echtzeit eine Schlägerei auf einem öffentlichen Platz aus dem Videostream der Überwachungskameras erkennen und verhindern wollen, haben Sie keine Zeit, diese Daten zu speichern und nachträglich zu analysieren denn dass Sie den Schuldigen kennen und nachträglich fangen könnten, hilft dem eventuell erstochenen Opfer herzlich wenig. Glauben Sie nicht alles, was Ihnen Hersteller und Berater erzählen. Ob es Old-School-BI-Experten sind oder hippe MapReduce-Spezialisten der Moderne: MapReduce ist bei Echtzeitüberwachung das falsche Mittel. Und auch die beste Hardware der Welt wird das nicht ändern. Denn Sie können bei MapReduce weder die Verarbeitungszeit zuverlässig fixieren oder vorhersagen noch die Vollständigkeit der Daten in einem verteilten System garantieren, sofern Sie weder die Konsistenz aufweichen noch die Kausalität der einzelnen Ereignisse über mehrere Maschinen hinweg garantieren. Events können verloren gehen oder die speichernden Knoten sind mal wieder nicht verfügbar, wenn Sie MapReducen wollen. Die Verteilung hat Ihre Seele. Wenn Sie bessere Fast-Echtzeit-Vorhersagen treffen wollen, wissen wollen, wie die einzelnen Events in einem Verbund ein Gesamtmuster ergeben, wie das eine Event aufgrund eines anderen entstanden ist (Kausalität) dann ist Complex Event Processing, also CEP [5], der Mechanismus Ihrer Wahl. Sie analysieren damit Datenströme, während Daten hereinfliegen. Und da gibt es wirklich keinen Weg drum herum. Mathe/Statistik fürchten Wenn Sie glauben, dass Ihr MapReduce-Tool die Mathematik bzw. die Statistik vor Ihnen verstecken wird, liegen Sie völlig falsch. Das wird es nicht. Denn bei der Analyse großer Datenmengen greift man auf statistische Berechnungen zurück. Und zur Wahrscheinlichkeitstheorie: Es geht um Prognosen, keine genauen Kalkulationen. Da reicht die normale 1+1-Arithmetik nicht mehr aus. Es ist also erforderlich, sich auch in Richtung Datenwissenschaft zu orientieren. Es ist fraglich, ob es sich als eigenständiger Beruf lohnt, aber zumindest IT-seitig muss man vieles aus dem mathematischen Sektor wissen oder verstehen. Selbst dann, wenn man zur Berechnung auf vorgefertigte Plattformen, Sprachen und Bibliotheken zurückgreift: Was sie tun, muss man trotzdem verstehen. Es gibt keinen Grund, Mathe zu fürchten. Man braucht hier Mathe, genau so, wie jeder ein ipad braucht. Aber eines haben wir noch vergessen: Visualisierung. Alles im Bilde Wenn Sie jetzt sagen, davon haben Sie keine Ahnung, dann sind wir schon mal zwei. Alles, was Sie hier beachten sollten, ist, dass es nicht mehr ausreicht, bei riesigen Datenmengen über ein Excel-Sheet Charts zu generieren. Es gibt tolle neue Methoden, Tools und Kartenarten, die riesige Datenmengen verständlich auf ein Bild herunterdampfen können. Wenn Sie wissen wollen, wie das geht, ist Andy Kirk ihr Mann, bzw. die Seite [6]. Die Moral von der G'schicht? Also, ich bin der Schlaumeier, der Ihnen hier Ihr Big-Data- Glashäuschen ruiniert, richtig? Fast. Eigentlich will ich auf Folgendes hinaus: Denken Sie nicht, dass es ausreicht, halbgare Blog- Posts zu lesen und sich dann als Experte zu bezeichnen. Menschen, die diese Posts verfassen, sind größtenteils sehr gebildet und schlau, sie fangen aber nicht bei Adam und Eva an und reduzieren das Geschriebene einfach auf ein leckeres Minimum. Holen Sie sich ein paar Basis-CS-Bücher über Netzwerke, Betriebssysteme, Maschinen, Datenbanken, Statistik etc. Die Investition lohnt sich. Sie müssen Full Stack gehen. Full Stack bedeutet, dass nicht alle Probleme im Big-Data-Umfeld mit Java oder Java-basierten Allzweckwaffen lösbar sind. Sie dürfen sie auch nicht von der Maschine abstrahieren, sondern müssen Technologien und Ansätze wählen, die so nah 8 bt