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

この記事は、大規模なDatabricks AI/BIダッシュボードのパフォーマンスを最適化する方法に関する2部構成シリーズの第2部です。 

前回の投稿では、layout、フィルター、パラメーター、キャッシュが、クリックごとにシステムが行う作業量をどのように決定するかに焦点を当てました。これらの最適化だけで、ダッシュボードが高速であると感じられることがよくあります。

この記事では、使用量の増加に伴い高速性を維持するプラットフォーム基盤に焦点を当てます。warehouseの選択とサイジング、データモデリングとスキーマの選択、ファイルlayoutとクラスタリング、そして安定した予測可能なパフォーマンスを実現するために再計算の代わりにマテリアライゼーションにいつ頼るべきかについて見ていきます。

最適化 #6：設計に合ったウェアハウス構成を選択する

ダッシュボードの形状（ページ、クエリーの組み合わせ、ユーザーのバースト性）をDBSQLウェアハウスのタイプとサイジングに合わせ、システムがキューイングなしで迅速に作業を受け入れられるようにします。

表示されているウィジェットは同時に送信されるため、ダッシュボードでは自然と短期的な同時実行の急増が発生します。ウェアハウスがバーストを吸収できない場合、キューイング（ピーク時のキュー登録クエリー数 > 0）が発生し、特にピーク時にはタイルの読み込み時間にばらつきが生じます。

DBSQLウェアハウスの同時実行性の仕組み

• サーバーレス + IWM: サーバーレスは、Intelligent Workload Managementを使用してコストを予測し、クエリーを承認して優先順位を付け、迅速にオートスケールします。一般的な起動時間は2〜6秒であるため、手動でチューニングしなくてもバーストのレイテンシーは低く抑えられます。
• Pro/Classic: 「クラスターあたり 10 の並列クエリー」というゲートは固定されており、自動スケーリングは分単位のthresholdでクラスターを追加し、startupには数分かかります。予想される並列実行数に基づいてキャパシティを計画し、ページ読み込み時の急増を避けてください。
• 監視と適切なサイジング: Peak Queued Queriesとクエリー履歴を監視し、ピークが0を超え続ける場合は、クラスターサイズを大きくするか（特にクエリー Profileがディスクへのspillを示している場合）、最大クラスター数を増やします。

なぜサーバーレスファーストなのか

• インタラクティブBIにはサーバーレスを推奨: 最速の起動、IWMによる動的な同時実行性、より効率的なIO。

実践的なサイジングのヒューリスティクス

• まず大きなクラスターサイズから開始し、テスト後にサイズを小さくします。Serverlessのオートスケールで同時実行の急増に対応し、キューのピークが続く場合にのみ最大クラスター数を増やします。
• 負荷の高いETLとBIは分離する: ワークロード/ドメインごとに専用のサーバーレスウェアハウスを割り当てる(キャッシュ汚染を回避し、IWMにワークロードパターンを学習させる)。
• 小規模で頻繁なクエリーを優先する: Serverless IWMは短いインタラクションを保護し、混合負荷時に迅速にスケールします。概要が最も軽いタイルを最初に実行するようにページを設計します。

詳細については、https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior をご覧ください。

最適化 #7: データ モデリングのベスト プラクティスを適用

適切に設計されたデータモデルは、AI/BI ダッシュボードのパフォーマンスの基礎となる重要な機能です。スター スキーマは、BI クエリーの記述方法と最適化方法に直接対応するため、インタラクティブ アナリティクスにとって最も効果的で予測可能なモデリング パターンであり続けます。

スター スキーマでは、中央のファクト テーブルに測定可能なイベント (売上、トランザクション、クリック) が含まれ、周囲のディメンション テーブル (日付、顧客、製品、地域) に結合されます。この構造により、結合の複雑さが最小限に抑えられ、データの重複が減り、シンプルで安定したクエリーパターンで効率的な集計が可能になります。その結果、ダッシュボードが実行する結合の数が減り、スキャンするデータ量も少なくなり、キャッシュとクエリーの最適化からより一貫して恩恵を受けることができます。

