التهيئات العامة لـ التجسيد
محركات الجداول المدعومة
ملاحظة: بالنسبة إلى materialized views، فجميع محركات *MergeTree مدعومة.
محركات الجداول التجريبية المدعومة
إذا واجهت مشكلات عند الاتصال بـ ClickHouse من dbt باستخدام أحد المحركات المذكورة أعلاه، فيُرجى الإبلاغ عن
مشكلة هنا.
ملاحظة حول إعدادات النموذج
settings إلى بند SETTINGS
المستخدم في عبارات DDL من نوع CREATE TABLE/VIEW، لذا تكون هذه عمومًا إعدادات خاصة بـ
محرك جدول ClickHouse المحدد. أما
query_settings الجديدة فتُستخدم لإضافة بند SETTINGS إلى استعلامات INSERT وDELETE المستخدمة في تجسيد النموذج (
بما في ذلك التجسيدات التزايدية).
توجد مئات من إعدادات ClickHouse، وليس من الواضح دائمًا أيّها إعداد “جدول” وأيّها إعداد “مستخدم”
(مع أن الأخيرة تكون متاحة عمومًا
في جدول system.settings.) وبوجه عام، يُوصى باستخدام القيم الافتراضية، وينبغي التحقق بعناية من أي استخدام لهذه الخصائص
واختباره.
إعدادات العمود
ملاحظة: تتطلب خيارات إعدادات العمود أدناه تفعيل عقود النموذج.
مثال على إعداد المخطط
إضافة أنواع معقدة
data_type الخاصة بالعقد. ولمعالجة ذلك، نوصي باستخدام الدالة CAST() في SQL الخاص بالنموذج لتحديد النوع المطلوب صراحةً. على سبيل المثال:
التجسيد: عرض
dbt_project.yml):
models/<model_name>.sql):
التجسيد: جدول
dbt_project.yml):
models/<model_name>.sql):
فهارس تخطي البيانات
table باستخدام إعداد indexes:
الإسقاطات
table وdistributed_table باستخدام إعداد projections:
_local، لا على جدول الوكيل الموزَّع.
التجسيد: incremental
dbt_project.yml:
models/<model_name>.sql:
الإعدادات
استراتيجيات النماذج التزايدية
dbt-clickhouse ثلاث استراتيجيات للنماذج التزايدية.
الاستراتيجية الافتراضية (القديمة)
استراتيجية Delete+Insert
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 المتاحة
استراتيجية الإلحاق
inserts_only في الإصدارات السابقة من dbt-clickhouse. ويعتمد هذا النهج ببساطة على إضافة
صفوف جديدة إلى العلاقة الحالية.
ونتيجة لذلك، لا تُزال الصفوف المكررة، ولا يوجد جدول مؤقت أو وسيط. وهو النهج الأسرع
إذا كانت الصفوف المكررة إما مسموحًا بها
في البيانات أو مستبعَدة بواسطة الاستعلام التزايدي أو عبارة WHERE/عامل التصفية.
استراتيجية insert_overwrite (تجريبية)
[IMPORTANT] حاليًا، لا تعمل استراتيجية insert_overwrite بشكل كامل مع التجسيدات الموزعة.تنفّذ الخطوات التالية:
- إنشاء جدول مرحلي (مؤقت) له البنية نفسها الخاصة بعلاقة النموذج التزايدي:
CREATE TABLE <staging> AS <target>. - إدراج السجلات الجديدة فقط (الناتجة عن
SELECT) في الجدول المرحلي. - استبدال الأقسام الجديدة فقط (الموجودة في الجدول المرحلي) في الجدول الهدف.
- إنه أسرع من الاستراتيجية الافتراضية لأنه لا ينسخ الجدول بأكمله.
- إنه أكثر أمانًا من الاستراتيجيات الأخرى لأنه لا يعدّل الجدول الأصلي حتى تكتمل عملية INSERT بنجاح: ففي حال حدوث فشلٍ أثناء التنفيذ، لا يتم تعديل الجدول الأصلي.
- يطبّق أفضل ممارسات هندسة البيانات المتعلقة بـ”عدم قابلية الأقسام للتغيير”، مما يبسّط المعالجة التزايدية والمتوازية للبيانات، وعمليات التراجع، وغير ذلك.
partition_by في إعدادات النموذج. وتتجاهل جميع
المعلمات الأخرى الخاصة بالاستراتيجية في إعدادات النموذج.
التجسيد: materialized_view
materialized_view عرضًا ماديًا في ClickHouse يعمل كمشغّل إدراج، إذ يحوّل الصفوف الجديدة من الجدول المصدر ويُدرجها تلقائيًا في الجدول الهدف. ويُعد هذا أحد أقوى أساليب التجسيد المتاحة في dbt-clickhouse.
نظرًا لتفاصيله، لهذا التجسيد صفحة مخصّصة مستقلة. انتقل إلى دليل العروض المادية للاطلاع على الوثائق الكاملة
التجسيد: dictionary (تجريبي)
التجسيد: distributed_table (تجريبي)
- إنشاء عرض مؤقت باستخدام استعلام SQL للحصول على البنية الصحيحة
- إنشاء جداول محلية فارغة استنادًا إلى العرض
- إنشاء جدول موزع استنادًا إلى الجداول المحلية.
- تُدرَج البيانات في الجدول الموزع، بحيث تُوزَّع عبر الأجزاء دون تكرار.
- تتضمن استعلامات dbt-clickhouse الآن تلقائيًا الإعداد
insert_distributed_sync = 1لضمان تنفيذ عمليات التجسيد التزايدي اللاحقة بشكل صحيح. وقد يؤدي ذلك إلى تنفيذ بعض عمليات insert في الجداول الموزعة ببطء أكبر من المتوقع.
مثال على نموذج لجدول موزع
عملية الترحيل المُنشأة
الإعدادات
materialization: distributed_incremental (تجريبية)
- استراتيجية Append تُدرِج البيانات فقط في الجدول الموزّع.
- استراتيجية Delete+Insert تُنشئ جدولًا موزّعًا مؤقتًا للتعامل مع جميع البيانات على كل شارد.
- الاستراتيجية الافتراضية (القديمة) تُنشئ جداول موزّعة مؤقتة ووسيطة للسبب نفسه.
مثال لنموذج distributed incremental
عمليات الترحيل المُنشأة
لقطة زمنية
snapshots/<model_name>.sql:
العقود والقيود
CHECK على مستوى الجدول/الـ model بالكامل. ولا يتم دعم المفتاح الأساسي، أو المفتاح الخارجي، أو القيد الفريد، أو قيود CHECK
على مستوى العمود.
(راجع وثائق ClickHouse حول مفاتيح المفتاح الأساسي وORDER BY.)