كتالوجات الجليد: دليل لمهندسي البيانات

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

ما هي فهرس Iceberg؟

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

المسؤوليات الأساسية لفهرس Iceberg

المسؤوليات الأساسية لفهرس Iceberg هي:

1. ربط مسارات الجدول: ربط مسار الجدول (على سبيل المثال، “db.table”) بملف البيانات الوصفية المقابل.
2. دعم العمليات الذرية: ضمان حالة الجدول المتسقة أثناء القراءة/الكتابة المتزامنة.
3. إدارة البيانات الوصفية: تخزين وإدارة البيانات الوصفية، مع ضمان الوصول والاتساق.

تقدم كتالوجات آيسبرغ تطبيقات متنوعة لاستيعاب هياكل الأنظمة المختلفة ومتطلبات التخزين. دعونا نستعرض هذه التطبيقات وملاءمتها للبيئات المختلفة.

أنواع كتالوجات آيسبرغ

1. كتالوج هادوب

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

مثال على التكوين

لتكوين كتالوج هادوب مع أباتشي سبارك:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \

  --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.type=hadoop \

  --conf spark.sql.catalog.my_catalog.warehouse=file:///D:/sparksetup/iceberg/spark_warehouse

طريقة مختلفة لتعيين الكتالوج في وظيفة سبارك نفسها:

SparkConf sparkConf = new SparkConf()

        .setAppName("Example Spark App")

        .setMaster("local[*]")

        .set("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions")

        .set("spark.sql.catalog.local","org.apache.iceberg.spark.SparkCatalog")

        .set("spark.sql.catalog.local.type","hadoop")

        .set("spark.sql.catalog.local.warehouse", "file:///D:/sparksetup/iceberg/spark_warehouse")

في المثال أعلاه، قمنا بتعيين اسم الكتالوج إلى “محلي” كما هو محدد في سبارك “spark.sql.catalog.محلي“. يمكن أن يكون هذا اختيارًا لاسمك.

الإيجابيات:

• إعداد بسيط، لا حاجة لمدير بيانات خارجي.
• مثالي لبيئات التطوير والاختبار.

السلبيات:

• محدود بنظام ملفات واحد (مثل، دلو S3 واحد).
• غير موصى به للإنتاج

2. كتالوج هايڤ

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

مثال على التكوين

لاستخدام كتالوج Hive في Spark:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \

  --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.type=hive \

  --conf spark.sql.catalog.my_catalog.uri=thrift://<metastore-host>:<port>

الإيجابيات:

• توافق عالي مع أدوات البيانات الكبيرة القائمة.
• مستقل عن السحابة ومرن عبر التثبيتات الخاصة والسحابية.

السلبيات:

• يتطلب الحفاظ على مخزن Hive، مما قد يزيد من تعقيد العمليات.
• يفتقر إلى دعم عمليات الجدول المتعددة، مما يقيد الذرية للعمليات عبر الجداول.

3. كتالوج AWS Glue

كتالوج AWS Glue هو كتالوج بيانات وصفية مُدار يقدمه AWS، مما يجعله مثاليًا للمؤسسات المستثمرة بشكل كبير في بيئة AWS. يتعامل مع بيانات الجدول Iceberg كخصائص الجدول ضمن AWS Glue، مما يسمح بالتكامل السلس مع خدمات AWS الأخرى.

مثال على التكوين

لإعداد AWS Glue مع Iceberg في Spark:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x,software.amazon.awssdk:bundle:x.xx.xxx \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog \

  --conf spark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO \

  --conf spark.hadoop.fs.s3a.access.key=$AWS_ACCESS_KEY \

  --conf spark.hadoop.fs.s3a.secret.key=$AWS_SECRET_ACCESS_KEY

الإيجابيات:

• خدمة مُدارة، مما يقلل من تكاليف البنية التحتية والصيانة.
• تكامل قوي مع خدمات AWS.

السلبيات:

• خاص بـ AWS، مما يقيد المرونة بين السحاب.
• لا يدعم عمليات الجدول المتعددة

4. كتالوج Nessie المشروع.

يقدم مشروع Nessie نهج “البيانات كشفرة”، مما يسمح بالتحكم في إصدارات البيانات. من خلال قدرات التفرع والوسم المشابهة لـ Git، يمكن لـ Nessie للمستخدمين إدارة فروع البيانات بطريقة مشابهة لشفرة المصدر. يوفر إطار قوي للمعاملات متعددة الجداول والعبارات.

