Snowflake Gen2ウェアハウス:速度向上はコストに見合うのか

Gen2ウェアハウスは、基盤となるクラウドプロバイダー(AWS、GCP)が提供する高速なハードウェアを活用しています。さらにSnowflakeは、Gen2ウェアハウス向けに独自のソフトウェア最適化を施しており、追加のパフォーマンス向上とコスト削減を実現しています。ほぼすべてのクエリがハードウェア改善の恩恵を受けますが、特定のworkloadsではソフトウェア最適化によるさらなる効果が得られます。

Gen2 Warehouseは現時点では提供リージョンが限られていますが、近いうちに対応リージョンが急速に拡大すると見込まれます。お使いのリージョンでGen2が利用可能かはこちらでご確認ください。

ハードウェアの改善

SnowflakeのGen2 Virtual Warehouseは、EC2インスタンスや仮想マシンなど、クラウドプロバイダーのコンピュート基盤上で動作します。クラウドプロバイダーは時間の経過とともにインスタンスを新しいハードウェアへとアップグレードしており、たとえばAWSは最近ARMベースのGraviton4プロセッサーを投入しました。Snowflakeは具体的なハードウェア構成を公表していませんが、各プロバイダーの最新世代を採用していると考えるのが妥当でしょう。これらの改善には、ローカルディスクの読み取り高速化、CPU性能の向上、ネットワークスループットの拡大が含まれ、いずれも初期状態でのクエリ性能向上に寄与します。

ソフトウェアの改善

Snowflakeはまた、DMLworkloads(テーブルへのマージ・更新処理)や特定の複雑なクエリを高速化するソフトウェア最適化を複数導入したと公表しています。

後述の分析結果からも分かるとおり、大幅な性能向上の多くはこのソフトウェア改善によるものと考えられます。

Gen2ウェアハウスは新しく高性能なハードウェア上で稼働するため、料金もその分高くなります。下記の料金表(出典)のとおり、Gen2ウェアハウスはAWSとGCPで35%、Azureで25%高額です。

これは移行を検討するうえで誰もが押さえておくべき重要なポイントです。クエリが速くなっても、コンピュート時間の短縮が値上がり分を上回らなければ意味がありません。さらに厄介なのは、多くの利用者がアイドル60秒でウェアハウスを停止する設定にしている点です。つまりアイドル中も高い単価で課金されるため、その分も試算に織り込む必要があります。

損益分岐点の計算

Gen2ではクエリが速く処理される代わりに高い単価で課金されるため、損益分岐点は次の式で求められます。

必要な時間短縮率(%)= 1 -(1 / 価格上昇係数)

Azureでは、ウェアハウス稼働時間を20%短縮できれば損益分岐に達します。

• 1 -(1 / 1.25)= 0.20

AWSでは、稼働時間を25.9%短縮できれば損益分岐に達します。

• 1 -(1 / 1.35)= 0.259

今回のベンチマークはAWSで実施したため、コスト中立を保つには少なくとも25.9%の性能向上が必要です。

1分の最低課金単位を忘れずに

ウェアハウスが起動するたびに、最低60秒分が課金される点に注意してください。たとえばGen1で30秒、Gen2で15秒のクエリの場合、コストは下がるどころか上がってしまいます。性能向上が追加コストに見合うかどうかは、利用シーンを踏まえて判断する必要があります。

理想的なコスト削減シナリオは、実行時間が1分を超え、かつ上記の損益分岐点を上回る短縮率を達成できるworkloadsです。

下の表にこの考え方をまとめています。

新たにGen2ウェアハウスを作成する、または既存のウェアハウスをGen2へ切り替える手順はとてもシンプルです。createまたはalterステートメントにresource_constraintパラメータを指定するだけで完了します。具体例は以下のとおりです。

-- create new
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alter existing
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Snowflakeには、TCP-Hデータセットを収録したサンプルデータベースが標準で付属しています。TCP-Hは、Transaction Processing Performance Councilが分析workloadsのベンチマーク向けに策定したデータセットです。