重要でありながら見落とされがちな詳細が、結合キーのデータ型です。ディメンションテーブルとファクトテーブルの結合には、文字列ではなく、整数ベースの代理キーを使用する必要があります。整数の結合は大幅に高速で、必要なメモリも少なく、キャッシュ効率を向上させ、Photonが高度に最適化されたベクトル化パスを使用して結合を実行できるようになります。文字列ベースの結合はCPUコストを増加させ、データと同時実行数が増加するにつれて隠れたボトルネックになる可能性があります。

Databricksでは、このパターンはLakehouseアーキテクチャと自然に適合します。ゴールドレイヤーは、AI/BIダッシュボード、メトリクスビュー、マテリアライズドビューに、ガバナンスが効いた再利用可能なセマンティック基盤を提供するために、Unity Catalogテーブルとして保存されたファクトとディメンションとしてモデル化する必要があります。

要点はシンプルです。BIクエリーが実際にどのように実行されるかをモデル化することです。ゴールドレイヤーで整数の結合キーを持つスター スキーマを使用すると、SQLがよりシンプルになり、結合が高速化され、大規模な環境でのパフォーマンスがより予測可能になります。

最適化 #8: Parquet の最適化手法

ダッシュボードがクエリーごとに読み取るデータ量を大幅に削減できるようにデータレイアウトを設計し、エンジンがParquetの統計情報とセレクティブリードを活用できるようにします。

ファイル レイアウトをパフォーマンス機能として扱う

Databricks SQLは、次の場合に最速になります。

• メタデータ（最小/最大統計）を使用してファイル全体をプルーニングする
• 大規模で連続したチャンクを効率的に読み取る
• そして、何千もの小さなファイルを開くことを回避します。

したがって、2つの最大の利点は次のとおりです。ファイルを最適なサイズに圧縮すること、および
述語がファイルをプルーニングできるようにデータをクラスタリングすることです。

詳細はこちらをご覧ください: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

典型的なアンチパターン: WHERE customer_id = ? のようなダッシュボード フィルター選択的に見えますが、データがクラスタ化されていない場合、一致する行がいたるところに散在しているため、エンジンは依然としてファイルの大部分にアクセスします。

テクニック

• Parquet上の組み込み予測IOのメリットを活用するには、Photonを使用してください。Photonは、AI支援による選択的読み取りと並列IOを適用して一致しないブロックをスキップし、リストするファイル数を減らすことで、手動でのインデックス作成なしに高速な選択的スキャンを実現します。
• マネージドテーブルの予測的最適化を有効にする: Databricks は、観測されたワークロード パターンに基づいてテーブル メンテナンスを自動的にスケジュールして実行できます。—OPTIMIZE (ファイル サイズを健全に保つためのコンパクション)、ANALYZE (最新の統計情報)、VACUUM (クリーンアップ)、リキッドクラスタリング (アダプティブ layout) などです。—これにより、手動でのチューニングから解放され、大規模な読み取りの価格性能が向上します。実際には、これにより (OPTIMIZE を使用して) 小さなファイルを事前に圧縮することでファイル サイズが健全に保たれ、Parquet メタデータ (フッター + min/max 統計) が、データ スキッピング、選択的スキャン、BI スキャン/同時実行処理で効果的に機能し続けます。
• 必要な場合は同じ操作を手動でTriggerする: 大量の取り込み/バックフィルやスキーマ変更の後、あるいは既知のレポートピークの前など、より厳密な制御やより迅速な効果を得たい場合は、OPTIMIZE や ANALYZE などのコマンドをランして、引き続き自分で操作をランできます。重要なのは意図的であることです。メンテナンスの頻度をテーブルの変更頻度に合わせて調整し、コンピュート コストが、同時実行性、レイテンシ、スキャン効率といった下流工程でのメリットによって正当化されるようにします。
• 大規模なパーティショニングの代わりに、リキッドクラスタリング を採用してください。Liquid はポイント参照と選択的スキャンのためにデータを増分クラスタリングします。クラスタリング列は (高カーディナリティであっても) いつでも完全な書き換えなしで変更でき、layout は使用状況の変化に応じて適応します。
• レイアウトをダッシュボードの述語に合わせます。Predictive IOが「調査」および「詳細分析」ページで広範囲をスキップできるように、一般的なフィルター/グループ化のディメンション（例: 日付、顧客、地域）を反映するLiquidクラスタリング列を選択します。

