مشكلة قفل البيانات التي عرّفت بصمت بيئة السحابة المتعددة
تقاربت استراتيجية السحابة المؤسسية نحو تعدد السحابة: 87٪ من المؤسسات تُشغّل الآن أحمال عمل عبر مزودي سحابة متعددين، وفقاً لتقرير Flexera 2025 State of the Cloud. لكن تعدد السحابة عملياً لم يُحقق الاستقلالية عن المورد والتحكم في التكاليف التي وعد بها. المؤسسات التي تستخدم سحابات متعددة تهدر بمتوسط 28٪ أكثر من الشركات أحادية السحابة، وإجمالي تكلفة ملكية تعدد السحابة عادةً ضعف ما تُقدّره الفرق، وفقاً لـ LeanOps Technology.
السبب الرئيسي هو ثقل البيانات. بمجرد تخزين مجموعات بيانات كبيرة في سحابة واحدة — في AWS S3 أو Google Cloud Storage أو Azure Blob — ينطوي نقلها على تكاليف egress تتراكم بمرور الوقت. تفرض AWS رسوم 0.09 دولار/جيجابايت خارجاً، وتفرض GCP رسوماً بين 0.08 و0.12 دولار/جيجابايت حسب الوجهة. شركة تُزامن 500 جيجابايت ليلاً بين AWS وGCP تتكبد حوالي 45 دولاراً يومياً في رسوم egress — أكثر من 16,000 دولار سنوياً على pipeline واحد.
السبب الثاني هو تشرذم التنسيقات. تُخزّن AWS البيانات محسَّنةً لخدماتها، وBigQuery من Google لها تنسيق تخزين خاص بها، وتُقدم خدمات كل منصة تنسيقات جداول ملكية تجعل الاستعلامات عبر السحابة معقدة تقنياً.
Apache Iceberg — تنسيق جداول مفتوح يُخزّن البيانات في ملفات Parquet قياسية مع طبقة بيانات وصفية مفتوحة — هو الاستجابة المعمارية لكلا المشكلتين في آنٍ واحد.
ما أعلنته Google ولماذا يهم
أعلنت Google عن مجموعة من القدرات المرتبطة بـ Iceberg في Cloud Next 2026:
Cross-Cloud Lakehouse (الإعلان #57): Cross-Cloud Lakehouse من Google — المعروف سابقاً بـ BigLake — مدعوم الآن بـ Iceberg REST Catalog يُمكّن الوكلاء وأحمال التحليلات من “الوصول بسلاسة إلى البيانات عبر AWS وAzure ونظام بيئي واسع من الشركاء”.
تخزين Iceberg المُدار وREST Catalog (الإعلان #61): تُوفر Google إدارة تلقائية ومعاملات متعددة الجداول على جداول Iceberg، مع قابلية التشغيل البيني للقراءة/الكتابة عبر BigQuery وApache Spark والمحركات مفتوحة المصدر. هذا يُزيل الحاجة إلى خطوط أنابيب ETL المعقدة لدمج البيانات قبل الاستعلام.
اتحاد كتالوج Lakehouse (الإعلان #58): مشاركة بيانات بدون نسخ عبر AWS Glue وDatabricks وSnowflake — مما يعني أن Google يمكنها استعلام البيانات مباشرةً في كتالوجات تلك الأنظمة دون استيراد أو نسخ.
التخزين المؤقت عبر السحابة (الإعلان #62): ذاكرة تخزين مؤقت ذكية تُخزّن البيانات عبر السحابة عند أول قراءة وتُخفض رسوم egress للاستعلامات اللاحقة لبيانات AWS وAzure.
محرك Lightning لـ Apache Spark (الإعلان #59): تحسين بنسبة تصل إلى 2x في نسبة السعر إلى الأداء مقارنةً بالبدائل الملكية في السوق لأحمال عمل Spark.
إعلان
ما يجب على مهندسي البيانات ورؤساء فرق البيانات فعله
1. توحيد جميع تعريفات الجداول الجديدة على Apache Iceberg فوراً
يخلق تقارب Google وAWS وAzure على Iceberg قاعدة معمارية واضحة لعام 2026: يجب أن تستخدم أي جدول بيانات جديد أو pipeline أو طبقة تخزين Iceberg افتراضياً. الفرق التي تستمر في إنشاء جداول بتنسيقات ملكية تراكم دين قفل سيكلف أكثر لمعالجته في 2027 مما يتطلبه جهد التوحيد على Iceberg اليوم.
2. تحديد فاتورة egress السنوية قبل تصميم أي بنية معمارية عبر السحابة
رقم 16,000 دولار سنوياً لـ pipeline واحد بسعة 500 جيجابايت ليلياً ليس حالة أسوأ — بل هو حالة تمثيلية لفريق بيانات متوسط الحجم. قبل تصميم أي بنية معمارية للبيانات عبر السحابة، احسب تكلفة egress صراحةً. نموذج تكلفة AWS (0.09 دولار/جيجابايت خارجاً)، وGCP (0.08-0.12 دولار/جيجابايت)، وAzure (متغير حسب المنطقة) تتراكم كلها على نطاق pipeline.
3. اعتماد الاتحاد بدون نسخ للاستعلامات التحليلية عبر المزودين
قدرة اتحاد كتالوج Lakehouse المُعلن عنها في Google Cloud Next 2026 — التي تُتيح المشاركة بدون نسخ عبر AWS Glue وDatabricks وSnowflake — هي أكثر القدرات قابلية للتنفيذ فوراً للقضاء على تنقل البيانات غير الضروري في التحليلات متعددة السحابة. الاتحاد بدون نسخ يعني الاستعلام عن جدول في AWS Glue من BigQuery دون تحريك ملفات Parquet الأساسية — فقط نتيجة الاستعلام تعبر الشبكة، لا مجموعة البيانات.
4. إعادة التفاوض على اتفاقيات التخزين السحابي باستخدام قابلية نقل Iceberg كرافعة تفاوضية
الانعكاس التجاري لتوحيد Iceberg هو أن اتفاقيات التخزين السحابي قابلة للتفاوض الآن بطرق لم تكن ممكنة من قبل. عندما تُخزَّن البيانات بتنسيق ملكي لا يمكن لأدوات مورد واحد فقط قراءته بكفاءة، تكلفة التحويل تكون ذات قيمة لا تُحدّ. عندما تُخزَّن البيانات في Iceberg على ملفات Parquet قياسية، تكلفة التحويل محدودة. استخدم هذه التكلفة المحدودة كأساس لإعادة التفاوض على تسعير التخزين وإعفاءات رسوم egress مع مزوديك الرئيسيين.
أين يقع هذا في نظام البيانات البيئي 2026
تقارب Iceberg في Google Cloud Next 2026 ليس إعلاناً معزولاً — إنه الاستجابة البنيوية للمؤسسات لمشكلة تراكمت خمس سنوات. اعتمدت المؤسسات تعدد السحابة للمرونة والامتثال التنظيمي والوصول إلى القدرات. واكتشفت أن تعدد السحابة عملياً يُنتج تشرذم البيانات وتكاليف egress وتعقيداً تحليلياً تتجنبه بنى السحابة الواحدة.
التأثير العملي لإعلانات Cloud Next 2026 هو أن الاستعلام التحليلي عبر السحابة — تشغيل استعلام يمس بيانات في AWS وGoogle Cloud وDatabricks في آنٍ واحد — ينتقل من مشروع هندسي مكلف إلى قدرة منصة قياسية. بالنسبة لمهندسي البيانات في 2026، الوضعية الاستراتيجية واضحة: التوحيد على Iceberg، وإزالة تنقل البيانات غير الضروري عبر الاتحاد والتخزين المؤقت، وتحديد فاتورة egress، واستخدام قابلية نقل Iceberg كرافعة تجارية مع مزودي السحابة.
الأسئلة الشائعة
ما هو Apache Iceberg وكيف يختلف عن تنسيقات جداول البيانات الأخرى؟
Apache Iceberg تنسيق جداول مفتوح لمجموعات البيانات التحليلية الكبيرة يُخزّن البيانات في ملفات Parquet قياسية مع طبقة بيانات وصفية مفتوحة. على عكس التنسيقات الملكية كجداول BigQuery الأصلية أو Delta Lake (التنسيق الافتراضي لـ Databricks)، يمكن قراءة جداول Iceberg وكتابتها بأي محرك متوافق — Spark وTrino وFlink وDuckDB ومحركات الاستعلام لـ AWS وGoogle Cloud وAzure — دون موصلات ملكية.
ما هي التكلفة السنوية الفعلية لنقل البيانات عبر السحابة ومدى أهميتها؟
تفرض AWS رسوماً 0.09 دولار/جيجابايت للبيانات الخارجة، وتفرض Google Cloud رسوماً بين 0.08 و0.12 دولار/جيجابايت حسب الوجهة. شركة تُزامن 500 جيجابايت ليلاً بين AWS وGCP تتكبد حوالي 45 دولاراً يومياً — أكثر من 16,000 دولار سنوياً لـ pipeline واحد. للمؤسسات التي تمتلك 10-20 pipeline نشطاً عبر السحابة، يمكن أن تتجاوز تكاليف egress السنوية 100,000-200,000 دولار. تُصنَّف هذه التكاليف غالباً تحت “الشبكات” في فواتير السحابة وتُقدَّر بشكل منهجي أقل مما هي عليه.
هل يتطلب اعتماد Apache Iceberg ترحيل البيانات الموجودة؟
ليس فوراً. يدعم Apache Iceberg الاعتماد التدريجي — يمكنك البدء بإنشاء جداول جديدة بتنسيق Iceberg مع إبقاء الجداول الحالية بتنسيقها الحالي. أدوات الترحيل يمكنها تحويل الجداول القائمة على Parebox إلى تنسيق Iceberg بأقل توقف ممكن. التوصية العملية هي توحيد جميع تعريفات الجداول الجديدة على Iceberg فوراً وجدولة ترحيل مرحلي للجداول ذات الحركة العالية خلال الـ 12 شهراً القادمة.
—
المصادر والقراءات الإضافية
🔗 مقالات ذات صلة
ثورة Data Lakehouse: كيف يعيد Apache Iceberg وDelta Lake تشكيل بنية البيانات
حروب السحابة في عصر الذكاء الاصطناعي: AWS مقابل Azure مقابل GCP في سباق أحمال العمل
صعود السحابة المتعددة: استراتيجية أم هروب من الارتباط بمزوّد واحد؟
AWS وGoogle Cloud يجعلان السحابة المتعددة حقيقة: ما الذي تغيره صفقة الربط البيني
