Detección de desviaciones de esquema en sistemas de datos distribuidos

El panel de análisis era correcto el martes. Para el jueves mostraba una caída del 23 por ciento en la adquisición de clientes que el equipo comercial estaba tratando como una señal comercial genuina, reorganizando los presupuestos de marketing, pausando campañas, escalando a la junta. El equipo de ingeniería de datos descubrió el viernes que el servicio ascendente había agregado una columna anulable a la registrations Tabla seis días antes. La canalización ETL no se había actualizado. El cálculo que derivaba la métrica de adquisición trataba los nuevos valores nulos como ceros en lugar de excluirlos. No se había enviado ninguna notificación de cambio de esquema. No se había incumplido ningún contrato de forma que produjera un error. La canalización se ejecutó correctamente; produjo números erróneos que parecían correctos.

La deriva de esquema representa una mutación estructural; a diferencia de los problemas de calidad de datos, donde los valores son incorrectos, la deriva de esquema rompe el contrato entre el origen y el destino. En un entorno de base de datos monolítica con un administrador de base de datos central que controla todo el DDL, ese contrato es aplicado por una única autoridad. En un sistema distribuido, donde docenas de servicios independientes poseen cada uno su propio almacén de datos, donde los flujos de eventos transportan esquemas Avro que evolucionan de forma independiente, donde las interfaces de archivos planos entre los trabajos por lotes del mainframe y las plataformas de análisis en la nube definen contratos implícitos que no existen en la documentación de ninguno de los sistemas, el contrato se distribuye a través de cada límite del sistema. La deriva de esquema en un entorno distribuido no espera a que un administrador de base de datos cometa un error. Surge del funcionamiento normal de equipos autónomos que toman decisiones individualmente sensatas sin una visibilidad completa de cada consumidor posterior de sus datos.

Qué es la deriva de esquemas y qué no lo es.

La deriva de esquema es un cambio en la estructura de un artefacto de datos que no se refleja en los consumidores de dicho artefacto. El énfasis en los consumidores es lo que distingue la deriva de la migración planificada: un cambio de nombre de columna ejecutado simultáneamente en la tabla de origen y en cada consulta consumidora constituye una migración de esquema. El mismo cambio de nombre ejecutado solo en la tabla de origen, lo que provoca que los consumidores lean nombres de columna obsoletos, constituye una deriva de esquema.

Las canalizaciones de datos se basan en un contrato de confianza entre el sistema de origen y el almacén de datos de destino. Este contrato es el esquema: la estructura, los tipos de datos y los nombres de columna acordados que definen el conjunto de datos. Cuando los equipos de origen modifican la base de datos de su aplicación sin notificar al equipo de datos, incumplen este contrato.

La deriva de esquema no es lo mismo que la deriva de datos. La deriva de datos es un cambio en la distribución estadística de valores dentro de un esquema estable: disminución de los valores promedio ordenados, aumento de las tasas nulas y cambios en las distribuciones categóricas. Ambas son señales importantes de calidad de datos, pero requieren enfoques de detección diferentes e indican causas raíz distintas. Un sistema de detección de cambios de esquema que monitorea los nombres y tipos de columnas no detectará la deriva de datos; un sistema de monitoreo de distribución no detectará las adiciones ni las eliminaciones de columnas.

La desviación del esquema no siempre es perjudicial. El seguimiento de la gravedad de la desviación a lo largo del tiempo ayuda a distinguir entre ciclos de desarrollo activos (desviación benigna) e inestabilidad (desviación crítica). La adición retrocompatible de una columna que admite valores nulos a una tabla constituye una desviación del esquema; el esquema cambia, pero puede que no afecte a ningún usuario que ignore la nueva columna. La clasificación de la desviación como benigna o crítica requiere comprender a los usuarios posteriores y cómo gestionan el cambio.

Los cuatro tipos de deriva de esquemas

Los sistemas de datos distribuidos producen desviaciones de esquema a lo largo de cuatro dimensiones distintas, cada una de las cuales requiere diferentes mecanismos de detección:

