AI/BIダッシュボードのパフォーマンスを最適化するためのトップ10のベストプラクティス(パート1)

ダッシュボードのパフォーマンスの問題は、単一の原因で発生することはほとんどありません。これらは通常、ダッシュボードの設計、ウェアハウスの同時実行性とキャッシュ、そしてレイクハウス内のデータレイアウトの複合的な影響によるものです。SQL、コンピュートのサイジング、テーブルのレイアウトといった1つのレイヤーのみを最適化した場合、部分的な改善は見られることが多いですが、実際の使用状況ではダッシュボードの動作が遅くなったり、予測不能になったりすることがあります。

この投稿では、Databricks AI/BIのパフォーマンスに包括的なアプローチで取り組みます。ブラウザとAI/BIオーケストレーションレイヤーから、Databricks SQLのアドミッションとキャッシュの動作を経て、Lakehouseでのファイルスキャンとデータスキッピングまで、ダッシュボードのインタラクションをエンドツーエンドで追跡します。その過程で、特に多くのユーザーが同じダッシュボードを同時に操作する場合に、大規模な環境でレイテンシの急増、キューイング、コスト増を最も頻繁に引き起こすパターンに焦点を当てます。

AI/BI ダッシュボード更新の仕組み

パフォーマンスを最適化するには、まず 1 回のクリックがスタック全体をどのように移動するかを理解する必要があります。ユーザーがダッシュボードを開いたり、フィルターを変更したりすると、複数のレイヤーにわたって連鎖反応が起こります。いずれかのレイヤーの設定が間違っていると、ユーザーはラグを感じます。

• ブラウザ(クライアントサイド): これは最初の防衛線です。100,000行未満かつ100MB未満のデータセットの場合、ブラウザがローカルエンジンとして機能し、フィールドフィルターやチャート間のインタラクションをメモリ内で瞬時に処理します。データがこのしきい値を超えると、すべてのインタラクションはウェアハウスに戻る必要があります。
• ダッシュボードのデザイン（オーケストレーター）：AI/BIサービスが、どのクエリーを実行する必要があるかを決定します。「単一ページ」のデザインでは、すべてのウィジェットのクエリーが同時に送信されるため、大規模な同時実行の急増が発生します。「複数ページ」のデザインでは、表示されているtabのデータのみを要求するため、コンピュートへの要求を効果的に形成します。
• Databricks SQL (エンジン): お客様のSQLウェアハウス (理想的にはサーバーレス) がバーストを受信します。複数のレイヤーを持つキャッシュをチェックし、その処理がすでに行われているかどうかを確認します。そうでない場合、Intelligent Workload Management (IWM) がクエリーを受け入れ、数秒でクラスターをオートスケールして、キューイングなしで負荷を処理します。
• Lakehouse(ストレージ): 最後に、エンジンがデータにアクセスします。クラウドオブジェクトストレージ内のDeltaファイルをスキャンします。ここでは、リキッドクラスタリングとデータ型がI/O効率を決定します。ファイルレベルの統計情報とメタデータを使用して可能な限り多くのデータをスキップし、結果セットを上位の処理に返すことが目標です。

これら4つのタッチポイントをそれぞれ最適化することで、ブルートフォースのコンピュートから脱却し、ユーザーの増加に合わせて拡張できる合理化されたアーキテクチャへと移行できます。

前提条件 - データとダッシュボードを理解する

何かを最適化する前に、まず何を目的として最適化するのかを定義する必要があります。ダッシュボードのパフォーマンスは単一の概念ではなく、明確な目標に結びついて初めて改善が意味を持ちます。一般的な目標には、最初のビジュアルが表示されるまでの時間の短縮、インタラクションの遅延の改善、同時実行下でのパフォーマンスの安定、ダッシュボードビューあたりのコストの削減などが含まれます。

目標が明確になったら、それを形成するパラメーターを理解する必要があります。これらには、データのサイズと増加、ユーザー数とそのアクセスパターン、そしてクエリーが実際にどのように動作するか（ページ読み込み時にいくつ実行されるか、どれくらいのデータをスキャンするか、結果が再利用されるか、常に再計算されるか）が含まれます。このようなコンテキストがないと、最適化は当てずっぽうになり、コストやレイテンシがあるレイヤーから別のレイヤーに移動するだけになることがよくあります。

したがって、効果的なダッシュボードの最適化は意図的に行われます。測定可能な目標を選び、それに影響を与えるデータと使用パターンを理解し、その上で初めて、後述する技術的な最適化を適用します。

最適化#1: ダッシュボードをページ（タブ）に整理する 

表示されているすべてのタイルがpotential triggerになる可能性があります。タイルは最初の読み込み時にランされ、フィルター/パラメーターの変更時、更新時、ユーザーがページに戻ったときに再ランされる可能性があります。タブを使用すると、これらの再実行がアクティブなページに限定され、バーストやヘッドオブラインブロッキングが削減されます。

