databricks-serverless

サーバーレスで Databricks のジョブとパイプラインをデプロイする

最初に：CLI の基本、認証、プロファイルの選択については、親の databricks-core スキルを使用してください。

このスキルではコンピュートを決定します。別のスキルや例（たとえば databricks-jobs）で クラスター構成が示されている場合は、代わりにこのスキルに従ってください。

作成するすべてのジョブ、パイプライン、バンドルでは、サーバーレスがデフォルトのコンピュートです。ユーザーが 明示的にクラスターを求めた場合は、その要望に従い、サーバーレスの選択肢について一文で触れてください。 既存のジョブを編集する場合は、ユーザーが変更を求めない限り、コンピュートを維持してください。追加するタスクには このスキルを適用してください。

1. サーバーレスかクラシックか

次の場合に限り、クラシックコンピュートを使用してください。

• R コード、またはノートブックセル内の Scala（%scala）：サーバーレスのノートブックで実行できるのは Python と SQL のみです。
• カスタム Docker イメージ
• OS パッケージ（apt-get）または pip で代替できないネイティブライブラリ
• カスタム Spark データソース JAR
• インスタンスタイプまたは Databricks Runtime バージョンに関する明確な必須要件
• ユーザーからの明示的なリクエスト
• セクション 5 の予算を超える既存コード
• サーバーレスを利用できないワークスペース：サーバーレスが利用できないためにジョブの作成または実行に失敗した場合は、ジョブ全体をクラシックにし、その旨を伝えてください。

その場合は、ブロックされているタスクだけにクラスターを割り当て（最新の LTS ランタイムと autoscale: {min_workers: 1, max_workers: 4} を指定した小規模な job_clusters エントリを 1 つ）、その他のすべてのタスクはサーバーレスのままにし、 ブロック要因を一文で伝えてください。ブロックされているパイプラインの場合は、serverless: true の代わりに パイプラインに clusters ブロックを指定してください。

クラシックを使う理由にならないもの：JAR タスク内の Scala または Java（JAR タスクはサーバーレスで実行されます）、GPU（サーバーレス GPU）、 大量のデータ、長い実行時間、Kafka、コスト（サーバーレス STANDARD はほとんどの場合、オンデマンドのクラシックと同等か安価です）、または 慣習。

2. すべてのタスクをサーバーレスにする

• 新規ジョブ： new_cluster、job_clusters、job_cluster_key、existing_cluster_id、 instance_pool_id、node_type_id、num_workers、autoscale、spark_version を省略してください。クラスターの指定がないタスクは サーバーレスで実行されます。既存のジョブでは、現在のクラスター設定を維持してください。
• ノートブックタスクには、ほかに何も必要ありません。Python スクリプト、wheel、JAR タスクは、ジョブレベルの環境からライブラリを 取得します。ワークスペースで提供されている最新の環境バージョンを、引用符で囲んだ文字列として使用してください。

  environments:
    - environment_key: default
      spec:
        environment_version: "4"                # example; use the latest
        dependencies: ["requests==2.32.3"]   # pin versions; JARs go in java_dependencies
  tasks:
    - task_key: main
      spark_python_task: {python_file: /Workspace/.../main.py}
      environment_key: default
  

• **SQL タスク：**サーバーレス SQL ウェアハウス。パイプライン：serverless: true を指定し、clusters ブロックは指定しません。
• **ストリーミング：**サーバーレスでサポートされているトリガーである .trigger(availableNow=True) を使用してください（processingTime または continuous トリガーは使用しません）。常時稼働の処理には、次の実行が前の実行の完了直後に開始される連続ジョブ （continuous: {pause_status: UNPAUSED}）でそのストリームを実行するか、連続パイプラインを使用してください。
• **作成するすべてのジョブにタグを付けてください。**これは、ほかの Databricks スキルと同様に、リソース追跡のためです。ジョブレベルの tags: {"aidevkit_project": "ai-dev-kit"} を指定してください。ユーザーがすでに設定しているタグは維持してください。

3. パフォーマンスモードを選択する

ジョブレベルの performance_target を設定してください。

