Schema-Drift-Erkennung in verteilten Datensystemen

Das Analyse-Dashboard war am Dienstag korrekt. Am Donnerstag zeigte es einen Rückgang der Kundengewinnung um 23 Prozent an, den das Business-Team als ernstzunehmendes Geschäftssignal interpretierte, Marketingbudgets umstrukturierte, Kampagnen pausierte und den Vorstand informierte. Das Data-Engineering-Team entdeckte am Freitag, dass der vorgelagerte Dienst eine Spalte mit Nullwerten hinzugefügt hatte. registrations Die Tabelle war sechs Tage zuvor aktualisiert worden. Die ETL-Pipeline war nicht aktualisiert worden. Die Berechnung der Akquisitionsmetrik behandelte die neuen Nullwerte als Nullen, anstatt sie auszuschließen. Es war keine Schemaänderungsbenachrichtigung versendet worden. Es war kein Vertrag verletzt worden, der einen Fehler verursacht hätte. Die Pipeline lief erfolgreich; sie lieferte falsche Zahlen, die jedoch korrekt aussahen.

Schema-Drift stellt eine strukturelle Veränderung dar. Anders als bei Datenqualitätsproblemen, bei denen Werte fehlerhaft sind, bricht Schema-Drift den Vertrag zwischen Quelle und Ziel. In einer monolithischen Datenbankumgebung mit einem zentralen Datenbankadministrator, der alle DDL-Anweisungen kontrolliert, wird dieser Vertrag von einer einzigen Instanz durchgesetzt. In einem verteilten System hingegen, in dem Dutzende unabhängiger Dienste jeweils ihren eigenen Datenspeicher besitzen, Ereignisströme Avro-Schemas enthalten, die sich unabhängig voneinander weiterentwickeln, und Flat-File-Schnittstellen zwischen Mainframe-Batch-Jobs und Cloud-Analyseplattformen implizite Verträge definieren, die in der Dokumentation beider Systeme nicht existieren, ist der Vertrag über alle Systemgrenzen verteilt. Schema-Drift in einer verteilten Umgebung wartet nicht auf einen Fehler des Datenbankadministrators. Sie entsteht aus dem normalen Betrieb autonomer Teams, die individuell sinnvolle Entscheidungen treffen, ohne vollständige Transparenz über alle nachgelagerten Datenkonsumenten zu haben.

Was Schema-Drift ist und was er nicht ist

Schema-Drift bezeichnet eine Änderung der Struktur eines Datenartefakts, die sich nicht in den Datenverarbeitungsvorgängen widerspiegelt. Die Fokussierung auf die Datenverarbeitungsvorgänge unterscheidet Schema-Drift von geplanter Migration: Eine Spaltenumbenennung, die gleichzeitig in der Quelltabelle und jeder verarbeitenden Abfrage ausgeführt wird, stellt eine Schema-Migration dar. Dieselbe Umbenennung, die nur in der Quelltabelle ausgeführt wird und dazu führt, dass die Datenverarbeitungsvorgänge veraltete Spaltennamen verwenden, ist hingegen Schema-Drift.

Datenpipelines basieren auf einem Vertrauensverhältnis zwischen Quellsystem und Ziel-Data-Warehouse. Dieses Vertrauensverhältnis ist das Schema: die vereinbarte Struktur, die Datentypen und die Spaltennamen, die den Datensatz definieren. Wenn vorgelagerte Teams ihre Anwendungsdatenbank ändern, ohne das Datenteam zu benachrichtigen, verletzen sie dieses Vertrauensverhältnis.

Schema-Drift ist nicht dasselbe wie Daten-Drift. Daten-Drift bezeichnet eine Veränderung der statistischen Verteilung von Werten innerhalb eines stabilen Schemas: sinkende durchschnittliche Ordnungswerte, steigende Nullwerte und sich verschiebende Kategorienverteilungen. Beide sind wichtige Indikatoren für Datenqualität, erfordern jedoch unterschiedliche Erkennungsansätze und weisen auf verschiedene Ursachen hin. Ein System zur Erkennung von Schemaänderungen, das Spaltennamen und -typen überwacht, erfasst keine Daten-Drift; ein System zur Überwachung der Verteilung erfasst keine hinzugefügten oder entfernten Spalten.

