Klärung Schritt Chaining

Question

Aufgrund der vielen unterschiedlichen Meinungen zum Schritt in Spring Batch Chaining, je nach Anwendungsfall, möchte ich wissen, was ist die häufigste Sinn:

Chaining der Schritte, also ein Job hat ein Fluss von Schritten, wo jeder Schritt Reader, Processer & Writer hat. Daten zwischen den Schritten werden über den Job ExecutionContext ausgetauscht.

OR

Chaining von ItemProcessors, das heißt ein Job hat nur einen Schritt und nur eine Strömung von ItemProcessors.

Die erste Möglichkeit ist meiner Meinung nach vernünftiger, da der Name 'Job' bedeutet, dass es mehrere Schritte gibt, um es zu beenden. Der Nachteil in vielen Anwendungsfällen könnte sein, dass es zu Beginn und am Ende eines Schrittes zu einem redundanten oder manchmal "leeren" Lesen von & kommt. Die zweite ist die gebräuchlichste Lösung, aber ich denke, diese "One Step" -Lösung ist nicht ganz die, für die Batch-Verarbeitung gedacht ist.

Was ist Ihre Meinung dazu?

Answer 1

Die Nützlichkeit von ItemProcessors ist ziemlich begrenzt, sie eignen sich am besten für Fälle, in denen Sie jedes gelesene Element transformieren möchten. Sie können sie verwenden, um Zeilen zu filtern, die Sie nicht möchten, aber in einigen Fällen Leser führt eine SQL-Abfrage aus), die schnell verschwendet wird, es ist viel effizienter, wenn Sie vermeiden können, diese Zeilen an erster Stelle zu lesen.

Es ist schön, einen Haken im Prozess zu haben, um in ItemProcessors fallen zu lassen, aber ich würde es nicht übermäßig verwenden. Die meisten nicht-trivialen Jobs scheinen mehrere Schritte zu haben und das Framework bietet Unterstützung für Schritte wie Fehlerbehandlung, Chunking, Partitionierung usw., wobei ItemProcessors im Vergleich zu Schritten extrem leicht sind und das Framework darüber hinaus keine Unterstützung für sie bietet Bereitstellung eines Platzes für sie im Workflow.

(Die Aussage "Daten zwischen den Schritten wird mit dem Job ExecutionContext ausgetauscht" scheint fraglich. Ich habe es verwendet, um Dinge wie die Anzahl der Zeilen gelesen oder geschrieben zu halten. Es ist kein guter Ort, um etwas viel größer zu setzen als das.)

Answer 2

Von http://docs.spring.io/spring-batch/reference/html/domain.html#domain:

Ein Job muss man viele Schritte, die genau hat man ItemReader, ItemProcessor und ItemWriter.

Also ist die Spring-Philosophie Verketten von Schritten.

Answer 3

Ich stimme völlig mit den Antworten überein, die von Nathan und lexicore gegeben werden.

Aber es gibt eine Bemerkung, die ich hinzufügen möchte. Ich tausche Geschäftsdaten niemals mit dem JobExecutionContext.

Wenn ich einen Job schreibe, der mehrere Schritte hat, schreibt jeder Schritt seine Geschäftsdaten in eine Datei und die nächsten Schritte lesen sie von dort aus.

Darüber hinaus haben wir in der Firma, mit der ich arbeite, das STEPP-Muster definiert, dem fast alle unsere Chargen folgen.

STEPP steht für

1. SELECT -> wählen Sie Daten, z. von einem db
2. VERäNDERN/FILTER -> in einer bequemeren Struktur transformiert und/oder
3. ENRICH Filter -> wenn necesssary Hinzufügen zusätzliche Daten, die für Business-Logik, die billiger zu laden, wenn nicht in der Auswahlphase
getan
4. PROCESS -> gelten die Businesslogik
5. PERSIST -> persistieren

Nicht jeder Job alle genannten Phasen hat. Zum Beispiel haben die meisten von ihnen keine Anreicherungsphase. Einige haben nur einen SELECT-, TRANSFORM- und einen PERSIST-Schritt.

Oft werden die verschiedenen Phasen als ein Schritt implementiert, der die Daten in einer Datei speichert, die von dem folgenden Schritt gelesen wird. Manchmal ist der ganze Job nur ein einziger Schritt. Manchmal besteht eine Phase aus mehreren Schritten. Es hängt immer von der Größe des Jobs ab.

Wir verwenden auch eine entsprechende Benennung, so dass die verschiedenen Phasen eindeutig identifizierbar sind. Unser Paket heißt beispielsweise com.xy._1_select, com.xy._2_transform usw. Die Verwendung der Nummer in den Paketnamen gibt ihnen direkt die richtige Reihenfolge in der Projekt-/Paketanzeige Ihrer IDE.