🫎

Tableauアンチパターン ー Tabelau側で集計を頑張る

に公開

はじめに

Tableau Cloudで作成したダッシュボードを含むデータ基盤を運用していく中でアンチパターンに遭遇したため、記載していければと思います。
初歩的な内容になっているかと思いますので、ジュニアレベルのデータアナリスト、データエンジニアや普段開発業務を行っていないビジネス職の方を想定読者としております。
もし内容に誤りがあれば、優しくコメントいただけますと非常にありがたく存じます 🙇‍♂️

アンチパターン概要 ❌

  • DWH側で集計をほぼ行わずにTableauに抽出を行っている
  • Tableauの計算フィールド等で重たい集計を行っている

何に困るの? 🤔

抽出データサイズが大きくなり、抽出パフォーマンスが悪くなる

当然ですが、Tableau Cloudから接続するテーブル(DWH,DB)のデータサイズが大きいと、その分抽出にかかる時間は増加します。
Tableau Cloudでは抽出時間の制限があり、制限を超過すると抽出が失敗してしまうため安定したダッシュボードの提供が難しくなります。
https://help.tableau.com/current/online/ja-jp/to_site_capacity.htm#ジョブ-ランタイム容量

上記の抽出時間超過を回避する方法は以下の2種類が考えられます。

  • 事前集計してデータサイズを小さくする
  • Tableau Bridgeというアプリケーションを使用して長時間の抽出に対応できるようにする

Tableau BridgeはEC2などに別途インストールして使用する必要があるため抽出時間超過に対応するためにEC2の運用保守作業が発生してしまいます。
基本的にはDWH側で適切な粒度まで集計を行い、データサイズを小さくすることが望ましいと考えます。

ダッシュボード表示の度に大きな計算が行われるため、表示パフォーマンスが悪くなる

キャッシュが効かない初期表示時やダッシュボード上でフィルタ、パラメータの値を変更するたびにTableau Cloud上で大きな計算が実行されてしまい、画面表示が遅くなりやすいです。
上記によりユーザ体験が損なわれ、ダッシュボードの利用率も下がってしまう恐れがあります。

ロジックや指標の管理が大変

Tableau側に計算ロジックを書きすぎると、そのロジックが変更になったときに影響調査や実際の変更作業に時間がかかります。
Tableau Cloud上で直接編集・管理されるダッシュボードのロジックはコードとしてバージョン管理しにくいため、特に注意が必要です。
またダッシュボードごとに指標のズレが生じやすい懸念もあるかと思います。

あるべき姿 🏃‍♂️

DWH側で適切な粒度まで集計を行う

ディメンショナルモデリング等を用いて、データ分析基盤として使用しやすいテーブル設計を行い、適切な粒度まで集計したデータをTableauに提供します。
これにより抽出パフォーマンスと表示パフォーマンスの改善が期待できます。

ただ適切な粒度というのが難しく、ダッシュボード要件によっては集計しすぎてしまうとTableau側での表現に制限が生じてしまうので注意が必要です。

  • 例:DWH側で月毎に販売実績データを集計したが、ダッシュボードで日毎に販売実績を見たいニーズがあった。

共通するロジックや指標はDWH側で管理する

共通するロジックや指標はDWH側で関数的に管理を行うことで再利用性を高め、BI側で気にすることなくデータを利用できる形にします。
dbtなどを使うと実現しやすそうかなと考えています。

これによりロジック管理工数の削減と指標のズレを抑制することが期待できます。

なぜアンチパターンが生まれてしまうのか? 🕵️‍♂️

最初にTableauダッシュボードを作成してからデータ基盤を構築するから

この流れ自体が悪いという訳ではないです。
実際に以前参加した技術カンファレンスでも、上記の流れでの開発は手戻りが少なく、少ない工数で開発できるとして紹介されておりました。
ただTableauダッシュボードを作成するときにTabeau Prepではなく、Tableauのダッシュボード上でゴリゴリに集計ロジックを書いて作成してしまうと、その後データ基盤の作成が非常に大変になります。
結果としてTableau側のロジックは残してデータ基盤側ではあまり集計を行わずに開発を終えてしまうというケースがあるのかなと思いました。

その他

  • データサイズが少ないうちはアンチパターンでも問題が起きずに回ってしまう
  • そもそも案件にデータエンジニアがいない
    • データアナリストがそのまま基盤構築も行うケースだと、アナリストが持っているスキルセットで実装を行いがちなので、Tableau側で複雑な集計を行わせてしまう
  • 短納期 などなど

まとめ ✅

  • Tableau側では計算させすぎないようにしよう
  • 共通するロジック、指標はDWH側できちんと管理しよう
  • データ基盤構築前提の案件では、データエンジニアと協力しながら、先を見越したTableau開発を一緒に進めよう

Discussion