Databricks アセットバンドルに関する FAQ

この記事では、Databricks アセット バンドルに関してよく寄せられる質問の一覧を示します。

なぜ開発用と本番運用用の対象環境を分ける必要があるのですか?

開発環境と製品環境を分離すると、次のことが可能になります。

• 開発変更を安全に分離して、誤って本番運用に影響を与えないようにします。
• 特定のターゲット環境に適用するリソースをカスタマイズすることで、コードの重複を防ぎます。
• CI/CD を合理化および簡素化するには、データベース パス、アラート、アクセス制御などの環境固有の構成を使用します。
• チームや環境間でワークフローを再利用します。

ターゲットを使用して、バンドル・デプロイメント環境を定義します。「ターゲット」を参照してください。

組織全体でバンドルの一貫性を保つにはどうすればよいですか?

バンドルテンプレートを使用して、一貫性のある構造を実現し、セットアップエラーを減らし、ベストプラクティスを促進します。デフォルトのバンドルテンプレートを使用することも、独自のカスタムバンドルテンプレートを作成することもできます。「Databricks Asset Bundle プロジェクト テンプレート」を参照してください。

同じクラスタリング定義など、バンドル全体で多くの繰り返しがあります。 これに対処する最善の方法は何ですか?

カスタム変数は、繰り返しやコンテキスト固有の設定を処理するのに最適な方法です。カスタム変数を参照してください。

デプロイ フローでバンドルを使用する場合のベスト プラクティスにはどのようなものがありますか?

Databricks では、次のことをお勧めします。

• 手動デプロイから、Git 統合ワークフローを使用した信頼性の高い自動化に移行します。
• CI/CD パイプラインで databricks bundle validate を使用してバンドルをデプロイする前に検証します。
• デプロイ手順を分離して、変更がレビューされ、意図的なものであることを確認します。
• 環境 (開発、ステージング、運用) をオーバーライドでパラメーター化し、変更を分離します。
• デプロイ後に統合テストを実行して、問題を早期に発見します。
• GitHub Actions、Azure DevOps、または GitLab CI を使用して、コミットまたは PR マージ時にデプロイをトリガーします。
• 何を、どこで、いつデプロイしたかを追跡することで、すべてのデプロイがコミットとバンドルのバージョンにマッピングされます。

既存のジョブ、パイプライン、ダッシュボード、その他の Databricks オブジェクトをバンドルに移植できますか?

はい。 databricks bundle generate コマンドを使用して、ローカルバンドル内の既存のジョブ、パイプライン、またはダッシュボードの設定ファイルを生成し、 databricks bundle deployment bind を使用してバンドルリソースをワークスペース内の対応するリソースにバインドします。これは、既存のワークフローを構造化されたバージョン管理された開発にオンボーディングするのに最適です。また、バインドは相対パスを絶対ワークスペース参照に解決するため、パス エラーが回避されます。

「既存のリソースをバンドルに移行する」を参照してください。

バンドルを反復的にテストするにはどうすればよいですか?

反復的なデプロイと実行により、より迅速に開発できます。

• デプロイ前に検証する
• 段階的にデプロイ
• 必要なものだけを実行する
• 編集と繰り返し

これにより、テストとデバッグが高速化され、コンテキストの切り替えが減り、完全な再デプロイなしでより安全で迅速なイテレーションが可能になり、本番運用に移行する際の規律が強化されます。