動的テーブルのウェアハウスの使用を理解する¶

すべての動的テーブルは、リフレッシュを実行するためにウェアハウスを必要とします。動的テーブルの作成時にこのウェアハウスを指定すると、Snowflakeはすべてのスケジュールされたリフレッシュに自動的に使用します。

動的テーブルのウェアハウスの構成ガイダンスについては、ウェアハウスの構成を調整するをご参照ください。

ウェアハウスのサイズがリフレッシュのパフォーマンスに与える影響¶

ウェアハウスが大きいほどコストが高いとは限りません。多くの場合、ウェアハウスサイズを2倍にすると、1秒あたりのコストは2倍になりますが、ランタイムは半分になります。そのため、より高速なリフレッシュにより、総コストは同様になります。大規模なウェアハウスは、2つの方法でパフォーマンスを向上させます。

メモリ ：リフレッシュでウェアハウスが提供する以上のメモリが必要になると、データはローカルストレージにスピルします。このスピルにより、合計計算作業が増加し、リフレッシュプロセスが遅くなります。ウェアハウスが大きいほど、より多くのメモリが使用でき、スピルを完全に回避できます。
並列処理:ウェアハウスが大きいほど、より多くのタスクを同時に実行できます。多くのパーティションにまたがる大量のデータをスキャンするリフレッシュが最も効果的です。小さいデータセットや連続した操作では、より大きなウェアハウスを使用すると見返りは少なくなります。

ウェアハウスのサイズの詳細については、ウェアハウスサイズをご参照ください。

動的テーブルは、異なるリフレッシュタイプ用に個別のウェアハウスをサポートしています。

WAREHOUSE:定期的なインクリメンタルリフレッシュを実行します。
INITIALIZATION_WAREHOUSE:初期化とフルリフレッシュを実行し、完全なデータスキャンを行うため、通常はよりリソースを大量に消費します。

重要

ALTER DYNAMIC TABLE REFRESH COPY SESSION を実行して手動で更新する場合、コマンドは現在のセッションのウェアハウスを使用します。SnowflakeはこのシナリオでINITIALIZATION_WAREHOUSEを無視します。初期化もです。

この分離により、定期的なインクリメンタルリフレッシュの間にその容量を支払うことなく、リソース集約型の初期化により大きなウェアハウスを使用することができるようになります。デュアルウェアハウスのサポートは、次の一般的なシナリオで役立ちます。

INITIALIZATION_WAREHOUSEパラメーターを設定しない場合、SnowflakeはWAREHOUSEで指定されたウェアハウスですべてのリフレッシュを実行します。