Tableau Prep Builder のフロー実行が 遅い問題（データベース接続の場合）
私の周りに Tableau PREP Builder (以下 "PREP"）の利用者が増えてきて嬉しいです。 一方で不満の声も多く寄せられています。一番多いのは「遅い」です。 リリースから６年が経ち、随分「速くなった」んですけどね、笑。 利用が広がれば使い方も様々。
・手元の Excel や CSV を 整形・加工したい
・既にあるデータマートや Tableau のデータソースに手を加えたい
・データベースに直接接続してデータマートを作りたい 等々
よって、一言で「遅い」と言っても原因や理由、対処方法は様々です。利用しているパソコンスペックやネットワーク環境にもよりますし、接続先のデータソースにもよります。フロー作成中かフロー実行か？にもよる。データ量（行数、列数）、フローの内容にもよります。
大概はフローの作り方を工夫すれば速くなるのですが、私も「これは遅い！」と思った事例がありました。
「データベースに接続し "PREP" を実行すると 30分位かかります。元データのファクトテーブル (売上トランザクション) は数億行あり、いくつかのマスターテーブルを結合し、計算、集計を行った後、Tableau Cloud にHYPERデータソースを出力してます。出力結果は 100万行くらい」
データベース接続でフロー実行する場合、クエリーはＤＢ側で処理されるので、そんなに時間かかるはずない。そう思っていました。
Tableau Prep Builder は可能だと判断した処理をすべてデータベースで実行させるので、既存のデータベースを利用したままフローの実行で高速パフォーマンスを実現できます。
https://www.tableau.com/ja-jp/products/prep
公式サイトにそう書かれていますし、元Salesforce Japan の Rintaro Sugimura さんもブログに書かれていて、SQLで検証もして下さってました。
今回のケースは、なぜそんなに遅くなるのか？？？
結論を先に申し上げますと、
フロー実行中のクエリーはデータベース側で行われていなかった！ ローカルＰＣで行われていた！
これどういうこと？？？
私も気になっていたのは「可能だと判断した処理」がどの処理か？という点でしたが、データベース接続の場合、"PREP" を使ってこなかったのであまり深く考えていませんでした。質問頂いたケースは、可能だと判断されない処理に該当してしまったのか？．．．
今回は、これを検証してみることにしました。
私のテスト環境です。
【PC環境】
Tableau PREP Builder version: 2024.3.0
CPU: AMD Ryzen 7
RAM: 16GB
OS: Windows 11
最近では、一般的なスペックになってきてると思います。まだ RAM: 4GB or 8GB のパソコンをお使いの方もいらっしゃると思いますが、”PREP” を使われる方は RAM: 16GB以上のパソコンを使用して下さい。”PREP” の推奨システム要件です。実行速度に悩み、嘆き、浪費する時間コストより、RAMのほうがはるかに安いです。
ご質問頂いた内容を検証するために、今回は Snowflake 環境で、Snowflake のサンプルデータを使わせて頂くことにしました。
【環境】
Snowflake Warehouse Size: XS
Wi-Fi Speed: 250Mbps
【サンプルデータ】
Snowflake の TPCH_SF100 を使用します。
ORDERS: 1億5000万行 4.3GB
CUSTOMER: 15万行 1.0GB
NATION: 25行 0.4MB
ER図に表すと以下の関係になっています。
（図の行数は TPCH_SF1で、 SF100はこれの100倍相当です）
【テストシナリオ】
"PREP" からこのテーブルに接続し、国名(NATION.NAME) 別に、ORDERS.TOTAL_PRICE の合計を、CSVファイルに出力する。
やることは簡単な内容ですが、データ量が非常に多いです。ファクトテーブル (ORDERS) の行数は１億５千万行。これを "PREP" でやったらどれ位時間がかかるだろうか？
【フローの作成】
”PREP” から Snowflakeに接続し、先ずはフローを作成していきます。今回は以下のフローを作成しました。
フロー作成中は「遅い」と感じることなく作成出来ました。フロー作成中はサンプリングがかります（テーブルにある全ての行が参照されるわけではない）。自動サンプリングでは、データ接続で39万行、結合後は1万行にサンプリングされていました。
【フローの実行】
さあ実行です。
「この程度のクエリーなら数秒で結果が返ってくるだろう」
そう思って待ちます。
30秒ほど経過して、PCのファンが回り始める…
（出力ダウンロードが始まったか？）
2分経過…
（まだ？ ちょっと遅いよね？）
そして、
これごときで３分以上かかるのは遅い。Snowflake上で SQLで捌いたら数秒。CSV出力したとしても結果は2000行だから秒もかからないはず。
いったいどんなクエリーが実行されてるか？ Snowflake側で確認してみた。
以下３本のクエリーが実行されてた。
SELECT
"N_NAME" AS "N_NAME",
"N_NATIONKEY" AS "N_NATIONKEY"
FROM "SFSALESSHARED_SFC_SAMPLES_SAMPLE_DATA"."TPCH_SF100"."NATION"
（実行時間: 0.1秒）
SELECT
"C_CUSTKEY" AS "C_CUSTKEY",
"C_NATIONKEY" AS "C_NATIONKEY"
FROM
"SFSALESSHARED_SFC_SAMPLES_SAMPLE_DATA"."TPCH_SF100"."CUSTOMER"
（実行時間: 5.0秒）
SELECT
"O_CUSTKEY" AS "O_CUSTKEY",
"O_TOTALPRICE" AS "O_TOTALPRICE",
CAST(DATE_TRUNC('MONTH',"O_ORDERDATE") AS DATE) AS "Year and Month"
FROM "SFSALESSHARED_SFC_SAMPLES_SAMPLE_DATA"."TPCH_SF100"."ORDERS"
（実行時間: 7.2秒）
おいおい、必要なテーブルから必要なフィールド持ってきてるだけかい？
結合も集計も Snowflake側ではやってない！ どうやら各テーブルからレコードをPC側にダウンロードしてきて、結合と集計はPC上でやってるようです（だからPCのファンが勢いよく回ってたのか！）。即ち、この３分２６秒のほとんどは、データの転送にかかってる時間と言える。
今回は、PREP から データベース接続し、数億行のテーブルを加工した場合に起こってる事象の確認までです。Snowflake で検証しましたが、Big Query でも同様でした。じゃどうしたらいいのか？
次回ブログでこれを紐解いていきます。続編をお楽しみに。
https://note.com/hiroakimo/n/ncfdc2728a7d9
（つづく）