Design für Resilienz

Design für Wiederaufnehmbarkeit

Einige Integrationsprozesse können sehr komplex sein und Abhängigkeiten mit anderen Prozessen haben. Sie können in mehrere Stufen gehen, bevor Daten endgültig in das endgültige Zielsystem geladen werden. Um die Wiederaufnehmbarkeit des Hinzufügens einer zusätzlichen Spalte zu Ihren Staging-Tabellen zu erleichtern, um die ID der aktuellen Belastung zu verfolgen (load_id oder load_date oder alles, das diesen Ladevorgang eindeutig identifiziert). Dies ermöglicht eine bessere Verfolgbarkeit und erleichtert das Entwerfen Ihrer Bereinigungsverfahren.

Was bedeutet dies für Oracle Data Integrator?

Verwenden Sie Variablen, um die ID des Prozesses, der geladen wird, zu verfolgen, und wenn möglich diese Werte zu den Zwischen-Datenphasen (zusätzliche Spalten in den Staging-Tabellen) hinzuzufügen.
Verwenden Sie diese Variablen, um einen anderen Sessionnamen (SESS_NAME) für jede Szenarioausführung festzulegen. Dadurch können Operatoren Prozesse, die nicht genau kennen, direkt identifizieren. Siehe Eindeutige oder dynamische Namen für Szenariosessions verwenden.
Ein vorheriges Beispiel, bei dem derselbe Prozess verwendet wird, um Hunderte von Dateien zu laden, ist es sinnvoller, nach der Datei einen Job zu verwenden, der verarbeitet wird als denselben generischen Jobnamen für alle Dateien.

Design zum Einschränken der Ausfallauswirkungen

Die Ausführung von umfangreichen Exporten zu vordefinierten Zeiten hat große Auswirkungen auf die gesamte Infrastruktur.

Beispiel:

Das Quellsystem ist betroffen, weil es die Anforderung erfüllen muss.
Das Netzwerk ist betroffen, weil die Bandbreite in den Service der Anforderung gestellt wird.
Die Ausführung der Gesamtintegrationsjobs dauert länger, weil die zu verarbeitende Datenmenge für den Benutzer existiert.
Eine kleine Blip oder Ausfälle in Ihrem Netzwerk bei der Integration hat wesentliche Auswirkungen auf die Integrationsaufgabe.

Integrationsjobs müssen entweder nicht "Batch" oder "Echtzeit" sein. Häufig können sie beide sein. Wenn es sich bei der endgültigen Belastung um einen Batchvorgang handeln muss (weil Daten konsolidiert oder zur Instanz aggregiert werden), können die Extraktion und einige Vorintegrationsprozesse in Echtzeit ausgeführt werden. Dadurch wird die Belastung der Gesamtinfrastruktur reduziert, und die Auswirkungen sollten beim Zugriff auf das Quellsystem während der Integration als Ausfall angesehen werden. Wenn die Daten extrahiert und mit Streaming vorbereitet wurden, müssen Sie nicht auf das Quellsystem zugreifen, wenn es für die endgültige Integration vorgesehen ist.

Oracle Data Integrator stellt eine Reihe von Tools bereit, die beim Erstellen von Packages verwendet werden können, um zu ermitteln, dass neue Daten verfügbar sind. Eine Liste finden Sie unter Ereignisgesteuerte Tools verwenden.

Für die Integration mit der echten Echtzeitreplikation kann Oracle Data Integrator eine Infrastruktur erstellen, die die Nutzung von Änderungen ermöglicht, die oben genannten APIs nutzt.

Daten zwischen Einfügen und Zusammenführen wählen

Es sind Kompromisse zwischen einem INSERT- und einem MERGE-Ansatz zum Laden von Daten vorhanden. Über die Integrationsstrategie können Sie feststellen, was geschieht, wenn ein Ladevorgang teilweise nicht erfolgreich verläuft.

