分散データシステムにおけるスキーマドリフトの検出

インコム 2026 年 10 月 27 日用途, コードレビュー, コンプライアンス, 企業の最新化, 影響分析, 情報技術, Tech Talk（テクニカルトーク）

火曜日の時点では、分析ダッシュボードは正しかった。木曜日には、顧客獲得が23%減少したことが示され、ビジネスチームはこれを真のビジネスシグナルとして扱い、マーケティング予算を再編成し、キャンペーンを一時停止し、取締役会に報告した。金曜日にデータエンジニアリングチームは、上流サービスがnull許容列を追加したことを発見した。 registrations 表は6日前に更新されていた。ETLパイプラインは更新されていなかった。取得指標を算出する計算式は、新しいnull値を除外するのではなく、ゼロとして扱っていた。スキーマ変更通知は送信されていなかった。エラーが発生するような契約違反も発生していなかった。パイプラインは正常に実行され、見た目は正しいものの、実際には誤った数値が生成された。

スキーマドリフトは構造的な変異であり、値が間違っているデータ品質の問題とは異なり、ソースとデスティネーション間の契約を破るものです。中央のDBAがすべてのDDLを制御するモノリシックデータベース環境では、その契約は単一の権限によって強制されます。しかし、数十の独立したサービスがそれぞれ独自のデータストアを所有し、イベントストリームが独立して進化するAvroスキーマを運び、メインフレームのバッチジョブとクラウド分析プラットフォーム間のフラットファイルインターフェースがどちらのシステムのドキュメントにも存在しない暗黙の契約を定義する分散システムでは、契約はシステム内のあらゆる境界に分散されます。分散環境におけるスキーマドリフトは、DBAがミスをするのを待つことはありません。それは、データの下流のすべての利用者を完全に把握することなく、個々に妥当な決定を下す自律的なチームの通常の運用から発生します。

レガシースキーマ境界をマッピングする

SMART TS XL メインフレームプログラムと最新の分析プラットフォームを接続するすべてのフラットファイルフォーマット契約を識別します。

さらに詳しく…

スキーマドリフトとは何か、そしてスキーマドリフトではないものとは何か

スキーマドリフトとは、データアーティファクトの構造変更が、そのアーティファクトを利用する側に反映されない状態を指します。ドリフトと計画的な移行を区別する重要な要素は、利用者の存在です。ソーステーブルとそれを利用するすべてのクエリで同時に実行される列名の変更は、スキーマ移行です。一方、ソーステーブルのみで同じ列名の変更が実行され、利用者が古い列名を読み取ってしまう場合は、スキーマドリフトとなります。

データパイプラインは、ソースシステムと宛先データウェアハウス間の信頼契約に基づいて構築されます。この契約とはスキーマ、つまりデータセットを定義する合意済みの構造、データ型、列名のことです。上流チームがデータチームに通知せずにアプリケーションデータベースを変更すると、この契約が破られます。

スキーマドリフトはデータドリフトとは異なります。データドリフトとは、安定したスキーマ内の値の統計的分布の変化であり、平均順序値の低下、NULL値の増加、カテゴリ分布のシフトなどを指します。どちらも重要なデータ品質シグナルですが、検出方法や根本原因は異なります。列名や型を監視するスキーマ変更検出システムではデータドリフトを検出できませんし、分布監視システムでは列の追加や削除を検出できません。

スキーマのずれは必ずしも有害とは限りません。時間の経過に伴うずれの深刻度を追跡することで、活発な開発サイクル（良性のずれ）と不安定性（重大なずれ）を区別することができます。テーブルにnull許容列を後方互換性を維持したまま追加することはスキーマのずれであり、スキーマは変更されますが、新しい列を無視するコンシューマーには影響を与えない可能性があります。ずれを良性か重大かに分類するには、下流のコンシューマーと、それらが変更をどのように処理するかを理解する必要があります。

スキーマドリフトの4つのタイプ