Snowflakeでは、snowflake_sample_dataデータベースに以下のスキーマが用意されています。

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SFはScale Factor(スケールファクター)の略で、SF10はSF1の10倍のサイズ、以下同様です。今回はSF10、SF100、SF1000のそれぞれに対し、複数の種類のworkloadsを検証しました。

ベンチマークでは主に次の3つのシナリオを取り上げました。

1. dbt:テーブルモデルとテストのみで構成したdbtプロジェクトのビルド。Snowflakeで広く使われているdbtプロジェクトが、Gen2ウェアハウスに適しているかを確かめるのが狙いです。
2. SELECTクエリ:BIツールやユーザー向けアプリケーションで発生する処理を模擬しています。
3. DMLworkloads:Snowflakeへの新規データのマージ・更新は、データエンジニアリングチームで頻発するworkloadsです。更新やマージなど複数のDMLシナリオを検証し、影響を確認しました。

dbt

セットアップ

Snowflake TCPHデータセットを扱う既存のdbtプロジェクトをforkし、更新を加えました。リポジトリはこちらです。

各データセットに対し、サイズの異なるウェアハウスでdbtプロジェクトを制限なく実行し、Gen1とGen2を比較しました。現実的な条件に近づけるため、小さなデータには小さなウェアハウス、大きなデータには大きなウェアハウスを割り当てています。

キャッシュの影響を避け、各テストの結果を個別に残すため、ビルドごとに新しいスキーマを用意しました。1回のビルドでは16のテーブルモデルと43のデータテストを実行します(dbt build --exclude tag:merge-test)。

結果

結果は以下のとおりです。

このdbtプロジェクトでの処理内訳は、約97%がCTASクエリ(テーブルモデル)、約3%がdbtテスト(シンプルなSELECTクエリ)です。

この結果を踏まえると、本プロジェクトのdbtテーブルモデルでは、35%の追加コストを正当化できるだけの性能向上が常に得られるわけではないことがわかります。

もう一点見逃せないのは、4XL Gen2ウェアハウスのコールドスタート時間が非常に長く、5分を超えるケースもあった点です。一方、Gen1の4XLはほぼ即座に起動しました。ウェアハウスの起動時間は課金対象ではないため、結果からは除外し、dbt実行前にウェアハウスを事前起動しています。夜間に実行するETLジョブではプロビジョニング時間が問題になることはほぼありませんが、念のため付記します。

シンプルなSELECTステートメント

BIツールやユーザー向けアプリケーションで発生する処理を再現するため、TPCHデータセットのサンプルSELECTクエリを実行しました。実行したクエリは表内にリンクしています。結果は以下のとおりです。

「Select, Aggregate」クエリはこちらです。

「Select, join, aggregate」クエリはこちらです。

いずれのSELECTステートメントも大きな性能向上を示し、秒単位のコストで見ればGen2で削減効果が得られました。ただし、ユーザー向けクエリは高速応答が求められるため、ここでSnowflakeの最低課金単位という壁にぶつかります。クエリの実行時間が60秒未満だったり、ウェアハウスのアイドル時間が長くなったりする場合(BIツールではよくある状況です)は、速度を最優先したい・追加コストを許容できるといった事情がない限り、引き続きGen1が無難な選択です。

もう一つ注目すべきは、Gen2ウェアハウスがウェアハウスサイズのダウンサイジングという選択肢を生む点です。たとえばGen2でクエリ時間が半分になったものの、アイドル時間のコスト増で総コストが上がってしまう場合、ウェアハウスサイズを半分に落とせば同等の性能を低コストで実現でき、結果的に大きな節約につながる可能性があります。

DML:大規模テーブルの更新

本セクションのupdateはすべて、update table <tbl> set column <col> = value形式のシンプルな更新です。注意点として、1カラムだけを更新しても、Snowflakeは該当行のマイクロパーティション全体を書き直す必要があります。そのため、Snowflake側の「作業量」という観点では、次の2つのコマンドは実質的に同等です。

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

ここでは次の3つのシナリオを実行しました。