Je nachdem, wie Sie die Daten in das Zielsystem laden, kann das Versehen der ordnungsgemäß geladenen Daten im Vergleich zu den nicht erfolgreichen Elementen unterscheiden, oder die Elemente einer Teillast können komplex sein. Auch wenn alle von Ihnen ausgeführten Daten aus einer Designperspektive an das Zielsystem angehängt werden, bietet es sich an eine Wiederherstellungsperspektive, die Vorteile beim Zusammenführen der eingehenden Daten mit den bereits im Zielsystem vorhandenen Daten zu berücksichtigen.

Wenn Sie diese Lösung wählen, müssen Sie die Auswirkung dieser Strategie auf die Performance der Ladevorgänge prüfen. Denken Sie jedoch daran, dass eine vollständig optimierte INSERT-Last, die nicht schneller ist als eine weniger effiziente MERGE-Anweisung, die erfolgreich verläuft.

Von einer Oracle Data Integrator-Perspektive aus einer INSERT-Strategie in eine MERGE-Strategie besteht aus einem sehr einfachen Vorgang. Sie müssen lediglich Ihre Integrationsstrategie ändern und das entsprechende Knowledge-Modul auswählen. Das bedeutet, dass es sich bei der Änderung von Knowledge-Modulen für eine große Anzahl an Mappings um eine anstehende Aufgabe handeln kann. Sie können eine derartige Aufgabe mit dem Oracle Data Integrator-SDK automatisieren.

Entwurf zur Begrenzung der geplanten Ausfälle

Geplante Ausfälle sind im Allgemeinen für Patching und Upgrades erforderlich.

In einer Cloud-Umgebung, in der Patches und Upgrades mehr und nahtlos von der Endbenutzerperspektive sind, wird das letzte Mal in einen Ausfall verlangt, weil der Code der Integrationsprozesse gepatcht wird. Das bedeutet, dass das Patching Teil der Entwicklungsstrategie sein muss, um sicherzustellen, dass Ausfälle mindestens auf einen Wert aufbewahrt werden.

Die Ausführungseinheit für Oracle Data Integrator ist ein Szenario. Wenn ein Szenario generiert wird, wird es mit einer Versionsnummer verknüpft (beginnend mit 001). Szenarios können erneut generiert (um die aktuelle Version zu überschreiben) oder eine neue Version generiert werden (002, 003 usw.).

Beim Aufrufen eines Szenarios empfiehlt Oracle, dass Sie immer die Versionsnummer-1 angeben. Dies bietet zwei Vorteile:

Oracle Data Integrator verwendet immer die neueste Version Ihres Szenarios. Sie müssen nicht ändern, wie Sie diese Szenarios aufrufen, während Sie neue Versionen generieren;
Kurz nach der Erstellung einer neuen Version des Szenarios ist dies die von Oracle Data Integrator ausgeführte Version. Unter Agent-Blueprint-Cache-Timeout konfigurieren wird beschrieben, wie mögliche Verzögerungen kontrolliert werden. Sie müssen Oracle Data Integrator nicht stoppen und neu starten oder das von Ihnen verwendete externe Orchestrierungstool verwenden, damit Oracle Data Integrator die neueste Version der Integrationsszenarios verwenden kann.

Hinweis: Dieser Ansatz ist nur möglich, wenn in Oracle Data Integrator keine unendlichen Schleifen vorhanden sind. Unbegrenzte Schleifen werden in Oracle Data Integrator nie empfohlen (sie sind tatsächlich als Anti-Pattern qualifiziert):

Sie schließen die Oracle Data Integrator-Logs: Loglöschungen wirken sich nie auf einen aktiven Job aus. Eine Endlosschleife wird immer ausgeführt, sodass die entsprechenden Logs nicht gelöscht werden können.
Sie verhindern das Live-Patching von Szenarios: Damit ODI die neue Version eines Szenarios wählt, muss es die Möglichkeit haben, dieses Szenario zu starten. Eine Endlosschleife endet niemals auf… und kann daher niemals neu gestartet werden.
Anstatt eine Endlosschleife zu haben, können Sie das Szenario beenden, indem Sie dasselbe Szenario asynchron aufrufen: Der letzte Schritt des Szenarios vor dem Beenden beginnt dann eine neue Kopie von sich selbst in einer neuen Session.