ダッシュボードパフォーマンスを考えるうえで1つのポイントとなってくる計算フィールド周りの最適化について自身の勉強もかねて記事にしてみました
ダッシュボードのパフォーマンス確認方法は以下を参考にしてください
https://help.tableau.com/current/pro/desktop/ja-jp/perf_record_create_desktop.htm
パフォーマンス改善の際に気を付けるべき点
①ネストされた計算を減らす
より複雑な集計などを実現しようとして入れ子が増えすぎてしまうケース。FIXED計算や集計関数とIF文などを組み合わさっていることがよくある
クエリパイプラインを意識してなるべく全体の計算量が少なくなるように分解するとよい
🚫 悪い例：
{FIXED [Category]:SUM({FIXED [Product]: SUM([Sales])})}
✅ 改善例：
{FIXED [Category],[Product]: SUM([Sales])}
Point!
- 不必要なネストを避ける
- シンプルな計算を心がける
- 同じ結果が得られるなら、よりシンプルな方法を選ぶ
②複雑な文字列操作を行わない
不要な文字の削除やデータの表記形式をそろえるために様々な文字列操作を実施しているパターン
そもそも文字列関数全般はパフォーマンスが悪いため、基本的にはデータソース側で対応するのがよい
🚫 悪い例：
LEFT(RIGHT(REPLACE([Full Name], " ", "|"),FIND([Full Name], " ")),LEN([Full Name]))
✅ 良い例：
REGEXP_EXTRACT([Full Name], '[^ ]+ ([^ ]+)', 1)
Point!
- 正規表現を活用する
- データインタプリターやタブの[変換]>[分割]などデフォルトで備わっている機能を活用
- データソース側で事前に処理できないか検討する
③LOD式の使い所に注意する
LOD式（Level of Detail式）は便利だが、使い方次第でパフォーマンスに大きく影響するので表計算機能とうまく使い分ける
チューニング時にはいくつかの実装方法に対してパフォーマンスモニタリングを実施したうえで、どちらの実装が速いかを検討する必要がある
使い分けのポイント：
表計算を使うべき場合：
- ランキング計算
- 移動平均の計算
- 合計に対する割合の計算
LOD式を使うべき場合：
- クロス集計が必要な場合
- フィルターの影響を除外したい場合
- 異なる粒度の計算が必要な場合
④関数レベルでのパフォーマンスに気を付ける
-
NOW関数よりTODAY関数のほうが早い
NOW関数は時間まで必要な際に、日付まででよい場合はTODAY関数を使うとよい - 集計関数では
MIN関数&MAX関数>SUM関数>AVG関数>COUNTD関数の順で速度が速い（左のほうが早い） -
IF関数のネスト構造は避けCASE関数で代用できる場合はこちらを利用する -
ELSE IFよりELSEIFと記載する（空白を開けない）
あとがき
データソース側でのフィルタリングやクレンジングを実施することが効果的なケースも多いですが、上記のような部分についても意識してダッシュボード作成をすることでより高いパフォーマンスを発揮できるので覚えておこうと思います。