الكشف عن انحراف المخطط عبر أنظمة البيانات الموزعة

كانت لوحة تحليلات البيانات صحيحة يوم الثلاثاء. وبحلول يوم الخميس، أظهرت انخفاضًا بنسبة 23% في اكتساب العملاء، وهو ما اعتبره فريق العمل مؤشرًا تجاريًا حقيقيًا، ما دفعهم إلى إعادة تنظيم ميزانيات التسويق، وإيقاف الحملات مؤقتًا، ورفع الأمر إلى مجلس الإدارة. واكتشف فريق هندسة البيانات يوم الجمعة أن خدمة المصدر قد أضافت عمودًا قابلًا للتصفير إلى registrations الجدول قبل ستة أيام. لم يتم تحديث مسار ETL. كانت العملية الحسابية التي استخرجت مقياس الاستحواذ تتعامل مع القيم الفارغة الجديدة كأصفار بدلاً من استبعادها. لم يتم إرسال أي إشعار بتغيير المخطط. لم يتم الإخلال بأي عقد بطريقة أدت إلى حدوث خطأ. تم تشغيل المسار بنجاح؛ وأنتج أرقامًا خاطئة بدت صحيحة.

يمثل انحراف المخطط تحولًا هيكليًا، على عكس مشكلات جودة البيانات حيث تكون القيم غير صحيحة، إذ يُخلّ انحراف المخطط بالاتفاق بين المصدر والوجهة. في بيئة قواعد البيانات المتجانسة ذات مدير قاعدة بيانات مركزي يتحكم في جميع أوامر تعريف البيانات (DDL)، يُفرض هذا الاتفاق من قِبل جهة واحدة. أما في نظام موزع، حيث تمتلك عشرات الخدمات المستقلة مخزن بيانات خاص بها، وحيث تحمل تدفقات الأحداث مخططات Avro التي تتطور بشكل مستقل، وحيث تُحدد واجهات الملفات المسطحة بين مهام المعالجة الدفعية على الحواسيب المركزية ومنصات التحليلات السحابية عقودًا ضمنية غير موجودة في وثائق أي من النظامين، فإن هذا الاتفاق يُوزع عبر جميع حدود النظام. لا ينتظر انحراف المخطط في بيئة موزعة خطأً من مدير قاعدة البيانات، بل ينشأ من التشغيل الطبيعي لفرق مستقلة تتخذ قرارات منطقية بشكل فردي دون رؤية كاملة لكل مستهلك نهائي لبياناتها.

ما هو انحراف المخطط، وما ليس هو

يُعرَّف انحراف المخطط بأنه تغيير في بنية عنصر بيانات لا ينعكس على مستخدمي هذا العنصر. ويكمن الفرق بين الانحراف والهجرة المخططة في التركيز على المستخدمين: فإعادة تسمية عمود تُنفَّذ في آنٍ واحد في جدول المصدر وفي كل استعلام مستخدم تُعدّ هجرة مخطط. أما إعادة التسمية نفسها التي تُنفَّذ فقط في جدول المصدر، مما يجعل المستخدمين يقرؤون أسماء أعمدة قديمة، فهي انحراف مخطط.

تعتمد مسارات البيانات على اتفاقية ثقة بين النظام المصدر ومستودع البيانات الوجهة. هذه الاتفاقية هي المخطط: البنية المتفق عليها، وأنواع البيانات، وأسماء الأعمدة التي تحدد مجموعة البيانات. عندما تُجري فرق المصدر تغييرات على قاعدة بيانات التطبيق دون إخطار فريق البيانات، فإنها تُخلّ بهذه الاتفاقية.

لا يُعدّ انحراف المخطط مرادفًا لانحراف البيانات. فانحراف البيانات هو تغيير في التوزيع الإحصائي للقيم ضمن مخطط مستقر، حيث تنخفض متوسطات قيم الترتيب، وتزداد معدلات القيم الفارغة، وتتحول التوزيعات الفئوية. وكلاهما مؤشران مهمان لجودة البيانات، لكنهما يتطلبان أساليب كشف مختلفة ويشيران إلى أسباب جذرية مختلفة. فنظام كشف تغييرات المخطط الذي يراقب أسماء الأعمدة وأنواعها لن يرصد انحراف البيانات؛ كما أن نظام مراقبة التوزيع لن يرصد إضافة الأعمدة أو حذفها.

