Effiziente Verarbeitung vieler Dateien mit Hilfe der Auftragsverarbeitung

Angenommen, Sie haben viele Dateien, die in einem Bucket IBM Cloud Object Storage gespeichert sind, und Sie möchten die Stapelverarbeitung in Code Engineverwenden. Ziel ist es, Dateien aus einem Bucket zu lesen, die Dateien zu bearbeiten und die Dateien in einem anderen Object Storage-Bucket auf die effizienteste Weise zu speichern. Angenommen, Sie haben jeden Tag 2000 Dateien im Eingabebucket. Alle Dateien haben unterschiedliche Dateinamen und die Dateinamen beginnen mit einem alphabetischen Zeichen (A-Z, a-z).

Bei der Planung einer Lösung für dieses Szenario denken Sie zunächst an eine ereignisgesteuerte Lösung. In diesem Fall wird für jede Datei, die in das Object Storage-Eingabebucket geschrieben wird, ein Ereignis erstellt und eine Code Engine-Anwendung aufgerufen. Bei Verwendung von Ereignissen kann eine einzelne Datei eine individuelle Verarbeitung auslösen, was für viele Dateien ineffizient sein kann.

Kann die Ausführung eines Batch-Jobs ein besserer Ansatz sein? Ja, es kann! Sehen wir uns an, warum Stapeljobs besser für die gemeinsame Verarbeitung mehrerer Dateien geeignet sind.

1. Legen Sie einen Ansatz fest, um die Dateigruppe in parallele Datenströme zu unterteilen. Teilen Sie die Dateien anhand des ersten Zeichens des Dateinamens auf. Bei diesem Ansatz können Sie 26 Datenströme verwenden, wobei jeder Datenstrom für Dateien verantwortlich ist, die mit einem bestimmten Zeichen beginnen. Sie können einen bestimmten Datenstrom ermitteln, indem Sie die automatisch injizierte Umgebungsvariable JOB_INDEX einer aktiven Jobinstanz lesen. Siehe Automatisch injizierte Umgebungsvariablen für Jobs. In diesem Beispiel können Sie Ihre Jobinstanzen konfigurieren, indem Sie entweder die Anzahl der Instanzen als 26 oder die Array-Indizes als 0-25 angeben.

   Jeder aktiven Jobinstanz wird ein Index von 0 bis 25 zugeordnet. Verwenden Sie in Ihrem Code das folgende Muster, um die Eingabedaten an die Jobinstanzen zu verteilen.

   • Jobinstanz mit JOB_INDEX=0 funktioniert für Dateien, die mit A oder a beginnen
   • Jobinstanz mit JOB_INDEX=1 funktioniert für Dateien, die mit B oder b beginnen
   • Jobinstanz mit JOB_INDEX=2 funktioniert für Dateien, die mit C oder c beginnen
   • [D ... y]
   • Jobinstanz mit JOB_INDEX=25 funktioniert für Dateien, die mit Z oder z beginnen.

   Da jeder Datenstrom mehrere Dateien verarbeitet, definieren Sie die Warteschlangenlänge eines Datenstroms als Anzahl der Dateien, die von dem einzelnen Datenstrom verarbeitet werden.

2. Erstellen Sie den Job und seine Konfiguration in Code Engine.

   • Geben Sie die Jobbereichsindizes als 0-25 an, die die 26 parallelen Datenströme darstellen.
   • Geben Sie die CPU-und Speicherressourcen für Ihren Job an oder übernehmen Sie die Standardwerte. Jeder Jobindex erhält dieselben CPU-und Speicherressourcen, die Sie für den Job angegeben haben, z. B. 1 vCPU und 4 GB Speicher.

3. Job ausführen. In der Konsole Code Engine können Sie die Anzahl der Jobindizes anzeigen, die anstehend, aktiv und abgeschlossen sind. Der Job endet, wenn der letzte Jobindex seine Ausführung beendet.

Verarbeitung einer Teilmenge von Daten und dynamische Zuweisung von Arbeit an parallele Joblaufinstanzen

Angenommen, Sie möchten nicht auf eine bestimmte Anzahl paralleler Instanzen beschränkt werden.

Im vorherigen Szenario wurden 26 parallele Datenströme definiert und die übergebenen Jobausführungen wurden in den definierten 26 parallelen Datenströmen ausgeführt.

Angenommen, Sie möchten nicht auf eine bestimmte Anzahl paralleler Instanzen beschränkt sein und einen Job ausführen, der einer bestimmten Jobausführungsinstanz Arbeitsströme dynamisch zuordnet. In diesem Fall können Sie sowohl die Umgebungsvariablen JOB_INDEX als auch JOB_ARRAY_SIZE verwenden, um einen Wert abzuleiten, der bestimmt, welcher Workstream verarbeitet wird. Diese Umgebungsvariablen werden automatisch für Jobs eingefügt.

• Die Umgebungsvariable JOB_INDEX ist der Wert des Index einer bestimmten Jobausführungsinstanz.
• Die Umgebungsvariable JOB_ARRAY_SIZE gibt die Anzahl der Jobinstanzen an, die gleichzeitig ausgeführt werden. Dieser Wert wird direkt als Feldgruppengröße der Jobausführung angegeben oder durch Zählen der angegebenen Feldgruppenindizes berechnet.

Angenommen, Sie haben eine Array-Größe von 10 konfiguriert, sodass jede Jobausführungsinstanz auf 10% der Gesamtdaten arbeiten soll (10 Jobausführungsinstanzen werden parallel ausgeführt). Bei dieser Konfigurationseinstellung bestimmt die Umgebungsvariable JOB_INDEX, an welchen der 10 %-Datenblöcke gearbeitet wird, und der berechnete Wert für JOB_ARRAY_SIZE ist 10.

