مستويات العزل وتعارضات الكتابة على Azure Databricks

يحدد مستوى عزل الجدول درجة عزل المعاملة عن التعديلات التي يتم إجراؤها بواسطة العمليات المتزامنة. تعتمد تعارضات الكتابة على Azure Databricks على مستوى العزل.

يوفر Delta Lake ضمانات معاملات ACID بين القراءات والكتابة. وهذا يعني:

• يمكن للعديد من الكتاب عبر مجموعات متعددة تعديل قسم جدول في نفس الوقت. يرى الكتاب طريقة عرض لقطة متناسقة للجدول وتحدث عمليات الكتابة بترتيب تسلسلي.
  • يستمر القراء في رؤية طريقة عرض لقطة متناسقة للجدول الذي بدأت به مهمة Azure Databricks، حتى عند تعديل جدول أثناء الوظيفة.

راجع ما هي ضمانات ACID على Azure Databricks؟.

إشعار

يستخدم Azure Databricks Delta Lake لجميع الجداول بشكل افتراضي. توضح هذه المقالة سلوك Delta Lake على Azure Databricks.

هام

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

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

فيما يلي أمثلة على الاستعلامات التي تغير بيانات التعريف:

-- Set a table property.
ALTER TABLE table-name SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

-- Enable a feature using a table property and update the table protocol.
ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

-- Drop a table feature.
ALTER TABLE table_name DROP FEATURE deletionVectors;

-- Upgrade to UniForm.
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));

-- Update the table schema.
ALTER TABLE table_name ADD COLUMNS (col_name STRING);

تعارضات الكتابة مع التزامن على مستوى الصف

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

يتوفر التزامن على مستوى الصف بشكل عام على Databricks Runtime 14.2 وما فوق. يتم دعم التزامن على مستوى الصف بشكل افتراضي للشروط التالية:

• الجداول مع تمكين متجهات الحذف وبدون تقسيم.
• الجداول ذات التجميع السائل، إلا إذا قمت بتعطيل متجهات الحذف.

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

بالنسبة لإصدارات وقت تشغيل Databricks الأخرى، راجع سلوك معاينة التزامن على مستوى الصف (قديم) .

يصف الجدول التالي أزواج عمليات الكتابة التي يمكن أن تتعارض في كل مستوى عزل مع تمكين التزامن على مستوى الصف.

إشعار

لا تدعم الجداول التي تحتوي على أعمدة الهوية المعاملات المتزامنة. راجع استخدام أعمدة الهوية في Delta Lake.

	INSERT (1)	التحديث والحذف والدمج في	تحسين
إدراج	لا يمكن التعارض
التحديث والحذف والدمج في	لا يمكن التعارض في WriteSerializable. يمكن أن يتعارض في Serializable عند تعديل الصف نفسه؛ راجع قيود التزامن على مستوى الصف.	MERGE INTO يتطلب Photon لحل التعارض على مستوى الصف. يمكن أن تتعارض عند تعديل الصف نفسه؛ راجع قيود التزامن على مستوى الصف.
تحسين	لا يمكن التعارض	لا يمكن التعارض	لا يمكن التعارض

هام

(1) تصف جميع INSERT العمليات في الجداول أعلاه عمليات الإلحاق التي لا تقرأ أي بيانات من نفس الجدول قبل الالتزام. INSERT تدعم العمليات التي تحتوي على استعلام فرعي يقرأ نفس الجدول نفس التزامن مثل MERGE.

تعارضات الكتابة دون تزامن على مستوى الصف

يصف الجدول التالي أزواج عمليات الكتابة التي يمكن أن تتعارض في كل مستوى عزل.

لا تدعم الجداول التزامن على مستوى الصف إذا كانت تحتوي على أقسام محددة أو لم يتم تمكين متجهات الحذف. Databricks Runtime 14.2 أو أعلى مطلوب للتزامن على مستوى الصف.

إشعار

لا تدعم الجداول التي تحتوي على أعمدة الهوية المعاملات المتزامنة. راجع استخدام أعمدة الهوية في Delta Lake.

	INSERT (1)	التحديث والحذف والدمج في	تحسين