مثال على التكوين

لتكوين Nessie كفهرس:

spark-sql --packages "org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x" \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.nessie.NessieCatalog \

  --conf spark.sql.catalog.my_catalog.uri=http://<host>:<port>

الإيجابيات:

• يوفر وظائف “البيانات كشفرة” مع التحكم في الإصدارات.
• يدعم معاملات متعددة الجداول.

السلبيات:

• يتطلب الاستضافة الذاتية، مما يزيد من تعقيد البنية التحتية.
• الدعم المحدود بالمقارنة مع Hive أو AWS Glue

5. كتالوج JDBC

يسمح كتالوج JDBC بتخزين البيانات الوصفية في أي قاعدة بيانات تتوافق مع JDBC، مثل PostgreSQL أو MySQL. يعتبر هذا الفهرس متعدد السحابة ويضمن التوفرية العالية من خلال استخدام أنظمة RDBMS الموثوقة.

مثال على التكوين

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x \

  --conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \

  --conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.jdbc.JdbcCatalog \

  --conf spark.sql.catalog.my_catalog.uri=jdbc:<protocol>://<host>:<port>/<database> \

  --conf spark.sql.catalog.my_catalog.jdbc.user=<username> \

  --conf spark.sql.catalog.my_catalog.jdbc.password=<password>

الإيجابيات:

• سهل الإعداد مع البنية التحتية الحالية لقواعد البيانات RDBMS.
• توفرية عالية ومتعددة السحابة.

السلبيات:

• لا يدعم معاملات متعددة الجداول.
• زيادة الاعتماد على تعريفات JDBC لجميع أدوات الوصول

6. كتالوج Snowflake

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

الإيجابيات:

• التكامل السلس: يجمع بين أداء Snowflake وقدرات الاستعلام مع تنسيق الجدول المفتوح لـ Iceberg، مما يسهل إدارة البيانات بشكل فعال.
• دعم كامل للمنصة: يوفر وصولًا شاملًا للقراءة والكتابة، بالإضافة إلى ميزات مثل معاملات ACID، وتطور المخطط، والسفر عبر الزمن.
• صيانة مبسطة: تتولى Snowflake مهام دورة الحياة مثل الضغط وتقليل الأعباء التشغيلية.

السلبيات:

• قيود السحابة والمنطقة: يجب أن يكون الحجم الخارجي في نفس مزود السحابة والمنطقة مثل حساب Snowflake، مما يحد من التكوينات عبر السحابة أو عبر المنطقة.
• حدود تنسيق البيانات: يدعم فقط تنسيق ملف Apache Parquet، والذي قد لا يتوافق مع جميع تفضيلات تنسيق البيانات التنظيمية.
• قيود العملاء من الأطراف الثالثة: يمنع العملاء من الأطراف الثالثة من تعديل البيانات في جداول Iceberg المدارة بواسطة Snowflake، مما قد يؤثر على سير العمل الذي يعتمد على الأدوات الخارجية.

7. الكتالوجات المستندة إلى REST

يدعم Iceberg الكتالوجات المستندة إلى REST لمعالجة العديد من التحديات المرتبطة بتنفيذ الكتالوجات التقليدية.

التحديات مع الكتالوجات التقليدية

1. تعقيد على جانب العميل: غالبًا ما تتطلب الكتالوجات التقليدية تكوينات واعتماديات على جانب العميل لكل لغة (Java، Python، Rust، Go)، مما يؤدي إلى عدم التناسق عبر لغات البرمجة ومحركات المعالجة المختلفة. اقرأ المزيد عن ذلك هنا.
2. قيود القابلية للتوسع: يمكن أن يؤدي إدارة البيانات الوصفية وعمليات الجدول على مستوى العميل إلى ظهور اختناقات، مما يؤثر على الأداء وقابلية التوسع في بيئات البيانات الكبيرة.

فوائد اعتماد كتالوج REST

• تكامل مبسط للعميل: يمكن للعملاء التفاعل مع كتالوج REST باستخدام بروتوكولات HTTP القياسية، مما يلغي الحاجة إلى تكوينات معقدة أو اعتماديات.
• قابلية التوسع: تسمح بنية كتالوج REST على جانب الخادم بإدارة بيانات وصفية قابلة للتوسع، مما يتناسب مع مجموعات البيانات المتزايدة وأنماط الوصول المتزامنة.
• المرونة: يمكن للمؤسسات تنفيذ منطق الفهرس المخصص على الجانب الخادم، مخصصًا فهرس REST لتلبية المتطلبات المحددة دون تعديل تطبيقات العميل.

