معماريات البث: Kafka و Kinesis والبث الحدثي — مقابلات هندسة البيانات: SQL والأنابيب وأنظمة البيانات الضخمة — Nerd Level Tech

فهم معماريات البث ضروري لأدوار هندسة البيانات الحديثة. يغطي هذا الدرس Apache Kafka و AWS Kinesis والمفاهيم الأساسية لأنظمة البيانات المدفوعة بالأحداث.

أساسيات البث الحدثي

المعالجة الدفعية مقابل البث

الجانب	المعالجة الدفعية	معالجة البث
الكمون	ساعات إلى أيام	ميلي ثانية إلى ثواني
البيانات	مجموعات بيانات محدودة	تدفق مستمر غير محدود
المعالجة	مرة لكل دفعة	مستمرة
الحالة	عادة بدون حالة	مع حالة
حالات الاستخدام	ETL، التقارير، تدريب ML	تحليلات الوقت الحقيقي، التنبيه، اكتشاف الاحتيال

نموذج البيانات المتدفقة

+----------+     +---------+     +------------+     +----------+
| المصادر  | --> | وسيط    | --> | محرك      | --> | المخرجات |
| (أحداث)  |     | الرسائل |     | المعالجة  |     |          |
+----------+     +---------+     +------------+     +----------+
                     |
                     v
              سجل أحداث دائم
              ومرتب

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

الأحداث: حقائق غير قابلة للتغيير حدثت في نقطة زمنية
المنتجون: التطبيقات التي تنشر الأحداث
المستهلكون: التطبيقات التي تشترك وتعالج الأحداث
المواضيع/التدفقات: فئات أو تغذيات الأحداث
الأقسام: تقسيمات فرعية للتوازي والترتيب

Apache Kafka بالتفصيل

معمارية Kafka

+------------------+     +------------------+     +------------------+
|    Producer 1    |     |    Producer 2    |     |    Producer 3    |
+--------+---------+     +--------+---------+     +--------+---------+
         |                        |                        |
         +------------------------+------------------------+
                                  |
                                  v
         +------------------------------------------------+
         |              Kafka Cluster                      |
         |  +--------+  +--------+  +--------+            |
         |  |Broker 1|  |Broker 2|  |Broker 3|            |
         |  +--------+  +--------+  +--------+            |
         |                                                 |
         |  Topic: orders (3 أقسام, RF=3)                 |
         |  +--------+  +--------+  +--------+            |
         |  |  P0    |  |  P1    |  |  P2    |            |
         |  |Leader  |  |Leader  |  |Leader  |            |
         |  +--------+  +--------+  +--------+            |
         +------------------------------------------------+
                                  |
         +------------------------+------------------------+
         |                        |                        |
         v                        v                        v
+--------+---------+     +--------+---------+     +--------+---------+
|   Consumer 1     |     |   Consumer 2     |     |   Consumer 3     |
| (القسم 0)        |     | (القسم 1)        |     | (القسم 2)        |
+------------------+     +------------------+     +------------------+
         |________________________|________________________|
                      Consumer Group: order-processors

سؤال المقابلة: "اشرح ضمانات الديمومة والترتيب في Kafka"

نموذج الإجابة:

"يوفر Kafka ضمانات قوية للديمومة والترتيب:

الديمومة:

الرسائل تُحفظ على القرص قبل التأكيد
عامل النسخ (RF) يحدد عدد النسخ الموجودة
مع RF=3 و acks=all، البيانات تنجو من فقدان وسيطين
ISR (النسخ المتزامنة) يضمن أن النسخ المحدثة فقط يمكنها أن تصبح قائدة

ضمانات الترتيب:

داخل القسم: ترتيب صارم مضمون (الرسائل تُعالج بترتيب الإزاحة)
عبر الأقسام: لا ضمان للترتيب
للحفاظ على الترتيب للأحداث المرتبطة، استخدم نفس مفتاح القسم

مثلاً، لضمان ترتيب جميع أحداث العميل:

# جميع الرسائل بنفس customer_id تذهب لنفس القسم
producer.send('orders',
              key=customer_id.encode(),
              value=order_data)
```"

### تكوين منتج Kafka

```python
from confluent_kafka import Producer

producer_config = {
    'bootstrap.servers': 'broker1:9092,broker2:9092',

    # إعدادات الديمومة
    'acks': 'all',                      # انتظر جميع نسخ ISR
    'retries': 3,                       # أعد المحاولة عند الفشل العابر
    'retry.backoff.ms': 100,

    # ضبط الأداء
    'batch.size': 16384,                # تجميع الرسائل (بايت)
    'linger.ms': 5,                     # انتظر امتلاء الدفعة
    'buffer.memory': 33554432,          # 32MB buffer
    'compression.type': 'snappy',       # ضغط الدفعات

    # مرة واحدة بالضبط
    'enable.idempotence': True,
    'transactional.id': 'my-transactional-producer'
}

