継続的インテグレーションと継続的デリバリー (CI/CD) とは、自動化パイプラインの使用を通じて、短時間で頻繁にソフトウェアを開発および提供するプロセスを指します。 CI/CD はソフトウェア開発で一般的であり、データ エンジニアリングやデータ サイエンスにますます必要になってきています。 開発チームは、コードのビルド、テスト、デプロイを自動化することで、手動プロセスよりも確実にリリースを提供できます。
Databricks には、各組織のソフトウェア開発ライフサイクル固有の側面により、組織によって若干異なる可能性があるアプローチに対応する CI/CD パイプラインを開発するためのツールが用意されています。 このページでは、Databricks の CI/CD パイプラインで使用できるツールに関する情報を提供します。 CI/CD の推奨事項とベスト プラクティスの詳細については、 Databricks のベスト プラクティスと推奨される CI/CD ワークフローを参照してください。
Azure Databricks 上の機械学習プロジェクトの CI/CD の概要については、「 Databricks で機械学習用の CI/CD をサポートする方法」を参照してください。
上位レベルのフロー
Azure Databricks CI/CD パイプラインの一般的なフローは次のとおりです。
-
バージョン: Azure Databricks コードとノートブックを Git などのバージョン 管理システムに格納します。 これにより、時間の経過と共に変更を追跡し、他のチーム メンバーと共同作業を行うことができます。
- 個々のユーザーは、Git リポジトリにコミットする前に、Git フォルダーを使用して変更を作成し、テストします。 Databricks Git フォルダー (Repos) を使用した CI/CD を参照してください。
- 必要に応じて 、バンドル Git 設定を構成します。
-
コード: ワークスペース内の Azure Databricks ノートブックで、または IDE を使用してローカルでコードと単体テストを開発します。
- Lakeflow Pipelines エディターを使用して、ワークスペースでパイプラインを開発します。
- Databricks Visual Studio Code 拡張機能を使用して、ローカルの変更を開発し、Azure Databricks ワークスペースにデプロイします。
-
ビルド: Databricks アセット バンドルの設定を使用して、デプロイ中に特定の成果物を自動的にビルドします。
- バンドル構成の成果物マッピングを設定します。
- Databricks Labs pylint プラグインで拡張された Pylint は、コーディング標準を適用し、Databricks ノートブックとアプリケーション コードのバグを検出するのに役立ちます。
-
デプロイ: Azure DevOps、GitHub Actions、Jenkins などのツールを使用して、Databricks アセット バンドルを使用して Azure Databricks ワークスペースに変更をデプロイします。
- バンドルデプロイモードを使用して デプロイを構成します。
- Azure DevOps と Databricks の使用の詳細については、Azure DevOps を使用した Azure Databricks での継続的インテグレーションと配信に関するページを参照してください。
- Databricks GitHub Actions の例については、 GitHub Actions を参照してください。
-
テスト: コードの変更を検証する自動テストを開発して実行します。
- pytest などのツールを使用して、統合をテストします。
-
実行: Databricks CLI と Databricks アセット バンドルを使用して、Azure Databricks ワークスペースでの実行を自動化します。
- databricks バンドル実行を使用してバンドル リソースを実行します。
- 監視: ジョブの監視などのツールを使用して、Azure Databricks のコードと運用ワークロードのパフォーマンスを 監視します。 これは、運用環境で発生した問題を特定して解決するのに役立ちます。
使用可能なツール
次のツールは CI/CD の基本原則をサポートしています。すべてのファイルのバージョン管理と資産管理の統合、コードとしてのインフラストラクチャの定義、環境の分離、テストの自動化、ロールバックの監視と自動化を行います。
| 面積 | 必要な場合は、これらのツールを使用します。... |
|---|---|
| Databricks アセット バンドル | CI/CD のベスト プラクティスとフローを使用して、Lakeflow ジョブ、Lakeflow 宣言パイプライン、MLOps スタックなどのリソースをプログラムで定義、デプロイ、実行します。 |
| Databricks Terraform プロバイダー | Terraform を使用して Databricks ワークスペースとインフラストラクチャをプロビジョニングおよび管理します。 |
| Azure DevOps を使用した Azure Databricks での継続的インテグレーションとデリバリー | Azure DevOps を使用する Azure Databricks 用の CI/CD パイプラインを開発します。 |
| Azure Databricks で Azure DevOps を使用して認証する | Azure DevOps で認証します。 |
| GitHub のアクション | AZURE Databricks 用に開発された GitHub アクションを CI/CD フローに含めます。 |
| Azure Databricks 上の Jenkins を使用した CI/CD | Jenkins を使用する Azure Databricks 用の CI/CD パイプラインを開発します。 |
| Apache エアフローを使用して Lakeflow ジョブを調整する | Apache エアフローを使用するデータ パイプラインを管理およびスケジュールします。 |
| CI/CD のサービス プリンシパル | CI/CD ではユーザーの代わりにサービス プリンシパルを使用してください。 |
| OAuth トークン フェデレーションを使用して Azure Databricks へのアクセスを認証する | CI/CD 認証にはワークロード ID フェデレーションを使用します。これにより、Databricks シークレットが不要になり、Databricks に対する最も安全な認証方法になります。 |
Databricks アセット バンドル
Databricks アセット バンドル は、Databricks の CI/CD に推奨されるアプローチです。 Databricks アセット バンドルを使用して、ジョブやパイプラインなどの Databricks リソースをソース ファイルとして記述し、それらを他の資産とバンドルして、配置可能なプロジェクトのエンドツーエンドの定義を提供します。 これらのファイルのバンドルはソース管理でき、Github Actions などの外部 CI/CD オートメーションを使用してデプロイをトリガーできます。
バンドルには、組織全体で一貫性とベスト プラクティスを適用するためのカスタム テンプレートや、多くの Databricks リソースのコード ファイルと構成をデプロイするための包括的なサポートなど、多くの機能が含まれています。 バンドルを作成するには、 バンドル構成構文 に関する知識が必要です。
CI/CD でバンドルを使用する方法に関する推奨事項については、 Databricks のベスト プラクティスと推奨される CI/CD ワークフローを参照してください。
ソース管理用のその他のツール
Databricks アセット バンドルを使用して完全な CI/CD を適用する代わりに、Databricks には、ソース管理とコード ファイルとノートブックのデプロイのみを行うオプションが用意されています。
Git フォルダー: Git フォルダーを使用して、リモート Git リポジトリの状態を反映できます。 運用用の Git フォルダーを作成して、ソース管理されたソース ファイルとノートブックを管理できます。 次に、Git フォルダーを手動で最新の状態にプルするか、GitHub Actions などの外部 CI/CD ツールを使用してマージ時に Git フォルダーをプルするか、外部 CI/CD パイプラインにアクセスできない場合にプルします。 この方法は、エアフローなどの外部オーケストレーターに対して機能しますが、ソース管理にはノートブックやダッシュボードの下書きなどのコード ファイルのみがあることに注意してください。 Git フォルダー内の資産を実行するジョブまたはパイプラインの構成と、ダッシュボードを発行するための構成はソース管理に含まれていません。
ジョブを含む Git: ジョブのコード ファイルのソース管理のみが必要な場合は、リモート Git リポジトリをソースとして使用するようにいくつかのジョブの種類を構成できます。 ジョブの実行が開始されると、Databricks はリモート リポジトリのスナップショット コミットを取得し、ジョブ全体が同じバージョンのコードに対して実行されるようにします。 この方法では、限られたジョブ タスクのみがサポートされます。 さらに、ノートブックやその他のファイルなどのコード ファイルのみがソース管理に含まれています。 タスク シーケンス、コンピューティング、スケジュールなどのジョブ構成はソース管理されないため、このアプローチはマルチ環境のクロスワークスペースデプロイには適していません。