أنماط ETL مقابل ELT

فهم أنماط تكامل البيانات أساسي لمقابلات هندسة البيانات. كن مستعداً لمناقشة متى تستخدم كل نهج والمقايضات المتضمنة.

ETL: استخراج، تحويل، تحميل

النهج التقليدي حيث يحدث التحويل قبل التحميل.

┌─────────┐    ┌──────────────┐    ┌─────────────┐
│ المصادر│───▶│ منطقة التدريج│───▶│  المستودع  │
└─────────┘    │  (تحويل)     │    └─────────────┘
               └──────────────┘

الخصائص

الجانب	ETL
موقع التحويل	خادم/كتلة ETL مخصصة
الحوسبة	منفصلة عن المستودع
البيانات في المستودع	نظيفة، محولة فقط
الأفضل لـ	محلي، الأنظمة القديمة
الأدوات	Informatica, Talend, SSIS

متى تستخدم ETL

• المستودعات المحلية: حوسبة مستودع محدودة
• بيانات حساسة: تحتاج للفلترة/الإخفاء قبل التحميل
• بوابات جودة البيانات: يجب التحقق قبل المستودع
• متطلبات الامتثال: التحويل في بيئة متحكم بها

مثال أنبوب ETL

# ETL تقليدي مع pandas
import pandas as pd

# استخراج
source_df = pd.read_sql("SELECT * FROM source_orders", source_conn)

# تحويل (على خادم ETL)
transformed_df = (
    source_df
    .drop_duplicates(subset=['order_id'])
    .assign(
        order_date=lambda x: pd.to_datetime(x['order_date']),
        total_amount=lambda x: x['quantity'] * x['unit_price']
    )
    .query('order_status != "cancelled"')
)

# تحميل
transformed_df.to_sql('dim_orders', warehouse_conn, if_exists='append')

ELT: استخراج، تحميل، تحويل

النهج الحديث يستفيد من حوسبة المستودع السحابي.

┌─────────┐    ┌─────────────────────────────────┐
│ المصادر│───▶│           المستودع              │
└─────────┘    │ ┌─────────┐    ┌─────────────┐  │
               │ │  خام   │───▶│   محول     │  │
               │ └─────────┘    └─────────────┘  │
               └─────────────────────────────────┘

الخصائص

الجانب	ELT
موقع التحويل	داخل المستودع
الحوسبة	محرك MPP للمستودع
البيانات في المستودع	خام + محولة
الأفضل لـ	المستودعات السحابية
الأدوات	dbt, Dataform, SQL المستودع

متى تستخدم ELT

• المستودعات السحابية: حوسبة وفيرة، قابلة للتوسع
• المرونة مطلوبة: متطلبات التحويل تتغير كثيراً
• استكشاف البيانات: المحللون يحتاجون وصول للبيانات الخام
• المخطط عند القراءة: تحديد الهيكل عند وقت الاستعلام

مثال أنبوب ELT

-- استخراج وتحميل: البيانات الخام تصل للتدريج
-- (تتم بواسطة أداة الاستيعاب: Fivetran, Airbyte, مخصص)

-- التحويل في المستودع مع dbt
-- models/staging/stg_orders.sql
WITH source AS (
    SELECT * FROM {{ source('raw', 'orders') }}
),
cleaned AS (
    SELECT
        order_id,
        customer_id,
        CAST(order_date AS DATE) as order_date,
        quantity,
        unit_price,
        quantity * unit_price as total_amount,
        order_status
    FROM source
    WHERE order_status != 'cancelled'
    QUALIFY ROW_NUMBER() OVER (
        PARTITION BY order_id ORDER BY updated_at DESC
    ) = 1
)
SELECT * FROM cleaned

مصفوفة المقارنة

العامل	ETL	ELT
حوسبة التحويل	خادم ETL	المستودع
تخزين البيانات الخام	ليس في المستودع	في المستودع
التأخير	أعلى (قفزة إضافية)	أقل (تحميل مباشر)
المرونة	أقل (تحويلات ثابتة)	أعلى (إعادة التحويل)
نموذج التكلفة	ترخيص أداة ETL	حوسبة المستودع
حجم البيانات	أفضل للأصغر	أفضل للأكبر
مجموعة المهارات	خبرة أداة ETL	خبرة SQL