producer = Producer(producer_config)

سؤال المقابلة: "كيف تعمل مجموعات المستهلكين في Kafka؟"

نموذج الإجابة:

"مجموعات المستهلكين تمكّن المعالجة المتوازية والتحمل للأخطاء:

تعيين الأقسام:

كل قسم يُعيّن لمستهلك واحد بالضبط في المجموعة
إذا المستهلكون < الأقسام: بعض المستهلكين يتعاملون مع أقسام متعددة
إذا المستهلكون > الأقسام: المستهلكون الزائدون خاملون
الأمثل: المستهلكون = الأقسام لأقصى توازي

إعادة التوازن:

تُفعّل عند انضمام/مغادرة المستهلكين أو تغيير الأقسام
المنسق يعيد توزيع الأقسام بين المستهلكين
أثناء إعادة التوازن، المعالجة تتوقف (يؤثر على التوفر)"

AWS Kinesis

مقارنة Kinesis مقابل Kafka

الجانب	Apache Kafka	AWS Kinesis
النشر	مُدار ذاتياً أو مُدار	مُدار بالكامل
الاحتفاظ	قابل للتكوين (غير محدود)	24 ساعة افتراضي، حتى 365 يوم
التقسيم	Partitions	Shards
الترتيب	لكل قسم	لكل Shard
التوسع	إضافة أقسام (لا رجعة)	تقسيم/دمج Shards
التسعير	تكلفة البنية التحتية	لكل shard-hour + البيانات
النظام البيئي	Kafka Connect, KSQL	Firehose, Analytics

سؤال المقابلة: "متى تستخدم Kinesis Data Firehose مقابل Data Streams؟"

نموذج الإجابة:

"الاختيار يعتمد على متطلبات المعالجة:

استخدم Kinesis Data Firehose عندما:

تحتاج توصيل بدون كود لـ S3، Redshift، Elasticsearch، أو Splunk
قرب الوقت الحقيقي مقبول (كمون 1-5 دقائق)
تريد توسع تلقائي بدون إدارة shards
التحويلات البسيطة (Lambda) كافية

استخدم Kinesis Data Streams عندما:

تحتاج كمون أقل من ثانية
منطق معالجة مخصص مطلوب
مستهلكون متعددون يحتاجون قراءة نفس التدفق
تحتاج قدرة إعادة التشغيل
معالجة تدفق معقدة مع Kinesis Data Analytics"

أنماط المعمارية المدفوعة بالأحداث

Event Sourcing

CRUD التقليدي:
+-------------+
|   Orders    |  <- الحالة الحالية فقط
| id | amount |
+----+--------+
| 1  | 150.00 |  <- لا تاريخ للتغييرات
+----+--------+

Event Sourcing:
+------------------------------------------+
|              Order Events                |
| event_id | order_id | type     | payload |
+----------+----------+----------+---------+
| E1       | O1       | Created  | $100    |
| E2       | O1       | Updated  | $150    |
| E3       | O1       | Shipped  | ...     |
+------------------------------------------+

الفوائد:

مسار تدقيق كامل
يمكن إعادة بناء الحالة في أي نقطة
يدعم الاستعلامات الزمنية
يمكّن إعادة تشغيل الأحداث للتصحيح

سؤال المقابلة: "صمم نظام اكتشاف احتيال في الوقت الحقيقي"

نموذج الإجابة:

"سأصمم هذا باستخدام معمارية بث:

المكونات:

استيعاب الأحداث:

المعاملات --> Kafka Topic: transactions
                 (مقسم بـ user_id للترتيب)

معالجة التدفق (Flink/Kafka Streams):

# قواعد اكتشاف الاحتيال
rules = [
    # القاعدة 1: فحص السرعة
    lambda events: len(events) > 10,  # >10 معاملات في النافذة

    # القاعدة 2: شذوذ المبلغ
    lambda events: max(e.amount for e in events) > 5 * avg_amount,
]

محرك القرار:

+-----------+     +----------+     +------------+
| محرك      | --> | تسجيل    | --> | القرار     |
| القواعد   |     | نموذج ML |     | (حظر/      |
| (سريع)    |     | (دقيق)   |     |  علم/مرر) |
+-----------+     +----------+     +------------+

هدف الكمون: <100ms من المعاملة للقرار"

النقاط الرئيسية للمقابلات

اعرف الأساسيات: المنتجون، المستهلكون، المواضيع، الأقسام، مجموعات المستهلكين
افهم ضمانات الترتيب: الأقسام تمكّن الترتيب، وليس المواضيع
دلالات التوصيل: مرة واحدة على الأكثر، مرة واحدة على الأقل، مرة واحدة بالضبط
Kafka مقابل البدائل المُدارة: متى تستخدم Kafka مقابل Kinesis مقابل Pub/Sub
أنماط مدفوعة بالأحداث: Event sourcing، CQRS، ومتى تطبقها

:::