分散データシステムは、4つの異なる側面でスキーマのずれを引き起こし、それぞれに異なる検出メカニズムが必要となる。

タイプ1：構造的な変位

物理スキーマ定義の変更：列の追加、列の削除、列名の変更、データ型の変更、制約の追加または削除、テーブルの追加および削除。これはスキーマのずれの中で最も目に見える形態であり、オブザーバビリティツールで最も一般的に対処されるものです。データベースのINFORMATION_SCHEMAクエリ、スキーマレジストリの比較、および移行ツールの監査ログは、接続されたシステムの構造的ずれを効果的に捕捉します。

検出：ベースラインとのスキーマスナップショットの比較、INFORMATION_SCHEMAポーリング、スキーマレジストリバージョンの比較。

タイプ2：意味のずれ

定義を変更せずに既存フィールドの意味を変更する。 status 以前は値が含まれていた ACTIVE, INACTIVE, PENDING 値が含まれています 1, 2, 3 生成サービスが列挙型を変更したためです。スキーマ、列名、データ型、null許容制約は変更されていません。意味的な契約が破綻しています。文字列ステータス値を解析していたコンシューマーは、自身のロジックでは処理できない整数値を受け取るようになりました。

セマンティックドリフトとコンテキストドリフトは、AIプログラムの失敗の大きな原因となっているにもかかわらず、議論の対象としては比較的新しく、監視も著しく不足しています。セマンティックドリフトは構造的なシグナルを生成しないため、自動的に検出するのが最も困難です。そのため、値の分布監視（既知の値と未知の値の比率の変化）または明示的な契約テストのいずれかが必要となります。

検出方法：値の分布監視、許容値の検証ルール、特定の有効な値を検証する契約テスト。

タイプ3：フォーマットのずれ

構造的に変更されていないフィールド内の値のエンコーディングまたはフォーマットが変更されました。以前はUTC ISO 8601文字列が含まれていたタイムスタンプフィールドに、Unixエポック整数が含まれるようになりました。以前は小数値が含まれていた通貨フィールドに、セント単位の整数値が含まれるようになりました。列は存在し、型は新しい値に対しても有効ですが、解析規則が変更されました。

フォーマットのずれは、分散システムの境界、つまりあるサービスがデータをシリアル化するフォーマットを別のサービスがデシリアル化する場面や、レガシーシステムとモダンシステムの境界、つまりCOBOLプログラムが特定のバイト位置規則でフラットファイルを書き込み、下流のETLプロセスがそれに依存する場面で特に頻繁に発生します。

検出：値の範囲とパターンの統計的プロファイリング、特定のフィールドに対するフォーマット検証ルール、境界契約テスト。

タイプ4：契約内容のずれ

データソースの可用性、鮮度、またはボリューム保証の変更。ソースシステムは以前は毎日午前3時（UTC）までにデータセットを配信していましたが、現在は午前6時までに配信するようになり、午前3時の鮮度を前提としていた下流プロセスに予期せぬ影響を与えています。ソースシステムは以前は1日あたり最低1,000レコードを保証していましたが、トラフィックの少ない時間帯にはそれよりも少ないレコードしか配信されなくなりました。どちらの変更も構造的な意味でのスキーマ変更ではありませんが、どちらもプロデューサーとコンシューマー間の契約を破ることになります。

検出機能：鮮度監視、容量異常検出、SLAに基づくアラート。

分散システムが問題を増幅させる理由

単一のデータベースと単一のアプリケーションチームで構成されるモノリシックシステムでは、スキーマ変更は管理されたイベントとして扱われます。DBAがマイグレーションを作成し、開発者がクエリを更新し、変更がまとめてデプロイされます。スキーマのずれのリスクは存在しますが、単一の権限を持つ担当者の管轄範囲内に収まります。

分散システムは、単一の権限を排除します。各サービスは自身のデータを所有し、各チームはスキーマの決定を独自に行います。各サービスのデータの利用者は、多くの場合、そのチームの直接的な認識範囲外にあります。特に、利用者がデータプラットフォーム、分析パイプライン、またはどの製品チームも積極的に保守していないレガシー統合ポイントである場合はなおさらです。

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