AI/BIダッシュボードでは、複数ページのレポートを構築できます。ユーザーの意図（概要→調査→詳細分析）に合わせてビジュアルをページにグループ化し、現在のページのみが実行されるようにします。これにより、ヘッドオブラインブロッキングが減少し、同時実行がより小さなバーストに形成され、繰り返し実行される決定論的なクエリーのキャッシュヒット率が向上します。

推奨されるページタイプ:

• 概要: 最初の描画のために高速なカウンターとトレンドラインを使用し、負荷の高い結合やウィンドウ関数はランディングページから除外します。
• 調査: 事前集計の削減が必要な場合は、SQLに述語をプッシュするフィルター(パラメーター)を使用して、エンティティ(顧客/製品/地域)に焦点を当てた探索を行います。
• 詳細分析：スケジュールされた更新またはマテリアライズド/メトリックビューによって実行される、コストの高い集計（ダッシュボードのデータセットをマテリアライズドビューにエクスポートできます）。

決定的なタイルを優先し (NOW() の使用を避ける)、結果キャッシュのヒット率を最大化します。ピークキュークエリを監視し、その値が常に 0 を超えている場合は、クラスターサイズを大きくするか、最大クラスター数を増やしてください。

AI/BIダッシュボードのドリルスルー機能は、選択したコンテキストを引き継ぎながら、高レベルのビジュアルから詳細なページへのナビゲーションを可能にします。これは、ユーザーの意図が明確になるまでコストの高いクエリーを遅延させることでページベースのデザインを適用するための有効な戦略であり、ファーストペイントのパフォーマンスを向上させ、不要な同時実行の急増を削減します。

コールアウト — これがどのwarehouseタイプでも役立つ理由: より小さく、予測可能なバーストにより、Serverless IWM は迅速に反応して過剰なスケーリングを回避し、Pro/Classic がページの読み込み中にクラスタースロットを飽和させるのを防ぎます。 

詳細については、以下を参照してください: https://www.databricks.com/blog/whats-new-in-aibi-dashboards-fall24

最適化その 2: スマートなデフォルトで「初回ペイント」を最適化する

ダッシュボードの第一印象は、その初回ペイント (ダッシュボードを開いてから意味のある結果が表示されるまでの時間) によって決まります。デフォルトのフィルター値は、ページの読み込み時にどのクエリーがすぐに実行されるか、そしてそれらのクエリーが処理する必要のあるデータ量を決定するため、ここで重要な役割を果たします。

フィルターにデフォルトが設定されていない場合、AI/BI ダッシュボードは最初に開くときにデータセット全体を読み込むことがよくあります。これにより、スキャン量が増加し、タイル全体にわたるクエリーのファンアウトが増え、ユーザーが実用的な知見を目にするまでの時間が遅くなります。その結果、特に多くのユーザーが同じダッシュボードを開くピーク時の同時アクセスにおいて、初回エクスペリエンスが低速で予測不可能になり、ユーザーに苦痛を与えます。

スマートデフォルトは、初期クエリーの形状を制約することでこの問題を解決します。一般的な例は次のとおりです。

• 日付フィルターを最近の期間（例：過去7日間または30日間）にデフォルト設定します。
• 一般的な地域、事業部門、またはトップレベルのエンティティを事前に選択する。
• 選択的でありながらも意味のある「すべて」を選択する(例: すべての履歴ではなく、現在の会計年度)。

技術的には、デフォルトフィルターはスキャンされるデータ量を削減し、キャッシュヒット率を向上させ、同じ初期状態でダッシュボードを開くユーザー間での結果の再利用を可能にします。これにより、最初のビジュアルが表示されるまでの時間が直接的に改善され、パフォーマンスの一貫性が大幅に向上します。

主要な設計原則はシンプルです。ランディングエクスペリエンスを最適化することです。ファーストペイントを高速かつ情報量の多いものにし、その後、ユーザーが探索するにつれて意図的に範囲を広げられるようにします。高速なファーストペイントは信頼を構築し、導入を促進し、その後のすべてのインタラクションのパフォーマンスベースラインを設定します。

詳細については、以下を参照してください: https://docs.databricks.com/aws/en/dashboards/filters#-set-default-filter-values

最適化その3: パラメーターを使用して大規模なデータセットをスライスする

パラメーターは、クエリーが実行される前にクエリーを形成するため、AI/BIダッシュボードをスケーリングするための最も効果的な方法の1つです。SQLに値を直接挿入することで、述語を早期にプッシュダウンします。その結果、Databricksはより早くデータをプルーニングでき、クエリーあたりの作業量を大幅に削減できます（理想的には、結合や集計の前にフィルタリングします）。

