ウェアハウスの概要¶
クエリ、およびテーブルへのデータのロードを含むすべての DML 操作には、ウェアハウスが必要です。ウェアハウスは、標準タイプまたはSnowpark用に最適化されたタイプのいずれかとして定義されることに加えて、サイズと、ウェアハウスアクティビティの制御と自動化に役立つように設定できる他のプロパティによって定義されます。
ウェアハウスはいつでも開始および停止できます。また、実行中であっても、ウェアハウスによって実行される操作の種類に応じて、多少の計算リソースの必要性に対応するために、いつでもサイズを変更できます。
ウェアハウスサイズ¶
サイズは、ウェアハウス内のクラスターごとに使用可能なコンピューティングリソースの量を指定します。Snowflakeは、次のウェアハウスサイズをサポートしています。
ウェアハウスサイズ |
クレジット / 時間（Gen1ウェアハウス） |
クレジット / 秒（Gen1ウェアハウス） |
注意 |
|---|---|---|---|
XS |
1 |
0.0003 |
Snowsight で作成され CREATE WAREHOUSE を使用するウェアハウスのデフォルトサイズ。 |
S |
2 |
0.0006 |
|
中 |
4 |
0.0011 |
|
L |
8 |
0.0022 |
|
XL |
16 |
0.0044 |
Classic Console を使用して作成されたウェアハウスのデフォルトサイズ。 |
2XL |
32 |
0.0089 |
|
3XL |
64 |
0.0178 |
|
4XL |
128 |
0.0356 |
|
5XL |
256 |
0.0711 |
Amazon Web Services（AWS）およびMicrosoft Azureリージョンで一般公開され、 US 政府リージョンではプレビュー段階にあります。 |
6XL |
512 |
0.1422 |
Amazon Web Services（AWS）およびMicrosoft Azureリージョンで一般公開され、 US 政府リージョンではプレビュー段階にあります。 |
前テーブルの数字は、Snowflake標準ウェアハウスの第一世代（Gen1）を参照しています。新しいGen2ウェアハウスの使用情報については、 Snowflake第2世代標準ウェアハウス を参照してください。第 2 世代標準ウェアハウスのクレジット消費に関する情報は、 Snowflake Service Consumption Table を参照してください。Gen2ウェアハウスはまだすべてのクラウドサービスプロバイダーやリージョンで利用可能ではなく、標準ウェアハウスを作成する際のデフォルトではありません。
ウェアハウスのサイズを変えずにSnowflakeウェアハウスの容量を拡張するもう一つの方法は、マルチクラスタ ウェアハウスを使用することです。この機能の詳細については、 マルチクラスターウェアハウス を参照してください。
大規模なウェアハウスサイズ¶
大規模なウェアハウスサイズ5X-Largeおよび6X-Largeは、すべてのAmazon Web Services（AWS）およびMicrosoft Azureリージョンで一般公開されています。
大規模なウェアハウスサイズは、 US 政府リージョンでプレビュー中です（ARM での FIPS サポートが必要です）。
クレジットの使用状況と請求への影響¶
上記のテーブルに示すように、次に大きいウェアハウスサイズにサイズを拡大すると、ウェアハウスを実行する各満1時間に対して、クレジット使用状況は2倍になります。ただし、Snowflakeは1秒あたりの請求を使用することに注意してください（ウェアハウスが起動するたびに最小60秒）。そのため、ウェアハウスには、実際に消費したクレジットに対してのみ請求されます。
請求されるクレジットの総数は、ウェアハウスが継続的に稼働している時間によって異なります。比較のため、次のテーブルでは、3つの異なるサイズのGen1標準ウェアハウスの稼働時間に基づく請求合計を示しています（合計値は1000クレジット未満に四捨五入されています）。
実行 時間 |
クレジット . （XS） |
クレジット . （XL） |
クレジット . （5XL） |
|---|---|---|---|
0～60秒間 |
0.017 |
0.267 |
4.268 |
61秒間 |
0.017 |
0.271 |
4.336 |
2分間 |
0.033 |
0.533 |
8.532 |
10分間 |
0.167 |
2.667 |
42.668 |
1時間 |
1.000 |
16.000 |
256.000 |
注釈
マルチクラスターウェアハウス の場合、請求されるクレジットの数は、ウェアハウスのサイズと期間内に実行されるクラスターの数に基づいて計算されます。
例えば、3XLマルチクラスターウェアハウスが1つのクラスターを1時間実行し、次に2つのクラスターを フル に次の1時間実行した場合、請求されるクレジットの合計数は192（つまり、64 + 128）になります。
マルチクラスターウェアハウスは、 Enterprise Edition の機能です。
データのロードへの影響¶
ウェアハウスのサイズを大きくしても、データロードのパフォーマンスが常に向上するわけでは ありません 。データロードのパフォーマンスは、ウェアハウスのサイズよりも、ロードされるファイルの数（および各ファイルのサイズ）の影響を受けます。
Tip
大量のファイル（つまり、数百または数千のファイル）を同時に一括ロードする場合を除き、通常は、より小さなウェアハウス（小、中、大）で十分です。より大きなウェアハウス（XL、2XLなど）を使用すると、より多くのクレジットが消費され、パフォーマンスの向上がみられない場合があります。
データロードのヒントとガイドラインの詳細については、 データロードに関する考慮事項 をご参照ください。
クエリ処理への影響¶
ウェアハウスのサイズは、特に大規模で複雑なクエリの場合、ウェアハウスに送信されたクエリの実行に必要な時間に影響を与える可能性があります。一般に、クエリのパフォーマンスはウェアハウスのサイズに応じて変化します。これは、ウェアハウスが大きいほど、クエリの処理に使用できるコンピューティングリソースが増えるためです。
ウェアハウスで処理されるクエリの実行が遅い場合は、いつでもウェアハウスのサイズを変更して、より多くのコンピューティングリソースをプロビジョニングできます。追加のリソースは、すでに実行されているクエリには影響しませんが、完全にプロビジョニングされると、キューに入れられたクエリまたは新しく送信されたクエリで使用できます。
自動中断と自動再開¶
ウェアハウスは、アクティビティに基づいて自動的に再開または一時停止するように設定できます：
デフォルトでは、自動サスペンドは有効になっています。Snowflakeは、指定された期間アクティブでない場合、ウェアハウスを自動的に一時停止します。
デフォルトでは、自動再開は有効になっています。ウェアハウスが必要なステートメントが送信され、 さらに ウェアハウスがセッションの現在のウェアハウスである場合、Snowflakeはウェアハウスを自動的に再開します。
これらのプロパティを使用して、ワークロードに合わせてウェアハウスの監視と使用を簡素化および自動化できます。自動サスペンドにより、受信クエリがない場合にウェアハウスを実行したままにしておく（およびクレジットを消費する）ことがなくなります。同様に、自動再開により、必要に応じてウェアハウスが再び起動することが保証されます。
注釈
自動サスペンドと自動再開は、ウェアハウス内の個々のクラスターではなく、ウェアハウス全体にのみ適用されます。 マルチクラスターウェアハウス の場合：
自動サスペンドは、最小数のクラスターが実行されており、指定された期間アクティビティがない場合にのみ発生します。通常、最小値は1（クラスター）ですが、1を超えることもあります。
自動再開は、ウェアハウス全体が中断されている場合（つまり、クラスターが実行されていない場合）にのみ適用されます。
クエリ処理と同時実行¶
ウェアハウスが同時に処理できるクエリの数は、各クエリのサイズと複雑さによって決まります。クエリが送信されると、ウェアハウスは各クエリの処理に必要な計算リソースを計算して予約します。クエリを処理するのに十分なリソースがウェアハウスにない場合、クエリはキューに入れられ、保留中のリソースは実行中の他のクエリが完了すると利用可能になります。
Snowflakeには、クエリ処理と同時実行性の制御に役立つように設定できるオブジェクトレベルのパラメーターがいくつか用意されています：
注釈
クエリが必要以上にキューイングされている場合は、別のウェアハウスを作成し、クエリを新しいウェアハウスに手動でリダイレクトできます。さらに、ウェアハウスのサイズを変更すると、クエリの同時実行性とキューイングの制限されたスケーリングが可能になります。ただし、ウェアハウスのサイズ変更は、主にクエリのパフォーマンスを向上させることを目的としています。
同時実行性の完全自動スケーリングを有効にするには、Snowflakeは マルチクラスターウェアハウス を推奨します。これは、追加のウェアハウスを作成し、クエリをリダイレクトするのと本質的に同じ利点を提供しますが、手動の介入は不要です。
マルチクラスターウェアハウスは、 Enterprise Edition の機能です。
セッションでのウェアハウスの使用¶
Snowflakeでセッションが開始されると、セッションにはデフォルトでそれに関連付けられたウェアハウスがありません。セッションにウェアハウスが関連付けられるまで、セッション内でクエリを送信できません。
ユーザーのデフォルトウェアハウス¶
セッションの開始直後にクエリを実行しやすくするために、Snowflakeは個々のユーザーごとにデフォルトのウェアハウスを指定することをサポートしています。ユーザーのデフォルトのウェアハウスは、ユーザーが開始したすべてのセッションのウェアハウスとして使用されます。
デフォルトのウェアハウスは、ユーザーを作成または変更するときに、ウェブインターフェイスまたは CREATE USER/ALTER USER を使用して指定できます。
クライアントユーティリティ/ドライバー/コネクタのデフォルトウェアハウス¶
ユーザーのデフォルトウェアハウスに加えて、Snowflakeクライアント（SnowSQL、 JDBC ドライバー、 ODBC ドライバー、Pythonコネクタなど）のいずれにもデフォルトウェアハウスを設定できます：
SnowSQL はデフォルトのウェアハウスを指定するための構成ファイルとコマンドラインオプションの両方をサポートしています。
ドライバーとコネクタは、セッションを開始するときに接続パラメーターとしてデフォルトのウェアハウスを指定することをサポートします。
詳細については、 Snowflakeに接続するためのアプリケーションおよびツール をご参照ください。
Notebookのデフォルトウェアハウス¶
Notebooksワークロードのコスト効率を高めるため、マルチクラスタのX-Smallウェアハウス（SYSTEM$STREAMLIT_NOTEBOOK_WH）が各アカウントに自動的にプロビジョニングされます。最大10クラスタ、60秒のデフォルトタイムアウトを特徴とするこのウェアハウスは、改良されたビンパッキングを使用しています。ACCOUNTADMIN ロールには OWNERSHIP 権限があります。
コスト管理への提言¶
Snowflake では、 SYSTEM$STREAMLIT_NOTEBOOK_WH ウェアハウスをノートブックワークロード専用に使用することを推奨しています。
ビンパッキングの効率を高め、クラスタの断片化を減らすために、Notebooksアプリからの SQL クエリを、顧客が管理する別のクエリウェアハウスに直接送信します。アカウント内のすべてのNotebookアプリに単一の共有ウェアハウスを使用することで、ビン詰めの効率がさらに向上します。
Notebook Pythonのワークロードを SQL クエリから分離することで、クラスタの断片化を最小限に抑えます。このアプローチは、クエリ実行に通常使用される大規模なウェアハウスとNotebook Pythonワークロードが同居しないようにすることで、全体のコストを最適化します。
アクセス制御の要件¶
権限 |
オブジェクト |
注意 |
|---|---|---|
USAGE |
SYSTEM$STREAMLIT_NOTEBOOK_WH |
デフォルトでは、 PUBLIC ロールは USAGE 権限を持っています。ACCOUNTADMIN は、 USAGE 権限の付与と取り消しができます。 |
MONITOR, OPERATE, APPLYBUDGET |
SYSTEM$STREAMLIT_NOTEBOOK_WH |
ACCOUNTADMIN が利用でき、 ACCOUNTADMIN が他のロールに付与できます。 |
ウェアハウスのデフォルトの優先順位¶
ユーザーがSnowflakeに接続してセッションを開始すると、Snowflakeは次の順序でセッションのデフォルトのウェアハウスを決定します：
ユーザーのデフォルトのウェアハウス、
» 上書き...
Snowflakeへの接続に使用されるクライアントユーティリティ（SnowSQL、 JDBC ドライバーなど）の構成ファイル内のデフォルトのウェアハウス（クライアントが構成ファイルをサポートしている場合）、
» 上書き...
クライアントコマンドラインまたはSnowflakeに渡されるドライバー/コネクタパラメーターで指定されたデフォルトのウェアハウス。
注釈
さらに、セッション内で USE WAREHOUSE コマンドを実行することにより、セッションのデフォルトのウェアハウスをいつでも変更できます。