【Tableau】 DATA Saber ord7. Performance Best Practice
Tableau/DATA Saberについて
Tableau/DATA Saberの概要、また私なりのこれまでの進め方については過去の記事をご参考ください。
Tableau DATA Saberとは何か
DATA Saberに取り組むための勉強方法や勉強時間
ord7.Performance Best Practice
復習や備忘も兼ねて知識系ord（2,4,7)について書いていこうと思います。
前回はord4.DATA Platform
今回はord7.Performance Best Practice
参考動画
パフォーマンスについて
なぜパフォーマンスが大切なのか
パフォーマンスが悪いと
答えを得るのに時間がかかる
分析フローが途切れてしまい乗れない
イライラする
自分が何を考えていたか、タスクを忘れて次のアイデアにつながらない
パフォーマンスが良いと
迅速に答えを見つけることができる
分析のフローに乗れる
遅いから自分で作ったほうが早いかも。。。と似たようなワークブックを量産せずに済む
パフォーマンスを決める要素
どこに負担がかかっている？
データが多すぎる？→チューニングしても早くならない
タブロー側でマークや行・列を使いすぎている可能性
データを集計する側とデータを描画する側のどちらが遅いか切り分ける
パフォーマンスを上げるために
パフォーマンスが悪い際にチェックすること（データを繋ぐときに）
ディメンション項目ではなるべくNULLは避ける
DB側でテーブルを準備する（集計データを事前準備、Tableauでの複雑な計算フィールドを回避するためにD B側で必要な処理をしておく。）
今まではTableauが気持ちを汲み取ってくれたがこれからはTableauの気持ちを汲み取る
データソース
データ量とパフォーマンスのジレンマ
データが多ければ多いほどたくさんのことを知ることができる
データが多ければ多いほど遅くなる
対象データの件数
・レコード数
行数が多いvs集計された行数が少ない
フィルターを使用し、件数を削減(抽出フィルター、データソースフィルタ
リレーショナル・データベース
・インデックスとパーティショニングは有効
・インデックス
・表の結合キーの列
・フィルターで使用される例
・パーティショニング
・ディメンション項目
NULL
・ディメンション項目ではNULLを避ける
・NULLをなくしてインデックス効果を向上
DB側でテーブルを準備
・集計データを事前準備
・Tableauでの複雑な計算フィールドを回避するために、DB側に必要な値をテーブルに持たせておく
結合vsブレンディング
・結合
・(特殊な事情でなければ)同じデータベースであれば、表の結合が望ましい
・インデックスを有効利用
・１本のクエリ
・ブレンド
・レコード数が多く、表の結合に適さない場合
・集計ビュー
・結合＆クロスデータベース結合
・ファクト（トランザクション）テーブルとマスタテーブルの結合
・ブレンディング
・多対多リレーションシップなどでJOINした際に値が合わないデータを結合
参照整合性の仮定
・ビューで使用している項目が1つのテーブルだけを対象とするケース
・「参照整合性の仮定」を設定することでクエリパフォーマンスを向上
・データメニューから設定
抽出vsライブ接続
・データエンジンの性能は相対的なもの
✔︎データエンジンが比較的速いケース
最適化されていないデータベース
PCファイル形式のデータソース
✔︎データエンジンが比較的遅いケース
高速マシーンのクラスター
データの抽出
・抽出のパフォーマンスの影響する原因
・行数
・列数(抽出ファイル作成時に影響)
・データ濃度(=ガーディナリティ、ディメンションメンバーの数)
・ディメンションvsメジャー
★集計された抽出
・集計された抽出を集計分析に使用
・DWHから負荷分散
・明細データはDWHに保持し、ライブ接続
・抽出を高速化
・表示単位に集計
・不要なディメンションフィルター
・使用していないフィールドを非表示
計算
・行レベル計算と集計計算
・データベース側で計算処理
・行レベル計算はスケーラビリティが高い
・DBチューニング施策が効果を出しやすい
・行レベル計算と集計計算の分割
・行レベル計算を１つの計算フィールドに
・集計計算を２つ目の計算フィールドに
・表計算
・クエリ結果を受け取り、Tableauが計算処理
・計算フィールドよりもTableauの計算負荷が高い
計算フィールドvsネイティブ機能
・ネイティブ機能は計算フィールドよりも速い事が多い
・ディメンションメンバーのグルーピング→グループが有効
・ディメンションメンバーの名前の変更→別名の変更
・メジャー値のカテゴリ化→ビンが有効
★計算フィールド
・データ型はパフォーマンスの影響が大きい
整数 ＜ ブール ＜ 文字列
・ロジック計算にはブーリアンを使用する
・悪い例
IF[DATE]=TODAY() THEN "TODAY" ELSE "TODAY" END
・良い例
[DATE]=TODAY()
・文字の検索
・CONTAINTS()はFIND()より速い
・ワイルドカード照合はCONTAINTS()より速い
計算フィールドで読むパラメーター
・条件式で参照するパラメーター
・表示名を利用
・整数として計算ロジックで参照
日付計算
そもそもデータ型を日付に変えればいい！文字型への変換は非効率
・悪い例
DATE(LEFT(STR([YYYYMMDD],4))+"-"+MID(STR[YYYYMMDD],4,2)0+
"-"+RIGHT(STR([YYYYMMDD],2)))
・数値型とDATEADD()の組み合わせ
・良い例
DATEADD('DAY',[YYYYMMDD]%100- 1,DATEADD('MONTH',INT([YYYYMMDD]%10000)/100)-1,DATEADD('YEAR',INT([YYYYMMDD])/10000)-1900,#1900-01-01#)
・日付関数
NOW() システムタイムスタンプ
TODAY() システム日付
ロジック関数
・ELSEIF！＝ELSE IF
IF [REGION]="EAST" AND [CUSTOMER SEGMENT]
="CONSUMER" THEN "EAST-CONSUMER"
ELSE IF [REGION]="EAST" AND [CONSUMER SEGMENT]
<>"CONSUMER" THEN "EAST-ALL OTHERS"
END
END
・改善例
IF [REGION]="EAST" AND [CONSUMER SEGMENT]
="CONSUMER" THEN "EAST-CONSUMER"
ELSEIF [REGION]="EAST" AND [CONSUMER SEGMENT]
<>"CONSUMER" THEN "EAST-ALL OTHERS"
END
・更に改善
IF [REGION]="EAST" THEN
IF [CONSUMER SEGMENT]="CONSUMER"
THEN "EAST-CONSUMER" ELSE "EAST-ALL OTHERS"
END
END
フィルター
■ディメンションフィルター
・不連続フィルターフィルターは遅い
・TableauはDBにクエリを発行し、全てのディメンションを取得しにいく
・範囲(連続)フィルターは速い
・大量の不連続の値を取り込むより速い
・データの濃度(ガーディナリティ*１列に入っている値の種類)が高い場合、
範囲フィルターの方が速い
・保持・除外フィルターは遅い
・複雑なWHERE句
・インデックスやパーティーションが有効に作用する
■日付フィルター
・不連続日付
・ひとつひとつ取得しなければならないのでクエリ結果が遅い
・連続日付の範囲指定
・範囲で取得するのでクエリ結果が速い
・相対日付が更に速い(今日から1年前など)
■クイックフィルター
・項目が表示されたクイックフィルターは遅い
・表示する必要のある項目は全て取得しなければならない
・複数の値(ドロップダウン)
・単一の値(ドロップダウン)
・数値フィルター
・範囲日付フィルター
・項目がデータに依存しないクイックフィルターは速い
・フィルターのための項目を探す必要がない
・複数の値(カスタムリスト)
・ワイルドカード照合
・相対日付フィルター
・期間を参照フィルター
■クイックフィルターの表示項目
・2種のクイックフィルター表示方法
・データベース内のすべての値
・他のフィルターが変更されたとしても影響されない
・関連値のみ
・他のフィルターが関連してくる
⇨パフォーマンスvs ビジュアル/ナビゲーション
■ダッシュボードのフィルター
・大量のクイックフィルターは遅い原因
・たくさんのディメンションリストを取得しなければならない
・クイックフィルターの代わりにGuided Analyticsを活用する
・異なるディメンションレベルで複数のシートを作る
・フィルターアクションを活用する
■クイックフィルターの代わりとなるもの
フィルターアクションを活用
メリット
・複数項目選択をサポート
・選択項目はデータに応じてダイナミックに変動
・データソース間を跨いでフィルターできる(最近クイックフィルターもできる)
・フィルター用のソースシートからもインサイトを得られる
デメリット
・設定がちょっと難しい
・UIがクイックフィルターやパラメーターの感じとちょっと違う
・ソースシートはデータソースからクエリされる必要がある
パラメーターを活用
メリット
・フィルター項目表示用のクエリが不要
・データソース間を跨いでフィルターできる(最近クイックフィルターもできる・・)
デメリット
・単一項目のみしか選択できない
・パラメーター＋計算フィールド＝複雑になりがち
ダッシュボードデザイン
ビュー(=シート)
・本当に必要なものだけを取得・表示する
・不要な"詳細"を外す
・チャート vs クロス集計
・行列の少ないマーク表示は表形式のものより早く表示できる
・テキストテーブルを描画するには大量のメモリが必要
・詳細なクロス集計を表示するにはGuided Analysisを使うこと
・不当な地理的役割は設定しない
・生成された緯度経度を参照する時間を省く
ダッシュボード
・シートやクイックフィルターを少なくする
・１シートにつき少なくとも1クエリ
・１クイックフィルターにつき少なくとも1クエリ
・タブを非表示にする(特にServerの場合)
・タブの表示されているビューはすべてプロセスが走る
・タブを表示するためにワークブックの構造を把握するプロセスが走る
・タブを減らすとパフォーマンスが上がる
・次のパラメーターを試してみる':tabs=no'
・フィルターアクションの"すべての値を除外"
・すべてのデータを取得する重たいクエリを避ける
・サイズを固定したダッシュボード
・異なるウインドウサイズで毎回描画しなければならない
・Viz QL Server はユーザーごとにレンダリングを行う
・"自動"はキャッシュヒット率が低い
・(それにそもそもデザインに問題もある)
Tableauの向き/不向き
Tableauが向いていること
ビジュアル
インタラクティブ
繰り返し・定期的に使う
迅速
シンプル
ユビキタス
Tableauがあまり向いていないこと
紙資料
データエクスポート
複雑なクロス集計
エクセルレポートの完全置換
さいごに
ord7.Performance Best Practiceは、普段Vizを作る中であまり意識してない部分で、理解するのにとても時間がかかりました。いつもこのダッシュボードのフィルターかけると、なんかくるくる回って表示までに時間かかってるけどなんでかなー、まあいいやとしてしまっていた。
KTさんの動画の中でもありますが、パフォーマンスが悪いと、中々見たい状態が表示されず結局使えないもの、となりがち。
ZEM問答の件では無いですが、前の伝統的エクセルの方が使いやすかったよね、となって、組織内でデータドリブン文化が根付かない、なんならTableauは使えないと言う印象だけ残ってしまう、となると目も当てられないですよね。
ひとまずこれで知識系ord（2,4,7)は終了。
次はHands Onの内容の復習に入ります。
この記事が気に入ったらサポートをしてみませんか？