هندسات المستودعات الحديثة

فهم هندسات مستودعات البيانات السحابية أساسي لمقابلات هندسة البيانات. كل منصة لديها خصائص مميزة تؤثر على قرارات التصميم.

هندسة Snowflake

المفاهيم الرئيسية

┌─────────────────────────────────────────────────┐
│              طبقة خدمات السحابة                  │
│  (تحسين الاستعلام، البيانات الوصفية، الأمان)   │
├─────────────────────────────────────────────────┤
│           طبقة الحوسبة متعددة الكتل             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ XS       │  │ Medium   │  │ 2XL      │     │
│  │Warehouse │  │Warehouse │  │Warehouse │     │
│  └──────────┘  └──────────┘  └──────────┘     │
├─────────────────────────────────────────────────┤
│            طبقة التخزين المركزية                │
│      (عمودي، مضغوط، S3/Azure/GCS)              │
└─────────────────────────────────────────────────┘

الميزات ذات الصلة بالمقابلات

الميزة	ما تحتاج معرفته
فصل التخزين/الحوسبة	توسيع مستقل، دفع منفصل
المستودعات الافتراضية	كتل حوسبة مستقلة
النسخ بدون نسخ	بيئات تطوير/اختبار فورية
السفر عبر الزمن	استعلام البيانات التاريخية (حتى 90 يوم)
التقسيمات الدقيقة	تقسيم تلقائي، 50-500MB مضغوط

سؤال المقابلة: "كيف يحقق Snowflake عزل الأداء؟"

الجواب: "Snowflake يستخدم مستودعات افتراضية منفصلة لأعباء عمل مختلفة. كل مستودع لديه موارد حوسبة مخصصة، لذا وظيفة ETL ثقيلة لن تؤثر على استعلامات لوحة القيادة إذا استخدموا مستودعات مختلفة. هذه الفائدة الرئيسية لفصل التخزين-الحوسبة."

استراتيجيات تحسين التكلفة

-- التعليق والاستئناف التلقائي
ALTER WAREHOUSE analytics_wh
SET AUTO_SUSPEND = 60  -- ثواني
    AUTO_RESUME = TRUE;

-- تخزين نتائج الاستعلام مؤقتاً
-- يخزن النتائج تلقائياً لمدة 24 ساعة
-- نفس الاستعلام، نفس الدور = نتائج فورية

-- مفاتيح التجميع للجداول الكبيرة
ALTER TABLE events CLUSTER BY (event_date, user_id);

هندسة BigQuery

المفاهيم الرئيسية

┌─────────────────────────────────────────────────┐
│                 محرك Dremel                      │
│      (بدون خادم، متوازي بشكل ضخم)              │
├─────────────────────────────────────────────────┤
│              تخزين Colossus                      │
│     (صيغة Capacitor العمودية، بيتابايت)        │
├─────────────────────────────────────────────────┤
│              شبكة Jupiter                        │
│        (عرض نطاق بيتابت بين الطبقات)           │
└─────────────────────────────────────────────────┘

الميزات ذات الصلة بالمقابلات

الميزة	ما تحتاج معرفته
بدون خادم	لا إدارة كتل
Slots	وحدات الحوسبة (2000 slot = ~$10K/شهر)
التقسيم	مطلوب للتحكم بالتكلفة على الجداول الكبيرة
التجميع	وضع البيانات المرتبطة معاً داخل الأقسام
BI Engine	تسريع في الذاكرة للوحات القيادة

سؤال المقابلة: "متى تستخدم BigQuery مقابل Snowflake؟"

الجواب: "BigQuery يتفوق لأعباء العمل الأصلية لـ GCP، التشغيل بدون خادم حقاً، وعندما تريد تجنب إدارة الكتل. Snowflake يقدم مرونة أكثر مع متعدد السحابة، مشاركة بيانات أفضل، وتسعير أكثر قابلية للتنبؤ. اختر بناءً على البصمة السحابية الحالية والتفضيلات التشغيلية."

أنماط التحكم بالتكلفة

-- دائماً قسّم الجداول الكبيرة
CREATE TABLE events
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id
AS SELECT * FROM raw_events;

-- استخدم dry-run للاستعلام لتقدير التكلفة
-- bq query --dry_run --use_legacy_sql=false 'SELECT ...'

-- اضبط حصص مخصصة
-- مستوى المشروع: أقصى بايت مفوتر في اليوم/الاستعلام

هندسة Redshift

المفاهيم الرئيسية

