Modern Batch

Frank Hinkel: Ja, ich bin der Frank Hinkel. Ich arbeite bei der innoQ und bin da als Berater und Entwickler tätig. Schwerpunktmäßig mit den Themen Java-Technologie und Architektur beschäftigt.

Stefan Tilkov: Ok. Das Thema, über das wir reden wollen, ist Batch- Verarbeitung. Vielleicht kannst du uns ein bisschen von deiner Historie erzählen, wie du dazu gekommen bist, dich ausgerechnet für dieses Thema zu interessieren.

Frank Hinkel: Ja, das hat mehrere Ursachen. Einmal habe ich eben auch in meiner beruflichen Laufbahn einige Batches implementiert – einmal im Bereich der Dokumentenverwaltung und einmal bei einer Dunkel-Policierung in Lebensversicherungen.

Stefan Tilkov: Super Wort: Dunkel-Policierungen. Großartig.

Frank Hinkel: Genau. Ja, das waren halt große Datenmengen, die da verarbeitet wurden und letzteres war halt meine Tätigkeit in einem Architekturteam, wo ich eine Batch-Architektur und Infrastruktur modernisiert habe. Wo wir quasi von der Mainframe-Batch-Architektur zu einer Distributed sind.

Stefan Tilkov: Also lass uns doch mal mit der Definition starten. Was ist denn Batch-Verarbeitung? Ist das, wenn ich eine CMD-Datei auf meinem Windows-System schreibe oder meinen wir damit was anderes?

Frank Hinkel: Ja, das ist eine gute Frage, weil hier ist mir häufig eine unterschiedliche Auffassung dieses Begriffs begegnet. Ursprünglich kommt das ja eigentlich aus dieser Lochkartenverarbeitung, weil man ganz früher ja diese Stapel mit Lochkarten hatte, die dann durch eine Rechenmaschine geschoben wurden. Und ja insbesondere in der Mainframe-Welt gibt’s noch sehr viele Batches – jetzt nicht mehr mit Lochkarten – aber im Grunde sind dort alle Programme, die keinen Dialog haben – kein Dialogsystem und keine Benutzerinteraktion – Batches. Egal wie viele Datenmengen dort verarbeitet werden, das sind per se erstmal Batches. Und wir aus der Distributed Welt, wir denken bei einem Batch an riesen Datenmengen. Und so kleinere Sachen, die jetzt einfach ohne Interaktionen laufen, die könnten wir jetzt auch beispielsweise in einem kleinen Quartz-Job schedulen. Das wäre nicht direkt so ein riesen Massenverarbeitungsprogramm, was auch ganz andere Anforderungen hat.

Stefan Tilkov: Was meinst du mit modern, wenn du sagst „Modern Batch“?

Frank Hinkel: Ich meine damit erstmal aktuelle Laufzeitumgebung, wie z.B. gängige Webserver. Einsatz von Frameworks oder der Java-Technologie beispielsweise. Dann, dass man weg von diesen Batch-Fenstern kommen will. Das ist so ein Trend – einer von vielen –, der sich im Bereich Batch etablieren. Man hat immer so Batch-Fenster, wo dann die Online-Welt runter gefahren wurde und dann liefen die Batches. Da jetzt auch 24/7 Bereitschaft oder auch Online-Fähigkeit angestrebt wird, ist das halt dem im Wege. Und gleichzeitig möchte man weg von großen Transaktionen. Dahin wandelt sich das ganze Verfahren hin zu kleineren Prozessen, zu Message-orientierten Batch- Verfahren, die die Frameworks auch unterstützen. Da werden dann große Datenmengen gesplittet, verarbeitet und am Ende wieder zusammengeführt, in kleinen Häppchen verarbeitet, eventuell auch parallel zum Online-Betrieb. Und ja, horizontale Skalierung, Lastverteilung, das ist auch ein Thema in der modernen Batchverarbeitung. Und die ganzen Themen bringen halt neue Herausforderungen mit sich.

Stefan Tilkov: Also ich kann mir gut vorstellen, dass es einigen Hörern vielleicht gar nicht so bewusst iStefan Tilkov: in der klassischen, echten Datenverarbeitung, wo man auch wirklich deutsche Begriffe verwendet, ist das ein ganz entscheidener Punkt. Also der wesentliche Teil der Daten, die für uns verarbeitet werden, von den Dienstleistern, mit denen wir zu tun haben – von Banken, Versicherungen und von Behörden und anderen – der überwiegende Anteil davon erfolgt tatsächlich immer unter Abhängigkeit von solchen Batch-Prozessen. Wo irgendeine Datei gelesen wird, dann wird da zwei Stunden gearbeitet und eine neue Datei geschrieben, die dann vielleicht wieder in einen anderen solchen Batch-Lauf hinein kommt und das ist der absolut übliche Vorgang.

