مشاركة عبر

كائنات قاعدة البيانات في Hive metastore القديم

  • مقالة

تركز وثائق Azure Databricks على العمل مع كائنات البيانات باستخدام كتالوج Unity، ولكن معظم الإرشادات تنطبق أيضا على العمل مع الكائنات المسجلة في Hive metastore القديم.

تركز هذه المقالة على كيفية العمل مع كائنات قاعدة البيانات المسجلة في Hive metastore القديم. على وجه التحديد، توضح هذه المقالة مكان اختلاف العمل مع كائنات Hive metastore عن العمل مع كائنات كتالوج Unity. كما يصف السلوكيات الأخرى التي قد تكون غير متوقعة.

توصي Databricks بترحيل جميع البيانات من Hive metastore القديم إلى كتالوج Unity. راجع ترقية جداول Hive وطرق العرض إلى كتالوج Unity.

كيف تعمل إدارة بيانات Hive metastore؟

على الرغم من أن مساحات عمل Azure Databricks تستمر في تضمين Hive metastore المضمن، يتم إهمال إدارة البيانات باستخدام Hive metastore. توصي Databricks باستخدام كتالوج Unity لجميع حوكمة البيانات. راجع العمل مع كتالوج Unity ومخزن Hive metastore القديم.

لا يقلل تمكين مساحة عمل لكتالوج Unity من قدرتك على العمل مع البيانات المسجلة بالفعل في Hive metastore. تظهر جميع كائنات البيانات المسجلة في مخزن بيانات الخلية القديم في واجهات كتالوج Unity في الكتالوج hive_metastore . يمكن أن يكون مخزن بيانات تعريف الخلية المختلط ومساحة عمل كتالوج Unity نموذجا مفيدا لانتقال مساحة عمل Hive metastore طويلة الأمد. ومع ذلك، فإن حوكمة البيانات ومزايا الأداء في كتالوج Unity عالية، ويجب عليك نقل مساحات العمل الخاصة بك بشكل كامل في أقرب وقت ممكن.

يستخدم Hive metastore التحكم في الوصول إلى الجدول (قوائم التحكم في الوصول إلى الجدول) لإدارة الوصول إلى كائنات قاعدة البيانات. يبقى بعض الدعم للتحكم في الوصول إلى الجدول عند استخدام الحساب في وضع الوصول المشترك. راجع التحكم في الوصول إلى جدول Hive metastore (قديم).

تمرير بيانات الاعتماد هو نمط مهمل لإدارة البيانات على كائنات قاعدة بيانات Hive metastore. لا تتناول هذه المقالة تمرير بيانات الاعتماد. راجع تمرير بيانات الاعتماد (قديم).

إشعار

حيث تشير هذه المقالة إلى التحكم في الوصول إلى البيانات في Hive metastore، فإنها تشير إلى التحكم في الوصول إلى الجدول القديم.

ما هو الكتالوج hive_metastore ؟

في مساحة العمل التي تم تمكينها ل Unity Catalog، تظهر جميع المخططات في Hive metastore كتوابع للكتالوج hive_metastore في مساحة الاسم ثلاثية المستويات في كتالوج Unity. لا يستخدم Hive metastore الكتالوجات فعليا، وتوفر هذه البنية نقطة إدخال إلى الجداول في مخزن بيانات تعريف Hive القديم لمستخدمي كتالوج Unity. استخدم بناء الجملة التالي للاستعلام عن الجداول في Hive metastore القديم:

SELECT * FROM hive_metastore.schema_name.table_name

إشعار

يمكنك اختياريا تعيين الكتالوج hive_metastore كمساحة العمل الافتراضية في مساحات العمل الممكنة لكتالوج Unity. راجع إدارة الكتالوج الافتراضي.

المخططات في Hive metastore

في Hive metastore القديم، المخطط هو أعلى مستوى في التسلسل الهرمي لعنصر البيانات.

هناك بعض الاختلافات المهمة بين كتالوج Unity و Hive metastore، بما في ذلك ما يلي:

  • لا يمكنك إنشاء مخططات في Hive metastore باستخدام مستكشف الكتالوج. يمكنك عرض أذونات المخططات وتحريرها.
  • يمكن أن تستخدم المخططات التي تم إنشاؤها في Hive metastore أحرف ASCII الأبجدية الرقمية فقط والتسطير السفلي في أسمائها.
  • يسمح لك Hive metastore بالإعلان عن LOCATION لمخطط أثناء الإنشاء. يعمل هذا بشكل مشابه لمواقع التخزين المدارة في كتالوج Unity، مع الاختلافات السلوكية التالية:
    • إذا لم توفر موقعا، استخدام الموقع /user/hive/warehouse/<schema-name> الافتراضي. هذا الموقع موجود على جذر DBFS، وهو غير مستحسن لتخزين أي بيانات إنتاج.
    • يمكن أن يكون المسار المتوفر أي موقع تخزين سحابي متاح للمستخدم الذي يقوم بإنشاء المخطط، بما في ذلك عناوين URIs السحابية وجذر DBFS وتركيبات DBFS.
    • لا تتم إدارة الوصول إلى الموقع بواسطة Hive metastore.
    • يؤدي حذف مخطط في Hive metastore إلى حذف كافة الملفات في موقع المخطط هذا بشكل متكرر، بغض النظر عن نوع الجدول (مدار أو خارجي).

