CI/CD (継続的インテグレーションと継続的デリバリー) は、コードの変更が迅速かつ確実に統合、テスト、デプロイされるようにするため、最新のデータ エンジニアリングと分析の基礎となっています。 Databricks は、組織の好み、既存のワークフロー、特定のテクノロジ環境によって形成された多様な CI/CD 要件があることを認識し、さまざまな CI/CD オプションをサポートする柔軟なフレームワークを提供します。
このページでは、独自のニーズと制約に合わせて堅牢でカスタマイズされた CI/CD パイプラインを設計および構築するのに役立つベスト プラクティスについて説明します。 これらの分析情報を活用することで、データ エンジニアリングと分析の取り組みを加速し、コードの品質を向上させ、デプロイエラーのリスクを軽減できます。
CI/CD の基本原則
効果的な CI/CD パイプラインは、実装の詳細に関係なく、基本原則を共有します。 次のユニバーサルベスト プラクティスは、組織の好み、開発者ワークフロー、クラウド環境全体に適用され、チームがノートブックファーストの開発ワークフローとコードとしてのインフラストラクチャワークフローのどちらを優先するかに関係なく、さまざまな実装間で一貫性を確保します。 これらの原則をガードレールとして採用し、組織のテクノロジ スタックとプロセスに合わせて仕様を調整します。
- バージョン管理のすべて
- ノートブック、スクリプト、インフラストラクチャ定義 (IaC)、ジョブ構成を Git に格納します。
- 標準の開発、ステージング、運用環境のデプロイ環境に合わせた Gitflow などのブランチ戦略を使用します。
- テストの自動化
- Python の pytest や ScalaTest for Scala などのライブラリを使用して、ビジネス ロジックの単体テストを実装します。
- Databricks CLI バンドル検証などのツールを使用して、ノートブックとワークフローの機能を 検証します。
- Spark DataFrames の chispa など、ワークフローとデータ パイプラインの統合テストを使用します。
- コードとしてのインフラストラクチャの採用 (IaC)
- Databricks Asset Bundles YAML または Terraform を使用して、クラスター、ジョブ、ワークスペースの構成を定義します。
- クラスターのサイズやシークレットなど、環境固有の設定をハードコーディングする代わりにパラメーター化します。
- 環境を分離する
- 開発、ステージング、運用用に個別のワークスペースを維持します。
- MLflow モデル レジストリを使用して、環境間でモデルのバージョン管理を行います。
- クラウド エコシステムに一致するツールを選択します。
- Azure: Azure DevOps と Databricks アセット バンドルまたは Terraform。
- AWS: GitHub Actions と Databricks のアセットバンドル、または Terraform。
- GCP: クラウド ビルドとデータブリックス アセット バンドルもしくは Terraform。
- ロールバックの監視と自動化
- デプロイの成功率、ジョブパフォーマンス、テストカバレッジを追跡します。
- 失敗したデプロイの自動ロールバック メカニズムを実装します。
- 資産管理を統合する
- Databricks アセット バンドルを使用して、コード、ジョブ、インフラストラクチャを 1 つのユニットとしてデプロイします。 ノートブック、ライブラリ、ワークフローのサイロ化された管理を回避します。
注
Databricks では、CI/CD 認証用のワークロード ID フェデレーションが推奨されます。 ワークロード ID フェデレーションにより、Databricks シークレットが不要になり、Databricks への自動フローを認証するための最も安全な方法になります。 CI/CD でワークロード ID フェデレーションを有効にするを参照してください。
CI/CD 用 Databricks アセット バンドル
Databricks アセット バンドルは、Databricks エコシステム内のコード、ワークフロー、インフラストラクチャを管理するための強力で統一されたアプローチを提供し、CI/CD パイプラインに推奨されます。 これらの要素を 1 つの YAML 定義ユニットにバンドルすることで、バンドルによってデプロイが簡略化され、環境間の一貫性が確保されます。 ただし、従来の CI/CD ワークフローに慣れているユーザーの場合、バンドルを採用するには考え方の変化が必要になる場合があります。
たとえば、Java 開発者は、Maven または Gradle を使用して JAR を構築し、JUnit で単体テストを実行し、これらの手順を CI/CD パイプラインに統合するために使用されます。 同様に、Python 開発者は多くの場合、コードをホイールにパッケージ化し、pytest でテストしますが、SQL 開発者はクエリの検証とノートブックの管理に重点を置いています。 バンドルを使用すると、これらのワークフローはより構造化された規範的な形式に集約され、シームレスなデプロイのためのバンドル コードとインフラストラクチャが強調されます。
次のセクションでは、開発者がバンドルを効果的に活用するためにワークフローを適応させる方法について説明します。
Databricks アセット バンドルの使用をすぐに開始するには、チュートリアル「 Databricks Asset Bundles を使用してジョブを開発 する」または 「Databricks Asset Bundles を使用して Lakeflow 宣言型パイプラインを開発する」を試してください。
CI/CD ソース管理の推奨事項
CI/CD を実装する際に開発者が行う必要がある最初の選択肢は、ソース ファイルの格納方法とバージョン管理方法です。 バンドルを使用すると、ソース コード、ビルド 成果物、構成ファイルなどすべてを簡単に含め、それらを同じソース コード リポジトリに配置できますが、別のオプションとして、バンドル構成ファイルをコード関連のファイルから分離することもできます。 選択は、チームのワークフロー、プロジェクトの複雑さ、CI/CD の要件によって異なりますが、Databricks では次のことをお勧めします。
- 小規模なプロジェクトや、コードと構成の間の緊密な結合の場合は、コードとバンドルの両方の構成に 1 つのリポジトリを使用してワークフローを簡略化します。
- 大規模なチームまたは独立したリリース サイクルの場合は、コードとバンドルの構成に個別のリポジトリを使用しますが、バージョン間の互換性を確保する明確な CI/CD パイプラインを確立します。
コード関連のファイルをバンドル構成ファイルと併置するか分離するかを選択する場合でも、Databricks または外部ストレージにアップロードするときに、追跡可能性とロールバック機能を確保するために、Git コミット ハッシュなどのバージョン管理された成果物を常に使用します。
コードと構成用の単一リポジトリ
この方法では、ソース コードとバンドル構成ファイルの両方が同じリポジトリに格納されます。 これにより、ワークフローが簡略化され、アトミックな変更が保証されます。
| 利点 | 短所 |
|---|---|
|
|
例: バンドル内の Python コード
この例では、1 つのリポジトリに Python ファイルとバンドル ファイルがあります。
databricks-dab-repo/
├── databricks.yml # Bundle definition
├── resources/
│ ├── workflows/
│ │ ├── my_pipeline.yml # YAML pipeline def
│ │ └── my_pipeline_job.yml # YAML job def that runs pipeline
│ ├── clusters/
│ │ ├── dev_cluster.yml # development cluster def
│ │ └── prod_cluster.yml # production def
├── src/
│ ├── dlt_pipeline.ipynb # pipeline notebook
│ └── mypython.py # Additional Python
└── README.md
コードと構成用の個別のリポジトリ
この方法では、ソース コードは 1 つのリポジトリに存在し、バンドル構成ファイルは別のリポジトリに保持されます。 このオプションは、個別のグループがアプリケーション開発と Databricks ワークフロー管理を処理する大規模なチームまたはプロジェクトに最適です。
| 利点 | 短所 |
|---|---|
|
|
例: Java プロジェクトとバンドル
この例では、Java プロジェクトとそのファイルは 1 つのリポジトリにあり、バンドル ファイルは別のリポジトリにあります。
リポジトリ 1: Java ファイル
最初のリポジトリには、Java 関連のすべてのファイルが含まれています。
java-app-repo/
├── pom.xml # Maven build configuration
├── src/
│ ├── main/
│ │ ├── java/ # Java source code
│ │ │ └── com/
│ │ │ └── mycompany/
│ │ │ └── app/
│ │ │ └── App.java
│ │ └── resources/ # Application resources
│ └── test/
│ ├── java/ # Unit tests for Java code
│ │ └── com/
│ │ └── mycompany/
│ │ └── app/
│ │ └── AppTest.java
│ └── resources/ # Test-specific resources
├── target/ # Compiled JARs and classes
└── README.md
- 開発者は、
src/main/javaまたはsrc/main/scalaでアプリケーション コードを記述します。 - 単体テストは、
src/test/javaまたはsrc/test/scalaに格納されます。 - pull request またはコミットにおける CI/CD パイプライン:
- コードを JAR (たとえば、
target/my-app-1.0.jar) にコンパイルします。 - JAR を Databricks Unity カタログ ボリュームにアップロードします。 JAR のアップロードを参照してください。
- コードを JAR (たとえば、
リポジトリ 2: バンドル ファイル
2 つ目のリポジトリには、バンドル構成ファイルのみが含まれています。
databricks-dab-repo/
├── databricks.yml # Bundle definition
├── resources/
│ ├── jobs/
│ │ ├── my_java_job.yml # YAML job dev
│ │ └── my_other_job.yml # Additional job definitions
│ ├── clusters/
│ │ ├── dev_cluster.yml # development cluster def
│ │ └── prod_cluster.yml # production def
└── README.md
バンドル構成databricks.ymlとジョブ定義は個別に管理されます。
databricks.ymlは、アップロードされた JAR 成果物を参照します。次に例を示します。
- jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
推奨される CI/CD ワークフロー
コード ファイルをバンドル構成ファイルと併置するか分離するかに関係なく、推奨されるワークフローは次のようになります。
コードをコンパイルしてテストする
- プル要求またはメイン ブランチへのコミットでトリガーされます。
- コードをコンパイルし、単体テストを実行します。
- バージョン管理されたファイル (たとえば、
my-app-1.0.jar) を出力します。
コンパイル済みファイル (JAR など) を Databricks Unity カタログ ボリュームにアップロードして格納します。
- コンパイルされたファイルを Databricks Unity カタログ ボリュームまたは AWS S3 や Azure Blob Storage などのアーティファクトリポジトリに格納します。
- Git コミット ハッシュまたはセマンティック バージョン管理に関連付けられたバージョン管理スキーム (
dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jarなど) を使用します。
バンドルを検証する
databricks bundle validateを実行して、databricks.yml構成が正しいことを確認します。- この手順により、不足しているライブラリなどの構成ミスが早期にキャッチされます。
バンドルをデプロイする
databricks bundle deployを使用して、バンドルをステージング環境または運用環境にデプロイします。databricks.ymlでアップロードされたコンパイル済みライブラリを参照します。 ライブラリの参照については、「 Databricks Asset Bundles ライブラリの依存関係」を参照してください。
機械学習用の CI/CD
機械学習プロジェクトでは、従来のソフトウェア開発と比較して、固有の CI/CD の課題が発生します。 ML プロジェクトに CI/CD を実装する場合は、次の点を考慮する必要があります。
- 複数チームの調整: データ サイエンティスト、エンジニア、MLOps チームは、多くの場合、さまざまなツールとワークフローを使用します。 Databricks は、これらのプロセスを実験追跡用の MLflow、データ ガバナンス用の差分共有、コードとしてのインフラストラクチャ用の Databricks アセット バンドルと統合します。
- データとモデルのバージョン管理: ML パイプラインでは、コードだけでなく、トレーニング データ スキーマ、機能の分布、モデル成果物も追跡する必要があります。 Databricks Delta Lake では、データのバージョン管理に ACID トランザクションと時間移動が提供されますが、MLflow モデル レジストリはモデル系列を処理します。
- 環境間の再現性: ML モデルは、特定のデータ、コード、インフラストラクチャの組み合わせによって異なります。 Databricks アセット バンドルを使用すると、YAML 定義を使用して、開発、ステージング、および運用環境全体でこれらのコンポーネントをアトミックにデプロイできます。
- 継続的な再トレーニングと監視: モデルはデータの誤差によって低下します。 Lakeflow は自動再トレーニングパイプラインを有効にし、MLflow はパフォーマンス追跡のために Prometheus と Lakehouse Monitoring に統合されます。
ML CI/CD 用 MLOps スタック
Databricks は、 MLOps Stacks を通じて ML CI/CD の複雑さに対処します。これは、Databricks アセット バンドル、事前構成済みの CI/CD ワークフロー、およびモジュール型 ML プロジェクト テンプレートを組み合わせた運用グレードのフレームワークです。 これらのスタックはベスト プラクティスを適用すると同時に、データ エンジニアリング、データ サイエンス、MLOps の各ロールにわたるマルチチーム コラボレーションの柔軟性を実現します。
| チーム | 役割 | バンドル コンポーネントの例 | アーティファクトの例 |
|---|---|---|---|
| データ エンジニア | ETL パイプラインを構築し、データ品質を適用する | Lakeflow 宣言型パイプライン YAML、クラスター ポリシー | etl_pipeline.yml、feature_store_job.yml |
| データ サイエンティスト | モデル トレーニング ロジックを開発し、メトリックを検証する | MLflow プロジェクト、ノートブックベースのワークフロー | train_model.yml、batch_inference_job.yml |
| MLOps エンジニア | デプロイの調整、パイプラインの監視 | 環境変数、ダッシュボードの監視 | databricks.yml、lakehouse_monitoring.yml |
ML CI/CD コラボレーションは次のようになります。
- データ エンジニアは、ETL パイプラインの変更をバンドルにコミットし、自動スキーマ検証とステージング デプロイをトリガーします。
- データ サイエンティストは ML コードを送信します。ML コードは単体テストを実行し、統合テスト用のステージング ワークスペースにデプロイします。
- MLOps エンジニアは、検証メトリックを確認し、MLflow レジストリを使用して検証済みモデルを運用環境に昇格させます。
実装の詳細については、次を参照してください。
- MLOps Stacks バンドル: バンドルの初期化とデプロイの詳細なガイダンス。
- MLOps Stacks GitHub リポジトリ: トレーニング、推論、CI/CD 用の事前構成済みテンプレート。
標準化されたバンドルと MLOps スタックを使用してチームを調整することで、組織は ML ライフサイクル全体で監査可能性を維持しながらコラボレーションを効率化できます。
SQL 開発者向けの CI/CD
Databricks SQL を使用してストリーミング テーブルと具体化されたビューを管理する SQL 開発者は、Git 統合と CI/CD パイプラインを利用してワークフローを合理化し、高品質のパイプラインを維持できます。 クエリに対する Git サポートの導入により、SQL 開発者は Git を利用して .sql ファイルのバージョン管理を行いながらクエリの記述に集中できます。これにより、高度なインフラストラクチャの専門知識を必要とせずにコラボレーションと自動化が可能になります。 さらに、SQL エディターを使用すると、リアルタイムのコラボレーションが可能になり、Git ワークフローとシームレスに統合されます。
SQL 中心のワークフローの場合:
バージョン管理 SQL ファイル
- Databricks Git フォルダーまたは外部 Git プロバイダー (GitHub、Azure DevOps など) を使用して、.sql ファイルを Git リポジトリに格納します。
- ブランチ (開発、ステージング、運用など) を使用して、環境固有の変更を管理します。
.sqlファイルを CI/CD パイプラインに統合してデプロイを自動化します。- プル要求中に構文とスキーマの変更を検証します。
.sqlファイルを Databricks SQL ワークフローまたはジョブにデプロイします。
環境の分離のためのパラメーター化
.sqlファイル内の変数を使用して、データ パスやテーブル名などの環境固有のリソースを動的に参照します。CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
更新のスケジュール設定と監視
- Databricks ジョブの SQL タスクを使用して、テーブルと具体化されたビュー (
REFRESH MATERIALIZED VIEW view_name) の更新をスケジュールします。 - システム テーブルを使用して更新履歴を監視します。
- Databricks ジョブの SQL タスクを使用して、テーブルと具体化されたビュー (
ワークフローは次のようになります。
- 開発: ローカルまたは Databricks SQL エディターで
.sqlスクリプトを記述してテストし、Git ブランチにコミットします。 - 検証: プル要求中に、自動化された CI チェックを使用して構文とスキーマの互換性を検証します。
- デプロイ: マージ時に、CI/CD パイプライン (GitHub Actions や Azure Pipelines など) を使用して、.sql スクリプトをターゲット環境にデプロイします。
- 監視: Databricks ダッシュボードとアラートを使用して、クエリのパフォーマンスとデータの鮮度を追跡します。
ダッシュボード開発者向けの CI/CD
Databricks では、 Databricks アセット バンドルを使用した CI/CD ワークフローへのダッシュボードの統合がサポートされています。 この機能により、ダッシュボード開発者は次のことが可能になります。
- バージョン管理ダッシュボード。監査性を確保し、チーム間のコラボレーションを簡素化します。
- エンドツーエンドでの整合を目的として、環境全体でジョブとパイプラインに加えダッシュボードのデプロイを自動化します。
- 手動エラーを減らし、環境間で更新プログラムが一貫して適用されるようにします。
- CI/CD のベスト プラクティスに従いながら、高品質の分析ワークフローを維持します。
CI/CD のダッシュボードの場合:
databricks bundle generateコマンドを使用して、既存のダッシュボードを JSON ファイルとしてエクスポートし、それをバンドルに含む YAML 構成を生成します。resources: dashboards: sales_dashboard: display_name: 'Sales Dashboard' file_path: ./dashboards/sales_dashboard.lvdash.json warehouse_id: ${var.warehouse_id}これらの
.lvdash.jsonファイルを Git リポジトリに格納して、変更を追跡し、効果的に共同作業を行います。databricks bundle deployを使用して CI/CD パイプラインにダッシュボードを認証的にデプロイします。 たとえば、デプロイの GitHub Actions ステップは次のようになります。name: Deploy Dashboard run: databricks bundle deploy --target=prod env: DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}変数 (たとえば、
${var.warehouse_id}) を使用して、SQL ウェアハウスやデータ ソースなどの構成をパラメーター化し、開発、ステージング、運用環境間でのシームレスなデプロイを保証します。bundle generate --watchオプションを使用して、ローカル ダッシュボードの JSON ファイルと Databricks UI で行われた変更を継続的に同期します。 不一致が発生した場合は、デプロイ時に--forceフラグを使用して、リモート ダッシュボードをローカル バージョンで上書きします。
バンドル内のダッシュボードの詳細については、 ダッシュボード リソースを参照してください。 バンドル コマンドの詳細については、コマンド グループbundle参照してください。