Frank Hinkel: Genau, da gibt’s dann noch gerade in Großunternehmen tausende von Batch-Ketten, die täglich laufen. Und das ist auch ein ganz wichtiges Asset für die Unternehmen. Also fest verdrahtet in deren Geschäftsprozessen.

Stefan Tilkov: Wenn wir uns jetzt das vorstellen, also wir haben diese klassische Welt, die Mainframe-Welt, wo die Verarbeitung auf diese Art und Weise funktioniert. Wir haben dieses ganze moderne Zeug, mit dem wir uns ja normalerweise beschäftigen. Hat das Sinn diese beiden Welten miteinander zu verknüpfen, zu kombinieren oder muss man sich exklusiv für eine entscheiden?

Frank Hinkel: Also gewissermaßen ist man oftmals sogar dazu gezwungen, die zu kombinieren. Weil wir haben ja gerade gesagt, die Unternehmen haben diese riesigen Batch-Netze, die haben da ihre Assets. Und jetzt kommen neue Produkte auf den Markt, neue Standardsoftware, welche einfach nicht auf den klassischen Systemen laufen. Die aus der Java-Welt beispielsweise sehr leicht zu erreichen sind und deswegen auch eine Integration in diese Technologien brauchen. Hinzu kommen, demografische Gründe. Also Java- Entwickler kommen frisch von der Uni, beispielsweise COBOL-Entwickler sind schwerer zu finden. Dann halt auch gewisse Strategien. Java-Prozessoren sind auf einigen Maschinen günstiger als COBOL-Prozessoren. Da gibt’s also auch Strategien, die einen dazu bewegen, sowas zu tun. Ansonsten gibt es im Grunde verschiedene Ansätze das zu tun, das zu kombinieren. Es gibt ein beispielsweise Quick-and-Dirty Ansatz, den wir auch mal ausprobiert hatten, in der Vergangenheit oder den ich mal ausprobiert hatte. Der war sehr sehr Dirty. Das Dirty groß geschrieben. Was man da macht ist im Grunde auf einem Mainframe eine JVM zu starten pro Batch. Und das bringt natürlich Speicherallokationen mit sich und das will man als Betriebler auf dem Mainframe nicht sehen, das ein Entwickler speicher allokiert. Das wollen die nicht, das ist problematisch da. Bringt diverse Sicherheitskonzepte durcheinander und das verlangsamt auch die Entwicklungszeit, da ja das Starten einer JVM pro Batch-Lauf teilweise relativ lange dauern kann. Also wenn ich jetzt einen Batch habe, der zwei Sekunden dauert – das Starten der JVM dauert zehn oder 15 – dann steht das in keinem Verhältnis.

Stefan Tilkov: Dauert das Starten einer JVM wirklich zehn oder 15?

Frank Hinkel: Also ich hatte einige, da war das. Das hat wirklich so lange gedauert. Bis alles hochgefahren war, bis alles allokiert war, der Speicher reserviert. Also diese Ramp-up-Phase bis zum Start des Jobs, die war relativ lang.

Stefan Tilkov: Ok.

Frank Hinkel: Ja da gibt es halt – das ist diese Quick-and-Dirty Variante, wo ich sage, die geht relativ schnell. Eine andere Variante, die meiner Meinung nach wesentlich besser ist, ist die Verwendung eines Webservers, der beispielsweise auch auf einem virtuellen Linux auf dem Mainframe laufen kann. Also man hat dann so eine Art distributed auf einem Unix. Auf einem Z/OS dann. Da gibt’s auch ein paar Nachteile, das ist aus meiner Sicht aber die bessere Variante.

Stefan Tilkov: In gewisser Weise ist das so eine Art sehr sehr großer Bruder eines vorgestarteten Prozesses auf einem Unix-System, ne? Also wenn ich auf einem Unix-System Prozesse starten will, dann will ich nicht bei jedem Aufruf erneut dafür bezahlen, dass der Prozess gestartet werden muss. So ähnlich will ich hier eine komplette Umgebung, eine komplette Maschine starten, um das ganze zu machen und dann da rein rufen zu können, anstatt diesen Start-up-Overhead jedes Mal wieder zu zahlen.

