チュートリアル: Databricks Asset Bundles を使用して AI/BI ダッシュボードの変更を大規模かつ安全にシップする方法

エラーだらけのダッシュボードで役員会議が始まることを考えれば、アナリティクスチームは夜も眠れなくなるでしょう。採用計画、製品ローンチ、あるいは収益予測が、誤ったメトリクスに基づいていたと後から発覚することも同様です。あるいは、ダッシュボードが顧客の購入履歴を誤表示したせいで、サポートチームが過剰な返金を行ってしまった、という事態もまた然りです。

これらの失敗は、分析が不十分なことが原因であることはほとんどありません。他の本番運用システムと同様に、多くの場合、データモデルや要件が進化する中で、バージョン管理、信頼性の高いレビュープロセス、あるいは環境をまたいで変更を反映するための再現可能な方法がないまま、ダッシュボードが手動で更新されることが原因となっています。

このブログ記事では、ビジネスを推進する本番環境レベルのダッシュボードは、本番運用コードと同じ規律で管理する必要があるというシンプルな主張をします。Databricks AI/BIは、データパイプラインやガバナンスレイヤーと同じデータインテリジェンスプラットフォーム上で実行されるため、チームはバージョン管理、環境固有の設定、管理されたデプロイメントといった本番運用プラクティスをダッシュボードにも適用できます。

これを具体的に説明するために、アナリストが日々のダッシュボード作成方法を変更することなく、本番運用レベルのDatabricksの機能を使用する方法をご紹介します。

具体的には、このフローで何ができるかをご紹介します。

• ダッシュボードへの各変更を確認し、承認します
• ダッシュボードの履歴を追跡し、コードの変更をビジネス要件に関連付けます
• ダッシュボードを以前のバージョンにロールバックする

前提条件：

このワークフローには、ほとんどの組織がすでに導入している1回限りのインフラストラクチャ設定が必要です。これらがまだない場合は、社内の DevOps または IT グループにセットアップの支援を依頼してください:

• ダッシュボードを作成、テスト、デプロイするための少なくとも 2 つの Databricks ワークスペース (例: 開発ワークスペースと本番運用ワークスペース)
• DatabricksのGit連携フォルダー（AWS | Azure | GCP）は、ダッシュボード定義のバージョン管理に使用されます
• プロジェクト用に設定されたDatabricks Asset Bundles (DABs) (AWS | Azure | GCP)

はじめに: ダッシュボードの変更を安全に提供するための構造化されたワークフロー

現実的なシナリオを見ていきましょう。あなたは財務部門と営業部門の幹部が毎週使用するセールス パフォーマンスダッシュボードを所有しています。これは、ワークスペースで直接構築されたインターンのプロジェクトとして始まりましたが、時間とともに進化し、現在ではいくつかの役員レビューで使用されています。

取締役会での優先順位の変更により、新しい要件が発生しました。財務部門は、単一の集計売上指標に代わり、コミット済みと未コミットの売上高を追跡する必要が生じ、ダッシュボードは次の予測レビューまでに新しい定義を反映させる必要があります。

これらの値は、報酬やボーナスの計算など、実際のビジネス上の意思決定に直接反映されます。そこで、このダッシュボードを初めて規律あるデプロイメントパスに乗せてみましょう。

ステップ1: ダッシュボードをDatabricks Asset Bundleに追加する

プロセスを開始する前に、IT グループと協力して、いくつかの基本的なコードツールをセットアップします。これには、空の「Databricks Asset Bundle」を含む Git リポジトリと、バンドルを自動的にデプロイするための ci/cd スクリプトが含まれます。

Git リポジトリはファイルの変更を追跡するためのツールです。まず、Databricks に接続して、ダッシュボード構成への変更を追跡できるようにする必要があります。Databricks ワークスペースから、Git フォルダーを作成し、セットアップ ダイアログにリポジトリの URL を貼り付けます。これにより、Databricks がリポジトリを認識し、次のステップでダッシュボードをリポジトリに追加できるようになります。

Databricks アセットバンドルは、コードファイル (この場合はダッシュボード) をまとめるための方法です。リポジトリにバンドルが既に含まれている場合、自動的に検出され、矢印アイコンを使用して開くことができます。それ以外の場合は、Git フォルダの作成メニューから新しいバンドルを作成できます。

Asset Bundleエディター内で、現在空になっているバンドルに、新規コンポーネントと既存コンポーネントの両方を追加できます。ダッシュボードを含めるには、[追加] メニューを開き、[既存のダッシュボードを追加] を選択します。追加後、バンドルの一部として src フォルダ内にダッシュボードが表示されます。

これ以降、ダッシュボードはデプロイ可能なアセットとして管理されるため、同じダッシュボードを開発、テスト、本番の各ワークスペースにわたって簡単にプロモートできるようになります。

最後に、ダッシュボードをリポジトリにコミットします。これにより、ダッシュボードの現在の状態がベースラインとして記録され、今後の変更を追跡・レビューするための明確な出発点となります。

