ما هو Apache Iceberg؟

بالإضافة إلى مواصفات تنسيق الجدول المفتوح، يشتمل Iceberg أيضًا على مجموعة من واجهات برمجة التطبيقات والمكتبات التي تمكن محركات التخزين ومحركات الاستعلام ومحركات التنفيذ من التفاعل بسلاسة مع الجداول التي تتبع هذا التنسيق.

أصبح تنسيق جدول Iceberg جزءًا لا يتجزأ من النظام البنائي للبيانات الضخمة، ويرجع ذلك إلى حد كبير إلى قدرته على توفير وظائف لا تتوفر عادةً مع تنسيقات الجداول الأخرى. وباستخدام مجموعة البيانات الوصفية المحفوظة في كل جدول، يتيح Iceberg تطوير المخطط وتطور الأقسام والتراجع عن إصدار الجدول من دون الحاجة إلى عمليات إعادة كتابة الجداول أو ترحيلها المكلفة. فهو نظام تخزين محايد بالكامل، مع دعم لمصادر بيانات متعددة، ولا توجد تبعيات لنظام الملفات.

أنشأ جداول Iceberg في الأصل مهندسو البيانات في Netflix وApple في عام 2017 لمعالجة أوجه القصور في جداول Apache Hive، وجعلوا جداول Iceberg مفتوحة المصدر وتبرعوا بها لصالح مؤسسة Apache Software Foundation في العام التالي. وقد أصبح مشروع Apache رفيع الطراز في عام 2020.

تساعد سرعة وكفاءة وموثوقية Apache Iceberg وسهولة استخدامه بشكل عام على تبسيط وتنسيق معالجة البيانات على أي نطاق. وقد ساعدت نقاط القوة هذه على جعله تنسيق الجداول المفضل لعدد من مستودعات البيانات وبحيرات البيانات ومستودعات بحيرات البيانات الرائدة، بما في ذلك IBM® watsonx.data ومستودع Netezza وDb2 warehouse.

Iceberg هو أحد تنسيقات الجداول المفتوحة المصدر القليلة التي تمكِّن معاملات ACID: تبادل البيانات التي تحافظ على الدقة من خلال ضمان الخصائص الذرية والاتساق والعزلة والفعالية.

كانت نشأة Iceberg نتيجة محاولة لمعالجة القيود العملية لجداول Apache Hive في بيئة بحيرة بيانات كبيرة. بحسب Ryan Blue، رئيس PMC لمشروع Apache Iceberg والمهندس الأول سابقًا في Netflix: "كانت العديد من الخدمات والمحركات المختلفة تستخدم جداول Hive. لكن المشكلة كانت أننا لم نتمكن من ضمان صحة البيانات. وكما أضاف في مؤتمر عام 2021: "لم تتوفر لدينا معاملات ذرية". "في بعض الأحيان، كانت التغييرات في نظام واحد تتسبب في حصول نظام آخر على بيانات خاطئة، وهذه النوعية من المشكلات جعلتنا نتجنّب استخدام هذه الخدمات أو إجراء تغييرات على جداولنا حفاظًا على الأمان".¹

نشأ Apache Hive كوسيلة لجعل مجموعات Apache Hadoop تعمل بطريقة مشابهة لقواعد البيانات العلائقية التي يمكن الوصول إليها عبر SQL. ورغم أنه يعمل بشكل فعَّال مع البيانات الثابتة، فإنه يتكيف بصعوبة مع مجموعات البيانات المتغيرة: يجب تنسيق التغييرات يدويًا عبر التطبيقات والمستخدمين المختلفين، وإلا فقد يؤدي الأمر إلى تلف البيانات وحدوث عدم دقة في مجموعات البيانات الكبيرة.

لضمان الدقة في بيئة ديناميكية، تم تصميم Iceberg لضمان أن أي معاملة بيانات تعرض جميع خصائص ACID الأربعة:

غالبًا ما يُقارَن تنسيق جدول Apache Iceberg بتقنيتين أخريين للبيانات مفتوحة المصدر تقدمان معاملات ACID: Delta Lake، طبقة التخزين المحسَّنة التي تم إنشاؤها في الأصل باستخدام Databricks والتي توسع نطاق ملفات بيانات Parquet مع سجل المعاملات القائم على الملفات ومعالجة البيانات الوصفية القابلة للتطوير، وApache Hudi- اختصار للعبارة "Hadoop Upserts Deletes and Incrementals" - الذي طورته Uber في الأصل في عام 2016.

وفقًا لدراسة أجرتها Synvert عام 2022، تم إنشاء بيانات عشوائية وتخزينها بتنسيق JSON في حاوية AWS S3 لاستخدامها في وضع معايير للتقنيات الثلاث. وقد أظهر اختبارها في النهاية أن تنسيق جدول Iceberg المحسَّن حقق أداءً أفضل مقارنةً بأداء كلٍّ من Delta Lake وApache Hudi عبر جميع المقاييس التي تم اختبارها^.2

• التخزين: كانت أحجام الملفات الناتجة لجداول Iceberg أصغر بكثير مقارنةً بأحجام الملفات الناتجة لجداول Delta Lake أو Hudi، ما يوفر ميزة كبيرة لتحسين التخزين.
   

• عمليات الإدراج: بالنسبة إلى عمليات الإدراج، حققت جداول Iceberg أيضًا أسرع أداء وأقصر وقت تشغيل. بالإضافة إلى ذلك، كانت جداول Iceberg وDelta Lake أسرع بكثير من جداول Hudi.
   

• عمليات التحديث: بالنسبة إلى عمليات التحديث، كانت جداول Iceberg أسرع بكثير من جداول Delta Lake وHudi. والجدير بالذكر أنه على عكس نظرائها، لم يزد وقت تشغيل جداول Iceberg بشكل كبير مع العدد الإجمالي للسجلات: عند الحد الأقصى لأعباء العمل التي تم اختبارها في الدراسة -500 مليون سجل- فقد كانت جداول Iceberg أسرع بنحو 10 أضعاف مقارنةً بجداول Delta Lake.
   

• عمليات الإزالة: بالمثل، كان Iceberg أسرع بعدة أضعاف مقارنةً بالخيارين الآخرين لعمليات الإزالة.

ينفذ Iceberg تسلسلاً هرميًا ثلاثي الطبقات لملفات البيانات الوصفية لضمان صحة بيانات الجدول وتنسيقها عبر تنسيقات الملفات المتنوعة والتغييرات المستمرة.

إن جداول Iceberg المكتوبة بلغتَي Java وPython، والتي يتم تقديمها أيضًا على واجهة برمجة تطبيقات Scala، تدعم مجموعة متنوعة من تنسيقات ملفات البيانات الكبيرة، بما في ذلك Apache Parquet وApache Avro وApache ORC. فهي تقدِّم وظائف مشابهة لتلك الموجودة في جداول SQL في قواعد البيانات التقليدية بطريقة محايدة لتنسيقات الملفات ومحايدة للمورِّدين، ما يسمح بتشغيل محركات متعددة في مجموعة البيانات نفسها.

تتكون بنية جدول Iceberg من ثلاث طبقات: كتالوج Iceberg وطبقة البيانات الوصفية وطبقة البيانات.

يقع كتالوج Iceberg نفسه فوق طبقة البيانات الوصفية والبيانات لاحقًا، تمامًا مثل قمة جبل جليدي يستقر فوق سطح الماء. يقوم بتخزين مؤشرات البيانات الوصفية المحدثة (أو "الحالية") التي تعين اسم جدول معين إلى موقع ملف (ملفات) بياناته الوصفية الحالية. بالإضافة إلى الكتالوج المدمج، يدعم Iceberg أطر عمل الكتالوج الأخرى مثل Hive MetaStore أو AWS Glue.

العمليات على مستوى كتالوج Iceberg ذرية، لأن هذا ضروري لضمان صحة المعاملات الإجرائية.

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

