DATA Saber Ord7
こちらの問題はかなり苦戦しました。。。。DATA Saber目指す中ではかなり重要な部分でした。基本メモ書きなのでつたない文で申し訳ないです。
(写真のアイスは濃厚さがほどほどでおいしかったです…!)
パフォーマンスを決める要素
・やりたいこと：だれが何のためにどのように使うのか
・知識：どうしたらTableauが遅くなるのかなど
・データ量：全RAWデータ、集計データ、絞ったデータ
・処理能力：ハードウェア、DB製品、チューニング
パフォーマンスが悪くなっている原因を突き止めないといけない
PCなのかTableauなのかDBを保存しているところなのか。
・データが遅ければTableauではやくなることはない
・Destopで遅ければ、Serverではやくなることはない
・入れすぎ厳禁
パフォーマンス記録
レコード数
⇒抽出フィルター
⇒データソースフィルター
リレーショナルデータベース［ライブのとき］
・インデックス
⇒表の結合キーの列
⇒フィルターで使用される列
・パーティショニング
⇒ディメンション項目
・NULL
⇒ディメンション項目ではNullは避ける
⇒Nullをなくしてインデックス効果を向上
・DB側でテーブルを準備
⇒集計データを事前準備
⇒Tableauでの複雑な計算フィールドを回避するために、DB側に必要な値をテーブルに持たせておく
結合・ブレンディング
・結合
⇒同じデータベースであれば表の結合が望ましい
⇒インデックスを有効利用
⇒１本のクエリ
・ブレンド
⇒レコード数が多く、表の結合に適さない場合
⇒集計ビュー
・結合クロスデータ結合
⇒ファクトテーブルとマスタテーブルの結合
・ブレンディング
⇒多対多リレーション市ppなどでJOINした際に値が合わないデータを結合
参照整合性の仮定
⇒ビューで設定している項目が1つのテーブルだけを対象とするケース
⇒クエリパフォーマンスを向上
⇒データメニューから設定
抽出・ライブ接続
⇒データエンジンの性能は相対的
データの抽出
⇒行数
⇒列数(抽出ファイル作成時に影響)
⇒データ濃度(カーディナリティ。ディメンションメンバーの数)
⇒ディメンションvsメジャー
・行レベル計算と集計計算
⇒DB側で計算処理
⇒行レベル計算はスケーラビリティが高い
・行レベル計算と集計計算を分割
⇒行レベル計算を一つの計算フィールドに
⇒集計計算を二つ目の計算フィールドに
・表計算(%に対する割合など)
⇒クエリ結果を受け取りTableauが計算処理
⇒計算フィールドよりもTableau計算負荷が高い
計算フィールドvsネイティブ機能
⇒ネイティブ機能は計算フィールドよりも速いことが多い
ディメンションメンバーのグルーピング(グループが有効)
ディメンションメンバーの名前変更(別名の編集が有効)
メジャー値のカテゴリ化(ビンが有効)
計算フィールド
⇒データ型はパフォーマンスへの影響が大きい
整数はブールより速い
整数・ブールは文字よりも速い
⇒ロジック計算にはブーリアンを使用する
悪い例 IF [DATE]=TODAY() THEN "TODAY" ELSE "NOT TODAY" END
良い例 [DATE]=TODAY() 出た値の真偽それぞれに名前を付けられる(行レベルのみ)
⇒文字の検索
CONTAINS()はFIND()より速い
ワイルドカード照合はCONTAINS()より速い
条件式で参照するパラメータ
VALUEの部分を数字名にしておくとのちのち扱いやすい
(できるだけ文字列を減らそうとしていく流れ！)
日付計算
文字列への変換は非効率
悪い例 DATE(LEFT(STR[YYYYMMDD],4+"-"+MID(STR[YYYYMMDD],4,2)+"-"+RIGHT(STR[YYYYMMDD],2))
良い例 DATDD('DAY',[YYYYMMDD]%100-1,DATEDD('MONTH',INT(([YYYYMMDD]%10000)/100)-1, DATEDD('YEAR',INT([YYYYMMDD]/10000)-1900,#1900-01-01#)))
またはDATEPARSE("yyyy年MM月dd日",[日付])
日付関数
NOW() システムタイムスタンプ
TODAY() システム日付
ロジック関数
IF文でできるだけ条件は一つに、シンプルに心がける
フィルター
ディメンションフィルター
不連続フィルターは遅い
・TableauのDBにクエリ発行し、すべてディメンションを取得していく
範囲(連続)フィルターは速い
・大量の不連続の値を取り込むより早い
・データの濃度が高い場合(1列に入っている値の種類)、範囲フィルターのほうが早い
保持・除外フィルターは遅い
インデックスやパーティションが有効に作用する
日付フィルター
・不連続日付：ひとつひとつ取得しなければならないのでクエリ結果が遅い
・連続日付の範囲指定：範囲で取得するので結果が早い、相対日付はさらに早い
クイックフィルター
項目が表示されたクイックフィルターは遅い
⇒表示する必要のある項目はすべて取得しなければならない
複数の値(ドロップダウン)、単一値(ドロップダウン)、数値フィルター、範囲日付フィルター
項目がデータに依存しないクイックフィルターは速い
⇒フィルターのための項目を探す必要がない
複数の値(カスタムリスト)、ワイルドカード照合、相対日付フィルター、期間を参照フィルター
クイックフィルターの表示項目
2種のクイックフィルターの表示方法
データベース内のすべての値
ほかのフィルターが変更されたとしても影響されない
関連値のみ
ほかのフィルターが関連してくる
パフォーマンスVSビジュアル/ナビゲーショントレードオフの関係
ダッシュボード上のクイックフィルター
大量のクイックフィルターは遅い原因
たくさんのディメンションリストを取得しなければならない
クイックフィルターの代わりにGuided Analyticsを活用する
異なるディメンションレベルで複数のシートを作る
フィルターアクションを使用する
クイックフィルターの代わりに…
フィルターアクションを活用する
PROS
・フィルター項目表示用のクエリが不要
・データソース間をまたいでフィルターできる
CONS
・単一項目のみしか選択できない
・パラメーター+計算フィールド=複雑になりがち
フィルターの順序を意識する
・抽出フィルター
・データソースフィルター
・コンテキストフィルター
・FIXED
・セットフィルター
・ディメンションフィルター
・EXCLUDE/INCLUDE
・メジャーフィルター
・表計算フィルター
ダッシュボードデザイン
ビュー
・本当に必要なものだけを取得・表示する 不要な詳細は外す
・チャートvsクロス集計
行列の少ないマーク表示は表形式のものより速く表示
テキストテーブルを描写するには大量のメモリが必要
詳細なクロス集計を表示するにはGuided Anylysisを使うこと
・不要な地理的役割は付与しない
生成された緯度経度を参照する時間を省く
ダッシュボード
・シートやクイックフィルターを少なくする
1シートに少なくとも1クエリ
1クイックフィルターに少なくとも1クエリ
・タブを非表示にする
・タブの表示されているビューはすべてプロセスが走る
タブを表示するためにワークブックの構造を把握するプロセスが走る
・タブを減らすとパフォーマンスが上がる
次のパラメータを試してみる';tabs=no'
・フィルターアクションの"すべての値を除外"
・すべてのデータを取得する重たいクエリを避ける
・サイズを固定したダッシュボード
・異なるウィンドウサイズで毎回描写しなければならない
・ViZQL Serverはユーザーごとにレンダリングを行う
・"自動"はキャッシュヒット率が低い