🎉

Tableauのパフォーマンス計測の方法と計測結果の読み取り方について

2023/12/09に公開

Tableauのパフォーマンスについて、勉強会をしたので、その内容について書いておきます。

パフォーマンス計測の目的

性能(応答時間)の可視化と評価

応答時間を正確に計測できます。
「評価」するためには事前に目標値の設定が必要ですが、Tableauレポートのパフォーマンスは、データ量・レポートの複雑さ・ネットワーク帯域およびハードウェアのスペック等によって大きく変わるので、あくまで努力目標にするほうが無難かと思います。

問題の特定と最適化の検討

問題が顕在化する前に、表示速度に対する危機感を持ちましょう。
作っていて何か遅いと感じたら、早めに対策ができると思います。

パフォーマンス計測の実施方法

Tableau Desktopの場合

Tableau Desktopでワークブックを開き、「ヘルプ」→「設定とパフォーマンス」→「パフォーマンスの記録を開始」オプションを選択
https://help.tableau.com/current/pro/desktop/ja-jp/perf_record_create_desktop.htm

Tableau Serverの場合

デフォルトでは、パフォーマンスの記録は有効になっていないので、有効化することが必要。

https://help.tableau.com/current/server/ja-jp/perf_record_create_server.htm

有効化した後、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