Anwendungsfälle für Stream Processing und Streaming Analytics in der Ära von Big Data und Hadoop
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 11 | |
| 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 | 10.5446/43603 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
data2day 201511 / 11
8
10
00:00
SPARK <Programmiersprache>Streaming mediaRollbewegungLösung <Mathematik>AlgorithmMathematicianTape driveStreaming mediaComputer animationLecture/Conference
00:43
Processing <Programmiersprache>Component-based software engineeringSun <Marke>Abstract machinemakeExpandierender GraphProcess capability indexMenu (computing)World Wide WebGame theoryOptical character recognitionArtificial neural networkOvoidVRMLStreaming mediaSource codeRCSDigital object identifierSchaleSPARK <Programmiersprache>Apache <Programm>IBMSQLExact sequencePOWER <Computerarchitektur>Computing platformTape driveComputer programmingNewton's law of universal gravitationDesktopLoop (music)DemosceneUser interfaceTypHTMLComputer musicMilan <Programmiersprache>Product (category theory)Concurrency (computer science)CodeScientific modellingSystems <München>InformationPoint (geometry)Apache <Programm>Point cloudService (economics)SPARK <Programmiersprache>StatisticsNewsletterSoftware frameworkMachine learningMATLABOpen sourceTape driveSoftwareReal-time operating systemLink (knot theory)DatabaseAlgebraic closureComponent-based software engineeringAtomic nucleusTwitterEchtzeitverarbeitungFocus (optics)Data warehouseProcessing <Programmiersprache>Streaming mediaInterface (computing)CONSULTANT <Datenbank>Direction (geometry)DemosceneSimilarity (geometry)SmartphoneZusammenhang <Mathematik>Source codeLinieServer (computing)Lösung <Mathematik>Mobile appHöheCASSet (mathematics)Internet der DingePattern languageoutputWeb serviceAPIEvent horizonAlgorithmProof theoryWeb pageGoogleSocial classStrich <Typographie>Moment (mathematics)Probability theoryPayPalOperatorEckeBIND <Programm>LaptopProcess (computing)InternetFacebookImplementationExplosionStandard deviationDecision theoryCorrelation and dependenceAutomationVERKAUF <Programm>Digital filterBALL <Programm>Enterprise Service BusKonnektorEnterprise architectureExecution unitSoftware developerParticle detectorWeb browserMetreStatistisches ModellTime zoneVibrationMaxima and minimaPlane (geometry)Spring (hydrology)Form (programming)Stack (abstract data type)Route of administrationOrder (biology)CalculationLibrary (computing)CASHENumberData conversionFünfzigMusical ensembleStrutDrum memoryRAMAbteilungFactorizationPower (physics)QuoteVertex <Computergraphik>Physical quantityInterface (computing)Data modelOperator (mathematics)LengthElectronic data processingCodeQuery languageGRADEMotion (physics)Row (database)Abstract machineSingle sign-onArmMultitier architectureApple <Marke>Google MapsPer milRepresentational state transferInfinityRivenEigenvalues and eigenvectorsForced inductionPhysical lawHand fanBlock (periodic table)Single-precision floating-point formatComputer animation
Transcript: German(auto-generated)
00:07
Vielen Dank, herzlich willkommen. Also keine Sorge, es ist kein Product Pitch. Ich zeige natürlich schon einige Use Cases, wie wir es bei Kunden umsetzen, aber es ist jetzt wirklich völlig produktunabhängig und passt auch ganz gut zu dem Vortrag von gerade. Ich habe zwar von den ganzen Algorithmen, die er gezeigt hat, Formeln, kein Wort verstanden, aber ich zeige trotzdem,
00:23
wie wir es bei uns einbinden. Das ist das coole dran und das zeigt eben auch, wie sinnvoll es ist, manchmal die Rollen zu trennen und dass es eben immer relevanter auch wird, solche Themen wie Data Scientist, die es gibt als Mathematiker und wie man dann denen Lösungen auch in die unsere Welt quasi oder meine Welt mit einbinden kann. Genau, deswegen
00:42
fange ich hier im Prinzip gleich an. Thema ist, wie der Kollege gerade gesagt hat, Stream Processing. Was möchte ich heute mitgeben? Es sind im Prinzip drei Themen. Streaming Analytics oder Stream Processing ist mehr oder weniger ein Synonym füreinander, je nachdem wen man fragt, ob man zum Analysten geht. So Gardner, Forrester, die sagen mehr Streaming Analytics. Im Entwicklungsumfeld, im Java-Umfeld heißt es
01:01
Stream Processing. Spielt im Prinzip keine Rolle, es geht einfach darum, Daten in Echtzeit schnell zu verarbeiten, während sie eben noch in Bewegung sind. Das ist ganz wichtig, der Kern hier, while it is in motion. Während die Daten fließen, muss man sie verarbeiten und nicht erst, wenn sie schon in der Datenbank sind und veraltet sind. Was auch ganz wichtig ist, wenn wir bei einigen der Anwendungsfälle auch
01:21
sehen, Streaming Analytics geht zwar in erster Linie natürlich um Automatisierung, weil es um sehr, sehr viele große Datenmengen geht, aber trotzdem ist oftmals trotzdem noch Mensch benötigt. Was andererseits auch wieder gut ist für uns, wir werden nicht unnötig und auch das wird man eben in einigen Beispielen mal sehen. Und was wir von sehr vielen Kunden sehen einfach ist das Thema, dass wirklich im Prinzip Change is the only
01:45
constant. Also es ändert sich die ganze Zeit und deswegen muss man eben schnell auf Anforderungen reagieren können. Also es geht nicht nur initialen Projekt aufsetzen, sondern schnell Themen auch ändern. Und das ist eben so ein wichtiger Punkt, den wir auch in dem Umfeld unheimlich oft sehen und auch da werde ich im Detail darauf eingehen.
02:02
Deswegen sehen wir jetzt hier die Agenda. Ich habe insbesondere am Anfang ein paar verschiedene Anwendungsszenarien von verschiedenen Kunden aus verschiedenen Branchen, wo wir dieses Thema Streaming Analytics einsetzen. Dann ganz kurz eine einführende technische Sicht. Was ist Stream Processing eigentlich? Und dann Fokus im Prinzip wirklich am Marktüberblick. Was gibt es da so an Open Source Frameworks,
02:22
an kommerziellen Herstellern? Wie spielt das Ganze zusammen? Wie setze ich ein Projekt auch wirklich um? Und dann der letzte Punkt eben auch, wie hängt das Ganze mit anderen Technologien und Lösungen zusammen? Zum Beispiel Apache Adub oder auch Machine Learning, wie wir gerade gesehen haben von Amazon oder mit irgendwie R oder Matlab oder was auch immer man verwendet, spielt im Prinzip keine Rolle. Und diese ganzen Zusammenhänge
02:43
ist dann der letzte Punkt, den ich dann darstellen werde, sowohl aus technologischer Sicht, aber dann auch nochmal an einem eigenen Anwendungsbeispiel, an einem Real World Use Case quasi. Erster Punkt ist trotzdem jetzt erstmal einfach ein Überblick ohne Blick tief auf die Technologie. Was machen wir so bei verschiedenen Kunden? Und im Kern geht es wirklich bei diesem Thema Streaming Analytics immer drum. Hier oben
03:04
steht jetzt Find and Act on Critical Business Moments. Also wirklich, solange es noch relevant ist, zu reagieren oder oft auchmals proaktiv zu agieren, bevor etwas passiert. Also wenn Betrug bereits passiert ist, ist es zu spät zu reagieren. Oder wenn der Kunde bereits aus dem Laden raus ist, kann ich ihm nicht noch
03:20
was verkaufen, weil dann ist er schon gegangen. Das sind einfach so viele Beispiele aus allen verschiedenen Branchen, wo das Thema relevant ist, wo man wirklich in Echtzeit reagieren muss oder vielleicht innerhalb von einer Sekunde oder zwei oder drei Sekunden. Aber wo dann selbst zehn Minuten oftmals schon zu spät sein können. Das ist einfach der Fokus von diesem ganzen Thema Streaming Analytics, ist eben in Echtzeit zu reagieren und eben nicht erst wenn es zu spät ist. Also quasi
03:43
dieses Thema von früher, Batch Processing. Ich schreibe es erst in die Datenbank und dann lasse ich meine Reports drüber laufen und vielleicht auch erst über Nacht über ETL Prozesse oder ähnliches, sondern ich möchte eben sofort reagieren. Ich habe es am Anfang gesagt, kein Thema ist im Prinzip in der Regel natürlich schon dieses Maschine zu Maschine Automation, also viele Sachen automatisieren. Anders geht es
04:02
nicht, weil dafür geht es um viel zu viele Millionen von Events. Also wir haben jetzt zum Beispiel eine Messaging-Lösung, die kann wirklich im Telco-Bereich und Finance-Bereich sechs Millionen Nachrichten pro Sekunde verarbeiten. Das muss man sich mal vorstellen. Sechs Millionen Nachrichten pro Sekunde. Da kann man natürlich keine Menschen hinsetzen, die das verarbeiten. Aber auf der anderen Seite gibt es eben
04:21
trotzdem sehr, sehr viele Anwendungsfälle, wo trotzdem noch ein Mensch drüber schauen sollte. Zwar nur dann über vielleicht 100 von diesen Millionen Events, aber über die Relevanten, wo man dann die Entscheidungen treffen muss. Weil wir auch gleich im Beispiel noch ein bisschen sehen, was das dann konkret bedeutet. Aber wichtig ist eben wirklich, es geht hauptsächlich um Automatisierung natürlich, aber oftmals ist eben trotzdem noch ein Mensch benötigt. Ich habe jetzt ein paar verschiedene Use
04:44
cases. Erstes Thema hört man immer mehrst, genau wie auch gerade bei diesem Amazon-Vortrag, so dieses Thema Predictive. Also quasi mit einer Wahrscheinlichkeit in die Zukunft schauen. Und das Beispiel, das ich jetzt hier habe, ist mehr aus der Industrie, geht es um Predictive Fault Management. Und letztendlich geht es hier darum, dass
05:01
Kunden bestimmte Teile schon austauschen, bevor sie kaputt gehen. In diesem Beispiel sieht man jetzt hier, das ist bei einer Ölplattform. Da steht jetzt auch hier, ein Ausfall kostet ungefähr 10 Millionen US-Dollar und es gab ungefähr 20 bis 100 Ausfälle pro Jahr. Also kann man sich vorstellen, was das für Kosten sind. Und was die jetzt mittlerweile machen, und eben genau mit diesem Thema Streaming Analytics,
05:23
sie analysieren eben Daten nicht erst, wenn sie schon passiert sind. Also wenn das Gerät explodiert ist, ist es zu spät, dann sind diese 10 Millionen Schaden da. Sondern sie analysieren diese Daten jetzt eben in Echtzeit. Also von diesen ganzen Bohrmaschinen und diesen verschiedenen Sensoren ist eben alles irgendwie angebunden ans Internet und jeder Sensor wird in Echtzeit analysiert. Und hier geht es wirklich dann um Millionen von
05:44
Sensordaten, die in Echtzeit analysiert und korreliert werden müssen. Sieht man jetzt hier an einem Beispiel, im Prinzip ist es jetzt eine ganz vereinfachte Form, aber hier haben wir jetzt im Prinzip drei verschiedene Sensoren. Wir haben Vibration, Temperature und Voltage. Und die senden konstant immer wieder neue Sensorinformationen raus. Und jetzt
06:03
haben wir hier oben dazu eine Regel definiert. If vibration spike is followed by a temp spike, then voltage spike within 12 minutes, then flag high severity alert. Das heißt also wir schauen uns immer irgendwelche Zeitfenster an. Und immer, wenn in diesem Zeitfenster dieses Pattern passiert, dass zuerst genau dieses Event passiert by vibration und
06:23
dann zwei Minuten später das und dann als drittes noch das Voltage und das Ganze in einem Zeitfenster von 12 Minuten in diesem Beispiel, dann schlag ein Alarm, weil dann ist die Wahrscheinlichkeit eben größer 80 Prozent, dass dieses Gerät bald explodieren wird. Und dann tauschen sie es eben lieber für 10.000 Euro vorher aus, auch wenn es vielleicht gar nicht explodieren wird. Aber die Wahrscheinlichkeit ist eben hoch
06:42
genug, dass sich das eben rechnet, weil eben später der Schaden sonst 10 Millionen wäre. Das ist so dieses Thema predictive analytics in diesem Beispiel jetzt an Voltmanagement. Aber gibt es viele andere Anwendungsfälle, wo man das benutzt. Aber hier ist eben auch nochmal wichtig, natürlich tauschen die nicht so einen Teil sofort aus, bloß weil dieser Alarm schlägt, weil es eben trotzdem erstmal nur eine Wahrscheinlichkeit
07:03
ist. Und deswegen gibt es zusätzlich zu dieser automatisierten Verarbeitung eben trotzdem noch eine Oberfläche, wo diese Events in Echtzeit auch reingepusht werden, sodass dann eben ein Operator diesen Alarm hier sieht, zum Beispiel hier jetzt oben ist dieses Rot. Und dann kann der anhand von diesen Informationen nochmal im Detail reinschauen und Entscheidungen
07:20
treffen. Tauschen wir dieses Teil jetzt wirklich aus oder ist es jetzt trotzdem irgendein anderer Grund, warum diese Wahrscheinlichkeit oder dieser Alarm losgeschlagen wurde. Genau dieses Thema werde ich nachher auch im Live-Thema mal zeigen, dass man sich mal vorstellen kann, wie das Ganze in Echt aussieht. Da komme ich dann im Ende des Vortrags dazu. Ein anderes Beispiel ist auch noch dieses Thema Internet of Things,
07:41
mit überall sind Sensoren dran, ist dieses Thema Manufacturing. Und da kann man sich auch viele viele verschiedene Industrien vorstellen, wo eben produziert wird. Und bei diesem Beispiel war es jetzt so, dass eben bloß irgendwelche ganz kleinen Teile aus irgendwelchen Stoffen erstellt werden, aber eben ein gewisser Teil dieser produzierten Teile kaputt ist. Und das sind eben nur ein paar Prozent, die abgestoßen werden, die man nachher
08:03
wegschmeißen muss. Und hier steht es jetzt auch für jedes ein Prozent, dass man diesen Prozess verbessern kann, macht man 11 Millionen Dollar mehr Profit. Also kann man sich auch wieder rechnen in Business Case, wie schnell sich sowas lohnt für ein Prozent mehr, das ich ausliefern kann und nicht wegschmeiß, verdiene ich 11 Millionen. Und auch hierfür machen die das auf die gleiche Weise, die haben das ganze eben über Sensoren angebunden
08:23
und überwachen eben dann in Echtzeit wirklich, das ist eben der Kern auch, diese ganzen verschiedenen Informationen, die sie reinbekommen und können dann in Echtzeit darauf reagieren und sehen zum Beispiel, hier schaut es jetzt schlecht aus für die Lieferung, die gerade produziert wird, hier ändern wir jetzt irgendwelche Faktoren, damit eben anders
08:41
produziert wird. Ich kann jetzt hier auch gar nicht weiter ins Detail gehen, ich kenne mich fachlich damit jetzt auch nicht aus, aber dieses Kernthema ist einfach dieses Yield Optimation, also wirklich diese Prozesse so optimieren, dass eben der Ausfall von diesen produzierten Einheiten geringer wird. Weil ich eben nicht erst am nächsten Tag oder in der nächsten Stunde schaue, was ist da schief gelaufen und was müssen wir alles wegschmeißen, sondern bevor die Teile produziert werden, kann man eben schon
09:03
erkennen mit einer großen Wahrscheinlichkeit, dass hier wahrscheinlich was schief laufen wird und kann dann eben proaktiv darauf reagieren. Das ist so die Grundidee dahinter. Aber was auch ganz wichtig ist, ist das Thema Streaming Analytics, das kommt natürlich in erster Linie bei so Themen Internet of Things, Manufacturing denkt man oft drüber nach oder alles,
09:21
wo eben so erstmal klassisch man denkt, da sind eigentlich Sensoren dabei, aber auch im Retailing Umfeld, wie wir es jetzt bei Amazon gesehen haben, gibt es immer mehr Bereiche, wo diese Sensoren und diese Streaming Analytics immer wichtiger wird. Und es geht eben auch nicht nur um diese Sensoren von Internet of Things, sondern um irgendwelche anderen Feeds, zum Beispiel die Twitter Feeds, die reinrasseln und eben analysiert werden müssen. Auch da
09:42
werden wir nachher noch ein Beispiel dazu sehen. Konkret jetzt zum Thema Retailing geht es einfach darum und es geht jetzt auch nicht nur auch bei Beispiel wie Amazon, die eben On Store, also zum Beispiel Media Markt oder Saturn in Deutschland ihre Geräte verkaufen
10:00
wollen. Und da ist ganz klar auch das Ziel, man muss einfach seinen Kunden auf der einen Seite kennen und sein Inventory, also was hat man auf Lager. Und nur wenn man diese Kombination hat in Echtzeit, dann kann man eben daraus den Mehrwert schaffen und dem Kunden letztendlich glücklicher machen und mehr verkaufen. Und wirklich hier heißt jetzt zum Beispiel den Kunden zu kennen, heißt jetzt eben zum Beispiel wirklich auch
10:22
zu wissen, wo er ist. Also dieses Thema Location Based Transparency. Wir haben Kunden am Flughafen, wenn die rumlaufen, dann wird eben analysiert, wo läuft der rum und empfehle ich dem jetzt lieber einen Starbucks Kaffee, weil ich eben weiß, in 10 Minuten oder in 10 Metern kommt er dort vorbei. Wenn er ganz woanders im Frankfurter Flughafen ist, dann brauche ich ihm das nicht empfehlen. Dann empfehle ich ihm irgendwas, wo dort irgendein Shop verfügbar ist als Beispiel. Also auch hier sehen wir einfach
10:42
diesen Trend, der immer weitergeht. Die Kunden haben immer mehr Geräte, mit denen sie online sind. Es ist nicht mehr nur der Webbrowser wie früher. Sie haben ihr Smartphone, ihr Tablet, ihre Uhr oder was auch in Zukunft alles kommen wird. Das ist alles verbunden und hinten dran natürlich genau die ganzen Systeme.
11:00
Und da sind wirklich alle Systeme in Echtzeit angebunden. Nur dann kann ich eben erst mal den Mehrwert schaffen, dass ich eben in Echtzeit entscheiden kann, was biete ich jetzt diesem Kunden an oder was eben auch nicht. Also wir haben da zum Beispiel dieses Thema, was wir in großen Kunden haben, ist Macy's in den USA. Die haben Verkaufshäuser in den kompletten USA und da ist es so,
11:21
die haben eben dann auch eine Loyalty Card, so was wie Miles and More oder Bahnmeilen bei uns, wo dann die Kunden einkaufen. Und dadurch lassen sie sich ja noch registrieren mit ihren Punkten und Macy's wissen genau, wo die sind. Und ein Beispiel ist zum Beispiel, wenn dann dieser Stammkunde und dann geht es aber auch nur, das ist dann dieses Thema auch ein bisschen Machine Learning. Man muss lernen, wem empfehle ich was?
11:41
Wenn dann eine Frau irgendwie zwischen 30 und 50 gerade für 20 Dollar eingekauft hat und den Laden verlässt und dann schicken wir ihr schnell noch einen Coupon für den nächsten Starbucks, der direkt nebenan ist und geben den umsonst einen Starbucks Kaffee. Also zahlt wirklich komplett Macy's diese 5 Dollar. Und warum machen die das? Weil eben aus diesen statistischen Analysen der historischen Daten
12:01
erkannt wurde, wenn sich Frauen inzwischen 30 und 50 in diesen Kaffee nebenein setzen, überlegen sie 10 Minuten und dann fällt ihnen ein, ich muss noch das kaufen und das und das und laufen wieder zurück. Und das ist einfach dieses Thema und das wurde eben dann auch nachgewiesen und da kann man dann wirklich zum Management gehen und sagen, hey, damit können wir viel mehr Geld verdienen. Und das geht nur, wenn man die Daten in Echtzeit Streaming Analytics
12:23
analysiert und nicht erst, wenn der Kunde bereits den Laden verlassen hat, weil dann bringt nichts mehr. Dann geht er eben nicht zum Macy's, sondern geht er eben zur Konkurrenz. Das ist so diese Grundidee dahinter und eben auch more context und more personal. Das ist ganz, ganz wichtig. Es bringt eben nichts, wenn man wirklich jedem Kunden Newsletters sendet oder irgendwelche Standard Informationen.
12:42
Man muss dem Kunden die richtigen Informationen auf das richtige Gerät in der richtigen Zeit schicken. Nur dann funktioniert dieses Thema. Was diese Kunden jetzt hier auch mit einbinden sind eben und das ist das Thema so Open API. Sie öffnen sich mittlerweile auch zu einem sogenannten Marktplatz. Das heißt, wenn ich Macy's anschaue, die operieren eben dann zusammen
13:01
mit einem Starbucks oder auch mit einer Pharmacy oder mit vielen anderen Partnern, mit denen man dann eben gemeinsam quasi den Kunden letztendlich analysieren kann, um eben den Kunden Vorteil zu schaffen, aber daraus eben für sich natürlich auch den Mehrwert zu schaffen. Ich meine, das ist diese klassische Diskussion. Warum gibt man Google seine Informationen? Weil man dann auch den Mehrwert hat mit Google Maps und diese ganzen Themen.
13:21
Und genauso machen das eben auch Kunden wie zum Beispiel jetzt einen Retailer, der eben überall seine Shops hat. Ich gebe dem Kunden was, dafür gibt ihr mir wieder was zurück. Und mittlerweile binden eben viel mehr Kunden auch viel mehr Systeme an. Und ich meine, USA sind da immer fünf Jahre voraus, aber bei denen läuft eben viel zum Beispiel bei iBeacons, wo ich dann wirklich Standortanalyse mache und genau weiß,
13:41
wo läuft der Kunde rum in meinem Laden, dass ich eben genau weiß, er ist jetzt im zweiten Stock genau vor diesem Teil. Und deshalb hat meine Frau dann gestern schon angeschaut und sie hat bald Geburtstag. Und deswegen ist wieder mein auch mein Kundensystem hintendran angeschlossen. Und dann weiß ich eben, ich schicke jetzt eben genau dem Kunden die Empfehlung für dieses Kleid, weil meine Frau hat es schon auf der Webseite gestern angeschaut und hat übermorgen Geburtstag.
14:00
Und so werden diese ganzen Informationen korreliert. Und in Echtzeit kann ich dem Kunden das richtige Angebot machen. Zum Beispiel gibt eben 30 Prozent Angebot genau für dieses Kleid oder was eben die Frau haben möchte. Und wo es eben der Trend auch immer mehr hingeht. Und da muss man auch wieder sagen, dass solche, wie wir jetzt gerade gesehen haben, natürlich Amazon ist dann Vorreiter.
14:20
Amazon, Facebook, Google, das sind immer die großen Tech Companies, die bauen sich ihre Lösungen selber. Die anderen, die müssen das irgendwie im Nachhinein lösen und setzen dann eben oftmals auch Produkte oder Frameworks ein, die unter anderem von den Tech Giganten open sourced werden oder am Markt eben entstehen. Und was wir eben auch immer mehr den Trend sehen, zum Beispiel in diesem Retailing Bereich
14:41
sind eben so Sachen wie zum Beispiel Social Media Analytics, dass man auch wieder in Echtzeit die ganzen Feeds analysiert von Facebook, von Twitter, weil eben sich ein Kunde beschwert über irgendwas und dann kann ich da in Echtzeit drauf reagieren, solange eben der Kunde noch im Laden ist oder irgendwas kaufen will. Es geht aber auch in die Richtung Internet of Things wird immer mehr verbreitet bei Retailern.
15:01
Auch hier bei Amazon ist es oftmals schon schon lange vorhanden, dieses Smart Warehouse, da bin ich eben intelligent in meinem Lagerhaus, die Daten verarbeite und ähnliches, um eben automatisiert zu handeln. Das geht aber immer weiter und eben auch nicht nur bei Amazon, sondern auch bei anderen Retailern um solche Themen wie Smart Tags, Smart Shelves, dass eben kein Arbeiter mehr im Department Store
15:22
hingehen muss und schauen muss, was ist noch auf Lager hier an Geräten oder an Artikeln, sondern automatisiert beschwert sich eben dieses dieser Ständer. Hey, meine Artikel gehen bald aus, schick mir mal Nachschub aus dem Lager und die kommunizieren quasi alle selbst miteinander. Und das geht natürlich eben alles nur automatisiert in Echtzeit, wenn es sinnvoll sein soll oder zumindest in schnellen Abläufen.
15:43
In vielen Fällen. Das ist so das Thema Retailing, wo man das eben auch immer mehr sieht. Und was eben auch noch ein interessanter Punkt ist, so dieses Crowdmanagement, habe ich es hier genannt. Da geht es hier so drum, dieses Thema Turn the Customer into a Fan. Und das kann man sich jetzt hier wirklich vorstellen im Prinzip
16:01
überall, wo viele Menschenmassen sind. Ich habe jetzt hier oben geschrieben Stadion, Flughafen, Konferenz, Hotel. Kann man sich im Prinzip alles darunter vorstellen, wo eben viele Menschen sind. Und auch hier ist im Prinzip wirklich jedes Teil angebunden und sendet Informationen. Und ich muss die Informationen in Echtzeit korrelieren, um eben Mehrwert zu schaffen.
16:21
Ein Beispiel, das wir hier haben, ist mit den Sacramento Kings. Das ist ein NBA Basketball Team in den USA. Und die haben jetzt eben letztes Jahr ein neues Stadion gebaut und haben da eben von Anfang an auch die ganze Technologie gleich mit eingebunden. Und da kann man sich so viele Use Cases überlegen, was das für einen Mehrwert schaffen kann. Hier ist bloß mal ein paar Beispiele.
16:41
Bevor der Fan überhaupt erst ins Stadion fährt zum Spiel, wird auf seiner App am Smartphone automatisch schon signalisiert, welchen Weg er zum Stadion nehmen soll. Zum Beispiel eben weil eben diese App weiß, hier diese Straße ist Stau, aber eine andere Straße ist eben kein Stau, weil es eben alles in Echtzeit analysiert wird, weil ich eben wieder diverse andere Systeme und offene Schnittstellen
17:01
wie zum Beispiel Google Maps oder was auch immer angebunden habe, um zu wissen, wie kommt mein Fan am besten zum Stadion? Hat er dann geparkt? Geht es weiter? Die App empfiehlt ihm eben so dieses Thema Intelligent Wayfinding. Wo soll ich eigentlich langlaufen? Wo ist mein Platz überhaupt? Ist vielleicht für Dauerkarten nicht so interessant, aber für welche, die nicht so oft im Stadion sind,
17:21
den man dann genau erklärt. Wo soll ich hinlaufen? Und was zum Beispiel auch die Sacramento Kings machen, da gibt es dann eben, wenn das Spiele nicht ausverkauft sind, dann kann man eben diese besseren Sitzplätze an Fans verkaufen. Wenn ich eben zum Beispiel ein Billig Ticket habe für 20 Euro und dann ist eben noch dieser Sitz ganz vorne für 200 Euro frei,
17:41
dann kann ich eben diesem Nachkunden eine Nachricht schicken. Hey, lieber Kunde, weil du schon zehnmal in diesem Jahr da warst bei uns, kriegst du für 50 Prozent Rabatt jetzt diesen Sitz da vorne, wenn du willst, anstatt für 200 Euro für 100 Euro. Und so diese ganze Korrelation. Und das funktioniert eben alles nur, wenn ich die Daten in Echtzeit analysiere und dann drauf reagiere, weil wenn das Spiel aus ist, ist es zu spät dafür.
18:02
Das muss ich sofort machen, bevor das Spiel beginnt. Sonst macht es keiner mehr. Anderes Thema ist so dieses Thema auch wieder Food und Shopping und Dinner und ähnliches. Auch die Sacramento Kings haben hier zum Beispiel diverse Restaurants angebunden, die außen um das Stadion sind. Und so kann ich dem Kunden eben dann, bevor das Spiel aus ist,
18:20
irgendwelche Coupons schicken, damit er irgendwo noch in den Restaurant geht. Aber auch da geht es wirklich noch weiter. Da ist nicht nur dann einfach die API angebunden, dass ich eben das Restaurant reservieren kann, sondern das sind dann Systeme angebunden, wie zum Beispiel die Lagerhaltung in der Küche von diesem Restaurant. Und wenn dann nebendran zum Beispiel ein Steakhouse ist, das noch 50 Steaks hat, die es verkaufen muss.
18:41
Und dann weiß man aber, heute Abend kommen gar nicht mehr so viele Leute wahrscheinlich, dass ich alle Steaks verbraten muss. Aber morgen muss ich sie wegschmeißen, weil sie zu alt sind. Also muss ich doch schauen, dass ich diese Steaks irgendwie loswerde. Und deswegen kann ich das Ganze korrelieren und biete dann manchen Kunden, wo sie eben wissen, die möchten gerne Steaks essen, einen Coupon an für 50 Prozent auf dieses Steak. Das ist dann so eine Win-Win-Situation. Der Kunde ist nachher glücklich, weil er sein Steak billig bekommt
19:02
und das Restaurant ist glücklich, weil eben die Steaks eh sonst weggeschmissen werden müssen. Und so ist es wieder. Informationen aus allen Ecken werden integriert und korreliert in Echtzeit, um eben den Mehrwert zu schaffen. Ziel eins, den Kunden glücklich zu machen und Ziel zwei natürlich, daraus mehr Umsatz zu schaffen für das Unternehmen.
19:20
Payment ist auch noch das Thema. Natürlich kann man ja auch mittlerweile mit allem zahlen. Also auch das ist alles integriert. Früher hat jeder mit Kreditkarte oder Cash gezahlt. Heute zahlen die Leute auch bei solchen Stadien schon mit PayPal oder irgendwelchen Systemen. In Zukunft zahlt man vielleicht mit Bitcoins. Keiner weiß es. Oder wir haben jetzt letzte Woche mit einem Autohersteller gesprochen. Die erwarten, dass in zehn Jahren die jungen Leute mit Facebook ihr Auto bezahlen. Davon gehen die aus.
19:42
Das kann man sich von uns wahrscheinlich keiner vorstellen, aber die gehen davon aus, dass sowas kommen wird. Und das muss man einfach alles integrieren, dass das möglich ist. Das waren jetzt zahlreiche Anwendungsfälle erst mal. Jetzt ist die Frage, wie setzt sich das Ganze eben um? Und da kommen wir jetzt eben zu diesem Thema Stream Processing, Streaming Analytics.
20:04
Und wie ich jetzt gerade schon gesagt habe im Prinzip, der Kern ist einfach, ich habe eben diese Streams an Events von diversen verschiedenen Input Quellen, wo eben diese, egal ob Sensoren sind oder vielleicht auch nur Twitter Feeds oder irgendwelche anderen Informationen, die kommen rein. Und ich muss sie eben in Echtzeit oder oftmals auch eben in zehn Sekunden realisieren und korrelieren,
20:22
solange es eben noch heiß ist, damit ich eben noch agieren kann proaktiv. Und beim Stream Processing ist es eben so, da schreibt man eben nicht mehr in der Datenbank und analysiert nachher alles. Das kennen wir jetzt alle, wenn wir früher Web Service implementiert haben oder irgendwelche APIs gebaut haben. Habe ich noch mal was in die Datenbank geschrieben und irgendwer anders hat es dann ganz dann später abgefragt
20:42
und hat die Information erhalten. Oder wenn ich viele Daten gehabt habe, dann habe ich eben sogenanntes Batch Processing gemacht oder auch ETL Prozesse, die das Ganze oftmals über Nacht erst verarbeitet haben, weil es einfach zu viele Daten waren, um das sofort zu verarbeiten. Und hier muss ich das Ganze eben in Echtzeit analysieren. Und genau dafür ist eben dieses Streaming Analytics auch gedacht
21:01
und entwickelt worden, das Konzept. Und da habe ich dann eben diese Continuous Queries und Sliding Windows, mit denen ich kontinuierlich die Information abfrage und aber nicht in der Datenbank speicher, sondern sofort in Memory verarbeite. Und jetzt hier ist immer quasi unsere Referenz Architektur
21:21
für Streaming Analytics, schaut jetzt erst mal ziemlich wild aus. Brauchen wir jetzt hier auch gar nicht im Detail drauf eingehen. Wichtig sind hier im Prinzip zwei Themen. Man sieht jetzt hier was Blaues und man sieht was Rotes. Das Blaue ist das, wo ich jetzt im ersten Teil näher drauf eingehen werde. Das ist so dieses Thema Stream Processing. Wie kann ich die ganzen Sensor Daten und Twitter Feeds in Echtzeit verarbeiten, um dann eben automatisiert zu reagieren
21:42
oder eben auch noch irgendeinen Menschen einzuschalten in der UI, der reagieren kann. Der zweite Teil, der kommt dann danach im nächsten Abschnitt. Das ist dann dieses Thema Wie kombiniere ich das Ganze mit meinen historischen Daten? Und das ist eben dann der Punkt. Ich muss natürlich erst mal meine Patterns in den historischen Daten erkennen,
22:01
um sie dann in Echtzeit anzubinden. Das ist das Thema im Prinzip, was wir gerade bei Amazon gehört haben. Dieses Machine Learning. Es lernt eben aus den historischen Daten und diese Modelle kann ich dann in Echtzeit anbinden, um in Zukunft eben den Betrug zu verhindern, bevor er passiert oder dem Kunden ein Angebot zu machen, bevor er den Laden verlassen hat. Das ist dann, wo sich dieser Kreis dann eben auch schließt.
22:22
Jetzt zuerst geht es aber wirklich um dieses Thema Stream Processing. Und da schauen wir jetzt mal, was gibt es da so für Alternativen am Markt? Im Prinzip gibt es drei Optionen, wenn ich so Streaming Analytics Stream Processing umsetzen möchte. Ich kann mir entweder nur diese ganzen Konzepte greifen wie Sliding Windows und Continuous Queries und kann mir selber was bauen.
22:41
Oder ich nehme irgendwelche Frameworks, mit denen ich viel Code schreiben kann und das Ganze selber entwickle. Oder ich nehme irgendwelche Produkte, mit denen man das Ganze umsetzen kann. Das Thema Konzepte, also wie gesagt, Continuous Queries, Sliding Windows und so weiter, was man eben alles so hat für Stream Processing, um es umzusetzen.
23:00
Damit kann man sich selber eine Lösung bauen. Habe ich im Prinzip noch nie irgendwo gesehen. Die meisten verwenden eben entweder ein Framework oder Produkt, weil es gibt eben auch viele Open Source Frameworks, die kostenlos sind. Und da haben sich dann viele schlaue Leute mit diesen Themen schon beschäftigt, haben das Ganze quasi gebaut. Und ich kann einfach diese Libraries in mein Projekt einbinden. Deswegen ist die Frage, warum soll ich es mir selber bauen?
23:21
Ich denke, es gibt ganz, ganz selten den Grund, warum man das machen sollte. Jetzt schauen wir uns dann eben an. Was gibt es eben für Alternativen, die ich einsetzen kann? Ich habe das mal so versucht darzustellen. Es gibt auf der einen Seite Produkte, die man verwenden kann. Und auf der anderen Seite gibt es Frameworks hier unten. Und hier ist jetzt auch noch wichtig, eben dieses Thema Open Source versus Closed Source.
23:40
Und da gibt es eben Produkte, die sind in der Regel immer Closed Source, weil da müssen die Hersteller mit Geld verdienen. Bei Open Source ist es so, bei Frameworks ist es so. Die meisten sind auch Open Source. Aber es gibt zum Beispiel auch solche Lösungen wie von Amazon, Kinesis, wie wir auch vorhin gehört haben. Das ist dann so eine kommerzielle Lösung, die man auch verwenden kann. Da möchte ich jetzt einfach mal genauer reinschauen, damit es klar wird.
24:02
Wie kann ich das mit Streaming Frameworks umsetzen und nachher auch mit Produkten? Und deswegen jetzt erst mal zu den Frameworks. Framework muss man sich wirklich vorstellen. Das ist letztendlich eine Menge an Klassen oder Bibliotheken, die ich eben in mein Projekt einbinde und dann mir selber den Code schreibe. Also ich rufe irgendwelche APIs auf, die eben dann zum Beispiel
24:23
so ein Sliding Window irgendwie implementieren oder so einen Filter oder solche Themen. Ich habe da eben dann in der Regel habe ich so eine SQL ähnliche Abfrangesprache. Der Unterschied ist wieder zur SQL. Da kann ich nur select Stern from X und dann lädt er mir die Daten. Das ist so dieses Request Response.
24:42
Aber Stream Processing ist eben anders. Stream Processing ist eben diese Continuous Queries, die Sliding Windows. Und deswegen kann man das in der Regel nicht mit SQL machen, sondern eben nur mit einer SQL ähnlichen Sprache. Also die meisten Frameworks und Produkte haben eine Sprache entwickelt, die oft mal sehr ähnlich zur SQL ist. Aber irgendwie diese Thematiken wie Continuous Queries mit einbindet
25:01
in diese Sprache, weil ansonsten kann ich das eben nicht umsetzen. Dieses Thema Streaming Analytics. Das Ganze muss ich natürlich skalieren können. Das ist klar. Das gilt alles sowohl für Frameworks als auch für Produkte, weil es eben um Millionen von Daten geht. Und ich muss viele verschiedene Schnittstellen anbinden. Da haben wir jetzt auch gehört in den ganzen News Cases, die ich vorhin erzählt habe.
25:20
Kann man sich vorstellen, in der Regel ist es nicht nur eine Schnittstelle, sondern viele verschiedene Sensordaten oder APIs, die ihre Sensoren oder Informationen reinschicken, die ich analysieren muss. Deswegen haben die meisten Frameworks und Produkte eben auch irgendwie viele Schnittstellen. Also zum Beispiel zu Internet of Things Technologien oder auch zu Messaging Standards oder ähnliche Themen.
25:42
Und sie implementieren eben quasi solche Themen wie Filtern, Sortieren, Aggregieren. Diese ganzen Themen werden quasi implementiert, sodass ich nur noch die Operation aufrufen muss. Und die Implementierung unten drunter kümmert sich das Framework darum. Und das ist eben auch der Grund, warum sollte ich selber mit meinen Konzepten das selber implementieren, wenn es eben genau diese Open Source Frameworks gibt,
26:01
die ich dafür genauso einsetzen kann? Schauen wir uns ein paar von denen mal ein bisschen im Detail an, also wirklich nur ganz high level. Das erste Framework ist Apache Storm. Das wurde von Twitter open sourced vor ein paar Jahren. Und deshalb wirklich das Hauptziel wirklich. Ich habe einen Input Links, nennt sich hier Spout,
26:21
und ich habe rechts diese Balls und ich verarbeite die Daten. Also hier geht es wirklich um das klassische Thema. Ich kriege viele Mengen an Daten rein, dann verarbeite ich die Daten irgendwie, zum Beispiel Aggregationen oder Sortieren oder Filtern und habe hier ein Output am Ende. Das ist letztendlich das Ziel von Apache Storm, das ist ein klassisches Stream Processing Framework. Den Code hier kann man gar nicht lesen, denn das kann man dann auf dem PDF besser.
26:42
Das Ziel hier, der Kern ist einfach zu zeigen, es ist einfach ein Framework. Ich schreibe Java Code oder Scala oder welche Sprachen eben unterstützt werden und schreibe eben mit diesem Framework meinen Code selber. Das ist eben der Kernpunkt bei einem Framework. Ich importiere die Library und schreibe mir meinen Code selber. Das war jetzt ein Open Source Framework.
27:00
Auf der anderen Seite habe ich gesagt, es gibt auch so kommerzielle Lösungen, zum Beispiel Amazon Kinesis. Die haben dann zum Beispiel den Vorteil eben, dass sie natürlich an die anderen Produkte des Herstellers angebunden sind. Hier sieht man jetzt, es gibt eben dann Out of the Box Connectoren, zum Beispiel zu Amazon S3, Redshift, DynamoDB und bestimmt in Zukunft auch irgendwann zu dieser Machine Learning Lösung, die wir vorhin im Vortrag gesehen haben.
27:23
Aber trotzdem ist es noch so, auch bei so einem Produkt oder nicht Produkt, sondern so einem kommerziellen Framework wie Kinesis ist es trotzdem so. Ich habe zwar ein bisschen grafische Unterstützung, Unterstützung, wo ich Sachen konfigurieren kann. Hier, wie man es vielleicht von Amazon kennt, wenn schon jemand mal die Amazon Web Services benutzt hat. Das ist einfach ein zusätzlicher Service von denen.
27:41
Aber letztendlich trotzdem meine ganze Verarbeitungslogik schreibe ich dann eben mit dem Code selber. Ich importiere die API, die Library und schreibe mir diesen Code dazu. Was auch noch ganz interessant war, ist ein Blogpost vom letzten Jahr hier. Man muss sich auch immer bewusst sein, zum Beispiel, wenn man so Vorteile verwenden will aus der Cloud. Es ist schnell verfügbar, es ist hoch skalierbar und diese ganzen Themen hat eben auch Nachteile.
28:02
Man kann sie eben auch nicht beeinflussen. Also ich möchte jetzt gar nicht im Detail weiter darauf eingehen. Kann man vielleicht im Nachgang mal den Link lesen. Aber hier geht es einfach um so Themen, dass ich, wenn ich einen Software als Service für so etwas verwende, dass ich dann auch wirklich nicht flexibel bin, sondern nur das verwenden kann, was der mir eben anbietet. Das ist dann oftmals die Challenge.
28:21
Anderes Framework, denke ich, hat immer mehr sieht man immer mehr am Markt, Apache Spark. Apache Spark ist erst einmal ein grundsätzliches Framework für die Verarbeitung von großen Datenmengen. Deswegen hat es eine Kernbibliothek und oben drüber verschiedene Add-ons. Eins dieser Add-ons ist eben auch Spark Streaming, mit dem ich eben ähnlich wie mit Apache Storm
28:41
eben auch meine Input Streams verarbeiten kann und dann den Output eben irgendwohin weiter schicken kann. Das ist eine Komponente von Apache Spark. Was man aber hier ganz klar sagen muss, bei Apache Spark ist es so, dass hier der Fokus, zumindest was man so überall liest von verschiedenen Kunden oder auch von anderen Tech-Giganten, die verwenden das in der Regel wirklich
29:01
für dieses Thema Analytics. Also eigentlich mehr so für diese Themen wie Machine Learning oder andere Analysen. Ich habe da mal auch noch mal letzte Woche noch mal gegoogelt und alles, was man dazu findet im Prinzip an Referenzius-Cases und ähnliches, ist der Fokus fast immer auf dem Analytics-Teil und nicht auf dem Streaming-Teil von Apache Spark. Also ja, man kann damit Stream-Processing implementieren,
29:23
aber es wird selten gemacht. Das hat unter anderem auch Gründe, weil Spark von Grund her erst mal Batch-Processing macht. Das nennt sich dann Micro-Batches und ist eben kein echtes Streaming, wo ich jedes Event einzeln verarbeite. Es schnappt sich dann eben in mehreren Events
29:41
und macht dann eben so ein Micro-Batch davon. Und deswegen kann es dann eben öfter mal auch Performance-Probleme geben oder andere Challenges. Da haben wir zum Beispiel, ich war letzte Woche auf einer anderen Veranstaltung, da war jemand von Otto, der einen Vortrag gehabt hat. Und die sind sehr begeistert von Apache Spark und sind aber trotzdem wieder weg von Spark Streaming hin zu einer anderen Lösung, weil das eben nicht getaugt hat für die Anwendungsfälle,
30:02
unter anderem eben wegen diesen Micro-Batches. Aber sie haben trotzdem neue Projekte angefangen mit Spark für diesen Analytics-Teil, für Machine Learning. All das ist, denke ich, der Trend im Moment eben so Spark eher für diesen Analytics-Teil und nicht für den Streaming-Teil. Wir haben jetzt übrigens das, glaube ich, das letzte zu Open Source. Wir haben im anschließenden Vortrag kommt Apache Flink.
30:21
Das ist auch noch mal so ein Stream-Processing-Framework. Das ist dann wirklich ein ganzer Vortrag darüber. Und das versucht, ein bisschen das Problem hier zu lösen. Das ist eben dann erst mal eine richtige Streaming-Lösung und nicht eine Micro-Batches-Lösung. Und ansonsten hört sich das mal ziemlich ähnlich an zu Spark. Ich kenne es auch nicht im Detail. Da kann man sich vielleicht, wenn es einen mehr interessiert, noch den Vortrag danach anhören.
30:43
Okay, hier noch kurz Beispiele. Ist halt wieder ein bisschen Codeschreiben. Und als zweiten Teil jetzt hier habe ich eben dann auch noch die Produkte. Die sind eben ein bisschen anders als die Frameworks. Die Produkte haben die ganzen Benefits von diesen Frameworks natürlich auch. Also ich habe deswegen genauso diese ganzen Operatoren, die ich eben brauche für Streaming Analytics.
31:02
Ich habe die Connectivity zu den verschiedenen Schnittstellen, damit ich eben alles anbinden kann. Es ist hoch skalierbar, damit ich eben viele Messages und ähnliches verarbeiten kann. Zusätzlich habe ich aber eben bei dem Produkt ein paar weitere Ergänzungen, die ich so bei den meisten Frameworks eben nicht habe. In der Regel, ich zeige es nachher auch ganz kurz, habe ich eben eine grafische Oberfläche, wo ich das Ganze entwickle.
31:22
Und hier ist wirklich einfach dieses Thema Time to Market. Wie schnell kann ich etwas umsetzen? Ich kann mit den Frameworks immer alles implementieren. Es geht absolut. Da geht es einfach um das Thema. Und das ist halt auch, warum unsere Kunden oft unsere Produkte verwenden statt ein Framework, weil es eben viel schneller geht und weil es eben so Themen auch sind wie Maturity.
31:40
Also ich habe eben dann wirklich auch genug Consultants und 24 mal 7 Support, den ich dann im Hintergrund einfach habe. Oder eben dann Integration mit den anderen Produkten von einem Hersteller. Wie zum Beispiel bei Amazon, wir haben es gesehen, eben Support zu S3 und DynamoDB und ähnliches. Und bei Tipco, wir zum Beispiel haben eben dann Out of the Box Support und Integration mit unserem ESB, Master Data Management und diese ganzen Themen.
32:03
Hier jetzt auch einfach mal zwei Beispiele. Eins ist Infosphere Streams von IBM, ist eines der bekanntesten Stream Processing Produkte. Kann ich jetzt gar nicht so viel im Detail dazu sagen. Ich kenne es nicht im Detail. Ist eben eine Lösung. Die haben zum Beispiel auch mal einen Vergleich gemacht, einen Performance Vergleich, wo sich eben relativ schnell rauszeigt,
32:21
wenn es hohe Performance Anforderungen gibt. Auf dem gleichen Server Leistung und gleichen Memory Leistung schaffen eben dann solche Produkte oftmals deutlich mehr als irgendein Framework. Streams ist jetzt unser Produkt von Tipco. Es ist halt einfach auch eine Enterprise Lösung, die eben diese Mehrwert hat, die ich eben gerade gezeigt habe,
32:40
zwischen einem Framework den Unterschied und eben zwischen einem Produkt. Hier sieht man jetzt zum Beispiel eben diese grafische Entwicklung hat eben einfach das Ziel, damit ich eben nicht den Code schreiben muss, sondern das Ganze eben grafisch entwickle und eben später auch warten kann. Das ist so einer der Kernunterschiede, den wir oft sehen. Wir sind viel bei DAX Unternehmen unterwegs, bei großen Konzernen, wo es viele Dienstleister gibt, also nicht die Festangestellten wie beim Startup,
33:02
sondern die vielen Dienstleister und die wechseln auch mal ganz schnell die Leute durch, auch zu anderen Dienstleistern. Und wenn dann jemand reinkommt, kann man sich vorstellen, für den ist das viel einfacher, wenn der sich so was anschaut, um irgendeine Änderung zu machen. Als wenn er in den Code reingehen muss, in den Quellcode. Und ich habe es am Anfang gesagt oder auch bei den Use Cases Change ist der only constant, also es ändert sich ständig irgendwas, was ich ändern muss.
33:22
Das ist eben was man einfach hier schneller umsetzen kann mit so einem Tool. Und zusätzlich ist eben auch noch dieses Thema UI. Habe ich gesagt, es gibt viele Use Cases, wo ich eben eine grafische Oberfläche brauche. Ich kann mir sowas selber schreiben, ganz klar, mit irgendwie JavaScript Frameworks, wo ich die Events reinpusche. Oder ich nehme eben einen Hersteller, der eben dann irgendeine UI
33:41
mehr oder weniger out of the box hat, die ich dann quasi nur noch konfigurieren muss. Das ist einfach so die Kernunterschiede zwischen dem Produkt und einem Framework, wie bei vielen anderen Sachen auch, wie bei einem ESB von einem Integration Framework zum Produkt. So ist es auch hier bei diesem Thema Streaming Analytics. Oftmals kombiniert sich auch beides ganz gut. Also wir haben zum Beispiel Kunden, die haben zum Beispiel
34:00
eine Patchy Storm im Einsatz, wo diese ganzen Millionen an Streams durchgernagelt werden. Aber on top auf diesem Stream Processing Framework haben sie dann eben diese Live UI, die bei uns jetzt Tipco Live Datamart heißt, verwendet, um das Ganze eben grafisch zu visualisieren, um eben den Menschen interagieren zu lassen. Und so wir sehen es öfter mal, dass Kunden auch diese Produkte
34:22
miteinander kombinieren oder auch bei IBM ist das so. Also auch IBM Infostreams hat eben Konnektoren to Apache Spark, to Apache Storm und so weiter. Also es macht oftmals auch Sinn, die zu kombinieren, die Produkte. Das war jetzt so ein bisschen der Marktüberblick sowohl Frameworks als auch Produkte. Und jetzt ist eben noch mal der Kern zum Abschluss.
34:41
Wo ist der Zusammenhang zu den anderen Big Data Komponenten? Und da habe ich jetzt am Anfang bei dieser Referenz Architektur gesagt, hier das Blaue ist jetzt diese Verarbeitung in Echtzeit. Und trotzdem haben wir aber eben noch diese historischen Daten, diese großen Datenmengen. Oftmals ist es mittlerweile Hadoop oder es ist ein Data Warehouse oder irgendwo anders werden die Daten gespeichert.
35:01
NoSQL Datenbank oder wo auch immer. Und wie spielt das Ganze jetzt zusammen? Auf der einen Seite die historischen Daten. Terabytes, Gigabytes, Petabytes, wieviel auch immer eine Firma hat. Und eben diese Verarbeitung in Echtzeit von neuen Informationen, damit ich eben den Betrug erkennen kann, bevor er passiert oder dem Kunden noch etwas andrehen kann, bevor er den Laden verlassen hat.
35:22
Und da spielen eben genau diese beiden Punkte, die historischen Daten und die Echtzeitverarbeitung zusammen. Es geht nur beides. Eins allein reicht nicht aus. Ich muss eben zuerst die historischen Daten analysieren, um eben meine Patterns erst mal zu erkennen. Wenn ich diese Patterns dann gefunden habe, dann kann ich das Ganze deployen, quasi zum Beispiel
35:41
in einer Stream Processing Lösung eben, um dann eben in Echtzeit zu agieren, bevor etwas passiert. Predictive, Fraud Detection, Customer, bevor er den Laden verlassen hat, diese Themen. Also erst historische Daten analysieren und dann darauf reagieren. Ich habe also Big Data, egal wo, Data Warehouse, Hadoop, NoSQL, whatever.
36:02
Dann analysiere ich diese Daten. Das kann ich jetzt entweder mit, ich nenne es mal, Tools verwenden, die auch Business User verwenden können. Also bei uns ist jetzt zum Beispiel Tipco Spotfire so ein Tool. Konkurrenz ist zum Beispiel Tableau oder ClickTag. Das sind einfach so Tools, mit denen kann ich sehr, sehr einfach in Daten reinschauen, egal ob Excel, SQL, Hadoop.
36:21
Ich kann da grafisch reinschauen und kann diese Daten analysieren, sehr einfach. Zusätzlich kommt aber hier auch das Thema dieser Data Scientist ins Spiel. War vorhin von diesem Amazon Vortrag eben, wie gesagt, ich habe von diesen Formeln kein Wort verstanden. Deswegen so was macht der Data Scientist, der entdeckt eben diese Modelle und diese Modelle entwickelt er quasi.
36:40
Aber die muss ich dann mit einbinden in meine Analysen als fachlicher User. Um dann diese ganzen Modelle in Echtzeit weiter zu verarbeiten. Und deswegen zeigt diese Grafik jetzt ganz schön. Ich habe eben hier mein Streaming Analytics. Entweder habe ich jetzt hier so ein Framework, wie Apache Spark, Apache Storm, Kinesis oder ein Produkt wie Tipco Streambase und binde dann eben noch diese ganzen Informationen über die Patterns mit ein.
37:04
Und diese Patterns, die kann ich entweder in so einem Produkt selber mit definieren, irgendwelche Regeln über dieses Streaming. Oder ich binde eben schon Modelle ein, die woanders gefunden wurden durch einen Data Scientist. Also in so einer Echtzeit Verarbeitung kann ich dann eben hier Spark mit einbinden oder Open Source AR sehen wir immer mehr oder auch irgendwas kommerziell ist wie SAS oder Matlab.
37:23
Also ich kann diese Modelle dann in Echtzeit einbinden, um eben nicht nur auf historischen Daten zu agieren, sondern in Echtzeit zu agieren. Das ist der Kernmehrwert, den man eben mit Streaming Analytics macht. Ich möchte jetzt noch ein paar Minuten Live Demo zeigen, auch wenn ich gleich an der Grenze bin zur Zeitende. Deswegen hier nur ganz kurz.
37:41
Hier sehen wir jetzt eben zuerst Tipco Spotfire und zum Hintergrund das ist dieses Thema mit der Öl Plattform, wo ich eben diese verschiedenen Sensoren habe, Temperature Spike und so weiter, wo analysiert wird, wann die Devices explodieren mit einer hohen Wahrscheinlichkeit. Und was haben die jetzt hier gemacht? Das war ein Proof of Concept, den haben wir von Kunden gemacht in ein, zwei Wochen. Und hier wurden historische Daten analysiert mit verschiedenen
38:05
Informationen verstärkt, um das eben zu finden. Und hier wurde dann eben ein Algorithmus oder Pattern erkannt. Und hier sieht man jetzt eben diese verschiedenen Sensoren. Das ist quasi jetzt hier in diesem einfachen Beispiel grün und orange, wie immer weiter Daten fließen. Und ich sehe diese schwarzen Striche hier. Und das ist eben dann immer, wenn so ein Ausfall passiert ist,
38:21
so eine Explosion. Und jetzt sieht man hier eben, dass mit diesen Pattern quasi vorausgesagt werden kann, wann wahrscheinlich so eine Explosion passiert. Nicht immer, weil zum Beispiel hier sehen wir auch Linie 4. Hier ist zum Beispiel mal so ein Beispiel. Hier ist ein schwarzer Strich, obwohl dieses Pattern nicht eintrifft. Also es ist immer nur eine Wahrscheinlichkeitsrechnung.
38:40
Aber nicht immer hundertprozentig garantiert. Aber das schafft eben den Mehrwert zu zeigen, wann es wahrscheinlich ausfällt. Und was die jetzt hier gemacht haben, sie haben jetzt hier auch nicht nur das über die grafische Oberfläche gemacht, sondern auch die Modelle des Data des Scientists mit eingebunden. Also ich habe hier dann, in diesem Fall war es jetzt mit R. Kann ich jetzt mal kurz hier mal auf.
39:03
Das ist quasi so ein statistisches Modell, so ein Machine Learning Modell. Auch das verstehe ich genauso wenig wie das von den Amazon-Kollegen vorhin, aber das interessiert mich auch nur bedingt. Mich interessiert nur, dass ich es eben einbinden kann in mein Produkt. Und dann wurden eben hier diese Erkenntnisse, diese Patterns gefunden in der historischen Daten.
39:22
Und dann binde ich das Ganze eben in Echtzeit ein. Und dafür starte ich jetzt noch ganz kurz hier mal mein Beispiel. Auch wenn die Auflösung ein bisschen komisch ist. Aber das sollte klappen. Und jetzt wollen wir mal hier anschauen. Ich habe jetzt dann eben hier meine grafische Oberfläche, wo ich eben die einzelnen Komponenten,
39:41
die ich entweder mit einem Framework mit Code schreibe oder eben hier grafisch modelliere und konfiguriere. Habe ich jetzt eben hier so ein Beispiel für diese Sensor Analytics, wo ich irgendwelche Inputdaten habe in einer echten Anwendung, wenn es irgendwelche Streams in diesem Beispiel, damit es bei mir jetzt lokale auf dem Laptop läuft, habe ich jetzt einfach hier eine CSV Datei, die ich einlese mit den verschiedenen Events, die ist quasi eine Simulation, die man auch für Tests verwendet.
40:02
Und in diesem Beispiel habe ich jetzt eben hier entweder für diese Regeln, die ich implementieren möchte, mache ich das Ganze entweder direkt ins Stream Base mit irgendwelchen Komponenten, wenn es relativ einfach ist, wenn es ein Entwickler machen soll. Oder ich binde eben hier irgendwelchen externen Code vom Data Scientist ein. In diesem Beispiel haben wir eben unser R-Script oder R-Model.
40:24
Das ist eben dieses Model, das hat der Data Scientist entwickelt mit Spotfire aus den historischen Daten. Und dieses Modell binde ich, ohne es irgendwie am Code zu ändern, direkt in meine Echtzeitlösung ein, um eben hier zu sagen, bitte, liebe Stream Processing Anwendung,
40:41
binde ich hier dieses Modell ein und verarbeite es bei jedem Aufruf. Also hier sieht man jetzt eben dann, wenn wir das wieder groß machen, hier sieht man jetzt für jedes einzelne Event, das hier in Echtzeit reinkommt, wird eben jetzt mit diesem Score Data hier eben diese R in diesem Fall, also dieses Machine Learning Prozess, dieses Modell angewendet, um dann zu entscheiden,
41:01
ist dieses Event ein Betrug oder ist es eine Kaufempfehlung für den Kunden oder ähnliches? Das binde ich dann eben hier ein. Und dann habe ich eben noch hinten dran die Live UI, mit dem man eben so was dann auch noch entscheiden kann. Wo jetzt hier sieht man, es ist eine blöde Auflösung leider, wo man eben hier in Echtzeit die Events sieht. Und dann kann eben bei manchen Fällen
41:21
trotzdem noch der Mensch entscheiden. Hier poppt jetzt dann irgendwann ein Alarm auf. Und dann kann ich selber noch entscheiden, was mache ich jetzt hier? Soll ich vielleicht irgendwie Alarm schlagen oder tauschen wir es nicht aus oder muss ich weitere Analysen fahren? Das ist einfach dieses Thema, wenn es nicht nur automatisiert passieren soll, sondern der Mensch die Daten eben auch noch in Echtzeit verfolgen soll,
41:40
um dann darauf zu reagieren. Ich bin am Ende der Zeit, deswegen zwei, drei Folien noch, dann sind wir fertig. Aber ich wollte jetzt einfach hier nochmal, war wichtig dieser Zusammenhang zwischen historischen Daten auf der einen Seite, um die Patterns zu finden und das Ganze dann in Streaming Analytics in Echtzeit einzubinden. Das ist eben der wirkliche Mehrwert. Und letzter Use Case hier nochmal.
42:02
Bei Wetten ist es mittlerweile so, bei Sportwetten. Heutzutage ist das fast alles mittlerweile Live-Betting. Also hier sieht man jetzt 80 Prozent der Wetten werden mittlerweile während dem Spiel eingegeben. Und das ist natürlich aus technologischer Sicht eine Challenge, weil es ist sehr, sehr einfach, historische Daten zu analysieren in Hadoop oder irgendwo andersherum, um Patterns zu finden.
42:22
Wenn ich zum Beispiel die letzten 100 Spiele analysiere oder 1000, bevor ein Spiel anfängt, ein Fußballspiel, kann ich die Daten analysieren und mache dann eben meine Quoten, die vor dem Spiel sind. Sobald aber der Anstoß passiert, fallen Tore, passieren rote Karten, Verletzungen. Und da muss ich eben in Echtzeit wieder neu berechnen. Und das genau auch diese Korrelation. Ich habe meine historischen Daten, habe meine Einstiegspatterns,
42:42
aber dann muss ich hier in Echtzeit auf neue Änderungen reagieren. Und so sieht man eben wie die Kombination aus historischen Daten und aus Echtzeit Daten kombiniert werden kann. Deswegen, was nehmen wir jetzt hier mit? Streaming Analytics verarbeitet die Daten in Echtzeit, während sie noch in Bewegung sind. Das ist der Kernunterschied zur früheren Verarbeitung,
43:02
wo ich zuerst in die Datenbahn geschrieben habe und dann eben zu spät reagieren konnte und nur so kann ich eben wie Fraud Detection vorher umsetzen, bevor sie passieren. Ich kann dem Kundenangebot schicken, bevor er den Laden verlassen hat. Ich brauche dafür in der Regel Automatisierung, aber manchmal eben auch noch Human Interaction, damit ein Mensch das überwachen kann und reagieren kann.
43:21
Und was wir eben sehr viel sehen, ist dieses Thema Time to Market. Das ist eben dieser Kernpunkt, dieses Thema soll ich ein Framework oder ein Produkt verwenden, wo man sich aus meiner Sicht immer beides anschauen sollte und selber überlegen für sein Projekt, was passt besser zu mir, zu meinen Entwicklern natürlich und wie schnell muss ich deliveren? Ja, das war es dann. Zeit haben wir nicht mehr wirklich, glaube ich.
43:40
Fragen können da gerne dann noch vorkommen zu mir nachher. Und danke.