لا يُعدّ انحراف المخطط ضارًا دائمًا. يساعد تتبع شدة الانحراف بمرور الوقت على التمييز بين دورات التطوير النشطة (الانحراف الحميد) وعدم الاستقرار (الانحراف الحرج). تُعتبر إضافة عمود قابل للتصفير إلى جدول، مع الحفاظ على التوافق مع الإصدارات السابقة، انحرافًا في المخطط، حيث تغيّر المخطط، ولكن قد لا يُسبب ذلك أي مشكلة لأي مستخدم يتجاهل العمود الجديد. يتطلب تصنيف الانحراف إلى حميد أو حرج فهم المستخدمين النهائيين وكيفية تعاملهم مع التغيير.

أنواع انحراف المخططات الأربعة

تُنتج أنظمة البيانات الموزعة انحرافًا في المخطط على طول أربعة أبعاد متميزة، يتطلب كل منها آليات كشف مختلفة:

النوع 1: الانحراف الهيكلي

التغييرات في تعريف المخطط المادي: إضافة أعمدة، حذف أعمدة، إعادة تسمية أعمدة، تغييرات في أنواع البيانات، إضافة قيود أو حذفها، إضافة جداول أو حذفها. يُعد هذا الشكل الأكثر وضوحًا لانحراف المخطط، وهو الأكثر شيوعًا في معالجة أدوات المراقبة. تُسجّل استعلامات INFORMATION_SCHEMA الخاصة بقاعدة البيانات، ومقارنات سجل المخططات، وسجلات تدقيق أدوات الترحيل، الانحراف الهيكلي بفعالية للأنظمة المتصلة.

الكشف: مقارنة لقطة المخطط مقابل خط الأساس؛ استطلاع INFORMATION_SCHEMA؛ مقارنة إصدار سجل المخطط.

النوع الثاني: الانحراف الدلالي

تغييرات في معنى حقل موجود دون تغيير تعريفه. عمود باسم status التي كانت تحتوي سابقًا على قيم ACTIVE, INACTIVE, PENDING يحتوي الآن على قيم 1, 2, 3 لأن خدمة الإنتاج غيّرت تعدادها. لم يطرأ أي تغيير على المخطط، أو اسم العمود، أو نوع البيانات، أو قيد القيم الفارغة. وقد تم الإخلال بالعقد الدلالي. يتلقى المستهلكون الذين قاموا بتحليل قيم الحالة النصية الآن أعدادًا صحيحة لا تتعامل معها منطقهم.

يُعدّ كلٌّ من الانحراف الدلالي والانحراف السياقي من المصطلحات الحديثة نسبيًا، ويخضعان لمراقبة أقل بكثير، على الرغم من كونهما مسؤولين عن نسبة متزايدة من إخفاقات برامج الذكاء الاصطناعي. ويُعتبر الانحراف الدلالي الأصعب في الرصد التلقائي لأنه لا يُنتج أي إشارة هيكلية، ويتطلب إما مراقبة توزيع القيم (نسبة تغير القيم المعروفة إلى القيم غير المعروفة) أو اختبارًا صريحًا للعقود.

الكشف: مراقبة توزيع القيم؛ قواعد التحقق من صحة القيم المسموح بها؛ اختبارات العقود التي تؤكد على قيم صالحة محددة.

النوع 3: انحراف التنسيق

طرأت تغييرات على ترميز أو تنسيق القيم في الحقول التي لم يطرأ عليها تغيير بنيوي. على سبيل المثال، حقل الطابع الزمني الذي كان يحتوي سابقًا على سلاسل UTC ISO 8601، أصبح الآن يحتوي على أعداد صحيحة من حقبة يونكس. وحقل العملة الذي كان يحتوي سابقًا على مبالغ عشرية، أصبح الآن يحتوي على مبالغ بالسنتمترات كأعداد صحيحة. العمود موجود، ونوع البيانات لا يزال صالحًا للقيم الجديدة، ولكن اصطلاح التحليل قد تغير.

يُعد انحراف التنسيق شائعًا بشكل خاص عند حدود الأنظمة الموزعة، حيث تقوم خدمة ما بتسلسل البيانات بتنسيق تقوم خدمة أخرى بفك تسلسله، وعند حدود الأنظمة القديمة والحديثة، حيث تكتب برامج COBOL ملفات مسطحة باتفاقيات محددة لموضع البايت تعتمد عليها عمليات ETL اللاحقة.

