Unity Catalog في Databricks: إعداد الحوكمة بالشكل الصحيح

Unity Catalog هو طبقة الحوكمة في Databricks. يتحكم في من يستطيع رؤية وتعديل كل جدول وطريقة عرض ووحدة تخزين ملفات ودالة ونموذج ذكاء اصطناعي، ويسجّل مسار البيانات بينها، ويسجّل عمليات الوصول بحيث يمكنك إثباتها للمدقق.

إذا كنت تشغّل Databricks اليوم، فأنت عليه أصلاً أو في طور الانتقال إليه. فـ Hive metastore القديم في طريقه إلى الخروج، وكل ميزة أحدث في Databricks تفترض وجود Unity Catalog تحتها.

لم يعد السؤال هل تعتمده. بل هل سيبقى تصميم الكتالوجات لديك منطقياً بعد ثلاث سنوات من فرق جديدة وبيانات جديدة وتدقيق أو اثنين.

في برامج التصنيع والدفاع التي عملت عليها، نادراً ما كانت التقنية هي الجزء الصعب. الصعب كان الاتفاق على من يملك أي بيانات، وكيف تُفصل البيئات، وما الأدلة التي يحتاجها فريق الأمن.

كل شيء يقع تحت metastore، وهو الحاوية العليا. وتحته تستخدم أصول البيانات والذكاء الاصطناعي مساحة أسماء من ثلاثة مستويات: catalog.schema.object. فالاستعلام على prod_finance.gl.journal_lines يسمّي الكتالوج والمخطط والجدول.

تُسمّى الكائنات التي تمنح عليها الصلاحيات الكائنات القابلة للتأمين (securable objects). ووفقاً لـوثائق Unity Catalog، تنقسم إلى مجموعتين:

1. الأصول ضمن مساحة الأسماء: الجداول، وطرق العرض، ووحدات التخزين (volumes، وهي تخزين ملفات محكوم)، والدوال، والنماذج، والخدمات.
2. الكائنات على مستوى metastore: بيانات اعتماد التخزين، والمواقع الخارجية، والاتصالات (بقواعد البيانات الخارجية)، والمشاركات (shares).

اثنان من هذه الكائنات على مستوى metastore يستحقان شرحاً واضحاً، لأنهما يحددان أين توجد بياناتك فعلياً.

بيانات اعتماد التخزين (storage credential) تغلّف هوية سحابية، مثل دور IAM أو هوية مُدارة، يمكنها الوصول إلى حساب تخزين أو bucket. والموقع الخارجي (external location) يربط مسار تخزين ببيانات اعتماد. ومعاً يتيحان لـ Unity Catalog القراءة من التخزين السحابي والكتابة إليه دون تسليم المفاتيح للمستخدمين.

ثم هناك الجداول المُدارة مقابل الخارجية. مع الجداول المُدارة، يحكم Unity Catalog الجدول ويدير ملفاته. ومع الجداول الخارجية، يحكم الوصول فقط.

توصي Databricks الآن بالجداول المُدارة لكل البيانات الجديدة، مع الإبقاء على الجداول الخارجية أساساً لترقيات Hive. وأنا أتفق. فكتابة أدوات أخرى إلى المسارات نفسها عادةً ما تكون سبباً لإصلاح خط المعالجة، لا للإبقاء على الجدول خارجياً إلى الأبد.

قيد واحد يشكّل كل شيء: يمكنك أن يكون لديك metastore واحد فقط لكل منطقة سحابية. لا يمكنك حل العزل بمزيد من الـ metastores. بل تحله بالكتالوجات.

صلاحيات Unity Catalog هي صلاحيات SQL قياسية تُورَّث نزولاً. الصلاحية الممنوحة على كتالوج تنطبق على كل مخطط وجدول داخله. ويحتاج المستخدم إلى USE CATALOG وUSE SCHEMA للوصول إلى جدول، ثم SELECT لقراءته.

GRANT USE CATALOG ON CATALOG prod_finance TO `finance-analysts`;
GRANT USE SCHEMA ON SCHEMA prod_finance.gl TO `finance-analysts`;
GRANT SELECT ON SCHEMA prod_finance.gl TO `finance-analysts`;

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

