Fast Data mit Stream-Processing: Der Game Changer für das Internet der Dinge

Transkript

1 Fast Data mit Stream-Processig: Der Game Chager für das Iteret der Dige Fast Data mit Stream-Processig: Der Game Chager für das Iteret der Dige Die Nachfrage ach Stream-Processig steigt i diese Tage eorm a. Der Grud dafür ist, dass die reie Verarbeitug vo große Datemege (Big Data) icht mehr ausreiched ist. Dateströme müsse sofort i Echtzeit verarbeitet werde (Fast Data), um auf die heutzutage beötigte Flexibilität bei durchgehed digitale Prozesse reagiere zu köe. Dies gilt isbesodere beim Iteret der Dige (Iteret of Thigs, IoT), wo viele Geräte Dateströme produziere. Am Beispiel vo Predictive Aalytics wird i diesem Artikel der Mehrwert vo Stream-Processig aufgezeigt. Verschiedee Ope-Source-Frameworks ud kommerzielle Produkte werde dabei vorgestellt. Stream-Processig ist isbesodere für das Verarbeite vo Dateströme ud Sesordate geeiget. Die Verarbeitug vo mehrere Milliarde Datesätze pro Tag ist dabei keie große Herausforderug. Stream-Processig verarbeitet verschiedee Dateströme (z. B. Nachrichte vo Sesore, die seküdlich iklusive Zeitstempel verschickt werde). Ei Beispiel ist die Verarbeitug der Sesordate vo Züge, Schiee ud Bahhöfe. Die Sesore sede stark frequetiert Date mit städig idetische Datestrukture. Die Dateströme werde i Echtzeit verarbeitet, beispielsweise gefiltert ud aggregiert. Kozepte des Stream-Processig Stream-Processig wurde kozipiert, um Dateströme i Echtzeit zu aalysiere ud sofort auf Ereigisse reagiere zu köe. Aufgabe sid uter aderem das Filter, Aggregiere oder Korreliere vo Date. Dazu werde so geate Cotiuous Queries verwedet, die im Gegesatz zum Request-Respose-Kozept vo Datebak-Sprache wie SQL zusätzliche Fuktioalität abiete. Slidig Widows überwache beispielsweise Dateströme i eiem kotiuierlich fortlaufede Zeitfester bezüglich defiierter Patters. Die Keraufgabe beim Stream-Processig ist Streamig Aalytics ei Begriff, der durch Aalyste wie Garter ud Forrester etstade ist. Dabei werde Abfrage eimal defiiert ud da kotiuierlich o the fly ierhalb des Streams berechet, um Date zu korreliere. Dies steht im starke Gegesatz zu dem traditioelle Datebak-Modell, bei dem Date zuerst gespeichert ud idexiert werde, bevor sie da vo Abfrage verarbeitet werde. Aber auch beim Stream- Processig köe Iformatioe aus Datequelle wie relatioaler Datebak, NoSQL oder Hadoop mit eibezoge werde, beispielsweise um bestimmte historische Iformatioe mit i de Datefluss eizubette oder um verarbeitete Iformatioe i eier extere Datebak zu speicher. Nebe der rei automatisierte Verarbeitug vo Dateflüsse gibt es mittlerweile auch die Möglichkeit, dass der Edutzer mittels eier grafische Beutzugsoberfläche die kotiuierlich i Bewegug stehede Date mittels Push-Nachrichte i Echtzeit überwache ud proaktiv reagiere ka. Die Dateströme werde dabei kotiuierlich im Hauptspeicher aggregiert ud dem Edutzer im grafische Froted zur Verfügug gestellt. Abbildug 1 zeigt, wie diese Echtzeit-Oberfläche (iklusive Stream-Processig-Kompoete) i die Gesamtarchitektur passt. Nach der Erläuterug der Grudkozepte zeige ich im folgede Abschitt auf, warum Stream-Processig i Zukuft isbesodere für das Iteret of Thigs (IoT) so relevat ist. Abb. 1: Die Stream-Processig-Architektur. Awedugsfall: Predictive Aalytics Predictive Aalytics also das proaktive Reagiere auf ei wahrscheilich eitretedes Ereigis ist eies der Kertheme, für die Stream-Processig ideal geeiget ist. Aus techischer Sicht ethält die Realisierug üblicherweise zwei Schritte. Zuerst werde historische Date (z.b. gespeichert im Data Warehouse, i Hadoop, oder i eier NoSQL-Datebak) mit eier Busiess- Itelligece- oder Data-Discovery-Software wie Tableau oder TIBCO Spotfire aalysiert, um Muster zu erkee. Im zweite Schritt werde die Muster i eier Stream- Processig-Plattform implemetiert, um i Echtzeit im richtige Kotext proaktiv auf eue Ereigisse zu reagiere. Die Awedug ka außerdem auch diese Date wieder i eier Datebak speicher, sodass sich der Zyklus schließt, idem bestehede Muster optimiert ud eue Muster gefude werde köe. Im Umfeld des IoT ist isbesodere Predictive Fault Maagemet sehr spaed, bei 10

