اختر تنسيق جدول البيانات

مكتمل

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

يدعم Azure Databricks عدة صيغ تخزين، كل منها مصمم لسيناريوهات مختلفة. فهم اختلافاتهم يساعدك على اختيار التنسيق المناسب لمتطلباتك الخاصة.

فهم تنسيقات الملفات مقابل تنسيقات الجداول

قبل مقارنة الخيارات، من المهم التمييز بين تنسيقات الملفات وصيغ الجداول. تنسيق ملف مثل Parquet أو CSV أو JSON يحدد كيفية تخزين البيانات فعليا على القرص. تنسيق الجدول مثل Delta Lake أو Apache Iceberg يبني فوق تنسيقات الملفات بإضافة طبقة بيانات وصفية تتبع المعاملات وتغييرات المخطط ومواقع ملفات البيانات.

كل من دلتا ليك وأباتشي آيسبرغ يستخدمان باركيه كصيغة ملفاتهما الأساسية. الفرق الرئيسي يكمن في طبقة البيانات الوصفية التي تمكن الميزات المتقدمة مثل معاملات ACID، والسفر عبر الزمن، وتطور المخطط.

كيف يخزن باركيه البيانات بشكل مختلف

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

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

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

يوفر هذا النهج العمودي تقنيتين للتحسين تحسنان بشكل كبير في أداء التحليلات:

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

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

دلتا ليك كصيغة افتراضية

Delta Lake هو تنسيق التخزين الافتراضي لجميع الجداول في Azure Databricks. عندما تنشئ جدولا دون تحديد تنسيق، يستخدم Azure Databricks تلقائيا Delta Lake.

Delta Lake توسع ملفات Parquet بسجل معاملات يسجل كل تغيير في جدولك. يتيح هذا السجل عدة قدرات لا يوفرها باركيه وحده:

• معاملات ACID: يمكن لعدة قراء وكتاب متزامنين الوصول إلى نفس الجدول دون تلف البيانات. كل معاملة إما تكتمل بالكامل أو لا تؤثر عليها.

• السفر عبر الزمن: استعلام الإصدارات السابقة من جدولك باستخدام الطوابع الزمنية أو أرقام الإصدارات. قم بالتراجع عن التغييرات إذا لزم الأمر.

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

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

تتكامل Delta Lake بعمق مع منصة Azure Databricks. تعتمد ميزات مثل تجميع السوائل، والتحسين التنبؤي،وتغذية بيانات التغيير على سجل معاملات دلتا ليك.

بالنسبة لمعظم السيناريوهات في Azure Databricks، Delta Lake هو الخيار الموصى به. يوفر فوائد الأداء لباركيه مع ضمانات معاملية تتطلبها أنظمة بيانات الإنتاج.

Apache Iceberg للسيناريوهات عبر المنصات

Apache Iceberg هو تنسيق جدول مفتوح بديل يدعمه Azure Databricks للجداول المدارة والجداول الأجنبية. مثل دلتا ليك، يوفر آيسبرغ معاملات ACID، وتطوير المخططات، وقدرات السفر عبر الزمن مبنية فوق ملفات باركيه.

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

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

يمكن لكتالوج Unity إدارة جداول آيسبرغ مباشرة، مما يسمح ل Azure Databricks بالعمل ككتالوج لمحركات Iceberg الخارجية. يمكنك أيضا قراءة جداول آيسبرغ التي تديرها كتالوجات أخرى مثل AWS Glue أو Snowflake Horizon Catalog من خلال اتصالات الجداول الأجنبية.

فكر في جبل الجليد عندما:

• يجب الوصول إلى بياناتك بواسطة عدة محركات معالجة خارج Azure Databricks.
• منظمتك قامت بتوحيد معايير Iceberg لمشاركة البيانات عبر المنصات.
• أنت تندمج مع أنظمة لا تدعم دلتا ليك.

بالنسبة لأعباء العمل التي تعمل بشكل أساسي داخل Azure Databricks، تظل Delta Lake هي التنسيق الموصى به بسبب تكامل المنصات الأعمق وميزات التحسين.

عندما تطبق الصيغ القائمة على الصفوف

تظل CSV وJSON خيارات صالحة لسيناريوهات محددة، رغم أنهما أقل كفاءة في التحليلات واسعة النطاق.

استخدم CSV أو JSON عندما:

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

لتخزين البيانات التحليلية بشكل مستمر، قم بتحويل ملفات CSV أو JSON الواردة إلى جداول Delta Lake أثناء الاستيعاب. هذا التحويل يلتقط مكاسب الكفاءة من التخزين العمودي مع إضافة ضمانات معاملاتية.

تطبيق معايير القرار

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

Consideration	بحيرة دلتا	جبل الجليد الأباتشي	CSV/JSON
أداء التحليلات	ممتاز	ممتاز	رديء
معاملات ACID	‏‏نعم‬	‏‏نعم‬	لا
السفر عبر الزمن	‏‏نعم‬	‏‏نعم‬	لا
Azure Databricks integration	عميق	Supported	Basic
التوافق بين المنصات	النمو	واسع	يونيفرسال
موصى به للإنتاج	‏‏نعم‬	نعم (عند الحاجة إلى إجراء داخلي)	لا (منطقة هبوط فقط)

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