┌─────────────────────────────────────────────────┐
│              العقدة القائدة                      │
│    (تخطيط الاستعلام، التنسيق)                  │
├─────────────────────────────────────────────────┤
│            عقد الحوسبة                           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ العقدة 1 │  │ العقدة 2 │  │ العقدة N │     │
│  │(الشرائح) │  │(الشرائح) │  │(الشرائح) │     │
│  └──────────┘  └──────────┘  └──────────┘     │
└─────────────────────────────────────────────────┘

الميزات ذات الصلة بالمقابلات

الميزة	ما تحتاج معرفته
أنماط التوزيع	KEY, ALL, EVEN, AUTO
مفاتيح الفرز	مركب مقابل متشابك
Redshift Spectrum	استعلام بيانات S3 مباشرة
Concurrency Scaling	إضافة كتل تلقائية للذروات
AQUA	ذاكرة تخزين مؤقت معجلة بالأجهزة

سؤال المقابلة: "كيف تختار مفاتيح التوزيع في Redshift؟"

الجواب: "اختر مفتاح التوزيع بناءً على عمود الربط الأكثر تكراراً. إذا تم ربط الجداول على customer_id، كلاهما يجب أن يستخدم DISTKEY(customer_id) لوضع البيانات معاً. جداول الأبعاد الصغيرة يمكن أن تستخدم DISTSTYLE ALL للنسخ لكل العقد. تجنب انحراف البيانات—تحقق من التوزيع مع SVV_TABLE_INFO."

ضبط الأداء

-- تحقق من توزيع الجدول
SELECT "table", diststyle, sortkey1
FROM SVV_TABLE_INFO
WHERE "table" = 'fact_sales';

-- حلل ترميز الأعمدة
ANALYZE COMPRESSION fact_sales;

-- فراغ وتحليل بانتظام
VACUUM FULL fact_sales;
ANALYZE fact_sales;

مقارنة الهندسات

الجانب	Snowflake	BigQuery	Redshift
نموذج الحوسبة	مستودعات افتراضية	slots بدون خادم	كتل ثابتة
التوسع	تغيير حجم المستودع	تلقائي (أو محجوز)	تغيير حجم/مرن
نموذج التسعير	حوسبة + تخزين	بايت ممسوحة + تخزين	ساعات العقدة + تخزين
التزامن	مستودعات متعددة الكتل	عالي (قائم على slots)	طوابير WLM
مشاركة البيانات	أصلي، عبر الحسابات	عروض مصرح بها	مشاركة بيانات (أحدث)
شبه منظم	نوع VARIANT	STRUCT, ARRAY	نوع SUPER

أنماط التصميم عبر المنصات

النمط 1: التقسيم القائم على الوقت

-- Snowflake: تقسيم دقيق تلقائي + تجميع
CREATE TABLE events (
    event_id BIGINT,
    event_timestamp TIMESTAMP,
    user_id INT,
    event_type STRING
) CLUSTER BY (event_timestamp::DATE, user_id);

-- BigQuery: تقسيم صريح مطلوب
CREATE TABLE events
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id
AS SELECT ...;

-- Redshift: مفاتيح الفرز
CREATE TABLE events (
    event_id BIGINT,
    event_timestamp TIMESTAMP,
    user_id INT
)
SORTKEY (event_timestamp);

النمط 2: التحميل التدريجي

-- Snowflake: عبارة MERGE
MERGE INTO target t USING source s ON t.id = s.id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...;

-- BigQuery: MERGE مع التقسيم
MERGE target t USING source s ON t.id = s.id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...;

-- Redshift: نمط حذف + إدراج (MERGE أحدث)
BEGIN;
DELETE FROM target WHERE id IN (SELECT id FROM source);
INSERT INTO target SELECT * FROM source;
COMMIT;

النمط 3: العروض المحققة

-- كل المنصات تدعم العروض المحققة
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT
    DATE(sale_timestamp) as sale_date,
    product_id,
    SUM(amount) as total_amount,
    COUNT(*) as transaction_count
FROM fact_sales
GROUP BY DATE(sale_timestamp), product_id;

نظرة المقابلة: كن مستعداً لمناقشة المقايضات. كل مستودع يتفوق في سيناريوهات مختلفة—لا توجد منصة "أفضل" عالمياً. قدرتك على التفكير في المقايضات تُظهر تفكير المستوى الأعلى.

بعد ذلك، سنستكشف تطور data lake مقابل lakehouse. :::