📊

Snowflakeを使ってTableauのマルチファクター分析を試してみた

2024/08/05に公開

Snowflake

Tableau

tech

どうも。カスタマーサクセスマネージャー見習いの玉井です。

TableauのVer2024.2が出ましたが、このバージョンの新機能に「マルチファクター分析」というものがあります。

この機能、普段あまりデータウェアハウス（DWH）に触れない方だと、あまりピンと来ない機能かと思います。また、わかってても試す環境が無い方もいると思います。

というわけで、この記事では、マルチファクター分析という機能を実際に試してみたいと思います。

マルチファクター分析について

私が改めて説明するまでもなく、たくまん氏が以下の記事にてバッチリ解説してくれていますので、そちらをご覧ください。

端的にいえば「複数のファクトテーブルに対して複数のディメンジョンテーブルを結合できるようになった」といったところですが、上記記事にあるように、この機能は背後のデータソース（DBやDWH）がディメンショナル・モデリング（スタースキーマやスノーフレークスキーマなど）を採用している時に真価を発揮すると思います。
あえて強気なことをいうと、ExcelやCSV等のローカルデータに対してはこの機能はそこまで力を発揮しないと思います（Excel等でディメンショナル・モデリングの要領でファイルやシートを分けている現場を個人的に見たことがない）。

やってみた

では、実際にディメンショナル・モデリングされているデータに対して、2024.2のTableau Desktopを接続するとどうなるのでしょうか。実際に見てみましょう。

環境

Snowflake
- Enterprise Edition
Tableau Desktop
- 2024.2.1 Apple Silicon

使用するデータ

サンプルデータ: TPC-DS
こちらは、DWHの性能測定によく使われるデータセットです。Snowflakeにも最初からついてきます（ので便利）。

「TPC-DS は、小売製品サプライヤーの意思決定支援機能をモデル化しています。サポートするスキーマには、顧客、注文、製品データなどの重要なビジネス情報が含まれています。

ちなみに、本家解説には以下のように書かれています。

The TPC-DS schema is a snowflake schema. It consists of multiple dimension and fact tables.

んで、snowflake schemaってのは何かというと…。

スノーフレークスキーマは、スタースキーマを拡張した多次元データモデルで、ディメンションテーブルがサブディメンションテーブルに細分化されたものです。スノーフレークスキーマは、データウェアハウスやデータマート、リレーショナルデータベースの多次元分析を使用した BI（ビジネスインテリジェンス）やレポーティングによく使用されています。
※https://www.databricks.com/jp/glossary/snowflake-schema　より

まあ、とどのつまり、今回のマルチファクター分析を試すにはもってこいのデータソースということです（適当）。

Tableau Desktop 2024.2でやってみる

というわけで、実際にSnowflakeのTPC-DSに接続し、簡単な結合をやってみたのが以下です。

それぞれ（Web、店舗、カタログ）の売上テーブルに対して、日付テーブル（DATE_DIM）とアイテムテーブル（ITEM）を結合しています。
上記の画像に補足を入れるなら以下のようになります。

ディメンションテーブル（DATE_DIMとITEM）が、それぞれ複数のファクトテーブル（画像左側）に結合しています。これが今回のマルチファクター分析で出来るようになった機能です。
それぞれの「売上というファクト」に対して、「日付という切り口（ディメンション）」を用いて横断的に分析したいとき、スタースキーマやスノーフレークスキーマでモデリングされたテーブルだと、上記のように、日付テーブル1つを、それぞれのファクトテーブルに使いまわして結合することで、実現することができます（なんでこの手法が良いのか、というのは後述します）。

※↑めちゃくちゃテキトーなVizですが、日付で3つのファクトテーブルを横断分析しています。

以前のバージョンの場合

ここまで来て、「え、これって前からできへんかったっけ？？」と思われた方はいらっしゃいますでしょうか（何を隠そう、私がそうでした）。というわけで、以前のバージョン（2024.1）で同じことをやろうとしてみました。
結論、できません。

スクショだとすごく伝わりにくいのですが、これは「DATE_DIMをWEB_SALESにも結合させようとしているが、全然ドラッグできない」ところを撮影したものです。UI自体が「ファクトテーブルはいつも1つ！」な前提になってるんですね。まあ要するに2024.2より古いバージョンではマルチファクター分析はしっかり非対応だったんです。
ちなみに、マルチファクター分析を利用したワークブックを古いバージョンで開こうとするとこうなります。

マルチファクター分析を使わない（≒ディメンジョナルモデリングを採用しない）場合

さて、マルチファクター分析機能を超簡易的に試してみたわけですが、ここまで読んでみても「実際現場で役に立つの？」と思われる方も多いと思います。
ここは、逆に「マルチファクター分析を使わないとどうなるか？」という方向から、色々と私個人の考えを述べたいと思います。

専用のデータマート（大福帳）を作るパターン

今回やったような、複数のファクトテーブルを複数のディメンション（テーブル）で色々と切って分析していく…ということを、マルチファクター分析無しでやろうとした場合、まず初めに思いつくのは「DWH側で先に全部結合してしまう（大福帳を作る）」です。
マルチファクター分析はあくまでTableau Desktopの機能であり、「複数のファクトテーブルと複数のディメンションテーブルを結合する」こと自体はDWH側（SQL）でも出来ます。なので、先にDWH側で結合済の大福帳テーブルを作ってしまい、そのテーブルをTableau Desktopで参照すればええやん、というわけですね。
この方法がダメというわけではありませんが、（この方法を使っていく場合）大福帳テーブルのマネジメントにはかなり気合を入れる必要があります。
Tableau Desktopユーザー側からリクエストがあるたびに、DWH側で大福帳（だけでなくあらゆるデータマート）を作るとなると、まず、単純にDWH側で作業する方の負荷が高くなります。Tableau Desktopを使う人がDWHでも作業するという場合でも、（この運用を続ければ続けるほど）DWH上に似たようなテーブル（やビュー）が乱立していまい、ガバナンスがガタガタになっていきます。
であれば、DWHに用意するのは、キッチリと、スタースキーマ等のディメンショナル・モデリングを施したテーブルだけにして、後のことはTableau Desktop側でやるのが平和かと思います。

カスタムSQLを使うパターン

「なるべくTableau Desktop側に寄せたほうがいいなら、カスタムSQLで結合処理を書くぜ」となる方も、もしかしたらいらっしゃるかもしれません。
しかし、個人的に、（今回の要件とか関係なく）カスタムSQLはギリギリまで避けたほうが良いと思っています。SQLに内包されたあらゆる要件やビジネスロジック等がTableauワークブック内に閉じてしまうので、データ分析基盤全体の透明性が失われますし、ワークブックのメンテナンス性もかなり悪くなるからです（Vizをちょっと変更しようとしたら、めちゃくちゃSQLを改修する必要が出てくる等）。
カスタムSQLは極めて特殊な場合のみに利用するようにして、基本的にはTableauのネイティブ機能でデータに接続するのが望ましい…そう考えると、このパターンもあまり推奨したくはないですね。

その他

マルチファクター分析というより、そもそもディメンジョナルモデリング自体のメリットについては、以下の記事が参考になります。

おわりに

冒頭でも言った通り、マルチファクター分析は、ローカルファイルの分析ではそこまで力を発揮しないと思っています。
この機能をきっかけに、DWHやディメンショナル・モデリングが広まってほしいです。