Databricks における CI/CD ワークフロー

CI/CD（継続的インテグレーションと継続的デリバリー）は、コード変更が迅速かつ確実に統合、テスト、デプロイされることを保証するため、現代のデータエンジニアリングとアナリティクスの要となっています。Databricks は、組織の好み、既存のワークフロー、および特定のテクノロジー環境によって形成される多様な CI/CD 要件をお持ちであることを認識しており、さまざまな CI/CD オプションをサポートする柔軟なフレームワークを提供します。

このページでは、お客様固有のニーズと制約に合わせた、堅牢でカスタマイズされた CI/CD パイプラインを設計および構築するのに役立つ、推奨される CI/CD ワークフローについて説明します。これらの知見を活用することで、データエンジニアリングとアナリティクスの取り組みを加速し、コードの品質を向上させ、デプロイメントの失敗のリスクを軽減します。

CI/CDの主要原則

効果的な CI/CD パイプラインは、実装の詳細にかかわらず、基礎となる原則を共有しています。以下の普遍的なベストプラクティスは、組織の好み、開発者ワークフロー、クラウド環境全体に適用され、チームがノートブックファースト開発を優先する場合でも、Infrastructure-as-Code ワークフローを優先する場合でも、多様な実装全体で一貫性を確保します。これらの原則をガードレールとして取り入れ、具体的な点は組織の技術スタックとプロセスに合わせて調整してください。

すべてバージョン管理してください
- ノートブック、スクリプト、インフラストラクチャ定義（IaC）、およびジョブ設定をGitに保存します。
- 標準の開発、ステージング、および本番運用のデプロイメント環境に合わせた、Gitflow などのブランチ戦略を使用します。
テストの自動化
- ビジネスロジックの単体テストを、Python 用の pytest や Scala 用の ScalaTest といったライブラリを使用して実装します。
- Databricks CLIのbundle validateなどのツールを使用して、ノートブックとワークフローの機能を検証します。
- ワークフローやデータパイプラインには、Spark DataFrames 用の chispa などの統合テストを使用します。
Infrastructure-as-Code (IaC) を活用する
- クラスター、ジョブ、ワークスペースの設定は、Declarative Automation Bundles YAML または Terraformで定義します。
- クラスターサイズやシークレットなどの環境固有の設定をハードコーディングする代わりに、パラメーター化します。
環境を隔離する
- 開発、ステージング、本番運用用に個別のワークスペースを維持してください。
- 環境全体でのモデルのバージョン管理には、MLflow Model Registry をご利用ください。
お使いのクラウドエコシステムに一致するツールの選択：
- Azure：Azure DevOps と宣言型自動化バンドルまたは Terraform。
- AWS：GitHub Actionsと宣言型オートメーションバンドル、またはTerraform。
- GCP：Cloud Build および宣言型オートメーションバンドルまたは Terraform。
ロールバックを監視し、自動化します。
- デプロイの成功率、ジョブのパフォーマンス、およびテストカバレッジを追跡します。
- デプロイ失敗時の自動ロールバック機構を実装します。
統合アセットマネジメント
- コード、ジョブ、およびインフラストラクチャを単一ユニットとしてデプロイするには、宣言型オートメーションバンドルを使用します。ノートブック、ライブラリ、ワークフローのサイロ化された管理を回避します。

注記

Databricks は CI/CD 認証にワークロード ID フェデレーションを推奨します。ワークロード ID フェデレーションは Databricks シークレットを不要にするため、自動化されたフローを Databricks に認証するための最も安全な方法です。CI/CD でのワークロード ID フェデレーションの有効化を参照してください。

宣言型オートメーションバンドル（CI/CD向け）

Declarative Automation Bundles（旧称 Databricks Asset Bundles）は、Databricksエコシステム内でコード、ワークフロー、およびインフラストラクチャを管理するための強力かつ統一されたアプローチを提供し、CI/CDパイプラインに推奨されます。これらの要素をYAMLで定義された単一のユニットにバンドルすることで、バンドルはデプロイを簡素化し、環境全体で一貫性を確保します。しかし、従来のCI/CDワークフローに慣れているユーザーにとって、バンドルを採用することは、考え方の転換が必要となる可能性があります。

例えば、Java 開発者は、Maven や Gradle を使用して JAR をビルドし、JUnit を使用して単体テストを実行し、これらのステップを CI/CD パイプラインに統合することに慣れています。同様に、Python 開発者は多くの場合、コードを wheels にパッケージ化して pytest でテストしますが、SQL 開発者はクエリの検証とノートブック管理に重点を置いています。バンドルを使用することで、これらのワークフローはより構造化され、規範的な形式に統合され、シームレスなデプロイメントのためにコードとインフラストラクチャのバンドルに重点を置いています。

以下のセクションでは、開発者がバンドルを効果的に活用するためにワークフローをどのように適応できるかについて説明します。

宣言型オートメーションバンドルを今すぐ開始するには、チュートリアルをお試しください。「宣言型オートメーションバンドルでジョブを開発する」または「宣言型オートメーションバンドルでパイプラインを開発する」

