DATA Saber挑戦メモ　～Ord7～

こんにちは。DATA Saber挑戦中のysもり⊿です。今回はOrdial7の挑戦メモを書いていきます。
　写真は、先週末に出かけた近所の山の展望台からの眺めです。群馬県桐生市内を一望でき、自宅から歩いて1時間弱で登れるので、年に10回くらいは訪れています。富士山や浅間山を眺められる時もあります。今は左腕をケガしているため、リュックを背負っての山登りはまだ出来ませんが、人間ドックで要精密検査(脂質異常)の結果となり、体質改善の旅に出ました。展望台で小休止して良い息抜きができました。残りのApprenticeの旅は、体質改善もしながらの旅となります。どちらも継続してがんばります！

Ord6を振り返って

Ord6では、ビジュアライゼーション表現の仕方、伝え方を学べ、なるほどと思うところばかりで楽しめました。
　また、この頃からお気に入りの音楽を聞きながら、Apprenticeの旅をすると集中力が長続きすることが判明して、今でも実践しています。よろしかったら試してみてください。

Ord7のなるほどポイント

《パフォーマンスを決める要素について》
〈やりたいこと〉 誰が、何のために、どのように使うのか
〈知識〉 どういう操作が遅くなるか知る
〈データ量〉 全RAWデータ、集計データ、絞ったデータなのか
〈処理能力〉 ハードウェア、DB製品、チューニング

・表計算はTableau側で処理
・JOIN（結合）はデータベース側で処理
・Tableau Desktopで表示が遅いものをTableau Serverで高速にはできない

《パフォーマンスについてのベストプラクティス》
1. データが遅ければ、Tableauで早くなることはない
2. Desktopで遅ければ、Serverで早くなることはない
3. 入れすぎ厳禁（シンプルに）

・Tableauのシートで作業する前に抽出フィルター、データソースフィルターで件数を減らすことができる

《フィルターの適用順序について》
Tableau内部での操作順序を『クエリパイプライン』と呼び、以下の順序で処理される。
・抽出フィルター（Extract Filters）
　↓
・データソースフィルター（Data Source Filters）
　↓
・コンテキストフィルター（Context Filters）
　↓　ーセット、条件フィルター、topN、Fixed LOD表現
・ディメンションフィルター（Dimension Filters）
　↓　ーInclude/Exclude LOD表現
・メジャーフィルター（Measure Filters）
　↓　ー予想、集計計算
・表計算フィルター（Table Calc Filters）
　　  ー傾向線、リファレンスライン

・データの集計が遅い場合、DBで事前にテーブルを準備してもよい

《結合とブレンディングについて》
〈結合＆クロスデータベース結合〉
・ファクト（トランザクション）テーブルとマスターテーブルの結合
〈ブレンディング〉
・多対多リレーションシップなどでJOINした際に値が合わないデータを結合

・異なる粒度のデータを結合する場合はブレンディング
（例）売上は毎日あるが、在庫日は1週間ごとなどデータの粒度が異なる場合に用いる。

・ライブ接続が早いか抽出接続が早いかはケースバイケースである

《データ抽出のパフォーマンスに影響する要因》
・行数
・列数（抽出ファイル作成時に影響）
・データ濃度（=カーディナリティ(集合の要素数)、ディメンションメンバーの数）
・ディメンション vs. メジャー

・抽出は必要な粒度で集計した状態で作成することができる

《集計された抽出について》
〈集計された抽出を集計分析に使用〉
・DWH(Data Ware House)から負荷を分散
・明細データはDWHに保持し、ライブ接続
〈抽出を高速化〉
・表示単位に集計
・不要なディメンションバーをフィルター
・使用していないフィールドを非表示

・行レベル計算(※1)を内包する集計計算(※2)を作成するときは計算式を分けて記載
→再利用出来るようにするため。計算式が複雑にならないようにするため。
(※1)行レベル計算：文字列などの計算のこと。(IF,etc.)
(※2)集計計算：メジャー(数値など)の計算のこと。(SUM、AVG,etc.)

《計算について》
〈行レベル計算と集計計算〉
・データベース側で計算処理
・行レベル計算はスケーラリビティが高い
　（DBチューニング施策が効果を出しやすい）
〈行レベル計算と集計計算を分割〉
・行レベル計算を1つの計算フィールドに
・集計計算を2つめの計算フィールドに
〈表計算〉
・クエリ結果を受取り、Tableauが計算処理
・計算フィールドよりもTableauの計算負荷が高い

・地域の値「北海道」と「東北地方」を表示上「北日本」エリアとしてまとめたい場合は、グループ化して別名をつける（下記ネイティブ機能参照）

《計算フィールド vs. ネイティブ機能》
→ネイティブ機能は計算フィールドよりも速いことが多い
〈ディメンションメンバーのグルーピング〉
・グループが有効
〈ディメンションメンバーの名前変更〉
・別名の編集が有効
〈メジャー値のカテゴリ化〉
・ビンが有効

《速く処理できるデータ型の順序について》
整数　＞　ブール型(※1)　＞　文字列型　の順に早い。
(※1)ブール型：True/Falseを表すデータ型

《計算フィールドについて》
〈データ型はパフォーマンスへの影響大〉
・整数はブールより早い
・整数・ブールは文字よりも早い
〈ロジック計算はブーリアンをシンプルに〉
・悪い例：IF[DATE]=TODAY() THEN "TODAY" ELSE "NOT TODAY" END
・良い例：[DATE]=TODAY()
〈文字の検索〉
・CONTAINS()はFIND()よりも早い
・ワイルドカード照合はCONTAINS()より早い

