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はユーザーごとにレンダリングを行う
　　・"自動"はキャッシュヒット率が低い