تحليل البيانات: Athena وRedshift وGlue

التطبيق اللي خلصنا تصميمه في الجزء الثاني والعشرين يطلع بيانات كثيرة: طلبات وسجلات وأحداث. وبعدين يسألك أحد: "أي مدينة نمت أكثر هالسنة؟"

تقدر تشغّل هذا على قاعدة الإنتاج وتبطئها على عملائك. بس AWS عندها مجموعة خدمات مبنية للتحليل، وهذا الجزء دليل لها.

نوعين من الشغل #

الأسئلة اللي يسألها التطبيق تختلف عن الأسئلة اللي يسألها أصحاب القرار:

سر خدمات التحليل إنها تخزن البيانات بالأعمدة. عشان تجمع عمود واحد، ما تحتاج تقرأ الباقي:

Amazon Athena: SQL على S3 #

Athena يخليك تستعلم من ملفات S3 مباشرة بـ SQL. ما فيه شي تشغله: توصف الملفات كجدول، والبيانات تبقى مكانها.

تدفع حوالي 5 دولار لكل TB يتم مسحه، بحد أدنى 10 MB للاستعلام. وإنشاء الجداول والاستعلامات الفاشلة ما تكلف شي. ويناسب الأسئلة العابرة وتحليل السجلات، مثل سجلات موزع الحمل أو S3، وهو كمان اللي توجهك له AWS بعد ما أقفلت S3 Select على العملاء الجدد.

اقرأ أقل، وادفع أقل #

بما إن السعر يعتمد على اللي ينقرأ، القراءة الأقل تعني فاتورة أقل وجواب أسرع:

• تنسيقات الأعمدة: حوّل الملفات إلى Parquet أو ORC، فالاستعلام يقرأ أعمدته فقط.
• التقسيم (Partitions): قسّم البيانات إلى مسارات مثل year=2025/، فالاستعلام يتجاهل الباقي.
• الضغط: كل ما صغرت البيانات، قل اللي ينمسح.
• ملفات أكبر: آلاف الملفات الصغيرة تبطئ الشغل، فادمجها.

الاستعلامات الموحدة #

بياناتك مو كلها في S3؟ Federated Query يخلي Athena يوصل لمصادر ثانية مثل DynamoDB أو RDS، عبر موصل يشتغل كدالة Lambda في حسابك. واستعلام واحد يقدر يربطها مع ملفاتك كمان.

Amazon Redshift: المستودع #

لما تصير التقارير ثقيلة ومتكررة، مع ربط جداول كثير ومستخدمين كثير، تحتاج مستودع بيانات. Redshift مبني على PostgreSQL، ويخزن البيانات بالأعمدة، ويقسم الاستعلام على عدة عقد بالتوازي.

إدخال البيانات #

نقاط تستاهل تعرفها #

• Redshift Spectrum: استعلم من ملفات S3 داخل Redshift بدون تحميلها، واربطها مع جداولك.
• اللقطات: تلقائية وتزايدية، وتقدر تنسخها لمنطقة ثانية عشان تتعافى من كارثة.
• Multi-AZ: متاح في مجموعات RA3 من نوع Provisioned، بعقد في منطقتي توفر خلف نقطة وصول وحدة.

Athena أو Redshift؟ #

ابدأ بـ Athena، وانتقل لـ Redshift لما تصير استعلاماتك متكررة لدرجة تبرر تكلفته.

AWS Glue: تجهيز البيانات #

التحليل يفترض إن البيانات نظيفة ومرتبة، وهذا نادر. Glue مجموعة أدوات بدون سيرفرات لهذا الغرض:

نمط معروف: ينزل ملف في S3، وحدث يشغّل شغل Glue، ويحوله إلى Parquet في مجلد ثاني. ولاحظ إن Glue Ray Jobs أقفلت على العملاء الجدد في 30 أبريل 2026، بينما شغل Spark مستمر عادي.