ダッシュボードがリポジトリに追加され、自動生成されたいくつかの設定ファイル（末尾が.yml）も表示されます。これらのファイルには、さまざまな環境でダッシュボードをどのようにデプロイするかが記述されています。編集する必要はありません。

コミットメッセージフィールドに実行内容を説明する短いメモを追加し、Commit & Pushを選択します。これにより、ダッシュボードのチェックポイント（後で戻ることができる既知の良好な状態）が作成され、将来の変更を比較、レビューし、安全にデプロイできます。

ステップ 2: ダッシュボードを更新する

既存のダッシュボードがコミットされたので、本番運用に影響を与えることなく変更を開始できます。あなたが行った具体的な変更は Git によって追跡されます。

一般的には、Git branchを作成します。これは、他のユーザーに影響を与えることなく作業するためのダッシュボードのバージョンです。これを行うには、「Create Branch」ボタンを使用し、自分の名前、機能、変更に関連付けられたチケット番号など、わかりやすい名前を付けます。これは、更新のためのプライベート バージョンだとお考えください。ダッシュボードを自由に編集、テスト、調整し、変更をレビューしてデプロイする準備が整ったときに、別途判断することができます。

これで、ダッシュボードに変更を加えることができます！このケースでは、左上の売上数を変更して、未コミットとコミット済み両方の売上カウンターを追加します（視認性を高めるために太字の青と赤を選択しています）。

オーサリング体験は何も変わりません。ダッシュボードの UI エディタを使用して、通常どおりこれらの変更を行ってください。

開発環境でダッシュボードが正しく表示されたら、変更を本番運用に反映させるプロセスを開始する準備が整います。以前と同様に、上部にあるGitボタンを使用して、短いコミットメッセージを付けてこれらの変更をチェックインします。

ステップ3: 変更をレビュー

次に、このワークフローのもう1つの重要なメリットを活用できます。それは、変更が本番運用に適用される前に、他の人が変更をレビューし、フィードバックを提供する場ができることです。2人目のレビューを必要とすることは一般的なベストプラクティスですが、それと同じくらい重要なのは、レポートに影響を与える前に、アイデアを議論し、仮説を検証し、変更を洗練させるためのリスクの低いスペースが生まれることです。

レビューを開始するには、Git プロバイダーでプルリクエスト (PR) を作成します。これは基本的に、ダッシュボードの更新内容を確認するためのレビューページです。レビュアーは、変更内容を正確に確認し、対応が必要なコメントを残し、すべてが問題ないと判断したら更新を承認できます。

レビュー中は、本番運用ダッシュボードは変更されません。フィードバックに対処し、変更が承認された後にのみ、処理が先に進みます。

ダッシュボードの変更はバックグラウンドで構成ファイルとして保存・追跡されますが、実際に何が変更されたかを把握するのは難しいことがよくあります。このため、ほとんどのチームでは、PRがオープンされるたびに、レビュー用にダッシュボードの一時的なテストバージョンを自動でデプロイする、小規模な自動化を使用しています。これにより、レビュー担当者は本番運用に反映される前に、提案されたメトリクス、計算、レイアウトをコンテキストに沿って確認し、データロジックやUIの問題を把握できます。開発者やレビュー担当者がテスト用ダッシュボードのスクリーンショットやLinkを PR に直接含めることで、フィードバックがより迅速かつ確実になります。

レビュアーはコメントを追加して承認でき、それらは記録されるため、後で変更内容を容易に理解できます。

ステップ4: バンドルを使用してダッシュボードを本番運用にデプロイする

変更が承認され、ダッシュボードを本番運用にデプロイする準備が整いました。

ダッシュボードは、本番運用と開発環境で異なる設定が必要になることがよくあります。例えば、開発データセットの代わりに本番運用カタログやスキーマを指定したり、別のSQLウェアハウスを使用したりする場合などです。

幸いなことに、これらの違いは想定済みであり、デプロイメントプロセスの一部として処理されます。

アセットバンドルにダッシュボードを追加すると、Databricksによって小さな.ymlが生成されましたこれらの環境固有の設定を格納する構成ファイル。このファイルを使用すると、ダッシュボードのロジック自体を変更することなく、環境ごとに値を上書きできます。この例では、カタログ名に ${variable} の値を使用することで、ダッシュボードが本番運用で使用するカタログがテスト環境とは異なるように指定しました。

最後に、databricks.yml ファイルは、すべてのバンドルリソースをまとめ、各環境で使用されるカタログを定義することで、開発、テスト、本番運用 の各ワークスペースにわたって一貫したデプロイメントの管理を容易にします。

プルリクエストが承認されてメインブランチにマージされると、デプロイメントの自動化が実行され、databricks.ymlで定義された環境固有の値が使用されます。同じダッシュボードコードがワークスペース間で再利用され、カタログ、スキーマ、warehouseなどの設定はターゲット環境に基づいて適用されます。これにより、ワークスペースごとに個別のダッシュボードのコピーを維持する必要がなくなり、変更がどこでも予測どおりに動作することが保証されます。