• where句なしで60億行を更新
• 同じテーブルに対する選択的更新で、240万行(全体の0.04%)のみを更新
• 1行のみの更新
• SQLステートメントはこちらにあります。

結果はかなり明確で、Gen2ウェアハウスはフィルター付きupdateで非常に優れた性能を発揮しています。Snowflakeが導入した特定のソフトウェア最適化が効いていると考えられます。

コスト差が-79%となったクエリをもう少し掘り下げ、これほど大きな改善が出た理由を探ってみましょう。

スクリーンショットを見ると、書き込みバイト数が99%も減少しています。

(0.16 GB – 16.56 GB)/ 16.56 GB = -99%

DML:mergeクエリ

セットアップ

先ほどのシンプルなupdateとは異なり、Mergeクエリはソース側のレコードに基づいてターゲット側のレコードを更新します。joinでマッチしたレコードを更新し、新規レコードを挿入する形です。

n%の行を更新するmergeクエリはdbtのインクリメンタルモデルです。dbt run -s pre_merge+を実行し、22行目の行数制限フィルタを編集することで実行できます。データの一部のみが新規・更新となる現実的なインクリメンタル処理のシミュレーションです。更新するデータの割合を変えるには、この行を編集し、当該モデルと下流のインクリメンタルモデルを実行します。

「Merge, all rows updated」のタスクはこのクエリに対応し、全行を更新します。

なお、SF10データセットは約6,000万行、SF100は約6億行ある点に留意してください。

結果

上記の結果から、少数のレコードのみを更新するmergeクエリの方が、全件更新のmergeよりも大きな性能改善を得られることが明確に示されました。

その根拠はクエリプロファイルにあり、いくつか興味深い点が読み取れます。まず、ネットワーク通信が41%から13%へと大幅に減少しています。これは書き込みバイト数が1.6GBからわずか4.65MBへ激減したことが要因と考えられます。Snowflakeが圧縮を改善した、あるいはネットワーク上のデータ転送方法を最適化した可能性を示唆しています。どちらのクエリも更新対象は100行のみであることから、Gen2にはデータ書き込みを効率化する固有の最適化が含まれているという見立てを裏付ける結果と言えます。

例外的なケース

1件だけ異質な結果(下から2行目、削減率はわずか1%)が見られた点は非常に興味深いものです。Snowflakeのプロファイル上では書き込みバイト数が99.5%減少しているにもかかわらず、このような結果になっているからです。要因としてはS3のスロットリングやネットワーク速度などが考えられます。

これまでの結果はすべて秒単位で示しています。しかし冒頭で触れたとおり、クエリ実行後のアイドル時間も忘れてはいけない要素です。シンプルなシナリオで試算してみましょう。下の表では、Gen2がGen1の半分の時間でクエリを完了すると仮定しています。かなり楽観的な前提ですが、話を単純にするためです。さらに、自動停止が60秒に設定されているとすると、次のようになります。

当然ながら、workloadsの実行時間が長くなるほどこの影響は小さくなります。下の表は、クエリ実行時間が伸びるにつれて影響がどの程度緩和されるかを示しています。

この現象は次の式で表せます。

% アイドル時間 = [自動停止までの秒数] /([クエリ時間] + [自動停止までの秒数])

性能最適化を重視するSnowflakeのお客様にとって、アイドル時間の影響は、データエンジニアがクエリのチューニングに費やす工数や、その間に消費される追加クレジットのコストに比べれば微々たるものです。とはいえ、検討に含めておくべき要素であることに変わりはありません。

集計結果の読み方

集計結果は、各カテゴリーやウェアハウスサイズで実行したクエリ数の影響を強く受けるため、そのまま受け取ると誤解を招きやすい点に注意が必要です。また、同じカテゴリー内でも個別のクエリが集計値と大きく異なる結果になり得ますが、その差は集計値には現れません。

とはいえ、集計データはコストとパフォーマンスのばらつきを把握するうえで依然として有用です。

下記に、これまでのテスト結果を確認しやすく統合したものを示します。

