Le tableau de bord analytique était correct mardi. Jeudi, il affichait une baisse de 23 % des acquisitions de clients, que l'équipe commerciale a interprétée comme un véritable signal d'alarme, entraînant une réorganisation des budgets marketing, la suspension de campagnes et une remontée d'information auprès de la direction. L'équipe d'ingénierie des données a découvert vendredi que le service en amont avait ajouté une colonne autorisant les valeurs nulles. registrations Le tableau avait été modifié six jours auparavant. Le pipeline ETL n'avait pas été mis à jour. Le calcul de la métrique d'acquisition traitait les nouvelles valeurs nulles comme des zéros au lieu de les exclure. Aucune notification de modification de schéma n'avait été envoyée. Aucun contrat n'avait été enfreint de manière à générer une erreur. Le pipeline s'est exécuté avec succès ; il a produit des chiffres erronés qui semblaient corrects.
La dérive de schéma représente une mutation structurelle. Contrairement aux problèmes de qualité des données où les valeurs sont incorrectes, la dérive de schéma rompt le contrat entre la source et la destination. Dans un environnement de base de données monolithique avec un administrateur de base de données central qui contrôle toutes les instructions DDL, ce contrat est appliqué par une autorité unique. Dans un système distribué, où des dizaines de services indépendants possèdent chacun leur propre entrepôt de données, où les flux d'événements véhiculent des schémas Avro qui évoluent indépendamment, où les interfaces de fichiers plats entre les traitements par lots du mainframe et les plateformes d'analyse cloud définissent des contrats implicites qui n'existent dans la documentation d'aucun des deux systèmes, le contrat est distribué à toutes les limites du système. La dérive de schéma dans un environnement distribué n'attend pas qu'un administrateur de base de données commette une erreur. Elle émerge du fonctionnement normal d'équipes autonomes prenant des décisions judicieuses individuellement sans visibilité complète sur tous les utilisateurs en aval de leurs données.
Cartographier les limites du schéma existant
SMART TS XL identifie tous les contrats de format de fichier plat reliant les programmes mainframe aux plateformes d'analyse modernes.
EN SAVOIR PLUS…Qu’est-ce que la dérive de schéma, et qu’est-ce qu’elle n’est pas ?
La dérive de schéma est une modification de la structure d'un artefact de données qui n'est pas répercutée chez les utilisateurs de cet artefact. L'accent mis sur les utilisateurs est ce qui distingue la dérive d'une migration planifiée : un renommage de colonne exécuté simultanément dans la table source et dans chaque requête consommatrice constitue une migration de schéma. Le même renommage exécuté uniquement dans la table source, laissant les utilisateurs lire des noms de colonnes obsolètes, constitue une dérive de schéma.
Les pipelines de données reposent sur un contrat de confiance entre le système source et l'entrepôt de données de destination. Ce contrat constitue le schéma : la structure, les types de données et les noms de colonnes convenus qui définissent l'ensemble de données. Lorsque les équipes en amont modifient la base de données de leur application sans en informer l'équipe de données, ce contrat est rompu.
La dérive de schéma est différente de la dérive de données. La dérive de données correspond à une modification de la distribution statistique des valeurs au sein d'un schéma stable : baisse des valeurs moyennes, augmentation du taux de valeurs nulles, décalage des distributions catégorielles. Ces deux phénomènes constituent des signaux importants de la qualité des données, mais nécessitent des approches de détection différentes et révèlent des causes profondes distinctes. Un système de détection des modifications de schéma qui surveille les noms et les types de colonnes ne détectera pas la dérive de données ; un système de surveillance de la distribution ne détectera pas les ajouts et les suppressions de colonnes.
La dérive de schéma n'est pas toujours nuisible. Le suivi de son évolution au fil du temps permet de distinguer les phases de développement actives (dérive bénigne) des périodes d'instabilité (dérive critique). L'ajout rétrocompatible d'une colonne autorisant les valeurs NULL à une table constitue une dérive de schéma : le schéma a été modifié, mais cela ne devrait pas impacter les applications qui ignorent cette nouvelle colonne. Pour classer une dérive comme bénigne ou critique, il est essentiel de comprendre les applications en aval et leur comportement face à ce changement.
Les quatre types de dérive de schéma
Les systèmes de données distribués produisent une dérive de schéma selon quatre dimensions distinctes, chacune nécessitant des mécanismes de détection différents :
Type 1 : Dérive structurale
Modifications apportées à la définition du schéma physique : ajouts, suppressions et renommages de colonnes, changements de types de données, ajouts ou suppressions de contraintes, ajouts et suppressions de tables. Il s’agit de la forme la plus visible de dérive de schéma et celle le plus souvent prise en charge par les outils d’observabilité. Les requêtes INFORMATION_SCHEMA de la base de données, les comparaisons du registre de schémas et les journaux d’audit des outils de migration permettent de détecter efficacement les dérives structurelles des systèmes connectés.
Détection : comparaison d’un instantané de schéma avec une référence ; interrogation de INFORMATION_SCHEMA ; comparaison de la version du registre de schémas.
Type 2 : Dérive sémantique
Modifications apportées à la signification d'un champ existant sans modifier sa définition. Une colonne nommée
statusqui contenaient auparavant des valeursACTIVE,INACTIVE,PENDINGcontient maintenant des valeurs1,2,3Le service producteur a modifié son énumération. Le schéma, le nom de colonne, le type de données et la contrainte de nullité restent inchangés. Le contrat sémantique est rompu. Les consommateurs qui analysaient des valeurs d'état sous forme de chaîne reçoivent désormais des entiers qu'ils ne peuvent pas gérer.La dérive sémantique et la dérive contextuelle sont des sujets relativement récents et beaucoup moins surveillés, bien qu'elles soient toutes deux responsables d'une part croissante des défaillances des programmes d'IA. La dérive sémantique est la plus difficile à détecter automatiquement car elle ne produit aucun signal structurel ; elle nécessite soit une surveillance de la distribution des valeurs (l'évolution du rapport entre les valeurs connues et les valeurs inconnues), soit des tests de contrat explicites.
Détection : surveillance de la distribution des valeurs ; règles de validation des valeurs autorisées ; tests de contrat qui vérifient des valeurs valides spécifiques.
Type 3 : Dérive de format
Modifications apportées à l'encodage ou au format des valeurs dans des champs dont la structure est inchangée. Un champ d'horodatage qui contenait auparavant des chaînes UTC ISO 8601 contient désormais des entiers Unix. Un champ de devise qui contenait auparavant des montants décimaux contient désormais des montants en centimes sous forme d'entiers. La colonne existe, le type reste valide pour les nouvelles valeurs, mais la convention d'analyse a changé.
La dérive de format est particulièrement fréquente aux limites des systèmes distribués, où un service sérialise des données dans un format qu'un autre désérialise, et à la frontière entre les systèmes anciens et modernes, où les programmes COBOL écrivent des fichiers plats avec des conventions de position d'octets spécifiques dont dépendent les processus ETL en aval.
Détection : profilage statistique des plages de valeurs et des modèles ; règles de validation de format sur des champs spécifiques ; tests de contrat limite.
Type 4 : Dérive contractuelle
Modifications des garanties de disponibilité, de fraîcheur ou de volume d'une source de données. Auparavant, le système source fournissait un jeu de données quotidiennement avant 3 h UTC ; désormais, il le fournit avant 6 h, ce qui perturbe silencieusement les processus en aval qui supposaient une fraîcheur des données à 3 h. Le système source garantissait auparavant un minimum de 1 000 enregistrements par jour ; les périodes de faible activité produisent désormais moins d'enregistrements. Aucune de ces modifications ne constitue un changement de schéma au sens structurel du terme, mais toutes deux rompent le contrat entre le producteur et le consommateur.
Détection : surveillance de la fraîcheur ; détection des anomalies de volume ; alertes basées sur les SLA.
Pourquoi les systèmes distribués amplifient le problème
Dans un système monolithique avec une seule base de données et une seule équipe applicative, les modifications de schéma sont des événements contrôlés. L'administrateur de base de données rédige la migration, le développeur met à jour les requêtes, et la modification est déployée simultanément. Le risque de dérive de schéma existe, mais il est limité par le périmètre d'action de cette autorité unique.
Les systèmes distribués suppriment cette autorité unique. Chaque service est propriétaire de ses données. Chaque équipe prend des décisions concernant le schéma de manière indépendante. Les utilisateurs des données de chaque service sont souvent hors de la portée immédiate de cette équipe, notamment lorsqu'il s'agit d'une plateforme de données, d'un pipeline analytique ou d'un point d'intégration existant non maintenu par une équipe produit.
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) │
└──────────────────┘Le diagramme illustre le schéma de propagation : l’équipe du service des commandes ajoute coupon_id à leur base de données. S'ils mettent également à jour le schéma d'événements Kafka pour inclure coupon_idLe pipeline analytique doit être mis à jour pour prendre en compte ces données. Si le schéma Kafka est toujours en version 1, le champ n'atteint jamais le pipeline. Si le pipeline est mis à jour mais que le modèle du tableau de bord BI n'est pas actualisé, le champ existe dans l'entrepôt de données mais est absent du rapport. Ce décalage peut entraîner une perte de données silencieuse à quatre points d'entrée différents, chacun nécessitant un mécanisme de détection spécifique.
Les défaillances silencieuses des pipelines, les tableaux de bord obsolètes, les dérives de schéma et les jeux de données incomplets constituent des risques opérationnels majeurs dans les environnements de données d'entreprise modernes. Les architectures de données modernes tombent en panne plus rapidement que les environnements traditionnels : les transformations défaillantes, les problèmes de fraîcheur des données et la corruption silencieuse des données se propagent le long des pipelines bien avant que les équipes ne détectent manuellement les problèmes.
C’est le caractère « silencieux » de la dérive des schémas distribués qui la rend coûteuse. Une erreur provoquant une exception est détectée et corrigée. En revanche, une modification générant des valeurs erronées de manière silencieuse passe inaperçue jusqu’à ce qu’une décision métier basée sur ces valeurs ait des conséquences visibles.
Approches de détection par couche
La détection des dérives de schéma nécessite des outils et des techniques différents pour chaque couche d'un système distribué :
Couche de base de données et d'entrepôt de données
La couche de détection la plus aboutie. Les tables INFORMATION_SCHEMA de toutes les principales bases de données et entrepôts de données fournissent un instantané de métadonnées interrogeable :
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;Outils qui automatisent ce modèle : tests de schéma dbt, attentes de colonnes Great Expectations, surveillance de l’état des tables Monte Carlo, surveillance des dérives de schéma Acceldata.
Couche de flux d'événements
Les sujets Kafka utilisent des registres de schémas (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) pour gérer l'évolution des schémas Avro, Protobuf et JSON. Le registre applique des règles de compatibilité lors de la publication.
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_elseLe registre de schémas ne prévient pas les dérives sémantiques : un champ dont le nom et le type restent inchangés mais dont la signification a évolué passe les tests de compatibilité. Des tests de contrat (Pact, tests AsyncAPI) sont nécessaires pour la validation sémantique.
Couche API
Il existe quatre approches fondamentalement différentes pour détecter les dérives de schéma d'API : la comparaison des spécifications, la surveillance des écarts entre les spécifications et la réalité, la surveillance des écarts entre les applications réelles et la détection basée sur le trafic. La plupart des confusions dans ce domaine proviennent de la comparaison d'outils selon différentes approches.
Pour les API de services internes dans une architecture de microservices, les tests de contrats pilotés par le consommateur (Pact) constituent l'approche la plus fiable : chaque consommateur spécifie le contrat dont il a besoin du producteur, les contrats sont vérifiés par rapport à l'implémentation du producteur dans l'intégration continue, et toute modification qui enfreint le contrat d'un consommateur fait échouer la suite de tests du producteur avant le déploiement.
La limite du système hérité : là où la dérive devient invisible
Chaque méthode de détection décrite ci-dessus fonctionne pour les systèmes qui exposent des métadonnées de schéma via des interfaces interrogeables : INFORMATION_SCHEMA, registres de schémas, spécifications OpenAPI. À la frontière entre les systèmes mainframe traditionnels et les plateformes de données modernes, ces interfaces n’existent pas.
Un programme COBOL qui génère chaque nuit un fichier plat destiné à être utilisé par un pipeline ETL cloud définit un schéma implicite dans sa logique d'entrée et de sortie des descripteurs de fichiers. Le « schéma » du fichier plat (positions des octets, types de données, champs décimaux compactés COMP-3 et structures REDEFINES) réside dans le code source COBOL et non dans un registre ou un magasin de métadonnées interrogeable par les outils d'observabilité modernes.
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
Si l'équipe COBOL change CUST-BALANCE à partir de PIC S9(11)V99 COMP-3 à PIC S9(13)V99 COMP-3Pour gérer des valeurs de solde plus élevées, la précision est augmentée de deux chiffres, ce qui fait passer le champ de 7 à 8 octets au format décimal compressé. Chaque champ après l'octet 50 est décalé d'une position. Dans le fichier plat lu par le pipeline ETL, tous les champs après CUST-BALANCE sont désormais mal positionnés. Le pipeline ETL ne génère pas d'erreur ; il lit les octets 51 à 57 comme CUST-BALANCE et interprète l'octet suivant (qui est maintenant le premier octet de la représentation étendue de CUST-BALANCE) comme faisant partie de CUST-STATUS-CD. Le pipeline s'exécute. Les valeurs sont incorrectes. Aucune alerte de dérive de schéma n'est déclenchée.
Il s'agit de la catégorie la plus dangereuse de dérive de schéma dans les environnements d'entreprise : les modifications structurelles des systèmes existants qui se propagent silencieusement via les interfaces de fichiers plats sans aucun mécanisme de détection à aucune des extrémités.
Trois caractéristiques rendent la dérive des limites de propriété particulièrement dangereuse :
Le schéma est invisible pour les outils d'observabilité. Monte Carlo ne peut pas se connecter à un fichier VSAM. Acceldata ne peut pas interroger une entrée FD. La seule façon de détecter la modification est de comparer le code source COBOL avec une version précédente ; il s'agit d'une analyse de code, et non d'une surveillance des données.
La propagation est silencieuse. Les interfaces de fichiers plats ne valident pas la structure des enregistrements ; elles lisent les octets. Une modification de la disposition des octets produit des valeurs incorrectes, et non des erreurs.
La zone d'impact est étendue. Un copybook COBOL inclus par 300 programmes constitue un schéma partagé par ces 300 programmes. Toute modification apportée à ce copybook, équivalente à une instruction DDL ALTER TABLE, affecte simultanément les 300 programmes, et chaque application utilisant en aval un jeu de données produit par l'un d'eux subit les conséquences de cette modification.
Contrats schématiques : formaliser ce qui est généralement implicite
La solution structurelle à la dérive des schémas consiste à expliciter les contrats implicites, à définir ce qu'est le schéma, qui en dépend et quelles modifications sont autorisées, avant qu'une modification ne soit apportée plutôt qu'après qu'elle ait causé des problèmes.
| Couche contractuelle | Ce qu'il régit | Outils | Équivalent hérité |
|---|---|---|---|
| DDL de base de données | Structure du tableau, types de colonnes, contraintes | Liquibase, voie de migration, Atlas | Scripts de migration DB2 DDL |
| Schéma d'événement | Structure du flux Kafka/événements | Registre de schémas confluents, Apicurio | N/A (le fichier plat ne contient pas de registre) |
| contrat API | attentes concernant l'interface REST/gRPC | OpenAPI, Pact, API asynchrone | N/A (l'interface de fichiers n'a pas de spécification) |
| Qualité des données | Répartition des valeurs, fraîcheur, volume | Grandes Espérances, tests de dbt | Non applicable (pas de framework de test natif) |
| contrat de format de fichier | Disposition des octets dans un fichier plat, positions des champs | Entrée COBOL FD (source de vérité) | Contrôle de version du cahier d'exercices |
L'entrée « Contrôle de version du copybook » dans la colonne équivalente héritée est le mécanisme pratique de gestion de l'évolution du schéma COBOL : traiter le copybook comme un artefact versionné avec un processus d'approbation des modifications, tenir un registre des programmes qui incluent chaque copybook et exiger une analyse d'impact avant que toute modification du copybook ne soit approuvée.
Un flux de travail d'approbation des modifications de manuels scolaires :
- Le développeur propose une modification de
CUSTMSTR.CPY - L'analyse d'impact identifie tous les programmes qui incluent
CUSTMSTR.CPY(analyse statique) - Chaque fichier plat produit par ces programmes est identifié comme un événement de modification de schéma
- Chaque consommateur en aval de ces fichiers plats est notifié
- Des tests de validation auprès des consommateurs sont effectués sur la nouvelle mise en page.
- La modification n'est approuvée que lorsque tous les consommateurs confirment sa compatibilité.
Ce flux de travail reflète le modèle d'application de la compatibilité du registre de schémas, appliqué à la couche COBOL où il n'existe pas de registre de schémas natif.
Architecture de surveillance de la dérive de schéma distribuée
Une architecture complète de surveillance des dérives de schéma couvre les quatre types de dérives sur l'ensemble des couches du système :
Base de données d'instantanés de schéma. Stockez un instantané quotidien des métadonnées INFORMATION_SCHEMA de chaque table, de chaque version de schéma d'événement enregistrée, de chaque version de spécification d'API et (pour les systèmes existants) de chaque version de copybook. Cette base de données d'instantanés sert de référence pour la comparaison avec l'état actuel.
Pipeline de détection des modifications. Des tâches de comparaison quotidiennes sont exécutées sur la base de données instantanée afin de détecter les ajouts, les suppressions, les changements de type et les modifications de contraintes à chaque niveau surveillé. Les modifications critiques (changements de type non rétrocompatibles, suppressions de colonnes, ajouts de champs obligatoires) déclenchent des alertes immédiates. Les modifications mineures (ajouts de colonnes autorisant les valeurs nulles, modifications d'index) génèrent des notifications d'avertissement.
Registre d'impact sur les consommateurs. Ce catalogue associe chaque artefact de schéma à ses consommateurs connus : quels pipelines lisent quelles tables, quels services consomment quels sujets Kafka, quels traitements ETL traitent quels fichiers plats. Lorsqu'une modification de schéma est détectée, le registre d'impact sur les consommateurs détermine l'étendue de l'impact, le nombre de consommateurs affectés et les plus critiques.
Suite de tests de contrats. Tests automatisés vérifiant les hypothèses des consommateurs concernant les schémas des producteurs. Exécutés à chaque déploiement interagissant avec un service de production de données. Le déploiement échoue en cas de violation d'un contrat dont dépend un consommateur enregistré.
Surveillance des limites héritées. Pour les systèmes mainframe : comparaison des copybooks versionnés, surveillance des définitions de jeux de données JCL et validation du format des fichiers plats par rapport au schéma défini dans l’entrée FD du programme producteur. Cette couche nécessite une analyse du code plutôt qu’une surveillance des données, afin de détecter les modifications du code source COBOL qui constituent des changements de schéma pour les consommateurs en aval.
La surveillance planifiée est plus importante que beaucoup d'équipes ne le pensent. Les recommandations d'Acceldata concernant l'analyse des dérives planifiées préconisent des comparaisons automatisées avec une base de référence stable, à une fréquence hebdomadaire ou bihebdomadaire, et précisent qu'attendre des vérifications ponctuelles après une défaillance est insuffisant. Pour la surveillance des limites des systèmes existants, la fréquence doit correspondre au calendrier de déploiement COBOL : toute mise en production d'un copybook doit déclencher une analyse d'impact immédiate sur le schéma, sans attendre la prochaine comparaison planifiée.
Comment SMART TS XL Résout le problème de la dérive des schémas dans les environnements existants
SMART TS XL comble le manque de détection à la limite des systèmes existants, la couche où s'arrêtent les outils d'observabilité modernes et où les dérives de schéma les plus dangereuses passent inaperçues.
La fonctionnalité d'analyse statique du code analyse chaque entrée de descripteur de fichier COBOL, chaque membre COPY et chaque clause SELECT afin de produire une représentation structurée de chaque artefact de schéma dans l'environnement existant. Lorsque cette analyse est exécutée sur deux versions du code source, avant et après un déploiement, les différences constituent l'historique des modifications du schéma existant : quels copybooks ont été modifiés, quelles définitions de champs ont été modifiées et quelles étaient les structures avant et après. Il s'agit de la comparaison d'instantanés de schéma appliquée à la couche COBOL.
Le mappage des dépendances applicatives fournit le registre d'impact sur les consommateurs pour les schémas hérités : quels programmes incluent chaque copybook, quels programmes produisent quels fichiers plats, quels travaux JCL appellent quels programmes. Lorsqu'un copybook modifié est identifié dans le journal des modifications de schéma, le mappage des dépendances génère immédiatement la liste des consommateurs, c'est-à-dire tous les programmes qui incluent le copybook et tous les fichiers plats produits par ces programmes. Ce calcul de la zone d'impact permet de déterminer si une modification de copybook représente une modification interne à faible risque ou un événement à haut risque affectant des centaines de programmes et des dizaines de consommateurs en aval.
La fonctionnalité d'analyse d'impact transforme le périmètre d'impact en un plan de remédiation structuré : pour chaque consommateur identifié par la cartographie des dépendances, quelles modifications sont nécessaires pour intégrer le nouveau schéma, et dans quel ordre doivent-elles être appliquées ? Pour les consommateurs de la frontière entre systèmes existants et modernes, tels que les pipelines ETL qui lisent des fichiers plats produits par des programmes COBOL, l'analyse d'impact identifie les modifications spécifiques de position des champs et de type de données que la configuration de mappage des colonnes du pipeline ETL doit prendre en compte.
La fonctionnalité de recherche d'entreprise permet d'interroger les artefacts de schéma : elle permet de trouver tous les programmes qui lisent un champ à une position d'octet spécifique (identifiant ainsi les consommateurs qui seront affectés par une modification de la mise en page), tous les copybooks qui définissent un champ spécifique (identifiant ainsi l'artefact de schéma qui doit être versionné et soumis à un contrôle des modifications), et tous les programmes qui produisent des données dans un ensemble de données spécifique (identifiant ainsi les producteurs dont les modifications de schéma doivent déclencher des notifications pour les consommateurs). Cette fonctionnalité de recherche prend en charge à la fois le flux de travail proactif de gouvernance des schémas et l'investigation des incidents après une dérive.
Pour les organisations gérant modernisation de l'héritage programmes qui comprennent la migration des données des ordinateurs centraux vers des plateformes modernes, SMART TS XLL'analyse de schéma de fournit la documentation du schéma source requise par les outils de migration, les définitions complètes et actuelles des entrées FD et les structures de copybook qui définissent ce que sont réellement les données, et non seulement ce qu'elles étaient lors de la rédaction de la spécification de migration originale.
Un contrat non rédigé reste un contrat
La dérive de schéma dans les systèmes distribués n'est pas un problème nouveau. C'est un problème ancien que l'architecture distribuée rend plus difficile à résoudre, car l'autorité qui assurait le respect des contrats de schéma dans les systèmes monolithiques (l'administrateur de base de données central, l'équipe applicative unique, le code source unifié) a été répartie entre des dizaines de services indépendants, chacun prenant des décisions pertinentes individuellement avec une visibilité incomplète sur tous les consommateurs en aval.
La solution ne consiste pas à recentraliser l'autorité sur les schémas. Il s'agit plutôt de rendre explicites les contrats implicites, de les enregistrer dans des systèmes capables de comparer l'état actuel à une configuration de référence, d'appliquer des règles de compatibilité aux limites où des modifications sont introduites et de surveiller les violations aux limites où les modifications se propagent. Pour les systèmes modernes, les outils nécessaires existent et s'améliorent rapidement. En revanche, pour les systèmes existants à l'interface avec les plateformes modernes, le manque d'outils est réel et a des conséquences importantes : le format de fichier plat qui constitue un contrat de schéma pour un pipeline ETL cloud est invisible pour tous les outils d'observabilité modernes, à moins que le code source COBOL qui le définit ne soit analysé et versionné comme un artefact de schéma.
Le tableau de bord affichant une baisse de 23 % des acquisitions de clients n'était pas erroné quant aux données reçues. Son interprétation était erronée, car le schéma définissant ces données avait été modifié à un endroit où aucun contrat n'était enregistré et où aucun système de surveillance n'était en place. C'est à cet endroit précis, quel que soit son emplacement dans un système distribué, ancien ou moderne, que les programmes de détection des dérives de schéma doivent intervenir.