الكشف: التحليل الإحصائي لنطاقات القيم والأنماط؛ قواعد التحقق من صحة التنسيق في حقول محددة؛ اختبارات عقد الحدود.

النوع 4: انحراف العقد

تغييرات في ضمانات توفر البيانات أو حداثتها أو حجمها من مصدر البيانات. كان النظام المصدر يُسلّم مجموعة بيانات يوميًا بحلول الساعة 3 صباحًا بالتوقيت العالمي المنسق؛ أما الآن فيُسلّمها بحلول الساعة 6 صباحًا، مما يُعطّل العمليات اللاحقة التي كانت تفترض حداثة البيانات بحلول الساعة 3 صباحًا. كان النظام المصدر يضمن سابقًا حدًا أدنى قدره 1,000 سجل يوميًا؛ أما الآن فتُنتج فترات انخفاض حركة البيانات عددًا أقل. لا يُعد أي من هذين التغييرين تغييرًا في بنية النظام، ولكنهما يُخلّان بالاتفاق بين المُنتِج والمُستهلِك.

الكشف: مراقبة النضارة؛ الكشف عن الشذوذ في الحجم؛ التنبيه القائم على اتفاقية مستوى الخدمة.

لماذا تُفاقم الأنظمة الموزعة المشكلة؟

في نظام متجانس ذي قاعدة بيانات واحدة وفريق تطوير تطبيقات واحد، تُعتبر تغييرات المخطط أحداثًا مُدارة. يقوم مسؤول قاعدة البيانات بكتابة عملية الترحيل، ويُحدّث المطور الاستعلامات، ويتم نشر التغيير معًا. يوجد خطر انحراف المخطط، ولكنه محدود بنطاق السلطة الوحيدة.

تُزيل الأنظمة الموزعة تلك السلطة المركزية. فكل خدمة تمتلك بياناتها، ويتخذ كل فريق قراراته المتعلقة ببنية البيانات بشكل مستقل. وغالبًا ما يكون مستخدمو بيانات كل خدمة خارج نطاق معرفة ذلك الفريق المباشرة، لا سيما عندما يكون المستخدم منصة بيانات، أو مسار تحليلات، أو نقطة تكامل قديمة لا يُشرف عليها أي فريق منتج بشكل فعال.

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، فلن يصل الحقل إلى المسار. إذا تم تحديث المسار ولكن لم يتم تحديث نموذج لوحة معلومات ذكاء الأعمال، فسيكون الحقل موجودًا في مستودع البيانات ولكنه غير موجود في التقرير. يمكن أن يؤدي هذا التباين إلى فقدان بيانات صامت عند أي من الحدود الأربعة، ويتطلب كل حد آلية كشف مختلفة.

أصبحت أعطال خطوط البيانات الصامتة، ولوحات المعلومات القديمة، وانحراف المخططات، ومجموعات البيانات غير المكتملة، مخاطر تشغيلية رئيسية في بيئات بيانات المؤسسات الحديثة. تتعطل بنى البيانات الحديثة بشكل أسرع من البيئات التقليدية، حيث تنتشر عمليات التحويل المعيبة، وفشل تحديث البيانات، وتلف البيانات الصامت عبر خطوط البيانات قبل وقت طويل من اكتشاف الفرق للمشكلات يدويًا.

إن خاصية "الصمت" هي ما يجعل انحراف المخطط الموزع مكلفًا. يُلاحظ الخطأ الذي يُنتج استثناءً ويُصلح. أما التغيير الذي يُنتج أرقامًا خاطئة دون أن يُكتشف، فيستمر دون أن يُكتشف حتى يُتخذ قرار تجاري بناءً على تلك الأرقام، مما يُؤدي إلى عواقب واضحة.

أساليب الكشف حسب الطبقة

يتطلب اكتشاف انحراف المخطط أدوات وتقنيات مختلفة لكل طبقة من طبقات النظام الموزع:

طبقة قاعدة البيانات والمستودع

طبقة الكشف الأكثر تطوراً. توفر جداول 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، ومراقبة سلامة جدول Monte Carlo، ومراقبة انحراف مخطط Acceldata.