يلخّص الجدول أدناه ضوابط الوصول الرئيسية وحالتها حتى أكتوبر 2026.

الضابط	ما يفعله	الحالة (أكتوبر 2026)
الصلاحيات والملكية	امتيازات على مستوى الكائن، تُورَّث من الكتالوج إلى المخطط إلى الكائن	متاح للعموم
فلاتر الصفوف وأقنعة الأعمدة على مستوى الجدول	دالة SQL مرتبطة بجدول واحد تُخفي صفوفاً أو تُقنّع قيماً	متاح للعموم
سياسات ABAC لفلاتر الصفوف وأقنعة الأعمدة	سياسة واحدة، تُعرَّف على مستوى الكتالوج أو المخطط أو الجدول، تنطبق على كل كائن يحمل وسماً محكوماً	متاح للعموم منذ 28 أبريل 2026
الوسوم المحكومة (governed tags)	وسوم على مستوى الحساب بمفاتيح وقيم مضبوطة وتحديد من يحق له تعيينها	متاح للعموم منذ 2 أبريل 2026
تصنيف البيانات	يفحص الجداول ويشير إلى البيانات الحساسة مثل PII	متاح للعموم منذ 20 أبريل 2026؛ والمصنّفات المخصصة في Beta
سياسات ABAC DENY والسياسات على مستوى metastore	رفض صريح يتجاوز الصلاحيات؛ وسياسات على نطاق metastore	Beta
ABAC عبر المحركات	تقرأ المحركات الخارجية الجداول المُدارة المحمية بـ ABAC، مع فرض السياسات عبر serverless compute في Databricks	متاح للعموم منذ 1 أكتوبر 2026

التواريخ مأخوذة من ملاحظات إصدار Databricks لشهر أبريل 2026 وملاحظات أكتوبر 2026.

ABAC (التحكم في الوصول القائم على السمات) هو التغيير الأهم للبيئات الكبيرة. فبدلاً من كتابة قناع لكل جدول، تضع وسماً على الأعمدة، مثل classification = export_controlled، وتكتب سياسة واحدة تُقنّع كل عمود موسوم لكل من هو خارج مجموعة مسمّاة.

تصبح الجداول الجديدة محمية بمجرد وسمها. ويمكن لتصنيف البيانات أن يقترح الوسوم.

تحقّق من الحوسبة أولاً. تحتاج الجداول المؤمّنة بـ ABAC إلى serverless compute أو Databricks Runtime 16.4 أو أحدث. ولا تستطيع الـ clusters الأقدم قراءتها إطلاقاً.

فخّان أنبّه إليهما مبكراً. السياسات المتعارضة على العمود نفسه للمستخدم نفسه توقف الاستعلام بخطأ.

وإذا وقعت هوية التشغيل (run-as) لخط معالجة تحت قناع، فقد تُخزَّن البيانات المحدّثة مُقنّعة. استثنِ هويات الخدمة عن قصد، ووثّق السبب.

يُلتقط مسار البيانات تلقائياً، حتى مستوى العمود، للاستعلامات التي تعمل عبر Databricks SQL وSpark DataFrames في أي مساحة عمل مرتبطة بالـ metastore. ويغطي دفاتر الملاحظات والمهام وخطوط المعالجة ولوحات المعلومات. ويضيع مسار الأعمدة حين يشير الكود إلى الجداول بمسار التخزين، وهذا سبب إضافي لإيقاف الوصول القائم على المسارات.

تأتي أدلة التدقيق من جداول النظام. يحتفظ system.access.audit بأحداث التدقيق ولا يزال موسوماً بـ Public Preview في وثائق جداول النظام.

وتقع جداول مسار البيانات والفوترة بجانبه، مع احتفاظ مجاني لمدة 365 يوماً. لا يرى جداول النظام افتراضياً سوى مسؤولي الحساب والـ metastore، لذا قرّر مبكراً من يحصل على صلاحية القراءة، وهل ستنسخ بيانات التدقيق إلى نظام SIEM لديك لاحتفاظ أطول.

تغيّر اسم المشاركة هذا العام. أعلنت Databricks عن OpenSharing في 10 يونيو 2026 بوصفه الإصدار التالي من بروتوكول Delta Sharing، وتستضيفه الآن Linux Foundation، وقد امتد ليشمل أصول الذكاء الاصطناعي وعملاء Iceberg.