• STANDARD：時間が重要でなく、速度よりコストを重視する場合に使用します。スケジュールされたバッチや ETL、夜間または週次の実行、あるいはユーザーがレイテンシの要件はないと述べたジョブが該当します。実行の開始には秒ではなく分単位でかかりますが、コストは低くなります。これがデフォルトの選択です。
• PERFORMANCE_OPTIMIZED：ユーザーが SLA を明示した場合、実行時間に対して厳しい期限がある場合、結果を人が待っている場合、またはジョブが 30 分ごと以上の頻度で実行される場合に限り使用してください。

performance_target はノートブックタスクを含むジョブ全体に適用されます（インタラクティブノートブックのみ、常にパフォーマンス最適化モードで実行されます）。選択したモードとその理由を一文で伝えてください。例：「STANDARD：期限のない夜間バッチです。」 サーバーレス GPU タスクでは performance_target は無視されます。

パイプラインには独自の performance_target はありません。パイプラインをスケジュールするには、 ジョブから pipeline_task でトリガーし、そのジョブにモードを設定してください。ジョブのモードはパイプラインの更新に適用されます。 連続パイプラインが STANDARD で実行されるのは、連続ジョブから実行される場合のみです。

4. 作成したコードは、最初からサーバーレスで実行されます

サーバーレスでは、Unity Catalog テーブル、/Volumes/... パス、Unity Catalog の外部ロケーションの背後にあるクラウドパス、dbfs:/databricks-datasets/ 配下のサンプルデータを読み取れます。DBFS マウント（dbfs:/mnt/...）やその他の DBFS ルートパスは読み取れません。DBFS がブロッカーとなるのは、これらの場合のみです。

DataFrame API と SQL API のみを使用します（RDD、sc.*、spark.sparkContext は使用しません）。Unity Catalog の3つの要素からなるテーブル名を使用します。DBFS マウント（dbfs:/mnt/...）ではなく、/Volumes/... パスを使用します。ストリーミングトリガーには availableNow を使用します。.cache() や .persist() は使用しません。エグゼキューター、ドライバー、メモリ設定に spark.conf.set は使用しません。依存関係は環境で固定し、init スクリプトは使用しません。

5. 既存コード：移行ではなく、手短な確認

ユーザーはデプロイを待っています。短時間で一度だけ確認し、その後デプロイしてください。