Schema-Drift ist nicht immer schädlich. Die Überwachung des Schweregrads der Drift im Zeitverlauf hilft, zwischen aktiven Entwicklungszyklen (unbedenkliche Drift) und Instabilität (kritische Drift) zu unterscheiden. Das Hinzufügen einer Spalte mit Nullwerten zu einer Tabelle, die abwärtskompatibel ist, stellt eine Schema-Drift dar – das Schema ändert sich, aber dies muss keine Auswirkungen auf Benutzer haben, die die neue Spalte ignorieren. Die Klassifizierung einer Drift als unbedenklich oder kritisch erfordert ein Verständnis der nachgelagerten Benutzer und wie diese mit der Änderung umgehen.

Die vier Arten von Schema-Drift

Verteilte Datensysteme erzeugen Schema-Drift entlang vier verschiedener Dimensionen, die jeweils unterschiedliche Erkennungsmechanismen erfordern:

Typ 1: Strukturelle Verschiebung

Änderungen an der physischen Schemadefinition: Hinzufügen, Entfernen und Umbenennen von Spalten, Änderungen von Datentypen, Hinzufügen oder Entfernen von Einschränkungen sowie Hinzufügen und Entfernen von Tabellen. Dies ist die sichtbarste Form der Schemaabweichung und wird am häufigsten von Überwachungstools erfasst. Datenbankabfragen (INFORMATION_SCHEMA), Vergleiche der Schema-Registry und Audit-Logs von Migrationstools erfassen strukturelle Abweichungen in verbundenen Systemen effektiv.

Erkennung: Vergleich von Schema-Snapshots mit einer Baseline; Abfrage von INFORMATION_SCHEMA; Vergleich der Schema-Registry-Versionen.

Typ 2: Semantische Drift

Änderungen der Bedeutung eines bestehenden Feldes ohne Änderung seiner Definition. Eine Spalte mit dem Namen status die zuvor Werte enthielten ACTIVE, INACTIVE, PENDING enthält nun Werte 1, 2, 3 Weil der produzierende Dienst seine Enumeration geändert hat. Schema, Spaltenname, Datentyp und Nullable-Einschränkung sind unverändert. Der semantische Vertrag ist verletzt. Konsumenten, die bisher Statuswerte als Zeichenketten verarbeitet haben, erhalten nun Ganzzahlen, die ihre Logik nicht verarbeiten kann.

Semantische und kontextuelle Drift sind neuere Themen in der Diskussion und werden deutlich weniger überwacht, obwohl beide für einen wachsenden Anteil der Fehler in KI-Programmen verantwortlich sind. Semantische Drift ist am schwierigsten automatisch zu erkennen, da sie kein strukturelles Signal erzeugt und entweder die Überwachung der Werteverteilung (das Verhältnis von bekannten zu unbekannten Werten ändert sich) oder explizite Vertragsprüfungen erfordert.

Erkennung: Überwachung der Werteverteilung; Validierungsregeln für zulässige Werte; Vertragstests, die bestimmte gültige Werte bestätigen.

Typ 3: Formatabweichung

Änderungen an der Kodierung oder dem Format von Werten in strukturell unveränderten Feldern. Ein Zeitstempelfeld, das zuvor UTC-ISO-8601-Zeichenketten enthielt, enthält nun Unix-Epochenwerte. Ein Währungsfeld, das zuvor Dezimalbeträge enthielt, enthält nun Cent-Beträge als ganze Zahlen. Die Spalte existiert, der Datentyp ist für die neuen Werte weiterhin gültig, aber die Parsing-Konvention hat sich geändert.

Formatabweichungen treten besonders häufig an den Schnittstellen verteilter Systeme auf, wo ein Dienst Daten in einem Format serialisiert, das ein anderer deserialisiert, und an der Schnittstelle zwischen Legacy- und modernen Systemen, wo COBOL-Programme flache Dateien mit spezifischen Byte-Positionskonventionen schreiben, von denen nachgelagerte ETL-Prozesse abhängen.

Erkennung: Statistische Profilerstellung von Wertebereichen und Mustern; Formatvalidierungsregeln für spezifische Felder; Grenzwertüberschreitungstests.