ستظل ترى "Delta Sharing" في الوثائق والعقود الأقدم. والمشاركة (share) كائن في Unity Catalog، والمشاركة من Databricks إلى Databricks هي أيضاً الطريقة التي تنقل بها البيانات بين الـ metastores الإقليمية.

وللبيئات المختلطة، أصبحت جداول Apache Iceberg المُدارة والأجنبية متاحة للعموم في 21 مايو 2026. تُقرأ الجداول الأجنبية عبر Lakehouse Federation من كتالوجات مثل AWS Glue أو Snowflake Horizon. ويمكن لمحركات مثل Spark وFlink وTrino استخدام نقطة نهاية Iceberg REST catalog في Unity Catalog.

وهناك أيضاً Unity Catalog مفتوح المصدر تحت مظلة LF AI & Data Foundation، لكنه مشروع في مرحلة sandbox، وليس الخدمة المُدارة. لا تبنِ خطة خروج عليه دون اختبار.

الكتالوجات هي الوحدة الرئيسية للعزل. وتقول أفضل ممارسات Unity Catalog من Databricks إن الكتالوجات عادةً ما تقابل بيئة، أو فريقاً، أو وحدة أعمال، أو مزيجاً منها. ومعظم التصاميم الفعلية مزيج.

طريقتان لتقسيم الكتالوجات

كتالوج لكل بيئة

• كتالوجات dev وtest وprod، ومخططات لكل مجال
• ربط كل كتالوج بمساحة العمل الخاصة به بسيط
• تتداخل الملكية مع نمو المجالات داخل كتالوج واحد
• يناسب الفرق الأصغر والمراحل الأولى من الطرح

كتالوج لكل مجال وبيئة

• prod_finance وprod_quality وdev_finance وهكذا
• تملك كل مجموعة مجال كتالوجاتها الخاصة
• مساءلة واضحة ونطاق تدقيق أنظف
• كتالوجات أكثر تحتاج إلى تسمية وربط ومنح صلاحيات

خياري الافتراضي هو المجال مع البيئة لأي شركة لديها أكثر من حفنة من فرق البيانات. يتطلب ذلك انضباطاً أكبر في التسمية منذ البداية. لكنه يوفّر الجدال بعد عامين حول من يملك الجدول الذي يستعلم عنه الجميع ولا يصونه أحد.

يتلخّص باقي التصميم في أربع قواعد:

1. تأتي المجموعات من مزوّد الهوية لديك. وفّر المستخدمين والمجموعات في حساب Databricks عبر الإدارة التلقائية للهوية، أو عبر SCIM إذا كان مزوّدك لا يدعمها. عرّف المجموعات في Microsoft Entra ID أو Okta أو ما يعادلهما، لا في Databricks. وحين يغادر أحدهم، يذهب الوصول مع حسابه في الدليل.
2. تملك المجموعات كائنات الإنتاج. توجيه Databricks نفسها هو إسناد ملكية الكتالوجات والمخططات الإنتاجية إلى مجموعات، لا إلى أفراد أبداً. فالمالك يستطيع منح الوصول، لذا فوجود شخص كمالك استثناء دائم.
3. اربط الكتالوجات بمساحات العمل. الكتالوج الإنتاجي المرتبط بمساحات عمل الإنتاج فقط لا يمكن الاستعلام عنه من بيئة تجريبية، أياً كانت الصلاحيات.
4. صنّف قبل أن تمنح. اتفق على مفردات وسوم قصيرة (الحساسية، والبيانات الشخصية، وضوابط التصدير، والنظام المصدر) كوسوم محكومة، واكتب سياسات ABAC بناءً عليها.

في التصنيع، نظّمت الكتالوجات حسب نظام المصنع، أي مجال OT والنظام المصدر، لا حسب المصنع. توجد بيانات OT من أنظمة historian وMES والحساسات في كتالوجاتها الخاصة، ويملكها فريق بيانات العمليات أو الهندسة. وتوجد بيانات IT من ERP (SAP أو Oracle أو Microsoft Dynamics 365) والجودة وسلسلة الإمداد في كتالوجات أخرى.

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

