Power BI の DirectQuery レポートがクリックのたびに重くありませんか？

DirectQuery は文字通り、ユーザーのあらゆる操作をデータベースへの即時 SQL クエリに変換します。それが高速に動くかどうかは、裏側にあるデータ構造によって完全に決まります。

DirectQuery が生成するクエリの実態

• スタースキーマに対して実行される場合： 1 つのファクトテーブルと、確定したキーで結合された数個のディメンションテーブル。データベースはミリ秒単位で結果を返します。
• 第 3 正規形（3NF）や生のレイクテーブルに対して実行される場合： 10 個以上のテーブルにまたがる複雑なネスト結合が発生し、ビジュアルごと、クリックごとに毎回ゼロから SQL が組み立てられます。
• プッシュダウンが効かない構造： パーティションや適切なインデックスが存在しないテーブルでは、毎回フルスキャンが走ります。
• 静かなフォールバック： Direct Lake は、ソースデータの形式が要件に満たない場合、何のエラーも出さずに静かに DirectQuery へフォールバックします。このとき予期せぬコンピュートコストが発生します。

これにページ上のビジュアル数、そして同時アクセスするユーザー数を掛け算してみてください。それが膨れ上がった請求書の正体です。

なぜその負担がアナリストに押し付けられるのか

• ウェアハウスが提供しているのは基幹システムの運用テーブルのコピーであり、分析用に最適化されたテーブルではありません。
• インポートモードへの変更は一時しのぎに過ぎず、DirectQuery を選んだ最大の理由である「リアルタイムデータ」を失うことになります。
• ビジュアルの配置や表示件数は調整できても、アナリスト権限では基盤側のパーティション再構成はできません。

本来その処理が行われるべき場所

• 分析用にテーブル構造を整えるのはウェアハウスの責務： DirectQuery はスキーマを最適化できません。クリックのたびに支払っている遅延とコストは、適切なモデリングを怠ったツケです。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけスタースキーマを整備し、すべてのレポートが高速に参照できるようにすべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

完成したモデルが届いたときに変わること

Datavault Builder は、ターゲットプラットフォーム（Snowflake、Databricks、Fabric、Synapse など）上でネイティブに動作するディメンショナルモデル（実テーブルまたは最適化ビュー）を自動生成します。トランザクション用ではなく、分析クエリのプッシュダウンに最適化された構造です。

• 1 つのファクトと明確なディメンション： 生成される SQL は構造上シンプルで極めて短くなります。
• 最適なパーティションとクラスタリング： ユーザーが実際にフィルターやスライサーで絞り込む列に基づいて最適化されます。
• Direct Lake が確実に維持される： テーブルが最初から Direct Lake の要求する形状で生成されるため、DirectQuery へのフォールバックが防がれます。
• コンピュートコストが激減： 各クリックが生レイヤーではなく軽量で最適化されたモデルをスキャンするため、クラウドコストが大幅に抑制されます。
• リアルタイム性と処理速度のトレードオフが解消されます。

上流チームに何を要求すべきか

「DirectQuery がクリックごとに正規化テーブル群を複雑に結合しているため、ユーザーが増えるほどコンピュートコストが跳ね上がっています。このレポート用に、パーティション分割されたスタースキーマをウェアハウス側で提供してもらえませんか？」

このように具体的に要望を伝えることで、問題の根本原因があるレイヤーに対して正確な改修を依頼できます。