Tipo 1: Deriva estructural

Cambios en la definición del esquema físico: adición, eliminación y cambio de nombre de columnas, modificación de tipos de datos, adición o eliminación de restricciones, y adición o eliminación de tablas. Esta es la forma más visible de desviación del esquema y la que suelen abordar las herramientas de observabilidad. Las consultas INFORMATION_SCHEMA de la base de datos, las comparaciones del registro de esquemas y los registros de auditoría de las herramientas de migración capturan eficazmente la desviación estructural en sistemas conectados.

Detección: Comparación de instantáneas del esquema con una línea base; sondeo de INFORMATION_SCHEMA; comparación de versiones del registro de esquemas.

Tipo 2: Desviación semántica

Cambios en el significado de un campo existente sin cambios en su definición. Una columna llamada status que previamente contenían valores ACTIVE, INACTIVE, PENDING ahora contiene valores 1, 2, 3 Debido a que el servicio productor modificó su enumeración, el esquema, el nombre de la columna, el tipo de datos y la restricción de valores nulos permanecen sin cambios. El contrato semántico se ha roto. Los consumidores que analizaban valores de estado de tipo cadena ahora reciben números enteros que su lógica no puede procesar.

La deriva semántica y la deriva contextual son conceptos relativamente nuevos y mucho menos monitoreados, a pesar de que ambos son responsables de una proporción cada vez mayor de fallos en los programas de IA. La deriva semántica es la más difícil de detectar automáticamente porque no produce ninguna señal estructural; requiere el monitoreo de la distribución de valores (cambios en la proporción de valores conocidos a desconocidos) o pruebas de contrato explícitas.

Detección: Monitorización de la distribución de valores; reglas de validación de valores permitidos; pruebas de contrato que verifican valores válidos específicos.

Tipo 3: Desviación de formato

Cambios en la codificación o el formato de los valores dentro de campos que no han sufrido cambios estructurales. Un campo de marca de tiempo que antes contenía cadenas UTC ISO 8601 ahora contiene enteros de época Unix. Un campo de moneda que antes contenía cantidades decimales ahora contiene cantidades en centavos como enteros. La columna existe, el tipo sigue siendo válido para los nuevos valores, pero la convención de análisis ha cambiado.

La desviación de formato es particularmente común en los límites de los sistemas distribuidos, donde un servicio serializa datos en un formato que otro deserializa, y en el límite entre sistemas heredados y modernos, donde los programas COBOL escriben archivos planos con convenciones específicas de posición de bytes de las que dependen los procesos ETL posteriores.

Detección: Análisis estadístico de rangos y patrones de valores; reglas de validación de formato en campos específicos; pruebas de límites contractuales.

Tipo 4: Desviación del contrato

Cambios en las garantías de disponibilidad, actualidad o volumen de una fuente de datos. El sistema de origen entregaba un conjunto de datos diariamente a las 3:00 a. m. UTC; ahora lo entrega a las 6:00 a. m., interrumpiendo silenciosamente los procesos posteriores que asumían la actualidad a las 3:00 a. m. El sistema de origen garantizaba un mínimo de 1,000 registros por día; ahora, en períodos de bajo tráfico, se registran menos. Ninguno de estos cambios constituye una modificación del esquema en el sentido estructural, pero ambos incumplen el contrato entre productor y consumidor.

Detección: Monitorización de la frescura; detección de anomalías de volumen; alertas basadas en acuerdos de nivel de servicio (SLA).

Por qué los sistemas distribuidos amplifican el problema

En un sistema monolítico con una única base de datos y un único equipo de desarrollo de aplicaciones, los cambios de esquema son eventos controlados. El administrador de la base de datos (DBA) escribe la migración, el desarrollador actualiza las consultas y el cambio se implementa de forma conjunta. Existe el riesgo de que el esquema se desvíe, pero está limitado por el ámbito de la autoridad centralizada.

