التوفيق بين البيانات: إثبات نجاح ترحيل البيانات

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

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

لهذا السبب يوجد التوفيق بين البيانات (Reconciliation). إنها عملية مقارنة البيانات قبل وبعد الترحيل لإثبات أنه لم يتم فقدان أو تغيير أو إفساد أي شيء. إنها نقطة التفتيش النهائية قبل أن تعلن اكتمال الترحيل.

لماذا لا تكفي السكريبتات الخالية من الأخطاء

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

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

الأخطاء في السجلات لا تلتقط هذا النوع من المشاكل. لا يعلم محرك قاعدة البيانات أن الصف المفقود هو خطأ. إنه يعرف فقط أن جملة INSERT تم تنفيذها بنجاح. الطريقة الوحيدة لاصطياد هذه الإخفاقات الصامتة هي مقارنة بيانات المصدر مع بيانات الهدف مباشرة.

النهج العملي للتوفيق بين البيانات

لا يحتاج التوفيق بين البيانات إلى أن يكون معقدًا. الطريقة الأبسط والأكثر فعالية هي مقارنة المجموع الاختباري (Checksum). بدلاً من عمل Checksum للملفات، تقوم بعمل Checksum لدفعات من البيانات.

إليك كيفية عمل ذلك لترحيل جدول:

  1. اقرأ دفعة من الصفوف من جدول المصدر.
  2. احسب تجزئة (Hash) للدفعة بأكملها (على سبيل المثال، باستخدام MD5 أو SHA256 على تسلسل جميع قيم الأعمدة).
  3. اقرأ نفس الدفعة من جدول الهدف باستخدام نفس الترتيب واحسب نفس التجزئة.
  4. قارن بين التجزئتين.

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

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

الرسم البياني التالي يوضح عملية التوفيق دفعة تلو الأخرى:

flowchart TD A[البداية] --> B[استخراج دفعة من جدول المصدر] B --> C[حساب تجزئة الدفعة] C --> D[استخراج نفس الدفعة من جدول الهدف] D --> E[حساب تجزئة الدفعة] E --> F{مقارنة التجزئات} F -- متطابقة --> G[تحديد الدفعة كموثقة] F -- غير متطابقة --> H[وضع علامة على الدفعة للتحقيق] G --> I{هل توجد دفعات أخرى؟} H --> I I -- نعم --> B I -- لا --> J[مقارنة عدد الصفوف] J --> K{هل عدد الصفوف متطابق؟} K -- نعم --> L[إنشاء تقرير: الترحيل موثق] K -- لا --> M[وضع علامة على التناقض والتحقيق] L --> N[النهاية] M --> N

إليك استعلام SQL ملموس يطبق هذا النهج لجدولين:

-- مقارنة عدد الصفوف والمجاميع الاختبارية بين جداول المصدر والهدف
WITH source_checksums AS (
    SELECT
        COUNT(*) AS row_count,
        MD5(STRING_AGG(CAST(column1 AS TEXT) || '|' || CAST(column2 AS TEXT) || '|' || CAST(column3 AS TEXT), ',' ORDER BY id)) AS batch_hash
    FROM source_table
),
target_checksums AS (
    SELECT
        COUNT(*) AS row_count,
        MD5(STRING_AGG(CAST(column1 AS TEXT) || '|' || CAST(column2 AS TEXT) || '|' || CAST(column3 AS TEXT), ',' ORDER BY id)) AS batch_hash
    FROM target_table
)
SELECT
    'عدم تطابق عدد الصفوف' AS issue
FROM source_checksums, target_checksums
WHERE source_checksums.row_count <> target_checksums.row_count
UNION ALL
SELECT
    'عدم تطابق المجموع الاختباري' AS issue
FROM source_checksums, target_checksums
WHERE source_checksums.batch_hash <> target_checksums.batch_hash;

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

ما الذي يجب التحقق منه أيضًا بالإضافة إلى المجاميع الاختبارية

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

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

القيم الفارغة (Null). قد تغير عمليات الترحيل أحيانًا الأعمدة الفارغة إلى قيم افتراضية أو العكس. قارن عدد القيم الفارغة لكل عمود بين المصدر والهدف. غالبًا ما يشير عدم التطابق هنا إلى مشكلة في تحويل النوع أو قيد قيمة افتراضية تم تطبيقه بشكل غير صحيح.

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

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

جعل التوفيق بين البيانات جزءًا من خط الأنابيب الخاص بك

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

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

  • الاتصال بقاعدتي بيانات المصدر والهدف.
  • تشغيل مقارنة المجموع الاختباري على دفعات.
  • التحقق من عدد الصفوف، وعدد القيم الفارغة، وتوزيعات القيم.
  • إنشاء تقرير مفصل عن أي عدم تطابق.
  • إرسال إشعار (بريد إلكتروني، Slack، أو أيًا كان ما يستخدمه فريقك) بالنتائج.

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

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

ما ليس عليه التوفيق بين البيانات

التوفيق بين البيانات ليس بديلاً عن عمليات التشغيل التجريبي (Dry Runs) أو استراتيجيات التعبئة الخلفية. كل خطوة تخدم غرضًا مختلفًا.

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

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

قائمة تحقق عملية للتوفيق بين البيانات

عند إعداد التوفيق لترحيلك القادم، إليك قائمة تحقق مختصرة لتوجيهك:

  • مقارنة المجموع الاختباري لكل دفعة (1000-10000 صف لكل دفعة)
  • تطابق عدد الصفوف بين المصدر والهدف
  • تطابق عدد القيم الفارغة لكل عمود
  • تطابق توزيع القيم للأعمدة الرئيسية
  • التحقق من الحالات الحدودية (الأحرف الخاصة، القيم الحدودية)
  • سكريبت آلي مدمج في خط الأنابيب
  • إشعار عند الفشل مع تقرير مفصل بعدم التطابق

الخلاصة

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