طبقة بث الأحداث

تستخدم مواضيع Kafka سجلات المخططات (سجل مخططات Confluent، وسجل مخططات AWS Glue، و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).

طبقة واجهة برمجة التطبيقات

توجد أربع طرق مختلفة جذريًا لرصد انحرافات مخططات واجهات برمجة التطبيقات: مقارنة المواصفات، ومراقبة المواصفات بالواقع، ومراقبة الواقع بالواقع، والكشف القائم على حركة البيانات. وينشأ معظم اللبس في هذا المجال من مقارنة الأدوات التي تعتمد على طرق مختلفة.

بالنسبة لواجهات برمجة التطبيقات الداخلية للخدمات في بنية الخدمات المصغرة، يعد اختبار العقود الموجهة من قبل المستهلك (Pact) هو النهج الأكثر موثوقية: يحدد كل مستهلك العقد الذي يحتاجه من المنتج، ويتم التحقق من العقود مقابل تنفيذ المنتج في التكامل المستمر، وأي تغيير يكسر عقد المستهلك يفشل مجموعة اختبار المنتج قبل النشر.

حدود النظام القديم: حيث يصبح الانحراف غير مرئي

جميع أساليب الكشف المذكورة أعلاه فعّالة مع الأنظمة التي تعرض بيانات تعريف المخطط عبر واجهات قابلة للاستعلام: INFORMATION_SCHEMA، وسجلات المخططات، ومواصفات OpenAPI. أما عند الحد الفاصل بين أنظمة الحواسيب المركزية القديمة ومنصات البيانات الحديثة، فلا وجود لهذه الواجهات.

يُعرّف برنامج COBOL الذي يُنتج ملفًا نصيًا يوميًا لاستخدامه في خط أنابيب ETL السحابي، مخططًا ضمنيًا في منطق إدخال وإخراج FD الخاص به. يوجد "مخطط" الملف النصي، بما في ذلك مواقع البايتات وأنواع البيانات وحقول الأرقام العشرية المضغوطة COMP-3 وهياكل REDEFINES، في شفرة مصدر 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 من PIC S9(11)V99 COMP-3 إلى PIC S9(13)V99 COMP-3بإضافة رقمين من الدقة للتعامل مع قيم الرصيد الأكبر، يتوسع الحقل من 7 بايتات إلى 8 بايتات بتنسيق عشري مضغوط. كل حقل بعد البايت 50 يتحرك موضعًا واحدًا. الآن، يحتوي الملف النصي الذي تقرأه عملية ETL على جميع الحقول بعد CUST-BALANCE في مواضع بايتات خاطئة. لا تُنتج عملية ETL خطأً؛ فهي تقرأ البايتات من 51 إلى 57 على أنها CUST-BALANCE وتُفسر البايت التالي (وهو الآن البايت الأول من التمثيل الموسع لـ CUST-BALANCE) كجزء من CUST-STATUS-CD. تعمل العملية. الأرقام خاطئة. لا يتم إطلاق أي تنبيه لانحراف المخطط.

هذا هو أخطر أنواع انحراف المخططات في بيئات المؤسسات: التغييرات الهيكلية في الأنظمة القديمة التي تنتشر بصمت من خلال واجهات الملفات المسطحة دون وجود آلية اكتشاف في أي من الطرفين.

ثلاث خصائص تجعل انحراف الحدود القديمة خطيراً بشكل فريد:

لا يمكن لأدوات المراقبة رصد المخطط. لا يستطيع برنامج مونت كارلو الاتصال بملف VSAM. ولا يستطيع برنامج Acceldata الاستعلام عن مدخل FD. الطريقة الوحيدة لاكتشاف التغيير هي مقارنة كود COBOL المصدري بإصدار سابق، وهي عملية تحليل للكود، وليست عملية مراقبة للبيانات.

لا يحدث انتشار للخطأ. لا تتحقق واجهات الملفات المسطحة من صحة بنية السجلات؛ بل تقرأ البايتات. يؤدي تغيير تخطيط البايتات إلى قيم خاطئة، وليس إلى أخطاء.