Frank Hinkel: Genau.

Stefan Tilkov: Also damit meinst du jetzt mit Integration von Batch, von der Distributed- und Mainframe-Welt, dass ich jetzt vor allem Geschäftslogik, die ich mit einer modernen Programmiersprache – in der Regel wird das dann Java sein – implementiert habe, die dann eben in so eine Batch-Verarbeitung einbetten kann, die ich aber auf dem Mainframe immernoch steuere. Also diese ganze Job-Kontrolle, das Batch-Netz, das Job-Netz, das da verwaltet wird – mit den entsprechenden Tools, die es zum Teil seit was weiß ich 25 oder 30 Jahren gibt – wird einfach erweitert um eine Komponente, um einen Batch, der in einer anderen Programmiersprache entwickelt wurde.

Frank Hinkel: Richtig. Und im Batch-Netz selber wäre dann auch so ein Job oder so ein Programm genau wie jedes andere. Also man könnte drei – weiß ich nicht – COBOL-Batches laufen lassen, dann einen Java-Batch, der dann tatsächlich auf einem Webserver läuft, und dann wieder einen COBOL-Batch. Das könnte man halt miteinander kombinieren an der Stelle.

Stefan Tilkov: Gut, was hat das für Vor- und Nachteile, wenn man das macht?

Frank Hinkel: Ja, Vorteile, auf einem Webserver das ganze laufen zu lassen, ist natürlich, dass man nah an der Online-Variante ist. Man kann dort profitieren von den ganzen Konzepten, die dahinter stecken, wie z.B. der Application-Live-Cycle, Deployment, Release-Verfahren. Das würde man alles mitnehmen, wenn man diese Quick-and-Dirty Variante macht, dann muss man sich selber darum kümmern. Da könnte man Dinge wiederverwenden. Dann hat man halt das ganze Programm eines Web-Servers, was einem zur Verfügung steht: Logging, Monitoring, worauf man zurückgreifen kann. Ja, das sind so aus meiner Sicht wesentliche Vorteile an dieser Stelle.

Stefan Tilkov: Für welchen Anwendungsfall würdest du das sehen? Also was sind typische Fälle, wo so ein Ansatz passt?

Frank Hinkel: Ja, Anwendungsfälle sind beispielsweise Schriftverkehr, Brieferstellung, Dunkel-Policierung – haben wir ja auch schon genannt –, Statistiken. Klassischerweise gibt’s halt aber immer die gleichen Schritte. Also unabhängig davon, was ich für einen fachlichen Anwendungsfall habe, habe ich immer die gleichen Schritte im Prinzip. Es gibt immer ein Sortieren, es gibt ein Extrahieren und ein Aggregieren. Und meistens ist es eine Kombination davon oder nur eins. Und die bilden dann meistens die fachlichen Fälle halt ab.

Stefan Tilkov: Also der entscheidene Punkt ist glaube ich bei all diesen Batches, dass man die selbe Operation für eine Vielzahl von Elementen macht.

Frank Hinkel: Genau.

Stefan Tilkov: Hast du Erfahrung auf dem Mainframe damit, sowas zu parallelisieren?

Frank Hinkel: Nee. Parallelisiert haben wir da tatsächlich nicht. Soweit waren wir da noch nicht.

Stefan Tilkov: Achso, ok. Was habt ihr denn sonst noch so für Probleme gehabt mit dem ganzen Ansatz.

Frank Hinkel: Ja, Probleme. Also erstmal gibt es relativ viele Points-of- Failures. Man hat viele involvierte Resourcen, Randsysteme, die Applikation selber, hat den Job. Allen Parteien kann es da irgendwo schlecht gehen und auch die Steuerdatenbank kann kaputt sein mit irgendwelchen Meta- Informationen. Und das Problem, was man da hat, ist, dass dort gerade im Betrieb die Erfahrung fehlt. Wenn man sich jetzt so einen Betrieb vorstellt, der riesen Batch-Netze verwaltet, die haben jahrzehntelange Erfahrung. Die wissen ganz genau, wie sie das System zu verstehen haben und können oftmals auch rettend eingreifen. Wenn die da um drei Uhr nachts im Batch-Fenster das ganze überwachen und es geht was schief, können die rettend eingreifen. Wenn man jetzt mit so eine völlig neuen Infrastruktur um die Ecke kommt, geht das halt verloren. Und da kann man beispielsweise, also man muss Know-How aufbauen, meiner Meinung nach, und da kann man beispielsweise so ein schwarzes Schaf implementieren, was z.B. alle möglichen Fail-over Szenarien durchgeht. Und dann mit den Leuten, die dann damit zu tun haben, mit dem System, ja die Leute dann darauf vorzubereiten und zu erkennen, wie sich das System verhält.

