التهيئات العامة لـ التجسيد
محركات الجداول المدعومة
ملاحظة: بالنسبة إلى 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. يتطلب كل إدخال إسقاط مفتاح query أو index، وليس كليهما.
ملاحظة: بالنسبة إلى الجداول الموزعة، يُطبَّق الإسقاط على الجداول _local، لا على جدول الوكيل الموزَّع.
ملاحظة: يؤدي تحديد كل من query وindex في إدخال الإسقاط نفسه إلى ظهور خطأ في وقت الترجمة البرمجية.
إسقاطات الاستعلامات
query لتعريف استعلام إسقاط كامل:
إسقاطات الفهارس
index كاختصار نحوي لإسقاطات الفهارس خفيفة الوزن التي تستخدم العمود الافتراضي _part_offset. مرّر اسم عمود واحد أو قائمة أعمدة للترتيب وفقًا لها:
التجسيد: incremental
dbt_project.yml:
models/<model_name>.sql:
الإعدادات
استراتيجيات النماذج التزايدية
dbt-clickhouse ثلاث استراتيجيات للنماذج التزايدية.
الاستراتيجية الافتراضية (القديمة)
استراتيجية Delete+Insert
delete+insert عمليات الحذف خفيفة الوزن لإزالة الصفوف المتأثرة، ثم تُدرج الصفوف الجديدة. ولأنها لا تنسخ الجدول بأكمله، فإن أداءها أفضل بكثير من استراتيجية “legacy”. يؤدي تعيين use_lw_deletes: true في ملف التعريف إلى جعل delete+insert استراتيجية التزايدية الافتراضية.
هناك بعض التحذيرات المهمة عند استخدام هذه الاستراتيجية:
- تعمل مباشرةً على الجدول المتأثر من دون إنشاء أي جداول وسيطة أو مؤقتة، لذا إذا حدثت مشكلة أثناء العملية، فمن المرجح أن تصبح بيانات النموذج التزايدي في حالة غير صالحة.
- تتطلب إعداد ClickHouse
allow_nondeterministic_mutations. يفعّله المهايئ تلقائيًا لجلساته الخاصة متى أمكن ذلك. وعندما يتعذر تفعيله (على سبيل المثال، إذا كان للقراءة فقط بالنسبة إلى مستخدم dbt الخاص بك)، فإن السلوك يعتمد على كيفية اختيار الاستراتيجية: فالنماذج التي تعتمد على الاستراتيجية الافتراضية تعود بصمت إلى استراتيجية legacy، بينما تفشل النماذج التي تعيّنdelete+insertأوmicrobatchصراحةً في وقت التشغيل، ويفشلuse_lw_deletes: trueفي ملف التعريف عند الاتصال. - في بعض الحالات النادرة جدًا، قد يؤدي استخدام
incremental_predicatesغير الحتمية إلى حدوث حالة سباق للعناصر المحدَّثة أو المحذوفة. ولضمان نتائج متسقة، ينبغي أن تقتصر المسندات التزايدية على الاستعلامات الفرعية التي تتعامل مع بيانات لن تُعدَّل أثناء التجسيد التزايدي.
استراتيجية 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.
نظرًا لتفاصيله، لهذا التجسيد صفحة مخصّصة مستقلة. انتقل إلى دليل العروض المادية للاطلاع على الوثائق الكاملة
التجسيد: قاموس (تجريبي)
dbt run، يُستبدل الـ قاموس بتعريف النموذج الحالي باستخدام CREATE OR REPLACE DICTIONARY.
التهيئات
مثال باستخدام مصدر ClickHouse
مثال باستخدام مصدر HTTP
source_type='http' (أو خيار table)، لا يُستخدم SQL الخاص بالنموذج كمصدر، لكن dbt لا يزال يتطلب body — لذا استخدم العنصر النائب select 1:
التجسيد: 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.)