Jedenfalls geht was. So, geht gleich weiter im Programm
. Ich hatte eigentlich noch darauf gehofft,
dass es so ein paar Fragen zwischendurch gibt,
in denen ich meine Präsentation am Hochguten kann.
Hören mich alle gut? Auch hinten weiter. Super.
Höher. So. Okay, ja, herzlich willkommen erstmal zu
meinem Vortrag mit dem Thema Big Data und Data Science.
Es sind ja zwei super gehypte Begriffe wahrscheinlich,
die am meisten gehypten Begriffe in IT-Welt aktuell.
Ich habe mir mal die Freiheit genommen,
Data Science einfach noch mit in die Runde zu schmeißen,
wenn wir schon so bei so vielen Hype-Themen sind.
Da kann ich auch ein bisschen mehr zu erzählen
als über Big Data Technologien
Aus meiner Erfahrung möchte ich so ein bisschen erzählen,
was meiner Meinung nach hinter den beiden Themen steckt,
welche immensen Möglichkeiten die Entwicklung dahinter auch mit sich bringen,
aber auch so ein bisschen Vorsicht.
Ich weiß, wir sind hier zu Gast bei einer Unternehmensberatung,
aber auch bitte Vorsicht, nicht jedem Hype-Thema folgen.
Da gibt es, glaube ich, so ein paar Do's
and Don'ts, die ich Ihnen mitgeben möchte.
Ganz kurz zu mir, ich habe 2003 in dem Bereich angefangen,
da gab es diese beiden Begriffe noch gar nicht.
Da haben wir von Data Mining gesprochen,
von Machine Learning vielleicht noch. Ich habe bei Otto angefangen,
da Katalogsteuerung mitgemacht, dann bin ich zu Xing gegangen,
habe da das Data Mining aufgebaut,
war dann nochmal bei einer unserer Marketingagentur zwischendurch und bin jetzt bei Jimdo momentan.
Kommen wir gleich noch mal ein bisschen detailliert dazu.
Also ich habe es schon so ein bisschen Krams in dem Bereich
gesehen und hoffe, dass ich spannende Sachen dazu erzählen kann.
Astrid, bitte einmal. Weiter. Ja, Big Data
ist wie Sex bei Teenagern. Jeder redet drüber.
Niemand weiß, wie es geht. Jeder glaubt, dass
alles tun. Also behauptet jeder, man tue es auch.
Ich weiß nicht, ob Clean ist so ein bisschen.
Ist nicht von mir. Ist nicht von mir ist,
von dem Dan Riley. Der das auf Facebook irgendwann mal
gepostet und zig Leute haben es übernommen. Ich finde,
es trifft den Nagel so ganz gut auf den Kopf.
Meiner Meinung nach wird Big Data das Wort Big Data,
meiner Erfahrung nach zum Beispiel in unserem Team bei Jim New
benutzen wir das Wort eigentlich nie.
Alle Leute, die ich kenne, die wirklich Big Data machen,
sagen nicht, dass sie Big Data machen.
Vielleicht die Facebook und Twitter-Leute, wenn sie irgendwie PR-Maßnahmen raushauen müssen,
werden sie dazu genötigt, zu sagen, wir machen Big Data.
Ich weiß nicht, vielleicht achtet ihr mal drauf,
meine beiden Nachredner sozusagen, wie häufig sie den Tirmen wirklich benutzen.
Ich benutze den eigentlich auch nicht so gerne auf Präsentation
dann doch,
aber ja
Ich habe noch mal überlegt, welche Definitionen ich eigentlich super spannend finde.
Asrid hatte gerade diese klassische von The Locity Variety on Volume war das,
glaube ich, die so ein bisschen Big Data ausmacht.
Finde ich auch gut. Nur The Volume klingt immer so,
als ob man das so an Terabyte oder Peterbyte festmachen könnte. Und ich glaube,
was wichtig ist für viele von euch auch zu verstehen,
als Big Data nichts ist,
wo irgendwie die Daten groß genug sein müssen und dann kann man loslegen,
sondern die Technologien sind jetzt da und können,
also ihr könnt die Tools auch nutzen,
ohne Big Data zu machen.
Also wir bei Jimdo machen definitiv keinen Big Data.
Wir benutzen aber
Big Data Tools
Und die Definition ist, there are of big data
start when the human caused of making the decision of throughing something data away,
became higher then the Machine cause of continuume to start.
Also heißt, dass in dem Moment Big Data wirklich losging,
als in dem Moment, als die Kosten,
die man dafür verbraucht hat, dass ein Mensch entscheiden musste,
ob wir die Daten behalten oder nicht, höher geworden sind,
als die Kosten, die einfach zu speichern.
Und ein gutes Beispiel dafür, werde ich auch gleich nochmal drauf eingehen,
ist Amazon S3. Das ist so ein allgemeiner Data-Dump,
Dropbox, Instagram, alle Online-Dienste, die ihr so kennt,
basieren theoretisch auf Amazon Webservices und nutzen dieses S3 als Big Data Storage.
Aber werde ich gleich nochmal ein bisschen näher
Zu erzählen. Für uns konkret oder für mich
in meiner Berufserfahrung war zum Beispiel das Festhalten von Logfiles,
dass man die plötzlich einfach gespeichert hat und nicht irgendwie nach
drei Monaten wegrotiert hat und weggeschmissen hat oder so.
Das war zum Beispiel mein persönlicher Big Data-Moment. Wo haben wir
die gespeichert? S3. Jo. Einmal weiter nochmal bitte. Zweiter Bass-Term,
Data Science, dass das Zusammenkommen von Hacking-Skills, also von Programmierskills,
Math and Statistic Knowledge, sowie substantiver Expertise in einer Industrie,
also sagen wir zur Sandhandel, Logistik, was auch immer.
Und wenn diese drei Themen zusammenkommen, dann spricht man davon,
dass da ein Data Scientist steht, Sitz liegt,
was auch Auf jeden Fall klassische Data-Science-Produkte sind,
wenn sie zum Beispiel oder wenn ihr zum Beispiel AB-Tests oder Hypothesentests in eurem Unternehmen macht,
um festzustellen, ob eine bestimmte Maßnahme kausal auf eine KPI einzahlt oder nicht.
Anderes Thema sind zum Beispiel die Empfehlungen von Amazon oder LinkedIn,
wenn es darum geht, neue Mitglieder oder Jobs zu empfehlen.
Das sind so klassische Data-Science-Produkte basieren, eben häufig auf Big Data-Technologien.
Ich habe ein paar mehr Slides, insofern das,
du hast mehr zu tun als ich eben bei dir.
Ich möchte euch ganz kurz zwei Cases, schön Neudeutsch sagt, darstellen.
Einmal so ein Big Data Case und einen Data Science Case von Jim Doo
und dann noch so ein paar Big Data Duos and Don'ts mitgeben.
Die sind teilweise ein bisschen populistisch, also seht's mir nach,
aber Big Data ist auch eben auch ein populistisches Thema.
Okay, gehen wir los. Ganz kurz zu Jim Doo,
ich weiß nicht, kennt ihr alle Jim Doo,
kann ich mir das Slide sparen?
Einmal ganz kurz, Händehof, wer Jim Doo kennt?
Joa, das sind alle, okay. Das hier ist eigentlich
das wichtigste Thema. Wir sind Bootstrapped und unsere drei Gründer
sind verrückt genug, irgendwie riesige Summen an BC-Kapital auszuschlagen,
zu sagen, nee, wir machen das selber.
Und wenn man selber sagt so, ja, aber dann könnten wir das,
nee, nee, nee, wir machen das selber.
Und genau das ist das Ding, was Bei Jimdo,
auch so ein Präzedenzfall eigentlich dafür ist,
warum wir jetzt zum Beispiel nicht sagen können, okay,
wir setzen uns zusammen mit SAP oder Oracle und machen das Big Data-Projekt.
Das ist meiner Meinung nach sowieso irgendwie nicht so zielführend.
Aber wir sind beide im Aufbau unseres, ja, unserer Dateninfrastruktur sehr schrittweise vorgegangen.
Und was uns dabei auch sehr stark geholfen hat,
waren eben diese Möglichkeiten, Astrid hat es eben schon gesagt,
in der Cloud wirklich nur zu variablen Kosten, Server anzumieten.
Gar keine Fixkosten mehr zu haben, was das Servermanagement betrifft
oder die Infrastruktur, sondern alles variabel zu bieten.
Gehe ich, glaube ich, jetzt direkt auch noch weiter
darauf ein. Kannst du auch mal weitermachen?
Genau,
Jimdo Lockfall-Analyse
Wie auch immer. Hätte ich das gewusst, hätte ich mir diese Titelslide gespart,
dann hätten wir... Ich wäre ein bisschen effizienter gewesen.
Auf jeden Fall, Jim, du, wenn ihr eine Gymdo seid,
startet auf dem Content-Management-Server von Jimdo, dann werden da Logfiles geschrieben.
Logfiles werden, glaube ich, für, wie meistens es
bekannt werden, immer geschrieben. Wenn ihr auf spiegel.de geht,
wird auf dem Web-Server irgendwo einen Logfile-Eintrag geschrieben mit eurer IP,
die ihr gerade habt, mit dem User Agent,
mit den ganzen Informationen, so einem Browser etc.,
zumindest generell ist es so.
Also bei uns, wenn ihr eine Webseite kreiert,
dann wird vom CMS-Server aus so ein Logfile geschrieben.
Und Informationen, die da für uns zum Beispiel festgehalten werden,
die relativ wertvoll sind,
sind welche Design-Templates
ein User
ausgewählt hat
Wenn dann User seine Seite sozusagen publishen möchte,
dann die Seite selber wird noch in der MaioSGL abgespeichert,
aber das ändern wir auch hoffentlich bald,
dann wird sie gepublished auf dem Webserver,
wo dann sozusagen diese Gymnu-Seite zur freien Verfügung von allen Internetnutzern steht.
Und da werden natürlich auch wieder Lock-Files geschrieben. Das heißt,
wir sehen eben die Nutzer oder die Visitor unserer User,
unserer Kunden, wie die sich verhalten. Nochmal nächstes. Genau,
das ist so ein, ja, so ein Lock-File,
wo eben dann die IPs stehen und welcher Host besucht wurde,
zu welcher Zeit etc.,
sieht erstmal total langweilig aus und vor allen Dingen
auch nicht unbedingt geeignet,
um es in eine SQL-Datenbank
zu schreiben
Für die die SQL-Datenbank kennen, die würden mir vielleicht zustimmen, vielleicht aber auch nicht.
Also man kann es mit SQL machen, klar,
aber es gibt mittlerweile wirklich effizientere Möglichkeiten, das zu betreiben. Kannst du noch einmal tun. Und zwar,
Map Reduce haben wir ja eben schon gehört,
für mich eigentlich die Technologie, die Big Data so groß gemacht hat,
mittlerweile so ein bisschen veraltet in die Jahre gekommen,
ich habe gerade gehört, für die es interessiert, Mahood,
das sind so ein Java-Framework zum Data Science oder Machine Learning,
die werden jetzt nicht mehr weiter auf Map Reduce bauen,
sondern auf Patchy Spark, aber nur für die Experten,
die das jetzt wirklich interessieren.
Auf jeden Fall kann man jetzt so einen Logfall nehmen und
es aufteilen und es auf verschiedene Workout- oder Slave-Notes verteilen.
Und das ist eigentlich relativ, also da wären wirklich,
ich weiß nicht, die ersten zehn Zahlen oder die ersten
zehn Millionen Zahlen werden dann auf den Not ganz oben geschoben und so weiter.
Und das ist die Map-Phase. Dann können da zum Beispiel
für eine Website, die an User sozusagen erstellt hat,
können dann, ja, Berechnungen durchgeführt werden,
beispielsweise wie viel Request gab es für diese Seite.
Und das wird parallel gemacht auf diesen Workout-Notes. Das heißt,
es sind nicht mehr abhängig davon, also es ist,
es wird ein stark parallelisierbares Problem und ich kann es eigentlich
mit Rechenpower totschlagen.
Das ist eigentlich so
Ganz kurz zusammengefasst, die Power, die hinter Matt Reduce steht.
Dann wird in der Reduce-Phase teilweise auf denselben Servern,
die es vorberechnet haben, werden die Daten wieder zusammengefasst,
sodass ich am Ende als Analyst oder Data Scientist meine Ergebnisse habe, zum Beispiel,
wie viele Visits habe ich aus einem bestimmten Land für eine IP?
Genau, und wir machen das zum Beispiel so für dieses Problem,
haben wir keine festen Server,
wir lassen da eine Stunde lang ungefähr 20 Amazon-Cluster laufen,
lassen diesen Matt Reduce-Prozess laufen und schalten die danach wieder ab.
Das heißt, wir zahlen wirklich nur für die eine Stunde,
also dann mal 20,
aber wir zahlen nur für diese eine Stunde
wirklich dann Serverkapazitäten
Und das ist wirklich, also für so ein Unternehmen wie Jimno oder
wahrscheinlich dann auch andere kleine und mittelständische Unternehmen, ist das ein super,
super Vorteil, diese Serverkapazitäten so flexibel anbieten zu können.
Ja, Spam-Modeling, das ist jetzt mehr aus der Data-Science-Ecke,
so ein bisschen weg von den reinen Technologie-Themen, wenn man den Usern ermöglicht,
Webseiten zu erstellen und die im Internet zu publishen,
könnt ihr euch vorstellen, was dabei auch für Kram bei rumkommt,
Drogen, Sex, Porn, alles Mögliche, illegaler Content,
die man eigentlich nicht haben möchte.
Ein weiteres Problem, was wir haben, sind Spam-Seiten,
die gar nicht so in erster Linie gleich als Spam zu erkennen sind,
das geht da so um Google Rankings pushen.
Da werden ganz viele von so Spamern, werden ganz viele Seiten kreiert,
die dann am Ende auf eine Seite zeigen,
die vom Google Panage Rank her stark gepusht werden soll.
Eigentlich nicht so wirklich schlimm. Sollen die doch da machen,
was sie wollen? Google wird das sowieso irgendwann erledigen,
aber es beraubt uns halt unser Server-Kapazitäten. Erstens und zweitens
verdirbt es halt so ein bisschen unsere Kennzahlen. Also wir wissen,
wenn wir das nicht identifizieren würden, wissen nicht,
wie viele Seiten wir tatsächlich in welchen Monaten gewonnen hätten.
Und so ein Klassification-Tree, das ist so ein klassisches Data-Mining oder
Machine Learning, eine Methode, die man anwenden kann.
Da geht man halt so von oben nach unten in diesen Baum
nach unten in die Blattknoten und oben zum Beispiel ganz oben ist die Frage,
wie viele andere Webseiten sind schon von diesem IP-Blog passiert?
Also von dieser IP, wie viele Webseiten wurden da schon
auf Jimdo kreiert? Und je nachdem, wie die Entscheidung,
also hier ist es, wenn es mehr als 64 Seiten sind,
dann deutet es eher auf Spam hirn.
Dann geht es in den rechten Teil des Baumes.
Dann die zweite Frage, die dann,
also die würden nicht von Menschen entschieden,
sondern eben von den Computern, Machine Learning eben,
wie viel mal wurde ein Blogmodul hinzugefügt
Wenn dann eine Webseite, für die es zu entscheiden gilt,
wie hoch der Spam-Faktor ist, durch den Baum rattert,
dann landet sie zum Beispiel ganz unten im Blattknoten und da steht dann zum Beispiel,
dass die Wahrscheinlichkeit, dass diese bestimmte Webseite jetzt Spam ist,
zum Beispiel 98 Prozent ist.
Und dann können wir halt hingehen,
die entweder automatisch blocken oder wir haben so ein Tool entwickelt,
wo unsere Supporter, weil automatisch Webseiten wegblocken,
könnt ihr euch vorstellen, das sind ja nur Wahrscheinlichkeiten,
das kann auch in die Hose gehen.
Vor allen Dingen, wenn es eine Seite ist,
für die immer Geld bezahlt,
die können wir nicht automatisch runterholen oder aus dem Netz holen.
Insofern zeigen wir dann unseren Kollegen eben an im Support,
hier, das sind die Wahrscheinlichkeiten,
die dieser Baum oder Wir benutzen halt eine Reihe von Boring Random Forest,
nennt man das dann.
Habt ihr nochmal ein Buzzword, was ihr mit nach Hause nehmen könnt?
Also Random Forest, Machine Learning, der Shit momentan.
Deep Learning und Random Forest, wenn ihr irgendwas heute Abend
noch erzählen wollt, Deep Learning, Random Forest.
Deep Learning sogar noch ein bisschen mehr,
aber da weiß niemand so richtig, wie es funktioniert.
Random Forest und Deep Learning. Wir machen Random Forest.
So. Ja, viele Seiten, also da wird zum Beispiel
angezeigt, aus welchem Land diese Seite kreiert wurde.
Da haben wir auch so klassische Zielländer, die sehr spendträchtig
Ja, und dann können unsere Kollegen ankreuzen oder anklicken,
was es denn tatsächlich ist, ob es wirklich Spam ist,
ob es Phishing ist auch ein Riesenproblem für uns,
ob es Porn ist, das ist eigentlich,
ja, ja, kein Problem,
aber solange der Inhalt nicht zu schmutzig ist.
Und dann nur Spam oder kein Tell.
Und das fließt wieder zurück in unsere Machine Learning-Algorithmen,
um eben, ja, die Systeme weiter zu verbessern.
So, kommen wir zu den Do's and Don'ts.
Jetzt kommen nur noch Bilder, nur noch Bilder.
Naja, fast. Also, aber nichts mehr,
das war so der schwerste Part eigentlich, dieser Classification Tree.
Google Flue Trans, eines der Vorzeigedata oder Big Data,
Big Data,
Big Data-Projekte
Kribbeltrends analysieren. Die haben es,
also die kennt wahrscheinlich alle die Story, das hieß super toll geschafft haben,
auf Basis der Suchanfragen, die User stellen, vorherzusagen,
wie viel Grippeinfizierte es denn in welchem Land gibt,
in welchem Bundesland sogar für Deutschland.
Also die gehen sehr, ja, können halt alle Daten nutzen,
die sie halt haben, inklusive der Geokudierung.
Das hat auch ein paar Jahre sehr gut funktioniert,
dass News oder Nature News hat darüber sogar einen Artikel gepublished,
das ist so ein Scientific Journal,
bis es dann irgendwann nicht mehr funktioniert hat
Und das ist eigentlich so,
dann haben dann viele Gegner von Big Data gesagt,
ah, das taugt doch alles nicht,
so dieses Ganze von wegen, if you have anoth data,
the number speak for yourself is bullshit und so.
Ist natürlich auch Quatsch, aber es zeigt halt einfach die Grenzen
auf von Big Data. Weil die Jungs haben halt einfach
eine Kolation dargestellt und damit ist es besser vorhersagen können,
wie viel Grippeinfizierte es denn in bestimmten Ländern gibt, als die Weltgesundheitsorganisation selber.
Wie gesagt, das hat bis vor ein paar Jahren
auch echt noch gut funktioniert. Dann gab es wohl,
ja, gab es wohl den Fall,
dass in den USA so Dezember 2012 wahnsinnig viel in der Presse
über Grippe berichtet und dadurch Leute einfach mehr gesucht haben,
ohne dass sie wirklich grippelinfiziert waren.
Das konnte der Algorithmus halt nicht so gut antizipieren oder das Modell,
was die aufgestellt haben, die Google Scientist.
Und ein zweites Ding war wohl, dass Google selber
ihren Suchalgorithmus so ein bisschen getuned haben. Und dann,
wenn jemand nach Symptomen wie, weiß nicht,
Running Knows oder Halsschmerzen gesucht hat, automatisch gleich Grippe,
Diagnosen vorgeschlagen haben, die Leute dann wahrscheinlich wieder nochmal gesucht haben.
Also ist aber für mich ein gutes Beispiel,
wie schnell Leute eben drauf rumreiten können,
sodass Big Data doch nicht funktioniert oder die Grenzen nicht genau kennen.
Genauso wie das Nächste, wenn sie auf Amazon,
das ist wirklich ein Beispiel, das habe ich selber Gestern,
vorgestern noch rausgesucht, wenn sie noch Baseballschläger suchen,
kriegen sie eben auch die Sturmhaube, den Teleskopschlagstock,
das K.O.-Pfefferspray und den Fighter-Anhänger.
Alles ist das, was man für einen schönen Samstag-Fußballnachmittag braucht.
Das ist halt auch Big Data. Amazon interessiert das
einen Shit, ob das politisch korrekt ist oder nicht.
Die machen damit Geld. Genau mit diesen Vorschlägen. Da
sitzt keiner mehr, der ist kuratiert und sagt so,
ey, das geht nicht, das können wir nicht machen.
Den Schritt muss man auch bereit sein, zu gehen.
Als wir bei Xing die Job-Recommendations entwickelt haben, saß da
auch der Vorstand Ich kriege hier gar keine Jobs empfohlen und etc.
Das war halt, weil der Input einfach auch nicht da war.
Also man muss dann konsequent sagen, so wir gehen weg davon,
Sachen manuell zu kuratieren, sondern trauen so ein bisschen den Algorithmen.
Solange sie Geld machen, solange sie effizient sind.
Das muss man natürlich immer noch überprüfen. Okay. So,
jetzt kommen wirklich nur noch einfache Bilder. Also wenn man,
wenn man, wenn man quasi alle Daten zur Verfügung hat,
weil man Twitter meint oder Facebook und irgendwelche Dienstleister hat,
die einen alle Daten zur Verfügung stellen,
dann kommt es eigentlich nicht mehr so darauf an,
ob man eine Antwort zu der Frage findet,
sondern welche Fragen man stellt
Bei Jimdo zum Beispiel haben wir uns sehr stark darauf konzentriert,
am Anfang herauszufinden,
warum denn User von den freien Mitgliedschaften zur Pro- oder Business-Mitgliedschaft wechseln,
um mehr Geld zu machen, klar.
Und das war eigentlich nicht die richtige Fragestellung. Wir haben dann später herausgefunden,
dass es eigentlich wichtiger gewesen wäre, zu fragen,
warum werden denn User aktiv und beschäftigen sich regelmäßig mit ihrer Webseite?
Weil wenn sie das machen, wenn sie das geschafft haben,
dann werden sie auch automatisch irgendwann zu käufern und generieren Revenue.
Also sieht man, was halt schnell passieren kann bei diesen
ganzen supermächtigen Tools und Algorithmen etc., dass sie mit dieser Macht,
die sie plötzlich haben, Die voll falschen Fragen beantworten.
Und wir hätten fast das superduper Conversion-Modell entwickelt,
ohne dass wir uns auf die eigentlich wirklich richtige Frage konzentriert hätten,
was sie unterscheidet.
Oder warum werden denn User wirklich aktive User,
die sich regelmäßig und nachhaltig mit ihrer Seite beschäftigen?
Dann versuchen Sie bitte Schritt für Schritt vorzugehen.
Suchen Sie sich ein Problem, was in Ihrem Unternehmen wirklich brennt,
so wie bei uns, war das eben dieses Conversion-Problem.
Und versuchen Sie nicht gleich so das Framework zu bauen,
um all Ihre theoretischen Big Data-Fragen der nächsten zehn Jahre
zu beantworten.
Das geht meistens in die Box
Ich weiß, von einem großen E-Commerce-Anbieter in Hamburg,
dass die jetzt gerade das Super-Duper-Recommendation-System bauen wollen auf Basis von Storm,
das ist auch so eine neue Real-Time-Technologie,
kann sich auch merken, Storm, ganz Apachy-Storm.
Nee, Quatsch, nicht Apachy, aber Storm,
das ist halt auch so ein bisschen, das kann,
dass am Ende des Tages werden die wahrscheinlich da ein Recommenda-System haben,
was auch ganz cool funktionieren wird.
Aber die werden vermutlich viel länger brauchen,
als wenn sie prototypisch vorgehen und versuchen,
ein Stück für Stück halt Mehrwerte zu generieren.
Ja, unterliegen sie nicht dieser Wahnvorstellung,
dass sie irgendwann, dass die Big Data-Architektur haben,
wo sie nur noch so ab und an
ein paar Schalter drehen müssen und alles wird gut.
Das klappt meiner Meinung nach nicht
Stattdessen, und ich kriege da kein Geld für,
ein bisschen Werbung für Amazon Web Services, die sind echt Meister darin,
einfache Tools anzubieten und wirklich quasi quarterlich neue Systeme rauszuhauen, die perfekt miteinander integriert sind.
Das heißt, wenn sie jetzt anfangen,
all ihre Daten einfach erstmal in eine S3 reinzuballern,
und das ist jetzt wahrscheinlich ein bisschen populistisch,
vielleicht werde ich dafür auch gleich noch zerrissen,
aber wenn sie jetzt anfangen, Daten,
die sie noch nicht wegschmeißen wollen,
weil sie denken, da könnte irgendwie was Wertvolles drinstecken,
wenn sie die jetzt anfangen in eine S3 reinzuballern und dann in einem halben Jahr jemanden einstellen,
der sich vielleicht mit Elastic Merpeduce rauskennt,
dann machen sie auf jeden Fall nichts falsch.
Und sie können diese Tools, wunderbar miteinander verbinden.
Chinesis ist so ein neues Realtime-Analytics-Tool, was Amazon anbietet.
Haben wir leider noch nicht ausprobiert, aber sehr vielversprechend.
Man bindet sich natürlich auch an Amazon.
Ganz klar. Also die Kosten oder beziehungsweise die Opportunitätskosten,
dass sie halt nur noch variable Kosten haben, theoretisch,
sind natürlich die extreme Bindung, die sie an Amazon dann haben.
Aber die senken die Preise ja ständig.
Das kann ja nicht schief gehen. Ja,
aber als Tipp kann man da, glaube ich,
viel richtig machen,
wenn man da aufsetzt
Dann bitte verfallen Sie nicht irgendwelchen Dogmatismen, von wegen No-OS-Goal,
no-SPOL vs. SQL, hier No-OS-Goal durch Luke Skywalker dargestellt,
der die böse Darth Raider, SQL-Front,
Larry Allison und wie sie alle heißen, diese bösen Kapitalisten schlägt.
Das ist natürlich auch totaler Quatsch,
meiner Meinung nach und völlig unprofessionell jetzt zu sagen, ja,
SQL ist sowas von gestern, das funktioniert alles nicht.
Ich bin ziemlich sicher, dass ungefähr, naja,
nee, ich sag's lieber nicht. Aber ich glaube,
dass, naja doch, also ich bin mir ziemlich sicher,
dass noch so das meiste,
was aus Daten an Mehrwerten erwirtschaftet wird
Für mich aus dem Fenster lehnen und sagen,
es sind locker über 60 Prozent,
die noch ganz auf klassischen SOL-Technologien basieren.
Nutzen Sie einfach das, was aus den Technologien passt?
Und ohne zu sehr zu sagen, ja, wir machen nur SUL.
Wenn es SQL ist, dann ist es auch fein.
Amazon hat zum Beispiel mit Redshift ein super performantes Data Warehouse
aufgebaut und raten Sie mal, was da für das Interface ist.
Postgress SQL, Standard Esquell.
Einmal nochmal weiter, bitte
Ja, ich weiß nicht, ob man das erkennen kann,
aber auch für sowas würde ich echt zur Vorsicht raten, den Back-Data-Bass von SAP.
Wenn sie den sehen, rennen sie am besten schnell weg.
Nicht einsteigen. Ich weiß nicht, der hat nicht mal
Fenster. Keine Ahnung, was da drin passiert.
Ja. Ja, bitte. Dann, ja,
wie schon gesagt, Storm, jetzt gibt es Spark,
es gibt so viele Buzzwords und man hat das Gefühl,
shit, pick und matt reduce, das ist doch alles schon wieder von vorgestern.
Mein Gott, und das habe ich jetzt gerade erst begriffen,
mache ich danach weiter. Also bitte verfallen Sie nicht diesen Wahn,
jeder neuesten Technologie hinterherrennen zu müssen und die auch ausprobieren zu müssen.
Ja, einfach da nochmal der Tipp zu. Dann,
ja, das ist Jimdo, das bin ich.
Und das ist ironisch gemeint. Das ist nicht, also wenn Sie,
ja, plötzlich Daten im Zugriff haben für das Unternehmen,
wenn Sie ein Data-Team aufbauen oder die ersten Steps machen,
gibt es plötzlich ganz viele Erwartungen.
Sie sehen die Gesichter von den drei Gründern auch vorne,
wie erwartungsvoll die alle an diese Daten wollen und wollen plötzlich wissen,
wie viele neue User haben wir denn in Warschauen,
wie viel denn in Brasilien, St. Paulo,
da habe ich gerade letztens irgendwie ein Training gemacht etc.
Also ganz viele Ad-hoc-Rates, die auf sie einen prasseln, einschlagen quasi.
Und sie sind quasi der Zuhälter von den Daten.
Das ist total ein total mieser Job, weil sie wissen,
das ist super wertvoll, aber ich kann ihn nicht,
ich kann nicht jede Fragestellung beantworten.
Deswegen, und sie sind in dieser Rolle des kleinen Datenprinzen,
der da wirklich einfach irgendwie darauf reagiert und plötzlich ganz viel Macht hat,
versuchen sie sowas auf jeden Fall zu vermeiden.
Deswegen einmal weiter keine Datenprinzen. Stattdessen, was wir machen bei Jimdo,
ist, dass wir jedem Kollegen theoretisch anbieten,
auch in unser Data Ware auszugehen.
Klingt ein bisschen verrückt, aber das dürfen die auch erst,
nachdem sie SQL-Schulung gemacht haben.
Das ist recht erfolgreich und dann freuen die sich natürlich
Weil wir sind, Jim Du ist natürlich auch so ein bisschen eine Hippie-Company.
Ich meine, hier sehen Sie die Unterhosen unserer drei Gründer.
Der Hund guckt auch schon ein bisschen komisch.
Aber ja, das ist eigentlich so mein Tipp.
Versuchen Sie die Daten, die sind Datenschatz,
nicht durch zwei, drei oder vier Mann-Teams heben zu lassen,
sondern möglichst vielen Leuten Zugriff auf diese Daten zu gehen.
Also sowas wie Datendemokratie zu schaffen. Ja, ich glaube,
nochmal ein nächstes Line. Genau, das sind meine Kontaktdaten.
Also sehr gerne, wenn Sie irgendwie jetzt Fragen haben.
Mensch, Moldwald hat das und das erzählt,
wie mache ich denn da jetzt weiter?
Können Sie
mich gerne kontaktieren
Das ist mein Blog, der heißt wirklich so.
Habe ich auch ein bisschen mehr zu diesem Data to the People und Datendemokratie erzählt.
Bitte, ich freue mich immer über Feedback.
Ich habe das Gefühl, man diskutiert viel zu wenig mit
normalen Menschen über dieses Big Data-Phänomen.
Insofern vielen lieben Dank. Ja, vielen Dank für die
erste Hälfte.
Gibt es noch Fragen?
Also, ja
Wir haben leider kein Mikro. Ich würde dich bitten,
laut zu sprechen, Entschuldigung. Würdest du aus deiner Erfahrung auch sagen,
also wie der Vortrag von Astet,
hört es sich ja so ein bisschen so an,
wie ich baue mir einfach als Deutsch-Cluster und der Zugriff auf die Daten.
Es passt genauso einfach, als hätte ich ein SQL-System.
Aber eine der Herausforderungen ein neues QL ist ja nun auch,
dass ich mir eigentlich für den Prozess und für den Zugriff
auch die Daten eigentlich in jedem Schritt überlegen muss,
was ist die richtige Technologie, weil ich wahrscheinlich am Ende nicht mit einer US-UL-Technologie übertreibe, sondern mehrere Dinge.
Ja, also man sollte sich darüber auf jeden Fall Gedanken machen,
Was ich super charmant fand,
als ich das erste Mal mit Amazon-Webservices in Kontakt gekommen bin,
das war, als wir bei der Online-Marketing-Agentur versucht haben,
ganz viele verschiedene Ad-Server-Daten und die Klicks und Impressions von verschiedenen Ad-Servern zusammenzududeln.
Und wir haben die Daten in der S3 gespielt und ja
, dann liegen die da halt erstmal in der S3.
Und das ist halt, man denkt, scheiße,
jetzt muss ich ein Java-Map-Reduce-Job schreiben, um herauszufinden,
wie viele Klicks es zum Beispiel an einem Tag gab.
Das ist Gott sei Dank, gibt es das Mody auch
so mit dieser Gegenbewegung zu Noah SQL.
Viele sagen ja auch nur, SQL heißt nicht not SQL,
sondern not only SQL
Zum Beispiel mit Half hat wieder so ein klassisches SQL-Interface,
womit man darauf zu, auf die Daten zugreifen könnte.
Dann gibt es, also es tut mir leid,
aber von Amazon, ich kenne leider keine einen oder anderen
Infrastrukturen und ich würde mir auch keinen eigenen Server irgendwo hinstellen.
Aber man kann zum Beispiel auch mit Empalla oder H-Base
relativ zügig auf diese Daten zugreifen.
Es ist natürlich was anderes, als sie einfach irgendwo
eine Mai SQL-Kiste hinzustellen und dann mit SQL drauf loszujockern.
Aber die, also die haben sich schon sehr viele Gedanken gemacht,
wie genau dieses Problem zu lösen ist.
Und ja, also mit diesen Elastic Map Reduce Jobs von
Amazon kann man eben diese Technologien nutzen.
Hat das das
ein bisschen beantwortet
Ja, es war mehr so,
dass man sich dem Prozess eigentlich viel stärker verrauchen fühlen muss,
als wenn ich nur eine SUL da anfangen kann,
auf der ich eigentlich alles machen kann.
Das dachte ich auch, ist aber viel weniger so,
als man es befürchtet. Also es gibt zum Beispiel von Hive
am Logfile zu analysieren. Gibt es so vorgefertigte Sörde-Dateien,
die vorgeben, wie diese Logfiles halt zu analysieren sind,
wie man herausfindet, ob es ein Mobile-Klein ist oder nicht?
Die muss man natürlich finden und mit irgendjemand sprechen,
der einen daran hinzugibt, aber dann kann man ganz normales SUL schreiben.
Also ich könnte es jetzt auch zeigen,
aber das SQL sieht relativ einfach raus.
Darüber, klar, das ist was anderes,
als wenn man jetzt ganz normal Majorscare benutzt,
aber es ist einfacher,
als man es befürchtet
Weil genau das halt die Hemmstelle ist,
sage ich mal, jetzt für den normalen Daten,
alle wissen, wie ich eigentlich auch einer bin,
jetzt mit diesem Mepree oder mit diesen Big Data-Technologien loszulegen,
weil man so schnell denkt, oh,
man muss da irgendwas ein Jahr war oder in irgendeiner Programmiersprache hacken,
obwohl man ja eigentlich SQL gewohnt ist.
Weitere Fragen? Fordern wir. Ist 20 Uhr,
ich würde sagen,
wir machen 20 Minuten