Analytický panel byl v úterý v pořádku. Do čtvrtka vykazoval 23% pokles v získávání zákazníků, což obchodní tým považoval za skutečný obchodní signál, reorganizoval marketingové rozpočty, pozastavil kampaně a eskaloval problém na správní radě. Tým datového inženýrství v pátek zjistil, že upstreamová služba přidala do sloupce s hodnotou Null. registrations tabulka o šest dní dříve. ETL kanál nebyl aktualizován. Výpočet, který odvodil metriku akvizice, považoval nové hodnoty null za nuly, místo aby je vyloučil. Nebylo odesláno žádné oznámení o změně schématu. Žádná smlouva nebyla porušena způsobem, který by způsobil chybu. Kanál běžel úspěšně; generoval nesprávná čísla, která vypadala správně.
Posun schématu představuje strukturální mutaci. Na rozdíl od problémů s kvalitou dat, kde jsou hodnoty nesprávné, posun schématu narušuje smlouvu mezi zdrojem a cílem. V monolitickém databázovém prostředí s centrálním správcem databází, který řídí veškerou DDL, je tato smlouva vynucována jedinou autoritou. V distribuovaném systému, kde desítky nezávislých služeb vlastní své vlastní úložiště dat, kde proudy událostí nesou schémata Avro, která se vyvíjejí nezávisle, kde rozhraní plochých souborů mezi dávkovými úlohami mainframe a platformami cloudové analytiky definují implicitní smlouvy, které neexistují v dokumentaci žádného z těchto systémů, je smlouva distribuována napříč všemi hranicemi systému. Posun schématu v distribuovaném prostředí nečeká, až správce databází udělá chybu. Vyplývá z běžného provozu autonomních týmů, které činí individuálně rozumná rozhodnutí bez úplného přehledu o každém následném spotřebiteli jejich dat.
Mapování hranic staršího schématu
SMART TS XL identifikuje každou smlouvu o formátu plochého souboru, která propojuje mainframové programy s moderními analytickými platformami.
ZJISTĚTE VÍCE…Co je a co není drift schématu
Posun schématu je změna ve struktuře datového artefaktu, která se neprojevuje u příjemců daného artefaktu. Důraz na příjemce je to, co odlišuje posun od plánované migrace: přejmenování sloupce provedené současně ve zdrojové tabulce a každý dotaz, který daný sloupec spotřebovává, je migrace schématu. Stejné přejmenování provedené pouze ve zdrojové tabulce, které ponechává příjemce čtoucí zastaralé názvy sloupců, je posun schématu.
Datové kanály se spoléhají na smlouvu o důvěře mezi zdrojovým systémem a cílovým datovým skladem. Tato smlouva představuje schéma: dohodnutou strukturu, datové typy a názvy sloupců, které definují datovou sadu. Když nadřazené týmy změní databázi své aplikace, aniž by o tom informovaly datový tým, tuto smlouvu porušují.
Posun schématu není totéž co posun dat. Posun dat je změna ve statistickém rozložení hodnot v rámci stabilního schématu, kdy průměrné hodnoty pořadí klesají, míra nulových hodnot roste, rozdělení kategorií se posouvá. Oba jsou důležité signály kvality dat, ale vyžadují odlišné přístupy k detekci a indikují odlišné základní příčiny. Systém detekce změn schématu, který monitoruje názvy a typy sloupců, nepostihne posun dat; systém monitorování distribuce nepostihne přidání a odebrání sloupců.
Posun schématu také nemusí být vždy škodlivý. Sledování závažnosti posunu v čase pomáhá rozlišit mezi aktivními vývojovými cykly (benigní posun) a nestabilitou (kritický posun). Zpětně kompatibilní přidání sloupce s povolenou hodnotou null do tabulky je posun schématu, schéma se změnilo, ale nemusí narušit žádného příjemce, který nový sloupec ignoruje. Klasifikace posunu jako benigního nebo kritického vyžaduje pochopení následných příjemců a toho, jak se s touto změnou vypořádají.
Čtyři typy driftu schématu
Distribuované datové systémy způsobují posun schématu ve čtyřech odlišných dimenzích, z nichž každá vyžaduje odlišné detekční mechanismy:
Typ 1: Strukturální posun
Změny v definici fyzického schématu: přidání sloupců, odebrání sloupců, přejmenování sloupců, změny datových typů, přidání nebo odebrání omezení, přidání a odebrání tabulek. Toto je nejviditelnější forma posunu schématu a ta, kterou nejčastěji řeší nástroje pro sledování. Dotazy INFORMATION_SCHEMA databáze, porovnání registrů schémat a protokoly auditu migračních nástrojů efektivně zachycují strukturální posun pro připojené systémy.
Detekce: Porovnání snímku schématu s výchozím stavem; dotazování INFORMATION_SCHEMA; porovnání verzí registru schématu.
Typ 2: Sémantický drift
Změny významu existujícího pole beze změn jeho definice. Sloupec s názvem
statuskteré dříve obsahovaly hodnotyACTIVE,INACTIVE,PENDINGnyní obsahuje hodnoty1,2,3protože produkční služba změnila svůj výčet. Schéma, název sloupce, datový typ a omezení s povolenou hodnotou null se nezměnily. Sémantický kontrakt je porušen. Příjemci, kteří analyzovali stavové hodnoty řetězců, nyní dostávají celá čísla, která jejich logika nezpracovává.Sémantický drift a kontextový drift jsou v diskusi novější a dramaticky méně monitorované, přestože oba jsou zodpovědné za rostoucí podíl selhání programů umělé inteligence. Sémantický drift je nejobtížněji zachytitelný automaticky, protože neprodukuje žádný strukturální signál, vyžaduje buď monitorování distribuce hodnot (poměr změn známých a neznámých hodnot), nebo explicitní testování smluv.
Detekce: Monitorování distribuce hodnot; pravidla pro validaci povolených hodnot; smluvní testy, které uplatňují specifické platné hodnoty.
Typ 3: Posun formátu
Změny kódování nebo formátu hodnot v rámci strukturálně nezměněných polí. Pole časového razítka, které dříve obsahovalo řetězce UTC ISO 8601, nyní obsahuje celá čísla z období Unixu. Pole měny, které dříve obsahovalo desetinné částky, nyní obsahuje částky v centech jako celá čísla. Sloupec existuje, typ je stále platný pro nové hodnoty, ale konvence parsování se změnila.
Posun formátu je obzvláště běžný na hranicích distribuovaných systémů, kde jedna služba serializuje data ve formátu, který jiná deserializuje, a na hranici mezi staršími a moderními systémy, kde programy v COBOLu zapisují ploché soubory se specifickými konvencemi pozic bajtů, na kterých závisí následné ETL procesy.
Detekce: Statistické profilování rozsahů hodnot a vzorů; pravidla validace formátu pro specifická pole; testy hraničních smluv.
Typ 4: Posun smlouvy
Změny v dostupnosti, aktuálnosti nebo objemových zárukách zdroje dat. Zdrojový systém dříve dodával datovou sadu denně do 3:00 UTC; nyní ji dodává do 6:00, čímž tiše přerušuje následné procesy, které předpokládaly aktuálnost ve 3:00. Zdrojový systém dříve garantoval minimálně 1 000 záznamů denně; období s nízkým provozem nyní produkují méně záznamů. Ani jedna ze změn není změnou schématu ve strukturálním smyslu, ale obě porušují smlouvu mezi producentem a příjemcem.
Detekce: Monitorování aktuálnosti; detekce anomálií objemu; upozornění na základě SLA.
Proč distribuované systémy problém zhoršují
V monolitickém systému s jednou databází a jedním aplikačním týmem jsou změny schématu řízenými událostmi. DBA zapíše migraci, vývojář aktualizuje dotazy a změna se nasadí společně. Riziko posunu schématu existuje, ale je omezeno rozsahem jediné autority.
Distribuované systémy tuto jednotnou autoritu odstraňují. Každá služba vlastní svá data. Každý tým činí rozhodnutí o schématu nezávisle. Příjemci dat každé služby jsou často mimo bezprostřední povědomí daného týmu, zejména pokud je příjemcem datová platforma, analytický kanál nebo starší integrační bod, který žádný produktový tým aktivně neudržuje.
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 znázorňuje vzorec šíření: tým Order Service přidává coupon_id do své databáze. Pokud také aktualizují schéma událostí Kafka tak, aby zahrnovalo coupon_id, analytický kanál musí být aktualizován, aby jej bylo možné využít. Pokud je schéma Kafka stále ve verzi 1, pole se do kanálu nikdy nedostane. Pokud je kanál aktualizován, ale model řídicího panelu BI není aktualizován, pole existuje ve skladu, ale v sestavě chybí. Posun může způsobit tichou ztrátu dat na kterékoli ze čtyř hranic a každá hranice vyžaduje jiný detekční mechanismus.
Tiché selhání datových kanálů, zastaralé dashboardy, posun schématu a neúplné datové sady se staly hlavními provozními riziky v moderních podnikových datových prostředích. Moderní datové zásobníky selhávají rychleji než tradiční prostředí, přičemž poškozené transformace, selhání aktuálnosti a tiché poškození dat se šíří napříč kanály dlouho předtím, než týmy problémy odhalí ručně.
Právě „tichá“ vlastnost je důvodem, proč je posun distribuovaného schématu drahý. Chyba, která způsobí výjimku, je zaznamenána a opravena. Změna, která tiše produkuje chybná čísla, probíhá nepozorovaně, dokud obchodní rozhodnutí založené na těchto číslech nepřinese viditelné důsledky.
Detekční přístupy podle vrstvy
Detekce posunu schématu vyžaduje pro každou vrstvu distribuovaného systému jiné nástroje a techniky:
Databázová a skladová vrstva
Nejvyspělejší detekční vrstva. Tabulky INFORMATION_SCHEMA v každé hlavní databázi a úložišti poskytují snímek metadat, na který lze dotazovat:
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;Nástroje, které tento vzorec automatizují: testy schématu DBT, očekávání sloupců Great Expectations, monitorování stavu tabulek Monte Carlo, monitorování driftu schématu Acceldata.
Vrstva streamování událostí
Témata Kafka používají registry schémat (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) k řízení vývoje schémat Avro, Protobuf a JSON. Registr vynucuje pravidla kompatibility v době publikování:
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_elseRegistr schématu nezabraňuje sémantickému driftu, což je pole, jehož název a typ se nezměnily, ale jehož význam se změnil, projde kontrolami kompatibility. Pro sémantickou validaci je vyžadováno testování kontraktů (Pact, AsyncAPI).
Vrstva API
Existují čtyři zásadně odlišné přístupy k zachycení odchylek schématu API: porovnávání specifikací, monitorování specifikací a reality, monitorování reality a detekce na základě provozu. Většina zmatků v této oblasti pramení z porovnávání nástrojů s různými přístupy.
Pro interní servisní API v architektuře mikroslužeb je nejspolehlivějším přístupem testování smluv řízených spotřebitelem (Pact): každý spotřebitel specifikuje smlouvu, kterou od producenta požaduje, smlouvy jsou ověřeny oproti implementaci producenta v CI a jakákoli změna, která naruší smlouvu spotřebitele, před nasazením neprojde testovací sadou producenta.
Hranice staršího systému: Kde se drift stává neviditelným
Každý výše popsaný detekční přístup funguje pro systémy, které zpřístupňují metadata schématu prostřednictvím dotazovatelných rozhraní: INFORMATION_SCHEMA, registry schémat, specifikace OpenAPI. Na hranici mezi staršími mainframe systémy a moderními datovými platformami tato rozhraní neexistují.
Program v COBOLu, který každou noc vytváří plochý soubor pro spotřebu cloudovým ETL kanálem, definuje implicitní schéma ve své vstupní a výstupní logice FD. „Schéma“ plochého souboru, pozice bajtů, datové typy, decimalní pole COMP-3 a struktury REDEFINES existují ve zdrojovém kódu COBOLu, nikoli v žádném registru nebo úložišti metadat, které mohou moderní nástroje pro pozorovatelnost dotazovat.
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
Pokud se tým COBOL změní CUST-BALANCE od PIC S9(11)V99 COMP-3 na PIC S9(13)V99 COMP-3, přidáním dvou číslic přesnosti pro zpracování větších hodnot zůstatku se pole v dekadickém formátu rozšíří ze 7 bajtů na 8 bajtů. Každé pole po bajtu 50 se posune o jednu pozici. Plochý soubor, který ETL kanál čte, má nyní všechna pole po CUST-BALANCE na nesprávných bajtových pozicích. ETL kanál negeneruje chybu; čte bajty 51-57 jako CUST-BALANCE a interpretuje další bajt (který je nyní prvním bajtem rozšířené reprezentace CUST-BALANCE) jako součást CUST-STATUS-CD. Kanál běží. Čísla jsou nesprávná. Nespustí se žádné upozornění na posun schématu.
Toto je nejnebezpečnější třída posunu schématu v podnikových prostředích: strukturální změny ve starších systémech, které se tiše šíří přes rozhraní plochých souborů bez detekčního mechanismu na obou koncích.
Tři vlastnosti činí posun hranic starších systémů jedinečně nebezpečným:
Schéma je pro nástroje pro sledování neviditelné. Monte Carlo se nemůže připojit k souboru VSAM. Acceldata se nemůže dotazovat na položku FD. Jediný způsob, jak detekovat změnu, je porovnat zdrojový kód COBOLu s předchozí verzí, což je operace analýzy kódu, nikoli operace monitorování dat.
Šíření je tiché. Rozhraní plochých souborů neověřují strukturu záznamů; čtou bajty. Změna rozložení bajtů vede k nesprávným hodnotám, nikoli k chybám.
Poloměr šíření je široký. COBOL sešit, který je součástí 300 programů, je schéma sdílené 300 programy. Změna v sešitě, ekvivalent příkazu DDL ALTER TABLE, ovlivní všech 300 programů současně a každý následný příjemce jakékoli datové sady vytvořené kterýmkoli z těchto 300 programů zdědí tento posun.
Schématické smlouvy: Formalizace toho, co je obvykle implicitní
Strukturálním řešením posunu schématu je vytvoření explicitních implicitních smluv, které definují, co schéma je, kdo na něm závisí a jaké změny jsou povoleny, a to před provedením změny, a ne až poté, co něco naruší.
| Smluvní vrstva | Co řídí | Tools | Ekvivalent starší verze |
|---|---|---|---|
| Databázový DDL | Struktura tabulky, typy sloupců, omezení | Liquibase, Flyway, Atlas | Migrační skripty DB2 DDL |
| Schéma události | Struktura proudu událostí Kafka/událost | Registr konfluentních schémat, Apicurio | N/A (plochý soubor nemá registr) |
| Smlouva API | Očekávání rozhraní REST/gRPC | OpenAPI, Pact, AsyncAPI | N/A (rozhraní souboru nemá žádnou specifikaci) |
| Kvalita dat | Distribuce hodnot, čerstvost, objem | Velká očekávání, DBT testy | N/A (žádný nativní testovací framework) |
| Smlouva o formátu souboru | Rozložení bajtů v plochém souboru, pozice polí | COBOL FD heslo (zdroj pravdy) | Řízení verzí Copybooku |
Položka „Řízení verzí sešitu“ ve sloupci ekvivalentu starší verze představuje praktický mechanismus pro správu vývoje schématu COBOL: sešit se zachází jako s verzovaným artefaktem s procesem schvalování změn, udržuje se registr programů, které jednotlivé sešity obsahují, a před schválením jakékoli úpravy sešitu je vyžadována analýza dopadu.
Pracovní postup schvalování změn v sešitě:
- Vývojář navrhuje změnu
CUSTMSTR.CPY - Analýza dopadů identifikuje každý program, který zahrnuje
CUSTMSTR.CPY(statická analýza) - Každý plochý soubor vytvořený těmito programy je identifikován jako událost změny schématu.
- Každý následný uživatel těchto plochých souborů je informován.
- Spotřebitelské ověřovací testy se provádějí s ohledem na nové rozvržení.
- Změna je schválena pouze tehdy, když všichni spotřebitelé potvrdí kompatibilitu.
Tento pracovní postup zrcadlí vzor vynucení kompatibility registru schématu, aplikovaný na vrstvu COBOL, kde neexistuje žádný nativní registr schématu.
Architektura monitorování pro posun distribuovaného schématu
Kompletní architektura monitorování posunu schématu pokrývá všechny čtyři typy posunu napříč všemi vrstvami systému:
Databáze snímků schématu. Ukládá denní snímek metadat INFORMATION_SCHEMA každé tabulky, každé verze schématu registrovaných událostí, každé verze specifikace API a (u starších systémů) každé verze copybooku. Databáze snímků je základní linií, se kterou se porovnává aktuální stav.
Kanál detekce změn. Denní porovnávací úlohy se spouštějí s databází snímků a detekují přidání, odebrání, změny typů a změny omezení na každé monitorované vrstvě. Změny s vysokou závažností, změny typů, které nejsou zpětně kompatibilní, odebrání sloupců, přidání povinných polí, spouštějí okamžitá upozornění. Změny s nízkou závažností, přidání sloupců s hodnotou Null, změny indexů, generují upozornění.
Registr dopadu na spotřebitele. Katalog, který mapuje každý artefakt schématu na jeho známé spotřebitele: které kanály čtou z kterých tabulek, které služby spotřebovávají která témata Kafka, které úlohy ETL zpracovávají které ploché soubory. Když je detekována změna schématu, registr dopadu na spotřebitele určí poloměr výbuchu, kolik spotřebitelů je ovlivněno a kteří jsou nejkritičtější.
Sada testů smluv. Automatizované testy, které ověřují předpoklady spotřebitelů o schématech producentů. Spouštějí se na každém nasazení, které se dotýká služby produkující data. Nasazení selže, pokud je porušena smlouva, na které je registrovaný spotřebitel závislý.
Monitorování hranic starších systémů. Pro sálové systémy: porovnávání verzovaně řízených copybooků, monitorování definic datových sad JCL a validace formátu plochých souborů oproti schématu definovanému v položce FD produkčního programu. Tato vrstva vyžaduje spíše analýzu kódu než monitorování dat a detekuje změny ve zdrojovém kódu COBOL, které představují změny schématu pro následné uživatele.
Plánované monitorování je důležitější, než si mnoho týmů myslí. Pokyny společnosti Acceldata k plánované analýze driftu doporučují automatizovaná porovnávání se stabilní základní hodnotou v týdenní nebo čtrnáctidenní kadenci a výslovně uvádějí, že čekání na ad hoc kontroly po selhání je nedostatečné. Konkrétně u monitorování hranic starších systémů by kadence měla odpovídat harmonogramu nasazení COBOLu: jakékoli vydání copybooku do produkčního prostředí by mělo spustit okamžitou analýzu dopadu schématu, spíše než čekání na další plánované porovnání.
Jak SMART TS XL Řeší drift schématu ve starších prostředích
SMART TS XL řeší mezeru v detekci na hranici staršího systému, vrstvě, kde se moderní nástroje pro pozorování zastavují a kde nejnebezpečnější posun schématu zůstává nepovšimnut.
Funkce statické analýzy kódu analyzuje každou položku COBOL FD, člen COPY a klauzuli SELECT, aby vytvořila strukturovanou reprezentaci každého artefaktu schématu ve starším prostředí. Když je tato analýza spuštěna na dvou verzích kódové základny, před a po nasazení, rozdíly tvoří protokol změn staršího schématu: které sešity se změnily, které definice polí se změnily, jaké bylo rozvržení před a po. Toto je porovnání snímků schématu aplikované na vrstvu COBOL.
Mapování závislostí aplikací poskytuje registr dopadů na spotřebitele pro starší schémata: které programy zahrnují jednotlivé sešity, které programy produkují které datové sady plochých souborů, které úlohy JCL volají které programy. Když protokol změn schématu identifikuje upravený sešit, mapa závislostí okamžitě vygeneruje seznam spotřebitelů, každý program, který obsahuje sešit, a každý následný plochý soubor, který tyto programy produkují. Toto je výpočet poloměru šíření, který určuje, zda je změna sešitu nízkorizikovou interní modifikací nebo vysoce rizikovou událostí, která ovlivňuje stovky programů a desítky následných spotřebitelů.
Funkce analýzy dopadu převádí poloměr výbuchu do strukturovaného rozsahu nápravy: pro každého příjemce identifikovaného mapou závislostí jsou nutné změny, aby se přizpůsobilo novému schématu, a v jakém pořadí by měly být tyto změny provedeny? U hraničních příjemců od starších po moderní, tedy u ETL kanálů, které čtou ploché soubory vytvořené programy v COBOLu, analýza dopadu identifikuje specifické změny polohy polí a změny datových typů, které je nutné aktualizovat v konfiguraci mapování sloupců ETL kanálu.
Funkce podnikového vyhledávání umožňuje dotazování při vyhledávání artefaktů schématu: nalezení každého programu, který čte pole na určité bajtové pozici (identifikace příjemců, kteří budou ovlivněni změnou rozvržení), každého sešitu, který definuje určité pole (identifikace artefaktu schématu, který musí být verzovaný a řízený změnami), každého programu, který produkuje výstup do určité datové sady (identifikace producentů, jejichž změny schématu musí spustit oznámení příjemcům). Tato vyhledávací funkce podporuje jak proaktivní pracovní postup správy schématu, tak i vyšetřování incidentů po posunu.
Pro organizace spravující starší modernizace programy, které zahrnují migraci dat z mainframů na moderní platformy, SMART TS XLAnalýza schématu poskytuje dokumentaci zdrojového schématu, kterou migrační nástroje vyžadují, kompletní a aktuální definice položek FD a struktury copybooku, které definují, co data skutečně jsou, nejen to, co byla v době, kdy byla napsána původní specifikace migrace.
Smlouva, kterou nikdo nenapsal, je stále smlouvou
Posun schématu v distribuovaných systémech není nový problém. Je to starý problém, jehož řešení distribuovaná architektura ztěžuje, protože autorita, která vynucovala smlouvy schématu v monolitických systémech – centrální správce databází, jednotný aplikační tým a jednotná kódová základna – byla rozdělena mezi desítky nezávislých služeb, z nichž každá činí individuálně rozumná rozhodnutí s neúplným přehledem o každém následném uživateli.
Řešením není recentralizace autority nad schématem. Jde o to, aby byly implicitní kontrakty explicitní, aby byly registrovány v systémech, které dokáží porovnat aktuální stav s výchozím stavem, vynutit pravidla kompatibility na hranicích, kde jsou změny zaváděny, a monitorovat porušení na hranicích, kde se změny šíří. Pro moderní systémy nástroje pro tento účel existují a rychle se zlepšují. Pro starší systémy na hranici s moderními platformami je mezera v nástrojích skutečná a závažná. Plochý formát souboru, který je kontraktem schématu pro cloudový ETL kanál, je pro žádný moderní nástroj pro sledování neviditelný, pokud není zdrojový kód COBOL, který jej definuje, analyzován a verzován jako artefakt schématu.
Panel, který ukazoval 23procentní pokles v získávání zákazníků, se nemýlil v obdržených datech. Mýlil se v tom, co data znamenají, protože schéma, které definovalo význam dat, se změnilo na hranici, kde nebyla registrována žádná smlouva a žádný monitor to nesledoval. Tato hranice, ať už existuje kdekoli v distribuovaném systému, ať už starším nebo moderním, je oblastí, kam musí programy na detekci posunu schématu dosáhnout.
