إزالة ملفات البيانات غير المستخدمة باستخدام فراغ
يعمل VACUUM
التحسين التنبؤي تلقائيا على الجداول المدارة في كتالوج Unity. توصي Databricks بتمكين التحسينات التنبؤية لجميع الجداول المدارة في كتالوج Unity لتبسيط صيانة البيانات وتقليل تكاليف التخزين. راجع التحسين التنبؤي للجداول المدارة لكتالوج Unity.
يمكنك إزالة ملفات البيانات التي لم تعد مشار إليها بواسطة جدول Delta أقدم من حد الاستبقاء عن طريق تشغيل VACUUM
الأمر على الجدول. يعد التشغيل VACUUM
بانتظام أمرا مهما للتكلفة والتوافق بسبب الاعتبارات التالية:
- يؤدي حذف ملفات البيانات غير المستخدمة إلى تقليل تكاليف التخزين على السحابة.
- قد تحتوي ملفات البيانات التي تمت إزالتها بواسطة
VACUUM
على سجلات تم تعديلها أو حذفها. تضمن إزالة هذه الملفات نهائيا من التخزين السحابي عدم إمكانية الوصول إلى هذه السجلات.
حد الاستبقاء الافتراضي لملفات البيانات بعد التشغيل VACUUM
هو 7 أيام. لتغيير هذا السلوك، راجع تكوين استبقاء البيانات لاستعلامات السفر عبر الوقت.
VACUUM
قد تترك وراءها دلائل فارغة بعد إزالة جميع الملفات من داخلها. تحذف العمليات اللاحقة VACUUM
هذه الدلائل الفارغة.
توصي Databricks باستخدام التحسين التنبؤي للتشغيل VACUUM
تلقائيا لجداول Delta. راجع التحسين التنبؤي للجداول المدارة لكتالوج Unity.
تستخدم بعض ميزات 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.
- تتم إدارة بيانات موجز بيانات التغيير بواسطة Delta Lake في
- يتم فقدان القدرة على الاستعلام عن إصدارات الجدول الأقدم من فترة الاستبقاء بعد تشغيل
VACUUM
. - يتم حذف ملفات السجل تلقائيا وبشكل غير متزامن بعد عمليات نقطة التحقق ولا تخضع ل
VACUUM
. بينما تكون فترة الاستبقاء الافتراضية لملفات السجل 30 يوما، فإن التشغيلVACUUM
على جدول يزيل ملفات البيانات الضرورية للسفر عبر الوقت.
ملاحظة
عند تمكين التخزين المؤقت للقرص، قد تحتوي المجموعة على بيانات من ملفات Parquet التي تم حذفها باستخدام VACUUM
. لذلك، قد يكون من الممكن الاستعلام عن بيانات إصدارات الجدول السابقة التي تم حذف ملفاتها. ستؤدي إعادة تشغيل نظام المجموعة إلى إزالة البيانات المخزنة مؤقتا. راجع تكوين ذاكرة التخزين المؤقت للقرص.
VACUUM table_name -- vacuum files not required by versions older than the default retention period
VACUUM table_name RETAIN 100 HOURS -- vacuum files not required by versions more than 100 hours old
VACUUM table_name 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 عند تمكين متجهات الحذف.
مع تمكين الحذف المبدئي، قد تظل البيانات القديمة موجودة فعليا في الملفات الحالية للجدول حتى بعد حذف البيانات أو تحديثها. لإزالة هذه البيانات فعليا من الجدول، أكمل الخطوات التالية:
- شغّل
REORG TABLE ... APPLY (PURGE)
. بعد القيام بذلك، لم تعد البيانات القديمة موجودة في الملفات الحالية للجدول، ولكنها لا تزال موجودة في الملفات القديمة المستخدمة للسفر عبر الزمن. - قم بتشغيل
VACUUM
لحذف هذه الملفات القديمة.
REORG TABLE
ينشئ إصدارا جديدا من الجدول مع اكتمال العملية. تشير جميع إصدارات الجدول في المحفوظات قبل هذه المعاملة إلى ملفات البيانات القديمة. من الناحية المفاهيمية، يشبه OPTIMIZE
هذا الأمر، حيث تتم إعادة كتابة ملفات البيانات على الرغم من أن البيانات في إصدار الجدول الحالي تظل متسقة.
هام
يتم حذف ملفات البيانات فقط عند انتهاء صلاحية الملفات وفقا VACUUM
لفترة الاستبقاء. وهذا يعني أنه VACUUM
يجب إجراء بتأخير بعد REORG
بحيث تكون الملفات القديمة قد انتهت صلاحيتها. يمكن تقليل فترة VACUUM
الاستبقاء لتقصير وقت الانتظار المطلوب، على حساب تقليل الحد الأقصى للمحفوظات التي يتم الاحتفاظ بها.
لتحديد حجم نظام المجموعة الصحيح ل VACUUM
، فإنه يساعد على فهم أن العملية تحدث على مرحلتين:
- تبدأ المهمة باستخدام كافة عقد المنفذ المتوفرة لسرد الملفات في الدليل المصدر بالتوازي. تتم مقارنة هذه القائمة بجميع الملفات المشار إليها حاليا في سجل معاملات Delta لتحديد الملفات المراد حذفها. يجلس السائق الخاما خلال هذا الوقت.
- ثم يصدر برنامج التشغيل أوامر الحذف لكل ملف ليتم حذفه. حذف الملف هو عملية برنامج تشغيل فقط، ما يعني أن جميع العمليات تحدث في عقدة واحدة بينما تكون العقد العاملة الخامة.
لتحسين التكلفة والأداء، توصي Databricks بما يلي، خاصة بالنسبة لوظائف الفراغ طويلة الأمد:
- قم بتشغيل فراغ على نظام مجموعة مع تعيين التحجيم التلقائي ل 1-4 عمال، حيث يحتوي كل عامل على 8 ذاكرات أساسية.
- حدد برنامج تشغيل به ما بين 8 و32 نواة. قم بزيادة حجم برنامج التشغيل لتجنب أخطاء نفاد الذاكرة (OOM).
إذا كانت VACUUM
العمليات تحذف بانتظام أكثر من 10 آلاف ملف أو تستغرق أكثر من 30 دقيقة من وقت المعالجة، فقد تحتاج إلى زيادة حجم برنامج التشغيل أو عدد العمال.
إذا وجدت أن التباطؤ يحدث أثناء تحديد الملفات المراد إزالتها، أضف المزيد من العقد العاملة. إذا حدث التباطؤ أثناء تشغيل أوامر الحذف، فحاول زيادة حجم برنامج التشغيل.
توصي Databricks بالتشغيل VACUUM
بانتظام على جميع الجداول لتقليل تكاليف تخزين البيانات السحابية الزائدة. حد الاستبقاء الافتراضي للتفريغ هو 7 أيام. يمنحك تعيين حد أعلى إمكانية الوصول إلى سجل أكبر للجدول الخاص بك، ولكنه يزيد من عدد ملفات البيانات المخزنة، ونتيجة لذلك، يتحمل تكاليف تخزين أكبر من موفر السحابة الخاص بك.
تحذير
من المستحسن تعيين فاصل استبقاء زمني لمدة 7 أيام على الأقل، لأن اللقطات القديمة والملفات غير الملتزم بها يمكن أن تظل قيد الاستخدام من قبل القراء أو الكتاب المتزامنين إلى الجدول. إذا VACUUM
قمت بتنظيف الملفات النشطة، يمكن أن تفشل القراء المتزامنة، أو الأسوأ من ذلك، يمكن أن تتلف الجداول عند VACUUM
حذف الملفات التي لم يتم الالتزام بها بعد. يجب اختيار فاصل زمني أطول من أطول معاملة متزامنة قيد التشغيل وأطول فترة يمكن أن يتخلف فيها أي دفق عن آخر تحديث للجدول.
لدى Delta Lake فحص أمان لمنعك من تشغيل أمر خطير VACUUM
. إذا كنت متأكدا من عدم وجود عمليات يتم تنفيذها على هذا الجدول تستغرق وقتا أطول من الفاصل الزمني للاحتفاظ الذي تخطط لتحديده، يمكنك إيقاف تشغيل فحص الأمان هذا عن طريق تعيين خاصية spark.databricks.delta.retentionDurationCheck.enabled
تكوين Spark إلى false
.
VACUUM
تحتوي عمليات التثبيت في سجل معاملات Delta على معلومات التدقيق. يمكنك الاستعلام عن أحداث التدقيق باستخدام DESCRIBE HISTORY
.