Tableauのパフォーマンス計測の方法と計測結果の読み取り方について
Tableauのパフォーマンスについて、勉強会をしたので、その内容について書いておきます。
パフォーマンス計測の目的
性能(応答時間)の可視化と評価
応答時間を正確に計測できます。
「評価」するためには事前に目標値の設定が必要ですが、Tableauレポートのパフォーマンスは、データ量・レポートの複雑さ・ネットワーク帯域およびハードウェアのスペック等によって大きく変わるので、あくまで努力目標にするほうが無難かと思います。
問題の特定と最適化の検討
問題が顕在化する前に、表示速度に対する危機感を持ちましょう。
作っていて何か遅いと感じたら、早めに対策ができると思います。
パフォーマンス計測の実施方法
Tableau Desktopの場合
Tableau Desktopでワークブックを開き、「ヘルプ」→「設定とパフォーマンス」→「パフォーマンスの記録を開始」オプションを選択
Tableau Serverの場合
デフォルトでは、パフォーマンスの記録は有効になっていないので、有効化することが必要。
有効化した後、URLにパラメーターをつけることで計測が可能に。
セッション ID (iid)の直前、表示 URL の末尾に「:record_performance=yes&」 と入力
～/sheet0?:record_performance=yes&:iid=2
Tableau Cloudの場合
現時点では計測できないようです。
パフォーマンス記録ワークブック
「Performance Summary」と「Detailed Views」の2つのダッシュボードができます。
結果に記載されている内容は以下のとおりです。
| 表示項目 | 内容 | 対応策 |
|---|---|---|
| Computing layouts | レイアウトの計算 | ワークブックの簡素化を検討 |
| Connecting to data source | データ ソースへの接続 | ネットワーク問題またはデータベース サーバー問題が原因 |
| Compiling query | クエリのコンパイル | クエリのコンパイル時間が長い場合、生成されるクエリが複雑であるということ。ワークブックが複雑であることに起因（フィルターの数が多い、計算が複雑）。複雑な計算の例としては、長い計算、LOD 計算、ネストされた計算、など。 |
| Executing query | クエリの実行 | ライブ接続の場合：DBの最適化、抽出の検討。抽出の場合：フィルターの使用、コンテキスト フィルターの使用。 |
| Generating extract | 抽出の生成 | 抽出フィルターの検討。 |
パフォーマンスの改善手法
パフォーマンスが出ない原因はおおよそ以下のとおりかと思います。
パフォーマンス計測からどこが問題かを確認して、対策を練っていくことになります。
- データ量が多い
- ビジュアライゼーションが複雑
- 計算クエリが複雑
- ネットワークとハードウェア
データ量が多い時の改善策
当たり前ですが、データ量が多いとパフォーマンスは厳しいです。
クエリの実行に時間がかかっている場合は、データの持ち方を工夫してみます。
データを抽出する
これで解決するなら苦労しないです。。。
抽出時に、フィルターなどをかけて抽出するほか、使用しないカラムは取得しないなどの方法もあります。
データ量を減らす
データベース側で集計済みのテーブルを作成する、カスタムSQLを使って、集計済みのデータにアクセスする、など、データを集計して、データ量を減らすようにします。
これにより、データソースをサマリと明細の2つにわける、などの対応もあるかもしれません。
インデックス、パーティションを設定する
最後は、ライブ接続でデータベースのパワーを使ってパフォーマンスを上げることを検討します。
その場合は、テーブル側の設計にも考慮が必要です。
ビジュアライゼーションが複雑な場合の改善策
ダッシュボードの要件を適切に設定することが重要です。
1ダッシュボードに情報を盛り込みすぎない
見るだけのダッシュボードと、情報を深掘りするダッシュボードでは必要なデータの切り口や粒度が異なります。
また、粒度が異なるものを同じダッシュボードに配置すると、可読性が悪くなったり、どのVizに焦点を当てるべきかが不明確になります。
ダッシュボードの目的を再確認し、ダッシュボードを分ける等の対応を検討します。
適切なチャートを選択する
特にクロス集計など、表示する要素（データ）が多いものは取得する情報量が多い＝時間がかかることになります。
トップページにいきなりスクロールバー付きの詳細クロス集計があると遅くなるので、チャートがそこにある意図を明確にしたいです。
ツールヒント内Vizを使う
画面には詳細を表示せず、ツールヒントVizで明細を出す、という方法もあると思います。
とはいえ、ツールヒントVizは制約も多いので、使い過ぎには注意です。
フィルターの調整
フィルターを実行するたびにデータを再取得することになるため、フィルターの数を減らしたり、フィルターした結果の表示方法に工夫します。
初期表示するデータを絞ったり、TOP Nフィルタなどで表示する行数を減らす、などや、
フィルターに適用ボタンを設置したり、パラメータとパラメータアクションを使った検索条件の一括適用なども行って、体感時間を減らすようにします。
計算クエリが複雑
Tableauが作成したSQLは冗長になっていることもあり、計算式を工夫すれば回避できることもあります。
パフォーマンス計測で得られたクエリを、データベース側で実際に実行してみたり、ライブ接続ならデータベース側の実行ログを確認してみても良いかと思います。
SQLの実行計画を確認（EXPLAINなど）してみると、どこに問題があるかわかることもあります。
いくつか実際にあった事例です。
CONTAINS関数を使用しない
CONTAINS関数は、Tableauによって、REGEXP関数に変換されています。
であれば、と、計算フィールド側でEGEXP関数に変えたところ、実行時間が半分になりました。
さらに、カスタムSQLを使って、データベース側でEGEXP関数を使って整えたものを結合すれば、実行時間は約10分の1になりました。
CONTAINS関数は便利ですが、大量データを扱う時は気をつけたいです。
WINDOW関数を使用するときは、計算フィールドを分ける
計算フィールド内にWINDOWS関数を書くのではなく、WINDOWS関数を使った計算フィールドを別で作っておいて、それを参照するようにしたところ、早くなったことがあります。
おそらく、1行ずつWINDOW関数を実行しているものが、WINDOW関数実行済みのデータを結合する、に変わるのではないか、と推測しています。
まとめ
ダッシュボードをサンプルデータなど小さなデータで作っていて、いざ実データで動かそうとすると、パフォーマンスが全然出ない！という現象に遭遇することがあるかもしれません。
そんな時に、どう調べて、どう対応するか、少しでも役立てばと思います。
Discussion