إزالة ملفات البيانات غير المستخدمة باستخدام فراغ

يمكنك إزالة ملفات البيانات التي لم تعد مشار إليها بواسطة جدول Delta أقدم من حد الاستبقاء عن طريق تشغيل VACUUM الأمر على الجدول. يعد التشغيل VACUUM بانتظام أمرا مهما للتكلفة والتوافق بسبب الاعتبارات التالية:

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

حد الاستبقاء الافتراضي لملفات البيانات بعد التشغيل VACUUM هو 7 أيام. لتغيير هذا السلوك، راجع تكوين استبقاء البيانات لاستعلامات السفر عبر الوقت.

توصي Databricks باستخدام التحسين التنبؤي للتشغيل VACUUM تلقائيا لجداول Delta. راجع التحسين التنبؤي ل Delta Lake.

تستخدم بعض ميزات Delta Lake ملفات بيانات التعريف لوضع علامة على البيانات على أنها محذوفة بدلا من إعادة كتابة ملفات البيانات. يمكنك استخدام REORG TABLE ... APPLY (PURGE) لتنفيذ عمليات الحذف هذه وإعادة كتابة ملفات البيانات. راجع حذف بيانات التعريف فقط لفرض إعادة كتابة البيانات.

هام

• في Databricks Runtime 13.3 LTS وما فوق، VACUUM تختلف دلالات النسخ الضحلة مع الجداول المدارة كتالوج Unity عن جداول Delta الأخرى. راجع نسخ كتالوج فراغ وUnity الضحلة.
• VACUUM إزالة كافة الملفات من الدلائل التي لم تتم إدارتها بواسطة Delta Lake، مع تجاهل الدلائل التي تبدأ ب _ أو .. إذا كنت تقوم بتخزين بيانات تعريف إضافية مثل نقاط التحقق Structured Streaming داخل دليل جدول Delta، فاستخدم اسم دليل مثل _checkpoints.
  • تتم إدارة بيانات موجز بيانات التغيير بواسطة Delta Lake في _change_data الدليل وإزالتها باستخدام VACUUM. راجع استخدام موجز بيانات تغيير Delta Lake على Azure Databricks.
  • تستخدم فهارس عامل تصفية _delta_index Bloom الدليل الذي تديره Delta Lake. VACUUM تنظيف الملفات في هذا الدليل. راجع فهارس عامل تصفية Bloom.
• يتم فقدان القدرة على الاستعلام عن إصدارات الجدول الأقدم من فترة الاستبقاء بعد تشغيل VACUUM.
• يتم حذف ملفات السجل تلقائيا وبشكل غير متزامن بعد عمليات نقطة التحقق ولا تخضع ل VACUUM. بينما تكون فترة الاستبقاء الافتراضية لملفات السجل 30 يوما، فإن التشغيل VACUUM على جدول يزيل ملفات البيانات الضرورية للسفر عبر الوقت.

إشعار

عند تمكين التخزين المؤقت للقرص، قد تحتوي المجموعة على بيانات من ملفات Parquet التي تم حذفها باستخدام VACUUM. لذلك، قد يكون من الممكن الاستعلام عن بيانات إصدارات الجدول السابقة التي تم حذف ملفاتها. ستؤدي إعادة تشغيل نظام المجموعة إلى إزالة البيانات المخزنة مؤقتا. راجع تكوين ذاكرة التخزين المؤقت للقرص.

مثال على بناء الجملة للتفريغ

VACUUM eventsTable   -- vacuum files not required by versions older than the default retention period

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable DRY RUN    -- do dry run to get the list of files to be deleted

للحصول على تفاصيل بناء جملة Spark SQL، راجع فراغ.

راجع وثائق واجهة برمجة تطبيقات Delta Lake لتفاصيل بناء جملة Scala وJava وPython.

إشعار

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

حذف بيانات التعريف فقط لفرض إعادة كتابة البيانات

