متى يتم تقسيم الجداول على Azure Databricks

  • مقالة

توفر هذه المقالة نظرة عامة حول كيفية تقسيم الجداول على Azure Databricks وتوصيات محددة حول متى يجب عليك استخدام التقسيم للجداول المدعومة من Delta Lake. بسبب الميزات والتحسينات المضمنة، لا تتطلب معظم الجداول التي تحتوي على أقل من ТБ واحد من البيانات أقساما.

يستخدم Azure Databricks Delta Lake لجميع الجداول بشكل افتراضي. تفترض التوصيات التالية أنك تعمل مع Delta Lake لجميع الجداول.

في Databricks Runtime 11.3 LTS وما فوق، يقوم Azure Databricks تلقائيا بتخزين البيانات في جداول غير تقسيمية عن طريق وقت الاستيعاب. راجع استخدام تجميع وقت الاستيعاب.

هل تحتاج الجداول الصغيرة إلى تقسيم؟

توصي Databricks بعدم تقسيم الجداول التي تحتوي على أقل من تيرابايت من البيانات.

ما هو الحد الأدنى لحجم كل قسم في جدول؟

توصي Databricks بأن تحتوي جميع الأقسام على غيغابايت من البيانات على الأقل. تميل الجداول ذات الأقسام الأكبر والأقل إلى أداء الجداول التي تحتوي على العديد من الأقسام الأصغر.

استخدام تجميع وقت الاستيعاب

باستخدام Delta Lake وDatabricks Runtime 11.3 LTS أو أعلى، تستفيد الجداول غير المجمعة التي تقوم بإنشائها تلقائيا من تجميع وقت الاستيعاب. يوفر وقت الاستيعاب فوائد استعلام مماثلة لاستراتيجيات التقسيم استنادا إلى حقول التاريخ والوقت دون الحاجة إلى تحسين بياناتك أو ضبطها.

إشعار

للحفاظ على تجميع وقت الاستيعاب عند إجراء عدد كبير من التعديلات باستخدام UPDATE أو MERGE عبارات على جدول، توصي Databricks بتشغيل OPTIMIZE باستخدام ZORDER BY عمود يطابق ترتيب الاستيعاب. على سبيل المثال، قد يكون هذا عمودا يحتوي على طابع زمني للحدث أو تاريخ إنشاء.

هل تشارك Delta Lake وParquet استراتيجيات التقسيم؟

يستخدم Delta Lake Parquet باعتباره التنسيق الأساسي لتخزين البيانات، وتظهر بعض جداول Delta ذات الأقسام المحددة تنظيما مشابها لجداول Parquet المخزنة مع Apache Spark. يستخدم Apache Spark التقسيم على نمط Hive عند حفظ البيانات بتنسيق Parquet. لا يعد التقسيم على نمط الخلية جزءا من بروتوكول Delta Lake، ويجب ألا تعتمد أحمال العمل على استراتيجية التقسيم هذه للتفاعل مع جداول Delta.

العديد من ميزات Delta Lake تكسر الافتراضات حول تخطيط البيانات التي ربما تم نقلها من Parquet أو Hive أو حتى إصدارات بروتوكول Delta Lake السابقة. يجب أن تتفاعل دائما مع البيانات المخزنة في Delta Lake باستخدام العملاء وواجهات برمجة التطبيقات المدعومة رسميا.

كيف تختلف أقسام Delta Lake عن الأقسام في مستودعات البيانات الأخرى؟

في حين أن Azure Databricks وData Lake يعتمدان على تقنيات مصدر مفتوح مثل Apache Spark وParquet وHive و Hadoop، فإن تقسيم الدوافع والاستراتيجيات المفيدة في هذه التقنيات لا ينطبق بشكل عام على Azure Databricks. إذا اخترت تقسيم الجدول، ففكر في الحقائق التالية قبل اختيار استراتيجية:

  • لا يتم تعريف المعاملات بواسطة حدود القسم. يضمن Delta Lake ACID من خلال سجلات المعاملات، لذلك لا تحتاج إلى فصل دفعة من البيانات عن طريق قسم لضمان الاكتشاف الذري.
  • لا تحتوي مجموعات حساب Azure Databricks على منطقة بيانات مرتبطة بالوسائط الفعلية. يتم تخزين البيانات التي يتم استيعابها في مستودع التخزين في تخزين الكائنات السحابية. بينما يتم تخزين البيانات مؤقتا إلى تخزين القرص المحلي أثناء معالجة البيانات، يستخدم Azure Databricks إحصائيات مستندة إلى الملفات لتحديد الحد الأدنى من البيانات للتحميل المتوازي.

كيف يعمل ترتيب Z والأقسام معا؟

يمكنك استخدام فهارس ترتيب Z جنبا إلى جنب مع الأقسام لتسريع الاستعلامات على مجموعات البيانات الكبيرة.

إشعار

يمكن لمعظم الجداول الاستفادة من تجميع وقت الاستيعاب لتجنب الحاجة إلى القلق بشأن ترتيب Z وضبط التقسيم.

من المهم أن تضع القواعد التالية في الاعتبار أثناء التخطيط لاستراتيجية تحسين الاستعلام استنادا إلى حدود القسم وترتيب Z:

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

إذا كانت الأقسام سيئة للغاية، فلماذا تستخدمها بعض ميزات Azure Databricks؟

يمكن أن تكون الأقسام مفيدة، خاصة للجداول الكبيرة جدا. تركز العديد من تحسينات الأداء حول التقسيم على جداول كبيرة جدا (مئات التيرابايت أو أكبر).

يرحل العديد من العملاء إلى Delta Lake من مستودعات البيانات المستندة إلى Parquet. CONVERT TO DELTA تسمح لك العبارة بتحويل جدول قائم على Parquet موجود إلى جدول Delta دون إعادة كتابة البيانات الموجودة. على هذا النحو، لدى العديد من العملاء جداول كبيرة ترث استراتيجيات التقسيم السابقة. تسعى بعض التحسينات التي طورتها Databricks إلى الاستفادة من هذه الأقسام عندما يكون ذلك ممكنا، ما يخفف من بعض الجوانب السلبية المحتملة لاستراتيجيات التقسيم غير المحسنة ل Delta Lake.

Delta Lake وApache Spark هما تقنيات مفتوحة المصدر. بينما تستمر Databricks في تقديم الميزات التي تقلل من الاعتماد على التقسيم، قد يستمر مجتمع مصدر مفتوح في بناء ميزات جديدة تضيف التعقيد.

هل من الممكن التفوق على التحسينات المضمنة في Azure Databricks مع التقسيم المخصص؟

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