Adaptive Computeとは
一言で言ってしまえば、「自動拡張版のウェアハウス」になります。
何が変わるのか
従来のSnowflakeウェアハウスは、サイズ（XSMALL〜X6LARGE）やマルチクラスタ設定、Query Acceleration Serviceなどを手動でチューニングする必要がありました。
Adaptive Computeはこれらを自動化します。ウェアハウスサイズの概念がなくなり、Snowflake側がクエリの内容に応じて最適なリソースを自動的に割り当てます。
設定パラメータは2つだけ
MAX_QUERY_PERFORMANCE_LEVEL
- 意味：1クエリあたりの性能上限（XSMALL〜X4LARGE）
- デフォルト：２
QUERY_THROUGHPUT_MULTIPLIER
- 意味：同時実行の最大スループット倍率
- デフォルト：2（0にすると、動かないわけではなく無制限になるので注意）
コスト管理の考え方
従来の「ウェアハウスを起動している時間課金」から、クエリベースの従量課金に変わります。ただし既存のリソースモニターやBudgetsはそのまま使えます。
ユースケース別の推奨設定はこんなイメージです。
分析系（レイテンシ重視）
- MAX_QUERY_PERFORMANCE_LEVEL = XLARGE以上、QUERY_THROUGHPUT_MULTIPLIER高め
ETL系（コスト重視）
- MAX_QUERY_PERFORMANCE_LEVEL = MEDIUM/LARGE、倍率は中程度
予算厳しめ
- 両方低め＋リソースモニターで上限管理
現在のウェアハウスへの移行について
既存の標準ウェアハウスからの無停止変換が可能です。
ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'ADAPTIVE';
変換時にMAX_QUERY_PERFORMANCE_LEVELとQUERY_THROUGHPUT_MULTIPLIERは既存のウェアハウスサイズや設定から自動計算されるので、変換直後の手動チューニングは原則不要です。
現時点の制約
- Enterprise Edition以上が必要
- 利用可能リージョンは現在3箇所のみ（US West 2、EU West 1、AP Northeast 1 = 東京）
- X5Large/X6LargeやSnowpark-optimizedウェアハウスとの変換は未対応
- クエリ単位のコスト可視化はGA時に提供予定
個人的感想
メリット
- アナリストや分析エンジニアがウェアハウスサイズを意識せずに使えるサーバーレス的な体験を提供できる。インフラ側の知識がなくても「とりあえず投げれば動く」という運用が実現しやすい
デメリット
- コストの予測可能性が低い。クエリ内容によって課金が変動するため、厳格なコスト管理が求められる環境（たとえば部門ごとのチャージバックや予算上限が厳しいケース）には向きにくい
総評
- 個人的に、メリットもありながら、デメリットも勿論あるなと感じています。
- Adaptive ComputeはBudgetやリソースモニターで「上限」は設定できても、「今月いくらかかるか」を事前に見積もる手がかりが従来より薄い。標準ウェアハウスなら「このサイズを何時間使う」という計算ができましたが、Adaptiveはクエリの複雑さ次第で変わるので、CFOや経営層への説明責任が発生する環境だとハードルが上がりそうと感じました。