図は伝播パターンを示しています。注文サービスチームが追加します coupon_id 彼らのデータベースに。Kafkaイベントスキーマも更新して含める場合 coupon_id分析パイプラインを更新して、そのデータを取り込む必要があります。Kafkaスキーマがバージョン1のままの場合、そのフィールドはパイプラインに到達しません。パイプラインが更新されてもBIダッシュボードモデルが更新されない場合、そのフィールドはデータウェアハウスには存在しますが、レポートには表示されません。このドリフトは4つの境界のいずれにおいてもサイレントデータ損失を引き起こす可能性があり、各境界ごとに異なる検出メカニズムが必要です。

パイプラインのサイレント障害、古いダッシュボード、スキーマのずれ、不完全なデータセットなどは、現代のエンタープライズデータ環境における主要な運用リスクとなっています。最新のデータスタックは従来の環境よりも障害発生が速く、変換処理の失敗、データの鮮度不足、サイレントデータ破損などが、チームが手動で問題を検出するずっと前からパイプライン全体に広がっています。

分散スキーマのドリフトが高コストになるのは、「サイレント」な特性が原因です。例外を発生させるエラーは検知され、修正されます。しかし、サイレントに誤った数値を生成する変更は、その数値に基づくビジネス上の意思決定によって目に見える結果が生じるまで、検出されません。

層別検出手法

スキーマのずれを検出するには、分散システムの各レイヤーごとに異なるツールと技術が必要です。

データベースおよびデータウェアハウス層

最も成熟した検出レイヤー。主要なデータベースおよびデータウェアハウスのINFORMATION_SCHEMAテーブルは、クエリ可能なメタデータスナップショットを提供します。

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;

このパターンを自動化するツール：dbtスキーマテスト、Great Expectationsの列期待値、モンテカルロテーブル健全性監視、Acceldataスキーマドリフト監視。

イベントストリーミングレイヤー

Kafkaトピックは、スキーマレジストリ（Confluent Schema Registry、AWS Glue Schema Registry、Apicurio）を使用して、Avro、Protobuf、およびJSONスキーマの進化を管理します。レジストリは、公開時に互換性ルールを適用します。

ヤムル

# 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

スキーマレジストリはセマンティックドリフトを防ぐものではありません。名前と型は変更されていないものの、意味が変わったフィールドは互換性チェックを通過してしまいます。セマンティック検証には、契約テスト（Pact、AsyncAPIテスト）が必要です。

APIレイヤー

APIスキーマのずれを検出するには、根本的に異なる4つのアプローチがあります。仕様間の差分比較、仕様と実際の状況の監視、実際の状況間の監視、そしてトラフィックベースの検出です。この分野で最も混乱が生じているのは、異なるアプローチのツールを比較してしまうことにあります。

マイクロサービスアーキテクチャにおける内部サービスAPIの場合、コンシューマー主導型契約テスト（Pact）が最も信頼性の高いアプローチです。各コンシューマーはプロデューサーから必要とする契約を指定し、その契約はCI（継続的インテグレーション）でプロデューサーの実装に対して検証されます。また、コンシューマーの契約を破る変更は、デプロイ前にプロデューサーのテストスイートで失敗となります。

レガシーシステムの境界：ドリフトが目に見えなくなる場所

上記で説明したすべての検出方法は、INFORMATION_SCHEMA、スキーマレジストリ、OpenAPI仕様など、クエリ可能なインターフェースを通じてスキーマメタデータを公開するシステムに対して有効です。しかし、従来のメインフレームシステムと最新のデータプラットフォームの境界領域では、これらのインターフェースは存在しません。

クラウドETLパイプラインで使用するために毎晩フラットファイルを生成するCOBOLプログラムは、FDエントリおよび出力ロジックにおいて暗黙的なスキーマを定義します。フラットファイルの「スキーマ」、つまりバイト位置、データ型、COMP-3パック10進数フィールド、およびREDEFINES構造体は、COBOLソースコード内に存在し、最新の監視ツールが照会できるレジストリやメタデータストアには存在しません。

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

