ウェアハウスの概要¶
クエリ、およびテーブルへのデータのロードを含むすべての DML 操作には、ウェアハウスが必要です。ウェアハウスは、標準タイプまたはSnowpark用に最適化されたタイプのいずれかとして定義されることに加えて、サイズと、ウェアハウスアクティビティの制御と自動化に役立つように設定できる他のプロパティによって定義されます。
ウェアハウスはいつでも開始および停止できます。また、実行中であっても、ウェアハウスによって実行される操作の種類に応じて、多少の計算リソースの必要性に対応するために、いつでもサイズを変更できます。
このトピックの内容：
ウェアハウスサイズ¶
サイズは、ウェアハウス内のクラスターごとに使用可能なコンピューティングリソースの量を指定します。Snowflakeは、次のウェアハウスサイズをサポートしています。
ウェアハウスサイズ |
クレジット / 時間 |
クレジット / 秒 |
メモ |
|---|---|---|---|
XS |
1 |
0.0003 |
Snowsight で作成され CREATE WAREHOUSE を使用するウェアハウスのデフォルトサイズ。 |
S |
2 |
0.0006 |
|
M |
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 政府リージョンではプレビュー段階にあります。 |
大規模なウェアハウスサイズ¶
大規模なウェアハウスサイズ5X-Largeおよび6X-Largeは、すべてのAmazon Web Services（AWS）およびMicrosoft Azureリージョンで一般公開されています。
大規模なウェアハウスサイズは、 US 政府リージョンでプレビュー中です（ARM での FIPS サポートが必要です）。
クレジットの使用状況と請求への影響¶
上記のテーブルに示すように、次に大きいウェアハウスサイズにサイズを拡大すると、ウェアハウスを実行する各満1時間に対して、クレジット使用状況は2倍になります。ただし、Snowflakeは1秒あたりの請求を使用することに注意してください（ウェアハウスが起動するたびに最小60秒）。そのため、ウェアハウスには、実際に消費したクレジットに対してのみ請求されます。
請求されるクレジットの総数は、ウェアハウスが継続的に稼働している時間によって異なります。比較のために、次の表に実行時間に基づいた3つの異なるサイズのウェアハウスの請求合計を示します（クレジットの最も近い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に接続する をご参照ください。
Notebooksのデフォルトウェアハウス¶
SYSTEM$STREAMLIT_NOTEBOOK_WH という名前のSnowflakeが管理する専用ウェアハウスが、ノートブックアプリを実行するために各アカウントに自動的にプロビジョニングされます。このウェアハウスには次のような特性があります。
ウェアハウスは、 SYSTEM ロールの下、Snowflakeが所有および管理しています。このウェアハウスは DROP、 ALTER することはできません。
マルチクラスターのXSウェアハウスで、最大クラスター数は10です。デフォルトのタイムアウトは60秒です。
ウェアハウスはノートブックジョブのみを実行します。ノートブックアプリから発行された SQL クエリは、別個の、顧客が管理する クエリウェアハウス に送信されます。
SYSTEM$STREAMLIT_NOTEBOOK_WH を使用すると、いくつかの利点があります。
ノートブックPythonのワークロードを SQL クエリから分離することで、クラスターの断片化を減らすことができます。これにより、Notebooks Pythonのワークロードは、クエリ実行によく使用される大規模なウェアハウスに併設されないため、全体的なコストが最適化されます。
アカウント内のすべてのノートブックアプリケーションに単一の専用ウェアハウスを持つことで、断片化を減らし、より良いビンパッキングを支援します。
このデフォルトのウェアハウスをNotebooksで使用する方法については、 Snowflakeノートブックを実行するためのウェアハウスの推奨事項 を参照してください。
アクセス制御の要件¶
権限 |
オブジェクト |
メモ |
|---|---|---|
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 コマンドを実行することにより、セッションのデフォルトのウェアハウスをいつでも変更できます。