`.
2. إدراج السجلات الجديدة فقط (الناتجة عن `SELECT`) في الجدول المرحلي.
3. استبدال الأقسام الجديدة فقط (الموجودة في الجدول المرحلي) في الجدول الهدف.
يوفّر هذا النهج المزايا التالية:
* إنه أسرع من الاستراتيجية الافتراضية لأنه لا ينسخ الجدول بأكمله.
* إنه أكثر أمانًا من الاستراتيجيات الأخرى لأنه لا يعدّل الجدول الأصلي حتى تكتمل عملية INSERT
بنجاح: ففي حال حدوث فشلٍ أثناء التنفيذ، لا يتم تعديل الجدول الأصلي.
* يطبّق أفضل ممارسات هندسة البيانات المتعلقة بـ"عدم قابلية الأقسام للتغيير"، مما يبسّط المعالجة
التزايدية والمتوازية للبيانات، وعمليات التراجع، وغير ذلك.
تتطلب هذه الاستراتيجية تعيين `partition_by` في إعدادات النموذج. وتتجاهل جميع
المعلمات الأخرى الخاصة بالاستراتيجية في إعدادات النموذج.
## التجسيد: materialized\_view
ينشئ تجسيد `materialized_view` [عرضًا ماديًا في ClickHouse](/docs/ar/reference/statements/create/view#materialized-view) يعمل كمشغّل إدراج، إذ يحوّل الصفوف الجديدة من الجدول المصدر ويُدرجها تلقائيًا في الجدول الهدف. ويُعد هذا أحد أقوى أساليب التجسيد المتاحة في dbt-clickhouse.
نظرًا لتفاصيله، لهذا التجسيد صفحة مخصّصة مستقلة. **[انتقل إلى دليل العروض المادية](/docs/ar/integrations/connectors/data-ingestion/etl-tools/dbt/materialization-materialized-view)** للاطلاع على الوثائق الكاملة
## التجسيد: dictionary (تجريبي)
راجع الاختبارات
في [https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test\_dictionary.py](https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test\_dictionary.py) للاطلاع على
أمثلة على كيفية
تنفيذ التجسيدات لقواميس ClickHouse
## التجسيد: distributed\_table (تجريبي)
يُنشأ الجدول الموزع باتباع الخطوات التالية:
1. إنشاء عرض مؤقت باستخدام استعلام SQL للحصول على البنية الصحيحة
2. إنشاء جداول محلية فارغة استنادًا إلى العرض
3. إنشاء جدول موزع استنادًا إلى الجداول المحلية.
4. تُدرَج البيانات في الجدول الموزع، بحيث تُوزَّع عبر الأجزاء دون تكرار.
ملاحظات:
* تتضمن استعلامات dbt-clickhouse الآن تلقائيًا الإعداد `insert_distributed_sync = 1` لضمان تنفيذ
عمليات التجسيد
التزايدي اللاحقة بشكل صحيح. وقد يؤدي ذلك إلى تنفيذ بعض عمليات insert في الجداول الموزعة ببطء أكبر من
المتوقع.
### مثال على نموذج لجدول موزع
```sql theme={null}
{{
config(
materialized='distributed_table',
order_by='id, created_at',
sharding_key='cityHash64(id)',
engine='ReplacingMergeTree'
)
}}
select id, created_at, item
from {{ source('db', 'table') }}
```
### عملية الترحيل المُنشأة
```sql theme={null}
CREATE TABLE db.table_local on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = ReplacingMergeTree
ORDER BY (id, created_at);
CREATE TABLE db.table on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
### الإعدادات
تُدرج أدناه الإعدادات الخاصة بنوع materialization هذا:
| الخيار | الوصف | القيمة الافتراضية إن وجدت |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| sharding\_key | يحدد مفتاح التقسيم خادم الوجهة عند الإدراج في جدول بمحرك Distributed. ويمكن أن يكون مفتاح التقسيم عشوائيًا أو ناتجًا عن دالة hash | `rand()`) |
## materialization: distributed\_incremental (تجريبية)
نموذج تزايدي يستند إلى الفكرة نفسها التي يقوم عليها الجدول الموزّع، وتكمن الصعوبة الرئيسية في معالجة جميع
الاستراتيجيات التزايدية على نحو صحيح.
1. *استراتيجية Append* تُدرِج البيانات فقط في الجدول الموزّع.
2. *استراتيجية Delete+Insert* تُنشئ جدولًا موزّعًا مؤقتًا للتعامل مع جميع البيانات على كل شارد.
3. *الاستراتيجية الافتراضية (القديمة)* تُنشئ جداول موزّعة مؤقتة ووسيطة للسبب نفسه.
لا تُستبدل إلا جداول الشاردات، لأن الجدول الموزّع لا يحتفظ بالبيانات.
ولا يُعاد تحميل الجدول الموزّع إلا عند تمكين وضع full\_refresh أو عند احتمال تغيّر بنية الجدول.
### مثال لنموذج distributed incremental
```sql theme={null}
{{
config(
materialized='distributed_incremental',
engine='MergeTree',
incremental_strategy='append',
unique_key='id,created_at'
)
}}
select id, created_at, item
from {{ source('db', 'table') }}
```
### عمليات الترحيل المُنشأة
```sql theme={null}
CREATE TABLE db.table_local on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = MergeTree;
CREATE TABLE db.table on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
## لقطة زمنية
تتيح لقطات dbt تسجيل التغييرات التي تطرأ على نموذج قابل للتعديل بمرور الوقت. ويتيح ذلك بدوره تنفيذ
استعلامات على النماذج عند نقطة زمنية محددة، بحيث يمكن للمحللين "الرجوع بالزمن" للاطلاع على الحالة السابقة للنموذج. وهذه الوظيفة
مدعومة من خلال موصل ClickHouse، ويجري تكوينها باستخدام الصيغة التالية:
كتلة config في `snapshots/.sql`:
```python theme={null}
{{
config(
schema = "",
unique_key = "",
strategy = "",
updated_at = "",
)
}}
```
لمزيد من المعلومات حول التهيئة، اطّلِع على صفحة [مرجع إعدادات اللقطات](https://docs.getdbt.com/docs/build/snapshots#snapshot-configs).
## العقود والقيود
لا تُدعَم إلا عقود أنواع الأعمدة المتطابقة تمامًا. على سبيل المثال، سيفشل العقد الذي يحدد نوع العمود UInt32 إذا كان الـ model
يعيد UInt64 أو أي نوع عدد صحيح آخر.
كما أن ClickHouse لا تدعم *إلا* قيود `CHECK` على مستوى الجدول/الـ model بالكامل. ولا يتم دعم المفتاح الأساسي، أو المفتاح الخارجي، أو القيد الفريد، أو قيود CHECK
على مستوى العمود.
(راجع وثائق ClickHouse حول مفاتيح المفتاح الأساسي وORDER BY.)