في برامج الدفاع، توقّع أن يطرح فريق الأمن أربعة أسئلة. من يستطيع رؤية البيانات الخاضعة لضوابط التصدير؟ وكيف تُفصل عن كل ما عداها؟

أين تُخزَّن؟ وهل يمكنك إثبات كل ذلك لأي يوم في العام الماضي؟

يجيب Unity Catalog عن معظمها، إذا صمّمت لذلك:

1. أقل الصلاحيات. لا صلاحيات على مستوى metastore أو الكتالوج لمجموعات واسعة. امنح الصلاحيات على مستوى المخطط لمجموعات مسمّاة، واستخدم أقنعة ABAC للأعمدة الموسومة كبيانات خاضعة للضوابط. ولا تستخدم سياسات DENY إلا بعد خروجها من Beta وقبول جهات الاعتماد لديك بها.
2. الفصل. كتالوجات منفصلة للبيانات الخاضعة للضوابط، بموقع تخزين مُدار خاص بها، مرتبطة بمساحات عمل مخصصة. توصي Databricks بالتخزين المُدار على مستوى الكتالوج كوحدة العزل الرئيسية، وهذا يناسب الحالة جيداً.
3. إقامة البيانات. metastore واحد لكل منطقة يعني أن البيانات تبقى في منطقة تخزينها ما لم يشاركها أحد. عامِل كل مشاركة OpenSharing وكل رابط عابر للمناطق على أنه قرار إقامة بيانات يحتاج إلى موافقة.
4. أدلة التدقيق. مسار البيانات مع system.access.audit، مُصدَّرين إلى نظام SIEM لديك، يمنحانك من وصل إلى ماذا وإلى أين ذهب. وتذكّر أن جدول التدقيق لا يزال في Public Preview. في عملي في الدفاع، أرادت فرق الأمن نسخ سجلات التدقيق إلى نظام SIEM الخاص بها، لا تركها في جداول نظام Databricks فقط. ابنِ هذه التغذية في الخطة من البداية.

لا يقرّر Unity Catalog ما يُعد بيانات سرية أو خاضعة لـ ITAR، ولا يحلّ محل الاعتماد الأمني. وبعض أحمال عمل الدفاع لا يمكن تشغيلها في منطقة سحابية تجارية إطلاقاً.

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

هذا هو الترتيب الذي أتبعه لشركة تنتقل من Hive metastore، أو تبدأ من الصفر.

1. اتفق على نموذج الكتالوجات واصطلاح التسمية. المجال مع البيئة، مكتوباً، ومعتمداً من مالكي البيانات. غيّره لاحقاً وستعيد تسمية كل شيء.
2. اربط مزوّد الهوية. توفير على مستوى الحساب، ومجموعات معرّفة في الدليل، وإيقاف SCIM على مستوى مساحة العمل لمساحات عمل Unity Catalog.
3. أعِدّ بيانات اعتماد التخزين والمواقع الخارجية. تملكها مجموعة المنصة. ولا يحصل أحد غيرها على CREATE EXTERNAL LOCATION.
4. أنشئ الكتالوجات بتخزين مُدار وربط بمساحات العمل. تملك المجموعات الكتالوجات الإنتاجية من اليوم الأول.
5. عرّف الوسوم المحكومة وفعّل تصنيف البيانات. راجع نتائجه قبل أن تكتب سياسات بناءً عليها.
6. اكتب سياسات ABAC للأعمدة الحساسة. اختبرها مع مستخدمين حقيقيين على كل نوع حوسبة تشغّله، بما في ذلك أي cluster لا يزال دون Runtime 16.4.
7. انتقل من Hive metastore. توصي Databricks الآن بعمل federation لـ Hive metastore أولاً، ثم ترقية الجداول في مكانها. تساعد UCX في البيئات الكبيرة لكنها مشروع من Databricks Labs، يصونه المجتمع بدلاً من أن يكون مدعوماً رسمياً. خطّط لذلك.
8. فعّل تصدير التدقيق ومراجعة مسار البيانات. امنح صلاحية القراءة على جداول النظام، وأعِدّ تغذية SIEM، واتفق على من يراجع ماذا.
9. عطّل الوصول إلى Hive metastore بمجرد اكتمال الانتقال، كي لا يبني أحد بصمت على المسار القديم.

