Qlik のセット分析（Set Analysis）式が長すぎて重くなっていませんか？

セット分析（Set Analysis）は、今年と去年の比較など、正当なビジネス上の比較集計を行うための最適なツールです。しかし同時に、データモデルに欠落している要素を画面側で無理やり穴埋めするパッチとしても使われがちです。そしてアプリの動作を極端に重くしているのは、まさにこの後者の使われ方です。

長大なセット分析式が何を肩代わりしてしまっているのか

• 履歴データの復元： 日付修飾子と Aggr 関数を駆使して、「去年の 3 月時点」のレコード状態を数式の中でゼロから再構成している。
• フラグ判定のオンデマンド計算： 数式内の If() 条件が、「何がアクティブで何が有効か」を計算のたびに毎回判定している。
• 粒度の狂いの補正： 1 つのテーブル内に 2 つの粒度が混在しているため、Aggr や Only を使って重複を無理やり打ち消している。
• 欠落したリレーションシップの代用： {<Year={2024}>} や P() などのネストされた修飾子が、本来あるべきディメンションの役割を無理やり肩代わりしている。

これらはすべて、ユーザーが選択を行うたび、チャートごと、ユーザーごとに毎回評価されます。これが、画面がスピナーで固まる原因です。

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

• どの数式も、その週の締め切りまでに正しい数字を出すための最速の方法でした。
• そのロジックは .qvf ファイルの奥深くに埋もれており、アプリの外部からはレビューも再利用もできません。
• アナリストは数式を短く整理することはできても、データモデルが保持していない履歴を後から追加することはできません。

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

• 履歴管理、フラグ、粒度の確定はウェアハウスの責務： セット分析の中でこれらを処理すると、選択操作を行うたびにゼロから再計算されます。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ解決し、すべてのアプリが最適化されたテーブルを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

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

Datavault Builder は、SQL Server、Azure SQL、Oracle、Snowflake、Databricks など、既存のデータベース上でデータボルトおよびスタースキーマをネイティブに自動生成します。

• サテライトによる履歴保持： ポイントインタイム（PIT）テーブルにより、「3 月時点の数値」といった過去時点の問い合わせを数式ではなくテーブル結合で瞬時に返します。
• フラグが明示的な列として提供される： ウェアハウス側で 1 度だけ計算され、複雑な If() 式が不要になります。
• ファクトテーブルごとの単一の粒度： データの二重計上が原理的になくなり、Aggr による辻褄合わせが完全に排除されます。
• 適合ディメンション： セット修飾子が直接選択できる正規のフィールドが提供されます。
• 残るセット分析は純粋な比較計算のみとなり、同僚がひと目で理解できるほど短く高速になります。

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

単に「ダッシュボードが重い」と伝えるのではなく、以下のように依頼してください：

「現在のセット分析は、特定時点の状態の復元やステータスフラグの判定を選択のたびに再計算しているため、パフォーマンスが低下しています。数式を単純な集計で済ませられるよう、ウェアハウス側で PIT テーブルとフラグ列を用意してもらえませんか？」

このように要請することで、本来必要だったセット分析と、データ構造の不備を補うために使っていたセット分析を切り分け、根本的な解決を図ることができます。