ソース管理

バンドルを使用すると、ソースコード、ビルドアーティファクト、構成ファイルなど、すべてのものを簡単に含め、同じソースコードリポジトリに配置できます。ただし、バンドルの構成ファイルをコード関連のファイルから分離することも可能です。選択はチームのワークフロー、プロジェクトの複雑さ、および CI/CD 要件によって異なりますが、ワークフローとベストプラクティスの共有を簡素化するために、Databricks では、コードとバンドル構成の両方に単一のリポジトリを使用することをお勧めします。

加えて、Databricks は、マージ競合を最小限に抑え、メインブランチが常にデプロイ可能な状態であることを保証するためにトランクベースのブランチ戦略を推奨しています。また、追跡可能性とロールバック機能を確保するため、Databricks または外部ストレージにアップロードする際は、Gitコミットハッシュなどのバージョン管理されたアーティファクトを常に使用することをお勧めします。

これらのベストプラクティスの詳細については、ソース管理を参照してください。

バンドルによるCI/CDワークフロー

宣言型オートメーションバンドルを使用した推奨されるシンプルなワークフローは次のとおりです：

コードをコンパイルしてテストします
- プルリクエストまたはメインブランチへのコミット時にトリガーされます。
- コードをコンパイルし、ユニットテストを実行します。
- バージョン管理されたファイル（my-app-1.0.jarなど）を出力します。
コンパイル済みのファイル（例: JAR）を、Databricks Unity Catalog ボリュームにアップロードおよび保存します。
- コンパイルされたファイルは、Databricks Unity Catalog ボリュームまたは AWS S3 や Azure Blob Storage のようなアーティファクトリポジトリに保管してください。
- Git コミットハッシュまたはセマンティックバージョニングに結び付いたバージョニングスキームを利用してください。例: dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar。
バンドルの検証
- databricks bundle validate を実行して、databricks.yml の構成が正しいことを確認します。
- このステップによって、例えばライブラリの欠落といった設定ミスを、早期に検出できるようになります。
バンドルをデプロイしてください
- databricks bundle deployを使用して、バンドルをステージングまたは本番運用環境にデプロイします。
- アップロードされたコンパイル済みライブラリをdatabricks.ymlで参照してください。ライブラリの参照に関する情報については、宣言型自動化バンドルのライブラリ依存関係を参照してください。

機械学習のための CI/CD

機械学習プロジェクトは、従来のソフトウェア開発と比較して、CI/CDに特有の課題をもたらします。機械学習プロジェクトにCI/CDを実装する際は、以下の点を考慮する必要があるでしょう。

複数チームの連携：データサイエンティスト、エンジニア、MLOpsチームは、異なるツールやワークフローを使用することがよくあります。Databricksは、エクスペリメント追跡のためのMLflow、データガバナンスのためのOpenSharing、Infrastructure-as-CodeのためのDeclarative Automation Bundlesによって、これらのプロセスを統合します。
データとモデルのバージョン管理：機械学習パイプラインでは、コードだけでなく、トレーニングデータスキーマ、特徴量ディストリビューション、モデルアーティファクトも追跡が求められます。Delta Lakeは、データバージョン管理のためにACIDトランザクションとタイムトラベルを提供します。一方、MLflow Model Registryはモデルリネージを扱います。
環境間での再現性：機械学習モデルは、特定のデータ、コード、インフラストラクチャの組み合わせに依存しています。宣言型オートメーションバンドルは、YAML定義を使用して、開発、ステージング、および本番運用環境全体で、これらのコンポーネントのアトミックなデプロイを確実にします。
継続的な再トレーニングとモニタリング: データドリフトによりモデルが劣化します。 Lakeflowジョブによりパイプラインの自動再トレーニングが可能になり、 MLflowパフォーマンス追跡のために Prometheus およびDatabricksデータ品質モニタリングと統合されます。

機械学習 CI/CD 向けの MLOps スタック

Databricks は、宣言型オートメーションバンドル、事前設定されたCI/CDワークフロー、モジュール式の機械学習プロジェクトテンプレートを組み合わせた本番運用レベルのフレームワークであるMLOpsスタックを通じて、機械学習におけるCI/CDの複雑さに対処します。これらのスタックは、データエンジニアリング、データサイエンス、MLOps の各ロール間における複数チームのコラボレーションに柔軟性をもたらしながら、ベストプラクティスを適用します。

チーム	責任	バンドルコンポーネントの例	アーティファクトの例
データエンジニア	ETLパイプラインを構築し、データ品質を確保します。	Lakeflow Spark宣言型パイプライン YAML、クラスターポリシー	`etl_pipeline.yml`, `feature_store_job.yml`
データサイエンティスト	モデルのトレーニングロジックを開発し、メトリクスを検証します。	MLflow プロジェクト、ノートブックベースのワークフロー	`train_model.yml`, `batch_inference_job.yml`
MLOpsエンジニア	デプロイメントをオーケストレーションし、パイプラインを監視します。	環境変数、モニタリングダッシュボード	`databricks.yml`, `lakehouse_monitoring.yml`

