BIサービス提供のポイント：パフォーマンスとTCOを最大化する

BIダッシュボードの動作が遅く、チューニングに時間とコストがかかりすぎていませんか？

これはよくあるパターンです。ダッシュボードのクエリに30秒かかるため、誰かが集計テーブルを作成して高速化します。そのテーブルには更新パイプラインが必要です。パイプラインには監視が必要です。次に、2番目のBIツールがわずかに異なる形式で同じデータを必要とするため、誰かが別のパイプラインを使用して別の集計テーブルを作成します。やがて、集計、抽出、ツール固有のセマンティックレイヤーが乱立し、それぞれが独自の鮮度ウィンドウ、独自のガバナンスギャップ、そしてコンピューティング費用に独自の項目を持つことになります。

BIワークロードは、他の分析ワークロードとは異なります。これらは高い並行性、低レイテンシー、反復的なクエリパターンを特徴とします。この組み合わせには、データのモデリング、保存、最適化、提供に対する意図的なアプローチが求められます。朗報です。Databricksは、物理データレイアウトからガバナンスされたセマンティックレイヤーまで、BI提供のためのフルスタックを提供し、各レイヤーがその下のレイヤーのパフォーマンス向上を増幅させます。

この投稿では、クエリパフォーマンスとコストを最大化するための実用的なガイダンスとともに、そのスタックをボトムアップで解説します。

BI提供スタック

各レイヤーについて詳しく説明する前に、全体像をご覧ください。

Unity Catalogは、生データからセマンティクス、消費に至るまで、リネージとアクセス制御を通じて全体的なガバナンスを提供します。各レイヤーは、パフォーマンスとコストの異なる側面に対応しています。それぞれについて見ていきましょう。

物理レイヤーの最適化

物理レイヤーは、BIパフォーマンスの大部分が決まる場所です。ここを適切に設定すれば、セマンティックレイヤーに触れる前に、すべてのクエリが恩恵を受けます。

ディメンショナルモデリングから始める

スター型スキーマは、BIクエリパフォーマンスのゴールドスタンダードであり続けています。サロゲートキーを介してファクトテーブルに結合された幅広の非正規化ディメンションテーブルは、クエリオプティマイザーにクリーンで予測可能な結合パスを提供します。

Databricksは、必要なリレーショナルモデリングの構成要素を完全にサポートしています。これには、主キーと外部キーの制約（オプティマイザーヒントのためのRELYを含む）、サロゲートキー用のID列、およびCHECKとNOT NULL制約が含まれます。メダリオンアーキテクチャに従う場合、正規化されたモデルまたはData VaultモデルはSilver層に保持し、BI消費のためにGold層に非正規化されたスター型スキーマを構築します。

詳細な実装パターン（SCD Type-1およびType-2の処理、MERGEを使用したファクトテーブルETL、遅延到着ディメンションなど）については、「Databricks SQLでのディメンショナルデータウェアハウスの実装」ブログシリーズをご覧ください。

マネージドテーブルの使用

Unity Catalogのマネージドテーブルは、このスタックの他のすべての基盤となります。Unity Catalogは、マネージドテーブルのすべての読み取り、書き込み、ストレージ、および最適化の責任を管理します。これにより、外部テーブルでは得られない自動機能が利用可能になります。Predictive Optimization（後述）はデフォルトで有効になっています。自動リキッドクラスタリングは、クエリパターンが変化するにつれて適応するクラスタリングキーを選択します。メタデータキャッシュは常にオンであり、クラウドストレージへのリクエストを減らし、クエリ計画を高速化します。

BI提供だけでなく、Bronze、Silver、Goldの各レイヤー全体でマネージドテーブルを使用してください。これらはUnity Catalogのデフォルトのテーブルタイプであり、このスタックの他のすべての最適化と相まって、パフォーマンスとガバナンスのメリットが増大します。

リキッドクラスタリングの適用

リキッドクラスタリングは、静的パーティショニングと手動のZ-ORDERに代わるもので、これらのアプローチとは異なり、既存のデータを書き換えることなくクラスタリングキーを再定義できます。テーブル作成時にCLUSTER BY (col1, col2)を追加するか、既存のテーブルでALTER TABLEを使用します。どの列を選択すべきかわからない場合は、CLUSTER BY AUTOを使用すると、Predictive Optimizationが観測されたクエリパターンに基づいてキーを選択します。

BIワークロードの場合、最も一般的なフィルター列と結合列（日付キー、地域、製品カテゴリなど）でクラスタリングします。最大4つの列を選択でき、2つの列が高度に相関している場合は、1つだけ含めます。ダッシュボードがクラスタ列でフィルターをかけると、リキッドクラスタリングはデータスキッピングを通じてクエリパフォーマンスを向上させます。

