Zenn
📑

Tableauのパフォーマンス改善のチェックポイント

2022/04/17に公開
パフォーマンス
Tableau
改善
チューニング
チェックリスト
tech

Tableauで開発するにあたり、パフォーマンスを意識したデータソース設計やTableauの開発を行う必要があります。私がパフォーマンスの点において意識すべき事項をリストアップします。

基本事項

  • 必要最低限のデータを「抽出」する。
  • 計算フィールドを多用しない。
  • Tableauの標準機能を理解して、活用する。
  • フィルターの使用には注意を払い、多用しない。
  • クエリパイプラインを理解する。
  • 遅いダッシュボードは使われないことを心に留めておく。

パフォーマンス留意事項

データソース設計

データ型

  • 小さいデータ型を使用する。
    （真偽型 > 整数型 > 小数型 > 日付型 > 日付時刻型 > 文字列型 ）
  • フィルターに使う計算フィールドはIF文を使わず真偽型を返すようにしてフィルターでTRUE/FALSEの値をフィルター項目として利用できないかを検討する。
  • 小数を含む演算（掛け算）は内部的にキャストが発生するのでパフォーマンスが悪くなるので避ける。

ネイティブ機能の活用

  • 項目のグルーピングは、計算フィールドを使わず「グループ」機能を利用する。
  • 項目の結合は、計算フィールドで結合せずに、「結合済みフィールド」機能を利用する。
  • 計算フィールドを使わず、プレフィックスやサフィックスなど書式設定を活用する。

計算フィールド

  • 計算フィールドを使わず事前にDBで計算できないかを検討する。
  • 計算フィールド内での計算フィールドの参照を避ける。
    パフォーマンスを優先するならば、1つの計算フィールドにまとめることも検討すべき。
  • 計算を簡略化できないかを検討
    表計算などを利用する場合に、生成された数式を確認して簡略化できないかを検討する。
  • 計算フィールドでのセットやグループの使用を避ける
    CASE WHEN なので代用する

条件分岐

  • ELSE IF より ELSEIFを利用
    Tableauの作り上、 ELSEIFは分割せずに1フレーズで利用した方が速い
  • CASE WHEN で代用できる場合はこちらを利用（IFのネストは避ける）
    特に計算フィールドを使っている場合は、IF文では複数回計算フィールドを参照されるところを、CASE文で1回にすることが可能な場合あり
  • IFをネストする場合は、データから判定回数が減るように順番を検討する。
    判定回数が減るように、データセットを確認しながらIF文のネストの順番は検討した方がよい。

関数

  • 日付の場合、NOW()よりTODAY()を使う
    NOW()は時間まで取得するので、日付のみを利用する場合は、TODAY()の方がよい。

  • 集計関数 MIN, MAX, SUMは速い。 AVGは遅い。COUNTDはさらに遅い。
    ATTRは、MINかMAXで代用する。その他の集計関数の使用は多用しない。

  • 文字列関数（LEFT,MID,RIGHT）もパフォーマンスが悪いので、使用回数を少なくする。

LOD表現

  • LODも遅いので、使用箇所は要検討
    LOD関数によりデータセットを何度も集計することになるので、使いどころは要検討。一方で、LOD関数を利用することでデータセット自体を小さくすることができる場合もあるので、全体としてパフォーマンスが向上することもある。

  • LODよりも表計算を利用する
    LODよりも表計算の方が速いことがある。細かいチューニングをする場合は、パフォーマンスをモニタリングして、どちらの実装が速いかを検討すべき。

  • EXCLUDEよりINCLUDEの方がパフォーマンスがよい。

形状

  • 形状にカスタムシェイプの使用を避ける
  • カスタムシェイプの画像は大きいサイズにしない

フィルター

  • 除外フィルターはパフォーマンスが悪い
    連続の範囲指定フィルターで代用できないかを検討

  • 不連続の項目より連続項目のフィルターの方が速い
    リスト選択型のフィルターより範囲指定のフィルターの方が速い

  • フィルターの適用範囲は必要最低限にする
    むやみにフィルター項目を追加しない。

  • ユーザフィルターはキャッシュが効きにくいので使用を避ける
    ユーザフィルターはデータ量も増えやすいので、利用する場合は注して設計を行う必要があある

  • 範囲指定のクイックフィルターの方がパフォーマンスがよい
    不連続の項目のリストから連続の範囲フィルターにできないかを検討する

  • データソースフィルターは使用しない
    データソースフィルターでフィルタリングするより、SQLの段階でフィルタリングする方がパフォーマンスがよい

コンテキストフィルター

  • コンテキストフィルターは設定する場合も1シート1フィルター
    コンテキストフィルターを設定すればパフォーマンスが必ず良くなるわけではなく悪化する場合も多い。1つのみ設定して、前後で体感レベルで向上しているかを確認する
  • FIXEDのフィルターとしてのコンテキストフィルターを利用することは有効
  • 関連値の代わりとしてのコンテキストフィルターを利用することもあり

クイックフィルター

  • 関連値のみの使用もパフォーマンスが悪い
    関連値はフィルターを変更する度にクエリが発行されるので、使用は最低限にする
  • クイックフィルターの数は少なくする
    多数のクイックフィルターがどうしても必要な場合は、フィルター用のダッシュボードにすることも検討する。
  • 項目数の多いクイックフィルターは避ける
    項目数の多いフィルターは表示に時間がかかる。ワークシートをフィルターとして使うような多段階の絞込み方法などの代用も検討すべき
  • フィルターが重い場合は、「適用ボタン」の利用も検討する。
    操作性は悪くなるので、安易には採用しないでその他のチューニング方法をまずは検討する。
  • アクションフィルターの多用は避ける。

ダッシュボード・シート

  • 表示モードは固定にする
    キャッシュが効きやすくなる。自動調整のレイアウトの場合はフィルター項目が同じでも画面サイズが異なるとキャッシュが効かない。
  • 使用していないシートはダッシュボードから削除する
    使用していなくても計算処理が走るので、ダッシュボードから削除する。
  • シートの数を増やすと遅くなるので要注意
    1ダッシュボード 3,4シートが目安。
  • 集計表は大きくなると遅くなるので注意
    Tableauで巨大な集計表の表示には時間がかかる。上位〇〇件といったフィルターをかけられないかという仕様の検討をすべき
  • シートのマーク数は確認
    数が多いと遅くなるので注意。各シートの左下のマークの数値を確認して、無駄なものがないかをチェックする
  • 1ワークブックに含まれるダッシュボード数が増えると初期表示が重くなる
    場合によってはワークブックを分けることを検討すべき。
  • タイルで配置するか、浮動で配置するかはパフォーマンスに大きな違いはない。

今後も留意する項目が増えた際にはアップデートしていきます。

◆他のTableau関連の記事はこちら

Discussion