結果: 脆弱なインデックスや手動チューニングを行わなくても、アクセスするファイルが減り、スキップするブロックが増え、同じ知見を得るための実時間が短縮されます。

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

• https://www.databricks.com/blog/faster-lakeview-dashboards-materialized-views
• https://docs.databricks.com/aws/en/compute/photon
• https://docs.databricks.com/aws/en/delta/data-skipping
• https://docs.databricks.com/aws/en/delta/optimize 

最適化 #9：メトリクスビューのマテリアライゼーションを活用する

最適化#7: データモデリングのベストプラクティスを適用するでは、明確に定義されたファクト、ディメンション、KPIを持つスター スキーマの重要性に焦点を当てました。メトリックビューは、Databricks AI/BIにおけるこれらの原則を直接的に継承したものです。

メトリクスビューはBIセマンティクスを中心に設計されており、メジャーとディメンションで構成されているため、KPIをモデリングするための自然な抽象化となります。これにより、チームはビジネスメトリクスを一度定義するだけで、複数のダッシュボード、エージェント、その他のクライアントツールで同じKPIを一貫して再利用できます。これにより重複が削減され、KPI driftが防止され、導入が進むにつれて分析ロジックの整合性が保たれます。

Materilization for Metric Views により、Databricks は頻繁に使用される集計を自動的に事前計算し、維持します。これらの集計は増分的に更新され、クエリー実行時にオプティマイザがダッシュボードのクエリーを透過的に書き換え、最も一致する事前計算済みの結果を使用するようにします。その結果、ダッシュボードのクエリーはインタラクションごとにスキャンするデータ量が大幅に少なくなり、チームが個別の集計テーブルやカスタム パイプラインを管理する必要がなくなります。

Metric Views を使用しない場合は、マテリアライズド ビューで同様のアプローチを適用できます。例えば、大規模なファクト テーブルの集計バージョンを事前に計算して保存することで、ダッシュボードでは、はるかに小さく最適化されたデータセットに対してクエリーを実行できるようになります。これにより、スキャンされるデータ量が削減され、ユーザーのインタラクションごとにコストのかかる集計を繰り返し再計算する必要がなくなるため、パフォーマンスが大幅に向上します。

これらのテクニックはすべて、同じこと、すなわちスキャンするデータ量を減らすことを最適化します。KPIを一度定義し、メトリックビューまたはマテリアライズドビューで頻繁に使用される集計を事前計算することで、ダッシュボードは大規模なファクトテーブルの繰り返し集計を回避できます。スキャンされるバイト数が少ないことは、クエリーの高速化、より予測可能なレイテンシー、大規模な運用におけるパフォーマンスの向上に直接つながります。

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

• https://docs.databricks.com/aws/en/metric-views/materialization

最適化 #10: データ型の最適化

データ型は、各ダッシュボードクエリーに対してDatabricks SQLが読み取り、移動、処理する必要があるデータ量に直接影響します。完璧なSQLとキャッシングがあっても、非効率なデータ型は気付かないうちにIO、メモリ負荷、CPUコストを増加させ、タイルの表示速度の低下やコンカレンシーの減少として現れます。

内部では、Databricks SQLはカラムナーParquetファイル上で動作します。より小さく、適切に選択されたデータ型は、次のことを意味します:

• ストレージからスキャンされるデータ量の削減 (より狭い列)、
• キャッシュ密度の向上 (より多くの値がメモリと結果キャッシュに収まる)、
• Photonでの高速なベクトル化実行(SIMDフレンドリーなレイアウト)、
• 最小/最大統計がより厳密であるため、データスキッピングがより効果的になります。

いくつかの仕組みが最も重要です:

• 可能な限り、識別子には文字列の代わりにINT / BIGINTを使用してください。文字列はスキャン、比較、キャッシュにコストがかかりますが、数値キーは桁違いに低コストです。
• 文字列ベースの日付よりも、DATE 型または TIMESTAMP 型を優先的に使用します。ネイティブの時間型を使用すると、述語プッシュダウン、効率的な比較、より効果的なプルーニングが可能になります。
• 適合する最小の数値型 (INT と BIGINT、FLOAT と DOUBLE など) を使用して、列幅とメモリフットプリントを削減してください。
• 必要な場合を除き、BI向けのテーブルで過剰な精度のDECIMALを使いすぎないようにしてください。高精度の10進数は集計中のCPUコストを増加させます。
• スキーマをクリーンで安定した状態に保ちます。暗黙的なキャスト（例：クエリー時のSTRING → INT）は最適化を無効にし、実行ごとに不要なコンピュートを追加します。

