【Tableau】DATA Saber（Ord7）

◆Viewerの実際
　Vizの多くは必要とされず、意外にシンプルでピンポイントでした　v(･_･)v

■データを一目で見せる

「Performance Best Practice」の内容をまとめました

1．パフォーマンスの考え方（概論）

（1）なぜ大事か
　　　フローが途切れると、アクションやアイデアに結びつかない
　　　✓迅速に答えを見つけることができる
　　　✓分析のFlowに乗れる
　　　✓似たようなワークブックを量産せずにすむ
　　　✓Fast workbook = Happy users

（2）要素
　　　やりたいこと
　　　　誰が何のためにどのように使うのか
　　　知識
　　　　どういう操作が遅くなるか知る（どういう処理が早くなるか）
　　　データ量
　　　　全RAWデータ、集計データ、絞ったデータ
　　　処理能力
　　　　ハードウェア、DB製品、チューニング

（3）誰がなにを処理するか
　　　DB
　　　　クエリの実行（結合、集計、計算）
　　　Tableau
　　　　レンダリング（マーク、表計算、ソート）

　　　パフォーマンスが遅くなったとき、どこが原因か

　◆ベストプラクティス
　　Ⅰ．データが遅ければ、Tableauで早くなることはない
　　Ⅱ．Desktopが遅ければ、Serverで早くなることはない
　　Ⅲ．入れすぎ厳禁（シンプルに）　『１分析で１ワークブックくらい』

　Tableauが気持ちを汲み取ってくれていた
　DATASaberたるもの、Tableauの気持ちを汲み取ろう

　「パフォーマンス記録」
　　・ヘルプ ＞ 設定とパフォーマンス ＞ パフォーマンスの記録を開始
　　・いろいろ操作する
　　・ヘルプ ＞ 設定とパフォーマンス ＞ パフォーマンスの記録を停止
　　・ワークブック「Performance Summary」が表示される
　　　cf.「Events Sorted by Time」＞「Executing Query」

2．データソース

（1）増えるデータ vs ハードウェア

（2）データ量とパフォーマンスのジレンマ
　　　データは多ければ多いほど、たくさんのことを知ることができる
　　　データは多ければ多いほど、遅くなる（=Flowに乗れない）

（3）対象データの件数
　　　行数が多い vs 集計され行数が少ない
　　　フィルターで件数を削減　『直近2年だけ、特定カテゴリだけ』
　　　（抽出／データソースフィルター）　『ディメンションは減らない』

（4）リレーショナル・データベース
　　　インデックスとパーティションは有効
　　　インデックス
　　　　表の結合キー列
　　　　フィルターで使用される列
　　　パーティショニング
　　　　ディメンション項目　『全抽出は有効ではない、ライブで有効』

（5）リレーショナル・データベース
　　　NULL
　　　　ディメンション項目ではNULLを避ける
　　　　NULLを無くしてインデックス効果を向上
　　　DB側でテーブルを準備
　　　　集計データを事前準備
　　　　Tableauでの複雑な計算フィールドを回避するために、
　　　　DB側に必要な値をテーブルに持たせておく

（6）結合vsブレンディング
　　　結合
　　　　同じデータベースであれば、表の結合が望ましい
　　　　インデックスを有効利用
　　　　１本のクエリ
　　　ブレンド
　　　　レコード数が多く、表の結合に適さない場合
　　　　集計ビュー

　◆おさらい
　　　結合&クロスデータベース結合
　　　　ファクト（トランザクション）テーブルとマスタテーブルの結合　　
　　　ブレンディング
　　　　多対多リレーションシップなどでJOINした際に値が合わないデータを結合

（7）①結合、②ブレンディング、③クロスデータベース結合
　　　✓いつくっつく
　　　　　①DB
　　　　　②ローカルのメモリ
　　　　　③ローカルのメモリ
　　　✓どういう動き
　　　　　①くっついてから集計
　　　　　②集計してからくっつく
　　　　　③くっついてから集計
　　　✓どんなデータがTableauに送られる
　　　　　①集計後の結果
　　　　　②各データソースからのデータがリンクした項目と
　　　　　　Viz内のディメンションで集計
　　　　　③結合でキー項目として使用されている項目と
　　　　　　Viz内で使用されている項目全件
　　　✓パフォーマンスに影響するもの
　　　　　①DBスペック
　　　　　②リンクした項目の項目数
　　　　　③テーブルに入っている行数

（8）抽出 vs ライブ接続
　　　データエンジンの性能は相対的なもの
　　　　比較的早いケース
　　　　　最適化されていないデータベース
　　　　　PCファイル形式のデータソース
　　　比較的遅いケース　
　　　　高速マシンのクラスター

（9）データの抽出
　　　抽出のパフォーマンスに影響する要因
　　　　行数
　　　　列数（抽出ファイル作成時に影響）
　　　　データ濃度（＝カーディナリティ、ディメンションメンバーの数）
　　　　ディメンションvsメジャー

3．計算フィールド