وممكن تقرأ عن AWS Data Pipeline، خدمة أقدم لنقل البيانات ومعالجتها بجدول. وهي مقفلة على العملاء الجدد وفي وضع الصيانة، فاستخدم Glue أو Step Functions للشغل الجديد.

Lake Formation: صلاحيات البحيرة #

S3 مع ملفات Parquet وفهرس هو اللي يسمونه بحيرة بيانات (Data Lake). ولما تكبر، إدارة الوصول عبر سياسات الحاوية تصير صعبة، لأن S3 يعرف الملفات، مو الأعمدة.

Lake Formation يعطيك مكان واحد تمنح فيه الوصول بقاعدة البيانات والجدول والعمود وحتى الصف: فريق المبيعات يشوف الطلبات بدون أرقام البطاقات مثلاً. وهذي الصلاحيات تنطبق عبر خدمات مثل Athena وRedshift وEMR.

البحث والشغل الكبير واللوحات #

OpenSearch #

قاعدة البيانات شاطرة في الجلب بالمفتاح. OpenSearch شاطر في البحث بأي كلمة في أي حقل، وفي تحليل السجلات. ويجي كـ مجموعات مُدارة تتحكم في أحجامها، أو Serverless للحمل المتغير.

وغالباً يكون نسخة من بياناتك، مو المصدر. نمطين معروفين:

• بحث على جدول: DynamoDB Streams ثم Lambda ثم OpenSearch. تبحث هناك، ثم تجيب العنصر كامل من الجدول.
• تحليل السجلات: CloudWatch Logs ثم Firehose ثم OpenSearch.

Amazon EMR #

عندك شغل Spark أو Hadoop قائم؟ EMR يشغله، وتقدر تختار تشغيله على EC2 أو EKS أو كـ Serverless. وعلى EC2 فيه ثلاث أنواع من العقد:

Quick Sight #

Amazon Quick Sight يبني لوحات متابعة من Athena وRedshift وRDS وS3 وغيرها. كان اسمه QuickSight، ومن أكتوبر 2025 صار جزء من مجموعة أوسع اسمها Amazon Quick، مع إن الـ API لسا يستخدم الاسم القديم.

• SPICE: محرك في الذاكرة يخلي اللوحات سريعة، بدون ما يضغط على المصدر مع كل مشاهدة.
• Analysis أو Dashboard: تعدل في الـ Analysis، وتنشره كـ Dashboard للقراءة فقط.
• أمان الصفوف: كل مدير يشوف بيانات منطقته فقط.

التيارات: Flink وKafka #

Kinesis وFirehose يوصلون البيانات. طيب لو تبي تحللها وقت وصولها، مثل كشف نمط مشبوه خلال ثواني؟

Managed Service for Apache Flink (اسمه القديم Kinesis Data Analytics) يشغّل تطبيقات Flink تقرأ من تيار Kinesis أو من MSK، بدون ما تدير المجموعة.

Amazon MSK هو Apache Kafka مُدار، أشهر منصة تيارات في عالم المصادر المفتوحة. ويجي كمجموعات Provisioned بوسطاء Standard أو Express، أو كـ Serverless.

كيف توصل البيانات؟ #

اختيار طريق الإدخال يبدأ من كم مرة توصل البيانات، وكم حجمها:

وأمّن كل طريق بنفس الأسلوب: أدوار IAM بأقل صلاحية، وتشفير أثناء النقل والتخزين، وطرق خاصة مثل VPC Endpoints بدل الإنترنت العام لما تقدر.

الصورة الكاملة #

هذا كيف تجتمع القطع في مسار معتاد:

عملي: Parquet يقلل اللي يقرأه الاستعلام #

بنولّد ملف فيه 200,000 طلب ونسأله نفس السؤال مرتين. من CloudShell:

BUCKET=series-data-$RANDOM$RANDOM
aws s3 mb s3://$BUCKET

