دليل اختبار AWS Data Engineer

📋 نظرة عامة على الاختبار

170 دقيقة

مدة الاختبار

85 سؤال

تقريباً

750/1000

درجة النجاح

$150

رسوم الاختبار

🎯 المجالات الرئيسية

استيعاب البيانات وتحويلها (34%) - أكبر نسبة في الاختبار
تخزين البيانات وإدارتها (26%)
العمليات والدعم (22%)
أمان البيانات والحوكمة (18%)

💡 نصيحة مهمة: ركز على السيناريوهات العملية والحالات الواقعية. الاختبار يركز على كيفية حل المشاكل أكثر من الحفظ النظري.

📚 الخدمات الأساسية المطلوبة

Amazon S3 - التخزين الأساسي
AWS Glue - ETL وإدارة البيانات
Amazon Kinesis - البيانات المتدفقة
Amazon Redshift - مستودع البيانات
AWS Lambda - الحوسبة بدون خادم
Amazon EMR - معالجة البيانات الكبيرة
AWS Step Functions - تنسيق سير العمل
Amazon Athena - الاستعلام المباشر

📥 استيعاب البيانات

🌊 Amazon Kinesis

يستخدم لاستيعاب البيانات المتدفقة في الوقت الفعلي (Real-time Streaming)

سيناريو عملي:

لديك تطبيق يولد ملايين السجلات يومياً من أجهزة IoT. كيف تستوعب هذه البيانات؟

الحل: استخدم Kinesis Data Streams لاستقبال البيانات، ثم Kinesis Data Firehose لتحميلها تلقائياً إلى S3

                        # مثال: إرسال بيانات إلى Kinesis
                        kinesis.put_record(
                            StreamName='sensor-data-stream',
                            Data=json.dumps(sensor_data),
                            PartitionKey=device_id
                        )
                    

أنواع Kinesis:

Data Streams: تدفق مخصص، تحكم كامل
Data Firehose: تحميل تلقائي للوجهات (S3, Redshift)
Data Analytics: تحليل فوري بـ SQL

📦 AWS Database Migration Service (DMS)

لنقل البيانات من قواعد البيانات إلى AWS

سيناريو عملي:

شركة تريد نقل قاعدة بيانات MySQL إلى Redshift مع استمرار التزامن

الحل: DMS مع CDC (Change Data Capture) للتزامن المستمر

📨 Amazon MSK (Managed Streaming for Kafka)

بديل لـ Kinesis، يستخدم Apache Kafka

أفضل للأنظمة التي تستخدم Kafka مسبقاً
دعم أكبر للـ connectors
مزيد من التحكم في التكوين

🎯 نقاط مهمة للاختبار:

Kinesis للبيانات البسيطة والسريعة
MSK عند الحاجة لتوافق Kafka
DMS للنقل من قواعد البيانات
AWS DataSync لنقل الملفات الكبيرة

💾 تخزين البيانات

🪣 Amazon S3

القلب النابض لأي نظام بيانات في AWS

فئات التخزين Storage Classes:

S3 Standard: للوصول المتكرر
S3 Intelligent-Tiering: تنقل تلقائي حسب الاستخدام
S3 Glacier: للأرشفة طويلة المدى (رخيص جداً)

سيناريو عملي:

لديك بيانات تاريخية نادراً ما تحتاجها، كيف توفر التكلفة؟

الحل: استخدم S3 Lifecycle Policies لنقل البيانات تلقائياً إلى Glacier بعد 90 يوم

                        # تنظيم البيانات بـ Partitioning
                        s3://bucket/year=2024/month=01/day=15/data.parquet
                        # يسرع الاستعلامات بشكل كبير
                    

🏢 Amazon Redshift

مستودع البيانات (Data Warehouse) للتحليلات الضخمة

متى تستخدم Redshift:

تحليلات معقدة على بيانات منظمة
استعلامات SQL على petabytes من البيانات
تقارير الأعمال (BI)

أفضل الممارسات:

استخدم Distribution Keys لتوزيع البيانات بكفاءة
Sort Keys لترتيب البيانات وتسريع الاستعلامات
Compression لتقليل حجم التخزين
COPY من S3 بدلاً من INSERT لأداء أفضل

