الانتقال إلى المحتوى الرئيسي
يغطي هذا القسم جميع خيارات التجسيد المتاحة في dbt-clickhouse، بما في ذلك الميزات التجريبية.

التهيئات العامة لـ التجسيد

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

محركات الجداول المدعومة

ملاحظة: بالنسبة إلى materialized views، فجميع محركات *MergeTree مدعومة.

محركات الجداول التجريبية المدعومة

إذا واجهت مشكلات عند الاتصال بـ ClickHouse من dbt باستخدام أحد المحركات المذكورة أعلاه، فيُرجى الإبلاغ عن مشكلة هنا.

ملاحظة حول إعدادات النموذج

يحتوي ClickHouse على عدة أنواع/مستويات من “الإعدادات”. في إعدادات النموذج أعلاه، يمكن ضبط نوعين منها. يشير settings إلى بند SETTINGS المستخدم في عبارات DDL من نوع CREATE TABLE/VIEW، لذا تكون هذه عمومًا إعدادات خاصة بـ محرك جدول ClickHouse المحدد. أما query_settings الجديدة فتُستخدم لإضافة بند SETTINGS إلى استعلامات INSERT وDELETE المستخدمة في تجسيد النموذج ( بما في ذلك التجسيدات التزايدية). توجد مئات من إعدادات ClickHouse، وليس من الواضح دائمًا أيّها إعداد “جدول” وأيّها إعداد “مستخدم” (مع أن الأخيرة تكون متاحة عمومًا في جدول system.settings.) وبوجه عام، يُوصى باستخدام القيم الافتراضية، وينبغي التحقق بعناية من أي استخدام لهذه الخصائص واختباره.

إعدادات العمود

ملاحظة: تتطلب خيارات إعدادات العمود أدناه تفعيل عقود النموذج.

مثال على إعداد المخطط

إضافة أنواع معقدة

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

التجسيد: عرض

يمكن إنشاء نموذج dbt على هيئة عرض في ClickHouse وتهيئته باستخدام الصيغة التالية: ملف المشروع (dbt_project.yml):
أو كتلة config (models/<model_name>.sql):

التجسيد: جدول

يمكن إنشاء نموذج dbt كـ جدول ClickHouse، وتهيئته باستخدام الصيغة التالية: ملف المشروع (dbt_project.yml):
أو كتلة config (models/<model_name>.sql):

فهارس تخطي البيانات

يمكنك إضافة فهارس تخطي البيانات ضمن تجسيدات table باستخدام إعداد indexes:

الإسقاطات

يمكنك إضافة الإسقاطات إلى نمطي الـ التجسيد table وdistributed_table باستخدام إعداد projections:
ملاحظة: بالنسبة إلى الجداول الموزعة، يُطبَّق الإسقاط على الجداول _local، لا على جدول الوكيل الموزَّع.

التجسيد: incremental

ستُعاد إعادة إنشاء نموذج الجدول عند كل تنفيذ لـ dbt. وقد يكون ذلك غير عملي ومكلفًا للغاية عند التعامل مع مجموعات نتائج كبيرة أو تحويلات معقدة. ولمعالجة هذا التحدي وتقليل وقت البناء، يمكن إنشاء نموذج dbt كجدول ClickHouse من نوع incremental، ويُضبط باستخدام البنية التالية: تعريف النموذج في dbt_project.yml:
أو كتلة config داخل models/<model_name>.sql:

الإعدادات

الإعدادات الخاصة بهذا النوع من التجسيد مُدرجة أدناه:

استراتيجيات النماذج التزايدية

يدعم dbt-clickhouse ثلاث استراتيجيات للنماذج التزايدية.

الاستراتيجية الافتراضية (القديمة)

تاريخيًا، لم يكن لدى ClickHouse سوى دعم محدود للتحديثات وعمليات الحذف، وذلك على شكل “mutations” غير متزامنة. ولمحاكاة سلوك dbt المتوقع، ينشئ dbt-clickhouse افتراضيًا جدولًا مؤقتًا جديدًا يحتوي على جميع السجلات “القديمة” غير المتأثرة (غير المحذوفة وغير المعدَّلة)، بالإضافة إلى أي سجلات جديدة أو محدَّثة، ثم يستبدل هذا الجدول المؤقت أو يُجري له EXCHANGE مع علاقة النموذج التزايدي الحالية. وهذه هي الاستراتيجية الوحيدة التي تحافظ على العلاقة الأصلية إذا حدث خطأ ما قبل اكتمال العملية؛ ولكن نظرًا لأنها تتضمن نسخًا كاملًا للجدول الأصلي، فقد تكون مكلفة جدًا وبطيئة في التنفيذ.