awk 'BEGIN {
  srand(7)
  split("Riyadh Jeddah Dammam Abha Tabuk", city, " ")
  for (i = 1; i <= 200000; i++)
    printf "%d,%s,%d,%.2f\n", i, city[int(rand()*5)+1], 2024+int(rand()*3), rand()*500
}' > sales.csv

head -3 sales.csv
aws s3 cp sales.csv s3://$BUCKET/raw/sales.csv

هذي الدالة تشغّل استعلام وتنتظره، ثم تطبع حالته والبايتات اللي مسحها ونتيجته:

run_sql() {
  ID=$(aws athena start-query-execution --query-string "$1" \
    --result-configuration OutputLocation=s3://$BUCKET/results/ \
    --query QueryExecutionId --output text)
  while true; do
    STATE=$(aws athena get-query-execution --query-execution-id $ID \
      --query QueryExecution.Status.State --output text)
    [ "$STATE" = QUEUED ] || [ "$STATE" = RUNNING ] || break
    sleep 1
  done
  aws athena get-query-execution --query-execution-id $ID \
    --query "QueryExecution.[Status.State,Statistics.DataScannedInBytes]" \
    --output text
  aws athena get-query-results --query-execution-id $ID \
    --query "ResultSet.Rows[*].Data[*].VarCharValue" --output text
}

صف الملف كجدول. ما ينتقل شي، والبيانات تبقى في S3:

run_sql "CREATE DATABASE series_data"

run_sql "CREATE EXTERNAL TABLE series_data.sales_csv (
  order_id INT, city STRING, year INT, amount DOUBLE
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION 's3://$BUCKET/raw/'"

اسأل السؤال:

run_sql "SELECT city, ROUND(SUM(amount)) AS total
FROM series_data.sales_csv WHERE year = 2025
GROUP BY city ORDER BY total DESC"

يطلع لك المجموع لكل مدينة، وأول سطر يبين إن الملف كله انمسح، أكثر من 5 MB بشوي، مع إن السؤال يخص سنة وحدة وعمودين. الحين أنشئ نسخة Parquet مقسمة باستعلام واحد:

run_sql "CREATE TABLE series_data.sales_parquet WITH (
  format = 'PARQUET',
  external_location = 's3://$BUCKET/parquet/',
  partitioned_by = ARRAY['year']
) AS SELECT order_id, city, amount, year FROM series_data.sales_csv"

aws s3 ls s3://$BUCKET/parquet/

بتشوف مجلد لكل سنة. اسأل نفس السؤال من الجدول الجديد:

run_sql "SELECT city, ROUND(SUM(amount)) AS total
FROM series_data.sales_parquet WHERE year = 2025
GROUP BY city ORDER BY total DESC"

الأرقام نفسها، بس البايتات الممسوحة جزء صغير من الرقم الأول. وعلى التيرابايتات، هذا الفرق هو فاتورتك.

run_sql "DROP TABLE series_data.sales_parquet"
run_sql "DROP TABLE series_data.sales_csv"
run_sql "DROP DATABASE series_data"
aws s3 rb s3://$BUCKET --force

الخلاصة #

• افصل التحليل عن قاعدة الإنتاج، وخزن البيانات بالأعمدة.
• Athena يستعلم من S3 بدون سيرفرات، وParquet والتقسيم يقللون تكلفته.
• Redshift للتقارير الثقيلة والمتكررة، وServerless بداية سهلة.
• Glue يفهرس بياناتك ويحولها، وLake Formation يحدد من يشوف أي عمود.
• OpenSearch للبحث، وEMR لشغل Spark، وQuick Sight للوحات، وFlink وMSK للتيارات.

اختبر نفسك #

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

الحين فهمت البيانات اللي عندك. تقدر تطلع منها أكثر، مثل قراءة المستندات وفهم الكلام وتوليد النصوص؟ في الجزء الرابع والعشرين نمر على خدمات الذكاء الاصطناعي الجاهزة في AWS.