この記事では、宣言型オートメーション バンドル (旧称 Databricks アセット バンドル) についてよく寄せられる質問を示します。
Databricks アセット バンドルの名前が宣言型オートメーション バンドルに変更された理由
新しい名前の宣言型オートメーション バンドルは、バンドルの使用方法と機能をより正確に反映します。 さらに、 資産 という用語は、Databricks で複数の意味を持つため、混乱を引き起こしました。 この名前の変更は互換性を損なわないものです。
bundle CLI コマンドと既存のすべての構成を変更する必要はありません。
Azure Databricks の CI/CD パイプラインの一部として宣言型オートメーション バンドルを使用するにはどうすればよいですか?
宣言型オートメーション バンドルを使用すると、Azure Databricks CI/CD 実装で資産を定義およびプログラムで管理できます。通常、次のものが含まれます。
- ノートブック: Azure Databricks ノートブックは、多くの場合、データ エンジニアリングとデータ サイエンスのワークフローの重要な部分です。 ノートブックのバージョン 管理を使用し、CI/CD パイプラインの一部として検証およびテストすることもできます。 ノートブックに対して自動テストを実行して、それらが期待どおりに機能しているかどうかを確認できます。
- ライブラリ: デプロイされたコードを実行するために必要な ライブラリの依存関係 を管理します。 ライブラリでバージョン管理を使用し、自動テストと検証に含めます。
- ワークフロー: Lakeflow ジョブ は、ノートブックまたは Spark ジョブを使用して自動化されたタスクをスケジュールして実行できるジョブで構成されます。
- データ パイプライン: データ パイプラインを宣言するための Databricks のフレームワークである Lakeflow Spark 宣言パイプラインを使用して、CI/CD オートメーションにデータ パイプラインを含めることもできます。
- インフラストラクチャ: インフラストラクチャの構成には、ターゲット環境のクラスター、ワークスペース、ストレージの定義とプロビジョニング情報が含まれます。 インフラストラクチャの変更は、CI/CD パイプラインの一部として検証およびテストできるため、一貫性があり、エラーが発生しなくなっていることを確認できます。
開発と運用のターゲット環境を分離する必要がある理由
開発環境と製品環境を分離することで、次の作業を行うことができます。
- 開発の変更を安全に分離して、運用環境に誤って影響を与えないようにします。
- 特定のターゲット環境に適用するリソースをカスタマイズして、コードの重複を防ぎます。
- データベース パス、アラート、アクセス制御など、環境固有の構成で CI/CD を合理化し、簡素化します。
- チームと環境間でワークフローを再利用する。
ターゲットを使用して、バンドルデプロイ環境を定義します。 「targets」を参照してください。
組織全体でバンドルの整合性を確保するにはどうすればよいですか?
一貫性のある構造にバンドル テンプレートを使用し、セットアップ エラーを減らし、ベスト プラクティスを促進します。 既定のバンドル テンプレートを使用することも、独自のカスタム バンドル テンプレートを作成することもできます。 宣言型オートメーション バンドル プロジェクト テンプレートを参照してください。
同じクラスター定義など、バンドル間で多くの繰り返しがあります。 これを処理する最善の方法は何ですか?
カスタム変数は、コンテキスト固有の設定だけでなく、繰り返しを処理する最適な方法です。 「カスタム変数」を参照してください。
デプロイ フローでバンドルを使用する場合のベスト プラクティスは何ですか?
Databricks では、次のことが推奨されています。
- Git 統合ワークフローを使用して、手動デプロイから信頼性の高い自動化に移行します。
- CI/CD パイプラインで
databricks bundle validateを使用してバンドルをデプロイする前に検証します。 - デプロイ手順を分離して、変更が確認され、意図的であることを確認します。
- 変更を分離するために、オーバーライドを使用して環境 (開発、ステージング、prod) をパラメーター化します。
- デプロイ後に統合テストを実行して、問題を早期にキャッチします。
- GitHub Actions、Azure DevOps、または GitLab CI を使用して、コミットまたは PR マージ時にデプロイをトリガーします。
- すべてのデプロイがコミットとバンドルのバージョンにマップされるように、デプロイされた内容、場所、およびタイミングを追跡します。
既存のジョブ、パイプライン、ダッシュボード、その他の Databricks オブジェクトをバンドルに移植できますか?
はい。
databricks bundle generate コマンドを使用して、ローカル バンドル内の既存のジョブ、パイプライン、またはダッシュボードの構成ファイルを生成し、databricks bundle deployment bindを使用して、バンドル リソースをワークスペース内の対応するリソースにバインドします。 これは、既存のワークフローを構造化されたバージョン管理された開発にオンボードするのに最適です。 バインドでは、絶対ワークスペース参照への相対パスも解決されるため、パス エラーが回避されます。
「既存のリソースをバンドルに移行する」を参照してください。
バンドルを繰り返しテストする方法
反復的なデプロイと実行により、より迅速に開発できます。
- デプロイする前に検証する
- 段階的にデプロイ
- 必要なものだけを実行する
- 編集と繰り返し
これにより、テストとデバッグが高速化され、コンテキストの切り替えが減り、完全な再デプロイなしでより安全で高速な反復が可能になり、運用環境に移行する際に規範が適用されます。