ほとんどのGitプロバイダーでは、プルリクエスト上でデプロイの自動化を確認できるため、デプロイを監視して完了時（または問題発生時）に確認できます。問題が発生した場合、デプロイは既存の本番運用ダッシュボードに影響を与えることなく停止し、トラブルシューティングが可能になります。デプロイが正常に完了すると、更新されたダッシュボードが本番運用で公開され、ステークホルダーが利用できる状態になります！

ボーナス1：履歴を詳しく見たい場合はどうしますか？

ダッシュボードの更新が公開されると、何が、いつ、なぜ変更されたのか、その履歴を把握する必要があるかもしれません。このフローの利点の1つは、変更が追跡可能になることです。ワークスペースで直接行われる1回限りの編集ではなく、保存された一連のバージョンとして表示されます。

各エントリはダッシュボードの更新を表し、作成者とタイムスタンプが含まれています。任意のエントリを開いて変更内容を確認し、必要に応じてロールバックできます。

利点2: 変更を元に戻す必要がある場合はどうしますか？

慎重にレビューやテストを行っても、ダッシュボードが読み込まれない、メトリックの定義が間違っているといった問題が発生する可能性があります。

ダッシュボードはこのワークフローを通じて管理されるため、更新のデプロイに使用したのと同じ管理プロセスを使用して、正常であることが確認済みのバージョンにロールバックできます。

まず、リポジトリでダッシュボードの変更履歴を開き、元に戻したい更新を見つけます。そこで、先に進む前に変更点を確認し、正しい変更を元に戻しているか確かめることができます。

変更の詳細から、リンクをたどってレビューページに戻ります。更新をロールバックするには、[元に戻す] を選択します。これにより、新しい「元に戻す」変更が作成されます。この変更はその特定の更新のみを取り消し、ダッシュボードのロジックを以前の状態に復元しますが、ダッシュボードの残りの履歴はそのまま維持されます。

変更が main ブランチにマージされると、ダッシュボードを本番運用にデプロイしたのと同じ自動化によってロールバックされます。これにより、すでに導入されている制御をバイパスすることなく、障害や影響の大きい計算の問題に数分で対応できます。

ボーナス 3: データソースが更新された場合はどうなりますか？

ほとんどのダッシュボードはデータソースと密接に連携しています。つまり、ダッシュボードの更新は、多くの場合パイプラインの更新と密接に関連しているということです。幸いなことに、アセットバンドルは関連コンポーネントを 1 つのパッケージにグループ化するように設計されています。

これにより、上流のデータモデルの変更に不意を突かれることがなくなり、可視化の変更にデータモデルの更新が必要な場合は、1回のデプロイメントで両方の変更を展開できます。

まとめ

AI/BI ダッシュボードを本番運用レベルのデータ製品として扱うことは、信頼性の高いビジネス上の意思決定とリスク軽減のために不可欠です。このワークフローでは、日々のダッシュボードの作成方法を変えることなく、少数の追加ステップによってダッシュボードの変更が可視化され、レビュー可能になり、元に戻すこともできます。

GitとDatabricksアセットバンドルでダッシュボードを管理することで、チームは変更、レビュー、テスト、デプロイという、更新のための定型的で予測可能なワークフローを確立します。更新が小さな表示上の調整であっても、ビジネスロジックの重要な変更であっても、同じプロセスが適用されます。

適切なデプロイ規律を導入することで、ダッシュボードの変更はリスクのソースではなくなり、取締役会のような重要な場面でもビジネスとともに進化する、信頼できる知見のソースとなります。

詳細情報 + 次のステップ

このワークフローで使用されている要素についてさらに詳しく知りたい場合は、次に役立つリソースをいくつか紹介します。

• 「ブランチ戦略」 (AWS | Azure | GCP)
  ベストプラクティスに従ったブランチング モデルを使用して、変更をマージおよびデプロイする方法について説明します。
• Databricks アセットバンドル (AWS | Azure | GCP)
  アセットバンドルを使用して、環境間で Databricks リソースを一貫してパッケージ化およびデプロイする方法について学びます。
• Databricksでの自動デプロイのためのCI/CD (AWS | Azure | GCP)
  スターターGithub Actionsスクリプト (AWS | Azure | GCP) を使用してCI/CDを実装する方法について学びます。
• Databricks ワークスペース UI でのアセットバンドルの使用 (AWS | Azure | GCP)
  ワークスペースから直接バンドルを作成、編集、デプロイする方法を説明します。
• DatabricksのGit対応フォルダー(AWS | Azure | GCP)
  DatabricksでのGit統合の仕組みと、バージョン管理が日々のアナリティクスワークフローにどのように適合するかについて説明します。

Databricks AI/BI で次のステップに進む準備ができましたら、次のいずれかのオプションを選択できます。

• 無償版とトライアル: 無償版またはトライアルにサインアップして、実際に体験してください。
• ドキュメント: ドキュメントで詳細をさらに掘り下げてご覧ください。
• ウェブページ: 詳細については、ウェブページをご覧ください。
• デモ: デモ動画や製品ツアー、ハンズオン チュートリアルで、これらのAI/BIが実際に動作する様子をご覧ください。
• トレーニング: Databricks Academyの無料製品トレーニングから始めましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事