إدراج	لا يمكن التعارض
التحديث والحذف والدمج في	لا يمكن التعارض في WriteSerializable. يمكن أن تتعارض في قابل للتسلسل؛ راجع تجنب التعارضات مع الأقسام.	يمكن أن تتعارض في قابل للتسلسل و WriteSerializable؛ راجع تجنب التعارضات مع الأقسام.
تحسين	لا يمكن التعارض	لا يمكن التعارض مع في الجداول مع تمكين متجهات الحذف. يمكن أن تتعارض بخلاف ذلك.	لا يمكن التعارض مع في الجداول مع تمكين متجهات الحذف. يمكن أن تتعارض بخلاف ذلك.

هام

(1) تصف جميع INSERT العمليات في الجداول أعلاه عمليات الإلحاق التي لا تقرأ أي بيانات من نفس الجدول قبل الالتزام. INSERT تدعم العمليات التي تحتوي على استعلام فرعي يقرأ نفس الجدول نفس التزامن مثل MERGE.

قيود التزامن على مستوى الصف

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

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

إشعار

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

تنطبق أيضا جميع القيود المفروضة على متجهات الحذف. راجع القيود.

متى تلتزم Delta Lake دون قراءة الجدول؟

لا تقرأ عمليات Delta Lake INSERT أو الإلحاق حالة الجدول قبل الالتزام إذا تم استيفاء الشروط التالية:

1. يتم التعبير عن المنطق باستخدام INSERT منطق SQL أو وضع الإلحاق.
2. لا يحتوي المنطق على استعلامات فرعية أو شرطية تشير إلى الجدول المستهدف بواسطة عملية الكتابة.

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

إشعار

تستخدم MERGE العديد من الأنماط الشائعة العمليات لإدراج البيانات استنادا إلى شروط الجدول. على الرغم من أنه قد يكون من الممكن إعادة كتابة هذا المنطق باستخدام INSERT عبارات، إذا كان أي تعبير شرطي يشير إلى عمود في الجدول الهدف، فإن هذه العبارات لها نفس قيود التزامن مثل MERGE.

كتابة مستويات عزل قابلة للتسلسل مقابل مستويات عزل قابلة للتسلسل

يحدد مستوى عزل الجدول درجة عزل المعاملة عن التعديلات التي يتم إجراؤها بواسطة المعاملات المتزامنة. يدعم Delta Lake على Azure Databricks مستويين من العزل: قابل للتسلسل و WriteSerializable.

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

• WriteSerializable (افتراضي): مستوى عزل أضعف من قابل للتسلسل. يضمن فقط أن عمليات الكتابة (أي، وليس القراءات) قابلة للتسلسل. ومع ذلك، لا يزال هذا أقوى من عزل اللقطة . WriteSerializable هو مستوى العزل الافتراضي لأنه يوفر توازنا كبيرا بين تناسق البيانات وتوافر العمليات الأكثر شيوعا.

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

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

بالنسبة للمستوى القابل للتسلسل، يرى القارئ دائما الجداول التي تتوافق مع المحفوظات فقط. بالنسبة إلى مستوى WriteSerializable، يمكن للقارئ رؤية جدول غير موجود في سجل Delta.

على سبيل المثال، ضع في اعتبارك txn1، وهو حذف طويل الأمد وtxn2، الذي يدرج البيانات المحذوفة بواسطة txn1. txn2 وtxn1 كاملة ويتم تسجيلها بهذا الترتيب في المحفوظات. وفقا للمحفوظات، يجب ألا تكون البيانات المدرجة في txn2 موجودة في الجدول. بالنسبة للمستوى القابل للتسلسل، لن يرى القارئ أبدا البيانات المدرجة بواسطة txn2. ومع ذلك، بالنسبة إلى مستوى WriteSerializable، يمكن للقارئ في مرحلة ما رؤية البيانات المدرجة بواسطة txn2.

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

تعيين مستوى العزل

يمكنك تعيين مستوى العزل باستخدام ALTER TABLE الأمر .

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

حيث <level-name> هو Serializable أو WriteSerializable.

على سبيل المثال، لتغيير مستوى العزل من الافتراضي WriteSerializable إلى Serializable، قم بتشغيل:

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