ظهرت عدة تنفيذات لفهرس REST، كل منها يلبي احتياجات تنظيمية محددة:

• Gravitino: خدمة فهرس REST مفتوحة المصدر تسهل التكامل مع Spark ومحركات المعالجة الأخرى، وتقدم إعدادًا مباشرًا لإدارة جداول Iceberg.
• Tabular: خدمة مُدارة توفر واجهة فهرس REST، تمكن المؤسسات من استغلال إمكانيات Iceberg دون تكلفة إدارة بنية الفهرس. اقرأ المزيد على Tabular.
• Apache Polaris: فهرس مفتوح المصدر ومتكامل بالكامل لـ Apache Iceberg، ينفذ واجهة برمجة تطبيقات REST لضمان توافق متعدد المحركات بسلاسة عبر منصات مثل Apache Doris وApache Flink وApache Spark وStarRocks وTrino. اقرأ المزيد على GitHub.

أحد الطرق المفضلة لدي والبسيطة لتجربة فهرس REST مع جداول Iceberg هي استخدام تنفيذ REST بسيط بلغة Java. يرجى التحقق من الرابط على GitHub هنا.

الاستنتاج

اختيار الكتالوج المناسب لـ Apache Iceberg أمر بالغ الأهمية لتحسين استراتيجية إدارة البيانات الخاصة بك. إليك نظرة عامة مختصرة لتوجيه قرارك:

• كتالوج Hadoop: مناسب بشكل أفضل لبيئات التطوير والاختبار بسبب بساطته. ومع ذلك، قد تواجه مشاكل في التناسق في سيناريوهات الإنتاج مع الكتابات المتزامنة.
• كتالوج Hive Metastore: هذا مثالي للمنظمات التي لديها بنية تحتية موجودة لـ Hive. يوفر التوافق مع مجموعة واسعة من أدوات البيانات الكبيرة ويدعم عمليات البيانات المعقدة. ومع ذلك، فإن الحفاظ على خدمة Hive Metastore يمكن أن يضيف تعقيدًا تشغيليًا.
• كتالوج AWS Glue: هذا هو الأنسب للأشخاص الذين استثمروا بشكل كبير في نظام AWS البيئي. يوفر تكاملًا سلسًا مع خدمات AWS ويقلل من الحاجة إلى خدمات بيانات التعريف المدارة ذاتيًا. ومع ذلك، فهو خاص بـ AWS، مما قد يحد من مرونة التغيير بين السحابات.
• كتالوج JDBC: مناسب للبيئات التي تفضل قواعد البيانات العلائقية لتخزين بيانات التعريف، مما يسمح باستخدام أي قاعدة بيانات متوافقة مع JDBC. وهذا يوفر مرونة ويستفيد من بنية RDBMS الموجودة ولكن قد يقدم تبعيات إضافية ويتطلب إدارة دقيقة لاتصالات قاعدة البيانات.
• كتالوج REST: هذا مثالي للسيناريوهات التي تتطلب واجهة برمجة تطبيقات موحدة لعمليات الكتالوج، مما يعزز التشغيل البيني عبر محركات المعالجة واللغات المتنوعة. يفصل تفاصيل تنفيذ الكتالوج عن العملاء ولكن يتطلب إعداد خدمة REST للتعامل مع عمليات الكتالوج، مما قد يضيف تعقيدًا في الإعداد الأولي.
• كتالوج مشروع نيسي: هذا مثالي للمنظمات التي تحتاج إلى التحكم في الإصدارات على بياناتها، مشابه لـ Git. يدعم التفرع، والتوسيم، والمعاملات متعددة الجداول. يوفر قدرات قوية في إدارة البيانات ولكنه يتطلب نشر وإدارة خدمة نيسي، مما قد يضيف عبئًا تشغيليًا.

فهم خيارات الكتالوج هذه وتكويناتها سيمكنك من اتخاذ قرارات مستنيرة وتحسين إعداد بحيرة البيانات أو بحيرة المنزل لتلبية احتياجات منظمتك المحددة.