（1）計算
　　　行レベル計算と集計計算
　　　　データベースで計算
　　　行レベル計算と集計計算を分割　『V.B.P.』
　　　　表計算
　　　クエリ結果をTableauが計算

（2）計算フィールドvsネイティブ機能
　　『計算フィールドはなるべく使わない』
　　　ネイティブ機能は計算フィールドよりも早いことが多い
　　　　グループ（ディメンションメンバー）
　　　　別名（名前変更）
　　　　ビン（メジャー値のカテゴリ化）　『幅が均等の場合』

（3）計算フィールド
　　　データ型は影響大（整数＜ブール＜文字）
　　　ロジック計算はブーリアン　『意外とIFが多い』
　　　文字の検索（ワイルドカード照合＜CONTAINS＜FIND）

（4）計算フィールドで読むパラメータ
　　　条件式で参照するパラメータ
　　　　表示名を利用（整数として計算ロジックで参照）　『おすすめ』

（5）日付計算
　　　日付型への変換
　　　　文字型への変換は非効率　『文字列変換しない』
　　　　数値型とDATEADDの組み合わせ
　　　日付関数
　　　　NOW（システムタイムスタンプ）
　　　　TODAY（システム日付）　

（6）ロジック関数
　　　ELSEIF／ELSE IF
　　　『スペースがあると次のIF文になる』
　　　『何度も同じ判定を書かない』

4．フィルター
　『フィルターの表示はもったいない、何のインサイトも得られない』

（1）ディメンションフィルター
　　　不連続フィルターは遅い
　　　範囲（連続）フィルターは早い

（2）日付フィルター
　　　不連続日付は遅い
　　　連続日付の範囲指定は早い
　　　相対日付はさらに早い

（3）クイックフィルター
　　　項目が表示されたクイックフィルターは遅い
　　　　複数の値（ドロップダウン）
　　　　単一値（ドロップダウン）
　　　　数値フィルター
　　　　範囲日付フィルター
　　　項目がデータに依存しないクイックフィルターは早い
　　　　複数の値（カスタムリスト）
　　　　ワイルドカード照合
　　　　相対日付フィルター
　　　　期間を参照フィルター

（4）クイックフィルターの表示項目
　　『クイックフィルターはなるべく使わないのもV.B.P.のひとつ』
　　　2種のクイックフィルターの表示方法
　　　　データベース内のすべての値は影響されない
　　　　関連値のみは他のフィルターが関連してくる

（5）ダッシュボート上のクイックフィルター
　　『熟練した人はクイックフィルターを使っていない』
　　『クエリ、画面スペースがもったいない』
　　　大量のクイックフィルターは遅い原因
　　　クイックフィルターの代わりにGuided Analyticsを活用する

（6）クイックフィルターの代わりに
　　『クイックフィルターは存在しないほうがいい』
　　『選ぶということは自分が見たいものではなかったから』
　　『自分が見たいものが最初から出ている、深堀りはマーク』
　　『クイックフィルターなく仕上げるのは、クリエイターの責任』
　　　フィルターアクションを活用
　　　パラメーターを活用（計算フィールド要）

（7）フィルターの種類と順序
　　　抽出フィルター（※）
　　　データソースフィルター（※）
　　　コンテキストフィルター
　　　FIXED
　　　セットフィルター
　　　ディメンションフィルター
　　　EXCLUDE/INCLUE
　　　メジャーフィルター
　　　表計算フィルター
　　　（※）画面上にデータは表示されない（使うことのないデータ）

5．ダッシュボートデザイン

（1）ビュー（シート）
　　　本当に必要なものだけを取得・表示する　『最後の整理が大事』
　　　（不要な詳細は外す）
　　　チャートvsクロス集計
　　　（マーク表示は表形式より早く表示できる）
　　　（詳細なクロス集計の表示はGuided Analyticsを使う）
　　　不要な地理的役割は設定しない
　　　（緯度経度の参照時間を省く）

（2）ダッシュボード
　　　シート、クイックフィルターは少なく
　　　（１シートに１クエリ、１クイックフィルターに１クエリ）
　　　タブは非表示（プロセスが走るため）
　　　フィルターアクション「すべての値を除外」
　　　サイズを固定したダッシュボード
　　　『ビューの縦横比が大事、サイズ感がデザイン性になる』

（3）Tableauが向いていること
　　　ビジュアル
　　　インタラクティブ
　　　繰り返し、定期的に使う
　　　迅速
　　　シンプル
　　　ユビキタス

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

■まとめ
　「パフォーマンスのよいダッシュボードデザイン」＝
　「人が見たときにもわかりやすいデザイン」

『一目見てわかることが大切
　（一画面に重要な情報が分かりやすく見られる）』
　“A dashboard is a visual display of the most important information needed to achieve one or more objectives,consolidated and arranged on a single screen so the information can be monitored at a glance.”　Stephen Few

『見た目がいいものにしていくと、ダッシュボードのパフォーマンスの
　　ベストプラクティスに通ずる』　KT

◆最後に
　Viewerに問いかけ目線を合わせると一体感を感じられる今日この頃