Typ 4: Vertragsdrift

Änderungen in der Verfügbarkeit, Aktualität oder den Mengengarantien einer Datenquelle. Das Quellsystem lieferte zuvor täglich bis 3 Uhr UTC einen Datensatz; nun erfolgt die Lieferung bis 6 Uhr, wodurch nachgelagerte Prozesse, die von einer Aktualität um 3 Uhr ausgingen, unbemerkt beeinträchtigt werden. Das Quellsystem garantierte zuvor mindestens 1,000 Datensätze pro Tag; in Zeiten geringen Datenverkehrs werden nun weniger Datensätze geliefert. Beide Änderungen stellen keine Schemaänderung im strukturellen Sinne dar, verletzen aber die Vereinbarung zwischen Produzent und Konsument.

Erkennung: Frischeüberwachung; Erkennung von Mengenanomalien; SLA-basierte Alarmierung.

Warum verteilte Systeme das Problem verstärken

In einem monolithischen System mit einer einzigen Datenbank und einem einzigen Anwendungsteam sind Schemaänderungen kontrollierte Vorgänge. Der Datenbankadministrator erstellt die Migration, der Entwickler aktualisiert die Abfragen, und die Änderung wird gemeinsam bereitgestellt. Das Risiko einer Schemaabweichung besteht zwar, ist aber durch den Zuständigkeitsbereich der einzelnen Instanz begrenzt.

Verteilte Systeme beseitigen diese zentrale Kontrollinstanz. Jeder Dienst ist für seine eigenen Daten verantwortlich. Jedes Team trifft Schemaentscheidungen unabhängig. Die Nutzer der Daten jedes Dienstes sind oft nicht direkt im Blickfeld des jeweiligen Teams, insbesondere wenn es sich um eine Datenplattform, eine Analysepipeline oder einen Legacy-Integrationspunkt handelt, der von keinem Produktteam aktiv betreut wird.

Distributed Schema Drift Propagation Path:

Order Service          Kafka Topic           Analytics Pipeline
┌─────────────────┐   ┌───────────────┐    ┌──────────────────────┐
│ orders table    │──>│ order.created │───>│ orders_fact table    │
│ + coupon_id     │   │ Avro schema   │    │ (missing coupon_id)  │
│   (new column)  │   │ v1 still used │    │ pipeline runs fine   │
│                 │   │               │    │ coupon data silently  │
│                 │   │               │    │ dropped              │
└─────────────────┘   └───────────────┘    └──────────────────────┘

                           ▼
                   BI Dashboard
                ┌──────────────────┐
                │ coupon_revenue   │
                │ always = $0      │
                │ (no error shown) │
                └──────────────────┘

Das Diagramm veranschaulicht das Ausbreitungsmuster: Das Order Service Team fügt hinzu coupon_id zu ihrer Datenbank. Wenn sie auch das Kafka-Ereignisschema aktualisieren, um Folgendes einzuschließen coupon_idDie Analyse-Pipeline muss aktualisiert werden, um die Daten zu verarbeiten. Befindet sich das Kafka-Schema noch in Version 1, erreicht das Feld die Pipeline nicht. Wird die Pipeline aktualisiert, das BI-Dashboard-Modell jedoch nicht, ist das Feld zwar im Data Warehouse vorhanden, fehlt aber im Bericht. Diese Abweichung kann an vier beliebigen Schnittstellen zu einem unbemerkten Datenverlust führen, und jede Schnittstelle erfordert einen anderen Erkennungsmechanismus.

Stille Pipeline-Fehler, veraltete Dashboards, Schema-Drift und unvollständige Datensätze haben sich zu erheblichen Betriebsrisiken in modernen Unternehmensdatenumgebungen entwickelt. Moderne Datenarchitekturen versagen schneller als traditionelle Umgebungen, wobei fehlerhafte Transformationen, Aktualitätsprobleme und unbemerkte Datenbeschädigungen sich in den Pipelines ausbreiten, lange bevor Teams die Probleme manuell erkennen.

Die „stille“ Eigenschaft ist es, die die Abweichung von verteilten Schemas so kostspielig macht. Ein Fehler, der eine Ausnahme auslöst, wird erkannt und behoben. Eine Änderung, die stillschweigend falsche Zahlen erzeugt, bleibt unbemerkt, bis eine auf diesen Zahlen basierende Geschäftsentscheidung sichtbare Konsequenzen hat.