COBOLチームが変更になった場合 CUST-BALANCE from PIC S9(11)V99 COMP-3 〜へ PIC S9(13)V99 COMP-3より大きな残高値を処理するために精度を 2 桁追加すると、フィールドはパック 10 進数形式で 7 バイトから 8 バイトに拡張されます。バイト 50 以降のすべてのフィールドは 1 バイトずれます。ETL パイプラインが読み込むフラットファイルでは、CUST-BALANCE 以降のすべてのフィールドが間違ったバイト位置になります。ETL パイプラインはエラーを生成しません。バイト 51～57 を CUST-BALANCE として読み込み、次のバイト (現在は CUST-BALANCE の拡張表現の最初のバイト) を CUST-STATUS-CD の一部として解釈します。パイプラインは実行されます。数値は間違っています。スキーマドリフトアラートは発生しません。

これは、企業環境におけるスキーマのずれの中で最も危険な種類のものです。レガシーシステムにおける構造的な変更が、両端に検出メカニズムがないまま、フラットファイルインターフェースを通じて静かに伝播していくのです。

レガシー境界の逸脱が特に危険な理由となる3つの特性：

スキーマは監視ツールからは見えません。モンテカルロ法はVSAMファイルに接続できません。アクセルデータはFDエントリを照会できません。変更を検出する唯一の方法は、COBOLソースを以前のバージョンと比較すること、つまりデータ監視操作ではなくコード分析操作を行うことです。

伝播は静かに行われます。フラットファイルインターフェースはレコード構造を検証せず、バイトを読み取ります。バイトレイアウトの変更はエラーではなく、誤った値を生成します。

影響範囲は広い。300個のプログラムで使用されているCOBOLコピーブックは、300個のプログラムで共有されるスキーマである。コピーブックへの変更（DDLのALTER TABLEに相当）は、300個すべてのプログラムに同時に影響を及ぼし、それらのプログラムによって生成されたデータセットを利用するすべての下流のコンシューマーも、その変更を継承することになる。

スキーマ契約：通常は暗黙のうちに行われることを形式化する

スキーマのずれに対する構造的な解決策は、暗黙の契約を明示化することです。つまり、スキーマとは何か、誰がそれに依存しているのか、どのような変更が許可されているのかを、変更によって何かが壊れてからではなく、変更が行われる前に定義することです。

契約レイヤー	規制対象	ツール	従来の同等品
データベースDDL	テーブル構造、列の型、制約	リキベース、フライウェイ、アトラス	DB2 DDL移行スクリプト
イベントスキーマ	Kafka/イベントストリームの構造	Confluent Schema Registry、Apicurio	該当なし（フラットファイルにはレジストリがありません）
API契約	REST/gRPCインターフェースに関する期待	OpenAPI、Pact、AsyncAPI	該当なし（ファイルインターフェースに仕様がない）
データ品質	価値分布、鮮度、容量	『大いなる遺産』、dbtテスト	該当なし（ネイティブテストフレームワークなし）
ファイルフォーマット契約	フラットファイルバイトレイアウト、フィールド位置	COBOL FDエントリ（真の情報源）	コピーブックのバージョン管理

レガシー相当列の「コピーブックのバージョン管理」エントリは、COBOLスキーマの進化を管理するための実用的なメカニズムです。コピーブックをバージョン管理された成果物として扱い、変更承認プロセスを適用し、各コピーブックを含むプログラムのレジストリを維持し、コピーブックの変更が承認される前に影響分析を要求します。

コピーブックの変更承認ワークフロー：

開発者は変更を提案します CUSTMSTR.CPY
影響分析では、以下を含むすべてのプログラムを特定します。 CUSTMSTR.CPY （静的解析）
これらのプログラムによって生成されるすべてのフラットファイルは、スキーマ変更イベントとして識別されます。
これらのフラットファイルの下流のすべての利用者に通知されます
消費者検証テストが新しいレイアウトに対して実行されます
変更は、すべての消費者が互換性を確認した場合にのみ承認されます。

