Skip to main content

مُهايئ dbt-clickhouse

يُمكّن dbt (أداة بناء البيانات) مهندسي التحليلات من تحويل البيانات في مستودعاتهم بمجرد كتابة عبارات SELECT. ويتولى dbt تحويل عبارات SELECT هذه إلى كائنات داخل قاعدة البيانات، مثل الجداول والعروض، وبذلك ينفّذ مرحلة التحويل (T) من Extract Load and Transform (ELT). يمكنك إنشاء نموذج يحدّده تعبير SELECT. داخل dbt، يمكن لهذه النماذج أن تشير إلى بعضها بعضًا وأن تُرتَّب في طبقات، مما يتيح بناء مفاهيم ذات مستوى أعلى. ويُولِّد تلقائيًا شيفرة SQL النمطية المطلوبة لربط النماذج. إضافة إلى ذلك، يحدّد dbt التبعيات بين النماذج ويضمن إنشاءها بالترتيب المناسب باستخدام رسم بياني موجّه لا دوري (DAG). يتوافق dbt مع ClickHouse عبر مُهايئ مدعوم من ClickHouse.

الميزات المدعومة

قائمة الميزات المدعومة:
  • التجسيد للجدول
  • التجسيد للعرض
  • التجسيد تزايدية
  • التجسيد تزايدية من نوع Microbatch
  • التجسيدات من نوع Materialized View (تستخدم صيغة TO الخاصة بـ MATERIALIZED VIEW، وهي تجريبية)
  • Seeds
  • Sources
  • إنشاء الوثائق
  • الاختبارات
  • Snapshots
  • معظم وحدات الماكرو في dbt-utils (وهي الآن مضمنة في dbt-core)
  • التجسيد مؤقتة
  • التجسيد للجدول الموزع (تجريبية)
  • التجسيد تزايدية موزعة (تجريبية)
  • العقود
  • إعدادات الأعمدة الخاصة بـ ClickHouse (Codec، TTL…)
  • إعدادات الجداول الخاصة بـ ClickHouse (indexes، projections…)
جميع الميزات حتى dbt-core 1.10 مدعومة، بما في ذلك الخيار --sample مع إصلاح جميع تحذيرات الإهمال للإصدارات المستقبلية. تكاملات Catalog (مثل Iceberg) التي قُدمت في dbt 1.10 ليست مدعومة أصلًا بعد في المهايئ، ولكن تتوفر حلول بديلة. راجع قسم دعم Catalog للتفاصيل. لا يزال هذا المهايئ غير متاح للاستخدام داخل dbt Cloud، لكننا نتوقع إتاحته قريبًا. يُرجى التواصل مع الدعم للحصول على مزيد من المعلومات حول هذا الأمر.

مفاهيم dbt وأنواع التجسيد المدعومة

يقدّم dbt مفهوم النموذج. ويُعرَّف النموذج على أنه عبارة SQL قد تجمع بين العديد من الجداول. ويمكن “تجسيد” النموذج بعدة طرق. ويمثل التجسيد استراتيجية بناء لاستعلام select الخاص بالنموذج. أما الشيفرة التي تقف وراء التجسيد فهي SQL قالبية تُغلّف استعلام SELECT الخاص بك داخل عبارة بهدف إنشاء relation جديدة أو تحديث relation موجودة. يوفر dbt خمسة أنواع من التجسيد، وكلها مدعومة بواسطة dbt-clickhouse:
  • view (الافتراضي): يُبنى النموذج كـ view في قاعدة البيانات. وفي ClickHouse يُنشأ هذا كـ view.
  • table: يُبنى النموذج كـ table في قاعدة البيانات. وفي ClickHouse يُنشأ هذا كـ table.
  • ephemeral: لا يُبنى النموذج مباشرةً في قاعدة البيانات، بل يُدرج داخل النماذج التابعة على شكل CTEs ‏(Common Table Expressions).
  • incremental: يُجسَّد النموذج في البداية كـ table، وفي عمليات التشغيل اللاحقة يُدرج dbt rows جديدة ويحدّث rows المتغيرة في table.
  • materialized view: يُبنى النموذج كـ materialized view في قاعدة البيانات. وفي ClickHouse يُنشأ هذا كـ materialized view.
وتحدد الصياغة الإضافية وclausees المختلفة كيفية تحديث هذه النماذج إذا تغيّرت بياناتها الأساسية. ويوصي dbt عمومًا بالبدء بتجسيد view إلى أن يصبح الأداء مصدر قلق. ويوفر تجسيد table تحسينًا في الأداء وقت الاستعلام عبر حفظ نتائج استعلام النموذج في table، مقابل زيادة في التخزين. ويطوّر نهج incremental هذه الفكرة أكثر، بحيث يمكن التقاط التحديثات اللاحقة على البيانات الأساسية في target table. كما يدعم المهايئ الحالي لـ ClickHouse أيضًا أنواع التجسيد dictionary وdistributed table وdistributed incremental. ويدعم المهايئ كذلك snapshots وseeds في dbt. فيما يلي الميزات التجريبية في dbt-clickhouse:

إعداد dbt ومهايئ ClickHouse

تثبيت dbt-core وdbt-clickhouse

يوفّر dbt عدة خيارات لتثبيت واجهة سطر الأوامر (CLI)، وهي موضّحة بالتفصيل هنا. نوصي باستخدام pip لتثبيت كلٍّ من dbt وdbt-clickhouse.

زوّد dbt بتفاصيل الاتصال الخاصة بمثيل ClickHouse لدينا.

اضبط ملف التعريف clickhouse-service في الملف ~/.dbt/profiles.yml، ووفّر خصائص schema وhost وport وuser وpassword. تتوفر القائمة الكاملة بخيارات إعدادات الاتصال في صفحة الميزات والإعدادات:

أنشئ مشروعًا لـ dbt

يمكنك الآن استخدام ملف التعريف هذا في أحد مشاريعك الحالية أو إنشاء مشروع جديد باستخدام:
داخل الدليل project_name، حدِّث ملف dbt_project.yml لتحديد اسم ملف التعريف للاتصال بخادم ClickHouse.

اختبار الاتصال

نفّذ dbt debug باستخدام أداة سطر الأوامر (CLI) للتأكد من أن dbt يستطيع الاتصال بـ ClickHouse. تأكد من أن المخرجات تتضمن Connection test: [OK connection ok]، مما يشير إلى نجاح الاتصال. انتقل إلى صفحة الأدلة لمعرفة المزيد عن كيفية استخدام dbt مع ClickHouse.

اختبار نماذجك ونشرها (CI/CD)

توجد العديد من الطرق لاختبار مشروع dbt الخاص بك ونشره. يقدّم dbt بعض الاقتراحات حول سير العمل وفق أفضل الممارسات ومهام CI. سنستعرض عدة استراتيجيات، لكن ضع في اعتبارك أن هذه الاستراتيجيات قد تتطلّب تعديلات كبيرة لتلائم حالة الاستخدام الخاصة بك.

‏CI/CD مع اختبارات بيانات بسيطة واختبارات الوحدة

من الطرق البسيطة لبدء مسار CI لديك تشغيل عنقود ClickHouse داخل مهمتك، ثم تشغيل نماذجك عليه. ويمكنك إدراج بيانات تجريبية في هذا العنقود قبل تشغيل النماذج. كما يمكنك ببساطة استخدام seed لملء بيئة الاختبار قبل الإنتاج بمجموعة فرعية من بيانات الإنتاج لديك. وبعد إدراج البيانات، يمكنك بعد ذلك تشغيل اختبارات البيانات واختبارات الوحدة. ويمكن أن تكون خطوة CD لديك بسيطة مثل تشغيل dbt build على عنقود ClickHouse الخاص ببيئة الإنتاج.

مرحلة CI/CD أكثر اكتمالًا: استخدم بيانات حديثة، واختبر فقط النماذج المتأثرة

تتمثل إحدى الاستراتيجيات الشائعة في استخدام مهام Slim CI، بحيث لا يُعاد نشر سوى النماذج المعدّلة (وتبعياتها الصاعدة والهابطة). ويعتمد هذا النهج على المخرجات الناتجة عن عمليات التشغيل في بيئة الإنتاج لديك (أي dbt manifest) لتقليل زمن تشغيل مشروعك وضمان عدم حدوث انجراف في المخطط بين البيئات. وللحفاظ على تزامن بيئات التطوير لديك وتجنب تشغيل نماذجك على عمليات نشر متقادمة، يمكنك استخدام clone أو حتى defer. نوصي باستخدام عنقود ClickHouse أو خدمة مخصصة لبيئة الاختبار (أي بيئة مرحلية) لتجنب التأثير في تشغيل بيئة الإنتاج لديك. ولضمان أن تكون بيئة الاختبار ممثلةً للواقع، من المهم استخدام مجموعة فرعية من بيانات الإنتاج لديك، إلى جانب تشغيل dbt بطريقة تمنع انجراف المخطط بين البيئات.
  • إذا لم تكن بحاجة إلى بيانات حديثة للاختبار، يمكنك استعادة نسخة احتياطية من بيانات الإنتاج لديك إلى البيئة المرحلية.
  • إذا كنت بحاجة إلى بيانات حديثة للاختبار، فيمكنك استخدام مزيج من remoteSecure() table function والعروض المادية القابلة للتحديث لإدراج البيانات بالوتيرة المطلوبة. وهناك خيار آخر يتمثل في استخدام تخزين الكائنات كوسيط، وكتابة البيانات دوريًا من خدمة الإنتاج لديك، ثم استيرادها إلى البيئة المرحلية باستخدام دوال الجداول الخاصة بتخزين الكائنات أو ClickPipes (للاستيعاب المستمر).