Stefan Tilkov: Ok.

Frank Hinkel: Und letztendlich ist auch die Aktzeptanz und die Bedienbarkeit vom Betrieb ein entscheidener Faktor für den Erfolg der Batches.

Stefan Tilkov: Was für Technologien gibt’s, die man da einsetzen kann? Irgendwelche Frameworks oder Tools oder Standards oder ähnliches?

Frank Hinkel: Ja, es gibt einige Frameworks. Es gibt auch ein JSR 352, der implementiert wird. Die versuchen halt immer – also das was Frameworks halt machen – immer wiederkehrende Funktionalitäten oder Gemeinsamkeiten zu standardisieren, sodass man nicht immer wieder das Rad neu erfinden muss. Soll in der Vergangenheit oft so gewesen sein, dass sich die Leute eigene Batch-Frameworks geschrieben haben, weil es keine gab. Und dieser JSR und auch andere Frameworks, die addressieren Themen, wie „Checkpointschreibung“, „Wiederaufsetzbarkeit“, „Automatischen Aussortieren“, Standard IO Komponenten werden da vorgegeben. Und ja der ganze Ablauf lässt sich halt konfigurieren. Das ist so ein bisschen das Hollywood-Prinzip, was da eingeflossen ist. Man programmiert sein kleines Modul, setzt das irgendwo rein und das wird dann aufgerufen von einer Ablauflogik, die man nicht programmiert hat, sondern man eigentlich nur konfiguriert hat.

Stefan Tilkov: Und dieses Framework außenrum ist natürlich oder aller Wahrscheinlichkeit nach auf vielen verschiedenen Umgebungen einsetzbar, sodass ich eben dieselbe Geschäftslogik ablaufen lassen kann, egal ob es jetzt auf einem Mainframe läuft, in einer bestimmten Umgebung läuft, ob es direkt auf einem Unix-System läuft oder ob es auf einem Windowsrechner oder sonst irgendwo läuft – das Framework abstrahiert sozusagen die Details der Umgebung entsprechend weg.

Frank Hinkel: Ja klar. Also die Infrastruktur wird davon vollständig abstrahiert, richtig.

Stefan Tilkov: Ein Teilaspekt, den du grad so ein bisschen nebenbei erwähnt hast, das war Wiederaufsetzen. Wie verhält sich es denn mit Transaktionalität und mit Transaktionen im Batch? Das fand ich immer ein relativ spannendes Thema.

Frank Hinkel: Ja, ist auch ein spannendes Thema, gerade Transaktionen auch wieder, wenn man jetzt die beiden Welten miteinander vergleicht. Denn wenn man sicht jetzt einen klassischen Host-Entwickler anguckt, dann ist für den eine Transaktion keine große Sache. Die ist in einem Fingerschnipp ist die durch. Wenn man jetzt aus der Webentwicklung kommt, dann hat man bei Transaktionen direkt ein bisschen – naja Angst will ich jetzt nicht sagen, aber die Alarmglocken schlagen. Ja, was macht man da? Man kann verschiedene Möglichkeiten dort einstellen. Also es gibt die Möglichkeit Chunks zu machen und dann eben Commit-Intervalle zu setzen, pro …

Stefan Tilkov: Lass und vielleicht mal eine Stufe zurück gehen.

Frank Hinkel: Ok.

Stefan Tilkov: Warum ist es eine schlechte Idee, wenn ich 15 Millionen Versicherungskunden verwalte und verarbeite, für jede einzelne Verarbeitung eine Transaktion zu machen? Das wäre dort einfach das naheliegenste, oder?

Frank Hinkel: Für jeden?

Stefan Tilkov: Für jede Einzelverarbeitung eine einzelne Transaktion zu machen. Also auch Chunking und sowas zu verzichten. Warum macht man das nicht?

Frank Hinkel: Ja, weil das halt total langsam wäre, wenn ich…

Stefan Tilkov: Warum wäre das total langsam? Also es ist vielleicht total offensichtlich, aber warum? Was ist der Grund, warum man das nicht tun will?