🗃️ AWS Lake Formation

بناء وإدارة Data Lake بسهولة

إدارة الصلاحيات المركزية
فهرسة تلقائية للبيانات
تنظيف وتحويل البيانات

⚡ نصيحة للاختبار: افهم متى تستخدم S3 vs Redshift vs DynamoDB. S3 للتخزين الرخيص والمرن، Redshift للتحليلات المعقدة، DynamoDB للوصول السريع جداً.

⚙️ معالجة البيانات

🔄 AWS Glue

خدمة ETL بدون خادم (Serverless)

مكونات Glue الأساسية:

Glue Crawler: يكتشف البيانات تلقائياً ويبني Data Catalog
Glue Jobs: وظائف ETL بلغة Python أو Scala
Glue Data Catalog: metadata store مركزي
Glue DataBrew: تنظيف البيانات بدون كود

سيناريو عملي:

لديك ملفات CSV في S3 وتريد تحويلها إلى Parquet وتحميلها في Redshift

الحل:

Glue Crawler لفهرسة ملفات CSV
Glue Job للتحويل من CSV إلى Parquet
COPY من S3 إلى Redshift

                        # مثال Glue Job
                        datasource = glueContext.create_dynamic_frame.from_catalog(
                            database="my_database",
                            table_name="raw_data"
                        )
                        
                        # تحويل البيانات
                        transformed = datasource.apply_mapping([
                            ("id", "int", "customer_id", "int"),
                            ("name", "string", "customer_name", "string")
                        ])
                        
                        # كتابة إلى S3 بصيغة Parquet
                        glueContext.write_dynamic_frame.from_options(
                            frame=transformed,
                            connection_type="s3",
                            connection_options={"path": "s3://bucket/output/"},
                            format="parquet"
                        )
                    

🐘 Amazon EMR

معالجة البيانات الكبيرة باستخدام Hadoop, Spark, Hive

متى تستخدم EMR:

معالجة بيانات ضخمة جداً (Big Data)
عند الحاجة لـ Spark أو Hadoop
Machine Learning على نطاق واسع
وظائف معقدة لا يدعمها Glue

EMR vs Glue - كيف تختار؟

استخدم Glue عندما: تحتاج حل سريع وبسيط، بدون إدارة infrastructure

استخدم EMR عندما: تحتاج تحكم كامل، أو تطبيقات Spark معقدة

⚡ AWS Lambda

معالجة البيانات الخفيفة والسريعة

رد فعل تلقائي على الأحداث (Event-driven)
معالجة بسيطة وسريعة
تشغيل كود بدون إدارة servers

مثال: تحويل تلقائي عند رفع ملف

عند رفع ملف JSON إلى S3، Lambda تقرأه وتحوله وتحفظه في bucket آخر

🎯 للاختبار: Glue للـ ETL العام، EMR للبيانات الضخمة والمعقدة، Lambda للمهام الخفيفة والسريعة

🎼 تنسيق سير العمل

🔀 AWS Step Functions

تنسيق سير العمل المعقد بصورة مرئية

الميزات الرئيسية:

سير عمل مرئي (Visual Workflow)
معالجة الأخطاء وإعادة المحاولة
تنسيق عدة خدمات AWS
Parallel Execution للأداء

سيناريو: Pipeline معقد

Lambda تتحقق من وجود ملفات جديدة في S3
Glue Job يعالج البيانات
Lambda تتحقق من جودة البيانات
إذا نجح: تحميل في Redshift
إذا فشل: إرسال إشعار SNS

الحل: Step Functions تنسق كل هذه الخطوات مع معالجة الأخطاء

📊 Amazon MWAA (Managed Apache Airflow)

Apache Airflow مُدار من AWS

متى تستخدم Airflow:

فريقك يستخدم Airflow بالفعل
تحتاج DAGs معقدة
جدولة متقدمة
مراقبة وتتبع دقيق

⏰ Amazon EventBridge

ربط التطبيقات عبر الأحداث

جدولة الأحداث (Cron Jobs)
ربط خدمات AWS ببعضها
Event-driven architecture

                        # جدولة Glue Job يومياً عند الساعة 2 صباحاً
                        Rate: cron(0 2 * * ? *)
                        Target: Glue Job
                    

