もうすぐ最終試練。
自分用メモとして・・・・
各Ordでつまずいた問題、復習しておきたいポイント（＆KTさんの動画リンク）を羅列しておきます。
動画見直しには下記のVizが便利。
＝＝
Ord7：Perfomance Best Practice
- 間違えた問題：Q2、Q8、Q14
- どこで何が処理されるか ★要確認
- クエリパイプラインは覚える！
- 「パフォーマンス記録」
-
ヘルプ→設定とパフォーマンス →パフォーマンスの記録→記録を停止
-
悪くなったら何が原因でおそいのかをつきとめないといけない
-
-
データ量が多ければ多いほどたくさんのことを知ることができる vs データは多ければ多いほど遅くなる
-
レコード数削減
-
フィルターを使用して件数を削減
-
抽出フィルタ
-
データソースフィルタ
-
-
-
リレーショナルデータベースの場合
-
インデックスとパーティショニングは有効
-
インデックス
-
表の結合キーの列
-
フィルターで使用される列
-
-
パーティショニング
-
ディメンション項目
-
-
-
- ディメンション項目ではNULLを避ける
-
DB側でテーブルを準備
-
結合 vs ブレンディング
結合
ブレンディング
クロスデータベース結合
→抽出してからのほうがいいいつくっつくか：
DB
ローカルメモリ
ローカルメモリ
どういう動きになるか
くっついてから集計する
集計してからくっつく
DBで集計してTableauでくっつく
くっついてから集計する
Tableauで行単位でくっついたあとに集計
結構な量がやってくる
どんなデータがTableauに送られるのか
集計後の結果
Vizのマークの分だけ
それぞれのデータソースからのデータがリンクした項目とViz内のディメンションで集計されたもの
結合でキー項目として使用されている項目と項目全件
パフォーマンスに影響するもの
DBのスペック
リンクした項目の項目数
テーブルに入っている行数
-
参照整合性の仮定
-
ビューで使用している項目が１つのテーブルだけを対象とするケース
-
わざわざ結合しない
-
-
抽出 vs ライブ接続 ★要復習
-
データエンジンが比較的早いケース
-
最適化されていないデータベース
- PCファイル形式のデータソース CSVとか
-
-
データエンジンが比較的遅いケース
-
高速マシンのクラスター
-
-
-
データの抽出：抽出パフォーマンス
-
行数
-
列数（抽出ファイル作成時）
-
- データ濃度（カーディナリティ。ディメンションメンバーのかず）
-
ディメンションvs メジャー：メジャーの方がいい
-
集計された抽出を集計分析に使用
-
非表示にしたものをぬいてくれる
- DWHから負荷分散
- 明細データはDWHに保持し、ライブ接続
- 抽出を高速化
- 表示単位に集計
- 不要なディメンションメンバーをフィルター
- 使用していないフィールドを非表示
- 計算フィールド
- 行レベル計算と集計計算（SUMとか）
-
データベース側で計算処理
-
行レベル計算はスケーラビリティが高い
-
DBチューニング施策が効果をだしやすい
-
-
行レベル計算と集計計算を分割 → 再利用
-
行レベル計算を1つの計算フィールドに
-
集計計算を2つ目の計算フィールドに
-
-
表計算 累計とか、合計に対する割合とか
-
クエリ結果を受け取り、Tableauが計算処理
-
計算フィールドよりもTableauの計算負荷が高い
-
-
- 行レベル計算と集計計算（SUMとか）
-
計算フィールド vs ネイティブ機能
-
なるべくネイティブ機能をつかう
-
ディメンションメンバーのグルーピング
-
グループが有効
-
-
ディメンションメンバーの名前変更
-
別名の編集が有効
-
-
メジャー値のカテゴリ化
-
ビンが有効
-
-
-
データ型はパフォーマンスへの影響が大きい
-
整数＞ブール＞文字
-
ロジック計算はブーリアンを使用
-
×：IF Date=Today() THEN ''TODAY" ELSE…
-
〇Date=TODAY() にして、真偽にし、別名にする
-
-
- 文字の検索
-
CONTAINS（）はFIND（）よりはやい
-
ワイルドカード照合はCONTAINSよりはやい
-
-
日付への変換
-
文字型への変換は非効率
-
数値型とDATEADD
-
DATEPARSEを使う（抽出後は必ず使える）
-
日付関数
-
NOW()
-
TODAY()
-
- ロジック関数
-
ELSEIF ! = ELSE IF
スペースけすだけで一個の分になおせる
-
-
- フィルタ
-
不連続フィルターは遅い（TableauはDBにクエリを発行し、すべてのディメンションを取得しにいく。一個ずつとってこなくてはいけない）
-
範囲（連続）フィルターは早い
-
大量の不連続の値を取り込むよりはやい
-
データの濃度（カーディナリティ ※1列に入っている値の種類）が高い場合、範囲フィルターの方が早い
-
-
保持、除外フィルターは遅い
-
ふくざつなWHERE句
-
-
インデックスやパーティションが有効に作用する
-
不連続日付
-
一つ一つ取得しなければならないのでクエリ結果が遅い
-
連続日付の範囲指定
-
範囲で取得するのでクエリ結果が早い
-
相対日付はさらにはやい（今日から何年前、の跡に計算）
-
-
- クイックフィルタ：大量のクイックフィルタは遅い原因
-
項目が表示されたクイックフィルターは遅い
-
表示する必要のある項目はすべて取得しなければならない
-
複数の値（ドロップダウン）
-
単一値（ドロップダウン）
-
数値フィルタ
-
範囲日付フィルタ
-
-
-
項目がデータに依存しないクイックフィルタは早い
-
フィルタのための項目を探す必要がない
-
複数の値（カスタムリスト）
-
ワイルドカード照合
-
相対日付フィルタ
-
期間を参照フィルタ
-
-
- クイックフィルタの表示項目
-
二種のクイックフィルターの表示方法
-
データベース内のすべての値
-
他のフィルタが変更されたとしても影響されない
-
-
関連値のみ
-
他のフィルターが関連してくる
-
-
-
-
クイックフィルターのかわりにGuided Analyticsを活用する ★
-
異なるディメンションれべるで複数のシートを作る
-
フィルターアクションを活用する
-
PROS
-
複数項目選択をサポート
-
選択項目はデータに応じてダイナミックに変動
-
データソース間をまたいでフィルターできる（最近クイックフィルターでもできるけど・・・）
-
フィルター用のソースシートからもインサイトを得られる
-
-
CONS・
-
設定がちょっと難しい（なれればどうってことない）
-
UIがクイックフィルターやパラメータの感じとちょっとちがう（むしろ使いやすい）
-
ソースシートはデータソースからクエリされる必要がある（クイックフィルターと同じだしむしろリッチに見せることができる）
-
-
-
パラメータを活用する
-
PROS
-
フィルター項目表示用のクエリが不要
-
データソース間をまたいでフィルターできる（最近クイックフィルターでもできるけど・・・）
-
-
CONS
-
単一項目しか選択できない
-
パラメータ＋計算フィールド＝複雑になりがち
-
-
-
-
-
- クエリパイプライン
-
抽出フィルタ
-
データソースフィルタ
-
コンテキストフィルター
-
FIXED
-
セットフィルター
-
ディメンションフィルタ
-
EXCULDE/INCLUDE
-
メジャーフィルタ
-
表計算フィルタ
-
-
ビュー（＝シート）
-
本当に必要なものだけを取得・表示する
-
不要な「詳細」は減らす
-
-
チャート vs クロス集計 ・
-
行列の少ないマーク表示は表形式のものより早く表示できる。テキストテーブルを描画するには大量のメモリが必要
-
詳細なクロス集計を表示するにはGuided Analysisを使うこと
どこかをクリックすると詳細が横に出るみたいな
-
- 不要な地理的役割は設定しない
- 生成された緯度経度を参照する時間を省く
-
-
ダッシュボード
-
シートやクイックフィルタを少なくする
-
１シートにつき少なくとも１クエリ
-
１クイックフィルターにつき少なくとも１クエリ
-
-
タブを非表示にする
-
タブの表示されているビューはすべてプロセスが走る
-
タブを表示するためにワークブックの構造を把握するプロセスが走る
-
-
タブを減らすとパフォーマンスが上がる
-
パラメータ’:tabs=no’ → URLのパラメータ
-
-
-
フィルタアクションの「すべての値を除外」 活用しましょう。
-
選択したあとフィルタするとNULLになる。
-
あとでだしたいときに全部だせる
-
LODつかって５個以上は選べないようにするとか
-
- すべてのデータを取得する重たいクエリを避ける
-
サイズを固定
-
「自動」はキャッシュヒット率が低い
-
-