تخطي البيانات ل Delta Lake
إشعار
في Databricks Runtime 13.3 والإصدارات الأحدث، توصي Databricks باستخدام التجميع السائل لتخطيط جدول Delta. التجميع غير متوافق مع ترتيب Z. راجع استخدام التجميع السائل لجداول Delta.
يتم تجميع البيانات التي تتخطى المعلومات تلقائيا عند كتابة البيانات في جدول Delta. يستفيد Delta Lake على Azure Databricks من هذه المعلومات (الحد الأدنى والحد الأقصى للقيم والأعداد الخالية وإجمالي السجلات لكل ملف) في وقت الاستعلام لتوفير استعلامات أسرع.
يجب أن يكون لديك إحصائيات مجمعة للأعمدة المستخدمة في ZORDER العبارات. راجع ما هو Z-ordering؟.
تحديد أعمدة إحصائيات دلتا
بشكل افتراضي، تجمع Delta Lake إحصائيات حول أول 32 عمودا محددا في مخطط الجدول. عند تمكين التحسين التنبؤي، يتم اختيار إحصائيات تخطي الملفات بذكاء ولا تقتصر على أول 32 عمودا. يعمل ANALYZEالتحسين التنبؤي تلقائيا ، وهو أمر لتجميع الإحصائيات، على الجداول المدارة في كتالوج Unity. توصي Databricks بتمكين التحسين التنبؤي لجميع الجداول المدارة في كتالوج Unity لتبسيط صيانة البيانات وتقليل تكاليف التخزين. راجع التحسين التنبؤي للجداول المدارة لكتالوج Unity.
هام
التحسين التنبؤي مع ANALYZE هو في المعاينة العامة. وهو يتضمن مجموعة إحصائيات ذكية أثناء عمليات الكتابة. استخدم هذا النموذج للتسجيل في المعاينة العامة.
إذا كنت لا تستخدم التحسين التنبؤي، يمكنك تعديل السلوك الذي يحد من مجموعات الإحصائيات إلى 32 عمودا عن طريق تعيين إحدى خصائص الجدول التالية:
| خاصية الجدول | وقت تشغيل Databricks مدعوم | الوصف |
|---|---|---|
delta.dataSkippingNumIndexedCols |
جميع إصدارات وقت تشغيل Databricks المدعومة | قم بزيادة أو تقليل عدد الأعمدة التي تجمع دلتا الإحصائيات عليها. يعتمد على ترتيب الأعمدة. |
delta.dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS وما فوق | حدد قائمة بأسماء الأعمدة التي تجمع Delta Lake الإحصائيات لها. يحل محل dataSkippingNumIndexedCols. |
يمكن تعيين خصائص الجدول عند إنشاء الجدول أو باستخدام ALTER TABLE عبارات. راجع مرجع خصائص جدول Delta.
لا يؤدي تحديث هذه الخصائص إلى إعادة حساب الإحصائيات تلقائيا للبيانات الموجودة. بدلا من ذلك، فإنه يؤثر على سلوك جمع الإحصائيات المستقبلية عند إضافة البيانات أو تحديثها في الجدول. لا تستفيد Delta Lake من الإحصائيات للأعمدة غير المضمنة في القائمة الحالية لأعمدة الإحصائيات.
في Databricks Runtime 14.3 LTS والإصدارات الأحدث، إذا قمت بتغيير خصائص الجدول أو تغيير الأعمدة المحددة للإحصائيات، يمكنك تشغيل إعادة حساب الإحصائيات لجدول Delta يدويا باستخدام الأمر التالي:
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
إشعار
يتم اقتطاع السلاسل الطويلة أثناء جمع الإحصائيات. قد تختار استبعاد أعمدة السلسلة الطويلة من مجموعة الإحصائيات، خاصة إذا لم يتم استخدام الأعمدة بشكل متكرر لتصفية الاستعلامات.
ما هو Z-ordering؟
إشعار
توصي Databricks باستخدام التجميع السائل لجميع جداول Delta الجديدة. لا يمكنك استخدام ZORDER بالاشتراك مع تكوين أنظمة المجموعات السائلة.
يعد ترتيب Z تقنية لتكوين المعلومات ذات الصلة في نفس مجموعة الملفات. يتم استخدام هذه المنطقة المشتركة تلقائيا بواسطة Delta Lake على خوارزميات تخطي بيانات Azure Databricks. يقلل هذا السلوك بشكل كبير من كمية البيانات التي يحتاج Delta Lake على Azure Databricks إلى قراءتها. إلى بيانات ترتيب Z، يمكنك تحديد الأعمدة التي تريد ترتيبها في ZORDER BY عبارة :
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
إذا كنت تتوقع استخدام عمود بشكل شائع في دالات تقييم الاستعلام وإذا كان هذا العمود يحتوي على علاقة أساسية عالية (أي عدد كبير من القيم المميزة)، فاستخدم ZORDER BY.
يمكنك تحديد أعمدة ZORDER BY متعددة لقائمة مفصولة بفواصل. ومع ذلك، تنخفض فعالية المنطقة مع كل عمود إضافي. سيكون ترتيب Z على الأعمدة التي لا تحتوي على إحصائيات مجمعة عليها غير فعال وإهدار للموارد. وذلك لأن تخطي البيانات يتطلب إحصائيات عمودية محلية مثل الحد الأدنى والحد الأقصى والعدد. يمكنك تكوين مجموعة الإحصائيات على أعمدة معينة عن طريق إعادة ترتيب الأعمدة في المخطط، أو يمكنك زيادة عدد الأعمدة لتجميع الإحصائيات عليها.
إشعار
ترتيب Z ليس متكررا ولكنه يهدف إلى أن يكون عملية تزايدية. الوقت الذي يستغرقه ترتيب Z غير مضمون لتقليله عبر عمليات تشغيل متعددة. ومع ذلك، إذا لم تتم إضافة أي بيانات جديدة إلى قسم تم ترتيبه فقط من قبل Z، فلن يكون لترتيب Z آخر لهذا القسم أي تأثير.
يهدف ترتيب Z إلى إنتاج ملفات بيانات متوازنة بالتساوي فيما يتعلق بعدد المجموعات، ولكن ليس بالضرورة حجم البيانات على القرص. غالبا ما يكون المقياسان مرتبطين، ولكن يمكن أن تكون هناك حالات لا يحدث فيها ذلك، مما يؤدي إلى انحراف في أوقات المهام الأمثل.
على سبيل المثال، إذا قمت
ZORDER BYبالتاريخ وكانت السجلات الأحدث أوسع بكثير (على سبيل المثال صفائف أطول أو قيم سلسلة) من تلك الموجودة في الماضي، فمن المتوقع أنOPTIMIZEتكون مدد مهمة المهمة منحرفة، بالإضافة إلى أحجام الملفات الناتجة. ومع ذلك، هذه مشكلة فقط للأمرOPTIMIZEنفسه؛ يجب ألا يكون لها أي تأثير سلبي على الاستعلامات اللاحقة.