We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Große Datenmengen bedeuten große Änderungen

00:00

Formal Metadata

Title
Große Datenmengen bedeuten große Änderungen
Subtitle
Wie Neue Daten die Welt verändern
Title of Series
Number of Parts
7
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Mit der Einführung der neuen Ansätze rund um Big Data entstehen zahlreiche Spannungen, die sich auf existierende Infrastrukturen und Prozesse auswirken. Zwar kann man einen Enterprise Data Hub (EDH) schrittweise in die IT-Landschaft implementieren, trotzdem sind die Auswirkungen auf die Datenverarbeitung fundamental: Die ganze isolierte, siloartige Architektur des existierenden Enterprise Data Warehouse (EDW) löst sich in ein vereintes, einzelnes, immer verfügbares System auf, welches neue Anforderungen an jede einzelne Phase der Verarbeitung stellt. Von der Aufnahme bis zum Bereitstellen und Erkunden sowie der Verarbeitung und letztlichen Ausgabe gibt es keinen Grund mehr, Daten zwischen System zu bewegen, sondern es benötigt nur eine zentrale Regelung für den Zugriff. In dieser Keynote wird der Einfluss auf sowohl die physikalische Architektur als auch die organisatorischen Rollen kritisch besprochen. War es soweit üblich, Entwicklungsprojekte in 6- bis 12-Monatsphasen abzuwickeln, wird mit dem EDH eine kontinuierliche Umsetzung ermöglicht. Wurde bis dato auf lange Zeit geplant und umgesetzt, wird das heute in extrem verkürzten Zyklen durchgeführt. Eine unternehmensweite Datenstrategie ersetzt die bisherige Informationsabgrenzung auf Abteilungsebene und eröffnet damit neue Gelegenheiten, welche eine sorgfältige Planung in Bezug auf Änderungen auf allen organisatorischen Ebenen benötigt. Wir schauen uns Rollen wie Geschäfts- und Abteilungsleitung, IT-Mitarbeiter, Entwickler und Endanwender an, um daran die Bedenken bei der Umstellung von EDW nach EDH zu beschreiben.
Interface (chemistry)Web browserBinary fileSegaSystems <München>Electronic data processingMoment (mathematics)Raw image formatDatabaseSoftware developerProcess (computing)ArmServer (computing)Attribute grammarUniformer RaumProfessional network serviceEstimatorCalculationInformationHausdorff spaceSummationNetwork-attached storageHaar measureDrop (liquid)WebsiteWINDOWS <Programm>Concurrency (computer science)LINUXWorkstation <Musikinstrument>Computing platformLaufzeitGraph coloringAlgorithmExplosionSmartphonePoint cloudHypercubeMoore's lawInternetdienstLecture/Conference
Windows Workflow FoundationMenu (computing)Greatest elementHydraulic jumpRoute of administrationDatabaseCodeBetriebsdatenDatabaseMathematical structureComputer scienceInternetIP addressData storage devicePhysical lawQuoteFactorizationScheme <Programmiersprache>EstimatorMach's principleEscape characterAxiom of choiceData streamSystem administratorMultitier architectureCache (computing)Mono-FrameworkSeries (mathematics)Greatest elementSystems <München>State of matterDirection (geometry)Well-formed formulaMoore's lawStaff (military)Hacker (term)Grand Unified TheorySATOPropositional formulaProcess (computing)Lecture/Conference
Data modelPell's equationModule (mathematics)SPARK <Programmiersprache>MomentumSQLComputing platformUniform resource nameDirection (geometry)Coma BerenicesPhysical quantityRoute of administrationDesktopSystems <München>CalculationRollbewegungData warehouseDecision theoryPlane (geometry)Software developerServer (computing)DatabaseEnterprise architectureScientific modellingGrand Unified TheoryDirection (geometry)Component-based software engineeringAbteilungComputing platformFunction (mathematics)Database transactionSpring (hydrology)REC <Programmiersprache>MicrosoftComputer fileHaar measureProcess (computing)InternetRaw image formatDistribution (mathematics)Absolute valueOpen sourceRing (mathematics)List of anatomical isthmiSystem administratorStandard deviationPRIMA <Programm>EmailAnbindung <Informatik>Chain ruleMachine learningDatabaseResource allocationApache <Programm>Run-time systemZugriffSpeciesPhysical systemWindows CEQueue (abstract data type)IterationPoint cloudOutline of industrial organizationBerechnungWeb pageLösung <Mathematik>WINDOWS <Programm>Interface (chemistry)Stack (abstract data type)FactorizationSPARK <Programmiersprache>Streaming mediaTwitterCurveOpen setLarge eddy simulationFacebookPrinciple of localityBackupVALSoftware testingCodeMach's principlePrime idealGoogleFirmwareSAM <Programm>AuthorizationStructural loadPhysikComputer musicSupremumNumberRelational databaseDomain nameSource codeInterface (computing)MikroarchitekturSimilarity (geometry)State of matterHausdorff spaceLibrary catalogLaserMatroidReal numberForced inductionMittelungsverfahrenOperateurSOLISSummierbarkeitMotion (physics)Point of saleMISSWritingWORKS SuiteFRAMEWORK <Programm>Boom (sailing)InternetdienstLecture/Conference
Transcript: German(auto-generated)
Schönen guten Morgen und erst mal vielen Dank für die Einladung und auch für die Einladung letztes Jahr. Wie gesagt, manchmal geht es halt nicht so, wie man plant, aber diesmal hat es geklappt, das freue ich mich auch drauf. Ganz kurz nur über mich. Ich bin irgendwie anscheinend binär veranlagt, ich mache alles irgendwie im Zweifach.
Ich habe zwei Kinder, zwei Hunde, zwei Katzen, eine Frau, die natürlich doppelt für mich zählt, ist klar. Und es ist das zweite Mal, dass ich krank eine Vorlesung oder Vortrag oder sonst irgendwas gebe. Ich kann mich erinnern, in 2010 war ich beim Kunden und habe dann, das war so eine, keine Ahnung, vor Ort und geschaltet in die ganze Welt.
Und ich war völlig, wie heute, ein bisschen erkältet und hatte mal, und deswegen hoffe ich, dass das jeder kennt hier im Raum, weil wir alle ungefähr gleich alt sind, ich will jetzt hier niemanden zu nahe treten, so einen Frank-Draben-Moment gehabt, nackte Kanone. Mikrofon war noch an, ich musste die Nase putzen und so weiter und das wurde dann weltweit übertragen.
Also ich hoffe, dass diesmal, dass ich es aushalte. Nasentropfen habe ich drinne. Entschuldigung, aber wie gesagt, wenn ich anfange zu husten, liegt das an meiner Erkältung. Ganz kurz nur, ja, wie gesagt, war ich fünf Jahre bei Cloudera, von 60 Leuten bis über 1.000, habe also miterlebt, wie das ganze Thema Gewachsenen ist. Ich war auf fast allen Hadoop World und Hadoop Summits, also Hadoop Summits die ersten und Hadoop World ab der ersten, Hadoop Summits ab der zweiten.
Habe also auch gesehen, wie das ganze auch als Markt gewachsen ist, war auch auf verschiedenen anderen Konferenzen, Berlin, Basur und wie sie alle heißen, also auch im lokalen Umfeld unterwegs und habe dort mir angeschaut,
wie Hadoop gewachsen ist oder auch Big Data Search und all die anderen Themen, die außenrum angebaut sind, gewachsen sind. Aber auch dabei immer wieder ähnliche Verhaltensmuster erkannt, über die ich heute auch sprechen möchte. Also ganz kurz, so als, ich möchte einen Bogen spannen, von wegen datengetrieben sein.
Deswegen sind wir auch hier alles, ich habe mir ja auch mal die ganzen Themen angeschaut von den Vorträgen, die Sie alle noch hören werden, heute und morgen, wirklich so eine gute Auswahl, super. Also viele interessante Themen drinnen, maschinelles Lernen, Suche, Datenverarbeitung, alles drinnen, also auch da eine riesen Auswahl.
Warum überhaupt, warum sind wir da heute, warum waren wir da nicht vor, keine Ahnung, 5 oder 10 Jahren? Dann auch mal kurz anschauen, wie es mit der aktuellen Technik aussah, wie es jetzt aussieht, bis hin zur Einführung Hadoop, warum überhaupt Hadoop und Hadoop ist hier eigentlich auch nur stellvertretend. Ich weiß, dass auch in diesen Vorträgen zum Beispiel auch alternative Stapel vorgestellt werden,
ist natürlich klar, wenn es Hadoop gibt, also wenn es eine Plattform gibt für große Daten, wird es auch irgendwann mal eine Konkurrenz geben für große Daten und das werden auch, wie gesagt, es ist relativ, obwohl ich über Hadoop spreche, ist der Ansatz der gleiche. Die Idee ist der gleiche und das Endergebnis auch das gleiche.
Also nur im Hinterkopf behalten, Hadoop ist hier mehr oder weniger ein Beispiel. Und das ist für mich der kritische Teil, wie beeinflusst das Ganze im Unternehmen oder auch weltweit, wie verändert das das Ganze den Menschen, die Technik und auch Prozesse. Das ist für mich dann der Höhepunkt und dann fasse ich normales zusammen.
Also, datengetrieben sein. Was hat sich geändert? Wir könnten eigentlich sagen gar nichts. Wir kennen das alle. Wer aus der EIT kommt, wir haben immer Daten gesammelt. Wir hatten schon immer Datenbanken, wo wir reingeschrieben haben. Also im Prinzip ist eigentlich nichts, was wir ändern müssten. Aber dennoch, irgendwo, jeder fühlt, jeder hört.
Irgendwie muss es was Neues geben oder irgendwas stimmt hier nicht. Irgendwas muss angepasst werden. Aber warum? Im Endeffekt haben wir Datenbanken schon immer gehabt und können dort Daten abspeichern. Also warum muss ich mich um diesen, ich sag mal, dieses Hype oder den Lärm, warum muss ich mich darum kümmern, dass ich jetzt irgendwas mit neuen Daten oder Big Data,
Big Data, wie wir auch wissen, ist eigentlich auch wieder völlig der falsche Begriff wie Cloud. Ist einfach so ein Wischwaschbegriff, der eigentlich gar nichts genau sagt, also dass es ein neues Thema ist. Cloud kann alles sein, Big Data kann alles sein. Also warum muss ich mich damit beschäftigen? Ich kann ja schon, wie gesagt, Daten speichern in Datenbanken, Card Reports anbieten, Dashboards, alles schon da gewesen.
Also warum überhaupt? Aber, und da kommen wir eben zu dem Thema, kann ich das heute mit den Techniken, die ich hatte oder habe, bis heute kann ich damit auch weiter wachsen und weiter Dienste anbieten innerhalb eines Unternehmens. Und da kommen wir in den Bereich, wo wir diese neuen Daten, schnelle Daten, die drei oder zehn Vs von Hadoop,
das ist egal wie viele, das kann man ausdehnen, fängt bei drei an, hört irgendwo bei, keine Ahnung, wo auf, mit Volume, Velocity, Variety, Varacity und wie sie alle heißen, Value, kann man hinten dran bauen. Also da gibt es die Frage, warum überhaupt das Ganze? Es geht nämlich um diese Kernfragen, bekomme ich aus meinen Daten alles raus,
was ich rausholen könnte? Also habe ich alle Daten, die ich benutzen könnte? Also auch alle Rohdaten zum Beispiel? Und habe ich auch die Möglichkeit, diese Daten in beliebiger Art und Weise zu verarbeiten? Geht das Ganze? Wie schnell geht das Ganze? Und wie flexibel bin ich dabei? Kann ich das jederzeit ändern? Kann ich das anpassen? Oder muss ich da lange Laufzeiten einplanen?
Also Daten ist sehr wichtig, wir hören nachher, Data is a new bacon, gibt es T-Shirts, Data is a new gold, wie auch immer, also das New Oil, da gibt es auch wieder 100 Varianten. Daten sind anscheinend sehr wichtig. Also Daten brauchen wir, aber eigentlich nur, wenn sie unsere Geschäftsvision verwirklichen.
Das heißt, wenn ich Daten habe, mit denen ich irgendwas machen kann, mit denen ich den Geschäftswert steigern kann, dann sind sie auch wichtig. Auch das macht Sinn. Auf der anderen Seite wissen wir aber auch, dass durch die IoT, wir leben in einer IoT-Welt, wir haben alle Smartphones,
jeder von diesen Smartphones sendet Signale nach Hause, ziemlich viele Signale, und das wird auf irgendwelchen Servern verarbeitet, welche wiederum selbst Signale erzeugen, die wiederum von anderen Servern aufgenommen werden, und so weiter und so fort. Also das kaskadiert sozusagen durch die ganze Welt der Chips und Silikone irgendwo, erzeugen wir automatisch durch einen kleinen Pingen hier irgendwo,
weil wir uns gerade alle zu einem einbefunden haben, eine massive Anzahl von Datenpunkten irgendwo in irgendeinem System. Also das Ganze passiert ständig und muss irgendwie auch verwaltet werden, verarbeitet werden, erfasst werden. Und wir leben in einer Welt, und das ist eben das, was interessant war. Wie gesagt, ich habe irgendwie auch noch mal ganz kurz so als Historie,
ich habe 1995 mein Studium abgeschlossen und habe also auch da das erste Mal, zum Beispiel, 1993 Linux 089 auf einem Windows-Dual-Boot-Rechner hochgefahren, habe mich das mal angeschaut, hatte dann irgendwie so ein Sunlab neben stehen gehabt, da hatten wir Microwecks, wo wir ein bisschen auf dem Thermal programmieren konnten,
und habe dann irgendwann mal, ich glaube 1994 an der Uni, ein Kobol-Programm von einem AEX-Mainframe auf einen, Entschuldigung, von einem Cyber-Mainframe auf einen AEX-Workstation portiert. Und da gab es dann sowas wie Goffer, Finger und auch Mosaik. Wer das noch erinnern kann, das war ganz, ganz begeisternd. Ich habe es aufgemacht, die erste Website angeschaut und gleich wieder zugemacht,
weil das war wirklich grottenhässlich und eigentlich gar nicht so richtig interessant, aber das waren so die ersten Merkmale, da passiert irgendwas, ich kann auf einmal Daten abrufen. Seitdem bin ich ständig dabei gewesen, also auch ganz begeistert dabei gewesen, wie man hoffentlich merkt, und das heißt, diese Information, die wir haben,
die Instrumentation, die wir haben und auch die Netzwerke, die wir aufgebaut haben seitdem, erzeugen so viel Daten, dass wir sie irgendwo absprechen können. Was können wir heute, weil wir heute so viele Chips haben und so viele Rechenleistungen haben, dass wir erzeugen und speichern können. Also Moore's Law ist hier voll im Einsatz und da können wir auch wieder kritisch ansetzen. Bleibt das so oder bleibt das nicht so?
Der Wachstum im Augenblick ist phänomenal, aber ist nicht irgendwann mal damit Schluss. Das ist auch eine kritische Frage, die wir uns stellen könnten. Auf der anderen Seite wollen wir mit den Daten auch was anfangen. Wir wollen also besser werden, die Daten auszunutzen, Kunden besser zur Verfügung zu stehen, Angestellten besser zu helfen,
Mitarbeitern, Angestellten die Daten oder die Informationen zukommen zu lassen, die sie brauchen, um ihre Arbeit besser zu machen, aber auch persönlich besser voranzukommen im Leben. Also auch zum Beispiel was Gesundheit angeht. Dass wir ihnen helfen können, Sachen zu erreichen, die sie so vorher gar nicht gesehen haben, dass wir auch Wert sehen bei uns zu arbeiten und deswegen auch länger und bessere Leistung abgeben.
Das ist einfach so. Auf der anderen Seite, und das ist das letzte Teil, das hören wir hier sehr stark in dieser Video-Konferenz, ist das Experimentieren. Wie können wir experimentieren in einer Art und Weise, dass wir die neuen Daten irgendwie neu verarbeiten können?
Und es sind mindestens zwei oder drei oder vier Vorträge, die habe ich gesehen, über iPython, Zeppelin, Notebooks. Das ist so eine der Ansätze, dass man sagt, anstatt dass ich irgendeinem Python an die Hand gebe und der macht dann irgendein Python-Programm und versucht dann irgendein Algorithmus zu finden, der auf Daten arbeitet, habe ich eine interaktive Frontfläche,
wo ich dann im Browser halt eben experimentieren kann, kann diese Notebooks abspeichern, weitergeben, kann sie auf der Welt verteilen, andere können sie weiterverarbeiten. Und im Endeffekt können wir damit das Wissen, das geballte Wissen, das wir weltweit verteilt haben, wir sind mal eine kleine Welt heutzutage eben durch das Internet, können wir dann neue Einsichten, neue Erkenntnisse aus diesen Daten herausholen,
die uns allen weiterhelfen. Also alles das passiert, während wir hier stehen und reden. Also experimentieren ist ein ganz wichtiger Faktor. Aber Schritt zurück, tolle Welt. Wie war es denn bis heute? Wir haben ja auch Daten gespeichert. Wir haben das Enterprise Data Warehouse gehabt, wo wir über Jahrzehnte schon,
seit den 70ern haben wir Unternehmensdaten in Datenbanken gespeichert. Das war am Anfang eine Datenbank, alles rein damit, fertig. Wir konnten also abspeichern, was diese Firma an Daten vorhalten musste. Aber mit der Zeit wurde diese Datenbank etwas, sagen wir mal, unpraktisch, weil alles dort zum Beispiel relational abgelegt war.
Wir haben ja InMorn und Kimbell mit den, Entschuldigung, wir haben, das habe ich vergessen, wir haben die Datenbanken relational abgelegt nach Cod. Und in der Beschreibung, also wir haben eine Datenbank, die absahiert war, wir haben SQL gehabt, wir konnten damit irgendwelche Regeln ausdrücken, wir konnten Daten beschreiben, Schemen ausdrücken, ablegen
und mussten uns wirklich nicht darum kümmern, was unter der Haube passiert. Das ist okay für eine bestimmte Anzahl von Anwendungen. Und auf einmal fängt man an, sagt, ich möchte nicht nur einfach transaktional arbeiten, sondern ich möchte auch andere Sachen mit den Daten machen, ich möchte sie analysieren. Und da kam eben dann dieser Schritt Richtung, okay, wir können das nicht einfach alles
einfach relational ablegen und dementsprechend alles auseinanderreißen, dass wir möglichst wenig Speicherplatz brauchen, weil wir alles normalisiert haben, indem wir eine Adresse haben, die fünf Kunden zugeordnet ist zum Beispiel, wenn sie im gleichen Haus wohnen oder so. Sondern wir brauchen die Daten auch in einem anderen Format,
dass wir halt Analysen drüber fahren können. Und das eben, wie gesagt, brauchte da eine Umstrukturierung der Daten, andere Schemas, andere Anwendungen, um dann eben die Daten so vorliegen zu haben, dass wir sie analysieren können. Also wir haben angefangen zu sagen, wegen dieser Aufgabe, weil wir Daten analysieren wollen, müssen wir sie umstrukturieren.
Und haben das eben auch gemacht. Das war, wie gesagt, das data warehouse und wollte wirklich diese zwei Fälle transaktional irgendwas, mit einem transaktionalen OLTP vorne Datenbank, ganz normaler Datenbank, geht in eine andere Datenbank, die nennt es ja irgendwie ODS, Operation Data Store. Deshalb liegt das schon anders. Strukturiert Stern, weiß ich was, wie gesagt, Inmon und Kimball waren so die beiden Vorreiter,
die verschiedene Bottom-Up, Top-Down Schemas entwickelt haben, wie man die Daten strukturieren kann. Aber hinter dem Ganzen liegt doch wirklich einfach nur eine Datenbank. Im Prinzip liegt eine Datenbank dahinter, Schemas, verschiedene Schemas, für verschiedene Anwendungsfälle, Prozesse, wie wir die Daten von A nach B bekommen, von Schema A nach Schema B nach Schema C, bis hin zu einer Architektur,
wie wir das Ganze kombinieren, um dann möglichst viel zu wachsen. Also wir haben da mehr reingespeichert, weil wir jetzt mehr erfassen können. Also in letzter Zeit, die Datenbanken waren super easy, alles war super, auch im Verkauf bei den Datenbanken, lief ganz toll. Und dann kam halt nur das Law und wir können auf einmal so viel Daten generieren,
dass diese Datenbanken, diese Strukturen, die wir haben, nicht mehr mit dem ganzen Wildwuchs an Daten zurechtkommen. Wir müssten sie ja erst mal reinladen, dann müsste man ETL machen, erst mal bereinigen, vom ETL erst mal dann irgendwo in den Zwischen, in so einem Staging Area und so weiter und so fort. Und das braucht Zeit und dauert zu lange. Das heißt, heutzutage mit dem bestehenden Strukturen etwas zu machen geht.
Ich höre immer wieder irgendwo, glaube ich, rein und der sagt immer, was haben wir schon immer gemacht, das geht auch heute noch damit. Klar, geht, mach, kein Problem, das ist nicht das Problem. Aber es wird schmerzhaft. Oder wie man jetzt aber so schön sagt, mach es doch so, dann ist es halt kacke. Also das kann man auch sagen.
Also ich will jetzt... Kommt noch einmal wieder, was der Kunde bezahlt, dann sage ich halt eben nicht. Dann sage ich halt, was anderes. Aber das Prinzip ist das gleiche. Also irgendwo, man kann es natürlich, man kann alles irgendwo reinzwängen in IT. Darum wollen wir gar nicht diskutieren. Wir wollen den möglichst einfachen Weg wählen, pragmatisch sein. Pragmatisch sein heißt, wir müssen irgendwo sehen,
was wir überhaupt abbilden können. Und das ist so eine Zusammenfassung. Wenn wir diesen normalen Aufbau haben, oben haben wir den Datenzugriff, unten haben wir die Datenquellen. Also wir haben irgendwo dazwischen die Datenbanken, die Daten speichern. Und irgendwo haben wir das Problem, wir haben begrenzte Erkenntnisse. Wir haben nicht genügend Sicht auf die Daten, weil wir teilweise Daten
innerhalb von diesem Pfad, wo es eintrifft über da, wo wir es verarbeiten, schmeißen wir Daten weg, weil sie ja gar nicht mehr wichtig sind. Wir sagen einfach, hier ist eine Datenquelle, da sind 100 Felder drin. Für diese Aufgabe brauche ich nur zehn. Zehn kommen weiter. Und dann aus den zehn fassen noch drei zusammen.
Und dann auf einmal habe ich dann 13, wo dann drei irgendwie berechnet sind aus irgendwas anderem. Ich brauche dann so eine Art Historie, wo kommen die Daten eigentlich her. Aber die Qualität der Daten nimmt irgendwie ab. Ich glaube, ich mache was Gutes, indem ich aggregiere und dann eben dann schon mal vorbereite für die Lösung. Aber im Endeffekt verliere ich an Feinheit.
Ich kann also nachher hinten nicht mehr irgendwas anderes machen, weil ich habe schon aggregiert. Ich kann nicht mehr jetzt auf die einzelnen Daten zugreifen. Auch das Problem mit Konformität und Sicherheit oder Schutz der Daten. Ich will natürlich auch so, dass ich es auch so hinbekommen, dass ich, wenn ich die Daten speichere, irgendwo eine Balance erstelle zwischen Sicherheit, wie ich die Daten, ich kann nicht einfach Privatdaten,
Kreditkartendaten oder persönliche Daten einfach irgendwo weiter erreichen. Ich muss also auch aufpassen, dass das irgendwo gesichert ist, das Ganze. Und dementsprechend muss ich rausstreichen. Also bei dem Transformieren streiche ich oft raus aus Sicherheitsgründen, um einfach die Daten zu bereinigen. Und am Ende kommt wie gesagt hinten auch nicht mehr viel raus.
Das heißt, ich muss also sehen, was ich damit mache. Also das, wie gesagt, ist so der, was bis heute das Dato das Problem war. Und das heißt, Daten zu kopieren auf der anderen Seite kostet viel Geld. Das heißt, ich habe mehrere Systeme, ich muss sie bewegen. Ich brauche Leute, die das aufbauen, das Ganze automatisieren, überwachen.
Das kostet alles irgendwo Geld. Bereitet auch Probleme. Dann natürlich sowas wie dieser typische, das ist auch ein interessanter Quote da, typische Sprichwörter in der IT. Es gibt zwei schwierige Sachen. Cash-Invalidierung und Namenssendung und Off-By-One-Fehler.
Wie gesagt, das sind so diese typischen Sachen, die man dann kennt. Ich habe jetzt hier Daten, die reingekommen sind. Ich transformiere sie, transformiere sie, fasse sie zusammen und hinten kommt irgendwas raus. Und auf einmal verändere ich vorne eine Eingabequelle. Jetzt muss ich das ganze Data Pipeline, muss ich komplett durchspielen, um das auszuprobieren. Das braucht Zeit und muss in einem Projekt umgesetzt werden.
Also das verminder die Qualität und den Wert pro byte. Also kann man es irgendwie messen. Gibt es keine Regeln für, ich habe auch noch keine wissenschaftliche Ausarbeitung gesehen, die sagt, was ist ein byte wert. Man kann zwar sagen, was kostet ein byte nach Storage-Kosten und so weiter. Das Ganze wird natürlich dramatisch gefallen.
Logaritmisch, also so, also, nein, Quatsch, doch exponential gefallen sozusagen. Also, wie könnte man das machen? Auf einer logaritmischen Scale können wir das sozusagen ausdrücken, dass im Prinzip das fast linear ist, der Verfall.
Darüber hinaus müssen wir jedes einzelne System anpacken. Das heißt, wir wollen irgendwas ändern, immer wieder. Also, wie gesagt, ich bin, Gott sei Dank, ich bin nicht in einer großen Firma groß geworden oder gewachsen, jetzt nicht, oder alt geworden, sagen wir es mal so, alt geworden. Sondern ich bin viele kleine Firmen, also Start-ups und ja, so neue Technologien. Wie gesagt, bin in den Herdu auch reingerutscht und auch hängen geblieben deswegen,
weil ich ja die Chance dazu hatte, weil die Firma flexibel genug war zu der Zeit. Aber große Firmen, ich betreue große Firmen und wenn ich dann reingehe und sage, okay, jetzt stellen wir mal schnell einen Workflow um, dann können wir auf einmal erst mal zehn Formulare ausgefüllt an alle, an die Kollegen in der Firma. Der eine macht Kontroll-M, der andere macht den Datenbank-Administrator,
der nächste macht irgendwo, keine Ahnung, Informatiker. Und wenn man die erst mal alle zusammen hat, bis erst mal ein neuer Workflow erstellt ist, oder es umgestellt worden ist, vergeht ewige Zeit. Also auch das ist ein echtes Problem. Also Verteilung von Data Pipelines dauert zu lange. Wir können also nicht reagieren.
Man bekommt ja Angst heutzutage. Es ist ja wie gesagt nicht nur, dass wir im Internet heute wissen, was wirklich heute passiert. Nicht wie früher, vor Jahren haben wir ja von Tage später erfahren, dass irgendwo in der Welt irgendwas passiert ist. Heute erfahren wir das ja sofort. Wir haben ja alle Reddit und wir haben alle Hacker-News und so weiter. Wir wissen also, was passiert. Wir sind am Puls der Zeit.
Und so ist natürlich auch Management. Die sind auch am Puls der Zeit. Management weiß, was passiert und Big Data ist wichtig. Und Big Data kann uns die Welt retten oder kann Menschen heilen, Millionen sparen. Und das ist wie gesagt so die Message, die ja rüberfließt im Internet. Das kommt so rüber und das kommt auch irgendwo an. Und irgendwann mal nach einer Zeit sinkt das auch rein.
Und dann irgendwann wird gesagt, okay, machen wir jetzt. Wir machen heute Big Data und los. Und dann komme ich gleich zu, was da passiert. Das Ganze wird als Entwicklungsprojekt gehandhabt. Also es ist Aufgabe, also wird normal als Projekt gehandhabt, wie jedes andere Projekt auch,
anstatt irgendwie als Aufgabe der Wertschöpfung oder der Geschäftswertsteigerung. Also irgendwo sollte es anders gehandhabt werden. Und jetzt kommt Hadoop. Jetzt sind wir natürlich alles super. Jetzt wie gesagt Hadoop oder Smack oder wie auch immer so heißen Big Data. Ich schmeiße das alles in einen Pott. Hier ein Beispiel von Cloudera. Ich war bei Cloudera, die Infografik, die ich schon hatte.
Von daher ist stellvertretend das Gleiche. Das ist jetzt wirklich nicht irgendwie ausgerichtet auf irgendeine Distribution. Es geht einfach mit darum zu sagen, Hadoop ist eine neue Art von Plattform. Wir haben eine Plattform, die alles herrscht, so wie Herr der Ringe. Der eine Ring, der alles sozusagen zusammenfasst, ist Hadoop.
Hadoop kann alles. Das kommt auch wieder so als Nachricht über das Internet. E-Mails im Inbox auf. Hadoop rettet die Welt. Super, dann machen wir das auch. Okay, gut, alles klar. Aber es ist nun mal unbegrenzte Datenvorhaltungen Hadoop.
Vereinter, mehrfacher Framework-Zugriff. Also wir haben mehrere Schnittstellen, wo wir auf die Daten zugreifen können. Und es ist quelloffen und es sind offene Standards. Auch das stimmt. Das ist so ähnlich wie früher mal bei Apache als Webserver, der auch über das Apache-Projekt losgetreten hat.
Haben wir jetzt ein quelloffenes Programm, was den großen Herstellern Probleme bereitet oder Kopfschmerzen bereitet. Weil da ist jetzt was, was auf einmal was kann, was mein Enterprise Data Warehouse, was ich seit Jahren verkauft habe, nicht mehr hinbekommt oder vielleicht nicht mehr hinbekommt. Aber Leute wandern auf einmal ab. Das hat auch Microsoft zum Beispiel gespürt
und hat dann gesagt, okay, wir machen auch irgendwas. Die haben Dryad entwickelt, haben also gedacht, wir haben auch was für einen Big-Data-Bereich. Und haben es wieder eingestellt, weil Hadoop schon so eine Fahrt aufgenommen hat, dass alles auf diesen Zug aufgesprungen ist. Also auch Microsoft zum Beispiel hat heute Open-Source-Entwickler, die in Jira am Jira arbeiten, Open-Source-Tickets sich abholen und dann arbeiten.
Open-Source-Committen. Also ist alles, wie gesagt, ich würde jetzt nicht sagen, wenn da irgendjemand schon ins Jenseits übergetreten ist, würde er sich im Grab umdrehen. Aber wie gesagt, ich glaube, da sind einige graue Haare entweder ausgefallen oder sind entstanden in Redmond, als dass dieser Schritt vollzogen worden ist,
dass man als Microsoft bei Open-Source wirklich mitarbeiten muss. Wir wissen, dass Microsoft schon seit Jahren auch Open-Source-Anstrengungen hatte. Es gab also von Bill Gates diese große Ankündigung, wir machen Open-Source. Aber ich möchte mal wirklich wissen, was dahinten wirklich rausgekommen ist. Also ich habe nichts gesehen. Ich gucke mir auch wirklich meistens natürlich auch nur den Apache-Bereich an.
Also nichts gegen Microsoft oder so. Aber es hat mir, meine Welt hat es nicht berührt. Also vielleicht haben Sie irgendwas von Ihren Sachen veröffentlicht, aber es hat mich nicht berührt. Also wichtig Quelloffen. Wie passt das Ganze jetzt rein? Also wir haben jetzt dieses Big-Data-System, Hadoop als Beispiel. Quelloffener alles muss es sein. Jeder kann es nutzen.
Relativ einfach einzusteigen. Das heißt, wo passt das Ganze hin? Und es passt wirklich neben die bestehenden Systeme. Und das war auch eine tolle Sache, dass wir sagen können, wir bringen Hadoop in eine Firma und müssen nichts abreißen. Wir müssen keine Brücken abbrennen, wir müssen nichts abbrechen, sondern wir können einfach Hadoop mit aufnehmen in diese neue Welt.
Und damit haben wir alles, was wir brauchen, um den einzelnen IT-Mitarbeiter, den Entwickler und so weiter abzuholen. Also sozusagen kannst du langsam deine Anwendungen von dem Enterprise Data Warehouse, was kriegt es vielleicht schon und ächzt es unter der Belastung. Du hast noch einen Jury Scales, der da drauf soll. Wer ist denn, wenn wir den jetzt umstellen auf das Hadoop, den Hadoop?
Dann kann man die Daten reinladen, beliebig viele, kann sie offen machen und zur Verfügung stellen. Und dann kann man loslegen mit einem Notebook obendrauf, Daten zu erkennen, zu verarbeiten und Mehrwert zu leisten, Mehrwert zu erreichen. Das ist eine ganz tolle Sache.
Damit können wir, wie gesagt, die Wertschöpfungskette verbessern, können sich Steigerungen darstellen. Wir können vor allen Dingen konform arbeiten, weil wir alle Daten in einer Plattform haben. Hier wird nichts mehr bewegt, sondern wir haben eine Plattform, die alle Daten vorhält. Das heißt, wenn wir Regeln vergeben, greifen diese Regeln auf alle Daten drauf zu.
Auch das ist eine tolle Sache. Und wie gesagt, unbegrenzt, das hatte ich schon erwähnt. Also eine Plattform für viele Workloads, für alle Workloads. Wie gesagt, Lord of the Rings ist so die Idee. Damit kann man alles hinbekommen. Aber wie gesagt, da kommen wir gleich darauf zurück. Das heißt, anstatt dass wir diese monolithischen Datenbanken haben,
die SILUS, also SILUS heißt hier wirklich einfach nur, Daten sind begrenzt auf ein physikalisches System. Wenn ich das von dieser Datenbank A auf die Datenbank B, auch wenn es die gleiche unterhalb liegende Datenbank ist, das macht jetzt keinen Unterschied, sondern wir haben eine Datenbank, die ein bestimmtes Schema hat. Wir verschieben die Daten von hier, transformieren sie nach B.
Dann haben wir eine andere Ansicht. Aber auch da ist wieder starre Ansichten angesagt. Und wir können nicht weiter irgendwas damit machen. Wir können nicht von vorne anfangen, ohne die ganze Verarbeitungskette neu aufzubauen und die Daten neu zu verarbeiten. Von diesem Aufbau steigen wir um auf eine Plattform, die alles in Rohformat vorhält.
Und dann erst Schema on Read, Daten erst transformiert, wenn wir den Job starten. Das heißt, Rotdaten rein, Job starten, die Daten werden verarbeitet, werden transformiert, on the fly. Was wir jetzt können, weil wir so viel Silikon haben, so viel CPU, dass wir damit verarbeiten können. Auch da sieht man, die Kollegen von den Storage Firmen,
haben da auch ihre Probleme. Weil die Storage Firmen sind so der typische Dinosaurier. Das ist also ein Riesenkörper und ein ganz kleines Gehirn. Weil der große Körper ist, das sind die ganzen Platten, die dahinter hängen. Und dann wird ein Windows CE oder sonst irgendwas läuft dann dahinter. Meistens ist das ein Windows OS mit irgendwelchen Aufbauten.
Ist dann der Controller, der die Daten über Netzwerk empfängt und dort ablegt in diesen Platten. Damit können wir keine Berechnungen machen. Damit können wir auch keine großen Berechnungen machen. Denn wenn wir verteilt berechnen wollen, können wir nicht durch dieses kleine Gehirn große Daten durchschicken. Das heißt, hier besteht ein neues System, wo wir sagen,
wir haben viele, viele Rechner. Jeder hat sein kleines Gehirn überall verteilt, aber jeder hat auch seine Datenlokale, die er verarbeiten kann. Und damit können wir mit Hadoop auf einmal große Datenlenken verarbeiten. Obwohl wir ganz normale günstige Rechner uns kaufen. Keine, wie gesagt, große Körper mehr versteckt hinter einer großen Haut oder so. Ist halt irgendein Rack mit einem Namen neben drauf oder so.
Und können Sachen machen, die wir vorher nicht machen konnten. Gut, ist alles schön und gut. Also haben wir eine Plattform. Und wenn wir uns jetzt das vorstellen. Genau das habe ich schon gesagt. Skalierung, wie gesagt, auf Grund ist von Grund auf mit eingebaut. Hadoop ist nicht nur diese viele, viele Rechner mit vielen Platten und vielen CPUs,
sondern es ist auch ausweislich hier aufgebaut. Auch das ist heute günstig. Wenn man sich den Javacode anschaut von Hadoop, ist es teilweise sogar erschreckend, wie einfach das ist, das Ganze. Aber es funktioniert im Großen und Ganzen. HDFS kann ich nur thumbs up geben. HDFS ist eine der Komponenten in Hadoop, speziell in Hadoop, die wirklich super funktioniert. Also das Verwaltungssystem ist rock solid, wie man so schön sagt.
Also wirklich solide und funktioniert einmal frei. Alles obendrauf reden wir gleich noch von. Also keine Silos, freien Zugriff auf Daten. Denn Daten in Hadoop werden nicht abgelegt in einem Schema, in der Datenbank hier und in einem Schema, in der Datenbank hier und wie gesagt Schema hier, sondern in einem Verzeichnis. Einfach ein Verzeichnis. Rohdaten in einem Verzeichnis.
Und da kann ich Rechte darauf vergeben. Und teilweise sogar auf Spalten- oder Zeilenebene. Also ich kann über spezielle Mechanismen, Lese-Mechanismen, kann ich sogar noch weiter runtergehen und nicht nur sagen, du hast kompletten Zugriff auf die Dateien, sondern du hast auch Zugriff auf die einzelnen Zeilen innerhalb der Dateien. Also auch das ist eine angenehme Sache.
Aber da stellt sich die Frage, jetzt habe ich also lauter Verzeichnisse und dann komme ich immer mit dem Beispiel von meiner Mutter mit ihrem Desktop, die weiß aber auch gar nichts weiter sagen. Meine Mutter weiß gar nicht, dass sie immer das Beispiel anbringt. Meine Mutter, ihr Desktop, ich weiß, wo immer meine Mutter ihr Desktop ist, aber wenn ich ihn aufmache, hat sie alle Icons auf dem Desktop. Alle.
Also jede Anwendung, die sie immer aufhatte, jedes Word-Dokument ist auf dem Desktop gespeichert. Während bei mir nur ein oder zwei Icons drauf sind, wo ich alles reinorganisiere. Weil bei mir ist eine Baumstruktur von einem paar, so ein, zwei, drei, vier Hauptordner, hange ich mich runter. Weil meine Mutter ist alles auf einem Desktop. Und das ist so ähnlich, wie wenn man sich Hadoop vorstellen, wenn ich Ihnen Hadoop gebe oder jemand anderem Hadoop gebe,
hat er jeder die Freiheit, zu machen, was er will. Und ich vergleiche das eigentlich so mit einem universellen Tieflader. Das im Prinzip gehe ich los und gehe zu MAN oder so, sage ich möchte einen Tieflader haben. Ich möchte mir nämlich was bauen. Das ist super. Wir haben den besten Tieflader, den Sie kaufen können. Also der Hadoop-Hersteller jetzt. Der sagt dann, das ist der beste Tieflader hier.
Also der hat die beste Maschine vorne drin. Der hat da einen Jan V8 vorne drin. Er hat HDFS-Reifen. Also das Ding ist super. Also wie eine Katze. Richtig so ein ganz tolles Ding. Ich kaufe das, fahre nach Hause, und der steht jetzt auf dem Hof und denkt mir, okay, jetzt will ich damit, keine Ahnung, zum Beispiel Beton fahren.
Ich gieße bei dem Beton obendrauf. Was passiert? Der Tieflader ist hin. Ist klar. Ich muss also irgendwie so eine große Tonne draufbauen. Am besten kaufen, wo ich dann Beton reinfüllen kann. Ich will einen Kran draus machen. Da mache ich über einen Kran. Kran bauen, nicht so einfach. Also ziehe ich wieder los und kaufe mir einen Kran,
den ich obendrauf baue. Das mache ich fünfmal. Baue fünf verschiedene Sachen obendrauf. Und irgendwann fällt das Flatbed einfach auseinander, weil ich so viele Löcher reingebohrt habe, dass die ganze Metallfläche oben so Schweizer Käse ist, dass nichts mehr drauffällt. Oder ich habe zum Beispiel einen Kran drauf und auf einmal ruft einer an, ich hätte gerne ein bisschen Beton. Keinen Kran. Also ich brauche jetzt nicht irgendwas zum Heben. Ich brauche nur Beton.
Dann sagt er, oh Mist, jetzt muss ich erst mal wieder den ganzen Kran runterbauen. Muss den Karton wieder... Also das wird am Anfang... Es hört sich jetzt ganz toll an, Hadoop. Das Problem ist, dass Hadoop viel zu tief sitzt. Hadoop ist nichts anderes wie ein Flatbed, also eine Art Tieflader, wo ich irgendwas drauf aufbauen kann. Das ist nicht genug. Okay, wir können natürlich jetzt sagen,
wir können es ein bisschen vereinfachen, das Ganze. Wir können also sagen, hm, wir organisieren die Daten für den einzelnen Anwender. Das heißt, wir machen das nicht wie meine Mutter oder ich. Also ich will nicht sagen, dass meine Mutter falsch liegt oder so. Ich finde halt nur nichts auf ihrem Desktop. Oder sie findet nichts auf meinem, weil da sind nur Folders und dann versteht sie ja nicht, wo was drin ist.
Suche kennst du ja auch nicht. Also versuche ich mir irgendwo zu sagen, ich muss irgendwas organisieren. Und das ist ganz wichtig. Das macht dieser Tieflader überhaupt nicht. Der Tieflader sagt mir nicht, wie ich hinten was aufzubauen habe. Vielleicht gibt es noch mal DIN-Vorbohrungen oder sowas. Aber wenn ich keine DIN aufbauten habe,
kann ich damit nichts anfangen. Das heißt, ich baue mir selbst was obendrauf. Dann kommt eben unsere menschliche Qualität des Erforschers und des Entwicklers. Irgendwie baut irgendwas obendrauf. Und das kann eben dementsprechend gut oder schlecht sein. Also, was muss ich machen? Ich muss also irgendwo definieren,
was ich mit den Daten mache. Und da, wie gesagt, ich habe halt viele Quellen, viele Geschäftssparten oder einzelne Abteilungen, die auf die Daten zugreifen. Ich habe viele Anwendungsfälle. Ich will also von zum Beispiel irgendwas vielleicht sogar transaktional bis hin zu Machine Learning, Notebooks und Exploration
und random forests gerne eine Ahnung drauf laufen lassen, dass ich irgendwo irgendwelche Erkenntnisse, Modelle entwickle, die ich weiter verwenden kann, die Erkenntnisse zum Verbinden mit anderen Erkenntnissen oder die Modelle, um sie anzuwenden, auf was gerade reinkommt. Und das muss irgendwie aufgebaut werden.
Aber zu guter Letzt kann es natürlich sein, dass auf einmal einer kommt und sagt, ja, das musst du aber auch in einer bestimmten Zeit machen. Das sind die sogenannten SLA, Service Level Agreements. Das heißt also, irgendwo gibt es eine Vorgabe, die sagt, super, du kannst Machine Learning machen, aber ich brauche die Ergebnisse in zehn Millisekunden. Weil ich damit zum Beispiel Entscheidungen treffe. Ich bin eine Kreditkartenfirma und muss entscheiden,
ob diese eine Transaktion, ob die okay ist oder nicht okay ist. Das heißt, ich muss irgendwo nicht nur das Modell berechnen, sondern ich muss auch das Modell anwenden auf eine Transaktion und muss das ausgeben. Kann das Hadoop oder kann das nicht Hadoop? Immer noch mit Hintergrundverhalten. Wir haben einen Tieflader. Tieflader fahren, wenn sie einmal fahren, fahren sie. Kann ich damit reagieren?
Kann ich damit Bogen schlagen oder so? Oder Rennen fahren? Also wie organisiere ich das Ganze? Und wir versuchen also, eine Lösung zu finden, wo wir die Daten möglichst roh aufnehmen. Wir wollen ja, wie gesagt, hat er erwähnt, Hadoop soll ja irgendwo die Daten roh behalten, dass wir sie auch immer wieder neu transformieren können, in neuen Wert erzeugen können, über Zeit.
Wir müssen irgendwo die Daten finden. Wir müssen sie verwalten können. Auch das muss irgendwie vorgegeben sein. Und wir müssen am besten vielleicht auch schon, und das ist so ein bisschen ein Schritt nach hinten, für die Auslieferung müssen wir Daten optimieren. Also wir müssen irgendwo vielleicht Daten zusammenführen und zusammengeführt zur Verfügung stellen. Also da sind wir wieder in dem Bereich, das kennen wir alle schon wieder. Also da gibt es nichts Neues im Lande,
sondern hier müssen wir wieder teilweise das Gleiche machen, wie früher auch. Und wir müssen sehen, wie wir die ganze Plattform aufbauen und Daten ausliefern können. Fangen wir mal von vorne an. Enterprise Data Hub, so nennt sich das Ganze bei Cloudera, Data Lake, bei anderen. Wie gesagt, ich weiß nicht, wie andere das nennen, aber es ist irgendwo Big Data. Big Data sitzt in der Mitte.
Oben haben wir die Konsumenten, unten haben wir die Quellen. Wie machen wir das Ganze? Also wir haben viele verschiedene Nutzer und wir haben viele verschiedene Quellen. Wie bekommen wir die Daten irgendwie organisiert dazwischen? Und das, wie wir von oben gesehen, ist das unser Tieflader. Das ist unser Big Data-Tieflader.
Also, okay, Daten können wir reinladen. Das ist okay. Wir haben also Quellen irgendwo auf der einen Seite und wir haben Dateien auf der anderen Seite. Wir haben Tools, die wir nehmen können, um relational Datenbanken abzuholen. Wir wollen ja migrieren auch. Wir wollen also Daten abholen und bewegen auf diese neue Plattform. Auch das müssen wir irgendwie können. Also hier haben wir die ganzen verschiedenen einzelnen Daten,
die dort rankommen. Und wie sie angebunden werden, kann ein bestehendes MQ-System sein. Wir wollen ja nichts wegschmeißen. Wie gesagt, wir wollen ja anbinden. Wir wollen ja neutral sein. Wir wollen bedienen. Wir wollen keine Brücken abbrennen. Es gibt also in Hadoop im Prinzip eine Anbindung an alle bestehenden alten Systeme.
Entweder SQL, MQ oder also Message Queues. Dann wäre schon Kafka einsetzt. Also natürlich auch modernere Sachen wie Kafka oder neuere Sachen wie Kafka. All das gibt es halt auch schon in Hadoop. Es gibt auch Tools, die man nehmen kann, um die Daten anzubinden. Das machen wir über zum Beispiel Scoop, NiFi
oder andere Tools, Flume. Binden wir halt eben das Ganze an. Es gibt auch, wie gesagt, dort Open Source Varianten. Es gibt dort kommerzielle Open Source Varianten in dem Bereich. Auch das ist ein Markt, der ganz stark im Augenblick am Puschen ist. Ich hatte die Konferenzen gesehen, von klein bis groß. Das erste Mal auf der Hadoop World war.
Das war die zweite, die es gab. Das war die erste, glaube ich. Also die zweite, glaube ich auch. Da war der Ausstellungspavillon, also die Ausstellungshalle. Da waren, glaube ich, zehn Firmen drin. Oder acht, glaube ich, oder so. Zwei davon waren schon, also drei waren für Front-End BI Tools,
die auf Hadoop zugreifen, um Daten zu visualisieren. Eine Firma war für das Einlesen der Daten. Die letzten Jahre auf der Hadoop Summit, Strater Hadoop Summit, war es dann schon, war es eine Halle so groß, also eine Messenhalle auf der Cebit, voll mit Herstellern. Also ich habe es nicht geschafft, alle mir anzuschauen. Es waren viel zu viele.
Und da waren viele, die es irgendwie hinbekommen, Daten an Hadoop ranzuführen. Themen, Streamsets, Waterline Data, die ein paar, die ich mir angeschaut habe. Also da gibt es einen riesen Markt, Daten an Hadoop heranzuliefern. Also okay, das können wir machen. Und wir speichern das Ganze in einem Verzeichnis ab,
irgendwo in Hadoop, aber einem bestimmten bekannten Verzeichnis, nach Quelle sortiert. Und schreiben das Ganze da rein. Das, wie gesagt, können wir dann verarbeiten, lesbar machen durch Transformationstools, wenn wir das wirklich brauchen. ITL, wie gesagt, ist jetzt wirklich, wir brechen nicht da irgendwie mit den alten Ideen. Wir brauchen manchmal wirklich Daten, die wir aufbereiten. Das heißt, wir benutzen dann Tools
auf einem Discovery Layer, wo wir dann sagen, jetzt haben wir sie gehoben von einem Raw Layer, also von dem eigentlichen Rotdaten-Ebene, auf die nächste Ebene, wo wir dann die Daten zur Verfügung stellen. Hier können jetzt kleine Four Teams die Daten klassifizieren. Und das ist ein ganz, ganz, ganz wichtiger Punkt. Ich habe das mehrfach erlebt bei großen Firmen,
die nicht vorankommen mit ihrem Hadoop, ich komme da gleich nochmal drauf, mit ihren Hadoop-Anstrengungen, weil sie nichts klassifizieren, fast nichts. Die meisten Daten, die reinkommen, sind Top Secret. Top Secret heißt, da darf keiner dran. Weil könnte nämlich sein, dass da Privatdaten drin sind. Das heißt, da wird einfach erstmal der höchste Label draufgeschrieben und wenn einer nachfragt,
dann wird er nachgeschaut und das Ganze, okay, das ist doch öffentlich, weil es war ja doch irgendwie keine Ahnung, was richtig war. Aber wenn das nicht passiert, wenn wir nicht also Data Stewards, bei anderen heißt das Data Clinic, habe ich auch schon gehört. Also egal, irgendjemand, der sagt, hier sind die Daten, wir wissen, was drin ist. Irgendeiner muss dafür unterschreiben. Und das ist das große Problem.
Und dafür unterschreiben will keiner. Irgendeiner muss dafür abzeichnen und wenn die Daten dann zur Verfügung stehen, muss es ein Katalogtool geben, das dann sagt, okay, hier sind die Daten, die es gibt und die und die Felder gibt es, also technische und Business-Meter-Daten müssen dann hinzugefügt sein, dass man das mit den Quellen was tun kann.
Und kann sie weiterverarbeiten durch andere Tools. Dann kommt der Shared Layer, wo ich dann oben drauf die Daten weiterverarbeiten kann. Dort habe ich jetzt die Möglichkeit zu sagen, jetzt kann ich Spaten übergreifen, die Daten dann zur Verfügung stellen. Jetzt kann zum Beispiel ein das Marketing sagen, ich brauche mal das Clickstream-Data, also was aus unserer Webseite kommt. Und ich brauche mal die Twitter,
den Twitter-Feed, was von Twitter gesagt wird über unseren gefilterten Twitter-Feed, also was Kunden über uns sagen. Die Daten kommen unten rein, laufen hoch und jetzt kann die Abteilung darauf zugreifen und kann die Daten verarbeiten. Auch das macht Sinn und wir haben Tools dafür, das zu verarbeiten. Und wie gesagt, auch da, ich hatte erwähnt, das ist nicht alles neu. Auch hier müssen wir
Daten optimieren, wenn es nämlich darum geht, schnell zu sein für die Auslieferung. Wieder das Beispiel für Kreditkarten-Fraud. Wenn ich also sage, ich muss jetzt innerhalb von wenigen Millisekunden Ergebnisse liefern, muss ich dann nochmal optimieren, die Daten ablegen in einem Format, die es mir erlaubt, das Ganze auszugeben. Und auch hier komme ich wieder in die Richtung Enterprise Data Warehouse
und deswegen ist auch so jemand wie Inmon und Kimball an Big Data interessiert, denn man kann die Physik, kann man leider nicht hier so richtig betrügen, wenn ich große Datenmengen habe und möchte sie optimiert ablegen, zum Beispiel für die Analyse versus für die zum Beispiel transaktionale
Verarbeitung, muss ich doch wieder anfangen, Daten umzuschreiben. Also auch die mehrfachen Schemas kommen auch hier wieder zum Spiel. Also Hadoop ist auch nicht alles Gold, was glänzt. Okay, was mit Echtzeit? Ja, kennt jeder, Lambda-Architektur war wahrscheinlich letztes Jahr oder das Jahr, irgendwann war das auf jeden Fall in vielen Konferenzen, Lambda-Architektur war eine
mindestens 4-5 Talks über wie kann ich dieses Hadoop-System, dieses Big Data-System agiler machen. Und diese Übergangslösung, wo wir noch nicht, wir konnten damals mit den CPUs und mit den Disks, die wir hatten, konnten wir noch nicht das hinbekommen, dass wir schnell genug Daten auch dann ausliefern oder verarbeiten konnten. Also die Kette hat noch zu lange gedauert.
Wurde dann so eine Art Zwischenlösung aufgebaut, die sich halt Lambda nennt, wo wir dann Hadoop mit irgendeinem Speed-Layer verbinden, wo wir dann so einen Kafka oder obendrauf Spark Streaming benutzen, um dann halt eben Daten möglichst direkt aus dem Rohsystem abholen, erkennen, verarbeiten, Storm benutzen oder ähnliche Sachen, wie gerade Spark Streaming Storm
Flink, wo wir dann die Daten verarbeiten, irgendwelche Erkenntnisse erzielen, trotzdem in die Langzeitkette speichern, dass wir das also auch komplett verarbeiten können, aber wir können relativ schnell Entscheidungen treffen und vorbereiten. Auch das ist möglich, geht also auch. Gut, also wir haben ein offenes Ökosystem, wir können machen, was wir wollen. Wir haben die Sicherheit
in die Steuerung. Es ist also auch eingebaut, dass man autodifizieren kann, dass man autorisieren kann, dass man auch sehen kann, wer hat was verarbeitet. Alles das bringt Hadoop schon mit, aber mehrfach. Und auch hier wiederum sehen wir über die Zeit, dass die einzelnen Hadoop Hersteller auseinanderdriften und andere oder konkurrierende
Systeme benutzen, um eben solche solche wichtigen Funktionen, essentielle Funktionen in einem IT System anders abzuhandeln. Und auch das wird längerfristig, glaube ich, nur zu Kopfschmerzen führen, aber ist im Augenblick Open Source. Wie gesagt,
ist ja nicht das Problem. Es geht erstmal darum, dass alles Open Source ist. Und leider ist das alles Open Source aber anders. Also auch da müssen wir mit zurechtkommen. Und Resource Management ist mit eingebaut, Jan oder ähnliche Sachen. Wir können also irgendwie kontrollieren, was passiert in dem Cluster und wir können die Kosten dann aufteilen. Wir können also erfassen, wer hat was gemacht und können dann die Abteilungen
bezahlen lassen für den Cluster. Das ist also erstmal so der Haupt Selling Point von Hadoop. Außerdem ist diese Struktur, die ich jetzt gerade vorgestellt habe, diese Informationsarchitektur, ist jetzt nicht zwingend so viele Layers, so viele Ebenen. Das können Sie anpassen, wie Sie wollen. Das können Sie also auch erweitern, verringern. Das ist im Bezug alles,
wie gesagt, das ist ja wie der Desktop von meiner Mutter oder meinem Desktop. Ich kann das machen, ich kann auch fünf oder zehn Ordner nehmen. Oder gar keinen oder irgendwas dazwischen. Das bleibt jeweils überlassen. Aber ohne eine Informationsarchitektur ist Hadoop nichts anderes, wie einfach nur eine große Fläche ohne Beschreibung. Das ist ein ganz wichtiger Faktor und eine Riesenentscheidung, also eine
Hürde, die man nehmen muss. Das muss man auch erstmal erkennen. Gut, also Wandel weg vom Big Data Spaghetti, weil wir oben lauter Systeme haben, die lauter Systeme schreiben und unten wieder lauter lesende Systeme haben, die von verschiedenen Systemen lesen, hin zum Big Data Lasagne. Das ist so der Take away für heute. Lasagne ist gut. Spaghetti ist
auch gut. Aber wie gesagt, haben wir schon so oft gesehen. Lasagne ist so ein bisschen was, so ein bisschen was extra. Sieht also so aus, dass wir einen Aufbau. Jetzt kommen wir zum entscheidenden Teil. Wir wollen das Ganze jetzt abrunden. Wir wissen also jetzt, wir haben bestehende Systeme, die vielleicht nicht mehr so richtig funktionieren in der heutigen Welt. Weil wir, wie gesagt, mehr können heute, als
diese Systeme original mal entwickelt worden sind. Wir überlaufen sie ein wenig. Jetzt haben wir Hadoop auf der anderen Seite. Hadoop verspricht, offen zu sein, alles speichern zu können, beliebige Schnittstellen, Batch, Interaktiv, Realtime, alles dabei. Also können wir damit machen, was wir wollen.
Auf die IT-Systeme, gute Nachricht. Alles beim Alten. Ganz cool. Die IT-Leute sind, wenn sie mal Hadoop angefangen haben und wenn Procurement mal sich damit abgefunden hat, dass man nicht mehr HPC Maschinen kauft, also High Performance Computing Maschinen kauft, die, keine Ahnung, über 70 CPUs drinne haben.
Und, wie gesagt, das ist eher so großes Gehirn und kleine Sachen. Also umgekehrt zum Dinosaurier haben wir hier mehr Gehirn als Beine. Jetzt brauchen wir hier was Ausgewogenes. Wir brauchen ganz normale Server. Das ist eigentlich ein Witz, aber wir brauchen ganz normale Server. Wir brauchen Server, Rec Server,
zwei CPUs, 6, 12, 24 Platten. Das ist eigentlich alles, was wir brauchen. Schon heute teilweise SSD ist manchmal sogar schon im Mix drinne und so weiter. Aber das ist meistens gar nicht vorgesehen beim Einkauf. Aber wenn das einmal gemacht ist, sind die alle gleich. Die können über die Integration, wenn die neue Generation rauskommt, hinzugefügt werden. Prima. Also IT
ist relativ gut aufgestellt und kann mitwachsen mit dem Hadoop Umfeld. Und auch wenige Administratoren können eben homogene große Cluster relativ einfach pflegen. Also auch das kann man automatisieren. Das sieht man, wenn man mal Google anschaut. Die reden halt davon, wie viele Leute sie haben pro Clusterknoten oder wie viele Clusterknoten pro Leute.
Da können wirklich gute Verhältnisse hergestellt werden. Aber leider ist noch nicht alles entwickelt. Also man muss manchmal auch ein bisschen verbasteln. Aber im Weiten, Russen und Katzen geht das. Was ist der Einfluss auf die Prozesse? Die Prozesse sind hier also mein erster, ich schmeiße einfach so einfach raus so als
Mitteilung. Projekt taugt nichts. Für Hadoop taugt Projektarbeit nichts. Diese ganze Idee, dass man sagt, wir bauen oder wir setzen ein Projekt auf, um ein Hadoop-Projekt umzusetzen, ist Horror. Absoluter Horror. Denn im Bezirk was wir gemacht haben, wir haben einen
Laster gekauft, der schon alles kann, also der im Bezirk eine Riesenlast ziehen kann oder tragen kann. Das heißt, wir haben schon die großen Maschinen, wir haben die Daten, die wir reinladen können. Warum müssen wir jetzt noch ein Projekt aufsetzen, um zum Beispiel Schemas anzupassen, Datenbanken anzupassen. Das brauchen wir gar nicht mehr, denn wir können ja Daten
jetzt reinschreiben und dann einfach freigeben. Fertig. Wir müssen nicht mehr irgendwie den Kollegen irgendeinen Antrag schicken mit 5 Durchdrucken oder so was, oder 5 Durchschlägen, damit er mir irgendwas freischaltet, irgendeine Datenbank anlegt oder Schema muss nochmal angepasst werden, nochmal in der Iteration nochmal ein Sprint. Wir machen ja heute alles in Sprints, wir sind ja alle agil.
Wir müssen nochmal ein Sprint verloren, weil wir haben das ja verpasst und so weiter, dann wird halt nochmal ein Sprint gemacht. Ansonsten ruf ich an, dann macht das halt eben. Also all das muss sich ändern. Und das ist heute noch überhaupt nicht angekommen. Also, wir brauchen irgendwas, was eigentlich plattform- oder funktionsübergreifend
ist. Wir müssen irgendwie sehen, ob wir wir haben das versucht bei Kunden, wir sind wir haben gesagt, macht nicht einfach einen Projektmanager, der dann immer wieder Leute fragt, und die sagen alle, ne, mach ich nicht, kann ich nicht, ich habe keine Zeit für, sondern um Big-Daten-Projekte, manchmal muss es halt noch ein Projekt sein, bis das Ganze steht, um Big-Data-Projekte umzusetzen,
es ist besser, so eine Art DevOps- Team zu bilden, zusammengesetzt aus wichtigen Leuten aus jeder von den Rollen. Und wenn die ihre Aufgabe erledigt haben, können die wieder zurückgehen zu den alten Rollen, aber vorher kriegt man das Ganze nicht umgesetzt. Wenn ich nicht alle an einem Tisch hab, die alle mitziehen, ist Big-Data erst mal auf die lange Bank geschoben. Das passiert jedes Mal, fast jedes Mal, wo ich hinkomme, außer es ist eine
agile Firma, die modern arbeitet und die einfach auch will, dann geht das Ganze. Die großen Firmen, die ganz, ganz großen, 100.000 mehr Mitarbeiter hab ich das, kann man wirklich abhaken, also 95, 99% von diesen großen Firmen haben Probleme Big-Data umzusetzen, weil sie einfach das Ganze falsch angehen, sie gehen das an wie jedes andere IT-Projekt,
und das braucht ewig. Also, vielleicht irgendwie das Ganze umstellen. Wichtig, das ist ja der wichtigste Teil, genau deswegen, ich hab ja darauf hingeführt schon, Menschen müssen sich ändern, und das ist ein ganz wichtiger Punkt. Karrieren ändern sich, heute ist das so, dass mittleres Management jedes Projekt als
kleinen Stein benutzt, um weiterzukommen im Leben. Das heißt, wenn ich 6 bis 12 Monate an einem Projekt gearbeitet habe, und das erfolgreich ist, egal wie es hinten rauskommt, bis das irgendwann einer aufdeckt, dass es nicht erfolgreich war, sind nochmal 6 bis 12 Monate vergangen, dann hab ich schon den nächsten Posten erklommen. Das heißt, man kann es mir wieder nicht wegnehmen, und so
passiert das doch heute. Es ist doch wirklich krass, was da eigentlich irgendwie auf der Ebene teilweise dann durchgeführt wird, das im Prinzip verschwiegen wird, vertuscht wird, damit der nächste, der reinkommt, auch nicht den Mist übernehmen muss, sondern das wird irgendwie anders dargestellt und dann neu gemacht, dann wird alles wieder rausgeschmissen, und dann neu gemacht heißt im Prinzip alten Mist raus, neuen Mist
rein. Und wie gesagt, das ist für mich der wichtigste Punkt. Wenn wir nicht auf der mittleren Ebene, und wie gesagt, oben kriegen wir relativ schnelle Entscheidungen, unten können wir relativ technisch das schnell umsetzen. Wenn wir in der Mitte nicht verstehen, was Hadoop oder Big Data bedeutet, kommen wir nicht voran, oder setzen wir das Ganze nicht schnell genug um. Architekten müssen sich auch umstellen,
wir bauen keine Systeme mehr. Hadoop ist eine riesen Plattform. Klar, es gibt immer noch Firmen für Datenbanksysteme, die gehen nicht weg. Ich will jetzt nicht sagen, es gibt nachher nur noch eine Firma, die nur noch auf 100% auf Hadoop läuft. Das ist ein Irrglauben. Aber Hadoop wird wichtig, weil wir die Daten groß werden. Das heißt, wir werden auf einmal 500.000 Maschinen in einem Cluster haben. Das ist wesentlich größer als
was wir je hatten, und das ist ein homogenes System. Das heißt, die Architekten müssen auch auf der Datenebene planen, und nicht mehr auf der Systemebene. Wenn die das System einfach neue Platten hinzu, und schon wächst das Ganze, dann muss ich nicht mehr groß mich anstrengen. Also da muss auch ein bisschen sich was ändern, aber die sitzen dazwischen.
Und auf den Administratorenseite, bei dem Personal, Administratoren, das ist ein neues IT-System. Das kann man beibringen, das kann man bedienen. Es gibt Grafen, Frontends dafür, dass man sehen kann, was macht das Ganze. Da passiert nicht viel. Die haben relativ die gleiche Rolle wie vorher auch.
Und Entwickler ganz oben drauf bekommen normale Schrittstellen. Die bekommen also DSLs, also Domainspecific Languages, wie SQL oder andere. Das heißt, ein Notebook mit Python drinnen, oder mit Scala drinnen, oder was auch immer, oder wie wir es auch gerade möchten, SQL drinnen. Die können mit den Daten dann arbeiten und darauf Lösungen aufbauen.
Also Entwickler, das wird einfach alles ein bisschen schneller, das Ganze. Wird größer, schneller, umfangreicher und mehr experimentell. Also auch das ist eine gute Sache, weil es sie begeistert. Und wenn wir das Ganze jetzt mal Gartner Halbkurve, also das ist die Gartner Kurve, wie Systeme sozusagen eingeführt werden. Anscheinend ist das
ein ganz klassisches Problem. Bei der Abhandlung oder Einführung von Technologien folgen wir so eine Kurve. Und das Ganze können wir bei Hadoop genau so beobachten. Also am Anfang Management hat das zehnte E-Mail bekommen, dass Big Data wichtig ist. Also wird Big Data auf die strategische Liste geschrieben. Für dieses Jahr
Mobile und Big Data ist strategisch. Punkt. Da wird meistens gesagt, IT bestell mal einen Cluster. IT geht los und baut einen Cluster. Ohne Anforderungen. Null. Der erste PUC kommt danach.
Wir wollen erst mal den Cluster aufbauen. Wir brauchen ja Big Data, also wird der Cluster aufgebaut. Also kommt dann der erste PUC. Okay. Alles klar. Hier ist begeistert. Jeder stürzt sich drauf. Hoffentlich. Es geht richtig los. Jetzt erster PUC. Wir bauen keine Ahnung. Das heißt eine ITL-Auslastung oder Abnahme von ITL-Arbeiten rüber zu Richtung Hadoop oder vielleicht Machine Learning
Geschichte, weil wir das brauchen. Egal was es ist, völlig egal. Einfach irgendein erster PUC wird gemacht. Und dann kommt Management von ganz oben nach 6 bis 12 Monaten. Und ohne Witz, ich war bei Kunden, die gesagt in 3 Monaten haben wir den Cluster laufen. Mit dem ersten PUC obendrauf. Mit den ersten Ergebnissen. Und ich sag immer, nee, das braucht 6 bis 12 Monate.
Und ich hab wirklich einfach nur aus Erfahrung hab ich fast immer recht. Die 3 Monate sind völlig überzogen. Bis da Procurement erstmal Cluster hingestellt hat, sind 3 Monate vergangen. Nocker. Und was wird heute gemacht? Heute wird natürlich die Cloud ausgelagert. Heute wird dann zum Beispiel dieser erste PUC in Amazon gemacht. Das verkürzt diese Kette. Aber
trotzdem nur am Anfang. Der Rest, was mach ich überhaupt mit diesem Tieflader? All die Probleme, wie richte ich dort Sicherheit ein? Ist nämlich genau das Problem. Das heißt, irgendwann kommt nämlich das ok, so Hadoop ist also doch nicht so Enterprise Ready wie uns verkauft wird. Ich bringe jetzt hier Hadoop rein, weil
sie gehen zu Cloudera, sie gehen zu Rottenworks. Da steht nur Enterprise Ready. Und sonst irgendwelche Schlagwörter. Ist nicht so. Überhaupt nicht so. Das ist eine reine, das ist ein glänzender leistungsfähiger Laster, den sie bekommen. Das ist das Prinzip, oder ich weiß auch immer welche Marke das ist, keine Werbung. Irgendeinen Laster,
den sie bekommen. Der ist wirklich toll. Das ist einer der besten Laster, den sie kaufen können. Das ist nicht das Problem. Der Laster ist schön. Aber, was sie damit machen, ist nirgendwo vorgeschrieben. Das heißt, irgendwann muss ich mich fragen, ok, Sicherheit? Wie richte ich das ganze ein? Keine Ahnung.
Müssen wir Ranger oder Sentry nehmen? Oder was auch immer? Wie funktioniert das ganze überhaupt? Wie komme ich eine Entwicklungsumgebung aufgebaut? Ach, Entwickler können nicht direkt auf die Rotdaten zugreifen? Das ist ja komisch. Müssen wir abregeln? Oder müssen wir neue Umgebungen aufbauen? Das heißt, nicht nur eine Umgebung, wie beim POC. Wir müssen auf einmal 4, 5 Umgebungen haben für Hadoop. Ich dachte, Hadoop
wäre diese eine Umgebung für alles. Nee, Hadoop ist eben nicht die eine Umgebung für alles. Hadoop ist die eine Umgebung für alles in der Produktion, ja. Aber ich brauche trotzdem noch Dianne, ich brauche Backups, ich brauche User-Accepting-Tests, ich brauche Web-Testumgebungen, ich brauche Entwicklungsumgebungen und so weiter und so fort. Oh, das kostet ja wieder Geld. Wo ist das Budget?
Also, wir sind ja wie Menschen, wir haben ja zwei Arten. Das ist ja in unserem Grundgehirn eingebaut. Ist entweder Fight oder Flight, Angriff oder Flucht. Das ist ja ganz tief eingebaut in unsere Gene und unsere Veranlagung. Und der erste Schritt ist natürlich, erst wollten sie, okay, wir machen es.
Und dann der zweite Schritt, was dann kommt, aus der mittleren Ebene, ist dann Flight. Big Data ist eigentlich gar nichts. Big Data taugt überhaupt nichts. Das war alles so gestern. Wir müssen gucken, wie wir rauskommen. Das Problem ist, da kommt man nicht raus. Es gibt da keine Alternativen, es gibt keine Wege außenrum. Dann kann ich sagen, wir lassen Big Data einfach, wir machen Cloud, wir machen Mobile.
Nee, Cloud und Mobile setzt auf Big Data auf. Das ist überhaupt nicht möglich. Also wir müssen uns damit beschäftigen. Das heißt, irgendwann kommt man die Erkenntnisse aus. Wir müssen irgendwas machen und was passiert? Man schmeißt Geld drauf. Also mehr Ressourcen, mehr Budget. Irgendwann mal knirscht die ganze Kette hoch zu, knirscht jeder, unterzeichnet aber, und dann werden die Umgebungen aufgebaut. Und dann kommen wir aus dem Tal raus,
die ersten Produktionen laufen. Jetzt können wir irgendwann mal mehr drauf laufen lassen auf dem Cluster. Wir müssen uns noch mit vielen Sachen beschäftigen, aber das Ganze funktioniert dann erst mal soweit. Das ist die ganze Geschichte. Es ging um große Datenmengen, bedeuten große Veränderungen. Ich sehe das als ganz, ganz wichtig zu erkennen,
dass wir, obwohl wir auf dieser Konferenz viele interessante Themen hören werden, über was ich mit großen Datenmengen machen kann, wie ich modern mit Daten umgehen kann, wie ich mehr Erkenntnisse herausholen kann, wie ich es besser verarbeiten kann. Und wie gesagt, der Firma, für die ich arbeite, einen Mehrwert erzielen kann.
Das ist alles schön und gut. Aber ob ich jetzt Hadoop oder irgendeinen anderen Big Data Stack unten drunter benutze, der Aufbau ist überhaupt nicht trivial, überhaupt nicht. Und wenn die Plattform nicht stimmt, habe ich Probleme zu zeigen, dass mein Projekt wirklich auch was bringt. Und irgendwann wird es vielleicht auf die lange Bank geschoben, obwohl es eine tolle Sache ist, weil die ganze Plattform nicht liefert, was sie eigentlich liefern sollte.
Also das müssen Sie irgendwie im Auge behalten oder Hadoop ändert, wie wir Sachen aufbauen. Wir tun nicht mehr physisch Systeme anfassen. Wir haben logische Projekte. Das heißt, wir haben nur noch Projekte, die sagen, du brauchst Zugriff auf das Clickstream,
du brauchst Zugriff auf Twitter, du brauchst Zugriff auf Facebook-Daten. Kein Problem. Hier sind deine Rechte. Los geht's. Notebook sitzt schon da, kannst loslegen, kannst ein Projekt machen. Also diese ganze Leute ansprechen, verändert sich komplett, beeinflusst die Menschen, die dazwischen sitzen. Es beeinflusst, wie Projekte durchgeführt werden. Keine sechs, zwölf Monate mehr.
Wie gesagt, keine typische Abhandlung. Meine Aufgabe ist, diese drei Projekte durchzusehen. Wenn die durchgesehen sind, wenn die erfolgreich sind, bin ich erstmal gemacht. Das wird anders laufen. Wir müssen wahrscheinlich in der gleichen sechs bis zwölf Monaten 10, 15, 20, vielleicht sogar 100 Mini-Projekte abwickeln,
um den Mehrwert zu zeigen. Das ist mehr so wie Venture Capital. Aus den 100 Mini-Projekten werden vielleicht nur fünf irgendwas für die Produktion. Und 99 werden weggeschmissen. Das ist eine ganz andere Sache, als wenn wir sagen, wenn ein Projekt losgetreten wird, dann ist die Wahrscheinlichkeit, dass es erfolgreich ist, relativ hoch. Ist auf der Hadoop-Seite gar
nicht so. Auf der Hadoop-Seite wollen wir experimentieren, wir wollen neue Sachen finden und das heißt auch manchmal aufgeben. In Amerika ist das Gang und Gebe. Amerika ist so das Land der Start-ups, der Möglichkeiten. In Deutschland sind wir alle noch so, schauen wir erstmal, keine Ahnung. Wir wollen ja jetzt nichts falsch machen. Wir wollen ja jetzt nicht irgendwas los treten, was nachher gesagt wird,
guckt den an, der hat schon das fünfte Projekt gemacht und da ist immer noch nichts geworden. Immer wieder fährt er gegen die Wand und da versucht es immer noch. Aber wir sind doch als Researcher, als wissenschaftlichen Mitarbeiter an Universitäten, sind wir doch genau das Gleiche. Wir versuchen so lange, bis wir einen Weg finden. Ansonsten, keiner sagt zu dem, du bist an der Uni, du bist ein Loser, du machst irgendwas, was keiner braucht.
Und das möchte ich gerne auf der Hadoop-Seite aufsehen. Dass wir wegkommen von dieser Idee, dass wir nur möglichst erfolgreiche Sachen anstoßen, sondern auch experimentieren. Und wie gesagt, es beeinflusst die verschiedenen Menschen zwischendurch und im Großen und Ganzen hört sich das alles toll an.
Aber wie gesagt, die Welt dazwischen ist noch ganz, ganz rau, ganz, ganz wilder Westen teilweise. Auch, wie gesagt, wenn wir hören, was man alles mit Daten machen kann, halten sie im Hinterkopf, dass Hadoop vieles, vieles noch gar nicht kann und sie darauf eingestellt sein müssen, um die Probleme herum zu schiffen, diese zu lösen und langfristig
dann zum Ziel zu führen. Danke.