Los sistemas distribuidos eliminan esa autoridad centralizada. Cada servicio es propietario de sus datos. Cada equipo toma decisiones sobre el esquema de forma independiente. Los usuarios de los datos de cada servicio suelen estar fuera del alcance inmediato del equipo, especialmente cuando se trata de una plataforma de datos, un sistema de análisis o un punto de integración heredado que ningún equipo de producto mantiene activamente.

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) │
                └──────────────────┘

El diagrama ilustra el patrón de propagación: el equipo de Servicio de Pedidos agrega coupon_id a su base de datos. Si también actualizan el esquema de eventos de Kafka para incluir coupon_idPara procesar los datos, es necesario actualizar el flujo de análisis. Si el esquema de Kafka aún está en la versión 1, el campo nunca llega al flujo. Si se actualiza el flujo, pero no se actualiza el modelo del panel de BI, el campo existe en el almacén de datos, pero no aparece en el informe. Esta desviación puede provocar una pérdida silenciosa de datos en cualquiera de los cuatro límites, y cada límite requiere un mecanismo de detección diferente.

Los fallos silenciosos en las canalizaciones, los paneles de control obsoletos, la desviación de esquemas y los conjuntos de datos incompletos se han convertido en riesgos operativos importantes en los entornos de datos empresariales modernos. Las pilas de datos modernas fallan más rápidamente que los entornos tradicionales, con transformaciones defectuosas, fallos de actualización y corrupción silenciosa de datos que se propagan a través de las canalizaciones mucho antes de que los equipos detecten los problemas manualmente.

La propiedad de "silencioso" es lo que encarece la desviación del esquema distribuido. Un error que produce una excepción se detecta y se corrige. Un cambio que produce cifras erróneas de forma silenciosa pasa desapercibido hasta que una decisión empresarial basada en esas cifras produce una consecuencia visible.

Enfoques de detección por capa

La detección de desviaciones de esquema requiere diferentes herramientas y técnicas para cada capa de un sistema distribuido:

Capa de base de datos y almacén de datos

La capa de detección más avanzada. Las tablas INFORMATION_SCHEMA en todas las bases de datos y almacenes de datos principales proporcionan una instantánea de metadatos consultable:

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;

Herramientas que automatizan este patrón: pruebas de esquema dbt, expectativas de columna de Great Expectations, monitoreo del estado de las tablas mediante Monte Carlo, monitoreo de la deriva del esquema de Acceldata.

Capa de transmisión de eventos

Los temas de Kafka utilizan registros de esquemas (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) para gestionar la evolución de los esquemas Avro, Protobuf y JSON. El registro aplica reglas de compatibilidad en el momento de la publicació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_else

El registro de esquemas no impide la deriva semántica; un campo cuyo nombre y tipo permanecen inalterados, pero cuyo significado ha cambiado, supera las comprobaciones de compatibilidad. Se requieren pruebas de contrato (Pact, pruebas de AsyncAPI) para la validación semántica.

Capa API

Existen cuatro enfoques fundamentalmente diferentes para detectar desviaciones en los esquemas de las API: comparación de especificaciones, monitorización de especificaciones a la realidad, monitorización de la realidad a la realidad y detección basada en el tráfico. La mayor parte de la confusión en este ámbito proviene de la comparación de herramientas que utilizan diferentes enfoques.

Para las API de servicios internos en una arquitectura de microservicios, las pruebas de contrato impulsadas por el consumidor (Pact) son el enfoque más fiable: cada consumidor especifica el contrato que requiere del productor, los contratos se verifican con la implementación del productor en la integración continua (CI), y cualquier cambio que infrinja el contrato de un consumidor hace que el conjunto de pruebas del productor falle antes del despliegue.

El límite del sistema heredado: donde la deriva se vuelve invisible.

Todos los métodos de detección descritos anteriormente funcionan para sistemas que exponen metadatos de esquema a través de interfaces consultables: INFORMATION_SCHEMA, registros de esquemas, especificaciones OpenAPI. En la frontera entre los sistemas mainframe heredados y las plataformas de datos modernas, estas interfaces no existen.