フィールドフィルターの動作は異なります。基になるデータセットがブラウザにキャッシュできるほど小さい場合 (10万行以下、100MB以下)、フィールドフィルターとクロスフィルターのインタラクションは、ウェアハウスとのラウンドトリップなしでクライアント側で評価できます。データセットがそのthresholdを超えると、フィールドフィルターは通常、データセットクエリーを(多くの場合CTEを介して)ラップすることでwarehouseにプッシュされます。これによりバックエンドのSQL実行がTriggerされますが、結合と集計の前に適用されるパラメーター化された述語ほど効果的にスキャンコストを削減できない場合があります。

パラメーターは、データ量を大幅に削減する日付範囲、地域、事業部門、またはその他のディメンションでスライスする場合に特に効果的です。また、パフォーマンスもより予測しやすくなります。各タイルがより安価なクエリーを実行するため、同時実行の急増をwarehouseが吸収しやすくなります。

トレードオフがあります。パラメーター値が異なるとクエリー署名も異なるため、ユーザーが常に一意の値を選択する場合、キャッシュの再利用率が低くなる可能性があります。実際には、これは通常、正しい妥協点です。キャッシュ ヒットのない、小さく安価なクエリーの方が、キャッシュに依存する、大きく高価なクエリーよりもはるかに優れています。よく使われるパスが引き続き結果キャッシュの恩恵を受けられるように、適切なデフォルト値と限定された一般的なパラメーター値のセットを使用することで、このバランスをさらに調整できます。

実用的な経験則は次のとおりです。データセットをブラウザキャッシュに収まる程度に小さく保ち、インタラクティビティにはフィールドフィルターを使用します（最良のケース：warehouseへのラウンドトリップなし）。データセットが確実にブラウザキャッシュの制限内に収まる自信がない場合は、パラメーターを使用して早期にデータセットを削減し（warehouseが最初に読み取るデータ量を減らす）、その後、より深い探索のためにフィルターを適用します。これにより、「すべてをスキャンして後でフィルタリングする」ダッシュボードが、データやユーザーが増えても高速を維持する、選択的でスケーラブルなクエリーに変わります。

詳細については、以下を参照してください:

• https://medium.com/@andrea0pica/databricks-ai-bi-caching-explained-0c4de1aa946b

最適化その4: ブラウザキャッシュを使用する

ブラウザのキャッシュは、インタラクションが小さなデータセットに対するフィールドフィルターベースである場合に最も役立ちます。パラメーターがSQLを変更したり、データセットがブラウザのthresholdを超えたりすると、インタラクションはウェアハウスの実行に戻ります。

Databricks AI/BI ダッシュボードは、データセットの結果をユーザーのブラウザに直接キャッシュできるため、SQL ウェアハウスとのラウンドトリップなしに、多くのインタラクションを完全にクライアント側で処理できます。

データセットがおよそ100,000行未満の場合、ブラウザがローカル実行エンジンになります。クロスフィルター、並べ替え、単純な集計はメモリ内で即座に解決でき、ほぼゼロレイテンシーのインタラクションを実現し、バックエンドの同時実行の負荷を完全に排除します。このため、うまく設計された概要ページは、高負荷な使用状況下でもしばしば「瞬時」に感じられます。

ブラウザのキャッシュは、次の場合に自動的に使用されます:

• データセットは十分に小さいため、安全にブラウザに読み込むことができます。
• インタラクションが、クライアント側で評価できるフィールドフィルターまたはクロスチャート選択に基づいている。
• パラメーターの変更によって、warehouseでのSQLの再実行が強制されない。

データセットがこのthresholdを超えて増加した場合、またはパラメーターが基になるSQLを変更した場合、インタラクションはwarehouseにプッシュバックされ、ブラウザのキャッシュは適用されなくなります。

設計上の重要なポイントは、意図的なデータセットのサイジングです。ランディングページと概要のデータセットを、コンパクトで事前集計され、一般的なKPIに焦点を当てたものに保ち、ブラウザキャッシュの対象となるようにします。これにより、瞬時の「初回描画」が実現し、クエリーのファンアウトが削減され、バックエンドでの実行が避けられない、より詳細な調査ページのためにウェアハウスの容量が温存されます。

詳細については、次を参照してください: https://docs.databricks.com/aws/en/dashboards/caching#dataset-optimizations

最適化その5: 結果キャッシュの使用を最大化する

最も安価で最速のクエリーは、実行しないクエリーです。

Databricks SQLの結果キャッシュは、結果を再計算する代わりにキャッシュから提供することで、繰り返されるダッシュボードのインタラクションをほぼ瞬時の応答に変えます。

結果キャッシュの仕組み（何が、どこに、どのくらいの期間キャッシュされるか）