このワークフローは、スキーマレジストリの互換性強制パターンを反映したもので、ネイティブのスキーマレジストリが存在しないCOBOLレイヤーに適用されます。

分散スキーマドリフトの監視アーキテクチャ

完全なスキーマドリフト監視アーキテクチャは、すべてのシステムレイヤーにわたる4つのドリフトタイプすべてを網羅します。

スキーマスナップショットデータベース。各テーブルのINFORMATION_SCHEMAメタデータ、登録されたすべてのイベントスキーマバージョン、すべてのAPI仕様バージョン、および（レガシーシステムの場合）すべてのコピーブックバージョンの日次スナップショットを保存します。スナップショットデータベースは、現在の状態を比較するための基準となります。

変更検出パイプライン。スナップショットデータベースに対して毎日比較ジョブが実行され、監視対象の各レイヤーにおける追加、削除、型変更、制約変更を検出します。重大度の高い変更、後方互換性のない型変更、列の削除、必須フィールドの追加が発生した場合は、即座にアラートがトリガーされます。重大度の低い変更、NULL許容列の追加、インデックスの変更が発生した場合は、アドバイザリ通知が生成されます。

コンシューマー影響レジストリ。すべてのスキーマアーティファクトを既知のコンシューマーにマッピングするカタログです。どのパイプラインがどのテーブルから読み取りを行うか、どのサービスがどのKafkaトピックを使用するか、どのETLジョブがどのフラットファイルを処理するかなどを記録します。スキーマの変更が検出されると、コンシューマー影響レジストリは影響範囲、影響を受けるコンシューマーの数、そして最も重大なコンシューマーを特定します。

契約テストスイート。プロデューサースキーマに関するコンシューマーの想定を検証する自動テスト。データ生成サービスに影響を与えるすべてのデプロイメントで実行されます。登録済みのコンシューマーが依存する契約に違反があった場合、デプロイメントは失敗します。

レガシー境界監視。メインフレームシステムの場合：バージョン管理されたコピーブックの比較、JCLデータセット定義の監視、および生成プログラムのFDエントリで定義されたスキーマに対するフラットファイル形式の検証。このレイヤーでは、データ監視ではなくコード分析が必要であり、下流のコンシューマーにとってスキーマ変更となるCOBOLソースの変更を検出します。

定期的な監視は、多くのチームが考えている以上に重要です。Acceldataの定期的なドリフト分析に関するガイダンスでは、安定したベースラインとの自動比較を週単位または隔週単位で行うことを推奨しており、障害発生後にアドホックなチェックを行うだけでは不十分であると明記しています。特にレガシー境界監視においては、監視の頻度をCOBOLのデプロイメントスケジュールに合わせる必要があります。つまり、コピーブックを本番環境にリリースする際には、次の定期比較を待つのではなく、直ちにスキーマ影響分析を実行する必要があります。

認定条件 SMART TS XL レガシー環境におけるスキーマのずれに対処する

SMART TS XL レガシーシステムの境界における検出ギャップ、つまり最新の可観測性ツールが機能しなくなる層、そして最も危険なスキーマのずれが検出されない層に対処します。

静的コード解析機能は、すべての COBOL FD エントリ、COPY メンバー、および SELECT 句を解析し、レガシー環境におけるすべてのスキーマ成果物の構造化された表現を生成します。この解析を、デプロイ前とデプロイ後の 2 つのバージョンのコードベースに対して実行すると、その差異がレガシースキーマの変更ログとなります。つまり、どのコピーブックが変更されたか、どのフィールド定義が変更されたか、変更前と変更後のレイアウトはどうだったかが記録されます。これは、COBOL レイヤーに適用されるスキーマスナップショット比較です。