1. ジョブが実行するファイルだけをスキャンします（grep や rg などのテキスト検索を使用し、リポジトリ全体は読み込まないでください）。対象は次のとおりです：sc., sparkContext, .rdd, parallelize, mapPartitions, reduceByKey, groupByKey, dbfs:/, /dbfs/, dbutils.fs.mount, .cache(, .persist(, spark.conf.set, processingTime, continuous=, writeStream, hive_metastore., GLOBAL TEMP, hivevar, init_scripts, apt-get, docker、 および他の言語：マジック全体が %scala または %r のもの（%run ではなく # MAGIC %r）、.r ファイルと R ノートブック、SparkR、sparklyr。R と Scala のセルはクラシックに回します（セクション 1）。

2. 軽微なブロッカー：修正が機械的かつ局所的で、ロジックを維持し、新しいインフラストラクチャを必要とせず、合計で小さな編集が約 5 件以下の場合は、修正してサーバーレスにデプロイします：

   • .cache()、.persist()、.unpersist()、setLogLevel、executor／driver／AQE の spark.conf.set 行を削除する
   • pip install または requirements.txt を、バージョンを固定したうえで環境に移す
   • トリガーを設定していないストリームに .trigger(availableNow=True) を追加する。ただし、いずれにせよスケジュールで実行されるジョブに限ります（processingTime または continuous トリガーを使うストリームはステップ 4 のブロッカーです）
   • dbfs:/mnt/... パスの代わりに /Volumes/... パスを使うのは、そのボリュームのストレージ場所がマウント元と同じで、ジョブが同じデータを読み取る場合に限ります。名前が似たボリュームでは不十分です。それ以外の場合、マウントはステップ 4 のブロッカーです。
   • 同じファイル内でビューを作成して読み取る場合は、CREATE GLOBAL TEMP VIEW を CREATE TEMP VIEW に、global_temp.<view> での読み取りを <view> に変更します（サーバーレスにはグローバル一時ビューがありません）。別のタスクまたはノートブックがグローバル一時ビューを読み取る場合は、ステップ 4 のブロッカーです。
   • 2 部構成のテーブル名にカタログを追加するのは、そのテーブルを含む Unity Catalog カタログが分かっている場合に限ります（たとえば、ジョブのデフォルトカタログ）。hive_metastore 内のテーブルはステップ 4 のブロッカーです。

   返信には、実施した編集をすべて記載してください。

3. RDD または SparkContext のコード：以下の条件をすべて満たす場合に限り、DataFrame に変換してサーバーレスにデプロイします：

   • ファイルが 1 つで、行数が約 200 行以下である
   • 変更が純粋な API の変換であり、同じロジックを DataFrame または SQL で表現する
   • すべての入力パス、テーブル、出力テーブル、パラメーターが元のままである。サンプルのデータセットであっても、別のデータセットに置き換えてはいけません
   • すべての入力がすでにサーバーレスで読み取り可能である（セクション 4：Unity Catalog テーブル、既存の /Volumes/... パス、外部ロケーション経由のクラウドパス、または dbfs:/databricks-datasets/）。新たな設定は不要である

   元のファイルを隣に <name>.classic.py として保存し、ジョブが変換後のファイルを参照するようにします。変換はまだ実行していないことをユーザーに伝え、クラシック版と出力を比較するテスト実行を 1 回提案してください。

4. それより大きな変更は書き換えません。 そのタスクは今すぐクラシックに移し、ほかのタスクはサーバーレスのままにして、最後に次のように記載します："Kept on classic because . To move it to serverless, use the databricks-serverless-migration skill." より大きな変更とは、ステップ 3 の条件を満たさない RDD コード（たとえば、DBFS マウントを読み取るコード）、同じストレージ上にボリュームがないマウント、Hive Metastore から Unity Catalog への移行、JAR の再コンパイル、ネットワークの変更、ストリームの動作変更（常時稼働する processingTime または continuous ストリーム）、またはステップ 3 の変換以外に約 5 件を超える編集が必要な変更です。

移行するかどうかをユーザーに尋ねて手を止めないでください。デプロイしてから、実施内容を報告してください。

よくある問題

問題	解決方法
Libraries field is not supported for serverless task	ライブラリを environments[].spec.dependencies（JAR の場合は java_dependencies）に移し、タスクに environment_key を設定します
サーバーレスジョブの起動が遅すぎる	起動速度を重視する場合に限り、performance_target: PERFORMANCE_OPTIMIZED を設定します（セクション 3）
Only remote Spark sessions ... are supported またはその他の RDD エラー	RDD／SparkContext のコードについては、セクション 5 の手順 3 または 4 を参照してください
[PATH_NOT_FOUND] または dbfs:/mnt/... にアクセスできない	DBFS マウントはサーバーレスでは機能しません。同じストレージ上のボリュームを使用します（セクション 5、手順 2）。それ以外の場合は手順 4 を参照してください
ワークスペースでサーバーレスが有効になっていない、または利用できない	ジョブをクラシックに設定し、その旨をユーザーに伝えます（セクション 1）
関連スキルの例で、新しいジョブに job_clusters を使用している	クラスターブロックは含めません。このスキルがコンピュートを決定します。既存のジョブでは、現在のコンピュートを維持します

関連スキル

• databricks-core - CLI の基本、認証、プロファイル
• databricks-jobs - ジョブの構造、タスクの種類、トリガー、通知
• databricks-pipelines - Lakeflow Spark Declarative Pipelines
• databricks-serverless-migration - 既存のクラシックワークロードからサーバーレスへの移行

ドキュメント

• ジョブ向けサーバーレスコンピュート
• サーバーレスコンピュートの制限事項
• サーバーレスの依存関係（環境）
• サーバーレスパイプライン