نطاق التأثير واسع. فملف COBOL المُضمّن في 300 برنامج هو عبارة عن مخطط مشترك بين 300 برنامج. أي تغيير في هذا الملف، وهو ما يُعادل أمر DDL ALTER TABLE، يؤثر على جميع البرامج الـ 300 في آنٍ واحد، ويرث كل مستخدم لاحق لأي مجموعة بيانات ناتجة عن أي من هذه البرامج الـ 300 هذا التغيير.

عقود المخططات: إضفاء الطابع الرسمي على ما هو عادةً ضمني

يتمثل الحل الهيكلي لانحراف المخطط في جعل العقود الضمنية صريحة، وتحديد ماهية المخطط، ومن يعتمد عليه، وما هي التغييرات المسموح بها، قبل إجراء التغيير بدلاً من إجرائه بعد أن يتسبب في كسر شيء ما.

طبقة العقد	ما يحكمه	الأدوات	المكافئ القديم
تعريف قاعدة البيانات (DDL)	بنية الجدول، وأنواع الأعمدة، والقيود	ليكويبيس، فلاي واي، أطلس	نصوص ترحيل DDL لـ DB2
مخطط الحدث	بنية تدفق الأحداث/كافكا	سجل مخططات كونفلوينت، أبيكوريو	غير متوفر (الملف المسطح لا يحتوي على سجل)
عقد واجهة برمجة التطبيقات	توقعات واجهة REST/gRPC	OpenAPI، Pact، AsyncAPI	غير متوفر (واجهة الملف ليس لها مواصفات)
جودة البيانات	توزيعات القيمة، النضارة، الحجم	آمال عظيمة، اختبارات العلاج السلوكي الجدلي	غير متوفر (لا يوجد إطار اختبار أصلي)
عقد تنسيق الملف	تخطيط بايت الملف المسطح، مواقع الحقول	مدخل COBOL FD (مصدر الحقيقة)	التحكم في إصدارات دفتر النسخ

يُعد إدخال "التحكم في إصدار دفتر النسخ" في عمود المكافئ القديم الآلية العملية لإدارة تطور مخطط COBOL: حيث يتم التعامل مع دفتر النسخ كعنصر ذي إصدار مع عملية الموافقة على التغيير، والاحتفاظ بسجل للبرامج التي تتضمن كل دفتر نسخ، واشتراط تحليل التأثير قبل الموافقة على أي تعديل على دفتر النسخ.

آلية الموافقة على تغييرات دفتر النسخ:

1. يقترح المطور تغييرًا على CUSTMSTR.CPY
2. يُحدد تحليل الأثر كل برنامج يتضمن CUSTMSTR.CPY (التحليل الثابت)
3. يتم تحديد كل ملف مسطح تنتجه تلك البرامج على أنه حدث تغيير في المخطط
4. يتم إخطار كل مستهلك لاحق لتلك الملفات المسطحة
5. يتم إجراء اختبارات التحقق من صحة المستهلك على التصميم الجديد
6. لا تتم الموافقة على التغيير إلا بعد تأكيد جميع المستهلكين على التوافق.

يعكس سير العمل هذا نمط فرض توافق سجل المخططات، المطبق على طبقة COBOL حيث لا يوجد سجل مخططات أصلي.

بنية مراقبة انحراف المخطط الموزع

تغطي بنية مراقبة انحراف المخطط الكاملة جميع أنواع الانحراف الأربعة عبر جميع طبقات النظام:

قاعدة بيانات لقطات المخطط. تُخزَّن لقطة يومية لكل جدول من بيانات تعريف INFORMATION_SCHEMA، ولكل إصدار من مخطط الأحداث المُسجَّلة، ولكل إصدار من مواصفات واجهة برمجة التطبيقات، ولكل إصدار من ملفات النسخ (للأنظمة القديمة). تُعتبر قاعدة بيانات اللقطات هي الأساس الذي تُقارن به الحالة الحالية.

نظام كشف التغييرات. تُجرى عمليات مقارنة يومية على قاعدة بيانات اللقطات، لكشف الإضافات والحذف وتغييرات أنواع البيانات وتغييرات القيود في كل طبقة مراقبة. تُطلق تنبيهات فورية عند رصد تغييرات بالغة الخطورة، وتغييرات أنواع البيانات غير المتوافقة مع الإصدارات السابقة، وحذف الأعمدة، وإضافة الحقول الإلزامية. أما التغييرات منخفضة الخطورة، وإضافة الأعمدة التي تقبل القيم الفارغة، وتغييرات الفهرسة، فتُصدر إشعارات استشارية.