Detektionsansätze nach Schicht

Die Erkennung von Schema-Drift erfordert für jede Schicht eines verteilten Systems unterschiedliche Werkzeuge und Techniken:

Datenbank- und Warehouse-Schicht

Die ausgereifteste Erkennungsschicht. INFORMATION_SCHEMA-Tabellen in jeder wichtigen Datenbank und jedem Data Warehouse liefern eine abfragefähige Metadaten-Momentaufnahme:

SQL

-- Detect structural schema changes since a baseline snapshot
-- Run daily; alert when new differences appear

WITH current_schema AS (
    SELECT
        table_name,
        column_name,
        data_type,
        is_nullable,
        column_default,
        ordinal_position
    FROM information_schema.columns
    WHERE table_schema = 'production'
),
baseline AS (
    -- Previous snapshot stored in schema_baseline table
    SELECT * FROM schema_monitoring.schema_baseline
    WHERE snapshot_date = CURRENT_DATE - 1
)
SELECT
    'ADDED'   AS change_type,
    c.table_name,
    c.column_name,
    c.data_type,
    CURRENT_DATE AS detected_date
FROM current_schema c
LEFT JOIN baseline b
    ON c.table_name = b.table_name
    AND c.column_name = b.column_name
WHERE b.column_name IS NULL

UNION ALL

SELECT
    'REMOVED' AS change_type,
    b.table_name,
    b.column_name,
    b.data_type,
    CURRENT_DATE
FROM baseline b
LEFT JOIN current_schema c
    ON b.table_name = c.table_name
    AND b.column_name = c.column_name
WHERE c.column_name IS NULL

UNION ALL

SELECT
    'TYPE_CHANGED' AS change_type,
    c.table_name,
    c.column_name,
    c.data_type || ' (was: ' || b.data_type || ')' AS data_type,
    CURRENT_DATE
FROM current_schema c
JOIN baseline b
    ON c.table_name = b.table_name
    AND c.column_name = b.column_name
WHERE c.data_type <> b.data_type;

Tools, die dieses Muster automatisieren: dbt-Schema-Tests, Great Expectations-Spaltenerwartungen, Monte-Carlo-Tabellenzustandsüberwachung, Acceldata-Schema-Drift-Überwachung.

Ereignis-Streaming-Ebene

Kafka-Topics nutzen Schema-Registries (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio), um die Weiterentwicklung von Avro-, Protobuf- und JSON-Schema zu steuern. Die Registry setzt Kompatibilitätsregeln zum Veröffentlichungszeitpunkt durch.

YAML

# Confluent Schema Registry: compatibility rule configuration
# Applied per topic; enforces at producer registration time

compatibility:
  BACKWARD:
    # New schema can read data written with old schema
    # Safe: consumers can be updated after producers
    allows: add_optional_fields, remove_fields_with_defaults
    blocks: rename_fields, change_types, add_required_fields

  FORWARD:
    # Old schema can read data written with new schema
    # Safe: consumers can be deployed before producers
    allows: add_required_fields, rename_with_aliases
    blocks: remove_fields_used_by_consumers

  FULL:
    # Both backward and forward compatible
    # Strictest: ensures zero-downtime evolution
    allows: add_optional_fields_with_defaults
    blocks: everything_else

Die Schema-Registry verhindert keine semantische Drift; ein Feld, dessen Name und Typ unverändert sind, dessen Bedeutung sich aber geändert hat, besteht die Kompatibilitätsprüfungen. Für die semantische Validierung sind Vertragstests (Pact-, AsyncAPI-Tests) erforderlich.

API-Schicht

Es gibt vier grundlegend verschiedene Ansätze, um Abweichungen im API-Schema zu erkennen: Spezifikationsvergleich, Überwachung der Übereinstimmung von Spezifikation und Realität, Überwachung der Übereinstimmung von Realität und verkehrsbasierte Erkennung. Die meisten Missverständnisse in diesem Bereich entstehen durch den Vergleich von Tools, die unterschiedliche Ansätze verfolgen.

