Designing Dashboard for Performance-復習まとめ
こんにちは。Riekoです。
今回はDATASaber技術試練ord7、Designing Dashboard for Performanceを復習して、まとめたことを書いていきます。
長文・駄文失礼します。
パフォーマンスの考え方
なぜパフォーマンスが大事か？
フローが途切れてしまうから
ぐるぐる回っている画面になると
思考のフローが途切れてしまう、速く答えを届けてあげることが大切
イライラする
アイデアに結びついていかない
速くすることが目的になってしまう
パフォーマンスが大事な理由
迅速に答えを見つけることができる
分析のFlowに乗れる
似たようなワークブックを量産せずに済む：自分で作ったら速いんじゃないか、と思ってワークブックを量産してしまうことがある
Fast workbook = Happy Users
パフォーマンスを決める要素
やりたいこと(Task)：やりたいことが決まるとデータを絞ることができる
誰が、何のために、どのように使うのか
知識
どういう操作が遅くなるかを知る
データ量
全RAWデータ、集計データ、絞ったデータ
処理能力：ここにフォーカスされがち←お金をかければなんとかできる
ハードウェア、DB製品、チューニング
他の要素を調節することで、処理能力にふんだんにお金を掛けなくてもよくなる（やりたいことをきちんと定義した上で）
やりたいことと知識が適切なものを選び取る力をくれる
誰が何を処理するかが重要
Tableauで何かすると、TableauがSQLに変換してDBにクエリを渡す。
DB側で結合、集計、計算が行われる
1.の結果Tableauに渡された結果を、ビジュアライズして表示する (VizQL)
Tableau側でマーク、表計算、ソートが行われる
Tableau側とDB側、それぞれの環境がどこにあるかを理解しておく必要
TableauがPCにあればPCが処理をがんばっているし、サーバーにあればサーバー側で処理を頑張っている
データのあるDBがDBサーバーにあれば、DBサーバー側に負荷がかかっている。ローカルにあればローカルに負荷がかかっている。
抽出ファイルの場合はローカルにデータを持ってきているのでローカルが頑張っている
大量のデータを扱って重くなっているとき、Tableauのマーク数が多すぎたりビューのレンダリングが原因で重くなっているのならばDB側をチューニングしても速くならない
何が原因で遅くなっているのかを正しく突き止めることが必要
突き止めたら、その処理がどこで行われているのかを考慮する
遅いときに抽出ファイルにするのは、DB側で遅いのをTableau側に処理させるということ
Tableauのレンダリングも重くてデータ側も重い場合：両方が同じ環境にあれば当然重くなる
サーバー側でたくさんの処理を行っている傍ら更新も同時に行っていると当然重くなる
どういう処理のパーツが重くて、それはどこで処理されているのか、どれをどこに持っていけば速くなりうるのかを抑えておく
ベストプラクティス
データが遅ければ、Tableauで速くなることはない
レコード数の集計などごく単純な処理で遅い場合Tableau側を直しても速くならないのでDBをチューニングする
Desktopで遅ければ、Serverで速くなることはない
Serverの方がスペックが高いので速そうに思えるが、同時に色んな処理をしているので遅くなりやすい
入れすぎ厳禁
1ワークブックに100シートなど、１ワークブックに色々詰め込むことはしない
いままではTableauがみなさんの気持ちを汲み取ってくれていましたが...
DATA Saberたるもの、みなさんもTableauの気持ちを汲み取ってみましょう！！！
Tableauの気持ちを聞く：パフォーマンスの記録
何が起こっているか？
どんなクエリが走っているのかわかる
何に時間がかかっているのか？
遅い処理だけに絞って確認できる
Serverのパフォーマンスビューも確認する。
データソース
増えるデータVSハードウェア
技術の進歩に伴い、データは加速度的に増加している
ハードウェアも進化しているが、それ以上にデータが増加しているので、データ量を気にせず操作できるまでには至っていないのが現状。
データは多ければ多いほどたくさんのことをしることができる
VS データは多ければ多いほど遅くなる(=Flowに乗れない)
対象データの件数
レコード数
行数が多いVS.集計され行が少ない：現状扱うのに妥当な件数か？
フィルターを使用し、件数を削減
抽出フィルター
データソースフィルター
データを扱うのに件数を減らせるなら、事前に集計して行を減らしてもよい。
不要なデータは抜いてしまって、件数を減らすこともできる。
抽出フィルターかデータソースフィルターを使わなければデータ件数が減っているわけではないので注意が必要。
リレーショナル・データベース
インデックスとパーティショニングは有効
インデックス
表の結合キーの列をインデックスに
フィルターで使用される列をインデックスに
パーティショニング
ディメンション項目を使う
全てのデータを抽出して使う場合はこれらは機能しない。
ライブで繋いでいる場合のみ有効。NULL：NULLがあると遅くなりがち
ディメンション項目ではNULLを避ける
NULLを無くしてインデックス効果を向上
DB側でテーブルを準備
集計データを事前準備
Tableauでの複雑な計算フィールドを回避するために、DB側に必要な値をテーブルに持たせておく
LOD計算が複雑で重くなっている場合など
結合・ブレンディング
結合
（特殊な事情でなければ）同じデータベースであれば、表の結合が望ましい
結合キーにインデックスを有効利用
1本のクエリで足りることになる
ブレンド
異なる粒度のデータ同士の結合で、レコード数が多く、表の結合に適さない場合
結合すると行が増えてしまう場合
集計されたビュー
結合&クロスデータベース結合
ファクト（トランザクション）テーブルとマスタテーブルの結合
ブレンディング
多対多リレーションシップなどでJOINした際に値が合わないデータを結合
いつくっつく？
結合：DB
ブレンディング：ローカルのメモリ
クロスデータベース結合：ローカルのメモリ
どういう動きになる？
結合：くっついてから集計します
ブレンディング：集計してからくっつきます
クロスデータベース結合：くっついてから集計します
どんなデータがTableauに送られるか？
結合：集計後の結果。つまりvizのマーク数だけ
ブレンディング：それぞれのデータベースからのデータがリンクした項目とviz内のディメンションで集計されたもの
クロスデータベース結合：結合でキー項目として使用されている項目とviz内で使用されている項目全件
パフォーマンスに影響するもの
結合：DBのスペック
ブレンディング：リンクした項目の項目数
クロスデータベース結合：テーブルに入っている行数→結構なデータ量が入ってきてる→抽出の方がよい
参照整合性の仮定
ビューで使用している項目が1つのテーブルだけを対象とするケース
「参照整合性を仮定」を設定することでクエリパフォーマンスを向上
ビューで結合を使わない場合はJOINしないという設定
結合するテーブルにない値はもってこれないので注意
データメニューから設定
抽出vsライブ接続
データエンジンの性能は相対的なもの
データエンジンが比較的速いケース
最適化されていないデータベース
PCファイル形式のデータソース
データエンジンが比較的遅いケース
高速マシンのクラスター
ライブの方が速い場合、抽出の方が速い場合それぞれある
※データエンジンとは：抽出を作成、更新、またはクエリするときに使用されるもの
データの抽出
抽出のパフォーマンスに影響する要因
行数
列数（抽出ファイル作成時に影響）
データ濃度（ = カーディナリティ。ディメンションメンバーの数）
サンプルスーパーストアのカテゴリなら3つ
ディメンションvsメジャー：メジャーの方が速い。正しく使い分けることが大切
ちゃんと整理して、分析に使い分けるものだけを残す
集計された抽出
集計された抽出を集計分析に使用
DWHから負荷分散
明細データはDWHに保持し、ライブ接続
抽出を高速化
表示単位に集計
不要なディメンションメンバーをフィルター
使用していないフィールドを非表示
表示されているディメンションでデータを集計できる。
行数を削ることができる：使っていないものは出さない
編集されないワークブックで有効
次の単位でロールアップ
細かすぎる粒度が要らない場合
計算フィールド
計算
行レベル計算と集計計算
データベース側で集計処理
行レベル計算はスケーラビリティが高い
DBチューニング施策が効果を出しやすい
行レベル計算と集計計算を分割
行レベル計算を1つの計算フィールドに
集計計算を2つ目の計算フィールドに分けた方がよい。
表計算
クエリ結果を受け取り、Tableauが計算処理
計算フィールドよりもTableauの計算負荷が高い
表計算に時間がかかっている場合は、Tableau側でなんとかする必要がある
計算フィールドvs ネイティブ機能
ネイティブ機能は計算フィールドよりも速いことが多い。
ディメンションメンバーのグルーピング
グループが有効
ディメンションメンバーの名前変更
別名の編集が有効
メジャー値のカテゴリ化
ビンが有効
ネイティブ機能は遅くならない工夫がされている
計算フィールド
データ型はパフォーマンスへの影響が大きい
整数はブールより速い
整数・ブールは文字よりも速い
文字列を使わないことが大切
ロジック計算にはブーリアンを使用する
悪い例
IF [DATE] = TODAY() THEN "TODAY" ELSE "NOT TODAY" END
よい例
[DATE] = TODAY()→真偽を別名で編集する
集計値のブール値は別名付けられないが、行レベルのブール値なら別名にした方がよい
文字の検索
CONTAINS()はFIND()より速い
ワイルドカード照合はCONTAINS()より速い
計算フィールドで読むパラメータ
条件式で参照するパラメータ
表示名を利用
整数として計算ロジックで参照
パラメータの判定式に数値を利用できる
日付計算
日付型への変換
文字型への変換は非効率
悪い例
- DATE(LEFT(STR([YYYYMMDD], 4) + "-" + MD(STR([YYYYMMDD], 4, 2) + "-" + RIGHT(STR([YYYYMMDD], 2)))))数値型とDATEADD()の組み合わせ
よい例
- DATEADD('day', [YYYYMMDD]%100-1. DATEADD('month', INT(([YYYYYMMDD]%10000/100)-1, DATEADD('year', INT([YYYYMMDD]/10000)-1900, #1900 -01-01#))))あらゆる形式で日付を表示したい場合、まずはDATEPARSEを使うこと
日付関数
NOW() システムタイムスタンプ
TODAY() システム日付
ロジック計算
ELSEIF != ELES IF
if [region] = "EAST" and [customer segment] = "COMSUMER"
then "EAST-CONSUMER"
else if [region] = "EAST" and [customer segment] <> "COMSUMER"
then "EAST-ALL OTHERS"
end
end改善例
if [region] = "east" and [customer segment] = "consumer" then "east-consumer"
elseif [region] = "east" and [customer segment]<> "consumer"
then "east-all others" endさらに改善
if [region] = "east" then
if [custormer segment] = "consumer" then
"east-consumer"
else "east-all others"
end
end何度も同じ判定を書かない
フィルター
ディメンションフィルター
不連続フィルターは遅い
TableauはDBにクエリを発行し、すべてのディメンションを取得しにいく
不連続の値を全部もってくる必要がある
範囲フィルターは速い
大量の不連続の値を取り込むより速い
データの濃度（カーディナリティ ※1列に入っている値の種類）が高い場合、範囲フィルターの方が速い
保持・除外フィルターは遅い
複雑なWHERE句
インデックスやパーティションが有効に作用する
日付フィルター
不連続日付
ひとつひとつ取得しなければならないのでクエリ結果が遅い
連続日付の範囲指定
範囲で取得できるのでクエリ結果が速い
相対日付はさらに速い
今日や何年前というのはデータではないので速い
クイックフィルター
シートやダッシュボードに表示されているフィルターのこと
項目が表示されたクイックフィルターは遅い
表示する必要のある項目は全て取得しなければならない
複数の値（ドロップダウン）
単一値（ドロップダウン）
数値フィルター
範囲日付フィルター
項目がデータに依存しないクイックフィルターは速い
フィルターのために項目を探す必要がない：値を入れて初めてクエリが走る
- 複数の値（カスタムリスト）
- ワイルドカード照合
- 相対日付フィルター
- 期間を参照フィルター
クイックフィルターの表示項目
2種のクイックフィルターの表示方法
データベース内の全ての値
他のフィルターが変更されたとしても影響しない
関連値のみ
他のフィルターが関連してくる
パフォーマンスvsビジュアル/ナビゲーション
トレードオフの関係
ダッシュボード上のクイックフィルター
大量のクイックフィルターは遅い原因
たくさんのディメンションリストを取得しなければならない...
クイックフィルターの代わりにGuided Analyticsを活用する
異なるディメンションレベルで複数のシートを作る
フィルターアクションを活用する
クイックフィルターの代わりに...
フィルターアクションを活用する
クイックフィルターはない方がいい。→見たくないものを見せている可能性
PROS
複数項目選択をサポート
選択項目はデータに応じてダイナミックに変動
データソース間をまたいでフィルターできる（最近クイックフィルターでもできるけど...）
フィルター用のソースシートからインサイトも得られる
CONS?
設定がちょっと難しい（慣れればどうってことない）
UIがクイックフィルターやパラメータの感じとちょっと違う（むしろ使いやすい）：押せることに気づかない人がいる
ソースシートはデータソースからクエリされる必要がある（クイックフィルターと同じだしむしろリッチに見せることができる）
パラメーターを活用
PROS
フィルター項目表示用のクエリが不要
データソース間を跨いでフィルターできる（最近クイックフィルターもできるけど...）
CONS?
単一値のみしか選択できない
選択項目はダイナミックにならない←もうパラメータアクションとかでて変わった！パラメータ + 計算フィールド = 複雑になりがち...
フィルターの順番を理解する
抽出フィルター
データソースフィルター
コンテキストフィルター
FIXED
セットフィルター
ディメンションフィルター
EXCLUDE/INCLUDE
メジャーフィルター
表計算フィルター
ダッシュボードデザイン
ビュー（シート）
本当に必要なものだけを取得・表示する
不要な"詳細"は外す：詳細に入れている分細かいクエリが発生してしまう
いらない・使っていない計算式は消す
チャート vs クロス集計
行列の少ないマーク表示は表形式のものより速く表示できる
テキストテーブルを描画するには大量のメモリが必要
詳細なクロス集計を表示するにはGuided Analysisを使うこと
クリックすると一部のクロス集計が出てくるようにするなど
不要な地理的役割は設定しない
生成された緯度経度を参照する時間を省く
ダッシュボード
シートやクイックフィルターを少なくする
1シートにつき少なくとも1クエリ
1クイックフィルタにつき少なくとも1クエリ
タブを非表示にする（特にServerの場合）
タブの表示されているビューはすべてプロセスが走る
タブを表示するためにワークブックの構造を把握するプロセスが走る
タブを減らすとパフォーマンスが上がる
次のパラメータを試してみる':tabs=no'
フィルタアクションの"全ての値を除外"
全てのデータを取得する重たいクエリを避ける
フィルター外した時に何も表示しないようにする
サイズを固定したダッシュボード
異なるウィンドウサイズで毎回描画しなければならない
vizQL Serverはユーザーごとにレンダリングを行う
"自動"はキャッシュヒット率が低い
そもそもデザインの問題がある
Tableauが向いていること
向いていること
ビジュアル
インタラクティブ
繰り返し・定期的に行う
迅速
シンプル
ユビキタス
向いていないこと
紙資料
データエクスポート
複雑なクロス集計
Excelレポートの完全置換
a dashboard is a visual display of then most important information needed to achieve or or more objectives, consolidated and arranged on a single screen so the
information can be motitored at a glance
一目見てわかる（一画面に重要な情報がわかりやすくみられる）ことが大切
おわりに
Visual Studio Codeで箇条書きしていたので、
noteに起こすと大変見辛いものになってしまい申し訳ありません。
個人的な備忘録用の記事となりますので、
これから何度も見返してこれらの事項を説明できるように頑張りたいと思います。
Rieko