残りはPredictive Optimizationに任せる

Predictive Optimizationは、これらの操作から恩恵を受けるテーブルに対して、OPTIMIZE、VACUUM、および統計収集を自動的に実行するため、これらのジョブを自分でスケジュールする必要はありません。Photon書き込み中にDeltaデータスキッピング統計とクエリオプティマイザー統計の両方を収集し、既存のテーブルの統計をバックフィルします。観測されたワークロードでは、これにより平均22%のパフォーマンス向上が実現しました。反復的なフィルターパターンを持つBIワークロードの場合、その影響は特に顕著です。より良い統計は、より良いデータスキッピングとより効率的なクエリ計画を意味します。

カタログレベルでPredictive Optimizationを有効にし、実行させます。Predictive Optimizationの使用は、最も高いリターンと最も低い労力で実現できる最適化の1つです。

結果: BIクエリはスキャンするデータが少なくなり、より効率的に結合され、実行コストが削減されます。しかも、まだセマンティックレイヤーには触れていません。

メトリックビュー: メトリックを一度定義する

ここからが興味深い点です。ほとんどの組織では、同じビジネスメトリックが複数の場所で定義されています。あるBIツールでは収益計算、別のツールではわずかに異なる計算、そして前四半期に誰かが書いたSQLノートブックには3番目のバリアントが存在します。それぞれの定義は独立して変化し、どれが正しいのか誰も確信が持てません。

Unity Catalogのメトリックビューは、ヘッドレスBIレイヤーを提供することでこの問題を解決します。これは、特定のBIツールに依存せず、データモデルとKPIを一度だけ定義できる単一のガバナンスされたセマンティックレイヤーです。これらはSQLまたはUnity Catalog ExplorerのポイントアンドクリックUIで一元的に定義します。AI/BIダッシュボード、Genie、SQLノートブック、およびサードパーティのBIツールはすべて、同じ定義からメトリックを解決します。メトリックを一度定義すれば、人間であろうとAIであろうと、すべてのコンシューマーが同じ答えを得られます。

メトリックビューは、一元化されたメトリック定義を超え、セマンティックメタデータがその特徴です。display_name、comment、synonymsのようなフィールドは、AIシステムがビジネス上の質問を正しく解釈するために必要なコンテキストを提供します。ユーザーがGenieに「先週の収益はいくらでしたか？」と尋ねたとき、これらのアノテーションがGenieが自然言語を適切なメジャーとディメンションにマッピングする方法です。カスタムプロンプトも、個別の用語集も必要ありません。Databricks上に構築されたAIエージェントにも同じことが当てはまります。Unity Catalogにアクセスできるエージェントは、ハードコードされたSQLではなく、セマンティックレイヤーを通じてガバナンスされたメトリックを発見し、クエリを実行できます。メタデータが豊富であればあるほど、AIはより正確な答えを提供します。

Databricksのすべてのお客様がアクセスできるシステムテーブルを使用した例を次に示します。ただし、収益、注文量、顧客維持率などのビジネスKPIにも同じパターンが適用されます。このメトリックビューはDBSQLウェアハウスのメトリックを計算します。

コンシューマーは、MEASURE()を使用してメトリックビューをクエリし、ガバナンスされたメトリック定義を参照します。

メトリックはメトリックビューで一度定義されます。metv_dbsql_metricsをクエリするすべてのダッシュボード、Genieスペース、またはノートブックは同じ結果を得ます。以下は、メトリックビューをソースとして使用するダッシュボードです。

Genieが同じメトリックビューを使用している例です。

複数のBIツールにメトリック定義が散在しているチームにとって、メトリックビューはセマンティックレイヤーをDatabricksに統合する道筋を提供します。各ツールで個別のメトリックロジックを維持する代わりに、Unity Catalogで一度定義し、BIツールをその管理されたソースに接続できます。

コア実装はApache Spark™ (SPARK-54119)でオープンソース化されており、Unity CatalogのOSSサポートも予定されています。これにより、ベンダーロックインのないオープンスタンダードに基づいて構築できます。AIがBIワークロードの多くを担うようになるにつれて、このオープン性はより重要になります。データをクエリするエージェントは、各メトリックが何を意味するのかについて、一貫性のある機械可読な定義を必要とします。オープンスタンダードにより、ベンダー固有のツールだけでなく、あらゆるツールやエージェントが同じ管理されたメトリックに基づいて推論できるようになります。

メトリックビューの具体化：オーバーヘッドなしでOLAPパフォーマンスを実現