Für interne Service-APIs in einer Microservices-Architektur ist Consumer-Driven Contract Testing (Pact) der zuverlässigste Ansatz: Jeder Consumer gibt den Vertrag an, den er vom Producer benötigt, die Verträge werden in CI anhand der Implementierung des Producers überprüft, und jede Änderung, die einen Consumer-Vertrag verletzt, führt dazu, dass die Testsuite des Producers vor der Bereitstellung fehlschlägt.

Die Grenze des Altsystems: Wo die Systemdrift unsichtbar wird

Alle oben beschriebenen Erkennungsansätze funktionieren für Systeme, die Schema-Metadaten über abfragefähige Schnittstellen bereitstellen: INFORMATION_SCHEMA, Schema-Registries, OpenAPI-Spezifikationen. An der Schnittstelle zwischen älteren Mainframe-Systemen und modernen Datenplattformen existieren diese Schnittstellen nicht.

Ein COBOL-Programm, das eine nächtliche Flatfile für eine Cloud-ETL-Pipeline erzeugt, definiert ein implizites Schema in seiner FD-Eintrags- und Ausgabelogik. Das „Schema“ der Flatfile – Byte-Positionen, Datentypen, COMP-3-gepackte Dezimalfelder und REDEFINES-Strukturen – ist im COBOL-Quellcode enthalten und nicht in einer Registry oder einem Metadatenspeicher, den moderne Observability-Tools abfragen können.

Cobol

      *> This FD entry IS the schema contract for the nightly extract
      *> Any change here constitutes schema drift for the downstream ETL
       FD  CUSTOMER-EXTRACT-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 350 CHARACTERS.
       01  CUSTOMER-EXTRACT-REC.
           05  CUST-ID          PIC 9(10).        *> Bytes 1-10
           05  CUST-NAME        PIC X(40).        *> Bytes 11-50
           05  CUST-BALANCE     PIC S9(11)V99 COMP-3. *> Bytes 51-57 (packed)
           05  CUST-STATUS-CD   PIC X(2).         *> Bytes 58-59
           05  CUST-OPEN-DATE   PIC 9(8).         *> Bytes 60-67: YYYYMMDD
           05  FILLER           PIC X(283).       *> Bytes 68-350

Wenn sich das COBOL-Team ändert CUST-BALANCE ab PIC S9(11)V99 COMP-3 zu PIC S9(13)V99 COMP-3Durch Hinzufügen von zwei Nachkommastellen zur Verarbeitung größerer Saldenwerte erweitert sich das Feld im gepackten Dezimalformat von 7 auf 8 Byte. Jedes Feld nach Byte 50 verschiebt sich um eine Position. Die vom ETL-Pipeline gelesene Datei enthält nun alle Felder nach CUST-BALANCE an den falschen Byte-Positionen. Die ETL-Pipeline erzeugt keinen Fehler; sie liest die Bytes 51–57 als CUST-BALANCE und interpretiert das nächste Byte (das nun das erste Byte der erweiterten Darstellung von CUST-BALANCE ist) als Teil von CUST-STATUS-CD. Die Pipeline wird ausgeführt. Die Zahlen sind falsch. Es wird keine Schemaabweichungswarnung ausgelöst.

Dies ist die gefährlichste Art von Schema-Drift in Unternehmensumgebungen: strukturelle Änderungen in Legacy-Systemen, die sich stillschweigend über Flatfile-Schnittstellen ausbreiten, ohne dass es an einem der Enden einen Erkennungsmechanismus gibt.

Drei Eigenschaften machen die Verschiebung von Legacy-Grenzen besonders gefährlich:

Das Schema ist für Überwachungstools unsichtbar. Monte Carlo kann keine Verbindung zu einer VSAM-Datei herstellen. Acceldata kann keinen FD-Eintrag abfragen. Die einzige Möglichkeit, die Änderung zu erkennen, besteht darin, den COBOL-Quellcode mit einer vorherigen Version zu vergleichen – eine Codeanalyse, keine Datenüberwachung.

Die Weitergabe erfolgt stillschweigend. Schnittstellen für flache Dateien überprüfen nicht die Datensatzstruktur; sie lesen Bytes. Eine Änderung des Byte-Layouts führt zu falschen Werten, nicht zu Fehlern.