機械学習 CI/CD コラボレーションのイメージ：

データエンジニアはETLパイプラインの変更をバンドルにコミットし、自動スキーマ検証とステージングデプロイをトリガーします。
データサイエンティストは、ユニットテストを実行し、統合テストのためにステージングワークスペースにデプロイされる機械学習コードを提出します。
MLOps エンジニアは、検証メトリクスを確認し、厳選されたモデルを MLflow Registry を使用して本番運用に昇格させます。

実装の詳細については、以下を参照してください。

MLOpsスタックバンドル: バンドル初期化とデプロイのステップバイステップガイド。
MLOps Stacks GitHub リポジトリ: トレーニング、推論、CI/CD のための事前構成済みテンプレートです。

標準化されたバンドルとMLOps Stackにチームを連携させることで、組織は機械学習ライフサイクル全体で監査可能性を維持しながら、コラボレーションを効率化できます。

SQL 開発者向けの CI/CD

Databricks SQL を使用してストリーミングテーブルとマテリアライズドビューを管理する SQL 開発者は、Git 統合と CI/CD パイプラインを活用してワークフローを合理化し、高品質なパイプラインを維持できます。クエリに対するGitサポートが導入されたことで、SQL開発者は、Gitを活用して.sqlファイルのバージョン管理を行いながらクエリの作成に集中できます。これにより、深いインフラストラクチャの専門知識を必要とせずに、コラボレーションと自動化が可能になります。さらに、SQLエディタではリアルタイムコラボレーションが可能になり、Gitワークフローとシームレスに統合できます。

SQL中心のワークフロー向け：

SQLファイルのバージョン管理
- 保存 .sqlDatabricks Gitフォルダー、あるいはGitHub、Azure DevOpsなどの外部Gitプロバイダーを使用するGitリポジトリ内のファイル
- 環境固有の変更を管理するには、ブランチ（たとえば、開発、ステージング、および本番運用）を使用します。
.sqlファイルをCI/CDパイプラインに統合し、デプロイを自動化します：
- プルリクエスト中に構文とスキーマの変更を検証します。
- .sqlファイルをDatabricks SQLワークフローまたはジョブにデプロイします。
環境分離のためのパラメーター化
- .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)。
- システムテーブルによる更新履歴の監視

ワークフローは、次のようになる場合があります。

開発: .sqlスクリプトをローカルまたはDatabricks SQLエディターで作成およびテストし、その後、Gitブランチにコミットします。
検証：プルリクエスト中に、自動化されたCIチェックを使用して構文とスキーマの互換性を検証します。
デプロイ：マージ時、.sql をデプロイします。GitHub ActionsやAzure PipelinesなどのCI/CDパイプラインを使用して、スクリプトをターゲット環境に配信します。
監視：Databricks ダッシュボードおよびアラートを使用して、クエリのパフォーマンスとデータの鮮度を追跡します。

ダッシュボード開発者向けのCI/CD

Databricks は「宣言型オートメーションバンドル」を使用して、ダッシュボードを CI/CD ワークフローに統合することをサポートしています。この機能により、ダッシュボード開発者は次のことが可能になります：

ダッシュボードのバージョン管理によって、監査性が確保され、チーム間の共同作業が簡素化されます。
ジョブやパイプラインとともにダッシュボードのデプロイを環境全体で自動化し、エンドツーエンドのアラインメントを実現します。
手動によるエラーを削減し、複数の環境で更新が一貫して適用されるようにします。
CI/CDのベストプラクティスに従いながら、高品質のアナリティクスワークフローを維持します。

CI/CDでのダッシュボードについて：

databricks bundle generate コマンドを使用して、既存のダッシュボードを JSON ファイルとしてエクスポートし、バンドルに含める YAML 設定を生成します。

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ステップ：
YAML
```
name: Deploy Dashboard
  run: databricks bundle deploy --target=prod
env:
  DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
```
例えば${var.warehouse_id}のような変数を使用し、SQLウェアハウスやデータソースなどの構成をパラメータ化することで、開発、ステージング、本番運用環境全体にわたってシームレスなデプロイメントを確保できます。
Databricks UI で行われた変更とローカルダッシュボード JSON ファイルを継続的に同期するには、bundle generate --watch オプションを使用します。不一致が発生した場合は、デプロイ時に--forceフラグを使用して、リモートダッシュボードをローカルバージョンで上書きします。

バンドル内のダッシュボードに関する情報については、「ダッシュボードリソース」を参照してください。バンドルコマンドの詳細については、bundleコマンド・グループを参照してください。

CI/CDの主要原則​

宣言型オートメーションバンドル（CI/CD向け）​

ソース管理​

バンドルによるCI/CDワークフロー​

機械学習のための CI/CD​

機械学習 CI/CD 向けの MLOps スタック​

SQL 開発者向けの CI/CD​

ダッシュボード開発者向けのCI/CD​