We wtorek panel analityczny działał poprawnie. Do czwartku wskazywał 23-procentowy spadek liczby pozyskiwanych klientów, co zespół biznesowy traktował jako rzeczywisty sygnał biznesowy, reorganizując budżety marketingowe, wstrzymując kampanie i przekazując sprawę zarządowi. Zespół inżynierii danych odkrył w piątek, że usługa nadrzędna dodała kolumnę dopuszczającą wartości null do registrations tabela sześć dni wcześniej. Proces ETL nie został zaktualizowany. Obliczenia, które wyprowadziły metrykę akwizycji, traktowały nowe wartości null jako zera, zamiast je wykluczać. Nie wysłano żadnego powiadomienia o zmianie schematu. Żaden kontrakt nie został zerwany w sposób powodujący błąd. Proces działał pomyślnie; generował błędne liczby, które wyglądały na poprawne.
Dryf schematu reprezentuje mutację strukturalną. W przeciwieństwie do problemów z jakością danych, w których wartości są nieprawidłowe, dryf schematu zrywa kontrakt między źródłem a miejscem docelowym. W monolitycznym środowisku bazy danych z centralnym administratorem baz danych (DBA), który kontroluje cały DDL, kontrakt ten jest egzekwowany przez jeden podmiot. W systemie rozproszonym, gdzie dziesiątki niezależnych usług posiadają własne magazyny danych, gdzie strumienie zdarzeń przenoszą schematy Avro, które ewoluują niezależnie, gdzie płaskie interfejsy plików między zadaniami wsadowymi na komputerach mainframe a platformami analityki w chmurze definiują niejawne kontrakty, które nie występują w dokumentacji żadnego z systemów, kontrakt jest rozproszony w każdym miejscu w systemie. Dryf schematu w środowisku rozproszonym nie czeka na błąd administratora baz danych. Wynika on z normalnego działania autonomicznych zespołów podejmujących indywidualnie rozsądne decyzje bez pełnej widoczności każdego odbiorcy danych.
Zmapuj granicę schematu legacy
SMART TS XL identyfikuje wszystkie kontrakty dotyczące formatu pliku płaskiego, łączące programy mainframe z nowoczesnymi platformami analitycznymi.
DOWIEDZ SIĘ WIĘCEJ…Czym jest dryf schematu, a czym nie jest
Dryf schematu to zmiana w strukturze artefaktu danych, która nie znajduje odzwierciedlenia u odbiorców tego artefaktu. Nacisk na odbiorców odróżnia dryf od migracji planowanej: zmiana nazwy kolumny wykonywana jednocześnie w tabeli źródłowej i każde zapytanie odbiorcze jest migracją schematu. Ta sama zmiana nazwy wykonywana tylko w tabeli źródłowej, pozostawiająca odbiorców w odczycie nieaktualnych nazw kolumn, to dryf schematu.
Potoki danych opierają się na kontrakcie zaufania między systemem źródłowym a magazynem docelowym. Kontrakt ten jest schematem: uzgodnioną strukturą, typami danych i nazwami kolumn, które definiują zbiór danych. Gdy zespoły nadrzędne zmieniają bazę danych aplikacji bez powiadomienia zespołu ds. danych, zrywają ten kontrakt.
Dryft schematu to nie to samo, co dryft danych. Dryft danych to zmiana rozkładu statystycznego wartości w stabilnym schemacie, spadek średnich wartości rzędu, wzrost współczynników wartości null oraz przesunięcie rozkładów kategorycznych. Oba te zjawiska są ważnymi sygnałami jakości danych, ale wymagają różnych metod wykrywania i wskazują na różne przyczyny. System wykrywania zmian schematu, który monitoruje nazwy i typy kolumn, nie wykryje dryftu danych; system monitorowania dystrybucji nie wykryje dodawania i usuwania kolumn.
Dryft schematu nie zawsze jest szkodliwy. Śledzenie stopnia dryftu w czasie pomaga odróżnić aktywne cykle rozwoju (dryft łagodny) od niestabilności (dryft krytyczny). Dodanie kolumny z wartością null do tabeli, zachowując wsteczną kompatybilność, to dryft schematu – schemat uległ zmianie, ale nie może to spowodować awarii żadnego konsumenta, który ignoruje nową kolumnę. Klasyfikacja dryftu jako łagodnego lub krytycznego wymaga zrozumienia konsumentów niższego rzędu i sposobu, w jaki radzą sobie ze zmianą.
Cztery typy dryfu schematu
Rozproszone systemy danych powodują dryf schematu wzdłuż czterech odrębnych wymiarów, z których każdy wymaga innych mechanizmów wykrywania:
Typ 1: Dryf strukturalny
Zmiany w definicji schematu fizycznego: dodawanie i usuwanie kolumn, zmiany nazw kolumn, zmiany typów danych, dodawanie i usuwanie ograniczeń, dodawanie i usuwanie tabel. Jest to najbardziej widoczna forma dryftu schematu i ta, którą najczęściej rozwiązują narzędzia do obserwowalności. Zapytania do bazy danych INFORMATION_SCHEMA, porównania rejestrów schematów i dzienniki audytu narzędzi do migracji skutecznie rejestrują dryft strukturalny w systemach połączonych.
Wykrywanie: porównanie migawki schematu z linią bazową, sondowanie INFORMATION_SCHEMA, porównanie wersji rejestru schematów.
Typ 2: Dryf semantyczny
Zmiana znaczenia istniejącego pola bez zmiany jego definicji. Kolumna o nazwie
statusktóry wcześniej zawierał wartościACTIVE,INACTIVE,PENDINGteraz zawiera wartości1,2,3Ponieważ usługa produkująca zmieniła swoje wyliczenie. Schemat, nazwa kolumny, typ danych, ograniczenie dopuszczające wartości null pozostają niezmienione. Kontrakt semantyczny jest zerwany. Konsumenci, którzy analizowali wartości statusu w postaci ciągu znaków, otrzymują teraz liczby całkowite, których ich logika nie obsługuje.Dryf semantyczny i dryf kontekstowy to nowe zjawiska, które są znacznie rzadziej monitorowane, mimo że oba odpowiadają za rosnącą liczbę awarii programów AI. Dryf semantyczny jest najtrudniejszy do automatycznego wykrycia, ponieważ nie generuje sygnału strukturalnego i wymaga monitorowania rozkładu wartości (zmiany stosunku wartości znanych do wartości nieznanych) lub jawnego testowania kontraktów.
Wykrywanie: monitorowanie rozkładu wartości; reguły sprawdzania dozwolonych wartości; testy kontraktów, które potwierdzają określone prawidłowe wartości.
Typ 3: Dryf formatu
Zmiany w kodowaniu lub formacie wartości w polach o niezmienionej strukturze. Pole znacznika czasu, które wcześniej zawierało ciągi UTC ISO 8601, teraz zawiera liczby całkowite epoki Unix. Pole waluty, które wcześniej zawierało kwoty dziesiętne, teraz zawiera kwoty w centach jako liczby całkowite. Kolumna istnieje, typ jest nadal prawidłowy dla nowych wartości, ale konwencja analizy składniowej uległa zmianie.
Dryf formatu jest szczególnie powszechny na granicach systemów rozproszonych, gdzie jedna usługa serializuje dane w formacie, który inna deserializuje, a także na granicy między starszymi i nowszymi wersjami, gdzie programy COBOL zapisują płaskie pliki ze specyficznymi konwencjami pozycji bajtów, od których zależą późniejsze procesy ETL.
Wykrywanie: statystyczne profilowanie zakresów wartości i wzorców; reguły walidacji formatu w określonych polach; testy kontraktów granicznych.
Typ 4: Dryf kontraktowy
Zmiany w gwarancjach dostępności, świeżości lub wolumenu źródła danych. System źródłowy wcześniej dostarczał zestaw danych codziennie o godzinie 3:00 UTC; teraz dostarcza go o godzinie 6:00, dyskretnie przerywając procesy downstream, które zakładały świeżość danych o godzinie 3:00. System źródłowy wcześniej gwarantował minimum 1,000 rekordów dziennie; okresy niskiego ruchu generują teraz mniej rekordów. Żadna ze zmian nie jest zmianą schematu w sensie strukturalnym, ale obie zrywają umowę między producentem a konsumentem.
Wykrywanie: monitorowanie świeżości, wykrywanie anomalii objętości, powiadamianie na podstawie SLA.
Dlaczego systemy rozproszone potęgują problem
W systemie monolitycznym z jedną bazą danych i jednym zespołem aplikacji, zmiany schematu są zdarzeniami kontrolowanymi. Administrator baz danych opracowuje migrację, programista aktualizuje zapytania, a zmiana jest wdrażana wspólnie. Ryzyko dryfu schematu istnieje, ale jest ograniczone zakresem pojedynczego organu.
Systemy rozproszone eliminują ten pojedynczy autorytet. Każda usługa jest właścicielem swoich danych. Każdy zespół podejmuje decyzje dotyczące schematów niezależnie. Odbiorcy danych każdej usługi często pozostają poza bezpośrednią świadomością tego zespołu, zwłaszcza gdy odbiorcami są platforma danych, potok analityczny lub starszy punkt integracji, którego żaden zespół produktowy aktywnie nie obsługuje.
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) │
└──────────────────┘Diagram ilustruje wzór propagacji: zespół Order Service dodaje coupon_id do swojej bazy danych. Jeśli zaktualizują również schemat zdarzeń Kafki, aby uwzględnić coupon_id, aby go wykorzystać, należy zaktualizować potok analityczny. Jeśli schemat Kafki jest nadal w wersji 1, pole nigdy nie dociera do potoku. Jeśli potok zostanie zaktualizowany, ale model pulpitu nawigacyjnego BI nie zostanie odświeżony, pole istnieje w magazynie, ale nie jest uwzględniane w raporcie. Dryf może spowodować cichą utratę danych na dowolnej z czterech granic, a każda granica wymaga innego mechanizmu wykrywania.
Ciche awarie potoków danych, nieaktualne pulpity nawigacyjne, dryf schematów i niekompletne zestawy danych stały się poważnym ryzykiem operacyjnym w nowoczesnych środowiskach danych przedsiębiorstw. Nowoczesne stosy danych ulegają awariom szybciej niż tradycyjne środowiska, a uszkodzone transformacje, błędy świeżości i ukryte uszkodzenia danych rozprzestrzeniają się w potokach danych na długo przed ręcznym wykryciem problemów przez zespoły.
To właśnie ta „cicha” właściwość sprawia, że rozproszony dryf schematu jest kosztowny. Błąd generujący wyjątek jest zauważany i naprawiany. Zmiana generująca po cichu błędne liczby pozostaje niewykryta, dopóki decyzja biznesowa oparta na tych liczbach nie przyniesie widocznych konsekwencji.
Podejścia do wykrywania według warstwy
Wykrywanie dryfu schematu wymaga różnych narzędzi i technik dla każdej warstwy rozproszonego systemu:
Warstwa bazy danych i magazynu
Najbardziej dojrzała warstwa wykrywania. Tabele INFORMATION_SCHEMA w każdej głównej bazie danych i magazynie zapewniają migawkę metadanych z możliwością zapytania:
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;Narzędzia automatyzujące ten wzorzec: testy schematu DBT, oczekiwania dotyczące kolumn Great Expectations, monitorowanie kondycji tabel Monte Carlo, monitorowanie dryfu schematu Acceldata.
Warstwa strumieniowania zdarzeń
Tematy Kafki korzystają z rejestrów schematów (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) do zarządzania ewolucją Avro, Protobuf i schematów JSON. Rejestr wymusza reguły zgodności w momencie publikacji:
jamla
# 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_elseRejestr schematu nie zapobiega dryfowi semantycznemu – pole, którego nazwa i typ pozostają niezmienione, ale którego znaczenie uległo zmianie, przechodzi kontrolę zgodności. Do walidacji semantycznej wymagane jest testowanie kontraktów (testowanie Pact, AsyncAPI).
Warstwa API
Istnieją cztery zasadniczo różne podejścia do wykrywania dryfu schematu API: porównywanie specyfikacji, monitorowanie specyfikacji z rzeczywistością, monitorowanie rzeczywistości z rzeczywistością oraz wykrywanie ruchu. Najwięcej nieporozumień w tym obszarze wynika z porównywania narzędzi w różnych podejściach.
W przypadku wewnętrznych interfejsów API usług w architekturze mikrousług najbardziej niezawodnym podejściem jest testowanie kontraktów sterowane przez konsumenta (Pact): każdy konsument określa kontrakt, którego wymaga od producenta, kontrakty są weryfikowane względem implementacji producenta w CI, a każda zmiana, która narusza kontrakt konsumenta, powoduje niepowodzenie zestawu testów producenta przed wdrożeniem.
Granica systemu legacy: gdzie dryf staje się niewidzialny
Każde z opisanych powyżej podejść do wykrywania działa w systemach, które udostępniają metadane schematu za pośrednictwem interfejsów z możliwością zapytania: INFORMATION_SCHEMA, rejestrów schematów, specyfikacji OpenAPI. Na granicy między starszymi systemami mainframe a nowoczesnymi platformami danych interfejsy te nie istnieją.
Program COBOL, który generuje conocny plik płaski do wykorzystania przez chmurowy potok ETL, definiuje niejawny schemat w logice wejścia i wyjścia FD. „Schemat” pliku płaskiego, pozycje bajtów, typy danych, pola dziesiętne spakowane w formacie COMP-3 oraz struktury REDEFINES znajdują się w kodzie źródłowym COBOL, a nie w żadnym rejestrze ani magazynie metadanych, do którego mogą odpytywać nowoczesne narzędzia do obserwowania.
kobol
*> 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
Jeśli zespół COBOL ulegnie zmianie CUST-BALANCE od PIC S9(11)V99 COMP-3 do PIC S9(13)V99 COMP-3Po dodaniu dwóch cyfr precyzji w celu obsługi większych wartości salda, pole rozszerza się z 7 bajtów do 8 bajtów w spakowanym formacie dziesiętnym. Każde pole po bajcie 50 przesuwa się o jedną pozycję. Plik płaski odczytywany przez potok ETL zawiera teraz wszystkie pola po komendzie CUST-BALANCE na niewłaściwych pozycjach bajtów. Potok ETL nie generuje błędu; odczytuje bajty 51–57 jako CUST-BALANCE i interpretuje kolejny bajt (który jest teraz pierwszym bajtem rozszerzonej reprezentacji CUST-BALANCE) jako część CUST-STATUS-CD. Potok działa. Liczby są nieprawidłowe. Nie jest generowany żaden alert o dryfcie schematu.
To najniebezpieczniejsza klasa dryfu schematu w środowiskach korporacyjnych: zmiany strukturalne w starszych systemach, które rozprzestrzeniają się po cichu przez interfejsy plików płaskich, bez żadnego mechanizmu wykrywania na żadnym z końców.
Trzy właściwości sprawiają, że przesuwanie granic dziedzictwa jest wyjątkowo niebezpieczne:
Schemat jest niewidoczny dla narzędzi obserwowalności. Metoda Monte Carlo nie może połączyć się z plikiem VSAM. Acceldata nie może wykonać zapytania o wpis FD. Jedynym sposobem na wykrycie zmiany jest porównanie kodu źródłowego COBOL z poprzednią wersją, co jest operacją analizy kodu, a nie monitorowania danych.
Propagacja jest cicha. Interfejsy plików płaskich nie weryfikują struktury rekordów; odczytują bajty. Zmiana układu bajtów generuje błędne wartości, a nie błędy.
Zasięg jest szeroki. Kopiarka COBOL dołączona do 300 programów to schemat współdzielony przez 300 programów. Zmiana w kopii, odpowiednik instrukcji ALTER TABLE w DDL, wpływa na wszystkie 300 programów jednocześnie, a każdy dalszy odbiorca dowolnego zestawu danych wygenerowanego przez którykolwiek z tych 300 programów dziedziczy ten dryf.
Kontrakty schematów: Formalizowanie tego, co zwykle jest niejawne
Strukturalnym rozwiązaniem problemu dryfu schematu jest uczynienie niejawnych kontraktów jawnymi, zdefiniowanie, czym jest schemat, kto od niego zależy i jakie zmiany są dozwolone, przed wprowadzeniem zmiany, a nie po tym, jak coś zepsuje.
| Warstwa kontraktu | Co rządzi | Narzędzia | Odpowiednik starszej wersji |
|---|---|---|---|
| Baza danych DDL | Struktura tabeli, typy kolumn, ograniczenia | Liquibase, Flyway, Atlas | Skrypty migracji DDL DB2 |
| Schemat zdarzenia | Struktura strumienia Kafki/zdarzeń | Rejestr schematów konfluentnych, Apicurio | N/A (plik płaski nie ma rejestru) |
| Kontrakt API | Oczekiwania dotyczące interfejsu REST/gRPC | OpenAPI, Pact, AsyncAPI | N/A (interfejs pliku nie ma specyfikacji) |
| Jakość danych | Dystrybucje wartości, świeżość, wolumen | Wielkie nadzieje, testy DBT | N/A (brak natywnego środowiska testowego) |
| Umowa dotycząca formatu pliku | Płaski układ bajtów pliku, pozycje pól | Wpis COBOL FD (źródło prawdy) | Kontrola wersji kopii książki |
Wpis „Kontrola wersji kopii” w kolumnie odpowiednika starszej wersji to praktyczny mechanizm zarządzania ewolucją schematu COBOL: traktowanie kopii jako artefaktu z wersjonowaną wersją z procesem zatwierdzania zmian, prowadzenie rejestru programów zawierających każdą kopię i wymaganie analizy wpływu przed zatwierdzeniem jakiejkolwiek modyfikacji kopii.
Przepływ pracy zatwierdzania zmian w kopii:
- Deweloper proponuje zmianę
CUSTMSTR.CPY - Analiza wpływu identyfikuje każdy program, który obejmuje
CUSTMSTR.CPY(analiza statyczna) - Każdy plik płaski wygenerowany przez te programy jest identyfikowany jako zdarzenie zmiany schematu
- Każdy dalszy odbiorca tych plików płaskich jest powiadamiany
- Przeprowadzono testy walidacji konsumenckiej nowego układu
- Zmiana zostanie zatwierdzona dopiero wtedy, gdy wszyscy konsumenci potwierdzą kompatybilność
Ten przepływ pracy odzwierciedla wzorzec wymuszania zgodności rejestru schematów stosowany do warstwy COBOL, w której nie istnieje natywny rejestr schematów.
Architektura monitorowania rozproszonego dryfu schematu
Kompleksowa architektura monitorowania dryfu schematu obejmuje wszystkie cztery typy dryfu na wszystkich warstwach systemu:
Baza danych migawek schematu. Przechowuj codzienną migawkę metadanych INFORMATION_SCHEMA każdej tabeli, każdej zarejestrowanej wersji schematu zdarzeń, każdej wersji specyfikacji API oraz (w przypadku starszych systemów) każdej wersji copybook. Baza danych migawek stanowi punkt odniesienia, z którym porównywany jest stan bieżący.
Proces wykrywania zmian. Codzienne zadania porównawcze są uruchamiane na bazie danych migawek, wykrywając dodawanie, usuwanie, zmiany typów i ograniczenia na każdej monitorowanej warstwie. Zmiany o wysokiej istotności, zmiany typów niezgodne z poprzednimi wersjami, usunięcia kolumn, dodawanie pól wymaganych, wyzwalają natychmiastowe alerty. Zmiany o niskiej istotności, dodawanie kolumn z dopuszczalnymi wartościami null, zmiany indeksów, generują powiadomienia doradcze.
Rejestr wpływu na konsumentów. Katalog, który mapuje każdy artefakt schematu na znanych konsumentów: które potoki odczytują z których tabel, które usługi korzystają z których tematów Kafki, które zadania ETL przetwarzają które pliki płaskie. Po wykryciu zmiany schematu rejestr wpływu na konsumentów określa promień rażenia, liczbę konsumentów, których dotyczy zmiana, oraz to, którzy są najbardziej krytyczni.
Zestaw testów kontraktowych. Zautomatyzowane testy weryfikujące założenia konsumenta dotyczące schematów producenta. Uruchamiane przy każdym wdrożeniu, które ma związek z usługą generującą dane. Wdrożenie kończy się niepowodzeniem, jeśli kontrakt, od którego zależy zarejestrowany konsument, zostanie naruszony.
Monitorowanie granic starszej wersji. W przypadku systemów mainframe: porównanie kopii z kontrolą wersji, monitorowanie definicji zestawu danych JCL oraz walidacja formatu pliku płaskiego względem schematu zdefiniowanego we wpisie FD programu generującego. Ta warstwa wymaga analizy kodu, a nie monitorowania danych, wykrywając zmiany w kodzie źródłowym COBOL, które stanowią zmiany schematu dla dalszych użytkowników.
Planowane monitorowanie ma większe znaczenie, niż zakłada wiele zespołów. Wskazówki Acceldata dotyczące planowej analizy dryfu zalecają automatyczne porównania ze stabilną linią bazową w tygodniowym lub dwutygodniowym rytmie i wyraźnie zaznaczają, że oczekiwanie na doraźne kontrole po awarii jest niewystarczające. W przypadku monitorowania granic starszych systemów, rytm powinien być zgodny z harmonogramem wdrażania COBOL: każde wydanie kopii zapasowej w środowisku produkcyjnym powinno uruchamiać natychmiastową analizę wpływu schematu, zamiast czekać na kolejne zaplanowane porównanie.
W jaki sposób SMART TS XL Rozwiązuje problem dryfu schematu w środowiskach starszych
SMART TS XL rozwiązuje problem luki w wykrywaniu na granicy starszego systemu, czyli na warstwie, na której kończą się nowoczesne narzędzia obserwacji i gdzie najbardziej niebezpieczne odchylenia schematu pozostają niewykryte.
Funkcja statycznej analizy kodu analizuje każdy wpis FD języka COBOL, element COPY i klauzulę SELECT, aby wygenerować ustrukturyzowaną reprezentację każdego artefaktu schematu w starszym środowisku. Po uruchomieniu tej analizy na dwóch wersjach bazy kodu, przed i po wdrożeniu, różnice stanowią dziennik zmian schematu starszego: które kopie zostały zmienione, które definicje pól zostały zmienione, jakie były układy przed i po wdrożeniu. Jest to porównanie migawek schematu zastosowane do warstwy COBOL.
Mapowanie zależności aplikacji zapewnia rejestr wpływu konsumentów na starsze schematy: które programy zawierają każdy copybook, które programy generują które płaskie zbiory danych, które zadania JCL wywołują które programy. Gdy dziennik zmian schematu zidentyfikuje zmodyfikowany copybook, mapa zależności natychmiast generuje listę konsumentów, każdy program zawierający copybook oraz każdy płaski plik generowany przez te programy. To obliczenie promienia rażenia określa, czy zmiana copybooka jest modyfikacją wewnętrzną o niskim ryzyku, czy zdarzeniem o wysokim ryzyku, wpływającym na setki programów i dziesiątki dalszych konsumentów.
Funkcja analizy wpływu konwertuje promień rażenia na ustrukturyzowany zakres remediacji: dla każdego konsumenta zidentyfikowanego przez mapę zależności, jakie zmiany są wymagane, aby dostosować się do nowego schematu i w jakiej kolejności należy je wprowadzić? W przypadku konsumentów granicznych od starszych do nowszych, czyli potoków ETL odczytujących pliki płaskie generowane przez programy COBOL, analiza wpływu identyfikuje konkretne zmiany pozycji pól i typów danych, które należy zaktualizować w konfiguracji mapowania kolumn potoku ETL.
Funkcja wyszukiwania korporacyjnego umożliwia wyszukiwanie artefaktów schematu za pomocą zapytań: znajdź każdy program odczytujący pole w określonej pozycji bajtu (identyfikując odbiorców, na których wpłynie zmiana układu), każdy copybook definiujący określone pole (identyfikując artefakt schematu, który musi być wersjonowany i kontrolowany pod kątem zmian), każdy program generujący dane wyjściowe do określonego zestawu danych (identyfikując producentów, których zmiany schematu muszą wywołać powiadomienia odbiorców). Ta funkcja wyszukiwania obsługuje zarówno proaktywny przepływ pracy w zakresie zarządzania schematem, jak i badanie incydentów po wystąpieniu odchylenia.
Dla organizacji zarządzających modernizacja dziedziczna programy obejmujące migrację danych z komputerów mainframe na nowoczesne platformy, SMART TS XLAnaliza schematu zapewnia dokumentację schematu źródłowego wymaganą przez narzędzia migracji, kompletne, aktualne definicje wpisów FD i struktury kopii, które definiują, czym są faktycznie dane, a nie tylko czym były w momencie pisania oryginalnej specyfikacji migracji.
Umowa, której nikt nie napisał, nadal jest umową
Dryf schematu w systemach rozproszonych nie jest nowym problemem. To stary problem, który architektura rozproszona utrudnia rozwiązanie, ponieważ uprawnienia egzekwowania kontraktów schematu w systemach monolitycznych – centralny administrator baz danych, pojedynczy zespół ds. aplikacji, ujednolicona baza kodu – zostały rozproszone na dziesiątki niezależnych usług, z których każda podejmuje indywidualnie rozsądne decyzje, nie mając pełnego wglądu w każdego odbiorcę.
Rozwiązaniem nie jest ponowna centralizacja uprawnień nad schematem. Chodzi o to, aby jawnie ujawnić niejawne kontrakty, zarejestrować je w systemach, które mogą porównywać stan bieżący z bazowym, egzekwować reguły zgodności na granicach wprowadzania zmian oraz monitorować naruszenia na granicach propagacji zmian. W przypadku nowoczesnych systemów narzędzia do tego celu istnieją i są szybko udoskonalane. W przypadku starszych systemów na granicy z nowoczesnymi platformami luka w narzędziach jest realna i ma istotne konsekwencje. Płaski format pliku, jakim jest kontrakt schematu dla potoku ETL w chmurze, jest niewidoczny dla każdego nowoczesnego narzędzia do obserwowalności, chyba że źródło COBOL, które go definiuje, zostanie przeanalizowane i wersjonowane jako artefakt schematu.
Panel, który wykazał 23-procentowy spadek liczby pozyskiwanych klientów, nie mylił się co do otrzymanych danych. Mylił się co do znaczenia danych, ponieważ schemat definiujący ich znaczenie zmienił się w punkcie, w którym nie zarejestrowano żadnej umowy i nie monitorowano żadnego monitora. Ta granica, niezależnie od tego, gdzie występuje w systemie rozproszonym, tradycyjnym czy nowoczesnym, to właśnie tam muszą dotrzeć programy do wykrywania dryfu schematu.