Databricks SQL は、クエリーを実行する前にキャッシュされた結果を確認します。

• ローカル結果キャッシュ (すべてのウェアハウス): クラスターごとのキャッシュです。
   
• リモート結果キャッシュ (サーバーレス): ワークスペース全体で有効で、warehouseの再起動後も永続化します。

どちらのキャッシュにも約24時間のTTLがあり、基になるテーブルが変更されると無効化されるため、再利用のメリットを享受しながら鮮度を保つことができます。

キャッシュヒットが発生しやすくなるようにダッシュボードを設計する

キャッシュヒットは自動的に行われるものではなく、設計の結果として得られるものです。多くのユーザーがウェアハウスに同じ方法で同じ質問をすることで、最大限の価値が得られます。

1) タイルを決定論的にする
非決定論的な関数（例：NOW() / current_timestamp()）は、クエリーの結果を変えて再利用を妨げるため、使用を避けてください。明示的な日付/時刻パラメーターを使用し、クエリーテキストを安定させて、同一の選択がキャッシュから提供されるようにしてください。

2) データセットを再利用し、クエリーの「形状」を一貫させる
タイルが同じデータセットロジックと一貫した述語/グループ BYの形状を共有すると、キャッシュと再利用が劇的に改善します。複数のビジュアルが同じバックエンドクエリー(または同じ正規データセット)で応答できる場合、発行されるステートメントの数が減り、かつキャッシュのヒット率が向上します。

3) ID と権限借用に注意する
結果キャッシュの再利用は、同じクエリーが同じアクセスコンテキストで実行される場合に最も効果的です。セットアップでビューアーごとの権限借用を使用している場合、結果をアイデンティティ間で常に安全に共有できるとは限らないため、キャッシュの再利用が減少する可能性があります。
ベストプラクティス: セキュリティとガバナンスの観点から許容される場合は、公開済みダッシュボードに共有実行 ID (サービスプリンシパルや共有アクセスコンテキストなど) を使用することを推奨します。これにより、繰り返し表示する際にキャッシュの再利用によるメリットを享受できます。ユーザーごとの権限借用を使用する必要がある場合は、データセットの再利用を最大化し、決定的でパラメーター化された共通パスに焦点を当てることで補います。

繰り返しのインタラクションにはサーバーレスを優先する

Serverless はリモート結果キャッシュを追加します。これはワークスペース全体で共有され、再起動後も維持され、ODBC/JDBC クライアントと SQL Statement API によっても使用されます。繰り返し開かれ、共通のフィルターパスを持つダッシュボードの場合、これは多くの場合、最大の「無料の」パフォーマンス向上をもたらします。

事前にキャッシュをウォームアップする

公開済みのダッシュボードには、スケジュールを追加します。スケジュールランにより、ピーク時間前にデータセットのロジックを実行してキャッシュにデータを格納することで、初回描画が改善され、正時のバーストが平滑化されます。

ヒットを確認する（そして誤解を招くベンチマークを避ける）

使用:

• クエリー履歴: from_result_cache and cache_origin_statement_id
• キャッシュの適格性を理解するためのEXPLAIN EXTENDED

注意事項：

• ローカルキャッシュには、約500 MiBを超える結果は挿入されません（リモートキャッシュにはサイズ制限はありません）。
• リモートキャッシュには、Cloud Fetchをサポートするクライアントが必要です（古いドライバーでは利用できない場合があります）。

ベンチマークでは、制御されたテスト中にのみキャッシュを無効にします:
SET use_cached_result = false
…そして、ダッシュボードが本番運用でキャッシュの恩恵を受けられるように、実際の使用では再度有効にします。

運用上の衛生管理: キャッシュ汚染の回避

同じBIウェアハウスで、関連のないワークロードを混在させないでください。ドメイン/ワークロードごとに専用のサーバーレスBI warehouseを使用すると、それらのダッシュボードにとって重要な繰り返しクエリーでリモートキャッシュが満たされやすくなります。

詳細については、以下を参照してください: https://www.databricks.com/blog/understanding-caching-databricks-sql-ui-result-and-disk-caches 

展望：パート2

このパートでは、warehouseとデータが関与する前の段階で、ダッシュボードの設計とインタラクションのパターンがどのようにパフォーマンスを形成するかに焦点を当てました。ファンアウトを削減し、ファーストペイントを最適化し、キャッシュの再利用を最大化することで、基になるデータを変更することなく、多くの場合、大きな改善を実現できます。パート2では、プラットフォームをさらに深く掘り下げ、適切なSQLウェアハウスの選択とサイジング方法、データモデリングとファイルレイアウトがスキャン効率に与える影響、そして使用量の拡大に応じてダッシュボードを高速かつ安定に保つための事前計算、マテリアライゼーション、データ型の活用方法について説明し、全体像を完成させます。

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