استنساخ سطحي لجداول كتالوج Unity

  • مقالة

هام

يتوفر دعم النسخ الضحل للجداول المدارة في كتالوج Unity في المعاينة العامة في Databricks Runtime 13.3 وما فوق. يتوفر دعم النسخ الضحل للجدول الخارجي ل Unity Catalog في المعاينة العامة في Databricks Runtime 14.2 والإصدارات الأحدث.

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

هام

يمكنك فقط استنساخ الجداول المدارة في كتالوج Unity إلى الجداول المدارة في كتالوج Unity والجداول الخارجية لكتالوج Unity إلى جداول Unity الخارجية. VACUUM يختلف السلوك بين الجداول المدارة والجداول الخارجية. راجع نسخ كتالوج فراغ وUnity الضحلة.

لمزيد من المعلومات حول استنساخ دلتا، راجع استنساخ جدول على Azure Databricks.

للحصول على المزيد حول جداول كتالوج Unity، راجع إنشاء جداول في كتالوج Unity.

إنشاء نسخة ضحلة على كتالوج Unity

يمكنك إنشاء نسخة ضحلة في كتالوج Unity باستخدام نفس بناء الجملة المتاح للنسخ الضحلة في جميع أنحاء المنتج، كما هو موضح في مثال بناء الجملة التالي:

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name> SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

لإنشاء نسخة سطحية على كتالوج Unity، يجب أن يكون لديك امتيازات كافية على كل من الموارد المصدر والهدف، كما هو مفصل في الجدول التالي:

Resource الأذونات المطلوبة
الجدول المصدر SELECT
مخطط المصدر USE SCHEMA
كتالوج المصدر USE CATALOG
مخطط الهدف USE SCHEMA, CREATE TABLE
الكتالوج الهدف USE CATALOG
الموقع الخارجي المستهدف (الجداول الخارجية فقط) CREATE EXTERNAL TABLE

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

إشعار

قد يختلف مالك جدول مستنسخ عن مالك الجدول المصدر.

الاستعلام عن جدول مستنسخ ضحل أو تعديله في كتالوج Unity

هام

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

للاستعلام عن نسخة ضحلة على كتالوج Unity، يجب أن يكون لديك امتيازات كافية على الجدول وتحتوي على موارد، كما هو مفصل في الجدول التالي:

Resource الأذونات المطلوبة
Catalog USE CATALOG
مخطط USE SCHEMA
جدول SELECT

يجب أن يكون لديك MODIFY أيضا أذونات على الهدف من عملية النسخ لإكمال الإجراءات التالية:

  • إدراج سجلات
  • حذف السجلات
  • تحديث السجلات
  • MERGE
  • CREATE OR REPLACE TABLE
  • DROP TABLE

النسخ الضحلة للكتالوج الفراغي والكتالوج Unity

هام

هذا السلوك موجود في المعاينة العامة في Databricks Runtime 13.3 LTS وما فوق للجداول المدارة وDatabricks Runtime 14.2 والإصدارات الأحدث للجداول الخارجية.

عند استخدام جداول كتالوج Unity لمصدر وهدف عملية استنساخ ضحلة، يدير كتالوج Unity ملفات البيانات الأساسية لتحسين الموثوقية لمصدر وهدف عملية النسخ. لا يؤدي التشغيل VACUUM على مصدر نسخة ضحلة إلى قطع الجدول المستنسخ.

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

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

يغير هذا التتبع المحسن لبيانات التعريف كيفية VACUUM تأثير العمليات على ملفات البيانات التي تدعم جداول Delta، مع الدلالات التالية:

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

إشعار

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

العمل مع الجداول المستنسخة الضحلة في وضع وصول المستخدم الفردي

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

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

توصي Databricks بالعمل مع استنساخ كتالوج Unity على الحساب مع وضع الوصول المشترك لأن هذا يسمح بالتطور المستقل للأذونات لأهداف النسخ الضحلة لكتالوج Unity وجداول المصدر الخاصة بها.

القيود

  • يجب أن تكون النسخ الضحلة على الجداول الخارجية جداول خارجية. يجب أن تكون المستنسخات الضحلة على الجداول المدارة جداول مدارة.
  • لا يمكنك مشاركة المستنسخات الضحلة باستخدام Delta Sharing.
  • لا يمكنك تداخل المستنسخات الضحلة، ما يعني أنه لا يمكنك إجراء نسخة ضحلة من نسخة ضحلة.
  • بالنسبة للجداول المدارة، يؤدي إسقاط الجدول المصدر إلى قطع الجدول الهدف للنسخ الضحلة. لا تتم إزالة ملفات البيانات التي تدعم الجداول الخارجية بواسطة DROP TABLE العمليات، وبالتالي لا تتأثر النسخ الضحلة من الجداول الخارجية بإسقاط المصدر.
  • يسمح كتالوج Unity للمستخدمين UNDROP بالجداول المدارة لمدة 7 أيام تقريبا بعد DROP TABLE الأمر. في Databricks Runtime 13.3 LTS وما فوق، تستمر النسخ الضحلة المدارة استنادا إلى جدول مدار تم إسقاطه في العمل خلال فترة السبعة أيام هذه. إذا لم تقم UNDROP بالجدول المصدر في هذه النافذة، يتوقف الاستنساخ الضحل عن العمل بمجرد تجميع ملفات بيانات الجدول المصدر للبيانات المهملة.