こちらの機能の存在は知っていたのですが、触ったことがなかったので触ります。
プレビュー
本機能はパブリックプレビューです。
Databricksアセットバンドルとは
マニュアルにはいろいろ書いてありますが、私の理解はこちらです。
- Databricksのノートブックのみならず、クラスターやジョブ、モデルレジストリの構成などもコードで管理してDatabricksワークスペースにデプロイする仕組み。
- これによって、ノートブック(ソースコード)やクラスターやジョブの構成もGitHubなどのバージョン管理ツールで管理できるようになる。これがすなわち、Infrastructure as Code(IaC)。
- Terraformはインフラの管理が対象ですが、こちらではソースコードも一緒にGitHubで管理できるとのこと。
動かしてみる
触ってみます。以下のチュートリアルの方がデプロイまでカバーしていますのでこちらを。
Databricks CLIのインストール
アセットバンドルの作成、デプロイなどはDatabricks CLIから行います。最新のバージョンになっていなければアップグレードします。
databricks -v
Databricks CLI バージョン 0.205が必要なので要件を満たしています。
Databricks CLI v0.212.3
認証設定
開発マシンからDatabricksワークスペースに接続するために認証を行います。
databricks auth login --host https://<ワークスペースのホスト名>
上を実行すると、ブラウザが開くのでDatabricksワークスペースにログインします。ログインに成功すると以下のような画面が表示されます。
CLIのプロファイルとして保存されます。
✔ Databricks Profile Name: <プロファイル名>
Profile <プロファイル> was successfully saved
バンドルの作成
テンプレートが用意されているとのことなので、そちらを使います。
databricks bundle init
カーソルを上下されることでテンプレートを選択します。default-python
を選びます。
プロジェクト名はデフォルトのままにします。
サンプルノートブックのみを作るので、yes -> no -> noと答えます。
Unique name for this project [my_project]:
Include a stub (sample) notebook in 'my_project/src': yes
Include a stub (sample) Delta Live Tables pipeline in 'my_project/src': no
Include a stub (sample) Python package in 'my_project/src': no
Workspace to use (auto-detected, edit in 'my_project/databricks.yml'): https://<ワークスペースホスト名>
✨ Your new project has been created in the 'my_project' directory!
注意
上でWorkspace to useが自動検知されますが、使いたいワークスペースではない場合は'my_project/databricks.ymlを編集する必要があります。CLIのDEFAULTプロファイルが選択されます。
私の場合はワークスペースのURLを切り替えたかったので、databricks.ymlのhostを変更しました。
# This is a Databricks asset bundle definition for my_project.
# See https://docs.databricks.com/dev-tools/bundles/index.html for documentation.
bundle:
name: my_project
include:
- resources/*.yml
targets:
# The 'dev' target, for development purposes. This target is the default.
dev:
# We use 'mode: development' to indicate this is a personal development copy:
# - Deployed resources get prefixed with '[dev my_user_name]'
# - Any job schedules and triggers are paused by default
# - The 'development' mode is used for Delta Live Tables pipelines
mode: development
default: true
workspace:
host: https://<ワークスペースのホスト名>
## Optionally, there could be a 'staging' target here.
## (See Databricks docs on CI/CD at https://docs.databricks.com/dev-tools/bundles/index.html.)
#
# staging:
# workspace:
# host: https://<ワークスペースのホスト名>
# The 'prod' target, used for production deployment.
prod:
# We use 'mode: production' to indicate this is a production deployment.
# Doing so enables strict verification of the settings below.
mode: production
workspace:
host: https://<ワークスペースのホスト名>
# We always use /Users/takaaki.yayoi@databricks.com for all resources to make sure we only have a single copy.
# If this path results in an error, please make sure you have a recent version of the CLI installed.
root_path: /Users/takaaki.yayoi@databricks.com/.bundle/${bundle.name}/${bundle.target}
run_as:
# This runs as takaaki.yayoi@databricks.com in production. We could also use a service principal here,
# see https://docs.databricks.com/dev-tools/bundles/permissions.html.
user_name: takaaki.yayoi@databricks.com
テンプレートを検証します。デフォルトではプロファイルDEFAULTが使用されるので、私は明示的に使いたいプロファイルを指定しています。
cd my_project
databricks bundle validate --profile <プロファイル名>
{
"bundle": {
"name": "my_project",
"target": "dev",
"environment": "dev",
"terraform": {
"exec_path": "/Users/takaaki.yayoi/my_project/.databricks/bundle/dev/bin/terraform"
},
"lock": {},
"git": {
"bundle_root_path": "."
},
"mode": "development"
},
"include": [
"resources/my_project_job.yml"
],
"workspace": {
"host": ...略...
},
"sync": {}
}
って、上見たらデプロイにはterraform使ってますね。
ローカルプロジェクトをDatabricksワークスペースにデプロイ
その前にデプロイ先がAWSのDatabricksの場合には修正が必要です。上のテンプレートではジョブクラスターを作成するのですがその際のインスタンス指定がStandard_D3_v2となっており、Azure前提となっています。
以下のようにnode_type_idをi3.xlargeに変更します。ローカルプロジェクトのディレクトリ構造を見ていると何をデプロイするのかが分かってきます。
# The main job for my_project.
resources:
jobs:
my_project_job:
name: my_project_job
schedule:
# Run every day at 8:37 AM
quartz_cron_expression: '44 37 8 * * ?'
timezone_id: Europe/Amsterdam
email_notifications:
on_failure:
- takaaki.yayoi@databricks.com
tasks:
- task_key: notebook_task
job_cluster_key: job_cluster
notebook_task:
notebook_path: ../src/notebook.ipynb
job_clusters:
- job_cluster_key: job_cluster
new_cluster:
spark_version: 13.3.x-scala2.12
node_type_id: i3.xlarge
autoscale:
min_workers: 1
max_workers: 4
デプロイします。-tスイッチでターゲットのワークスペースを指定しています。すなわち、これを切り替えることで開発環境へのデプロイやプロダクション環境へのデプロイを制御できるわけですね。
databricks bundle deploy -t dev --profile <プロファイル名>
注意
デプロイを行うユーザーは認証設定でログインに用いたユーザーが使用されます。
Uploading bundle files to /Users/<ユーザー名>/.bundle/my_project/dev/files...
Deploying resources...
Updating deployment state...
Deployment complete!
ワークスペースを見るとリソースがデプロイされています。
ジョブも作成されています！
デプロイしたプロジェクトの実行
なんとローカルからジョブも実行できます。
databricks bundle run -t dev my_project_job --profile <プロファイル名>
ジョブが起動しました！
ジョブが完了しました！(うるさい)
ローカル側でも進捗が表示されます。
Run URL: https://<ワークスペースホスト名>/?o=791148388305836#job/509846911203305/run/634811057107698
2024-02-06 20:12:37 "[dev ...] my_project_job" RUNNING
2024-02-06 20:17:56 "[dev ...] my_project_job" TERMINATED SUCCESS
クリーンアップ
ワークスペースからデプロイしたバンドルを削除します。
databricks bundle destroy --profile <プロファイル名>
ジョブの削除確認メッセージが表示されますので、yを押します。
ワークスペース上のバンドル削除確認メッセージが出るのでyを押します。
これでクリーンアップされました。
Deleted snapshot file at /Users/takaaki.yayoi/my_project/.databricks/bundle/dev/sync-snapshots/f710b353e97d0b24.json
Successfully deleted files!
Destroy complete!
その他のリソース
インフラだけでなくコンテンツたるソースコードやモデルなどもコントロールできるところがミソですかね。今後、他のサンプルも動かしてみます。