تجنب التعارضات باستخدام التقسيم وشروط الأوامر المفككة

في جميع الحالات التي تم وضع علامة "يمكن أن تتعارض"، يعتمد ما إذا كانت العمليتان ستتعارضان على ما إذا كانتا تعملان على نفس مجموعة الملفات. يمكنك جعل مجموعتين من الملفات مفككة عن طريق تقسيم الجدول بنفس الأعمدة المستخدمة في شروط العمليات. على سبيل المثال، سيتعارض الأمران UPDATE table WHERE date > '2010-01-01' ... و DELETE table WHERE date < '2010-01-01' إذا لم يتم تقسيم الجدول حسب التاريخ، حيث يمكن لكليهما محاولة تعديل نفس مجموعة الملفات. سيؤدي تقسيم الجدول حسب date إلى تجنب التعارض. لذلك، يمكن أن يؤدي تقسيم جدول وفقا للشروط المستخدمة عادة في الأمر إلى تقليل التعارضات بشكل كبير. ومع ذلك، يمكن أن يؤدي تقسيم جدول حسب عمود له علاقة أساسية عالية إلى مشكلات أداء أخرى بسبب العدد الكبير من الدلائل الفرعية.

استثناءات التعارض

عند حدوث تعارض في المعاملة، ستلاحظ أحد الاستثناءات التالية:

ConcurrentAppendException

يحدث هذا الاستثناء عندما تضيف عملية متزامنة ملفات في نفس القسم (أو في أي مكان في جدول غير مقسم) الذي تقرأه العملية. يمكن أن تكون إضافات الملف ناتجة عن INSERTعمليات أو UPDATEDELETEأو.MERGE

مع مستوى العزل الافتراضي ل WriteSerializable، لا تتعارض الملفات المضافة بواسطة العمليات العمياءINSERT (أي العمليات التي تلحق البيانات بشكل أعمى دون قراءة أي بيانات) مع أي عملية، حتى لو لمست نفس القسم (أو في أي مكان في جدول غير مقسم). إذا تم تعيين مستوى العزل إلى Serializable، فقد تتعارض الإلحاقات العمياء.

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

// Target 'deltaTable' is partitioned by date and country
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

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

// Target 'deltaTable' is partitioned by date and country
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + <date> + "' AND t.country = '" + <country> + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

هذه العملية آمنة الآن لتشغيلها بشكل متزامن في تواريخ وبلدان مختلفة.

ConcurrentDeleteReadException

يحدث هذا الاستثناء عندما تقوم عملية متزامنة بحذف ملف تقرأه العملية. الأسباب الشائعة DELETEهي عملية أو UPDATEأو MERGE التي تعيد كتابة الملفات.

ConcurrentDeleteDeleteException

يحدث هذا الاستثناء عندما تقوم عملية متزامنة بحذف ملف تحذفه العملية أيضا. قد يحدث هذا بسبب عمليتي ضغط متزامنتين تعيدان كتابة نفس الملفات.

MetadataChangedException

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

ConcurrentTransactionException

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

ProtocolChangedException

يمكن أن يحدث هذا الاستثناء في الحالات التالية:

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

راجع كيف تدير Azure Databricks توافق ميزات Delta Lake؟ لمزيد من التفاصيل.

سلوك معاينة التزامن على مستوى الصف (قديم)

يصف هذا القسم سلوكيات المعاينة للتزامن على مستوى الصف في Databricks Runtime 14.1 والإصدارات أدناه. يتطلب التزامن على مستوى الصف دائما متجهات الحذف.

في Databricks Runtime 13.3 LTS وما فوق، تمكن الجداول مع تكوين أنظمة المجموعات السائلة تلقائيا التزامن على مستوى الصف.

في Databricks Runtime 14.0 و14.1، يمكنك تمكين التزامن على مستوى الصف للجداول ذات متجهات الحذف عن طريق تعيين التكوين التالي للمجموعة أو SparkSession:

spark.databricks.delta.rowLevelConcurrencyPreview = true

في Databricks Runtime 14.1 والإصدارات أدناه، تدعم الحوسبة غير الفوتونية التزامن DELETE على مستوى الصف للعمليات فقط.