Die Auswirkungen sind weitreichend. Ein von 300 Programmen eingebundenes COBOL-Copybook stellt ein von allen 300 Programmen gemeinsam genutztes Schema dar. Eine Änderung am Copybook, vergleichbar mit einer DDL-Anweisung ALTER TABLE, betrifft alle 300 Programme gleichzeitig, und jeder nachgelagerte Nutzer eines von einem dieser 300 Programme erzeugten Datensatzes übernimmt die Änderung.

Schemaverträge: Formalisierung dessen, was üblicherweise implizit ist

Die strukturelle Lösung für Schema-Drift besteht darin, implizite Verträge explizit zu machen, indem man definiert, was das Schema ist, wer davon abhängt und welche Änderungen zulässig sind, bevor eine Änderung vorgenommen wird und nicht erst, nachdem sie etwas kaputt gemacht hat.

Vertragsschicht	Was es regelt	Zubehör	Legacy-Äquivalent
Datenbank-DDL	Tabellenstruktur, Spaltentypen, Einschränkungen	Liquibase, Flyway, Atlas	DB2 DDL-Migrationsskripte
Ereignisschema	Kafka/Ereignisstromstruktur	Confluent Schema Registry, Apicurio	Nicht zutreffend (die Datei hat keine Registrierung)
API-Vertrag	Erwartungen an die REST/gRPC-Schnittstelle	OpenAPI, Pact, AsyncAPI	Nicht verfügbar (Dateischnittstelle hat keine Spezifikation)
Datenqualität	Wertverteilung, Frische, Volumen	Große Erwartungen, DBT-Tests	Nicht verfügbar (kein natives Testframework)
Dateiformatvertrag	Byte-Layout einer Flatfile, Feldpositionen	COBOL FD-Eintrag (Quelle der Wahrheit)	Copybook-Versionskontrolle

Der Eintrag „Copybook-Versionskontrolle“ in der Spalte „Legacy-Äquivalent“ ist der praktische Mechanismus zur Verwaltung der COBOL-Schemaentwicklung: Das Copybook wird als versioniertes Artefakt mit einem Änderungsgenehmigungsprozess behandelt, es wird ein Verzeichnis geführt, in dem festgehalten ist, welche Programme welches Copybook enthalten, und vor der Genehmigung einer Copybook-Änderung ist eine Auswirkungsanalyse erforderlich.

Ein Genehmigungsworkflow für Änderungen im Regelwerk:

1. Der Entwickler schlägt eine Änderung vor CUSTMSTR.CPY
2. Die Wirkungsanalyse identifiziert jedes Programm, das Folgendes umfasst CUSTMSTR.CPY (statische Analyse)
3. Jede von diesen Programmen erzeugte Flatfile wird als Schemaänderungsereignis identifiziert.
4. Jeder nachgelagerte Nutzer dieser Flatfiles wird benachrichtigt
5. Es werden Verbrauchervalidierungstests für das neue Layout durchgeführt.
6. Die Änderung wird erst dann genehmigt, wenn alle Verbraucher die Kompatibilität bestätigen.

Dieser Workflow spiegelt das Kompatibilitätserzwingungsmuster der Schema-Registry wider, angewendet auf die COBOL-Schicht, wo keine native Schema-Registry existiert.

Überwachungsarchitektur für verteilte Schema-Drift

Eine vollständige Architektur zur Überwachung von Schemaabweichungen deckt alle vier Abweichungstypen über alle Systemschichten hinweg ab:

Schema-Snapshot-Datenbank. Speichert täglich einen Snapshot der INFORMATION_SCHEMA-Metadaten jeder Tabelle, jeder registrierten Ereignisschemaversion, jeder API-Spezifikationsversion und (für Legacy-Systeme) jeder Copybook-Version. Die Snapshot-Datenbank dient als Basis, mit der der aktuelle Zustand verglichen wird.

Änderungsüberwachungspipeline. Tägliche Vergleichsjobs werden in der Snapshot-Datenbank ausgeführt und erkennen Hinzufügungen, Löschungen, Typänderungen und Änderungen von Einschränkungen auf jeder überwachten Ebene. Änderungen mit hoher Priorität, nicht abwärtskompatible Typänderungen, Spaltenlöschungen und Hinzufügungen von Pflichtfeldern lösen sofortige Warnmeldungen aus. Änderungen mit niedriger Priorität, Hinzufügungen von Spalten mit Nullwerten und Indexänderungen generieren Benachrichtigungen.