ここから得られる教訓は、Gen2が自社のユースケースでどう振る舞うかは必ず自分たちのデータで検証してみるべき、ということに尽きると思います。クラウドの多くの要素と同様、どのツールが普遍的に安く優れているかを断定するのは難しく、結局はユースケース次第です。

そのうえで、いくつか重要なポイントを整理しておきます。

• クエリを高速化し、多くの場合はコスト削減にもつながる「ゼロ工数のスイッチ」が手に入った。
• シンプルなSELECTクエリは今回のテストでもトップクラスの結果を示し、26%のコスト削減を実現した。
  • ただし、稼働率の低いウェアハウスで最低課金単位未満の短いクエリを実行する場合、かえって割高になる可能性がある。
  • とはいえ、全社のビジネスユーザー向けにゼロ工数で20%の性能向上が得られるなら、10%(たとえば年間1万ドル増)のコスト増は十分に妥当な投資と言えるケースもあります。同等の最適化を自前で実装するのにかかる時間と比べて、トレードオフを検討してみてください。
• Gen2は、対象を絞ったupdateや、フルテーブルスキャンを伴うシンプルなSELECTクエリにおいては、Gen1を圧倒的に上回る。
• 一方、平均的なdbtテーブルモデルでは必ずしも安くならない。「create or replace table as」で全パーティションを書き直すことが原因と考えられる。ただし、mergeステートメントを使うインクリメンタルモデルでは、より安く・速くなる可能性がある。

Gen2ウェアハウスが特に効果を発揮するのは、現在のウェアハウスのリソースが逼迫していて、たとえばMediumからLargeへのアップサイズを検討しているケースだと考えています。クレジット単価が100%増となるLargeに上げるのではなく、まずはGen2のMediumに切り替え、単価増を35%にとどめるアプローチです。個人的にも、Gen2は各ウェアハウスサイズ間の「半段階分のアップグレード」のような存在として捉え始めています。

• 全体の削減率は2%だったが、これは最大規模の2つのworkloadsに大きく引っ張られている。
• クレジット消費量上位2件を除外すると、合計削減率は7%となる。

今回のベンチマーク結果についてSnowflakeの担当者と話した際、印象に残った一言があります。「ベンチマークが教えてくれるのは、そのベンチマーク自体がどれだけ速く走ったかだけだ」。本番workloadsへの影響を考えるうえでは、考慮すべき要素が数多くあります。

• 並行性の不在:ベンチマークの多くは、並行性が問題にならない稼働率の低いウェアハウスで実行されている。
• 一時的なノイズ:同じクエリを同じ条件で実行しても、基盤クラウドの自然なばらつき(一時的な問題、AWS S3のスロットリングなど)により、別の時間に実行すれば±10%程度の差が出ることがある。

自社環境での実際のコスト影響を把握するには、対象を絞ったworkloadsで1週間程度Gen2を試運用してみることをお勧めします。

SELECTでは、より堅牢で科学的なベンチマーク手法の構築を目指しています。Pythonで同じクエリを、同じデータセットに対して複数のウェアハウスで何度も実行する、というシナリオを想定しています。サンプルサイズを大きくすることで、個々の結果が平均に与える影響を抑えられます。続報にご期待ください。

Gen2ウェアハウスを使ってみた感想もぜひお聞かせください。興味深い発見やコスト削減の事例があれば、お気軽にご連絡いただければ嬉しいです。

Jeffはデータ&アナリティクス分野のコンサルタントで、インサイトの自動化やデータを活用したビジネスプロセス制御に15年以上の経験を持ちます。技術面ではSnowflake + dbt + Tableauを得意とし、業界面では公益事業、臨床試験、出版、CPG、製造業での実績があります。お問い合わせはお気軽に:[email protected]。

Ian Whitestone・SELECT 共同創業者兼CEO

IanはSELECTの共同創業者兼CEOです。SELECTは、Snowflakeのコスト管理と最適化を提供するSaaSプラットフォームです。SELECTを立ち上げる前は、ShopifyとCapital Oneで6年間にわたり、フルスタックのデータサイエンス&エンジニアリングチームを率いていました。Shopifyでは、データウェアハウスの最適化とコスト可視化の取り組みを牽引しました。