Un programa COBOL que genera un archivo plano diario para su procesamiento por una canalización ETL en la nube define un esquema implícito en la lógica de entrada y salida de su archivo plano. El "esquema" del archivo plano, que incluye las posiciones de bytes, los tipos de datos, los campos decimales empaquetados COMP-3 y las estructuras REDEFINES, reside en el código fuente COBOL, no en ningún registro o almacén de metadatos que las herramientas de observabilidad modernas puedan consultar.

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 el equipo de COBOL cambia CUST-BALANCE desde PIC S9(11)V99 COMP-3 a PIC S9(13)V99 COMP-3Al agregar dos dígitos de precisión para manejar valores de saldo mayores, el campo se expande de 7 bytes a 8 bytes en formato decimal empaquetado. Cada campo después del byte 50 se desplaza una posición. El archivo plano que lee la canalización ETL ahora tiene todos los campos después de CUST-BALANCE en posiciones de byte incorrectas. La canalización ETL no produce un error; lee los bytes 51-57 como CUST-BALANCE e interpreta el siguiente byte (que ahora es el primer byte de la representación expandida de CUST-BALANCE) como parte de CUST-STATUS-CD. La canalización se ejecuta. Los números son incorrectos. No se activa ninguna alerta de desviación de esquema.

Este es el tipo de cambio de esquema más peligroso en entornos empresariales: cambios estructurales en sistemas heredados que se propagan silenciosamente a través de interfaces de archivos planos sin ningún mecanismo de detección en ninguno de los extremos.

Tres propiedades hacen que la deriva de los límites heredados sea particularmente peligrosa:

El esquema es invisible para las herramientas de observabilidad. Monte Carlo no puede conectarse a un archivo VSAM. Acceldata no puede consultar una entrada FD. La única forma de detectar el cambio es comparar el código fuente COBOL con una versión anterior, una operación de análisis de código, no de monitorización de datos.

La propagación es silenciosa. Las interfaces de archivos planos no validan la estructura de los registros; leen bytes. Un cambio en la disposición de los bytes produce valores erróneos, no errores.

El radio de impacto es amplio. Un archivo de copia COBOL incluido por 300 programas es un esquema compartido por esos 300 programas. Un cambio en dicho archivo, equivalente a una instrucción DDL ALTER TABLE, afecta a los 300 programas simultáneamente, y cualquier programa que utilice un conjunto de datos generado por cualquiera de ellos hereda la modificación.

Contratos de esquema: Formalizando lo que normalmente es implícito

La solución estructural a la deriva de esquemas consiste en hacer explícitos los contratos implícitos, definiendo qué es el esquema, quién depende de él y qué cambios están permitidos, antes de que se realice un cambio, en lugar de después de que este cause algún problema.

Capa contractual	Lo que rige	Accesorios	Equivalente del legado
DDL de base de datos	Estructura de la tabla, tipos de columnas, restricciones	Liquibase, Flyway, Atlas	Scripts de migración DDL de DB2
Esquema de evento	Estructura de flujo de eventos/Kafka	Registro de esquemas confluentes, Apicurio	N/A (el archivo plano no tiene registro)
Contrato API	Expectativas de la interfaz REST/gRPC	OpenAPI, Pact, AsyncAPI	N/A (la interfaz de archivos no tiene especificaciones)
Calidad de datos	Distribuciones de valor, frescura, volumen	Grandes expectativas, pruebas dbt	N/A (no hay marco de pruebas nativo)
Contrato de formato de archivo	Diseño de bytes de archivo plano, posiciones de campo	Entrada COBOL FD (fuente de verdad)	Control de versiones de Copybook

La entrada "Control de versiones de Copybook" en la columna de equivalentes heredados es el mecanismo práctico para gestionar la evolución del esquema COBOL: tratar el copybook como un artefacto versionado con un proceso de aprobación de cambios, mantener un registro de qué programas incluyen cada copybook y exigir un análisis de impacto antes de que se apruebe cualquier modificación del copybook.

Flujo de trabajo para la aprobación de cambios en el manual de instrucciones:

1. El desarrollador propone un cambio en CUSTMSTR.CPY
2. El análisis de impacto identifica cada programa que incluye CUSTMSTR.CPY (análisis estático)
3. Cada archivo plano producido por esos programas se identifica como un evento de cambio de esquema.
4. Se notifica a todos los consumidores posteriores de esos archivos planos.
5. Se realizan pruebas de validación por parte del consumidor con el nuevo diseño.
6. El cambio se aprueba solo cuando todos los consumidores confirman la compatibilidad.

Este flujo de trabajo refleja el patrón de aplicación de compatibilidad del registro de esquemas, aplicado a la capa COBOL donde no existe un registro de esquemas nativo.

Arquitectura de monitorización para la deriva de esquemas distribuidos

Una arquitectura completa de monitorización de la deriva del esquema abarca los cuatro tipos de deriva en todas las capas del sistema:

Base de datos de instantáneas de esquema. Almacena una instantánea diaria de los metadatos INFORMATION_SCHEMA de cada tabla, de cada versión del esquema de eventos registrados, de cada versión de la especificación de la API y (para sistemas heredados) de cada versión del copybook. La base de datos de instantáneas sirve como referencia para comparar el estado actual.

Canalización de detección de cambios. Se realizan comparaciones diarias contra la base de datos de instantáneas, detectando adiciones, eliminaciones, cambios de tipo y cambios de restricciones en cada capa monitorizada. Los cambios de alta gravedad, los cambios de tipo incompatibles con versiones anteriores, las eliminaciones de columnas y las adiciones de campos obligatorios activan alertas inmediatas. Los cambios de baja gravedad, las adiciones de columnas que admiten valores nulos y los cambios de índice generan notificaciones informativas.

Registro de impacto en el consumidor. Un catálogo que relaciona cada artefacto de esquema con sus consumidores conocidos: qué canalizaciones leen de qué tablas, qué servicios consumen qué temas de Kafka, qué trabajos ETL procesan qué archivos planos. Cuando se detecta un cambio de esquema, el registro de impacto en el consumidor determina el alcance del impacto, cuántos consumidores se ven afectados y cuáles son los más críticos.

Conjunto de pruebas de contratos. Pruebas automatizadas que verifican las suposiciones del consumidor sobre los esquemas del productor. Se ejecutan en cada despliegue que interactúa con un servicio de producción de datos. El despliegue falla si se incumple un contrato del que depende un consumidor registrado.

Supervisión de límites heredados. Para sistemas mainframe: comparación de copybooks con control de versiones, supervisión de la definición de conjuntos de datos JCL y validación del formato de archivo plano con respecto al esquema definido en la entrada FD del programa que lo produce. Esta capa requiere análisis de código en lugar de supervisión de datos, detectando cambios en el código fuente COBOL que constituyen cambios de esquema para los usuarios posteriores.

La monitorización programada es más importante de lo que muchos equipos creen. La guía de Acceldata sobre el análisis de desviaciones programadas recomienda comparaciones automatizadas con una línea base estable con una periodicidad semanal o quincenal, y señala explícitamente que esperar a realizar comprobaciones puntuales tras un fallo es insuficiente. En el caso específico de la monitorización de límites heredados, la periodicidad debe coincidir con el calendario de implementación de COBOL: cualquier lanzamiento de un copybook a producción debe activar un análisis de impacto de esquema inmediato, en lugar de esperar a la siguiente comparación programada.

Cómo SMART TS XL Soluciona la deriva de esquemas en entornos heredados.

SMART TS XL Aborda la brecha de detección en el límite del sistema heredado, la capa donde se detienen las herramientas de observabilidad modernas y donde la desviación de esquema más peligrosa pasa desapercibida.

La capacidad de análisis de código estático analiza cada entrada de definición de campo (FD) de COBOL, cada miembro de COPY y cada cláusula SELECT para generar una representación estructurada de cada artefacto de esquema en el entorno heredado. Al ejecutar este análisis en dos versiones del código fuente, antes y después de una implementación, las diferencias conforman el registro de cambios del esquema heredado: qué copybooks se modificaron, qué definiciones de campo cambiaron y cuáles eran las estructuras antes y después. Esta es la comparación de instantáneas de esquema aplicada a la capa COBOL.

