Tableau ダッシュボードのフィルターを切り替えるたびに待たされていませんか？

ボトルネックになっているのは Tableau ではありません。VizQL はユーザーのあらゆる操作を SQL クエリに変換します。その応答にかかる時間は、クエリ先のテーブルの構造によって完全に左右されます。

VizQL が裏で要求されていること

• スタースキーマに対して実行される場合： 1 つのファクトテーブルと、明確な主キーで結合された数個のディメンションテーブル。ミリ秒単位で結果が返ってきます。
• 第 3 正規形（3NF）や生テーブルに対して実行される場合： 10 個以上のテーブルにまたがる複雑な結合が発生し、マークごと、フィルターごと、ユーザーごとに毎回ゼロから SQL が再構築されます。
• インデックスが効かない： 基幹系のテーブルはトランザクション用にインデックスが貼られており、アナリストが集計に使うグループ化列には最適化されていません。
• ワークシート単位で掛け算される： ダッシュボード上の各ワークシートがそれぞれ独立してクエリを発行するため、負荷が倍増します。

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

• 与えられたデータソースは「たまたま社内に存在した運用テーブル」であり、分析用途に設計されたものではありませんでした。
• カスタム SQL やデータブレンドを駆使して何とか繋ぎ止めてきましたが、それによって発行されるクエリはさらに重くなっています。
• ワークブック側の計算式やレイアウトをチューニングすることはできても、アナリスト権限でソース側のモデリングを変更することはできません。

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

• 生テーブルを分析可能な構造に結合・整理するのはウェアハウスの責務： VizQL 内でそれをやらせると、フィルターを変更するたびにその重い結合処理が繰り返されます。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけスタースキーマを構築し、すべてのワークブックが最適化されたテーブルを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

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

Datavault Builder は、Snowflake、Databricks、BigQuery、Synapse、SQL Server、Oracle、Exasol、PostgreSQL 上で、分析アクセスに最適化されたファクトおよびディメンションをネイティブに自動生成します。

• 1 つのファクトテーブルと適合ディメンション： VizQL が発行する SQL は構造上非常に短くシンプルになります。
• 明示的な単一キー結合： 複数列の文字列マッチングではなく、高速な単一カラムキーで結合されます。
• テーブルごとの単一の粒度： スキャン行数を不必要に膨らませる重複行が原理的に排除されます。
• ライブ接続が実用的に： 抽出（Extract）への逃げ道を探す必要がなくなり、必要に応じてライブ接続を快適に利用できます。
• フィルターが瞬時に反応するようになり、隠していたフィルターを再びダッシュボードに戻すことができます。

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

「フィルターをクリックするたびに VizQL が複数の正規化テーブルを複雑に結合しており、データ量の増加に伴ってクエリ時間が深刻化しています。運用テーブルを直接叩くのではなく、このダッシュボード専用のスタースキーマをウェアハウス側で提供してもらえませんか？」

このように具体的なメカニズムを指摘することで、ボトルネックの根本原因が存在するレイヤーでの改修を促すことができます。