كما أن استخدام بيئة مخصصة لاختبارات CI يتيح لك إجراء اختبارات يدوية من دون التأثير في بيئة الإنتاج لديك. فعلى سبيل المثال، قد ترغب في توجيه أداة BI إلى هذه البيئة لاختبارها. أما بالنسبة إلى النشر (أي خطوة CD)، فنوصي باستخدام المخرجات الناتجة عن عمليات النشر في بيئة الإنتاج لديك لتحديث النماذج التي تغيّرت فقط. ويتطلب ذلك إعداد تخزين الكائنات (مثل S3) كتخزين وسيط لمخرجات dbt لديك. وبعد إتمام ذلك، يمكنك تشغيل أمر مثل dbt build --select state:modified+ --state path/to/last/deploy/state.json لإعادة بناء الحد الأدنى من النماذج المطلوبة بشكل انتقائي استنادًا إلى ما تغيّر منذ آخر تشغيل في بيئة الإنتاج.

استكشاف المشكلات الشائعة وإصلاحها

الاتصالات

إذا واجهت مشكلات عند الاتصال بـ ClickHouse من dbt، فتأكد من استيفاء المعايير التالية:
  • يجب أن يكون المحرّك أحد المحرّكات المدعومة.
  • يجب أن تتوفر لديك الأذونات الكافية للوصول إلى قاعدة البيانات.
  • إذا كنت لا تستخدم محرّك الجدول الافتراضي لقاعدة البيانات، فيجب عليك تحديد محرّك جدول في تهيئة النموذج.

فهم العمليات طويلة الأمد

قد تستغرق بعض العمليات وقتًا أطول من المتوقع بسبب استعلامات معيّنة في ClickHouse. ولمعرفة أي الاستعلامات تستغرق وقتًا أطول بشكل أدق، ارفع مستوى السجل إلى debug — سيؤدي ذلك إلى عرض الوقت المستغرَق لكل استعلام. على سبيل المثال، يمكن تحقيق ذلك بإضافة --log-level debug إلى أوامر dbt.

القيود

يحتوي مهايئ ClickHouse الحالي لـ dbt على عدة قيود ينبغي أن تكون على دراية بها:
  • تستخدم الإضافة صياغة تتطلب ClickHouse بالإصدار 25.3 أو أحدث. نحن لا نختبر الإصدارات الأقدم من ClickHouse. كما أننا لا نختبر حاليًا الجداول Replicated.
  • قد تتعارض عمليات تشغيل مختلفة لـ dbt-adapter إذا جرى تشغيلها في الوقت نفسه، لأنها قد تستخدم داخليًا أسماء الجداول نفسها للعمليات نفسها. لمزيد من المعلومات، راجع issue #420.
  • يقوم المهايئ حاليًا بتمثيل النماذج كجداول باستخدام INSERT INTO SELECT. وهذا يعني فعليًا تكرار البيانات إذا أُعيد تنفيذ التشغيل. وقد تؤدي مجموعات البيانات الكبيرة جدًا (PB) إلى أوقات تشغيل طويلة للغاية، مما يجعل بعض النماذج غير عملية. لتحسين الأداء، استخدم ClickHouse Materialized Views من خلال تنفيذ العرض بالشكل materialized: materialization_view. بالإضافة إلى ذلك، احرص على تقليل عدد الصفوف التي يعيدها أي استعلام باستخدام GROUP BY حيثما أمكن. ويُفضَّل استخدام النماذج التي تلخّص البيانات على تلك التي تكتفي بتحويلها مع الحفاظ على عدد الصفوف نفسه الموجود في المصدر.
  • لاستخدام Distributed tables لتمثيل نموذج، يجب إنشاء الجداول replicated الأساسية على كل عقدة يدويًا. ويمكن بعد ذلك إنشاء Distributed table فوقها. لا يدير المهايئ إنشاء عنقود.
  • عندما ينشئ dbt relation ‏(table/view) في database، فإنه ينشئه عادةً بالشكل: {{ database }}.{{ schema }}.{{ table/view id }}. لا يوجد في ClickHouse مفهوم schemas. لذلك يستخدم المهايئ الصيغة {{schema}}.{{ table/view id }}، حيث يكون schema هو ClickHouse database.
  • لا تعمل النماذج ephemeral/CTEs إذا وُضعت قبل INSERT INTO في statement إدراج في ClickHouse، راجع https://github.com/ClickHouse/ClickHouse/issues/30323. لا ينبغي أن يؤثر ذلك في معظم النماذج، لكن ينبغي توخي الحذر عند تحديد موضع النموذج ephemeral في تعريفات النماذج وعبارات SQL الأخرى.

Fivetran

يتوفر موصل dbt-clickhouse أيضًا للاستخدام ضمن تحويلات Fivetran، ما يتيح إمكانات تكامل وتحويل سلسة مباشرةً داخل منصة Fivetran باستخدام dbt.
آخر تعديل في ٢٤ يوليو ٢٠٢٦