Frank Hinkel: Ja, weil das Schreiben allein der Meta-Informationen, dass ich jetzt den Monitor und den Lock setze auf die Datenbank und den wieder freigebe, total zeitintensiv ist. Wenn ich 10 Millionen Datensätze habe und für jeden einzelnen dieser 10 Millionen Datensätze einen Lock auf mache und einen Lock wieder schließe, dann würde das total lange dauern.

Stefan Tilkov: Genau. Also es ist wirklich zu schade, dass wir hier kein Video drehen, weil dein Gesichtsausdruck, als ich das gerade gefragt habe. Das war wirklich das blanke Entsetzen.

Frank Hinkel: Ich war wirklich schockiert.

Stefan Tilkov: Ok. Also das ist keine gute Idee 10 Millionen Transaktionen zu machen. Warum ist es denn eine schlechte Idee eine Transaktion zu machen für die 10 Millionen Kunden?

Frank Hinkel: Ja, also man kann ja davon ausgehen, wenn ich jetzt 10 Millionen Datensätze habe, dass einer dabei ist, der nicht korrekt ist. Das ist ja nicht sehr unwahrscheinlich. Wenn ich jetzt nur ganz am Ende die Transaktion schließe, dann würde ein Rollback stattfinden bis zum kompletten Anfang. Ich könnte keine konsistenen Zwischenschritte einsetzen, wo ich sagen könnte: „Roll nur ein Stück zurück und setz dann da wieder auf.“ Andereseits, ein anderer Nachteil ist auch, dass ich halt über den gesamten Zeitlauf des Batch-Laufs alle Resourcen, die ich in dem Zusammenhang brauche, geblockt hätte. Und damit steigt natürlich auch die Wahrscheinlichkeit eines Dead-Locks immens.

Stefan Tilkov: Und es mag natürlich auch sein, also vielleicht ist das jetzt auf dem Mainframe nicht so üblich, aber in den Umgebungen, die ich so kenne, ist es auch eine ganz schön große Angelegenheit. Man kann also nicht davon ausgehen, dass man die Resourcen tatsächlich hat. Die System-Resourcen, die man braucht um so eine riesen Transaktion zu fahren. Ok, d.h. der Mittelweg liegt irgendwo dazwischen. Wir müssen in irgendeinenr Form segmentieren und das ist ein Ding, das ist das, was du mit Chunking meintest, was die Batch- Frameworks sozusagen mit liefern.

Frank Hinkel: Genau, das ist sozusagen die technische Variante diese Transaktionsproblematik zu lösen. Es gibt auch andere Varianten, wo man sich sagt, man macht eine fachliche Transaktion. D.h., man zerteilt einen großen Batch in mehrere Schritte und quittiert dann einfach, dass man einen gewissen Datensatz gelesen hat. D.h., man hat dann nicht eine große Transaktionsklammer, sondern mehrere kleine. Muss sich dann programmatisch aber darum kümmern, dass alles konsistent ist. Das ist anspruchsvoller, man muss sich vorab viele Gedanken machen, wie man das umsetzt, aber letztendlich ist das wesentlich robuster und stabiler. Also das ist oft ein gängiges Prinzip, wie man das bei großen Datenmengen macht.

Stefan Tilkov: Bieten die Frameworks da auch irgendeine Unterstützung, die Frameworks, die du kennst?

Frank Hinkel: Das Zerlegen in fachliche Transaktionen, da kann man halt Chunks, Steps usw. verwenden. Also da kann man halt ein bisschen das ganze Zerlegen, das ein bisschen granularer machen. Aber die Frameworks gehen eher in die Richtung, dass sie technisch unterstützen.

Stefan Tilkov: Was wären denn Beispiele für solche Frameworks, also hast du ein paar konkrete Namen?

Frank Hinkel: Ja klar. Der Klassiker ist ja im Grunde Spring Batch. Spring Batch ist ja mehr oder weniger auch die Vorlage für die JSR-Spezifikation. Und ich denke auch das meist verwendete Batch-Framework im Java-Umfeld.