従来、BIダッシュボードの動作が遅すぎる場合、集計テーブルを構築するのが解決策でした。スター スキーマの上にマテリアライズドビューまたはカスタム事前集計テーブルを作成し、更新パイプラインを設定し、BIツールを新しいテーブルに再接続していました。これは機能しましたが、維持すべきオブジェクトとパイプラインの層全体が増え、集計ロジックが変更されるたびに、BIツールのクエリを一致するように更新する必要がありました。

メトリックビューの具体化は、よりシンプルな代替手段を提供します。メトリックビューで具体化を有効にすると、プラットフォームはBIツールがすでにクエリしているのと同じメトリック定義の背後で、事前集計された結果を自動的に維持します。個別の集計テーブルを構築したり、BIツールのクエリをリファクタリングしたりする必要はありません。内部では次のことが行われます。

• 自動事前集計: メトリックの結果が事前に計算され、保存されます
• 増分更新: 完全な再計算なしでメトリックが最新の状態に保たれます
• インテリジェントなクエリ書き換え: エンジンはクエリを最適な具体化にルーティングします
• 透過的なルーティング: ユーザーは同じ方法でメトリックをクエリし、システムは最速のパスを提供します

以前は完全なファクトテーブルをスキャンしていたダッシュボードクエリは、事前集計された具体化にヒットするようになり、レイテンシとコンピューティングコストが削減されます。上記のダッシュボードとGenieの例はどちらも同じメトリックビューをクエリしており、両方のクエリは透過的に具体化にルーティングされました。Genieからの以下のクエリプランは、これが実際に機能していることを示しています。

実用的なTCOのヒント

クエリの高速化とコスト削減は相反する目標ではありません。スキャンされるデータを削減するすべての最適化は、支払うコンピューティング費用も削減します。そして、スタック内の各最適化は複合的に作用します。Liquid clusteringとより良い統計は、データスキッピングとクエリプランを改善します。具体化は増分的に更新できるため、SQLウェアハウスがダッシュボードを提供するために必要なコンピューティングを削減します。コストを削減するためのその他の方法をいくつか紹介します。

• SQLウェアハウスを適切なサイズに調整します。 BIの同時実行バーストには、自動スケーリングを備えたサーバーレスSQLウェアハウスを使用します。ピーク容量ではなく、使用した分だけ支払います。
• DBSQLのキャッシュ層を活用します。 ディスクキャッシュはホットデータをウェアハウスのローカルに保持し、クエリ結果キャッシュ (QRC) は再実行なしで繰り返しのクエリを提供します。一貫したクエリパターンを持つダッシュボードの場合、キャッシュにより多くのリクエストがミリ秒単位のレイテンシで、ほぼゼロのコンピューティングコストで応答されます。
• 冗長なデータ移動を排除します。 抽出やインポートを使用するのではなく、DirectQueryまたはライブ接続を介してレイクハウスからBIを直接提供します。
• システムテーブルで監視します。 system.billing.usage や system.query.history などのシステムテーブルを使用して、ダッシュボード、ユーザー、ウェアハウスごとのBI使用状況を追跡できます。システムテーブル上にメトリックビューとAI/BIダッシュボードを構築して、BI使用状況を可視化します。

始める

スタック全体を一度に実装する必要はありません。最も効果が見込める場所から始めましょう。

1. 管理テーブル、主キー/外部キー、およびLiquid clusteringを使用して、ゴールド層のスター スキーマを構築 (または検証) します
2. カタログで予測最適化を有効にし、OPTIMIZE、VACUUM、および統計収集を自動管理します
3. 主要なビジネスKPIのメトリックビューを定義します — SQLまたはUC Explorer UIから始めます
4. トラフィックが最も多いメトリックのメトリックビューの具体化を有効にします
5. 結果を監視します — ダッシュボードをメトリックビューに向け、システムテーブルを介してクエリパフォーマンスを追跡します

Databricksは、BI提供スタックのあらゆる層で最適化を提供します。管理テーブル、Liquid clustering、および予測最適化により、スキャンされるデータと消費されるコンピューティングが最小限に抑えられます。メトリックビューは、ダッシュボード、Genie、AIエージェントに一貫してサービスを提供する、管理されたセマンティックレイヤーにビジネスロジックを集中させます。具体化は、手動の事前集計パイプラインなしで、1秒未満のクエリパフォーマンスを実現します。これらの層が複合的に作用することで、クエリのレイテンシと総所有コストの両方を削減します。

既存のゴールド層テーブルに最初のメトリックビューを定義し、具体化を有効にすることから始めましょう。開始するには、以下のリソースを参照してください。

• Unity Catalog メトリックビューの概要
• AI/BIにおけるメトリックビューの活用
• SQLエディターからのメトリックビューのクエリ
• Databricks SQLでのディメンショナルデータウェアハウスの実装

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