El mapeo de dependencias de la aplicación proporciona el registro de impacto en el consumidor para esquemas heredados: qué programas incluyen cada copybook, qué programas producen qué conjuntos de datos de archivos planos y qué trabajos JCL invocan qué programas. Cuando el registro de cambios del esquema identifica un copybook modificado, el mapa de dependencias genera inmediatamente la lista de consumidores, todos los programas que incluyen el copybook y todos los archivos planos posteriores que producen dichos programas. Este es el cálculo del radio de impacto que determina si un cambio en un copybook es una modificación interna de bajo riesgo o un evento de alto riesgo que afecta a cientos de programas y decenas de consumidores posteriores.

La capacidad de análisis de impacto convierte el radio de impacto en un alcance de remediación estructurado: para cada consumidor identificado por el mapa de dependencias, ¿qué cambios se requieren para adaptarse al nuevo esquema y en qué secuencia deben aplicarse esos cambios? Para los consumidores de transición entre sistemas heredados y modernos, como las canalizaciones ETL que leen archivos planos generados por programas COBOL, el análisis de impacto identifica los cambios específicos en la posición de los campos y en el tipo de datos que deben actualizarse en la configuración de asignación de columnas de la canalización ETL.

La función de búsqueda empresarial permite consultar el descubrimiento de artefactos de esquema: encuentre todos los programas que leen un campo en una posición de byte específica (identificando los consumidores que se verán afectados por un cambio de diseño), todos los copybooks que definen un campo específico (identificando el artefacto de esquema que debe ser versionado y controlado por cambios), y todos los programas que generan salida a un conjunto de datos específico (identificando los productores cuyos cambios de esquema deben activar notificaciones para los consumidores). Esta función de búsqueda admite tanto el flujo de trabajo de gobernanza proactiva de esquemas como la investigación de incidentes posteriores a la desviación.

Para organizaciones que gestionan modernización heredada programas que incluyen la migración de datos de mainframe a plataformas modernas, SMART TS XLEl análisis del esquema proporciona la documentación del esquema de origen que requieren las herramientas de migración, las definiciones de entrada FD completas y actualizadas, y las estructuras de copia que definen lo que son realmente los datos, no solo lo que eran cuando se escribió la especificación de migración original.

El contrato que nadie redactó sigue siendo un contrato.

La deriva de esquemas en sistemas distribuidos no es un problema nuevo. Es un problema antiguo que la arquitectura distribuida dificulta su solución, porque la autoridad que hacía cumplir los contratos de esquema en los sistemas monolíticos (el administrador de bases de datos central, el único equipo de aplicación, el código base unificado) se ha distribuido entre docenas de servicios independientes, cada uno de los cuales toma decisiones individualmente sensatas con una visibilidad incompleta de cada consumidor final.

La solución no consiste en recentralizar la autoridad sobre el esquema, sino en explicitar los contratos implícitos, registrarlos en sistemas que puedan comparar el estado actual con la línea base, aplicar reglas de compatibilidad en los límites donde se introducen los cambios y supervisar las infracciones en los límites donde se propagan dichos cambios. Para los sistemas modernos, las herramientas necesarias existen y mejoran rápidamente. Para los sistemas heredados en la frontera con las plataformas modernas, la falta de herramientas es real y tiene consecuencias importantes; el formato de archivo plano que constituye un contrato de esquema para una canalización ETL en la nube resulta invisible para cualquier herramienta de observabilidad moderna, a menos que el código fuente COBOL que lo define se analice y versione como un artefacto de esquema.

El panel de control que mostraba una caída del 23 % en la captación de clientes no se equivocaba con los datos recibidos. Se equivocaba en su significado, porque el esquema que definía dicho significado había cambiado en un límite donde no había ningún contrato registrado ni ningún sistema de monitorización supervisando. Ese límite, dondequiera que exista en un sistema distribuido, ya sea antiguo o moderno, es donde deben llegar los programas de detección de desviaciones de esquema.