Stefan Tilkov: Ok. Gut, haben wir noch anderes. Logging und Monitoring hast du glaube ich schon erwähnt, Wiederaufsetzen, Wiederanlauf. Das ist vielleicht auch so eine Sache, die ich mal ganz interessant fand. Durch die Art und Weise, wie man das auf dem Mainframe verarbeitet, gibt es ganz typischerweise Ergebnisdateien, also da wird ein Batch gestartet und als Ergebnis entsteht irgendwo was oder in einem Bereich wird irgendwas reingespult oder da ist irgendwie das Ergebnis. Und wenn da was abstürzt oder hängt, dann kann man das einfach nochmal starten. Also dann wird dieses Ergebnis weg geschmissen und man startet es einfach nochmal und wenn es dann durchgelaufen ist, läuft die Verarbeitung entsprechend weiter. Was ist mit so einem Szenario, wo man alles auf einer großen Datenbank macht? Wie ist das auf Systemen, wo das gar nicht so leicht ist, das Wiederanlaufen. Es gibt nicht sozusagen ein System-inherentes zurücksetzen, indem man einfach das Ergebnis nicht schreibt oder nicht weiter verarbeitet. Es ist einfach schon passiert, das finde ich einen ganz interessanten Unterschied in den Dingern.

Frank Hinkel: Ja was auch noch interessant ist in dem Zusammenhang, auch im Hinblick nochmal auf die Frameworks, ist halt dieses automatische Aussortieren. Und das ist auch aus meiner Sicht einer der größten Vorteile von dem Spring Batch Framework. Denn wenn man sich vorstellt – wir sind jetzt wieder bei den 10 Millionen Datensätzen – wir sagen, wir haben Batch- Fenster von fünf Stunden pro Nacht und nach einer Stunde stürtzt der Batch ab, es gibt einen Fehler. Und jetzt weiß man natürlich „Ok super. Wir haben Rollback, wir haben Checkpoint, wir müssen nicht mehr alle 10 Millionen Datensätze, sondern nur noch 9 Millionen oder so.“ Letztendlich hat man aber die fünf Stunden Batch-Fenster verloren. Und gerade bei so großen Datenmengen geht man ja davon aus, dass nicht alles richtig ist, sondern dass manuell irgendwas nachbearbeitet werden muss. Und ja hier hilft dann so eine automatische Aussortierung. Da kann man konfigurieren „Wenn der oder der Fehler auftritt, dann reagiere irgendwie anders.“ Und dann kann man halt sich das so einstellen, dass gewisse Datensätze dann woanders landen und dann diese Datensätze im nachhinein nochmal nachbearbeitet werden können, sodass der Batch komplett durchlaufen kann, das Zeitfenster wird ausgenutzt und man verliert einfach genau das halt nicht. Und das ist halt etwas, was meiner Ansicht nach häufig vorkommt. Das ist einer der häufigsten Anwendungsfälle.

Stefan Tilkov: Wobei man fachlich natürlich darauf achten muss, dass man nicht eine Folgeverarbeitung anstößt, die man nicht hätte anstoßen dürfen, weil davor irgendetwas nicht bearbeitet wurde.

Frank Hinkel: Klar, das muss man natürlich auf jeden Fall.

Stefan Tilkov: Genau, es bleibt immernoch Fachlogik übrig.

Frank Hinkel: Und wichtig ist auch da irgendwo so ein Skip-Element zu setzen. Also wenn der 1000ste Fehler hintereinander aufgetreten ist, dann sollte man wirklich mal abbrechen. Wenn das eigentlich nur Fehler sind, dann lohnt sich das auch nicht, dieses Batch-Fenster auszunutzen. Genau.

Stefan Tilkov: Du hast vorhin mal kurz Messaging erwähnt. Kannst du mir da nochmal den Bezug zu herstellen? Was hat Messaging mit Batch-Verarbeitung zu tun?

Frank Hinkel: Ja, das ist im Grunde dieser Gedanke, nicht dieses Batch- Fenster zu haben, sondern wirklich online laufen zu lassen und dann Nachrichten los zu schicken. Also ich habe jetzt irgendwie einen Benutzer, der gibt was ein. Dann würde normalerweise ein Datensatz erzeugt werden, über den dann nachts ein Batch läuft. Und das passiert jetzt nicht, jetzt wird eine Nachricht geschickt, die dann asynchron irgendwann verarbeitet wird, wenn Resourcen dafür da sind. Da gibt dann vielleicht ein paar Worker, die dann darauf horchen und dann arbeiten. Und dabei zerlegt man halt Daten oder man sorgt dann dafür, dass nur einzelne Datenblöcke kommen, die dann verarbeitet werden. Später vielleicht zusammengefasst, aber nicht dieser riesen Datenblock, der dann einfach einen Algorithmus durchläuft und dann wieder einen riesen Datenblock da drauf legt. So dieser asynchrone Gedanke ist auch dahinter.