الأنماط الهجينة

EtLT: استخراج، تحويل صغير، تحميل، تحويل

شائع عملياً—معالجة مسبقة خفيفة قبل التحميل.

# استخراج مع تحويل خفيف
raw_df = extract_from_source()

# تحويل خفيف (t) - فقط ما يكفي للتحميل
light_transformed = (
    raw_df
    .rename(columns=str.lower)  # توحيد أسماء الأعمدة
    .assign(
        _loaded_at=datetime.utcnow(),
        _source='salesforce'
    )
)

# تحميل للطبقة الخام
load_to_warehouse(light_transformed, 'raw.salesforce_accounts')

# تحويل ثقيل (T) في المستودع مع dbt
# dbt run --models staging.stg_accounts

ETL العكسي

دفع البيانات المحولة للأنظمة التشغيلية.

┌───────────┐    ┌─────────────┐    ┌───────────┐
│ المستودع │───▶│ Census/     │───▶│ Salesforce│
│  (Gold)   │    │ Hightouch   │    │ HubSpot   │
└───────────┘    └─────────────┘    └───────────┘

حالات الاستخدام:

• مزامنة شرائح العملاء لأدوات التسويق
• دفع درجات ML للـ CRM
• تحديث لوحات القيادة التشغيلية

أسئلة المقابلة

السؤال: "متى تختار ETL على ELT؟"

إطار الإجابة:

اختر ETL عندما	اختر ELT عندما
مستودع محلي بحوسبة محدودة	مستودع سحابي بحوسبة قابلة للتوسع
يجب فلترة البيانات الحساسة قبل التحميل	تحتاج بيانات خام للتحليل العشوائي
بوابات جودة بيانات صارمة مطلوبة	متطلبات التحويل تتغير بشكل متكرر
تكامل الأنظمة القديمة	مجموعة البيانات الحديثة (dbt, Snowflake)

السؤال: "صمم أنبوب بيانات لتحليلات التجارة الإلكترونية في الوقت الحقيقي"

هيكل الإجابة:

1. المصدر: قاعدة بيانات المعاملات (CDC مع Debezium)
2. البث: Kafka للأحداث في الوقت الحقيقي
3. التحميل: Kafka Connect → Snowflake (جداول خام)
4. التحويل: نماذج dbt (مرحلة → حقائق/أبعاد)
5. التقديم: لوحة قيادة BI مع طبقة في الوقت الحقيقي

القرارات الرئيسية:
- نمط ELT للمرونة
- CDC لالتقاط منخفض التأخير
- البث للمقاييس الحساسة للوقت
- تحويلات دفعية للتجميعات التاريخية

مبادئ تصميم أنابيب البيانات

1. القابلية للتكرار

الأنابيب يجب أن تنتج نفس النتيجة عند التشغيل مرات متعددة.

-- سيئ: إلحاق بدون إزالة تكرار
INSERT INTO target SELECT * FROM source;

-- جيد: دمج/upsert
MERGE INTO target t
USING source s ON t.id = s.id
WHEN MATCHED THEN UPDATE ...
WHEN NOT MATCHED THEN INSERT ...;

2. المعالجة التدريجية

معالجة البيانات الجديدة/المتغيرة فقط عند الإمكان.

-- معالجة السجلات الجديدة فقط
SELECT * FROM source
WHERE updated_at > (SELECT MAX(updated_at) FROM target);

3. تطور المخطط

التعامل مع تغييرات مخطط المصدر بأناقة.

# اكتشف الأعمدة الجديدة
source_cols = set(source_df.columns)
target_cols = set(get_target_columns())
new_cols = source_cols - target_cols

if new_cols:
    for col in new_cols:
        add_column_to_target(col)

نظرة المقابلة: هندسة البيانات الحديثة تفضل ELT للمستودعات السحابية، لكن افهم كلا النمطين. كثير من المنظمات لديها نهج هجينة، والأنظمة القديمة لا تزال تستخدم ETL.

بعد ذلك، سنستكشف تنسيق الأنابيب مع Airflow و Prefect و Dagster. :::