1. منح الصلاحيات للأفراد. ينجح ذلك لأسبوع. ثم لا يستطيع أحد الإجابة عن من لديه وصول إلى ماذا.
2. كتالوج ضخم واحد بمخططات لكل فريق. تتداخل الملكية ونطاق التدقيق، وتعيد بناءه لاحقاً.
3. ترك الجداول خارجية "مؤقتاً". تخسر ميزات الجداول المُدارة ويبقى لكل ملف مالكان.
4. اختبار السياسات على نوع cluster واحد. يتصرف ABAC بشكل مختلف حسب الحوسبة؛ وتفشل الإصدارات القديمة من Runtime كلياً.
5. معاملة التدقيق كمرحلة لاحقة. سيسأل المدقق عن الفترة التي سبقت تفعيله.

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

وللصورة الأوسع، ابدأ بـفيمَ تُستخدم Databricks، واطّلع على تسعير Databricks قبل أن تحدد حجم serverless compute لـ ABAC. وإذا كنت تقارن بين المنصات، فإن مقارنتي بين Snowflake وDatabricks تغطي الحوكمة في الجانبين. أساعد المؤسسات في التصنيع والدفاع على اتخاذ قرارات التصميم هذه؛ وإذا كان رأي ثانٍ سيفيدك، احجز مكالمة.

ما هو Unity Catalog في Databricks؟

Unity Catalog هو طبقة الحوكمة في Databricks. يوفّر مكاناً واحداً لإدارة الوصول إلى الجداول وطرق العرض ووحدات تخزين الملفات والدوال ونماذج الذكاء الاصطناعي، ويلتقط مسار البيانات تلقائياً ويسجّل الوصول في جداول نظام التدقيق. وتُخاطَب الأصول بصيغة catalog.schema.object تحت metastore واحد لكل منطقة.

هل ABAC في Databricks متاح للعموم؟

نعم. أصبحت سياسات التحكم في الوصول القائم على السمات لفلاتر الصفوف وأقنعة الأعمدة متاحة للعموم في 28 أبريل 2026، كما أصبحت الوسوم المحكومة وتصنيف البيانات متاحة للعموم في أبريل 2026. أما سياسات DENY والسياسات على مستوى metastore والمصنّفات المخصصة فكانت لا تزال في Beta حتى أكتوبر 2026.

هل Delta Sharing هو نفسه OpenSharing؟

نعم. أعلنت Databricks عن OpenSharing في يونيو 2026 بوصفه التطور التالي لبروتوكول Delta Sharing، وتستضيفه الآن Linux Foundation، وقد امتد ليشمل أصول الذكاء الاصطناعي وعملاء Iceberg. وتصف وثائق Databricks المشاركة الآن تحت اسم OpenSharing.

هل أستخدم الجداول المُدارة أم الخارجية في Unity Catalog؟

الجداول المُدارة لكل البيانات الجديدة. توصي بها Databricks لأن Unity Catalog يدير حينها الملفات والصيانة وميزات الأداء. احتفظ بالجداول الخارجية فقط حيث يجب أن يملك نظام آخر الملفات أو أثناء ترقية Hive metastore، وخطّط لتحويلها.

كيف أنتقل من Hive metastore إلى Unity Catalog؟

توصي Databricks بعمل federation لـ Hive metastore ككتالوج أجنبي أولاً، ثم ترقية الجداول في مكانها دون نقل البيانات. وللبيئات الكبيرة، تقيّم أدوات UCX من Databricks Labs الجاهزية وتنقل المجموعات والصلاحيات والجداول، لكن UCX يصونها المجتمع بدلاً من أن تكون مدعومة رسمياً.

هل تُنظَّم الكتالوجات حسب البيئة أم حسب مجال الأعمال؟

لمعظم المؤسسات، كلاهما: كتالوج واحد لكل مجال في كل بيئة، مثل prod_finance وdev_finance. يمنح ذلك كل مجموعة مجال ملكية واضحة ونطاق تدقيق نظيفاً. ويمكن للفرق الأصغر البدء بكتالوج واحد لكل بيئة ومخططات لكل مجال.