・日付の列に「2019年06月06日」という形式でデータが入っている文字列→日付型に直す方法は、まずは文字列型→Date型に変更してみる

《日付関数について》
・NOW()：システムタイムスタンプ
・TODAY()：システム日付

・日付のフィルターでは相対日付フィルタ(※)がパフォーマンス良い
（※) 例：今日から○○日前,etc.

・フィルターでは、複数の値（カスタムリスト）(※)がパフォーマンスが良い
(※)任意の値、文字検索,etc.

・表示されたフィルターの「関連値のみ」オプションを使用すると表示が遅くなる（クエリが増えるため）
　（カテゴリ/家具、家電、事務用品 → サブカテゴリ/椅子、テーブル･･･）

《フィルターについて》
〈不連続フィルターは遅い〉
・TableauはDBにクエリを発行し、すべてのディメンションを取得しにいく
〈範囲（連続）フィルターは早い〉
・大量の不連続の値を取り込むよりも早い
・データの濃度（カーディナリティ（1列に入っている値の種類））が高い場合、範囲フィルターの方が早い
〈保持・除外フィルターは遅い〉
・複雑なWHERE句による
〈インデックスやパーティションが有効に作用する〉
〈不連続日付は遅い〉
・ひとつひとつ取得しなければならないのでクエリ結果が遅くなる
〈連続日付の指定日付は早い〉
・範囲で取得するのでクエリ結果が早い
・相対日付はさらに早い
〈項目が表示されたクイックフィルターは遅い〉
・表示する必要のある項目は全て取得しなければならないため
（複数の値(ドロップダウン)、単一値(ドロップダウン)、数値フィルター、範囲日付フィルター)
〈項目がデータに依存しないクイックフィルターは早い〉
・フィルターのための項目を探す必要がないため
（複数の値(カスタムリスト)、ワイルドカード照合、相対日付フィルター、期間を参照フィルター）
〈2種のクイックフィルターの表示方法〉
（例：カテゴリー/サブカテゴリー,etc.）
・データベース内の全ての値
→他の全てのフィルターが変更されたとしても影響を受けない
・関連値のみ
→他のフィルターが関連してくる
〈大量のクイックフィルターは遅い原因〉
・たくさんのディメンションリストを取得しなければならない

《クイックフィルターの代わりに･･･》
〈フィルターアクションを活用する〉
[PROS]
・複数項目選択をサポート
・選択項目はデータに応じてダイナミックに変動
・データソース間をまたいでフィルターできる（クイックフィルターでもできるようになったが･･･）
・フィルター用のソースシートからもインサイトが得られる
[CONS？]
・設定がちょっと難しい（慣れの問題･･･）
・UIがクイックフィルターやパラメータの感じとちょっと違う（むしろ使いやすい）
・ソースシートはデータソースからクエリされる必要がある（クイックフィルターと同じだしむしろリッチに見せることができる）
〈パラメータを活用〉
[PROS]
・フィルター項目表示用のクエリが不要
・データソース間をまたいでフィルターできる（クイックフィルターでもできるようになったが･･･）
[CONS？]
・単一項目のみしか選択できない
・パラメータ + 計算フィールド = 複雑になりがち･･･

《クエリパイプライン（フィルターの順序）について》
・抽出フィルター
　↓
・データソースフィルター
　↓
・コンテキストフィルター
　↓
・FIXED
　↓
・セットフィルター
　↓
・ディメンションフィルター
　↓
・EXCLUDE/INCLUDE
　↓
・メジャーフィルター
　↓
・表計算フィルター

《ビュー（シート）について》
〈本当に必要なものだけを取得・表示する〉
・不要な詳細は外す
〈チャート vs. クロス集計〉
・行列の少ないマーク表示は表形式のものより早く表示できる
（テキストテーブルを描画するには大量のメモリが必要）
・詳細なクロス集計を表示するにはGuided Analyticsを使う
〈不要な地理的役割は設定しない〉
・生成された緯度経度を参照する時間を省く

《ダッシュボードについて》
〈シートやクイックフィルターを少なくする〉
・1シートにつき少なくとも1クエリ
・1クイックフィルターにつき少なくとも1クエリ
〈タブを非表示にする（特にServerの場合）〉
・タブの表示されているビューはすべてプロセスが走る
（タブを表示するためにワークブックの構造を把握するプロセスが走る）
・タブを減らすとパフォーマンスが上がる
〈フィルターアクションの”全ての値を除外”〉
・すべてのデータを取得する重たいクエリを避ける
〈サイズを固定したダッシュボード〉
・異なるウィンドウサイズで毎回描画しなければならない
・”自動”はキャッシュヒット率が低い
・（それにそもそもデザイン上の問題もあり）

《Tableauが向いていること》
・ビジュアル
・インタラクティブ
・繰り返し、定期的に使う
・迅速
・シンプル
・ユビキタス（いつでも使え、どこでも接続できる状態）

《Tableauがあまり向いていないこと》
・紙資料
・データエクスポート
・複雑なクロス集計
・Excelレポートの完全置換

Ord7を振り返って

Ord7は、パフォーマンスについての旅でした。今までTabuleauがこちらを理解してくれていましたが、少しはTableauの気持ちを汲み取ることができたような気がしております。メモしておきたいことが多すぎて、だいぶ長文になってしまいました😓
　GW休み前半の頃でしたが、お気に入りの音楽を聴きながら集中力を持続して旅をしていました😌 GW後半へ旅は続きます。

最後までお読みいただきありがとうございます。