Angenommen, Sie möchten 3 der ersten 10 Jobausführungsinstanzen erneut ausführen, weil sie zuvor fehlgeschlagen sind. Die anderen 70% der Daten wurden erfolgreich verarbeitet. Sie möchten die drei speziellen fehlgeschlagenen Indizes angeben, wenn Sie die Jobausführung erneut übergeben. Angenommen, Sie möchten die Indizes 3, 7 und 9 erneut ausführen.

For this new job run, say that you update only the array indices; for example, "3, 7, 9". Da der Wert der Umgebungsvariablen JOB_ARRAY_SIZE automatisch berechnet wird, wenn Array-Indizes anstelle der Array-Größe angegeben werden, ist der Wert von JOB_ARRAY_SIZE jetzt 3 statt 10, da 3 Array-Indizes angegeben wurden.

Um sicherzustellen, dass Ihre Jobausführungsaktion "submit" (oder "resubmit") die richtigen Datenblöcke für die angegebenen Indizes 3, 7 und 9 verarbeitet, können Sie stattdessen den automatisch berechneten Wert der Umgebungsvariablen JOB_ARRAY_SIZE mit der Option --array-size-var-override in der CLI oder durch Angabe eines angepassten Werts im Eingabefeld JOB_ARRAY_SIZE in der Konsole überschreiben.

Wenn Sie den Korrekturwert für die angepasste Arraygröße auf 10 setzen, berechnen die Jobausführungsinstanzen die Chunkgröße ordnungsgemäß als 10% und die erneut übergebenen Jobausführungsinstanzen verarbeiten die gewünschten Daten (Indizes 3, 7 und 9). Mit dieser Option können Sie einen konstanten Wert für die Arraygröße für Jobwiederholungsszenarios erzwingen, in denen nur einige Jobinstanzen übergeben oder erneut übergeben werden.

Nach der Implementierung dieses Jobausführungsansatzes können Sie die Anzahl paralleler Jobausführungen dynamisch erhöhen oder verringern.

Im Gegensatz zur Methode zur Zuweisung der Verwendung der Umgebungsvariablen JOB_INDEX zum Definieren der Jobausführungs-Workstream-Beziehung ist diese Methode zum Überschreiben der Umgebungsvariablen JOB_ARRAY_SIZE zum dynamischen Zuweisen von Workstreams flexibler und ermöglicht Ihnen die Anpassung einer bestimmten Jobausführung an Ihre Anforderungen.

Vorteile der Ausführung paralleler Stapeljobs

Dieser Ansatz der Implementierung paralleler Stapeljobs bietet Vorteile.

• Reduzierte Initialisierung-Da ein Jobindex Dateien mit ähnlichen Startzeichen verarbeitet, ist nur eine Initialisierung oder Verbindungsaufbau pro Jobindex erforderlich. Dieser Ansatz spart Ressourcen und Kosten im Vergleich zur individuellen Initialisierung pro Datei. Bei der Lösung für parallele Jobs gibt es 26 Initialisierungen anstelle von 2000 Initialisierungen.

• Effiziente Ressourcennutzung-Durch die Aufteilung der Task in parallele, länger laufende Datenströme nutzt diese Lösung verfügbare Ressourcen effizienter, während die Verarbeitungsgeschwindigkeit maximiert wird.

Hinweise zur Planung paralleler Stapeljobs

Beachten Sie die folgenden Punkte, wenn Sie Lösungen für parallele Stapeljobs planen.

• Ausgleich von Indizes für parallele Jobs und Warteschlangenlänge-Es ist wichtig, eine gute Balance zwischen der Anzahl der Datenströme (Indizes für parallele Jobs) und der Warteschlangenlänge zu finden. Zu wenige Jobindizes können die verfügbaren Ressourcen nicht vollständig nutzen, während zu viele Indizes die Initialisierungsverarbeitung erhöhen und die Arbeitslast für Cloud-Services wie Object Storageerhöhen können. Dieser Effekt kann zu Ratenbegrenzungen führen, wenn Sie andere Cloud-Services aufrufen.

• Ähnliche Jobverarbeitungszeit-Beachten Sie bei der Planung Ihrer Lösung, dass jeder Jobindex ungefähr dieselbe Zeit benötigt, um seine Task abzuschließen. Vermeiden Sie Szenarios, in denen ein Jobindex deutlich länger dauert als andere, da die Verarbeitungszeit zu Ineffizienzen bei der Ressourcennutzung führen und die Jobverarbeitungszeit verlängern kann.

• Verwendung mehrerer Jobs-Im vorherigen Szenario besteht ein anderer Ansatz darin, mehrere Jobs zu verwenden. Diese mehreren Jobs basieren nicht auf den konfigurierten Array-Indizes. Erstellen Sie stattdessen zwei Stapeljobs: einen für Dateien, die mit A - Z beginnen, und einen für Dateien, die mit a - z beginnen. Ohne Änderungen an Ihrem Code können Sie diese beiden Jobs entweder parallel oder sequenziell auslösen, je nach Verarbeitungsanforderungen und Ressourcenverfügbarkeit.

• Mechanismus zur Jobauslösung-Sie haben die Möglichkeit, den Job mit einer Cron-Subskription in bestimmten Intervallen oder mit einer Auslöseranwendung auszulösen, die das Bucket Object Storage auf neue Dateien überwacht und die Stapelverarbeitung nach Bedarf einleitet. Je nach Szenario können Sie die Verwendung von Code Engine für Kosteneffizienz und Antwortzeit optimieren, um zu bestimmen, wie schnell die Dateien verarbeitet werden, nachdem sie in das Bucket geschrieben wurden.