2 dem (mit hoher Wahrscheilichkeit) bald ausfallede Kompoete ausgetauscht werde, bevor sie eie Schade arichte. So ka beispielsweise eie Ölplattform, auf der diverse Sesore masseweise Dateströme sede, mittels Predictive Fault Maagemet die Hardware überwache ud Teilbereiche für Beträge im Tausederbereich austausche, bevor diese wege Probleme (mit eier gewisse Wahrscheilichkeit) bald explodiere ud eie weitaus höhere Schade im Millioe-Bereich arichte. Abbildug 2 zeigt, wie ei Muster defiiert wird, um Stromspaug, Temperatur ud Vibratio vo eiem Gerät miteiader zu korreliere. Diese so geate Slidig Widows aalysiere i diesem Beispiel kotiuierlich die letzte zwölf Miute. I der Realität sehe solche Regel atürlich komplexer aus ud beihalte deutlich mehr Schittstelle. Aforderuge für Stream-Processig Stream-Processig ka etweder selbst implemetiert werde oder es wird ei Framework oder Produkt für die Verarbeitug der Dateströme verwedet. Eie selbstetwickelte Lösug macht i der Regel keie Si, da auch gute, kostelose Ope-Source- Frameworks zur Verfügug stehe. Währed mit eiem Framework aber och viel Etwicklugsaufwad otwedig ist, biete Produkte viele Fuktioalität out-of-the-box a. Nebe der Gesamtlaufzeit eies Projekts gilt es hier auch, die Gesamtkoste (Total Cost of Owershiop, TCO) eies Projekts über Etwicklug, Test, Betrieb ud Wartug zu betrachte, ud icht ur die reie Lizezkoste für kommerzielle Produkte. Aus techischer Sicht werde die folgede Kompoete beötigt, um Stream-Processig-Projekte umzusetze: Server: Ei auf Performace optimierter Awedugsserver mit hoher Durchsatz-Rate ud sehr gerige Latezzeite bildet die Grudlage für die Verarbeitug vo Dateströme. Mehrere Milliarde Evets täglich sid hier keie Selteheit oder besodere Schwierigkeit für eie eizele Maschie. Etwicklugsumgebug: Die Umgebug umfasst die Etwicklug, das Debuggig ud die Teste/Feed-Simulatio vo Streamig-Prozesse uter Verwedug vo Kompoete zum Filter, Aggregiere, Korreliere ud Trasformiere. Streamig-typische Operatore Abb. 2: Muster für die Aalyse vo Sesordate (mit SQL-ählicher Abfragesprache). wie Slidig Widows oder Cotiuous Queries sid ebefalls Pflicht. Die Etwicklug erfolgt etweder mittels Kodierug oder eier grafische Oberfläche. Wichtig ist außerdem eie offee IDE für eigee Erweiteruge, z.b. durch die Itegratio vo adere Code-Bibliotheke oder selbst gebaute Operatore bzw. Koektore. Koektore: Hierzu zähle vorgefertigte Schittstelle, um mit Datequelle auf eie stadardisierte Weise zu kommuiziere, sowohl für Iput als auch Output. Im Fokus stehe atürlich isbesodere Streamig-Schittstelle, basiered auf Stadards wie MQTT (Message Queue Telemetry Trasport) (ei offees Nachrichte-Protokoll für Machie-to-Machie-Kommuikatio) oder Low-Level-TCP-Sockets, aber auch explizite Koektore zu IoT-Geräte ud -Techologie, z.b. Zigbee, Beacos oder OSISOFT Pi. Weitere Schittstelle, die oft beötigt werde, sid aalytische Datebake (z.b. HP Vertica ), Marktdate (z.b. Bloomberg, FIX, Reuters ), statistische Modelle (z.b. SAS, MATLAB, R, TERR ) oder adere Techologie (z.b. JMS, Hadoop, Java,.NET, relatioale Datebake). Visual Streamig Aalytics: Hierbei hadelt es sich um eie Beutzugsoberfläche, mit der Date i Echtzeit überwacht werde köe. Nebe der Aalyse vo Streams (Live-Stream- Visualisierug, kotiuierliche ud dyamische Abfrage, Ad-hoc-Abfrage, Slice&Dice) sollte auch proaktive Iteraktio möglich sei (z.b. eie Alarm auslöse, ei Gerät sicherheitshalber abschalte oder eiem Kollege eie Nachricht schicke). Aktuell existiere am Markt ur weige Lösuge, die all diese Kompoete aus eiem Guss abiete. Es ist abzuwäge, ob der Fokus eies Projekts eher auf der Kodierug eier eigee Lösug aus verfügbare kostelose Bausteie oder auf der Verwedug eier verfügbare kommerzielle Lösug liege soll. Im Folgede werde ohe Aspruch auf Vollstädigkeit eiige der wichtigste Ope-Source-Lösuge ud kommerzielle Lösuge vorgestellt. Ope-Source-Frameworks für Stream-Processig Apache Storm (vgl. [Apa15-a]) ermöglicht eie massiv skalierbare Evet-Verarbeitug. Das Projekt wurde vo Twitter etwickelt ud a die Apache-Commuity übergebe. Storm basiert auf adere Ope-Source- Kompoete, isbesodere: Zookeeper für Cluster-Maagemet ZeroMQ für Multicast-Messagig Kafka für Queued-Messagig Storm ist bereits i zahlreiche Deploymets produktiv im Eisatz. Aktuell ist kei kommerzieller Support vo eiem dedizierte Hersteller verfügbar. Allerdigs habe eiige Hadoop-Hersteller Storm i ihre Distributio aufgeomme, worüber das Projekt da auch uterstützt wird. Storm ist eie gute Wahl, we ohe Lizezkoste eie eigee Awedug selbst etwickelt werde soll. Bria Bulkowski, Grüder vo Aerospike (eiem Abieter eier NoSQL-Datebak mit Koektore 01/

3 Fast Data mit Stream-Processig: Der Game Chager für das Iteret der Dige für Storm), hat ei gutes Präsetatiosdeck zusammegestellt, das ei Gefühl dafür gibt, wie mit Storm das Thema Stream-Processig bezüglich Istallatio, Etwicklug ud Deploymet agegage ud umgesetzt wird (vgl. [Bul14]). Zusammefassed ka festgehalte werde, dass wie auch bei de adere hier vorgestellte Frameworks das Codig ud viel Detailwisse im Vordergrud stehe müsse, um ei Projekt erfolgreich umzusetze. Auf der Webseite vo Storm werde zahlreiche iteressate Referez-Awedugsfälle erläutert (vgl. [Apa15-b]), daruter bekate Firme wie Groupo, Twitter, Spotify, HolodayCheck oder Alibaba. Apache Spark (vgl. [Apa15-c]) ist ei geerisches Framework für die Verarbeitug vo große Datemege, das verschiedee Kozepte wie Batch-Processig, I- Memory-Computig, Graphe-Aalyse ud Machie-Learig uter Nutzug eier Uified Core API für zahlreiche Programmiersprache wie Java, Scala, Pytho oder R uterstützt. Die verschiedee Kozepte ergäze de Ker mit Add-o-Bibliotheke, beispielsweise Spark-Streamig für Stream-Processig. Kommerzieller Support wird durch die 2013 gegrüdete Firma Databricks (vgl. [Datab15]) agebote. Spark wird mittlerweile als eies der wichtigste Big-Data-Projekte agesehe ud vo viele Firme uterstützt. So hat beispielsweise IBM im Jui 2015 ageküdigt, dass sich IBM-Forscher ud -Etwickler mit Spark-bezogee Projekte beschäftige werde (vgl. [IBM15-a]). Im Gegesatz zu Storm ist Spark allerdigs icht ur auf Stream-Processig fokussiert Spark-Streamig ist ur eie Kompoete uter viele ud verwedet de Batch-orietierte Ker, um das Streamig mittels Micro-Batches zu implemetiere, astatt jedes Tuple eizel zu verarbeite(vgl. [Dat14]). Weitere Ope-Source-Frameworks sid: Abb. 3: Etwicklugsumgebug (IBM IfoSphere Streams). ud.net. Kommerzieller Support wird vom Uterehme EsperTech agebote, das auch zusätzliche closed source Add-os abietet (vgl. [Esp15]). Ma sollte sich bewusst sei, dass die verschiedee Frameworks gewisse Stärke ud Schwäche habe ud auf Grud ihrer Kozepte für uterschiedliche Awedugsfälle geutzt werde. Mit Storm werde große Dateströme i Echtzeit gesammelt ud weiter verarbeitet, währed Spark seie Stärke isbesodere i de Bereiche Aalytics ud Maschie Learig zeige ka ud oftmals als Ersatz für Hadoops Map- Reduce eigesetzt wird. Aus diesem Grud werde verschiedee Frameworks auch gere kombiiert, beispielsweise Apache Storm für das Sammel der Dateströme ud Esper für die kotiuierliche Korrelatio der eigehede Iformatioe (vgl. [Dud11]). Zusätzlich werde i eiem Projekt schell weitere Frameworks otwedig, beispielsweise Hadoops YARN oder Mesos für Ressource- ud Cluster-Maagemet. Der Codig-Aufwad, die Komplexität für die Itegratio verschiedeer Frameworks sowie der magelde kommerzielle Support ud Tool-Support für das gesamte Projekt sid bei der Kombiatio verschiedeer Frameworks icht zu uterschätze. Eie adere Asatz wähle kommerzielle Abieter wie IBM oder TIBCO, auch we diese atürlich trotzdem Ope-Source- Apache Samza: Ei och juges Stream- Processig-Framework, das 2014 vo LikedI freigegebe wurde. Es basiert auf Apache Kafka ud Hadoop YARN (vgl. [Apa-a]). Apache Flik: Ei sehr juges geerisches Framework, das auf eier Stream- Processig-Egie basiert. Es bietet darauf aufbaued aber auch die Umsetzug aderer Kozepte, wie Batch- Processig, Machie Learig oder Graphe-Aalyse a (vgl. [Apa-b]). Esper: Hierbei hadelt es sich um ei ausgereiftes CEP-Framework für Java Abb. 4: Etwicklugsumgebug (TIBCO StreamBase). 12