سجل تأثير المستهلك. فهرس يربط كل عنصر من عناصر المخطط بمستهلكيه المعروفين: أي مسارات البيانات تقرأ من أي جداول، وأي الخدمات تستهلك أي مواضيع Kafka، وأي عمليات ETL تعالج أي ملفات نصية. عند اكتشاف تغيير في المخطط، يحدد سجل تأثير المستهلك نطاق التأثير، وعدد المستهلكين المتأثرين، وأيهم الأكثر أهمية.

مجموعة اختبارات العقود. اختبارات آلية تتحقق من افتراضات المستهلك حول مخططات المنتج. تُنفذ هذه الاختبارات على كل عملية نشر تتضمن خدمة إنتاج بيانات. ويفشل النشر في حال انتهاك عقد يعتمد عليه مستهلك مسجل.

مراقبة حدود الأنظمة القديمة. بالنسبة لأنظمة الحواسيب المركزية: مقارنة ملفات النسخ المُتحكَّم في إصداراتها، ومراقبة تعريفات مجموعات بيانات JCL، والتحقق من صحة تنسيق الملفات المسطحة وفقًا للمخطط المُعرَّف في مدخل FD الخاص بالبرنامج المُنتِج. تتطلب هذه الطبقة تحليل الشفرة بدلًا من مراقبة البيانات، حيث تكشف التغييرات في مصدر COBOL التي تُشكِّل تغييرات في المخطط بالنسبة للمستخدمين النهائيين.

تُعدّ المراقبة الدورية أكثر أهمية مما تتصوره العديد من الفرق. توصي إرشادات Acceldata بشأن تحليل الانحرافات الدورية بإجراء مقارنات آلية مع خط أساس ثابت أسبوعيًا أو كل أسبوعين، وتؤكد صراحةً أن انتظار عمليات التحقق المخصصة بعد حدوث عطل غير كافٍ. بالنسبة لمراقبة حدود الأنظمة القديمة تحديدًا، يجب أن تتوافق وتيرة المراقبة مع جدول نشر COBOL: أي إصدار لملف النسخ إلى بيئة الإنتاج يجب أن يُفعّل تحليلًا فوريًا لتأثير المخطط بدلًا من انتظار المقارنة الدورية التالية.

كيفية SMART TS XL معالجة انحراف المخطط في البيئات القديمة

SMART TS XL يعالج هذا النظام فجوة الكشف عند حدود النظام القديم، وهي الطبقة التي تتوقف عندها أدوات المراقبة الحديثة والتي يمر فيها أخطر انحراف في المخطط دون أن يتم اكتشافه.

تقوم خاصية تحليل الكود الثابت بتحليل كل مدخل من مداخل تعريفات الملفات (FD) في لغة COBOL، وعضو COPY، وعبارة SELECT، لإنتاج تمثيل منظم لكل عنصر من عناصر المخطط في البيئة القديمة. عند تشغيل هذا التحليل على نسختين من قاعدة البيانات، قبل وبعد النشر، تُشكل الاختلافات سجل تغييرات المخطط القديم: أي ملفات النسخ (copybooks) التي تغيرت، وأي تعريفات الحقول التي تغيرت، وما هي تخطيطات ما قبل وما بعد التغيير. هذه هي مقارنة لقطات المخطط المطبقة على طبقة COBOL.

توفر خريطة تبعية التطبيقات سجل تأثير المستهلك على المخططات القديمة: أي البرامج التي تتضمن كل ملف نسخ، وأي البرامج تُنتج أي مجموعات بيانات ملفات مسطحة، وأي وظائف JCL تستدعي أي البرامج. عندما يُحدد سجل تغييرات المخطط ملف نسخ مُعدَّل، تُنتج خريطة التبعية فورًا قائمة المستهلكين، أي كل برنامج يتضمن ملف النسخ وكل ملف مسطح تابع تُنتجه تلك البرامج. هذا هو حساب نصف قطر الانفجار الذي يُحدد ما إذا كان تغيير ملف النسخ تعديلًا داخليًا منخفض المخاطر أو حدثًا عالي المخاطر يؤثر على مئات البرامج وعشرات المستهلكين التابعين.