Verbraucher-Auswirkungsregister. Ein Katalog, der jedes Schema-Artefakt seinen bekannten Verbrauchern zuordnet: welche Pipelines welche Tabellen lesen, welche Dienste welche Kafka-Topics nutzen und welche ETL-Jobs welche Flatfiles verarbeiten. Wird eine Schemaänderung erkannt, ermittelt das Verbraucher-Auswirkungsregister den Wirkungsbereich, die Anzahl der betroffenen Verbraucher und die kritischsten.

Vertragstestsuite. Automatisierte Tests, die die Annahmen der Konsumenten über die Schemata der Produzenten überprüfen. Werden bei jeder Bereitstellung ausgeführt, die einen datenproduzierenden Dienst berührt. Die Bereitstellung schlägt fehl, wenn ein Vertrag verletzt wird, von dem ein registrierter Konsument abhängt.

Überwachung der Systemgrenzen. Für Mainframe-Systeme: Versionskontrollierter Copybook-Vergleich, Überwachung der JCL-Dataset-Definition und Validierung des Flatfile-Formats anhand des im FD-Eintrag des erzeugenden Programms definierten Schemas. Diese Schicht erfordert Codeanalyse anstelle von Datenüberwachung und erkennt Änderungen im COBOL-Quellcode, die Schemaänderungen für nachgelagerte Systeme darstellen.

Die regelmäßige Überwachung ist wichtiger, als viele Teams annehmen. Acceldata empfiehlt in seinen Richtlinien zur geplanten Driftanalyse automatisierte Vergleiche mit einer stabilen Baseline im wöchentlichen oder zweiwöchentlichen Rhythmus und weist ausdrücklich darauf hin, dass das Abwarten von Ad-hoc-Prüfungen nach einem Fehler nicht ausreicht. Insbesondere bei der Überwachung von Legacy-Systemgrenzen sollte der Rhythmus dem COBOL-Bereitstellungsplan entsprechen: Jede Copybook-Freigabe in die Produktion sollte eine sofortige Schema-Auswirkungsanalyse auslösen, anstatt auf den nächsten geplanten Vergleich zu warten.

Wie SMART TS XL Behebt Schemaabweichungen in Legacy-Umgebungen

SMART TS XL behebt die Erkennungslücke an der Grenze zu Altsystemen, der Schicht, in der moderne Observability-Tools aufhören und in der die gefährlichsten Schemaabweichungen unentdeckt bleiben.

Die statische Codeanalyse durchsucht jeden COBOL-FD-Eintrag, jedes COPY-Element und jede SELECT-Klausel, um eine strukturierte Darstellung aller Schema-Artefakte in der Legacy-Umgebung zu erstellen. Wird diese Analyse für zwei Versionen der Codebasis vor und nach einem Deployment durchgeführt, bilden die Unterschiede das Änderungsprotokoll des Legacy-Schemas: welche Copybooks und Felddefinitionen geändert wurden und wie die Layouts vor und nach dem Deployment aussahen. Dies ist ein Schema-Snapshot-Vergleich, angewendet auf die COBOL-Schicht.

Die Abhängigkeitsabbildung stellt die Liste der Auswirkungen auf bestehende Schemata bereit: Welche Programme verwenden welches Copybook? Welche Programme erzeugen welche Flatfile-Datensätze? Welche JCL-Jobs rufen welche Programme auf? Sobald das Änderungsprotokoll ein geändertes Copybook identifiziert, erstellt die Abhängigkeitsabbildung umgehend die Liste der betroffenen Programme – alle Programme, die das Copybook verwenden, und alle von diesen Programmen erzeugten Flatfiles. Diese Berechnung des Wirkungsradius bestimmt, ob eine Copybook-Änderung eine interne Änderung mit geringem Risiko oder ein Ereignis mit hohem Risiko darstellt, das Hunderte von Programmen und Dutzende von betroffenen Programmen beeinträchtigt.