4 Frameworks wie Storm, Spark oder Hadoop uterstütze ud itegriere. Kommerzielle Lösuge für Stream-Processig IBM IfoSphere Streams (vgl. [IBM15-b]) ist IBMs Flaggschiff-Produkt für Stream- Processig. Es bietet eie hohe Skalierbarkeit, sehr gute Performace ud Itegratio zu viele Schittstelle ud Techologie. Die Etwicklugsumgebug basiert auf Eclipse ud bietet grafische Etwicklug (siehe Abbildug 3). Zubair Nabi ud Eric Bouillet vom IBM Research Dubli habe gemeisam mit Adrew Baibridge ud Chris Thomas vo der IBM Software Group Europe eie Bechmark-Studie (vgl. Bai14]) erstellt, der IBM IfoSphere Streams mit Apache Storm vergleicht. Eier der Keruterschiede ist die deutlich bessere Performace gegeüber der Ope-Source-Lösug. Bei TIBCO StreamBase (vgl. [TIB15-a]) ist der größte Mehrwert laut Hersteller ebe hoher Performace ud ausgereiftem Produkt die sehr eifache ud schelle Etwicklug vo Streamig-Prozesse. Die Etwicklugsumgebug uterstützt die grafische Etwicklug vo Streamigtypische Probleme wie Slidig Widows, Cotiuous Queries oder Feed Simulatio ohe Codig (siehe Abbildug 4). TIBCO Live Datamart (vgl. [TIB15-b]) kosumiert Dateströme i Echtzeit ud erzeugt ei I-Memory Datamart ählich eiem klassische Datamart eies Data- Abb. 5: Live-Beutzugsoberfläche (TIBCO Live Datamart). Warehouse, aber ebe i Echtzeit. Das Live-Datamart bietet push-basierte Abfrageergebisse ud Alarme für Edutzer (siehe Abbildug 5). Der Cliet des Live-Datamart (Rich Cliet, Web-UI oder Mobile App) ist eie Pushbasierte Awedug, die mit dem Server kommuiziert. Dies ermöglicht die Aalyse vo Date i Echtzeit, Alarm-Maagemet ud iteraktive Aktioe auf alle visuelle Elemete, z.b. Tabelle, Charts ud Maps. Der Busiess-Aweder ka beispielsweise beim obe beschriebee Awedugsfall verschiedee Sesore wie Temperatur, Vibratioe ud Stromspaug icht ur passiv i Echtzeit überwache, soder bei Gefahre proaktiv reagiere ud Ge- gemaßahme treffe, bevor ei Schade (mit hoher Wahrscheilichkeit) eitritt. Dies ist auch der kokrete Uterschied eies Live-Datamart im Vergleich zu ur auf dem Desktop verfügbare Dashboard- Produkte, wie beispielsweise Datawatch Paoptico (vgl. [Dat15]). Weitere Frameworks ud Produkte für Stream-Processig Nebe TIBCO ud IBM biete auch die meiste adere große Softwarehersteller ei Produkt für Stream-Processig a, beispielsweise Apama vo der Software AG, Oracle CEP oder Sybase CEP vo SAP. Im Folgede stelle ich eiige weitere kommerzielle Frameworks ud Produkte kurz vor, Abb. 6: Kombiatio vo Apache Spark ud TIBCO StreamBase/Live Datamart. 01/