استراتيجية Delete+Insert

أضاف ClickHouse ميزة “lightweight deletes” كميزة تجريبية في الإصدار 22.8. وتُعد عمليات الحذف الخفيفة أسرع بكثير من عمليات ALTER TABLE … DELETE لأنها لا تتطلب إعادة كتابة أجزاء البيانات في ClickHouse. وتستخدم الاستراتيجية التزايدية delete+insert عمليات الحذف الخفيفة لتنفيذ عمليات materialization تزايدية بأداء أفضل بكثير من الاستراتيجية “القديمة”. ومع ذلك، هناك محاذير مهمة عند استخدام هذه الاستراتيجية:
  • يجب تمكين “lightweight deletes” على ClickHouse server لديك باستخدام الإعداد allow_experimental_lightweight_delete=1 أو تعيين use_lw_deletes=true في profile لديك (مما سيؤدي إلى تمكين هذا الإعداد لجلسات dbt الخاصة بك)
  • أصبحت “lightweight deletes” الآن جاهزة لبيئات production، ولكن قد تظهر مشكلات في الأداء ومشكلات أخرى في إصدارات ClickHouse الأقدم من 23.3.
  • تعمل هذه الاستراتيجية مباشرةً على table/relation المتأثر (من دون إنشاء أي جداول وسيطة أو temporary tables)، لذلك إذا حدثت مشكلة أثناء العملية، فمن المرجح أن تصبح البيانات في النموذج التزايدي في حالة غير صالحة
  • عند استخدام “lightweight deletes”، يفعّل dbt-clickhouse الإعداد allow_nondeterministic_mutations. وفي بعض الحالات النادرة جدًا عند استخدام incremental_predicates غير الحتمية، قد يؤدي ذلك إلى حدوث race condition للعناصر التي تم تحديثها/حذفها (ورسائل السجل ذات الصلة في logs الخاصة بـ ClickHouse). ولضمان نتائج متسقة، يجب أن تتضمن predicates التزايدية استعلامات فرعية فقط على بيانات لن يجري تعديلها أثناء materialization التزايدية.

استراتيجية Microbatch (تتطلب dbt-core >= 1.9)

تُعد الاستراتيجية التزايدية microbatch إحدى ميزات dbt-core منذ الإصدار 1.9، وقد صُممت للتعامل بكفاءة مع تحويلات البيانات الكبيرة ذات السلاسل الزمنية. وفي dbt-clickhouse، تستند هذه الاستراتيجية إلى الاستراتيجية التزايدية الحالية delete_insert من خلال تقسيم الزيادة إلى دفعات زمنية محددة مسبقًا استنادًا إلى إعدادات النموذج event_time و batch_size. إلى جانب التعامل مع التحويلات الكبيرة، تتيح microbatch ما يلي: للاطلاع على استخدام microbatch بالتفصيل، راجع الوثائق الرسمية.
إعدادات Microbatch المتاحة

استراتيجية الإلحاق

تحل هذه الاستراتيجية محل الإعداد inserts_only في الإصدارات السابقة من dbt-clickhouse. ويعتمد هذا النهج ببساطة على إضافة صفوف جديدة إلى العلاقة الحالية. ونتيجة لذلك، لا تُزال الصفوف المكررة، ولا يوجد جدول مؤقت أو وسيط. وهو النهج الأسرع إذا كانت الصفوف المكررة إما مسموحًا بها في البيانات أو مستبعَدة بواسطة الاستعلام التزايدي أو عبارة WHERE/عامل التصفية.

استراتيجية insert_overwrite (تجريبية)

[IMPORTANT] حاليًا، لا تعمل استراتيجية insert_overwrite بشكل كامل مع التجسيدات الموزعة.
تنفّذ الخطوات التالية:
  1. إنشاء جدول مرحلي (مؤقت) له البنية نفسها الخاصة بعلاقة النموذج التزايدي: CREATE TABLE <staging> AS <target>.
  2. إدراج السجلات الجديدة فقط (الناتجة عن SELECT) في الجدول المرحلي.
  3. استبدال الأقسام الجديدة فقط (الموجودة في الجدول المرحلي) في الجدول الهدف.
