Tableau パフォーマンスまとめ
DATA SaberでまなんだTableauのパフォーマンス情報を以下にまとめました。
参考にした動画はこちらです。
パフォーマンスの考え方
なぜパフォーマンスが大事なのか？
迅速に答えを見つけることができる
分析のFlowに乗れる
似たようなWBを量産せずに済む
パフォーマンスが悪いWBを渡されると、「自分が作るWBの方が速く見られるんじゃないか、、？」という疑問が生まれ、類似したWBを作ってしまうことがある
Fast workbooks = Happy users
パフォーマンスを決める要素
やりたいこと・知識が適切なものを選び取る力をくれる
やりたいこと
誰が何のためにどのように使う？
誰がどの粒度で、どの頻度で、いつ使うかが分かれば、そこにデータ量の粒度を合わせることができる
まずはこの部分を固めることでパフォーマンス向上につながる
知識
どういう操作が遅くなるか知る
データ量
使うデータはどんなデータ？
全RAWデータ？
集計データ？
フィルタで絞ったデータ？
処理能力
データがどんな環境に入っている？
ハードウェア
DB製品
処理をする場所
DB側での処理
結合（JOIN）
集計
計算
Tableau側での処理
マーク
表計算
ソート
データを集計するパートがDB側、ビューをレンダリングするパートがTableau側で行われている。
※レンダリング：ビューの元々の情報を、形を変えて表現するための処理のこと
パフォーマンスが悪い時は、負荷がかかっている場所を突き止めることが重要（DB側が重いのか？Tableau側が重いのか？）
パフォーマンス向上のベストプラクティス
データが遅ければ、Tableauで速くなることはない
Desktopで遅ければ、Serverで速くなることはない
入れすぎ厳禁
ひとつのWBにデータを詰め込みすぎない
データソース
対象データの件数
レコード数：今の環境で扱える妥当なレコード数になっているか？
対処策：
集計してレコードの行数を減らす
フィルタを使用し、件数を削減（Tableauではディメンションフィルタでは件数が減らないため注意）
抽出フィルタ
データソースフィルタ
リレーショナル・データベース
インデックスとパーティショニングはパフォーマンス向上に有効
インデックス
表の結合キーの列
フィルタで使用される列
パーティショニング
ディメンション項目
NULL
NULLはパフォーマンス低下につながるため、なるべく避ける
ディメンション項目ではNULLを避ける
NULLを無くしてインデックス効果を向上
DB側でテーブルを準備
集計データを事前準備しておく
Tableauで複雑な計算フィールドを回避するために、DB側に必要な値をテーブルに持たせておく
結合 vs ブレンディング
結合
（特殊な事情でなければ）同じデータベースであれば、表の結合が望ましい
インデックスを有効活用
1本のクエリ
ブレンド
集計したもの同士をくっつける
レコード数が多く、表の結合に適さない場合
集計ビュー
結合 vs ブレンディング vsクロスデータベース結合
抽出 vs ライブ接続
抽出・ライブ接続のどちらが速いかはケースバイケース
抽出のパフォーマンスに影響する要因
行数、列数
データ濃度（＝カーディナリティディ。メンションメンバーの数）
計算フィールド
計算
行レベル計算と集計計算
行レベル計算（＝非集計計算）：レコードの行の中だけで完結している計算
ex) 行ごとに作者の姓を表示する列（作者姓）を作成：SPLIT([Author], '', 2 )
集計計算：SUMやCOUNT、 AVGなどの集計関数がついている計算
ex) 各シリーズの冊数を表示する列（シリーズの冊数-シリーズの詳細レベル）を作成：COUNT([Series])
集計・非集計どちらもDB側での計算処理
行レベル計算はスケーラビリティが高い（＝データが増えても処理の効率が良い）
DBチューニング施策が効果を出しやすい
表計算
表計算：ビジュアライゼーション内の値に適用する変換
ex) 値をランキングに変換する、値を変換して累計表示する、値を変換して合計に対する割合を表示する
クエリ結果を受け取り、Tableauが計算処理
計算フィールドよりもTableauの計算負荷が高い
計算フィールド vs ネイティブ機能
ネイティブ機能は計算フィールドよりも速いことが多い
ディメンションメンバーのグルーピング
グループが有効
ディメンションメンバーの名前変更
別名の編集が有効
メジャー値のカテゴリ化（ex. 〇〇円ごとの単位で見たい）
均等の幅でカテゴリ化する場合ビンが有効
計算フィールド
データ型はパフォーマンスへの影響が大きい
整数 > ブール > 文字 の順で速い
ロジック計算にはブール値＋別名を使う
悪い例
IF [DATE] = TODAY() THEN "TODAY" ELSE "NOT TODAY" END
良い例
[DATE] = TODAY() にして別名で真→TODAY、偽→NOT TODAYに編集
文字の検索
CONTAINS()はFIND()より速い
ワイルドカード照合はCONTAINS()より速い
日付計算
日付型への変換
文字列型への変換は非効率
悪い例
DATE(LEFT(STR([YYYYMMDD]),4) + "-" + MID(STR([YYYYMMDD]),4,2) + "2" + RIGHT(STR([YYYYMMDD]),2))
良い例
まずは文字列型になっているデータ型をそのままDate型に変更してみる
8桁の数字は基本的にはDate型に変更できるが、できない場合はDATEPARSEを使用する
ロジック関数
ELSEIF != ELSE IF
ELSE IFでスペース区切りをすると、新たなIF文ができてしまう（ IF文が複数になってしまう）
ELSEIFだと一つのIF文でまとめることができる
フィルタ
ディメンションフィルタ
不連続フィルタは遅い
TableauはDBにクエリ発行し、全てのディメンションを取得しに行く
連続（範囲）フィルタは速い
大量の不連続の値を取り込むより速い
データの濃度（カーディナリティ＝1列に入っている値の種類）が高い場合、範囲フィルタの方が速い
日付フィルタ
不連続フィルタは遅い
一つ一つ取得しなければならないのでクエリ結果が遅い
連続（範囲）フィルタは速い
範囲で取得するのでクエリ結果が速い
相対日付はさらに速い
クイックフィルタ
項目が表示されたクイックフィルタは遅い
表示する必要のある項目を全て取得しなければならない
複数の値（ドロップダウン）
単一値（ドロップダウン）
数値フィルタ
範囲日付フィルタ
項目がデータに依存しないクイックフィルタは速い
フィルタのための項目を探す必要がない
複数の値（カスタムリスト）
ワイルドカード照合
相対日付フィルタ
期間を参照フィルタ
ダッシュボード上のクイックフィルタ
クイックフィルタはディメンションリストを取得するため、大量に使うと遅くなる原因
対処策
異なるディメンションレベルで複数シートを作る
フィルタアクションを活用する
クイックフィルタでリストから選択ではなく、シート上で直接選択できるようにする
パラメータを活用する
フィルタ項目表示用のクエリが不要になる
フィルタの動く順番を意識する
抽出フィルタ
データソースフィルタ
コンテキストフィルタ
FIXED
セットフィルタ
ディメンションフィルタ
EXCLUDE / INCLUDE
メジャーフィルタ
表計算フィルタ
ダッシュボードデザイン
ビュー（シート）作成時の注意点
本当に必要なものだけを取得、表示する
マークカードに不要な「詳細」を入れない
ビューにも出てこないしツールヒントにも表示されていないのに何故かマークカードに存在するもの、、これもクエリとして動いてしまうため勿体無い！
不要な地理的役割は設定しない
生成された緯度経度を参照する時間を省く
ダッシュボード作成時の注意点
シートやクイックフィルタを少なくする
特にServerの場合は、タブを非表示にする
タブの表示されているビューは全てワークブックの構造を把握するプロセスが走る
フィルタアクション「すべての値を除外」を活用
全てのデータを取得する重たいクエリを避ける
ダッシュボードサイズを固定する
”自動”は毎回レンダリングされるため、キャッシュヒット率が低い
そもそもデザインの問題もある