تتضمن طبقة بيانات Iceberg الوصفية - بترتيب تنازلي - ملفات البيانات الوصفية وقوائم البيانات وملفات البيانات.

تخزِّن البيانات الوصفية للجدول، بما في ذلك مخطط الجدول ومعلومات الأقسام واللقطة الحالية ولقطات الحالات السابقة. فبعد الإشارة إلى ملف البيانات الوصفية الحالي من إدخال الجدول في كتالوج Iceberg، يستخدم محرك الاستعلام القيمة [current-snapshot-id] للعثور على إدخاله في مصفوفة [snapshots]. ومن هناك، يمكنه تحديد موقع قائمة البيانات الوصفية للجدول وفتحها.

قائمة البيان التفصيلي هي ببساطة قائمة بملفات البيان التفصيلي، إضافةً إلى معلومات مهمة لكل ملف بيانات بداخلها، مثل موقعه واللقطة المرتبط بها والأقسام التي ينتمي إليها. تتوفر بعض التحسينات ووظائف التصفية في هذه المرحلة.

تتولى ملفات البيان التفصيلي تتبُّع ملفات البيانات وما يرتبط بها من تفاصيل وبيانات وصفية وإحصاءات. يهدف هذا إلى تعزيز واحدة من المزايا الأساسية لتنسيق جدول Iceberg التي يتفوق بها على تنسيق جدول Hive: القدرة على تتبُّع البيانات على مستوى الملفات. في هذه المرحلة، يمكن استخدام قيم[file-path] لكل كائن [data-file] للبحث عن الملف وفتحه.

توجد طبقة البيانات، كما يوحي اسمها، أسفل طبقة البيانات الوصفية وتحتوي على الملفات النهائية نفسها.

يقدم Apache Iceberg عددًا من الميزات المفيدة لتحسين إدارة البيانات وتبسيطها.

يتعامل Iceberg مع جميع تفاصيل التقسيم والاستعلام في الداخل. حيث يوفر تقسيم Iceberg المخفي على المستخدمين أعمال تقديم معلومات تخطيط الأقسام عند الاستعلام عن الجداول. فلا يحتاج المستخدمون إلى الاحتفاظ بأعمدة الأقسام بأنفسهم، أو حتى فهم تخطيط الجدول الفعلي، للحصول على نتائج استعلام دقيقة.

هذا لا يجعل تقسيم Iceberg سهل الاستخدام للغاية فحسب؛ بل يسمح أيضًا بتغيير تخطيطات الأقسام بمرور الوقت دون كسر الاستعلامات المكتوبة مسبقًا. فعند تطور مواصفات الأقسام، لا تتأثر البيانات الموجودة في الجدول (والبيانات الوصفية الخاصة به). حيث يتم تقسيم البيانات الجديدة فقط، المكتوبة على الجدول بعد التطور، مع المواصفات الجديدة، ويتم الاحتفاظ بالبيانات الوصفية لهذه البيانات الجديدة بشكل منفصل.

يوفر Iceberg دعمًا أصليًا لتطوير المخطط. يسمح ذلك للمستخدمين بتعديل مخططات الجداول من دون الحاجة إلى ترحيل البيانات المعقدة، ما يسهِّل إلى حد كبير التكيف مع هياكل البيانات المتطورة.

يُتيح Iceberg للمستخدمين الرجوع عبر لقطات بياناته إلى نقاط زمنية مختلفة. ويُعَد هذا أمرًا ذا قيمة لمجموعة متنوعة من حالات الاستخدام، بما في ذلك عمليات التدقيق وتصحيح الأخطاء وفحص الامتثال.

يوفر Iceberg مجموعة من قدرات الفهرسة التي تساعد على تحسين أداء الاستعلامات، مثل خيارات الدمج لدمج الملفات الصغيرة في ملفات أكبر لتقليل عبء البيانات الوصفية، وفلاتر Bloom لتقليل قراءة البيانات غير الضرورية أثناء تنفيذ الاستعلامات.