5 Fast Data mit Stream-Processig: Der Game Chager für das Iteret der Dige Liks [Ama15] Amazo Kiesis, 2015, siehe: [Apa15-a] The Apache Software Foudatio, Apache Storm, 2015, siehe: [Apa15-b] The Apache Software Foudatio, Compaies Usig Apache Storm, 2015, siehe: [Apa15-c] The Apache Software Foudatio, Spark, 2015, siehe: [Apa-a] The Apache Software Foudatio, Samza, siehe: [Apa-b] The Apache Software Foudatio, Apache Flik, siehe: [Bai14] Z. Nabi, E. Bouillet, A. Baibridge, C.Thomas, Of Streams ad Storms, 2014, siehe: [Bul14] B. Bulkowski, Real-time aalytics with Storm, NoSQL, ad Hadoop, Aerospike, 2014, siehe: [Dat15] Datawatch, 2015, siehe: [Datab14] Databricks, 2014, Spark 1.1: The State of Spark Streamig, siehe: [Datab15] Databricks, 2015, siehe: [DataT15-a] DataTorret, 2015, siehe: [DataT15-b] DataTorret, DataTorret Ope Sources DataTorret RTS, 2015, [Dud11] T. Dudziak, Thomas Dudziak s Blog, Storm & Esper, 2011, siehe: [Esp15] EsperTech, Esper, 2015, siehe: [IBM15-a] IBM, IBM Aouces Major Commitmet to Advace Apache Spark, Callig it Potetially the Most Sigificat Ope Source Project of the Next Decade, 2015, siehe: [IBM15-b] IBM, IfoSphere Streams, 2015, siehe: [SQL15] SQLstream, 2015, siehe: [Tib15] siehe: [TIB15-a] TIBCO Software, Ic., TIBCO StreamBase Named Leader i Forrester Wave for Big Data Streamig Aalytics Platforms 2014, 2015, siehe: [TIB15-b] TIBCO Software, Ic., TIBCO Live Datamart, 2015, siehe: [TIB15-c] TIBCO Software, Ic., TIBCO Spotfire, siehe: die ihre Fokus isbesodere auf Stream- Processig setze: Amazo Kiesis ist ei Cloud-Service für Stream-Processig vo Amazo ud Bestadteil der AWS-Plattform (Amazo Web Services). Der Service ka daher gut mit adere AWS-Services wie S3, Redshift oder DyamoDB kombiiert werde. Es hadelt sich hierbei um ei Framework, d.h. die Etwicklug fuktioiert ählich wie bei Apache Storm oder Spark mittels Quellcode (vgl. [Ama15]). DataTorret ist eie Plattform, die ativ auf Apache Hadoop läuft ud sowohl Batch- als auch Stream-Processig i eier Lösug ermöglicht (vgl. [DataT15-a]). Das Produkt bietet grafische Tools für Etwicklug ud Moitorig. Im Jui 2015 hat DataTorret ageküdigt, de Ker des Produkts, die DataTorret RTS Core Egie, als Ope-Source uter Apache Lizez zu veröffetliche (vgl. [DataT15-b]), der Rest des Produkts ist weiterhi ur kommerziell verfügbar. SQLstream bietet mit Blaze eie Stream- Processig-Plattform a, die auf dem SQL-Stadard aufbaut ud diese um proprietäre Streamig-Kostrukte erweitert. Dadurch köe Awedugsfälle mit SQL-ähliche Abfrage implemetiert werde. Das Produkt StreamLab ermöglicht das eifache Erstelle vo grafische Dashboards ohe Implemetierugsaufwad. Im Gegesatz zu beispielsweise TIBCO Live Datamart ist mit diese Dashboards allerdigs ur eie Überwachug, jedoch keie meschliche Iteraktio möglich (vgl. [SQL15]). Evaluierugsprozess: Framework, Produkt oder beides? Die meiste Frameworks ud Produkte höre sich sehr ählich a, we ma auf die jeweilige Webseite schaut. Alle biete Real- Time-Stream-Processig, hohe Skalierbar- keit, großartige Tools ud tolles Moitorig. Da isbesodere bei kommerzielle Lösuge laut de Hersteller das eigee Produkt immer eie eifache ud effiziete Etwicklug ermöglicht, sollte Alterative ubedigt ausgiebig getestet werde bezüglich eifacher Beutzbarkeit, effizieter Etwicklugsumgebug, Testig/Simulatio, Performace usw. Auch Theme wie eifache Istallatio, Betrieb, Wartug ud Weiteretwicklug sid wichtig. Ei Proof of Cocept mit zwei oder drei Frameworks bzw. Produkte ist driged azurate. Die uterschiedliche Frameworks ud Produkte uterscheide sich i eiige Aspekte stark voeiader: Eie explizit für Stream-Processig etwickelte (oft SQL-ähliche) Programmier-/Abfragesprache. Kodierug vs. grafische Etwicklug, Debuggig, Testig ud Simulatio. Hoch optimierte Performace. Moitorig- ud Alertig-Dashboards. 14