REORG TABLE يوفر الأمر بناء الجملة APPLY (PURGE) لإعادة كتابة البيانات لتطبيق الحذف المبدئي. لا تعيد عمليات الحذف المبدئي كتابة البيانات أو تحذف ملفات البيانات، بل تستخدم ملفات بيانات التعريف للإشارة إلى أن بعض قيم البيانات قد تغيرت. راجع جدول REORG.

تتضمن العمليات التي تنشئ عمليات حذف مبدئي في Delta Lake ما يلي:

• إسقاط الأعمدة مع تمكين تعيين العمود.
• حذف الصفوف مع تمكين متجهات الحذف .
• أي تعديلات للبيانات على أنظمة المجموعات التي تدعم Photon عند تمكين متجهات الحذف.

مع تمكين الحذف المبدئي، قد تظل البيانات القديمة موجودة فعليا في الملفات الحالية للجدول حتى بعد حذف البيانات أو تحديثها. لإزالة هذه البيانات فعليا من الجدول، أكمل الخطوات التالية:

1. شغّل REORG TABLE ... APPLY (PURGE). بعد القيام بذلك، لم تعد البيانات القديمة موجودة في الملفات الحالية للجدول، ولكنها لا تزال موجودة في الملفات القديمة المستخدمة للسفر عبر الزمن.
2. قم بتشغيل VACUUM لحذف هذه الملفات القديمة.

REORG TABLE ينشئ إصدارا جديدا من الجدول مع اكتمال العملية. تشير جميع إصدارات الجدول في المحفوظات قبل هذه المعاملة إلى ملفات البيانات القديمة. من الناحية المفاهيمية، يشبه OPTIMIZE هذا الأمر، حيث تتم إعادة كتابة ملفات البيانات على الرغم من أن البيانات في إصدار الجدول الحالي تظل متسقة.

هام

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

ما حجم نظام المجموعة الذي يحتاجه الفراغ؟

لتحديد حجم نظام المجموعة الصحيح ل VACUUM، فإنه يساعد على فهم أن العملية تحدث على مرحلتين:

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

لتحسين التكلفة والأداء، توصي Databricks بما يلي، خاصة بالنسبة لوظائف الفراغ طويلة الأمد:

• قم بتشغيل فراغ على نظام مجموعة مع تعيين التحجيم التلقائي ل 1-4 عمال، حيث يحتوي كل عامل على 8 ذاكرات أساسية.
• حدد برنامج تشغيل به ما بين 8 و32 نواة. قم بزيادة حجم برنامج التشغيل لتجنب أخطاء نفاد الذاكرة (OOM).

إذا كانت VACUUM العمليات تحذف بانتظام أكثر من 10 آلاف ملف أو تستغرق أكثر من 30 دقيقة من وقت المعالجة، فقد تحتاج إلى زيادة حجم برنامج التشغيل أو عدد العمال.

إذا وجدت أن التباطؤ يحدث أثناء تحديد الملفات المراد إزالتها، أضف المزيد من العقد العاملة. إذا حدث التباطؤ أثناء تشغيل أوامر الحذف، فحاول زيادة حجم برنامج التشغيل.

ما مدى تكرار تشغيل الفراغ؟

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

لماذا لا يمكنك تفريغ جدول Delta بحد استبقاء منخفض؟

تحذير

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

لدى Delta Lake فحص أمان لمنعك من تشغيل أمر خطير VACUUM . إذا كنت متأكدا من عدم وجود عمليات يتم تنفيذها على هذا الجدول تستغرق وقتا أطول من الفاصل الزمني للاحتفاظ الذي تخطط لتحديده، يمكنك إيقاف تشغيل فحص الأمان هذا عن طريق تعيين خاصية spark.databricks.delta.retentionDurationCheck.enabled تكوين Spark إلى false.

معلومات التدقيق

VACUUM تحتوي عمليات التثبيت في سجل معاملات Delta على معلومات التدقيق. يمكنك الاستعلام عن أحداث التدقيق باستخدام DESCRIBE HISTORY.