BI ワークロードでは、これらの選択が急速に積み重なります。ダッシュボード ページでは、それぞれが数百万行をスキャンする数十のクエリーが実行されることがあります。列幅を狭くして適切な型を定義すると、スキャン時間が短縮され、キャッシュヒット率が向上し、Photon が最高の効率で動作できるようになります。

経験則：スキーマ設計をパフォーマンス機能として扱う。Lakehouseでデータ型を一度最適化すれば、現在および将来のすべてのダッシュボードが自動的にその恩恵を受けます。

まとめ

10のベストプラクティスすべてに共通するテーマはシンプルです。ダッシュボードのインタラクションごとに毎回全コストを支払うのをやめることです。システムがビューごとに行う作業を減らし（ファンアウトの削減、スキャンされるデータの削減）、実行する作業を再利用可能にします（共有データセット、決定論的クエリー、キャッシュ、事前計算された集計）。これらの要素が揃うと、同時実行下でパフォーマンスが安定し、コストが予測可能になります。

具体的なアクションとして、最もよく使用するダッシュボードについて、これらの質問に「はい」と答えられる必要があります:

• ユーザーは高速な初回描画 (軽量なランディングビューと適切なデフォルト) を体験できていますか？
• 一般的なインタラクションは、少数の低コストなクエリー（スキャン後ではなく、早い段階でパラメータがフィルタリングする）をトリガーしますか？
• 繰り返し表示はキャッシュヒットになっていますか（決定論的なタイル、タイル間の再利用、スケジュールされたウォームアップ）？
• warehouseは、ピーク時の負荷をキューイングやspillingなしで吸収できるか（Peak Queued クエリーがほぼゼロに留まり、クエリー Profileがspillしないか）。
• レイクハウスは読み取りに最適化されていますか（健全なファイルサイズ、リキッドクラスタリング、クリーンなデータ型、事前計算されたホットな集計）？

実際に導入されているダッシュボードを 1 つ選び、簡単なベースライン (初回描画、インタラクション レイテンシー、キュー登録されたピーククエリー数、spill、キャッシュ ヒット率) を実行し、最も効果的な変更をいくつか適用して、再測定します。これを継続的に行うことで、データとユーザーが増加するにつれて、AI/BI は「時々速い」状態から確実に速い状態へと移行します。

参考資料

• SQL ウェアハウスのサイジング、スケーリング、キューイング、モニタリング、Serverless IWM と Pro/Classic オートスケールの比較。https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior
• ウェアハウスの作成/設定、コンカレンシーごとのクラスター数に関するガイダンス。
  https://docs.databricks.com/aws/en/compute/sql-warehouse/create
• サーバーレスの利点とそれが推奨される理由。
  https://docs.databricks.com/aws/en/compute/sql-warehouse/
• Warehouseのタイプとパフォーマンス機能（Photon、Predictive IO、IWM、Serverlessのstartup 2～6秒）。
  https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types
• 結果のキャッシュ (クラスターごと、および Serverless リモート結果キャッシュ)。
  https://docs.databricks.com/aws/en/lakehouse-architecture/performance-efficiency/best-practices https://learn.microsoft.com/ja-jp/azure/databricks/sql/user/queries/query-caching
• AI/BI ダッシュボード：ページ/キャンバス/データモデルとコンポーネント。
  https://docs.databricks.com/aws/en/dashboards
• パラメーターとフィールドフィルター、クエリベースのパラメーター。
  https://docs.databricks.com/aws/en/dashboards/parameters
• 負荷の高いワークロードを高速化するために、ダッシュボード データセットをマテリアライズドビューにエクスポートします。
  https://docs.databricks.com/aws/en/ai-bi/release-notes/2025
• 監査logsのダッシュボードクエリー実行（ロード時に実行される内容を確認）。
  https://docs.databricks.com/aws/en/admin/account-settings/audit-logs

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