💡 اختيار الأداة المناسبة:
Step Functions: للتنسيق البسيط والمرئي
MWAA: للـ pipelines معقدة ومتطلبات متقدمة
EventBridge: للجدولة والأحداث البسيطة

🔒 الأمان والحوكمة

🛡️ IAM (Identity and Access Management)

أساس الأمان في AWS

المفاهيم الأساسية:

IAM Roles: لمنح الصلاحيات للخدمات
IAM Policies: تعريف الصلاحيات بـ JSON
Least Privilege: أقل صلاحيات ممكنة

سيناريو: Lambda تقرأ من S3

Lambda تحتاج IAM Role مع Policy تسمح بـ s3:GetObject فقط على bucket محدد

                        {
                          "Effect": "Allow",
                          "Action": "s3:GetObject",
                          "Resource": "arn:aws:s3:::my-bucket/*"
                        }
                    

🔐 تشفير البيانات

في السكون (At Rest):

S3: SSE-S3, SSE-KMS, SSE-C
Redshift: KMS encryption
RDS: Encryption بـ KMS

أثناء النقل (In Transit):

SSL/TLS لكل الاتصالات
HTTPS endpoints

👁️ المراقبة والتدقيق

CloudWatch:

Metrics للأداء
Logs للتتبع
Alarms للتنبيهات

CloudTrail:

سجل لكل API call
من فعل ماذا ومتى
ضروري للامتثال (Compliance)

أفضل الممارسات:

فعّل CloudTrail على جميع المناطق
أرسل logs إلى S3 مع Glacier للأرشفة
استخدم CloudWatch Alarms للتنبيه على الأنشطة المشبوهة

🏷️ AWS Lake Formation Security

إدارة صلاحيات Data Lake بشكل مركزي

Column-level security
Row-level security
صلاحيات موحدة عبر Glue, Athena, Redshift

🔍 Amazon Macie

اكتشاف البيانات الحساسة تلقائياً

يكتشف PII (معلومات شخصية)
يفحص S3 buckets
تنبيهات عند وجود بيانات حساسة غير محمية

🎯 نقاط مهمة للاختبار:

استخدم KMS لتشفير البيانات الحساسة
فعّل CloudTrail دائماً للتدقيق
Lake Formation للصلاحيات المعقدة
VPC Endpoints لتأمين الاتصالات
S3 Bucket Policies + IAM = Defense in Depth

🎬 سيناريوهات عملية شائعة

📊 السيناريو 1: Data Lake إلى Data Warehouse

المشكلة:

شركة لديها ملايين الملفات CSV في S3، يريدون تحليلها في Redshift مع أداء عالي

الحل الأمثل:

Glue Crawler: فهرسة البيانات في Data Catalog
Glue ETL Job: تحويل CSV إلى Parquet مع Partitioning
تنظيم البيانات: year=2024/month=01/day=15/
Redshift COPY: تحميل البيانات بكفاءة عالية

لماذا Parquet؟

حجم أصغر بـ 75% من CSV
أداء استعلام أسرع بـ 10x
Columnar format مناسب للتحليلات

⚡ السيناريو 2: Real-time Analytics

المشكلة:

تطبيق e-commerce يحتاج تحليل فوري لسلوك المستخدمين

Architecture:

Kinesis Data Streams: استقبال الأحداث
Lambda: معالجة فورية وإثراء البيانات
Kinesis Data Firehose: تجميع وتحميل إلى S3
Kinesis Data Analytics: تحليل SQL فوري
QuickSight: لوحات تحكم مباشرة

# مثال: Lambda تثري البيانات
def lambda_handler(event, context):
    for record in event['Records']:
        payload = base64.b64decode(record['kinesis']['data'])
        data = json.loads(payload)
        
        # إثراء البيانات
        data['timestamp'] = datetime.now().isoformat()
        data['user_segment'] = get_user_segment(data['user_id'])
        
        return {'statusCode': 200}
                        

🔄 السيناريو 3: CDC للتزامن المستمر

المشكلة:

قاعدة بيانات production تحتاج تزامن مستمر مع Data Lake

الحل:

DMS: مع CDC enabled
S3: كوجهة للبيانات
Glue: معالجة التغييرات
Lake Formation: إدارة الصلاحيات

فوائد CDC:

لا يؤثر على أداء production
تزامن شبه فوري
تتبع جميع التغييرات (INSERT, UPDATE, DELETE)

🧹 السيناريو 4: تنظيف وجودة البيانات

المشكلة:

بيانات متسخة: قيم فارغة، تكرارات، تنسيقات مختلفة

الأدوات:

Glue DataBrew: تنظيف بدون كود (No-code)
Glue Data Quality: قواعد جودة تلقائية
Lambda: للتحققات المخصصة

# مثال: قاعدة Data Quality في Glue
Completeness "email" > 0.95  # 95% من السجلات تحتوي email
Uniqueness "user_id" = 1.0   # user_id فريد 100%
ColumnValues "age" between 0 and 120
                        

💰 السيناريو 5: تحسين التكلفة

المشكلة:

فاتورة AWS مرتفعة جداً، كيف نخفضها؟

الحلول:

S3 Lifecycle: نقل البيانات القديمة إلى Glacier (توفير 80%)
Redshift Pause/Resume: إيقاف في أوقات عدم الاستخدام
Spot Instances: لـ EMR (توفير 70%)
Glue Job Bookmarks: معالجة البيانات الجديدة فقط
Athena Partitioning: تقليل البيانات المفحوصة

💡 نصيحة ذهبية: استخدم AWS Cost Explorer لتحديد أكبر مصادر التكلفة، وركز عليها أولاً

🎯 نصائح النجاح في الاختبار

📝 استراتيجية الإجابة

اقرأ السؤال مرتين: غالباً تفاصيل مهمة في نهاية السؤال
ابحث عن الكلمات المفتاحية: "real-time", "cost-effective", "serverless", "minimal operations"
استبعد الإجابات الخاطئة أولاً: عادة 2 من 4 واضحة أنها خاطئة
إدارة الوقت: 2 دقيقة لكل سؤال تقريباً، لا تتوقف طويلاً

🔑 كلمات مفتاحية ومعانيها

"Real-time" أو "Streaming" → Kinesis, MSK
"Serverless" → Glue, Lambda, Athena
"Cost-effective" → S3, Glue, Athena (ادفع حسب الاستخدام)
"Minimal operational overhead" → Managed Services (Glue, MWAA)
"Complex transformations" → EMR Spark
"SQL queries on S3" → Athena
"Data Warehouse" → Redshift
"NoSQL" → DynamoDB
"Change Data Capture" → DMS with CDC

⚠️ أخطاء شائعة

❌ لا تفعل:

استخدام EMR عندما يكفي Glue (over-engineering)
تخزين بيانات حساسة في S3 بدون تشفير
COPY من DynamoDB إلى Redshift مباشرة (استخدم S3 كوسيط)
Kinesis Data Streams للبيانات التي لا تحتاج real-time

✅ افعل:

استخدم Parquet للتحليلات (أسرع وأرخص)
Partition البيانات حسب التاريخ
تفعيل compression على Redshift
استخدام Glue Data Catalog كـ metadata store موحد

🎓 مصادر التحضير

AWS Skill Builder: دورة رسمية مجانية
AWS Whitepapers: خاصة Data Analytics ones
Practice Exams: من AWS أو TutorialsDojo
Hands-on Labs: احصل على Free Tier وجرب
AWS Documentation: اقرأ Best Practices

📊 جدول المراجعة النهائية

الخدمة	متى تستخدمها	متى لا تستخدمها
Glue	ETL عام، serverless	معالجات معقدة جداً
EMR	Big Data، Spark معقد	مهام بسيطة
Kinesis	Real-time streaming	Batch processing
Athena	استعلام ad-hoc على S3	استعلامات متكررة معقدة
Redshift	Data Warehouse، BI	OLTP، transactions

🎯 النصيحة الأخيرة: الاختبار يركز على السيناريوهات العملية أكثر من الحفظ. فكر دائماً: "ما الحل الأبسط والأكثر كفاءة من حيث التكلفة؟"

🌟 بالتوفيق في الاختبار!

تذكر: الممارسة العملية أهم من الحفظ النظري