Spring XD - Tackling Big Data Complexity

German article on Spring XD, a system for big data ingestion and processing.

Transcript

1. magazin Java • Architekturen • Web • Agile www.javamagazin.de Java Mag 4.2014 Spring XD: Tackling Big Data Complexity   54 Chromecast Streaming Client in Deutschland  100 MacGyver Scaling Skalierung einer 3-Schichten-Architektur  85 Alle Infos hier im Heft!   51 Vert.x im Unternehmens­ einsatz: Asynchrone ­ Entwicklung in der Praxis 75 AngularJS-Tutorial: Die Anwendung erwacht zum Leben 46 Einfach skalieren mit Riak: Teil 8 der großen NoSQL-­ Serie 70 Neu auf der JDK-8-Bühne: StampedLock 28 Jetzt wird’s offiziell: ­JavaFX und das JDK 34 Das große Update auf einen Blick 13 Java  8 Sonderdruck für www.codecentric.de
2. Agile Sonderdruck von Tobias Flohre und Dennis Schulte Die Digitalisierung der Welt, technische Erneuerungen und Konkurrenzdruck sorgen für Herausforderungen im Datenmanagement, denen sich jedes Unternehmen heutzutage stellen muss. Datenmenge Auch wenn man bei Big Data vielleicht zunächst an die Suchmaschinen und sozialen Netzwerke dieser Welt denkt, so ist es doch ein Fakt, dass sich die zu verarbei- tenden Datenmengen in jedem Unternehmen erhöhen, und dass viele an die Grenzen ihrer einen relationalen Datenbank stoßen. Ob man das nun Big Data nennt oder nicht, ist Definitionsfrage. Keine Frage ist, dass man aktiv werden muss. Heterogene Datenquellen und Datenformate Dies ist einerseits eine Folge aus dem ersten Punkt, da bei großen Datenmengen andere Datenspeicher benö- tigt werden, aber der ursprüngliche operative Daten- speicher natürlich weiter betrieben wird. So existieren nun beispielsweise ein Hadoop-Cluster und eine rela- tionale Datenbank parallel. Andererseits werden Da- ten immer häufiger ihrer Natur entsprechend abgelegt: ein Graph in einer Graphdatenbank, ein Dokument in einer Dokumentendatenbank. Und auch im Bereich Messaging haben sich in den letzten Jahren die Pro- tokolle und Produkte vervielfacht. Einerseits haben unterschiedliche Datenquellen unterschiedliche Daten- formate, andererseits werden aber auch immer mehr un- und semistrukturierte Daten aufgenommen und verarbeitet. Stream Processing und Real Time Analytics Online bzw. Stream Processing wird immer relevanter. Daten zu sammeln und dann irgendwann im Batch zu verarbeiten, kann der entscheidende Wettbewerbsnach- teil gegenüber der Konkurrenz sein. Das gilt noch mehr für den Analytics-Bereich. Warum erst alle Daten spei- chern und dann zeitverzögert auswerten, wenn man sie direkt bei Ankunft auswerten kann? Was folgt daraus? Mit vielen unterschiedlichen Datenquellen und Daten- formaten wird die Datenintegration immer anspruchs- voller. Daten bzw. ihre Essenz werden immer häufiger dort benötigt, wo sie nicht vorhanden sind. Wenn bei- spielsweise Daten aus einer Datenquelle ins Hadoop Distributed File System (HDFS) gestreamt werden, eine Auswertung darüber aber in der operativen relationalen Datenbank benötigt wird, ist es notwendig, eine Daten- pipeline aufzubauen, die zum einen das Streamen ins HDFS abdeckt, andererseits aber die Auswertungsjobs anstößt und ihre Ergebnisse in die relationale Daten- bank pumpt. Ein Tool, das das Erstellen von Datenpipelines un- terstützt, muss mit unterschiedlichsten Datenquellen umgehen können und die Transformation in unter- schiedliche Datenformate unterstützen. Außerdem soll- ten Real-Time-Auswertungen auf den Datenströmen ermöglicht werden. Und, ganz wichtig, das Tool muss Streams, Jobs und Real Time Analytics Tackling Big Data Complexity Wenn man von Big Data spricht, redet man häufig über Hadoop oder NoSQL-Datenbanken. Dabei ist Big Data viel mehr als bloße Persistenz. Daten müssen gesammelt, verarbeitet und exportiert werden. Real Time Analytics sind ein weiteres großes Thema. Spring XD ist ein neu- es Mitglied im Spring-Ökosystem, das sich genau diese Themen auf die Fahne geschrieben hat. Mit einer einfachen DSL können Datenströme und Batch-Jobs erzeugt und Real-Time- Auswertungen auf den Datenströmen konfiguriert werden. Unter der Haube erfindet Spring XD das Rad nicht neu. Es basiert stark auf bewährten Projekten wie Spring Batch und Spring In- tegration und nutzt Spring Data und Spring for Hadoop für den Big-Data-Bezug. Bald erscheint Version 1.0 – höchste Zeit, einen genaueren Blick auf die Features zu werfen. © Software & Support Media GmbH 2 www.JAXenter.de javamagazin 4 | 2014
3. Agile Sonderdruck skalieren, sowohl bei der Menge als auch bei der Ge- schwindigkeit der Daten. Vorhang auf für Spring XD Spring XD ist ein einheitliches, verteiltes und erweiterbares System für Datenaufnahme, Real Time Analytics, Batch- Verarbeitung und Datenexport [1]. Es ist im Gegensatz zu den meisten anderen Spring-Projekten kein Framework, sondern bietet eine eigene, verteilte Laufzeitumgebung für bestimmte Arten von Modulen: Source, Processor, Sink und Job. Die ersten drei werden in Streams organisiert, behandeln Einzeldatensätze, die aus der Source gelesen, durch beliebige Processors bearbeitet und in das Sink ge- schrieben werden. Dabei können Daten durch Taps an jeder Stelle des Streams abgezapft, durch spezielle Ana- lytics-Module ausgewertet und in neue Streams abgelei- tet werden. Jobs verarbeiten Massendaten, können durch Streams ausgelöst werden und Daten in Streams emissie- ren. Für alle Arten von Modulen gibt es viele vordefinierte Komponenten, sodass die meisten Standardtechnologien abgedeckt sind. Module können aber auch ohne Probleme selbst geschrieben werden, wenn man etwas Spring-Integ- ration- bzw. Spring-Batch-Know-how hat. Im Folgenden werden wir zunächst genauer auf Streams, Jobs und Taps eingehen und dabei die DSL zum Erzeugen von Streams und Jobs erläutern, um dann auf die spezielle, verteilte Architektur einzugehen. Zu guter Letzt werden wir zeigen, wie eigene Module ein- fach implementiert und verwendet werden können. Streams Eine Source ist dafür verantwortlich, Daten aus einer Quelle zu lesen. Spring XD bietet Sources für viele Tech- nologien, bisher sind die Moduldefinitionen http, tail, file, mail, twittersearch, twitterstream, gemfire, gemfire- cq, syslog-udp, syslog-tcp, reactor-syslog, tcp, tcp-cli- ent, rabbit, jms, time und mqtt vorhanden [2]. Ein Sink ist dafür verantwortlich, Daten aufzuneh- men. Für Sinks bietet Spring XD bisher die Modulde- finitionen log, file, hdfs, avro, jdbc, tcp, mail, rabbit, gemfire-json-server, splunk, mqtt und router. In zukünftigen Releases werden sicherlich noch viele weitere Module hinzukommen, außerdem ist es einfach möglich, selbst Module zu erstellen. Dies zeigen wir am Ende des Artikels. Technisch gesehen sind alle Stream- Module Spring-Integration-Module [3]. Unsere Anforderung ist es nun, Daten aus einem Log- file eines Webservers in unser Hadoop Distributed File System (HDFS) zu schreiben. Die Daten liegen dabei be- reits im JSON-Format vor (Listing 1). Wir verwenden das Source-Modul tail, das eine Datei überwacht und immer, wenn eine neue Zeile in die Datei geschrieben wird, diese an den Stream weiterliefert. Für das Schreiben verwenden wir das Sink-Modul hdfs. Spring XD hat eine eigene DSL zum Erzeugen von Streams, dessen Syntax an Unix Pipes und Filters an- gelehnt ist. Der folgende Code zeigt unseren Stream, wobei das tail-Modul mit dem Namen der Datei, aus der gelesen werden soll, parametrisiert ist. Spezielle Ein- stellungen für den Zugriff auf Hadoop werden nicht di- rekt der Stream-Definition mitgegeben, sondern in einer Konfigurationsdatei hadoop.properties abgelegt: tail --name=/tmp/logfile.json | hdfs Das Pipe-Symbol repräsentiert einen Message Channel, der, je nach Modus, unterschiedlich implementiert wird, siehe dazu den Abschnitt „Verteilte Architektur“. Spring XD stellt eine eigene Shell zur Verfügung, über die Kommandos zur Administration von Streams ab- gesetzt werden können. Listing 2 zeigt die wichtigsten Befehle in Bezug auf Streams, wobei hier jeweils von bei- spiel als Namen des Streams ausgegangen wird. Die XD Shell nutzt dafür das REST-API des XD-Adminservers. In einem weiteren Schritt soll ein zusätzlicher Processor hinzugefügt werden, der nur die Logmeldungen mit der Kategorie INFO durchlässt. Mit einem Processor können Daten beliebig manipuliert und gefiltert werden, Spring XD bietet aktuell dafür die Module filter, json-field-value-filter, transform, json-field-extractor, script, split- ter und aggregator. In unserem Fall verwenden wir den json-field- value-filter, der das JSON-Feld ca- tegory für die Filterung verwendet (Listing 3 und Abb. 1). Abb. 1: Darstel- lung des Streams „tail | json-field- value-filter | hdfs“ Listing 1 {"category":"INFO", "url":"http://server.local:8080/api", "duration":"200", "timestamp":"1354697760477", "http_code":"200", "message":"This is a logentry."} Listing 2 xd:> stream create --name beispiel --definition "tail --name=/tmp/logfile.json | hdfs" xd:> stream destroy --name beispiel xd:> stream undeploy --name beispiel xd:> stream deploy --name beispiel Listing 3 tail --name=/tmp/logfile.json | json-field-value-filter --fieldName=category  --fieldValue=INFO | hdfs © Software & Support Media GmbH 3 www.JAXenter.de javamagazin 4 | 2014
4. Agile Sonderdruck Taps und Real Time Analytics Mit einem Tap ist es möglich, an jeder beliebigen Stelle eines Streams Daten abzuzapfen und in Echtzeit zu ana- lysieren. Dabei gibt es zwischen dem abgehörten Streams und dem Tap keine Seiteneffekte. Dies bedeutet aber auch, dass ein Löschen des Streams nicht gleichzeitig auch die zugehörigen Taps entfernt. Das o. g. Beispiel lie- fert alle Logeinträge der Kategorie INFO ins HDFS. Wir wollen nun in Echtzeit ermitteln, wie viele Requests insge- samt aufgetreten sind. Da wir wissen, dass es genau einen Logeintrag pro Request gibt, hängen wir uns mit einem Tap in den Stream beispiel und leiten die Nachrichten an einen counter weiter, der diese zählt (Listing 4). Die zweite Metrik soll die durchschnittliche Antwort- zeit für alle Requests ermitteln. Dazu legen wir das Feld duration zugrunde und verwenden die Analysekompo- nente richgauge. Mithilfe des json-field-extractor extra- hieren wir aus dem Logeintrag das Feld duration und reichen es an die Metrik weiter. Richgauge ermittelt da- bei nicht nur laufend den Durchschnittswert, sondern auch Min- und Max-Werte sowie die Anzahl der ausge- werteten Werte (Listing 5). Neben den genannten gibt es die weiteren Analyse- komponenten field-value-counter, aggregatecounter und gauge. Technisch ist eine Analysekomponente ein Sink und kann so auch selbst geschrieben werden. Die Metriken sind über HTTP oder auch Redis (falls verwendet) abrufbar. Der weiteren Verarbeitung oder auch grafischen Visualisierung mit entsprechenden Tools steht hier also nichts mehr im Weg. Zur weiteren Veranschaulichung sei an dieser Stelle auch auf die Bei- spielprojekte von Spring XD verwiesen [4]. Topics/Queues Bisher haben wir lineare Datenströme betrachtet, die von einer Source in ein Sink schreiben. Was aber, wenn wir aus zwei Sources in ein Sink schreiben wollen (Abb. 2)? Und was, wenn wir aus einer Source gelesene Daten in zwei unterschiedlichen Streams weiterverar- beiten wollen? Hier kommen die Named Channel ins Spiel, von denen es zwei Ausprägungen gibt: Topic und Queue. Mit folgendem Code erzeugen wir insgesamt drei Streams, wobei die ersten beiden ihre Nachrichten nicht in ein Sink, sondern in die queue: logEntries schreibt. Der dritte Stream liest die Nachrichten aus der Queue und schreibt sie ins HDFS: tail --name=/tmp/logfile1.json > queue:logEntries tail --name=/tmp/logfile2.json > queue:logEntries queue:logEntries > hdfs Listing 4 xd:> stream create --name beispielcount --definition "tap:stream:beispiel > counter --name=requestcount" Listing 5 xd:> stream create --name beispielaverage --definition "tap:stream:beispiel > json-field-  extractor --fieldName=duration | richgauge --name=averageduration" Listing 6 xd:> job create --name fileToHdfsJob --definition "filepollhdfs --names=forename, surname,address" Listing 7 xd:> job launch myjob xd:> stream create --name cronStream --definition "cron-trigger --cron='0/5 * * * * *'  --payload='{"param1":"Kenny"}' > queue:job:myjob" xd:> stream create --name csvStream --definition "file --ref=true --dir=/mycsvdir  --pattern=*.csv > queue:job:fileToHdfsJob" Listing 8 xd:> stream create --name jobNotifications --definition "queue:job:myjob-notifications > log" Abb. 2: Bei- spiel-Stream mit Queue © Software & Support Media GmbH 4 www.JAXenter.de javamagazin 4 | 2014
5. Agile Sonderdruck Als Nächstes erzeugen wir ebenfalls drei Streams, wo- bei der erste seine Nachrichten in das topic: logEntries schreibt, während die anderen beiden Streams die Nach- richten ins HDFS bzw. eine Datenbank schreiben. Da es ein Topic ist, erhalten beide Streams alle Nachrichten des ersten Streams: tail --name=/tmp/logfile.json > topic:logEntries topic:logEntries > hdfs topic:logEntries > jdbc Jobs Neben Streams, in denen Einzeldatensätze transportiert und verarbeitet werden, sieht Spring XD noch Jobs vor. Die technologische Basis ist dabei Spring Batch [5]. Für Jobs bietet Spring XD eine eigene Adminoberfläche, über die Jobs überwacht, gestartet und gestoppt werden können [2]. Da Jobs in der Regel anwendungsfallspezifischer sind, gibt es hier nicht so viele vorgefertigte Module wie im Stream-Bereich, aktuell sind das fünf: filejdbc für den Import von Daten aus einer Datei in eine relationale Da- tenbank, hdfsjdbc/jdbchdfs für den Export von Daten aus einem Hadoop Distributed File System (HDFS) in eine relationale Datenbank und umgekehrt, hdfsmon- godb für den Export von Daten aus einem HDFS in eine MongoDB und filepollhdfs für den Import von Daten aus einer CSV-Datei in ein HDFS. Bei der Erstellung eigener Job-Module können alle Features und Kompo- nenten von Spring Batch genutzt werden. Über Spring for Hadoop können auch Hive- und Pig-Skripte einfach durchgeführt werden. Listing 6 zeigt die Erzeugung eines Jobs vom Typ file- pollhdfs. Dabei werden mit dem Parameter names die Werte aus der CSV-Datei definiert, die ins HDFS impor- tiert werden sollen. Jobs können ad hoc, mit einem Cron Trigger und durch einen Stream gestartet werden, Listing 7 zeigt alle diese Varianten. In der zweiten Variante wird gezeigt, wie Job-Parameter übergeben werden können. Im Fall des Moduls filepollhdfs macht die dritte Variante Sinn, da dieses Modul die Input-CSV-Datei über einen Stream erwartet. Für jede Datei, die in das Verzeichnis my­csv­ dir kopiert wird, wird ein Job gestartet. Soll ein Job deaktiviert werden, kann er wie die Streams undeployt werden. Bisher haben wir gesehen, wie ein Job durch einen Stream gestartet werden kann. Ein Job kann seinerseits aber auch Nachrichten in Streams schreiben. Dafür er- hält jeder Job, der in Spring XD deployt wird, einen no- tifications Channel. Listing 8 zeigt, wie Nachrichten aus dem notifications Channel des Jobs myjob als Source für einen Stream verwendet werden können. Im Prinzip können beliebige Daten in den notifications Channel geschrieben werden, aber es gibt einige vorge- fertigte Spring Batch Listener, die allgemein definiert werden und deswegen immer genutzt werden können. So schreibt der SimpleXdJobExecutionListener bei- spielsweise am Ende des Joblaufs die JobExecution in den Channel, sodass ausgewertet werden kann, ob der Joblauf erfolgreich war, wie viele Items verarbeitet wur- den etc. Abbildung 3 zeigt ein System, in dem Batch-Jobs durch einen Stream gestartet werden und in dem Fall, dass der Joblauf fehlschlägt, eine Mail versendet wird. Verteilte Architektur Im einfachsten Fall wird Spring XD im Single-Node-Be- trieb gestartet. Für den schnellen Einstieg in diese neue Technologie und die lokale Ausführung auf einem Ent- wicklungsrechner ist dies genau der richtige Modus. In einer produktiven Umgebung sollte jedoch Spring XD im verteilten Multi-Node-Betrieb installiert werden. In- nerhalb von XD wird zwischen dem Adminserver und dem Container-Server unterschieden, die übrigens seit kurzer Zeit mit dem noch relativ jungen Framework Spring Boot [6] betrieben werden. Die in der XD Shell abgesetzten Kommandos werden immer vom Adminserver entgegen genommen, der dann dafür sorgt, dass die entsprechend notwendigen Modu- le auf den Containern auch zur Verfügung stehen und auf Daten warten. Die Distribution Integration Runtime (DIRT) ist für die Verteilung der Aufgaben auf die ver- Abb. 3: Batch-Job und Streams © Software & Support Media GmbH 5 www.JAXenter.de javamagazin 4 | 2014
6. Agile Sonderdruck schiedenen XD-Container-Instanzen zuständig. Als Datentransport kann aktuell Redis oder RabbitMQ genutzt werden. Bei der Anlage eines Streams über die bekannte XD Shell wird also ein HTTP-Request zum Adminserver gesendet, der dann die Streams analysiert, in einzelne Moduldefinitionen zerlegt und diese dann in eine Redis oder RabbitMQ Queue einstellt (siehe auch Abb. 4). Die Deployment Requests werden dann nach einem Round-Robin-Verfahren von den einzelnen In- stanzen aufgenommen und das entsprechende Modul wird installiert. Bei einem Modul handelt es sich letztendlich um ei- nen Spring Application Context, der in dem Container hochgefahren wird und die Spring Integration Endpoints oder auch den Spring-Batch-Job zur Verfügung stellt. Diese Art von Kommunikation erfolgt in Spring XD immer über den so genannten Control Bus. Die eigentli- chen Daten zur Verarbeitung laufen über den separaten Data Bus (Abb. 5). Seit dem Milestone 5 können die Bus-Systeme parallel auch mit verschiedenen Transport- technologien betrieben werden (z. B. Control Bus nutzt Redis und der Data Bus nutzt RabbitMQ). Mit dieser verteilten Architektur ist der Transport der einzige Fak- tor, der die Skalierbarkeit beschränkt. Module können gruppiert werden, sodass bestimmte Module immer zusammen in einem Container deployt werden. Das verringert das benötigte Transportauf- kommen. In Zukunft wird es auch möglich sein, zu be- stimmen, auf welchem Server welche Module installiert werden. So können starke Container die Batch-Aufga- ben übernehmen, während andere Container nur Daten sammeln. Neben dem manuellen Installationsverfahren für die XD-Container-Instanzen sind bereits weitere in Ent- wicklung, so zum Beispiel zum Deployment nach Cloud Foundry oder über YARN in einen Hadoop-Cluster. Erweiterbarkeit Bisher haben wir viel über Streams und Jobs im Allge- meinen und die vorgefertigten Module gesprochen. Bei der Lösung von Real-World-Problemen wird man ver- mutlich aber immer an den Punkt stoßen, an dem die vorgefertigten Module nicht mehr ausreichen. Wie er- weitert man also Spring XD um eigene Module? Implementierung des eigenen Moduls Jedes Spring-XD-Modul wird in einem eigenen Spring Application Context betrieben, so wundert es nicht, dass man diesen zumindest zum Teil bereitstellen muss. Die Modultypen Source, Processor und Sink werden dabei mithilfe von Spring Integration erstellt. Listing 9 zeigt eine Definition eines Processors, der Nachrichten mit ei- nem eigenen MessageSelector filtert. Der LOFMessage­ Selector verwendet dabei den LOF-Algorithmus, um Nachrichten zu klassifizieren, und leitet nur ungewöhn- liche Nachrichten weiter [7]. Jeder Modultyp hat einige wenige Konventionen, im Fall des Processors müssen ein Channel mit ID input und ein Channel mit ID output vorhanden sein, über die der Message Flow zu und von anderen Modulen läuft. Eine Source benötigt einen Channel mit ID output, ein Sink einen Channel mit ID input. In einem Job-Modul muss ein Spring-Batch-Job mit der ID job definiert sein. Registrierung des eigenen Moduls Für das Ermitteln von Modulen nutzt Spring XD das Strategieinterface ModuleRegistry. Default ist dabei zur- zeit die FileModuleRegistry, die Module im Dateisystem ermittelt. Durch die Installation von Spring XD wird das Verzeichnis modules erstellt. Dieses Verzeichnis hat für jeden Modultyp ein Unterverzeichnis, also source, sink, processor und job. Wollen wir nun unseren erstellten Processor bereitstellen, kopieren wir die Application- Context-XML-Datei in das Verzeichnis processor. Benötigt unser Modul eigene Bibliotheken, die Spring XD nicht mitliefert, so können diese so bereitgestellt werden, dass sie nur in einem eigens für das Modul ver- wendeten Classloader zur Verfügung stehen. So können Listing 9 <beans:beans xmlns...> <channel id="input"/> <filter input-channel="input" output-channel="output"> <beans:bean class="de.codecentric...LOFMessageSelector"> <beans:constructor-arg name="dimensions" value="${dimensions:3}"/> </beans:bean> </filter> <channel id="output"/> </beans:beans> Listing 10 xd:> stream create --name filterStream --definition "http | customFilter –-dimensions=4 | file" Abb. 4: Multi-Node-Betrieb mit Admin- und Containerservern © Software & Support Media GmbH 6 www.JAXenter.de javamagazin 4 | 2014
7. Agile Sonderdruck unterschiedliche Module unterschiedliche Versionen von gleichen Bibliotheken ver- wenden. Im obigen Beispiel müsste min- destens die Klasse LOFMessageSelector entsprechend bereitgestellt werden. Es ist zu erwarten, dass es neben die- ser Dateisystemvariante in Zukunft noch weitere, zentralere Varianten zur Bereit- stellung von Modulen geben wird. So gibt es bereits eine RedisModuleRegistry. Nutzung des eigenen Moduls Wir haben schon gesehen, dass Module parametrisiert erzeugt werden können. In Listing 10 sieht man, dass der Wert für das Konstruktorargument dimensions über einen Property Placeholder dimen- sions mit Default-Wert 3 aufgelöst wird. Dieser Wert kann bei der Erzeugung des Moduls gesetzt werden. Das Listing zeigt einen Stream mit einer http – Source und einem file – Sink, bei dem die Nachrichten durch unser neues Modul gefiltert werden. Der Name des Mo- duls ist dabei der Dateiname der Application-Context- XML-Datei (customFilter.xml), wobei die Dateiendung .xml abgeschnitten wird. Fazit Spring XD erleichtert das Erstellen von jeglichen An- wendungen, in denen Daten fließen müssen, kontinuier- lich oder im Batch, 100 000 pro Sekunde oder einmal täglich. Spring XD ist dabei kein Framework, sondern eine Laufzeitumgebung, in die man bestimmte Module deployen kann. Wenn man so will, ist Spring XD ein verteilter Application Server für Spring-Integration- und Spring-Batch-Module. Zusätzlich dazu definiert Spring XD eine DSL für die Erzeugung der Datenströme und Jobs und liefert viele Module für die meisten relevanten Technologien out of the box mit, sodass viele Anwen- dungsfälle schnell und ohne Spring-Know-how abge- deckt werden können. Mit dem Adminserver gibt es ein gutes UI für das Überwachen von Jobs. Basis des Artikels ist der Milestone 5, und der macht bereits einen vielversprechenden Eindruck. Auch die Tatsache, dass Spring XD einen zentralen Part im Exe- cution Layer der neuen Spring-IO-Strategie von Pivotal einnimmt, lässt hoffen [8]. Die technische Dokumenta- tion ist bereits umfassend und gut [2], und Spring XD ist über Spring for Hadoop mit den Hadoop-Distribu- tionen Cloudera CDH, Pivotal HD und Hortonworks HDP zertifiziert. Gute Voraussetzungen dafür, im Big-, Fast-Data- und Real-Time-Analytics-Umfeld eine inter- essante Rolle spielen zu können. Tobias Flohre arbeitet als Senior-Softwareentwickler bei der code- centric AG. Seine Schwerpunkte sind Java-Enterprise-Anwendun- gen und Architekturen mit JEE/Spring, häufig mit Fokus auf Spring Batch. Er spricht regelmäßig auf Konferenzen und bloggt auf blog. codecentric.de. tobias.flohre@codecentric.de Dennis Schulte ist seit 2009 als Senior IT Consultant bei der code- centric AG tätig. Er unterstützt seine Kunden insbesondere im Be- reich Enterprise-Architekturen und der Optimierung von IT-Prozessen. Aufgrund seiner langjährigen Erfahrung als Architekt und Entwickler verfügt er über ein umfassendes Wissen im Bereich Java EE und Open-Source-Technologien und hier insbesondere im Umfeld Spring Batch und Massendatenverarbeitung. Seine Projektschwerpunkte liegen in der Architektur- beratung und der Durchführung von Projekten im Versicherungsumfeld. Abb. 5: Detaillierter Blick auf aktive Module codecentric AG Kölner Landstraße 11 40591 Düsseldorf Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444 E-Mail: info@codecentric.de www.codecentric.de blog.codecentric.de Links & Literatur [1] http://projects.spring.io/spring-xd/ [2] https://github.com/spring-projects/spring-xd/wiki/Technical- Documentation [3] http://projects.spring.io/spring-integration/ [4] https://github.com/spring-projects/spring-xd-samples [5] http://projects.spring.io/spring-batch/ [6] http://projects.spring.io/spring-boot [7] https://github.com/codecentric/spring-xd-playground [8] http://spring.io/platform