ترحيل (تكرار) البيانات الوصفية إلى محرك معالجة بيانات
Replication of Your Metadata to a Data Processing Engine
شرح لآلية Repository Replication في Validatar التي تُزامن بيانات المستودع الداخلي باستمرار إلى محرك معالجة بيانات من نوع Snowflake لأغراض التقارير والتحليل.
نظرة عامة
تخزّن Validatar جميع بياناتها التشغيلية — كتالوجات البيانات الوصفية (metadata catalogs)، وتعريفات الاختبارات، ونتائج التنفيذ، ومقاييس التنميط (profiling metrics)، ودرجات الثقة (trust scores)، وغيرها — في قاعدة بيانات مستودعها الداخلي (SQL Server أو PostgreSQL). ورغم أن هذه القاعدة تُشغِّل التطبيق، إلا أنها ليست مصمَّمة للتحليلات المخصصة (ad-hoc analytics) أو التقارير عبر المنصات المختلفة.
يحل ترحيل المستودع (repository replication) هذه المشكلة عن طريق المزامنة المستمرة لبيانات Validatar الداخلية إلى محرك معالجة بيانات من نوع Snowflake. بمجرد التهيئة، تقوم Validatar بتحميل جداول المستودع تدريجيًا (incrementally) إلى مخطط (schema) مخصص في Snowflake، مما يمنح فريقك وصولًا مباشرًا عبر SQL إلى جميع بيانات Validatar التشغيلية. يتيح ذلك إعداد تقارير مخصصة، والتكامل مع أدوات BI، والمقارنات عبر البيئات المختلفة، وأي تحليل يستفيد من وجود بيانات Validatar في مستودع بيانات قابل للاستعلام.
المتطلبات الأساسية
قبل تهيئة ترحيل المستودع، تحتاج إلى:
- محرك معالجة بيانات من نوع Snowflake تم إنشاؤه بالفعل في Validatar (راجع مقالة Creating Data Processing Engines)
- تفعيل ميزة الترخيص Snowflake Results Storage في بيئة Validatar الخاصة بك
- صلاحية وصول المسؤول (Administrator) — لا يمكن تهيئة الترحيل إلا للمستخدمين الذين يحملون دور Global Configuration Admin
تهيئة ترحيل المستودع (Configuring Repository Replication)
انتقل إلى Settings > Configuration > Repository Replication.
الخطوة 1: اختيار محرك معالجة بيانات Snowflake
اختر محرك معالجة بيانات Snowflake الذي سيستقبل البيانات المُرحَّلة. تسرد القائمة المنسدلة جميع محركات Snowflake التي تم التحقق منها والمهيَّأة في بيئتك.
الخطوة 2: تحديد المخطط (Schema)
أدخل اسم مخطط Snowflake الذي سيتم فيه إنشاء الجداول المُرحَّلة. القيمة الافتراضية هي REPOSITORY.
يجب أن يكون مخطط الترحيل مختلفًا عن المخطط الافتراضي لمحرك معالجة البيانات المُختار. تقوم Validatar بإنشاء هذا المخطط وإدارته تلقائيًا — لست بحاجة إلى إنشائه مسبقًا في Snowflake.
الخطوة 3: تحديد جدول المزامنة (Sync Schedule)
انقر على Set Sync Schedule لتهيئة عدد مرات تشغيل عملية الترحيل.
يمكنك جدولة الترحيل ليعمل:
- يوميًا (Daily) — مرة واحدة في اليوم أو عدة مرات في اليوم
- أسبوعيًا (Weekly) — في أيام محددة من الأسبوع
- شهريًا (Monthly) — في أيام محددة من الشهر
بالنسبة لمعظم المؤسسات، تكفي المزامنة اليومية. أما إذا كان فريقك بحاجة إلى وصول شبه فوري إلى نتائج الاختبارات أو سجل التنفيذ، ففكر في جدولة عدة عمليات تشغيل يوميًا.
الخطوة 4: الحفظ (Save)
انقر على Save لحفظ التهيئة. سيبدأ الترحيل وفقًا للجدول الذي حددته.
آلية عمل التحميل التدريجي (Incremental Loading)
يستخدم ترحيل المستودع استراتيجية تحميل تدريجي لتقليل حجم البيانات المنقولة في كل عملية تشغيل.
نهج العلامة المائية الزمنية (Watermark Approach)
يتتبع كل جدول مُرحَّل علامة مائية زمنية (watermark) — وهي طابع زمني لآخر مزامنة ناجحة، ويتم تخزينها كحقل DateLastSynced لكل جدول. في كل عملية ترحيل:
- 1تستعلم Validatar عن قاعدة بياناتها الداخلية بحثًا عن الصفوف التي يكون فيها عمود المزامنة أكبر من العلامة المائية
- 2يتم اختيار الصفوف الجديدة والمعدَّلة فقط منذ آخر مزامنة
- 3يتم تسلسل (serialize) هذه الصفوف وبثها إلى جدول تجهيز مؤقت (staging table) في Snowflake ثم دمجها في الجداول الهدف
- 4تتقدم العلامة المائية إلى أحدث طابع زمني تم رصده
عمود المزامنة هو DateModified عند توفره، وفي حال عدم توفره يتم الرجوع إلى DateCreated للجداول التي لا تتتبع طوابع زمنية للتعديل.
عملية التجهيز والدمج (Staging and Merge Process)
يستخدم الترحيل نمط تجهيز-ثم-دمج (staging-then-merge):
- 1التجهيز (Staging) — يتم تسلسل الصفوف المتغيرة بصيغة JSON ورفعها إلى جدول تجهيز مؤقت (RepositoryReplicationStaging) في Snowflake
- 2الدمج (Merge) — لكل جدول، تنفّذ Validatar عبارة MERGE INTO التي تقوم بـ: تحديث الصفوف الموجودة (المطابَقة على المفتاح الأساسي ID)، وإدراج الصفوف الجديدة غير الموجودة في الهدف
- 3التنظيف (Cleanup) — يتم حذف سجلات التجهيز بعد نجاح عملية الدمج
يتميز هذا النهج بالكفاءة (لا يُنقل سوى البيانات المتغيرة)، وبكونه متكافئ القوة (idempotent) (إعادة تشغيل نفس الدفعة تُنتج نفس النتيجة)، ويعالج الإدراج والتحديث في عملية واحدة.
إعادة المزامنة الكاملة (Full Re-Sync)
إذا احتجت إلى فرض إعادة تحميل كاملة لجداول معينة — على سبيل المثال بعد تغيير في المخطط أو تصحيح بيانات — يمكنك إعادة تعيين تواريخ المزامنة لجداول فردية. يؤدي ذلك إلى مسح العلامة المائية وجعل عملية الترحيل التالية تسحب جميع صفوف تلك الجداول.
ما الذي يتم ترحيله
تُرحِّل Validatar 55 جدولًا من مستودعها الداخلي، تغطي كل منطقة رئيسية من مناطق المنصة. تستخدم جميع أسماء الجداول في Snowflake نمط تسمية SNAKE_CASE.
كتالوج البيانات الوصفية (Metadata Catalog)
| جدول Snowflake | المحتوى |
|---|---|
| META_SCHEMA | المخططات (schemas) المكتشفة من مصادر البيانات |
| META_TABLE | الجداول والعروض (views) داخل كل مخطط |
| META_TABLE_VERSION | النسخ التاريخية للبيانات الوصفية للجداول |
| META_COLUMN | الأعمدة ضمن الجداول |
| META_COLUMN_VERSION | النسخ التاريخية للبيانات الوصفية للأعمدة |
| META_DATA_SOURCE | تهيئات مصادر البيانات |
| META_DATA_PERMISSION | الصلاحيات على كائنات البيانات الوصفية |
| META_LINEAGE_SOURCE | ربط مصادر السلالة (lineage) |
| META_LINEAGE_TARGET | ربط أهداف السلالة (lineage) |
التنميط ودرجات الثقة (Profiling and Trust Scores)
| جدول Snowflake | المحتوى |
|---|---|
| META_DATA_LATEST_PROFILE | أحدث نتائج التنميط لكل كائن |
| META_DATA_PROFILE_SET | تهيئات مجموعات التنميط |
| DATA_PROFILE_DEF | بيانات وصفية لتعريف التنميط |
| META_TABLE_TRUST_SCORE | درجات الثقة لكل جدول |
| TRUST_SCORE_IMPACT_RATING | تهيئات تصنيف تأثير درجة الثقة |
الاختبارات والتنفيذ (Tests and Executions)
| جدول Snowflake | المحتوى |
|---|---|
| TEST | تعريفات الاختبارات |
| TEST_VERSION | النسخ التاريخية لتهيئات الاختبارات |
| TEST_DATA_SET | مجموعات البيانات المرتبطة بالاختبارات |
| TEST_DATA_SET_TYPE | تصنيفات أنواع مجموعات البيانات |
| TEST_EXECUTION | نتائج تنفيذ الاختبارات الفردية |
| TEST_META_LINK | الروابط بين الاختبارات وكائنات البيانات الوصفية |
| TEST_OVERALL_RESULT_STATUS | حالات نتائج الاختبار الإجمالية |
اختبارات القالب (Template Tests)
| جدول Snowflake | المحتوى |
|---|---|
| TEMPLATE_TEST_VERSION | تهيئات نسخ اختبارات القالب |
| TEMPLATE_TEST_DATA_SET | تعريفات مجموعات بيانات اختبارات القالب |
| TEMPLATE_TEST_CHILD_OBJECT | ربط كائنات الاختبارات الفرعية المُجسَّدة (materialized) |
| TEMPLATE_TEST_EXECUTION | نتائج تنفيذ اختبارات القالب |
المهام والجدولة (Jobs and Scheduling)
| جدول Snowflake | المحتوى |
|---|---|
| BATCH | سجلات دفعات التنفيذ |
| JOB | تعريفات المهام |
| JOB_STEP | الخطوات ضمن المهام |
| JOB_STEP_EXECUTION | نتائج تنفيذ خطوات المهام الفردية |
| JOB_SCHEDULE | ربط جدولة المهام |
| SCHEDULE | تعريفات الجدولة |
| SCRIPT_EXECUTION | سجلات تنفيذ النصوص البرمجية |
المشاريع والصلاحيات (Projects and Permissions)
| جدول Snowflake | المحتوى |
|---|---|
| PROJECT | تعريفات المشاريع |
| PROJECT_DATA_SOURCE | تعيين مصادر البيانات للمشاريع |
| PROJECT_MEMBER | عضوية المستخدمين في المشاريع |
| PROJECT_MEMBER_ROLE | تعيينات الأدوار لأعضاء المشروع |
الاتصالات (Connections)
| جدول Snowflake | المحتوى |
|---|---|
| CONNECTION | تعريفات الاتصالات |
| CONNECTION_VERSION | تهيئات نسخ الاتصالات |
الحقول المخصصة (Custom Fields)
| جدول Snowflake | المحتوى |
|---|---|
| CUSTOM_FIELD | تعريفات الحقول المخصصة |
| CUSTOM_FIELD_SECTION | تجميعات أقسام الحقول المخصصة |
| CUSTOM_FIELD_SECTION_FIELD | الحقول ضمن الأقسام |
| CUSTOM_FIELD_OBJECT_VALUE | قيم الحقول المخصصة المعيَّنة للكائنات |
| CUSTOM_FIELD_OPTION | خيارات القوائم المنسدلة للحقول المخصصة |
المستخدمون والأدوار (Users and Roles)
| جدول Snowflake | المحتوى |
|---|---|
| USER | حسابات المستخدمين |
| USER_IDENTITY | سجلات هوية المستخدم (SSO، محلي) |
| USER_ROLE | تعيينات الأدوار |
| USER_GROUP | تعريفات مجموعات المستخدمين |
| USER_GROUP_USER | عضوية المجموعات |
| ROLE | تعريفات الأدوار |
التهيئة والنظام (Configuration and System)
| جدول Snowflake | المحتوى |
|---|---|
| CODE_DEF | قيم البحث لتعريفات الأكواد |
| COMMENT | التعليقات على الكائنات |
| EVENT | أحداث النظام |
| EVENT_TYPE | تصنيفات أنواع الأحداث |
| EXCEPTION_LOG | سجلات الاستثناءات والأخطاء |
| FOLDER | التسلسل الهرمي للمجلدات لتنظيم الكائنات |
| QUALITY_DIMENSION | تعريفات أبعاد الجودة |
| REPORT | تهيئات التقارير |
| REPORT_PERMISSION | صلاحيات الوصول إلى التقارير |
| SEVERITY_LEVEL | تعريفات مستويات الخطورة |
العروض المساعدة (Helper Views)
بعد كل عملية ترحيل، تنشئ Validatar تلقائيًا وتحدّث عروضًا مساعدة (helper views) في مخطط الترحيل لتبسيط استعلامات التقارير الشائعة:
| العرض (View) | الغرض |
|---|---|
| VW_DATASET_HELPER_TABLE_PROFILES | يجمع أحدث نتائج التنميط مع تعريفات التنميط لتنميطات مستوى الجدول — صف واحد لكل جدول لكل مقياس تنميط |
| VW_DATASET_HELPER_COLUMN_PROFILES | نفس البنية لتنميطات مستوى العمود — صف واحد لكل عمود لكل مقياس تنميط |
| VW_DATASET_TABLES | عرض واسع للجداول مع قيم الحقول المخصصة المُحوَّلة (pivoted) ومقاييس التنميط مدمجة، جاهز لاستخدامات BI |
| VW_DATASET_COLUMNS | نفس البنية للأعمدة — يتضمن تحويلات الحقول المخصصة ومقاييس التنميط على مستوى العمود |
يتم توليد العرضين VW_DATASET_TABLES وVW_DATASET_COLUMNS ديناميكيًا استنادًا إلى تعريفات الحقول المخصصة والتنميط الخاصة بك. عند تغيير الحقول المخصصة أو تعريفات التنميط، يُعاد بناء هذه العروض تلقائيًا في عملية الترحيل التالية.
تطور المخطط (Schema Evolution)
تتعامل Validatar مع تغييرات المخطط تلقائيًا. في كل عملية ترحيل، يقارن النظام بنية الأعمدة المتوقعة لكل جدول في Snowflake بالجدول الفعلي في Snowflake. إذا تم اكتشاف عدم تطابق — كإضافة عمود جديد إلى نموذج Validatar، أو تغيير نوع عمود، أو حذف عمود — يتم حذف جدول Snowflake وإعادة إنشائه بالمخطط الصحيح. يتم إعادة تعيين تاريخ المزامنة لذلك الجدول، مما يؤدي إلى إعادة تحميل كاملة في المرة التالية.
هذا يعني أنك لست بحاجة إلى إدارة مخطط Snowflake يدويًا مع تطور Validatar. يتم التعامل مع الترقيات التي تضيف أعمدة جديدة إلى الجداول الداخلية بشكل شفاف.
حالة الترحيل (Replication Status)
بعد اكتمال الترحيل الأولي، يعرض قسم Replication Status في صفحة التهيئة إحصائيات لكل جدول:
- Table Name — جدول Snowflake
- Row Count — إجمالي عدد الصفوف في جدول Snowflake
- Unchanged — الصفوف التي لم تتغير منذ آخر مزامنة
- Modified — الصفوف المُحدَّثة منذ آخر مزامنة
- Inserted — الصفوف الجديدة منذ آخر مزامنة
يمكنك أيضًا عرض مقارنة بين مستودع Validatar الخاص بك وSnowflake لتحديد أي حالات عدم تطابق غير متوقعة. إذا أظهر جدول تباينًا، يمكنك مسح تاريخ مزامنته لفرض إعادة مزامنة كاملة.
أفضل الممارسات (Best Practices)
- جدولة الترحيل خلال ساعات الذروة المنخفضة — يمكن أن تكون المزامنة الكاملة الأولى مكثفة الاستهلاك للموارد. جدولها في وقت تتوفر فيه سعة كافية لكل من نسخة Validatar الخاصة بك وSnowflake.
- استخدام مخطط مخصص — احتفظ بالبيانات المُرحَّلة منفصلة عن كائنات Snowflake الأخرى. يُعد المخطط الافتراضي REPOSITORY خيارًا جيدًا.
- مراقبة صفحة Replication Status — تحقق دوريًا من وجود حالات عدم تطابق غير متوقعة بين عدد صفوف Validatar وSnowflake. الاختلافات الطفيفة مباشرة بعد المزامنة أمر طبيعي (قد تكون بيانات جديدة قد وصلت بين المزامنة والمقارنة)، لكن حالات عدم التطابق الكبيرة والمستمرة تشير إلى وجود مشكلة.
- منح صلاحية القراءة فقط في Snowflake — أنشئ دورًا في Snowflake بصلاحيات SELECT فقط على مخطط الترحيل لمستخدمي التقارير وBI لديك. لا تُعدِّل الجداول المُرحَّلة مباشرة — فVataliar تديرها.
- استخدام العروض المساعدة للتقارير — العرضان VW_DATASET_TABLES وVW_DATASET_COLUMNS مصمَّمان لأدوات BI ولوحات المعلومات. فهما يدمجان الأبعاد الأكثر شيوعًا مسبقًا، مما يوفر عليك كتابة استعلامات معقدة على الجداول الخام.
كيف يندرج هذا ضمن الصورة الأكبر
يربط ترحيل المستودع بيانات Validatar الداخلية بمنظومة التحليلات الأوسع لديك. مع وجود بياناتك الوصفية، ونتائج الاختبارات، ومقاييس التنميط، ودرجات الثقة في Snowflake، يمكنك:
- بناء لوحات معلومات مخصصة في أدوات مثل Tableau أو Power BI أو Looker
- تشغيل مقارنات عبر البيئات المختلفة عن طريق ترحيل عدة نُسخ من Validatar إلى نفس حساب Snowflake
- إنشاء تنبيهات آلية بناءً على اتجاهات نتائج الاختبارات أو تغيرات درجة الثقة
- تغذية بيانات Validatar إلى منصات حوكمة البيانات لإدارة موحَّدة للبيانات الوصفية
- إجراء تحليل تاريخي لتغطية الاختبارات، واتجاهات التنفيذ، وتحسينات جودة البيانات بمرور الوقت
لمزيد من المعلومات حول محركات معالجة البيانات، راجع مقالتَي What Is a Data Processing Engine؟ وCreating Data Processing Engines.