メインコンテンツまでスキップ

dbx からバンドルへの移行

important

Databricks では、Databricks Labs が dbx する代わりに、Databricks アセット バンドルを使用することをお勧めします。 dbxに関する関連記事は廃止されており、更新されない可能性があります。

この記事では、Databricks Labs が dbx するプロジェクトを Databricks アセット バンドルに移行する方法について説明します。 「Databricks Labs による dbx の概要」および「Databricks アセットバンドルとは」を参照してください。

移行する前に、 dbx by Databricks Labs と Databricks アセット バンドルの次の制限事項と機能の比較に注意してください。

機能の比較​

移行する前に、 dbx by Databricks Labs の次の機能が Databricks アセット バンドルにどのように実装されているかに注意してください。

テンプレートとプロジェクト​

dbx Jinjaテンプレートのサポートを提供します。デプロイメント設定に Jinja テンプレートを含め、環境変数をインラインまたは変数ファイルを介して渡すことができます。 推奨されませんが、 dbx はカスタムユーザー関数の実験的なサポートも提供しています。

バンドルは、構成を再利用するための Go テンプレート のサポートを提供します。 ユーザーは、事前に作成されたテンプレートに基づいてバンドルを作成できます。 テンプレートには、カスタムユーザー関数を除いて、ほぼ完全なパリティがあります。

ビルド管理​

dbx は、 pip wheel、Poetry、Flitを通じてビルドサポートを提供します。 ユーザーは、プロジェクトのdeployment.ymlファイルのbuildセクションでビルドオプションを指定できます。

バンドルを使用すると、ユーザーは Python wheel ファイルをビルド、デプロイ、および実行できます。 ユーザーは、バンドルの databricks.yml ファイル内の組み込み whl エントリを活用できます。

コードの同期、デプロイ、実行​

dbx を使用すると、Databricks ジョブなどのワークスペース リソースの生成とは別に コードをアップロード できます。

バンドルは、常に コードをアップロードし、ワークスペース リソースを作成または更新 します。 これにより、デプロイが簡素化され、すでに進行中のジョブのブロック条件を回避できます。

dbx プロジェクトのバンドルへの移行​

前述の制限事項と、 dbx by Databricks Labs と Databricks Asset Bundle の機能比較を確認したら、 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 ワークスペースでの認証用に Databricks CLI を設定します (たとえば、 Databricks 個人用アクセス トークン認証を使用します)。 その他の Databricks 認証の種類については、「 Databricks CLI の認証」を参照してください。

ステップ 2: バンドル設定ファイルを作成する​

Visual Studio Code、PyCharm Professional、IntelliJ IDEA Ultimate など、YAML ファイルや JSON スキーマ ファイルをサポートする IDE を使用している場合は、次のように、バンドル設定ファイルを作成するだけでなく、ファイルの構文やフォーマットを確認したり、コード補完のヒントを提供したりするためにも、IDE を使用できます。

  1. Add YAML language server support to Visual Studio Code, for example by installing the YAML extension from the Visual Studio Code Marketplace.

  2. Generate the Databricks Asset Bundle configuration JSON schema file by using the Databricks CLI to run the bundle schema command and redirect the output to a JSON file. For example, generate a file named bundle_config_schema.json within the current directory, as follows:

    Bash
    databricks bundle schema > bundle_config_schema.json

  3. Use Visual Studio Code to create or open a bundle configuration file within the current directory. By convention, this file is named databricks.yml.

  4. Add the following comment to the beginning of your bundle configuration file:

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

In the preceding comment, if your Databricks Asset Bundle configuration JSON schema file is in a different path, replace bundle_config_schema.json with the full path to your schema file.

  1. Use the YAML language server features that you added earlier. For more information, see your YAML language server’s documentation.

ステップ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: バンドルを検証する​

アーティファクトをデプロイする前、または Databricks ジョブ、DLT パイプライン、または MLOps パイプラインを実行する前に、バンドル設定ファイルの構文が正しいことを確認する必要があります。 これを行うには、バンドル ルートから bundle validate コマンドを実行します。

Bash
databricks bundle validate

bundle validateに関する情報については、「バンドルの検証」を参照してください。

ステップ 6: バンドルをデプロイする​

指定したローカル アーティファクトをリモート ワークスペースにデプロイするには、バンドル ルートから bundle deploy コマンドを実行します。 コマンド・オプションが指定されていない場合は、バンドル構成ファイルで宣言されているデフォルト・ターゲットが使用されます。

Bash
databricks bundle deploy

特定のターゲットのコンテキスト内でアーティファクトをデプロイするには、バンドル構成ファイル内で宣言されているターゲットの名前とともに、 -t (または --target) オプションを指定します。 たとえば、 developmentという名前で宣言されたターゲットの場合、次のようになります。

Bash
databricks bundle deploy -t development

bundle deployに関する情報については、「バンドルのデプロイ」を参照してください。

ヒント

バンドル定義のジョブとパイプラインを Databricks ワークスペース内の既存のジョブとパイプラインにリンクして、同期を維持できます。 バンドル・リソースのバインドを参照してください。

ステップ 7: バンドルを実行する​

特定のジョブまたはパイプラインを実行するには、バンドル ルートから bundle run コマンドを実行します。 バンドル設定ファイル内で宣言されているジョブまたはパイプラインを指定する必要があります。 -t オプションが指定されていない場合は、バンドル構成ファイル内で宣言されているデフォルト・ターゲットが使用されます。たとえば、デフォルトターゲットのコンテキスト内で hello_job という名前のジョブを実行するには、次のようにします。

Bash
databricks bundle run hello_job

developmentという名前で宣言されたターゲットのコンテキスト内で hello_job という名前のジョブを実行するには、次のようにします。

Bash
databricks bundle run -t development hello_job

bundle runに関する情報については、「ジョブまたはパイプラインの実行」を参照してください。

(オプション)ステップ 8: GitHub で CI/CD のバンドルを構成する​

CI/CD に GitHub を使用する場合は、GitHub Actions を使用して、特定の GitHub ワークフロー イベントやその他の条件に基づいて、 databricks bundle deploy コマンドと databricks bundle run コマンドを自動的に実行できます。 「Databricks アセット バンドルと GitHub Actions を使用して CI/CD ワークフローを実行する」を参照してください。

dbx プロジェクト設定の databricks.yml への変換​

dbxの場合、プロジェクト設定は、デフォルトではプロジェクトの .dbx フォルダー内の project.json という名前のファイルにあります。「プロジェクト ファイル参照」を参照してください。

バンドルの場合、バンドル構成は、デフォルトではバンドルのルートフォルダ内の databricks.yml という名前のファイルにあります。 「Databricks アセット バンドルの構成」を参照してください。

次の例の内容を含む conf/project.json ファイルの場合:

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 ファイルは次のとおりです。

YAML
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 ファイルの場合:

YAML
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 ファイルは次のとおりです。

YAML
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ファイルではサポートされておらず、特に明記されていない限り回避策はありません。

  • access_control_list
  • custom (代わりに標準のYAMLアンカーを使用してください)
  • deployment_config
  • Databricks ジョブ 2.0 形式 (代わりにジョブ 2.1 形式を使用)
  • dbx Jinja の特徴
  • 名前ベースのプロパティ
に最終更新