يوفّر هذا النهج المزايا التالية:
  • إنه أسرع من الاستراتيجية الافتراضية لأنه لا ينسخ الجدول بأكمله.
  • إنه أكثر أمانًا من الاستراتيجيات الأخرى لأنه لا يعدّل الجدول الأصلي حتى تكتمل عملية INSERT بنجاح: ففي حال حدوث فشلٍ أثناء التنفيذ، لا يتم تعديل الجدول الأصلي.
  • يطبّق أفضل ممارسات هندسة البيانات المتعلقة بـ”عدم قابلية الأقسام للتغيير”، مما يبسّط المعالجة التزايدية والمتوازية للبيانات، وعمليات التراجع، وغير ذلك.
تتطلب هذه الاستراتيجية تعيين partition_by في إعدادات النموذج. وتتجاهل جميع المعلمات الأخرى الخاصة بالاستراتيجية في إعدادات النموذج.

التجسيد: materialized_view

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

التجسيد: dictionary (تجريبي)

راجع الاختبارات في https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test&#95;dictionary.py للاطلاع على أمثلة على كيفية تنفيذ التجسيدات لقواميس ClickHouse

التجسيد: distributed_table (تجريبي)

يُنشأ الجدول الموزع باتباع الخطوات التالية:
  1. إنشاء عرض مؤقت باستخدام استعلام SQL للحصول على البنية الصحيحة
  2. إنشاء جداول محلية فارغة استنادًا إلى العرض
  3. إنشاء جدول موزع استنادًا إلى الجداول المحلية.
  4. تُدرَج البيانات في الجدول الموزع، بحيث تُوزَّع عبر الأجزاء دون تكرار.
ملاحظات:
  • تتضمن استعلامات dbt-clickhouse الآن تلقائيًا الإعداد insert_distributed_sync = 1 لضمان تنفيذ عمليات التجسيد التزايدي اللاحقة بشكل صحيح. وقد يؤدي ذلك إلى تنفيذ بعض عمليات insert في الجداول الموزعة ببطء أكبر من المتوقع.

مثال على نموذج لجدول موزع

عملية الترحيل المُنشأة

الإعدادات

تُدرج أدناه الإعدادات الخاصة بنوع materialization هذا:

materialization: distributed_incremental (تجريبية)

نموذج تزايدي يستند إلى الفكرة نفسها التي يقوم عليها الجدول الموزّع، وتكمن الصعوبة الرئيسية في معالجة جميع الاستراتيجيات التزايدية على نحو صحيح.
  1. استراتيجية Append تُدرِج البيانات فقط في الجدول الموزّع.
  2. استراتيجية Delete+Insert تُنشئ جدولًا موزّعًا مؤقتًا للتعامل مع جميع البيانات على كل شارد.
  3. الاستراتيجية الافتراضية (القديمة) تُنشئ جداول موزّعة مؤقتة ووسيطة للسبب نفسه.
لا تُستبدل إلا جداول الشاردات، لأن الجدول الموزّع لا يحتفظ بالبيانات. ولا يُعاد تحميل الجدول الموزّع إلا عند تمكين وضع full_refresh أو عند احتمال تغيّر بنية الجدول.

مثال لنموذج distributed incremental

عمليات الترحيل المُنشأة

لقطة زمنية

تتيح لقطات dbt تسجيل التغييرات التي تطرأ على نموذج قابل للتعديل بمرور الوقت. ويتيح ذلك بدوره تنفيذ استعلامات على النماذج عند نقطة زمنية محددة، بحيث يمكن للمحللين “الرجوع بالزمن” للاطلاع على الحالة السابقة للنموذج. وهذه الوظيفة مدعومة من خلال موصل ClickHouse، ويجري تكوينها باستخدام الصيغة التالية: كتلة config في snapshots/<model_name>.sql:
لمزيد من المعلومات حول التهيئة، اطّلِع على صفحة مرجع إعدادات اللقطات.

العقود والقيود

لا تُدعَم إلا عقود أنواع الأعمدة المتطابقة تمامًا. على سبيل المثال، سيفشل العقد الذي يحدد نوع العمود UInt32 إذا كان الـ model يعيد UInt64 أو أي نوع عدد صحيح آخر. كما أن ClickHouse لا تدعم إلا قيود CHECK على مستوى الجدول/الـ model بالكامل. ولا يتم دعم المفتاح الأساسي، أو المفتاح الخارجي، أو القيد الفريد، أو قيود CHECK على مستوى العمود. (راجع وثائق ClickHouse حول مفاتيح المفتاح الأساسي وORDER BY.)
آخر تعديل في ٢٥ يونيو ٢٠٢٦