تحوّل خاصية تحليل الأثر نطاق التأثير إلى نطاق معالجة منظم: لكل مستهلك مُحدد بواسطة خريطة التبعية، ما التغييرات المطلوبة لاستيعاب المخطط الجديد، وبأي تسلسل يجب تطبيق هذه التغييرات؟ بالنسبة لمستهلكي الحدود من الأنظمة القديمة إلى الحديثة، وخطوط أنابيب ETL التي تقرأ الملفات المسطحة الناتجة عن برامج COBOL، يُحدد تحليل الأثر تغييرات موضع الحقول المحددة وتغييرات أنواع البيانات التي يجب تحديث تكوين تعيين أعمدة خط أنابيب ETL ليعكسها.

تتيح إمكانية البحث المؤسسي إمكانية الاستعلام عن اكتشاف عناصر المخطط: العثور على كل برنامج يقرأ حقلاً في موضع بايت محدد (تحديد المستخدمين المتأثرين بتغيير التخطيط)، وكل ملف نسخ يُعرّف حقلاً محدداً (تحديد عنصر المخطط الذي يجب ترقيمه والتحكم في تغييراته)، وكل برنامج يُنتج مخرجات إلى مجموعة بيانات محددة (تحديد المنتجين الذين يجب أن تُؤدي تغييرات مخططاتهم إلى إرسال إشعارات للمستخدمين). تدعم إمكانية البحث هذه كلاً من سير عمل إدارة المخطط الاستباقي والتحقيق في الحوادث اللاحقة للانحراف.

للمنظمات التي تدير تحديث التراث البرامج التي تتضمن نقل بيانات الحواسيب المركزية إلى المنصات الحديثة، SMART TS XLيوفر تحليل المخطط الخاص بـ 's وثائق مخطط المصدر التي تتطلبها أدوات الترحيل، وتعريفات إدخال FD الكاملة والحالية وهياكل دفتر النسخ التي تحدد ماهية البيانات بالفعل، وليس فقط ما كانت عليه عند كتابة مواصفات الترحيل الأصلية.

العقد الذي لم يكتبه أحد يظل عقدًا

إن انحراف المخطط في الأنظمة الموزعة ليس مشكلة جديدة. إنها مشكلة قديمة تجعلها البنية الموزعة أكثر صعوبة في الحل، لأن السلطة التي كانت تفرض عقود المخطط في الأنظمة المتجانسة، أي مدير قاعدة البيانات المركزي، وفريق التطبيق الواحد، وقاعدة التعليمات البرمجية الموحدة، قد تم توزيعها عبر عشرات الخدمات المستقلة، حيث تتخذ كل خدمة قرارات منطقية بشكل فردي مع رؤية غير كاملة لكل مستهلك نهائي.

لا يكمن الحل في إعادة مركزية السلطة على المخطط، بل في جعل العقود الضمنية صريحة، وتسجيلها في أنظمة قادرة على مقارنة الحالة الراهنة بالوضع الأساسي، وفرض قواعد التوافق عند نقاط إدخال التغييرات، ومراقبة أي انتهاكات عند نقاط انتشارها. بالنسبة للأنظمة الحديثة، تتوفر الأدوات اللازمة لذلك، وهي في تطور مستمر. أما بالنسبة للأنظمة القديمة التي تتداخل مع المنصات الحديثة، فإن فجوة الأدوات حقيقية وذات عواقب وخيمة، إذ أن تنسيق الملف المسطح الذي يمثل عقد مخطط لخط أنابيب ETL السحابي غير مرئي لأي أداة مراقبة حديثة ما لم يتم تحليل مصدر COBOL الذي يُعرّفه وتحديد إصداراته كجزء من المخطط.

لم تكن لوحة المعلومات التي أظهرت انخفاضًا بنسبة 23% في اكتساب العملاء مخطئة بشأن البيانات التي تلقتها، بل كانت مخطئة بشأن دلالات هذه البيانات، لأن المخطط الذي يُحدد دلالات البيانات قد تغير عند نقطة فاصلة لم يُسجل فيها أي عقد ولم تكن هناك جهة مراقبة. هذه النقطة الفاصلة، أينما وُجدت في نظام موزع، سواء كان قديمًا أو حديثًا، هي التي يجب أن تصل إليها برامج كشف انحراف المخطط.