アプリケーション依存関係マッピングは、レガシースキーマのコンシューマー影響レジストリを提供します。つまり、どのプログラムが各コピーブックをインクルードしているか、どのプログラムがどのフラットファイルデータセットを生成しているか、どのJCLジョブがどのプログラムを呼び出すかといった情報です。スキーマ変更ログで変更されたコピーブックが特定されると、依存関係マップは直ちにコンシューマーリスト、つまりコピーブックをインクルードするすべてのプログラムと、それらのプログラムが生成するすべてのダウンストリームフラットファイルを生成します。これは、コピーブックの変更が低リスクの内部変更なのか、それとも数百のプログラムと数十のダウンストリームコンシューマーに影響を与える高リスクイベントなのかを判断する、影響範囲の計算です。

影響分析機能は、影響範囲を構造化された修復範囲に変換します。依存関係マップで識別される各コンシューマーについて、新しいスキーマに対応するためにどのような変更が必要か、また、それらの変更はどのような順序で適用すべきかが明らかになります。レガシーシステムから最新システムへの移行境界となるコンシューマー、つまりCOBOLプログラムによって生成されたフラットファイルを読み取るETLパイプラインの場合、影響分析によって、ETLパイプラインの列マッピング構成を更新して反映させる必要がある、特定のフィールド位置の変更とデータ型の変更が特定されます。

エンタープライズ検索機能により、スキーマアーティファクトの検出をクエリ可能にします。特定のバイト位置にあるフィールドを読み取るすべてのプログラム（レイアウト変更の影響を受けるコンシューマーを特定）、特定のフィールドを定義するすべてのコピーブック（バージョン管理と変更管理が必要なスキーマアーティファクトを特定）、特定のデータセットに出力を生成するすべてのプログラム（スキーマ変更によってコンシューマーへの通知をトリガーする必要があるプロデューサーを特定）を検索できます。この検索機能は、プロアクティブなスキーマガバナンスワークフローと、ドリフト発生後のインシデント調査の両方をサポートします。

管理する組織向けレガシーの近代化メインフレームのデータを最新のプラットフォームに移行するプログラム、 SMART TS XLのスキーマ分析は、移行ツールが必要とするソーススキーマドキュメント、つまり、元の移行仕様が作成された時点のデータだけでなく、データが実際に何であるかを定義する、完全かつ最新のFDエントリ定義とコピーブック構造を提供します。

誰も書いていない契約書も、やはり契約書である

分散システムにおけるスキーマのずれは、新しい問題ではありません。これは古くからある問題ですが、分散アーキテクチャによって解決がより困難になっています。なぜなら、モノリシックシステムにおいてスキーマ契約を強制していた権限、つまり中央データベース管理者、単一のアプリケーションチーム、統一されたコードベースが、数十もの独立したサービスに分散され、それぞれが下流のすべてのコンシューマーに対する完全な可視性を持たないまま、個別に妥当な決定を下しているからです。

解決策は、スキーマに対する権限を再集中させることではありません。暗黙の契約を明示化し、現在の状態をベースラインと比較できるシステムに登録し、変更が導入される境界で互換性ルールを適用し、変更が伝播する境界で違反を監視することです。最新のシステムでは、このためのツールは既に存在し、急速に改善されています。しかし、最新のプラットフォームとの境界にあるレガシーシステムでは、ツールのギャップは現実的かつ重大な問題です。クラウドETLパイプラインのスキーマ契約であるフラットファイル形式は、それを定義するCOBOLソースがスキーマアーティファクトとして分析およびバージョン管理されない限り、最新の監視ツールでは認識されません。

顧客獲得数が23%減少したことを示すダッシュボードは、受信したデータ自体に誤りがあったわけではありません。誤りは、データの意味に関する認識にありました。なぜなら、データの意味を定義するスキーマが、契約が登録されておらず、監視もされていない境界で変更されていたからです。分散システム（レガシーシステムであろうと最新システムであろうと）のどこに存在しようとも、スキーマのずれを検出するプログラムは、その境界に到達しなければなりません。