Stefan Tilkov: Was würdest du generell empfehlen, wenn man Batches schreibt? Also erstmal postulieren wir mal, man schreibt noch welche. Was du gerade gesagt hast war ja eher die Aussage, wir versuchen drum herum zu kommen. Wenn wir die Batches überflüssig machen, haben wir auch kein Problem mehr mit paralleler Online- und Batch-Verarbeitung. Denn es gibt keine Batch- Verarbeitung mehr. Kein Problem mit den Zeitfenstern für die Dunkel- Verarbeitung, weil es gibt sowieso keine Zeitfenster mehr. Und in webbasierten Zeiten ist das ja klar, dass das immer mehr verschwindet. Aber jetzt nehmen wir mal an es bleiben irgendwelche Dinge übrig, vielleicht im Bereich Reporting oder so oder irgendwelche anderen …

Frank Hinkel: Statistiken.

Stefan Tilkov: … Statistiken, was auch immer. Dinge die vielleicht nicht so in den transaktionalen Fluss hinein passen oder hinein gehören. Wie würdest du sowas heute angehen?

Frank Hinkel: Also erstmal würde ich mich überhaupt fragen: „Ist das ein Batch?“ Also ist das wirklich eine Massenverarbeitung oder kann ich auch einen Quartz-Job machen? Also ich habe Kollegen gesehen, die wollten eigentlich nur ein ganz kleines Progrämmchen schreiben und haben sich dann in Spring Batch eingearbeitet. Da war die Lernkurve und der Overhead nicht im Verhältnis zu dem, was sie eigentlich machen wollten. Da hätte ein kleiner Quartz-Trigger gereicht. Das muss man sich auf jeden Fall fragen.

Stefan Tilkov: Lass mich da aber noch mal eben einhaken. Was genau ist der Unterschied in der Qualität, also mit dem kleinen Quartz-Trigger, das spielt für dich in der gleichen Liga wie ein Cron-Job oder so. Da stoße ich einfach irgendwas an, aber dieses Programm, das ich da anstoße, in sich selbst ist einfach nur ein Programm. Da ist vielleicht eine for-Schleife drin, die 100.000 Dinge verarbeitet, aber ich brauche da kein dickes Framework oder irgendwelche Bibliotheken. Ist es das, was du meinst?

Frank Hinkel: Genau.

Stefan Tilkov: Ok, verstanden. Also erste Sache, erstmal sicher stellen, ob wir überhaupt ein Problem haben, dass es wert ist auf so eine Art und Weise gelöst zu werden. Ok.

Frank Hinkel: So, dann würde ich halt darauf achten, dass ich Komponenten, die ich im Online-Bereich entwickelt habe, nicht unreflektiert im Batch- Bereich wiederverwende. Klar tendiert man immer dazu, wiederzuverwenden. Gerade wir in der Java-Welt, wir wollen ja sowieso immer alles wiederverwenden. Und da sollte man darauf achten, dass man das nicht unreflektiert tut. Weil Online-Komponenten erfahrungsgemäß nicht immer so stark performanceoptimiert sind, wie Batch-Komponenten. Und außerdem auch oft unerwünschte Abhängigkeiten haben, dadurch vielleicht auch größeren Footprint. Also der ganze Rattenschwanz, den das nach sich zieht. Und da sollte man sich schon ganz genau angucken, was man davon wiederverwendet. Weiterer Tipp, der auch damit verbunden ist, ist halt, dass ich in dem Moment, wo ich entwickel – beispielsweise eine Online-Anwendung – dass ich dann schon im Hinterkopf habe „Moment, ich muss wahrscheinlich irgendwann Batch machen.“ D.h., ich kann gewissen Komponenten so schneiden, dass ich keine Abhängigkeiten habe, die ich nicht haben möchte. Das ist auch ein wichtiger Punkt. Und ansonsten, klar ich sollte IO, also ich sollte Resourcen dort verarbeiten, wo ich sie lese und schreibe und sie nicht großartig hin und her kopieren, weil IO immer ein wichtiger Kostenfaktor ist in Batch. Und ansonsten der größte Flaschenhals und auch immer der größte Hebel ist auch immer ein Datenbank-Statement oder eine Datenbank-Tabelle, das Design einer Datenbank-Tabelle. Da scheitern viele Jobs dran und da sollte man mit Kollegen mal drüber sprechen oder vielleicht wenn man auf Datenbankexperten Zugriff hat, die vielleicht mal drüber gucken lassen. Da ist immer viel Optimierungpotential verborgen.