لتجنب فقدان البيانات العرضي، يوصي Databricks بما يلي عند العمل مع مواقع مخطط Hive metastore:

  • لا تقم بتعيين موقع مخطط يحتوي بالفعل على بيانات.
  • لا تقم بإنشاء جدول خارجي في موقع مخطط.
  • لا تشارك موقعا بين مخططات متعددة.
  • لا تقم بتعيين موقع مخطط يتداخل مع موقع مخطط آخر. بمعنى آخر، لا تستخدم مسارا تابعا لموقع مخطط آخر.
  • لا تقم بتعيين موقع مخطط يتداخل مع موقع جدول خارجي.

الجداول المدارة في Hive metastore

لا تحتوي الجداول المدارة في Hive metastore على أي من مزايا الأداء للجداول المدارة في كتالوج Unity. مثل الجداول المدارة كتالوج Unity، تستخدم الجداول المدارة ل Hive metastore Delta Lake بشكل افتراضي. ومع ذلك، في Hive metastore، على عكس كتالوج Unity، يمكنك أيضا إنشاء جدول مدار باستخدام معظم تنسيقات البيانات الأخرى التي يدعمها Azure Databricks.

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

لا يدير Hive metastore تخطيط البيانات للجداول المدارة بالطريقة التي يديرها كتالوج Unity. عند إسقاط جدول مدار في Hive metastore، يتم حذف جميع ملفات البيانات الأساسية على الفور. في كتالوج Unity، من ناحية أخرى، يمكنك UNDROP جدول مدار لمدة 7 أيام، ويتم حذف البيانات نهائيا في غضون 30 يوما.

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

الجداول الخارجية في Hive metastore

تم تكوين معظم الجداول التي تم إنشاؤها في Azure Databricks قبل إدخال كتالوج Unity كجداول خارجية في Hive metastore. عادة ما تركز التوصيات القديمة التي تفضل الجداول الخارجية على بعض الجوانب الرئيسية:

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

توصي Azure Databricks الآن بالجداول المدارة في كتالوج Unity لمعظم تخزين البيانات الجدولية. راجع العمل مع الجداول المدارة.

طرق العرض في Hive metastore

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

بسبب القدرة على الإعلان عن طرق العرض مقابل مصادر البيانات غير الجدولية، يمكن أن تمنح طرق العرض في Hive metastore وصولا غير متوقع أو غير مقصود إلى البيانات مع تكوينات الوصول الأخرى في بيئة المستخدم.

على سبيل المثال، ضع في اعتبارك ما يلي:

  • يتم تعريف جدول my_table باستخدام مسار /mnt/my_tableتحميل DBFS .
    • يتم تخزين بيانات اعتماد تحميل DBFS في مساحة العمل، بحيث يمكن لجميع المستخدمين الوصول إلى هذا المسار بشكل افتراضي.
  • يتم استخدام قوائم التحكم بالوصول للجداول لتقييد الوصول إلى my_table مجموعة من المستخدمين.
    • يتم تطبيق قوائم التحكم بالوصول للجدول القديم فقط على الحساب الذي تم تكوينه باستخدام وضع الوصول المشترك أو مستودعات SQL.
  • يتم تعريف طريقة العرض my_view مباشرة مقابل URI السحابي الذي يدعم ملفات 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'البيانات نفسها .
    • تعتمد بيانات اعتماد URI على نهج الوصول المحددة في جلسة Spark أو تكوين الحساب.

تحتوي طريقة العرض my_view على الخصائص التالية:

  • لا يستخدم بيانات اعتماد تحميل DBFS المستخدمة لتحميل تخزين كائن السحابة إلى /mnt/my_table.
  • لا يحترم جدول قوائم التحكم في الوصول المعينة على my_table، بغض النظر عن تكوينات الحوسبة.
  • يتطلب نهج الوصول إلى البيانات المكونة للحساب الذي يوفر الوصول للقراءة إلى 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table'.

إشعار

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

جداول Hive القديمة ودعم HiveQL

يتضمن Azure Databricks بعض الدعم القديم لجداول Hive ووظائف HiveQL. هذه الوظيفة هي من بقايا الإصدارات المبكرة من Azure Databricks والنظام البنائي Apache Hadoop من الأدوات. لا توصي Databricks باستخدام جداول Hive أو وظائف Hive الأخرى، حيث لم يتم تحسين هذه الوظيفة وتفتقر إلى الدعم في بعض تكوينات الحوسبة.

تصف المقالات التالية وظائف Hive القديمة: