مشاركة عبر

الترحيل من dbx إلى الحزم

  • مقالة

هام

توصي Databricks باستخدام حزم أصول Databricks بدلا من dbx Databricks Labs. تم إيقاف المقالات ذات الصلة حول dbx وقد لا يتم تحديثها.

توضح هذه المقالة كيفية ترحيل المشاريع ل dbx بواسطة Databricks Labs إلى Databricks Asset Bundles. راجع مقدمة إلى dbx بواسطة Databricks Labs وما هي حزم أصول Databricks؟.

قبل الترحيل، لاحظ القيود التالية ومقارنات الميزات بين dbx بواسطة Databricks Labs وDatabricks Asset Bundles.

القيود

الوظائف التالية المدعومة في dbx Databricks Labs محدودة أو غير موجودة أو تتطلب حلولا بديلة في Databricks Asset Bundles.

  • إنشاء البيانات الاصطناعية JAR غير مدعوم في الحزم.
  • رمز FUSE لمسارات مساحة العمل غير معتمد في الحزم (على سبيل المثال، /Workspace/<path>/<filename>). ومع ذلك، يمكنك إرشاد الحزم لإنشاء مسارات مساحة عمل على غرار FUSE أثناء عمليات النشر باستخدام تدوين مثل /Workspace/${bundle.file_path}/<filename>.

مقارنات الميزات

قبل الترحيل، لاحظ كيفية تنفيذ الميزات التالية ل dbx Databricks Labs في Databricks Asset Bundles.

القوالب والمشاريع

dbx توفير الدعم ل Templating Jinja. يمكنك تضمين قوالب Jinja في تكوين النشر وتمرير متغيرات البيئة إما مضمنة أو من خلال ملف متغيرات. على الرغم من عدم الموصى به، dbx يوفر أيضا دعما تجريبيا لوظائف المستخدم المخصصة.

توفر الحزم الدعم لقوالب Go لإعادة استخدام التكوين. يمكن للمستخدمين إنشاء مجموعات استنادا إلى قوالب تم إنشاؤها مسبقا. هناك تماثل كامل تقريبا ل templating، باستثناء وظائف المستخدم المخصصة.

بناء الإدارة

dbx يوفر دعم البناء من خلال pip wheelوالشعر وFlit. يمكن للمستخدمين تحديد خيار الإنشاء في build قسم من ملف المشروع deployment.yml .

تمكن الحزم المستخدمين من إنشاء ملفات عجلة Python ونشرها وتشغيلها. يمكن للمستخدمين الاستفادة من الإدخال المضمن في whl ملف المجموعة databricks.yml .

مزامنة التعليمات البرمجية ونشرها وتشغيلها

dbx تمكين تحميل التعليمات البرمجية بشكل منفصل عن إنشاء موارد مساحة العمل مثل وظائف Azure Databricks.

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

ترحيل مشروع dbx إلى مجموعة

بعد ملاحظة القيود السابقة ومقارنات الميزات بين dbx Databricks Labs وDatabricks Asset Bundles، فأنت جاهز للترحيل من dbx إلى الحزم.

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

الخطوة 1: تثبيت Databricks CLI وإعداده

تتوفر حزم أصول Databricks بشكل عام في Databricks CLI الإصدار 0.218.0 وما فوق. إذا قمت بالفعل بتثبيت وإعداد Databricks CLI الإصدار 0.218.0 أو أعلى، فانتقل إلى الخطوة 2.

إشعار

الحزم غير متوافقة مع إصدارات Databricks CLI 0.18 والإصدارات أدناه.

  1. تثبيت أو تحديث إلى Databricks CLI الإصدار 0.218.0 أو أعلى. راجع تثبيت Databricks CLI أو تحديثه.
  2. قم بإعداد Databricks CLI للمصادقة مع مساحات عمل Azure Databricks المستهدفة، على سبيل المثال باستخدام مصادقة رمز الوصول الشخصي Azure Databricks. بالنسبة إلى أنواع مصادقة Azure Databricks الأخرى، راجع المصادقة ل Databricks CLI.

الخطوة 2: إنشاء ملف تكوين المجموعة

إذا كنت تستخدم IDE مثل Visual Studio Code أو PyCharm Professional أو IntelliJ IDEA Ultimate الذي يوفر الدعم لملفات YAML وملفات مخطط JSON، يمكنك استخدام IDE الخاص بك ليس فقط لإنشاء ملف تكوين المجموعة ولكن للتحقق من بناء جملة الملف وتنسيقه وتوفير تلميحات إكمال التعليمات البرمجية، كما يلي.

تعليمة Visual Studio برمجية

  1. أضف دعم خادم لغة YAML إلى Visual Studio Code، على سبيل المثال عن طريق تثبيت ملحق YAML من Visual Studio Code Marketplace.

  2. إنشاء ملف مخطط JSON لتكوين مجموعة أصول Databricks باستخدام Databricks CLI لتشغيل bundle schema الأمر وإعادة توجيه الإخراج إلى ملف JSON. على سبيل المثال، قم بإنشاء ملف باسم bundle_config_schema.json داخل الدليل الحالي، كما يلي:

    databricks bundle schema > bundle_config_schema.json

  3. استخدم Visual Studio Code لإنشاء ملف تكوين مجموعة أو فتحه داخل الدليل الحالي. حسب الاصطلاح، يسمى databricks.ymlهذا الملف .

  4. أضف التعليق التالي إلى بداية ملف تكوين المجموعة:

    # yaml-language-server: $schema=bundle_config_schema.json

    إشعار

    في التعليق السابق، إذا كان ملف مخطط JSON لتكوين Databricks Asset Bundle في مسار مختلف، فاستبدل bundle_config_schema.json بالمسار الكامل لملف المخطط الخاص بك.

  5. استخدم ميزات خادم لغة YAML التي أضفتها سابقا. لمزيد من المعلومات، راجع وثائق خادم لغة YAML.

PyCharm Professional

  1. إنشاء ملف مخطط JSON لتكوين مجموعة أصول Databricks باستخدام Databricks CLI لتشغيل bundle schema الأمر وإعادة توجيه الإخراج إلى ملف JSON. على سبيل المثال، قم بإنشاء ملف باسم bundle_config_schema.json داخل الدليل الحالي، كما يلي:

    databricks bundle schema > bundle_config_schema.json

  2. قم بتكوين PyCharm للتعرف على ملف مخطط JSON لتكوين المجموعة، ثم أكمل تعيين مخطط JSON، باتباع الإرشادات الواردة في تكوين مخطط JSON مخصص.

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

IntelliJ IDEA Ultimate

  1. إنشاء ملف مخطط JSON لتكوين مجموعة أصول Databricks باستخدام Databricks CLI لتشغيل bundle schema الأمر وإعادة توجيه الإخراج إلى ملف JSON. على سبيل المثال، قم بإنشاء ملف باسم bundle_config_schema.json داخل الدليل الحالي، كما يلي:

    databricks bundle schema > bundle_config_schema.json

  2. قم بتكوين IntelliJ IDEA للتعرف على ملف مخطط JSON لتكوين المجموعة، ثم أكمل تعيين مخطط JSON، باتباع الإرشادات الواردة في تكوين مخطط JSON مخصص.

  3. استخدم IntelliJ IDEA لإنشاء ملف تكوين مجموعة أو فتحه. حسب الاصطلاح، يسمى databricks.ymlهذا الملف . أثناء الكتابة، يتحقق IntelliJ IDEA من بناء جملة مخطط JSON وتنسيقه ويوفر تلميحات إكمال التعليمات البرمجية.

الخطوة 3: تحويل إعدادات مشروع dbx إلى databricks.yml

قم بتحويل الإعدادات الموجودة في dbx ملف المشروع .dbx/project.json إلى الإعدادات المكافئة في ملف الحزمة databricks.yml . للحصول على التفاصيل، راجع تحويل إعدادات مشروع dbx إلى databricks.yml.

الخطوة 4: تحويل إعدادات نشر dbx إلى databricks.yml

قم بتحويل الإعدادات الموجودة في dbx مجلد المشروع conf إلى الإعدادات المكافئة في ملف الحزمة databricks.yml . للحصول على التفاصيل، راجع تحويل إعدادات نشر dbx إلى databricks.yml.

الخطوة 5: التحقق من صحة المجموعة

قبل نشر البيانات الاصطناعية أو تشغيل مهمة Azure Databricks أو مسار Delta Live Tables أو مسار MLOps، يجب التأكد من أن ملف تكوين الحزمة الخاص بك صحيح من الناحية التركيبية. للقيام بذلك، قم بتشغيل bundle validate الأمر من جذر الحزمة:

databricks bundle validate

للحصول على معلومات حول bundle validate، راجع التحقق من صحة مجموعة.

الخطوة 6: نشر الحزمة

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

databricks bundle deploy

لنشر البيانات الاصطناعية ضمن سياق هدف معين، حدد -t الخيار (أو --target) جنبا إلى جنب مع اسم الهدف كما هو معلن داخل ملف تكوين المجموعة. على سبيل المثال، بالنسبة إلى هدف تم الإعلان عنه باسم development:

databricks bundle deploy -t development

للحصول على معلومات حول bundle deploy، راجع نشر مجموعة.

تلميح

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

الخطوة 7: تشغيل الحزمة

لتشغيل مهمة أو مسار معين، قم بتشغيل bundle run الأمر من جذر الحزمة. يجب تحديد المهمة أو المسار المعلن داخل ملف تكوين الحزمة. -t إذا لم يتم تحديد الخيار، يتم استخدام الهدف الافتراضي كما هو معلن داخل ملف تكوين المجموعة. على سبيل المثال، لتشغيل مهمة مسماة hello_job ضمن سياق الهدف الافتراضي:

databricks bundle run hello_job

لتشغيل مهمة مسماة hello_job ضمن سياق هدف تم الإعلان عنه بالاسم development:

databricks bundle run -t development hello_job

للحصول على معلومات حول bundle run، راجع تشغيل مهمة أو مسار.

(اختياري) الخطوة 8: تكوين الحزمة ل CI/CD باستخدام GitHub

إذا كنت تستخدم GitHub ل CI/CD، يمكنك استخدام إجراءات GitHub لتشغيل databricks bundle deploy الأمرين و databricks bundle run تلقائيا، استنادا إلى أحداث سير عمل GitHub المحددة ومعايير أخرى. راجع تشغيل سير عمل CI/CD باستخدام مجموعة أصول Databricks وإجراءات GitHub.

تحويل إعدادات مشروع dbx إلى databricks.yml

بالنسبة إلى dbx، تكون إعدادات المشروع بشكل افتراضي في ملف مسمى project.json في مجلد المشروع .dbx . راجع مرجع ملف المشروع.

بالنسبة إلى الحزم، تكون تكوينات الحزمة بشكل افتراضي في ملف يسمى databricks.yml داخل المجلد الجذر للحزمة. راجع تكوين مجموعة أصول Databricks.

conf/project.json لملف يحتوي على محتوى المثال التالي:

{
  "environments": {
    "default": {
      "profile": "charming-aurora",
      "storage_type": "mlflow",
      "properties": {
        "workspace_directory": "/Workspace/Shared/dbx/charming_aurora",
        "artifact_location": "/Workspace/Shared/dbx/projects/charming_aurora"
      }
    }
  },
  "inplace_jinja_support": true
}

الملف المقابل databricks.yml كما يلي:

bundle:
  name: <some-unique-bundle-name>

targets:
  default:
    workspace:
      profile: charming-aurora
      root_path: /Shared/dbx/charming_aurora
      artifact_path: /Shared/dbx/projects/charming_aurora
    resources:
      # See an example "resources" mapping in the following section.

الكائنات التالية في الملف السابق conf/project.json لهذا المثال غير معتمدة في databricks.yml الملفات وليس لها حلول بديلة:

  • inplace_jinja_support
  • storage_type

الكائنات الإضافية المسموح بها التالية في conf/project.json الملفات غير معتمدة في databricks.yml الملفات وليس لها حلول بديلة:

  • enable-context-based-upload-for-execute
  • enable-failsafe-cluster-reuse-with-assets

تحويل إعدادات نشر dbx إلى databricks.yml

بالنسبة إلى dbx، تكون إعدادات النشر بشكل افتراضي في ملف داخل مجلد المشروع conf . راجع مرجع ملف النشر. يحتوي ملف إعدادات النشر بشكل افتراضي على أحد أسماء الملفات التالية:

  • deployment.yml
  • deployment.yaml
  • deployment.json
  • deployment.yml.j2
  • deployment.yaml.j2
  • deployment.json.j2

بالنسبة إلى الحزم، تكون إعدادات النشر بشكل افتراضي في ملف مسمى databricks.yml داخل المجلد الجذر للحزمة. راجع تكوين مجموعة أصول Databricks.

conf/deployment.yml لملف يحتوي على محتوى المثال التالي:

build:
  python: "pip"

environments:
  default:
    workflows:
      - name: "workflow1"
        tasks:
          - task_key: "task1"
            python_wheel_task:
              package_name: "some-pkg"
              entry_point: "some-ep"

الملف المقابل databricks.yml كما يلي:

bundle:
  name: <some-unique-bundle-name>

targets:
  default:
    workspace:
      # See an example "workspace" mapping in the preceding section.
    resources:
      jobs:
        workflow1:
          tasks:
            - task_key: task1
              python_wheel_task:
                package_name: some-pkg
                entry_point: some-ep

الكائن التالي في الملف السابق conf/deployment.yml لهذا المثال غير معتمد في databricks.yml الملفات وليس لديه حلول بديلة:

الكائنات والوظائف الإضافية المسموح بها التالية في conf/deployment.yml الملفات غير معتمدة في databricks.yml الملفات وليس لها حلول بديلة ما لم يذكر خلاف ذلك: