【実行時間39%減】Snowflakeの新機能: Generation 2 Standard WarehouseとGen1をdbtで性能比較した

はじめに

CARTA HOLDINGSのfluctでデータエンジニアをやっているyanyanです。先日のSnowflake Summit 2025ではsnowflakeの新しい機能がたくさん発表されました。今回はその中のGeneration 2 Standard Warehouse (以降Gen2と表記します。) が東京リージョンでGAしていたので早速試してみました。

この記事では、fluctが取り扱っている本番の広告配信データを利用したdbtによるデータ加工でGen1とGen2の性能比較を行いました。結果的にクエリの実行時間が約39%削減され、クエリの実行時間がウェアハウスの消費クレジット量に影響するsnowflakeの課金体系ではコストの削減効果も見込めることがわかりました。

Generation 2 Standard Warehouse とは

Gen2は、Snowflakeの新世代コンピュートエンジンです。既存のGeneration 1 Standard Warehouse (以降Gen1と表記します。) からハードウェア・ソフトウェアの両面で改善が施されました。現在一部のリージョンでGAとなっており、AWS東京リージョンでは使えるようになっています。 Gen2に関する詳細は公式ドキュメントを読んでみてください。

ウェアハウスのコスト

ウェアハウスの課金体系はウェアハウスの起動時間 x 消費するクレジットの単価です。消費するクレジットの単価はウェアハウスの種類とサイズごとに決められています。

Gen1とGen2の差分として、先ほど述べた性能の向上だけではなくコスト面での差分もあります。例えば利用しているクラウドプロバイダーがAWSの場合、Gen1と比べてウェアハウスの起動時間で消費するクレジット単価が1.35倍になっています。そのため、クエリのパフォーマンスの向上だけでなくウェアハウスにかかるコストがどう変化するのかというのも気になってきます。

SELECT.devの記事によると、AWSの場合は25.9%のウェアハウス利用時間削減が損益分岐点であると書かれています。

fluctのデータについて

fluctはメディア向けの広告配信プラットフォームです。広告配信ログを集計し、レポーティングや分析、配信制御に活用しています。

データ基盤について

fluctのデータ基盤は以下のような構成になっています。

snowpipeによってロードされてきた未加工のデータを、dbtによって加工しレポーティングなどで利用可能な形にしていきます。今回はこのdbtによるデータ加工部分でGen2を利用した際に実行時間がどれほど削減されるかを見ていきます。

fluctのデータ加工の特徴

広告配信のログは量が膨大で逐次的にロードされてくるという特徴があります。dbtの実行のたびに全てのログをスキャンしていては膨大な時間とコストがかかってしまうため、1時間を最小単位として指定された期間にロードされたログのみを加工対象とし、永続化されたモデルは基本的にincremental modelを採用しています。加工対象となった期間のデータをdelete insertすることで冪等性を担保しています。

また、ログの種類によってデータ量が大きく異なるため、dbtのmodelに対してウェアハウスサイズを動的に指定できるような仕組みを導入しています（参考: https://zenn.dev/pei0804/articles/dbt-snowflake-dynamic-warehouse ）。この工夫により、処理対象のデータ量に応じて適切なコンピューティングリソースを割り当てることが可能になっています。

検証内容

検証目的

Gen1 と Gen2 の実行時間を比較
ウェアハウスサイズごとの性能差を把握
コスト削減効果の見積もり

検証方法

今回は、ウェアハウスサイズはそのままに、dbtで利用するウェアハウスの世代をGen1/Gen2に変更した際の実行時間変化を検証しました。

対象: 社内のデータ変換処理プロジェクトでの dbt runコマンドの実行
実行内容: 特定のモデル群を対象とした期間指定でのバッチ処理
dbt runで使われているウェアハウスサイズ: XS, M, L

今回は1時間の範囲でロードされた広告ログの加工を行います。ログの種類によりますが最大で約2億レコードが加工対象となるものもあります。

実行時間の計測方法

Elementaryの model_run_results テーブルを活用：

Elementaryについては過去記事を参照
dbtの各モデル実行詳細がテーブルとして記録
Snowflakeのquery\_historyと合わせてウェアハウスサイズごとの比較が可能

Gen2 の作成

参考: https://docs.snowflake.com/en/user-guide/warehouses-gen2\#examples

CREATE WAREHOUSE時にRESOURCE_CONSTRAINT = STANDARD_GEN_2を追加するだけで作成できます。既存のGen1をALTER WAREHOUSEでGen2に変更することも可能です。

CREATE OR REPLACE WAREHOUSE test_gen2_xs
  RESOURCE_CONSTRAINT = STANDARD_GEN_2
  WAREHOUSE_SIZE = XSMALL;

CREATE OR REPLACE WAREHOUSE test_gen2_m
  RESOURCE_CONSTRAINT = STANDARD_GEN_2
  WAREHOUSE_SIZE = MEDIUM;

CREATE OR REPLACE WAREHOUSE test_gen2_l
  RESOURCE_CONSTRAINT = STANDARD_GEN_2
  WAREHOUSE_SIZE = LARGE;

検証結果

全体的な性能向上

model_run_resultsモデルを利用してモデルごとの実行時間の統計値を出しました。

WAREHOUSE_GENERATION	TOTAL_SECOND	AVERAGE_SECOND	MAX_SECOND	MIN_SECOND	FIRST_QUARTILE	THIRD_QUARTILE
Gen1	4484.016970158	8.365703303	442.7701509	0.4406850338	0.8468532562	3.725326061
Gen2	2739.823887587	5.111611731	274.513495922	0.4664828777	0.8273079395	2.80370307

dbt run実行全体でかかった時間がTOTAL_SECONDになっていて、その改善率を見ると (4484 - 2739) * 100 / 4484 = 38.9161462979 で約39%実行時間を削減できました。

Warehouse サイズ別詳細結果

model_run_resultsとquery_historyを合わせて、ウェアハウスサイズごとの実行時間の統計値を出してみました。

WAREHOUSE_GENERATION	WAREHOUSE_SIZE	TOTAL_SECOND	AVERAGE_SECOND	MAX_SECOND	MIN_SECOND	FIRST_QUARTILE	THIRD_QUARTILE
Gen1	Large	1979.889523029	68.272052518	442.7701509	2.276962042	11.333432674	117.453224897
Gen2	Large	924.703825712	31.886338818	194.794121981	2.336107016	9.138259888	43.670960903
Gen1	Medium	6.738227844	6.738227844	6.738227844	6.738227844	6.738227844	6.738227844
Gen2	Medium	4.851819992	4.851819992	4.851819992	4.851819992	4.851819992	4.851819992
Gen1	X-Small	2270.932966471	8.537341979	430.716653109	0.9115920067	1.715276003	4.686035156
Gen2	X-Small	1588.962245941	5.973542278	274.513495922	0.8415699005	1.380925894	3.605362892