Die Auswirkungsanalyse wandelt den Wirkungsbereich in einen strukturierten Sanierungsrahmen um: Welche Änderungen sind für jeden in der Abhängigkeitskarte identifizierten Verbraucher erforderlich, um das neue Schema zu berücksichtigen, und in welcher Reihenfolge sollten diese Änderungen angewendet werden? Für Verbraucher an der Schnittstelle zwischen Legacy- und Modern-Systemen, also ETL-Pipelines, die von COBOL-Programmen erzeugte Flatfiles lesen, identifiziert die Auswirkungsanalyse die spezifischen Änderungen der Feldpositionen und Datentypen, die in der Spaltenzuordnungskonfiguration der ETL-Pipeline aktualisiert werden müssen.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage von Schema-Artefakten: Sie findet jedes Programm, das ein Feld an einer bestimmten Byte-Position liest (und identifiziert so die von einer Layoutänderung betroffenen Nutzer), jedes Copybook, das ein bestimmtes Feld definiert (und identifiziert so das zu versionierende und änderungskontrollierte Schema-Artefakt), und jedes Programm, das Ausgaben in ein bestimmtes Dataset erzeugt (und identifiziert so die Produzenten, deren Schemaänderungen Benachrichtigungen an die Nutzer auslösen müssen). Diese Suchfunktion unterstützt sowohl den proaktiven Workflow für die Schema-Governance als auch die Untersuchung von Vorfällen nach Schemaabweichungen.

Für Organisationen, die Modernisierung des Altbestands Programme, die die Migration von Mainframe-Daten auf moderne Plattformen umfassen, SMART TS XLDie Schemaanalyse von [Name des Tools] liefert die Quellschema-Dokumentation, die Migrationswerkzeuge benötigen, die vollständigen, aktuellen FD-Eintragsdefinitionen und Copybook-Strukturen, die definieren, was die Daten tatsächlich sind, und nicht nur, was sie waren, als die ursprüngliche Migrationsspezifikation geschrieben wurde.

Ein Vertrag, den niemand geschrieben hat, ist trotzdem ein Vertrag.

Schema-Drift in verteilten Systemen ist kein neues Problem. Es handelt sich um ein altes Problem, dessen Lösung durch verteilte Architekturen erschwert wird, da die Autorität, die in monolithischen Systemen die Einhaltung von Schema-Verträgen sicherstellte – der zentrale Datenbankadministrator, das einzelne Anwendungsteam, die einheitliche Codebasis –, auf Dutzende unabhängiger Dienste verteilt wurde, von denen jeder individuell sinnvolle Entscheidungen trifft und dabei nur unvollständigen Einblick in alle nachgelagerten Nutzer hat.

Die Lösung besteht nicht in einer erneuten Zentralisierung der Schema-Verwaltung. Vielmehr geht es darum, die impliziten Verträge explizit zu machen, sie in Systemen zu registrieren, die den Ist-Zustand mit dem Soll-Zustand vergleichen können, Kompatibilitätsregeln an den Schnittstellen durchzusetzen, an denen Änderungen eingeführt werden, und Verstöße an den Schnittstellen zu überwachen, an denen sich Änderungen ausbreiten. Für moderne Systeme existieren die entsprechenden Werkzeuge und werden rasant verbessert. Bei Legacy-Systemen an der Schnittstelle zu modernen Plattformen ist die Werkzeuglücke jedoch real und folgenreich: Das Flatfile-Format, das einen Schema-Vertrag für eine Cloud-ETL-Pipeline darstellt, ist für jedes moderne Observability-Tool unsichtbar, solange der zugehörige COBOL-Quellcode nicht als Schema-Artefakt analysiert und versioniert wird.

Das Dashboard, das einen Rückgang der Kundengewinnung um 23 Prozent anzeigte, bezog sich nicht falsch auf die empfangenen Daten. Es interpretierte die Daten jedoch falsch, da sich das Schema, das die Bedeutung der Daten definierte, an einer Stelle geändert hatte, an der kein Vertrag registriert und keine Überwachung stattfand. Diese Stelle, unabhängig von ihrem Verlauf in einem verteilten System – ob veraltet oder modern –, ist der Punkt, an dem Programme zur Erkennung von Schemaabweichungen ansetzen müssen.