Tableau × BigQuery　ダッシュボードのパフォーマンスを改善する

はじめに

ダッシュボードが「なんとなく重い」と感じたとき、その原因がどこにあるかを特定せずに対策を打っても効果は限定的です。

遅さの原因は大きく2つに分類できます。

• BigQuery側：クエリの実行に時間がかかっている

• Tableau側：データを受け取った後の描画・レイアウト計算に時間がかかっている

Tableauにはパフォーマンスレコーディングという機能があり、操作中の各処理にかかった時間を可視化できます。

まずこの機能で「どこが遅いか」を特定することが、改善の第一歩です。

パフォーマンスレコーディングとは

Tableauが内部で行っている処理を時系列で記録し、ワークブック形式で出力する機能です。

起動方法は「ヘルプ」→「設定とパフォーマンス」→「パフォーマンスの記録を開始」です。

操作が終わったら「パフォーマンスの記録を停止」をクリックすると、結果が別ワークブックとして自動的に開きます。

結果の見方

出力されるワークブックには複数のシートが含まれています。主に使うのは以下の2つです。

Timelineシート

処理が時系列で並び、どのタイミングでどの処理が走ったかを確認できます。

Events Sorted by Timeシート

処理時間が長い順に並んだ棒グラフです。ボトルネックを一目で特定できます。

記録される主な処理カテゴリは以下の通りです。

棒が最も長い処理が、ダッシュボードの表示のボトルネックです。

Executing Query が長ければBigQuery側、Rendering が長ければTableau側の問題と切り分けられます。

検証：ライブ接続 vs 抽出接続

同じダッシュボードでフィルター操作を行い、接続方式の違いによるパフォーマンスの変化を計測しました。

ライブ接続の場合

Executing Query が最大 1.21秒 かかっており、上位をすべて占めています。

Rendering は最大でも 0.04秒 と非常に短く、遅さの原因はBigQueryへのクエリ実行にあることが明確です。

抽出接続に切り替えた場合

Executing Query が最大 0.03秒 まで短縮されました。X軸のスケールが0〜2.4秒から0〜0.042秒に変わっていることからも、全体の処理時間が大幅に改善されていることがわかります。Rendering との差もほぼなくなり、BigQuery側のボトルネックが解消されたことが示されています。

比較まとめ

Renderingがほぼ変化していない点が重要です。接続方式を変えてもTableau側の描画処理は変わらないため、2つのボトルネックが独立していることがこの比較から確認できます。

抽出接続のトレードオフ

抽出接続はパフォーマンス改善に非常に効果的ですが、データがリアルタイムに更新されないというトレードオフがあります。

リアルタイム性が必要な場合は抽出接続が使えないため、ライブ接続のままBigQuery側の設計で対処する必要があります。

次のセクションでは、ライブ接続を維持したままExecuting Queryを短縮する2つのアプローチを紹介します。

ライブ接続のままExecuting Queryを改善する

ライブ接続を維持したままExecuting Queryを短縮するには、BigQuery側のテーブル設計を見直すことが有効です。

ここでは代表的な2つのアプローチを紹介します。

1. データマートの活用

Tableauが発行する集計クエリを、あらかじめBigQuery側で計算済みのマートテーブルに向けることで、クエリの処理量を削減できます。生テーブルに対して毎回集計クエリを走らせる代わりに、必要な集計をBigQuery側で事前に済ませておく設計です。

今回は以下のマートテーブルを作成しました。

Tableauの接続先をこのマートテーブルに変更し、同じ操作でパフォーマンスレコーディングを取得すると、Executing Query の時間が短縮されます。

ここでは確認のため、BigQueryのコンソール画面から同じクエリを実行してみます。

生テーブル接続時のパフォーマンス

マートテーブル接続時のパフォーマンス

事前に集計されたマートテーブルの方が、ジョブ完了までにかかる時間が短いことが確認できました。

小規模なサンプルデータのため、ほとんど差はありませんでしたが、行数・カラム数が多い本番環境のテーブルほど、マートへの事前集計による改善効果は大きくなります。

▼スロット時間ではなく期間で比較する理由

スロット時間はBigQueryが並列処理に使った全スロットの合計時間であり、複数のスロットが同時に動いた場合は実際の経過時間より大きな値になります。ユーザーが体感する「待ち時間」に近いのは、処理の開始から完了までの実際の経過時間である期間です。そのため本記事では期間を比較の指標として使用します。

2.データ型の統一

日付カラムが文字列型で保持されている場合、WHERE句で日付を絞り込んでも全件スキャンが発生します。

BigQueryはテーブルを日付の区画ごとに分けて保存していますが、文字列型では「どの区画を読めばよいか」を事前に判断できず、すべての区画を読み込んでから絞り込む動作になるためです。DATE型に統一することでこの問題が解消され、Executing Queryの短縮につながります

Tableauのフィルターで日付を絞り込む操作を行った場合を想定して、接続先テーブルのデータ型によって実行時間がどう変わるかを比較しました。

文字列型の日付に対してフィルターする場合

DATE型の日付に対してフィルターする場合

DATE型を使用してパーティションを有効化した方が、ジョブ完了までの時間が短いことが確認できました。

データ型の問題はテーブル設計の段階で埋め込まれるため、後から気づきにくい点に注意が必要です。

マートテーブルを作成する段階で型を統一しておくことが、根本的な対策になります。

▼ノード構成が異なる理由

文字列型日付テーブルではデータソース→Outputの2段構成になっています。

これはWHERE句の CAST(オーダー日 AS DATE) という条件がパーティションキーとして認識されないため、BigQueryがパーティションの絞り込みを行わずに全件をそのまま後段に渡していることを示しています。

一方、DATE型・パーティションありテーブルではデータソース→S00: Input→Outputの3段構成になっています。S00: Inputはフィルタリング処理にあたり、WHERE句の日付条件をパーティションキーとして認識した結果、該当期間のパーティションだけを読み込んで後段に渡しています。ノードが1つ多いのは余分な処理ではなく、不要なデータを早い段階で除外していると解釈できます。

まとめ

パフォーマンスレコーディングを使うと、「なんとなく遅い」という感覚を処理カテゴリと数値で特定できます。重要なのは、ボトルネックを特定してから対策を打つという順番です。

Executing Query が長い場合はBigQuery側に原因があります。抽出接続への切替が最も効果的ですが、リアルタイム性が必要な場合はマートテーブルの活用やDATE型への統一・パーティション設定といったBigQuery側の設計改善が有効です。

一方、Rendering が長い場合はTableau側に原因があります。集計レベルを上げる・表示件数を絞るといった方法でマーク数を減らすことが改善につながります。

いずれの対策も、パフォーマンスレコーディングで改善前後を比較することで、効果を定量的に確認できます。

おわりに

ダッシュボードが重いと感じたとき、「BigQueryのクエリが遅いのか、Tableauの描画が遅いのか」を切り分けることが改善の起点になります。パフォーマンスレコーディングはその切り分けを数値で行える手段であり、感覚に頼らない改善サイクルを作る上で非常に有効なツールです。

BIダッシュボードの設計・運用では、Tableau側の操作だけでなくBigQuery側のテーブル設計まで意識することが、快適なダッシュボード体験につながります。

この記事はData Saberコミュニティ活動の一環として執筆しました。