6 Uterstützug vo Hochverfügbarkeit ud Disaster Recovery. Ausgereifte Produkte. Echzeit-Oberfläche für proaktive, meschliche Iteraktioe mittels Echtzeit-Froted. Out-of-the-Box-Koektore für viele relevate Streamig-Techologie (z.b. IoT, Tradig-Markets, Social Feeds). Globaler Missio Critical Support, Cosultig ud Traiig. Ma sollte sich zu Begi überlege, welche dieser Aspekte im kokrete Projekt beötigt werde. Zusätzlich sid die Gesamtkoste (TCO) zu beachte, iklusive Lizezkoste ud Aufwad für Istallatio, Etwicklug ud Betrieb. Oftmals ist auch eie kurze Gesamtlaufzeit der wichtigste Aspekt für ei Projekt. Auf Grud zahlreicher magelder outof-the-box Fuktioalität i Frameworks werde sie oftmals auch mit eiem Produkt kombiiert. Beide sid daher durchaus auch komplemetär zueiader. Abbildug 6 zeigt, wie eie bestehede Awedug für das Sammel vo Dateströme auf Apache Storm basiered ud bereits produktiv im Eisatz um TIBCO StreamBase ergäzt wurde, um zusätzlich Aalyse, Abfrage, Itegratio ud Visualisierug sehr schell ud eifach ohe Kodierug umzusetze. Gerade bei diese Theme ist die Realisierug mit eiem Produkt oftmals deutlich effizieter. Eibidug i die Gesamtarchitektur Nebe der Evaluierug der Kerfuktioalität bezüglich Stream-Processig sollte vo Begi a betrachtet werde, wie die Itegratio mit aderer Middleware ud adere Aweduge zusammespielt. Die Projektarchitektur ka beispielsweise verschiedee Messagig-Techologie, eie Eterprise Service Bus (ESB) als Itegratiosplattform oder ei MDM-System (Master Data Maagemet) für die zetrale Verwaltug vo Stammdate beihalte. Hier gilt es zu kläre, iwieweit diese Kompoete lose gekoppelt, aber deoch gut miteiader itegriert sid. Asoste ka viel Aufwad ud hohe Komplexität für die Itegratio der verschiedee Kompoete etstehe. Auch hier ka ei Proof of Cocept i weige Tage viele harte Fakte bezüglich Eigug für das Projekt aufzeige. Ei weiterer wichtiger Aspekt ist die Eibidug vo statistische Modelle ud Machie Learig i eie Stream-Processig-Egie. Typischerweise werde Modelle vo Data Scietists mit Techologie wie R, SAS oder MATLAB erstellt ud traiiert, um eue Erketisse ud Muster zu fide. Diese Muster köe da ebefalls i eie Datefluss itegriert werde, um i Echtzeit auf eue Ereigisse zu agiere. Astatt die Modelle eu zu implemetiere, werde solche Modelle vo mache Hersteller vo Haus aus auch i der Stream-Processig-Plattform uterstützt beispielsweise TIBCOs Rutime for R (TERR) (vgl. [TIB15-c]), wodurch Stadard-R-Skripte ohe Äderuge des Codes i die Echtzeitverarbeitug eigebude werde köe. Asoste ist es auch möglich, ei Modell aus Tools wie SAS oder MATLAB im XML-basierte PMML-Stadard (Predictive Model Markup Laguage) zu exportiere ud da i Frameworks oder Produkte zu importiere. Diese Methode ist deutlich flexibler ud mächtiger, als ur Muster aus historische Date mittels Busiess Itelligece- Werkzeuge zu etdecke ud da statisch im Stream-Processig zu implemetiere. Stream-Processig uumgäglich für das IoT Stream-Processig wird verwedet, um Dateströme mit Milliarde vo Datesätze i Echtzeit zu verarbeite. Im Zeitalter des IoT wird dieses Kozept mit größerer Verbreitug daher jedes Jahr immer relevater. Auf dem Markt sid zahlreiche Frameworks ud Produkte verfügbar. Viele Lö- suge sid allerdigs och icht allzu ausgereift ud es magelt a guter Tool- Uterstützug. Sofer Codig erwüscht ist sowie Tool-Uterstützug ud kommerzieller Support icht die höchste Priorität habe, steht Apache Storm als sehr gute Ope-Source-Lösug a erster Stelle für das Sammel ud Verarbeite großer Dateströme. Apache Spark wird ebefalls immer relevater, zielt aber eher auf Theme wie Aalytics (als Ersatz für MapReduce) ud Machie Learig. Produkte wie IBM IfoSphere Streams oder TIBCO Stream- Base biete ausgereifte Produkte, grafische Tool-Uterstützug, eifache Itegratio i das restliche Uterehmesumfeld ud weltweite Support sowie Cosultig a. Eie Echtzeit-Oberfläche ermöglicht ebe automatisierter Verarbeitug auch proaktive meschliche Iteraktioe. Da alle Frameworks ud Produkte mit quasi idetische Merkmale ud Vorteile werbe, sid eie ausführliche Evaluierug bzw. ei Proof of Cocept mit Bezug zu Aufwad, Beutzbarkeit, Time-to-Market ud Gesamtkoste driged zu empfehle. Der Autor Kai Wäher (kotakt@kai-waeher.de) ist Techical Lead bei TIBCO. Seie Schwerpukte liege i de Bereiche Itegratio, Big Data, Aalytics, SOA, Microservices, BPM, Cloud Computig, Java EE ad Eterprise Architecture Maagemet. Er ist Autor vo Fachartikel ud hält Vorträge auf iteratioale IT-Kofereze. 01/