Stefan Tilkov: Ok. Jetzt – ohne Kundennamen zu nennen – vielleicht ganz allgemein die Frage. Du hast ja jetzt ganz klar sowas mit einem Mainframe- Hintergrund gemacht. Auch wenn wir sonst manchmal in unseren Podcasts darüber reden, dass wir Java in Frage stellen, weil wir viel moderenere Dinge gerne benutzen wollen, gibt es genügend Versicherungen, Banken, für die Java was unglaublich modernes ist und das absolut in Frage gestellt wird. Insbesondere kenne ich dir Frage oder den starken Zweifel daran, ob man mit Java überhaupt so eine Batch-Verarbeitung vernünftig und performant hinbekommen kann. Kannst du dazu was sagen, hast du harte Fakten?

Frank Hinkel: Also ich habe eine Erfahrung gemacht. Und zwar, wir hatten einen COBOL-Job, der lief glaube ich drei Stunden. Der lief im Java- Programm, im Java-Batch dann letztendlich – was waren das? – 20 Minuten. Das hing vor allen Dingen damit zusammen, dass der COBOL-Job gar nicht so performant programmiert war. Der war irgendwie programmiert. Man hatte sich da gar nicht so viel Gedanken gemacht. Man hat ihn einfach programmiert und gesagt: „Zwei Stunden? Naja, ist ok.“ Und im Java-Bereich hat man sich da von vornherein Gedanken gemacht, weil man genau auch diese Befürchtung hatte, dass es total langsam ist und dann war das letztendlich wirklich schnell. Ansonsten kann man sagen, klar Java ist ein Speicherfresser, was auf dem Mainframe nicht so gerne gesehen ist. Aber auch durch die Just-in- Time Compileroptimierung kann Batch auch meiner Erfahrung nach schnell laufen. Das ist jetzt nicht nach meiner Beobachtung ein Totschlag-Argument, dass Java langsamer ist oder so.

Stefan Tilkov: Ich würde vielleicht noch ergänzen, dass auch – bevor jetzt jemand den Eindruck bekommt, alle was wir hier sagen spielt nur auf dem Mainframe eine Rolle – dass das ganze, was wir gesagt haben zum Thema Batch- Verarbeitung, Batch-Prozesse, Sichtbarkeit in diesen einzelnen Prozessen, Wiederanlauf und ähnliches, das ist natürlich genau relevant, wenn ich auf einem offenen System, wenn ich auf einem Unix-System bin und da irgendwas programmiere. Klar, wenn das Programm nur eine Minute läuft, brauche ich nicht anzufangen mit einem Batch-Framework darin rumzuschrauben. Aber wenn das eine Verarbeitung ist, für 10 Millionen Datensätzen, dann will ich da sehr gerne auch wieder neu ansetzen können. Also ist das absolut übertragbar.

Frank Hinkel: Genau.

Stefan Tilkov: Gut. Hast du noch berühmte letzte Worte? Spring Batch hast du schon erwähnt als ein Ding. Was für einen Status hat der JSR, frage ich nochmal kurz neugierigerweise? Gibt’s da schon was?

Frank Hinkel: Der ist in der Implementierung, soweit ich weiß.

Stefan Tilkov: Gibt’s da eine Referenz-Implementierung? Finden wir mal raus, packen wir in die Shownotes unten mit rein. Alles klar. Wenn man sich in diese Thematik einarbeiten will, Spring Batch Dokumentation als Startpunkt, taugt das aus deiner Sicht was?

Frank Hinkel: Das ist aus meiner Sicht sowieso die beste Dokumentation momentan. Der JSR selber, wo ich noch reingeguckt habe, da waren die Bilder noch von Spring Batch. Also die Spec-Leader haben viel kopiert aus der Spring-Dokumentation. Auch die Bilder. Also deswegen denke ich, dass die Referenz-Implementierung, wenn es sie schon gibt, auch da sehr nah dran ist.

Stefan Tilkov: Alles klar. Gut, sonst noch letzte Worte?

Frank Hinkel: Nein, eigentlich. Vielen Dank für das Interview.

Stefan Tilkov: Gut, dann lassen wir es kurz und knapp dabei. Vielen Dank, Frank. Bis zum nächsten Mal.

Frank Hinkel: Ja, tschüss.