ウェアハウスに関する考慮事項

このトピックでは、Snowflakeで仮想ウェアハウスを使用してクエリを処理するための 一般 ガイドラインとベストプラクティスを提供します。すべてのクエリシナリオは異なり、同時ユーザー/クエリの数、クエリ対象のテーブルの数、データサイズと構成、およびウェアハウスの可用性、待ち時間、コストに関する特定の要件など、さまざまな要因の影響を受けるため、特定または絶対の数値、値、推奨事項を 提供しません

また、データのロードに関するウェアハウスの考慮事項については カバーしません 。別のトピックで説明します(サイドバーを参照)。

ウェアハウスを効果的かつ効率的に使用するための鍵は次のとおりです:

  1. さまざまな種類のクエリとさまざまなウェアハウスサイズを試して、特定のクエリのニーズとワークロードに最適な組み合わせを決定します。

  2. ウェアハウスのサイズに焦点を合わせないでください。Snowflakeは1秒あたりの課金を利用するため、より大きなウェアハウス(L、XL、2XLなど)を実行し、使用していないときは単に一時停止することができます。

注釈

これらのガイドラインとベストプラクティスは、すべてのアカウントの標準である単一クラスターウェアハウスと、 Snowflake Enterprise Edition (以上)で利用可能な マルチクラスターウェアハウス の両方に適用されます。

このトピックの内容:

ウェアハウスのクレジットはどのように請求されますか?

クレジットチャージは以下に基づいて計算されます:

  • クラスターごとのサーバー数(ウェアハウスのサイズによって決定されます)。

  • クラスターの数( マルチクラスターウェアハウス を使用している場合)。

  • 各クラスターの実行内の各サーバーが実行される時間の長さ。

例:

XS

クラスターごとに1サーバーを使用し、各クラスターが実行される連続した1時間ごとに1クレジットを請求します。連続する各サイズは、クラスターあたりのサーバー数を2倍にします。

4XL

クラスターごとに128サーバーを使用し、各クラスターが実行される連続した1時間ごとに128クレジットを請求します。

次の点に注意してください:

  • ウェアハウスクラスターの各サーバーには次のものがあります:

    • サーバーがいつ起動したかを追跡する内部タイマー。この内部タイマーは、1秒ごとにサーバーの個々のクレジット請求額を計算するために使用されます。

    • ウェアハウスが一時停止またはサイズ変更された場合でも、維持されるウェアハウス内の位置。サーバーは常に追加されたときとは逆の順序(別名 LIFO、「最後の入力、最初の出力」)で削除されるため、この位置はサーバーの追加と削除の方法に影響します。

  • サーバーがプロビジョニングされるとき:

    • サーバーのプロビジョニングの最小請求料金は1分(つまり、60秒)です。

    • 最初の60秒の期間が終了する前にウェアハウスを停止しても 利点はありません 。その期間のクレジットは既に請求されているからです。

    • 最初の60秒後、実行中のサーバーに対するすべての後続の課金は1秒ごとです(サーバーがシャットダウンするまで)。言い換えると:

      • サーバーが30〜60秒実行された場合、60秒で請求されます。

      • サーバーが61秒間実行された場合、61秒間のみ請求されます。

      • サーバーが61秒実行され、シャットダウンしてから再起動し、60秒未満実行されると、121秒(60 + 1 + 60)で請求されます。

  • ウェアハウスのサイズを変更すると、ウェアハウス内の クラスターの追加サーバーがプロビジョニングされます:

    • これにより、ウェアハウスに対して請求されるクレジット数がそれに対応して増加します(追加のサーバーの実行中)。

    • 追加サーバーの内部タイマーは、プロビジョニングされると開始されます(つまり、追加サーバーのクレジットは、ウェアハウスのサイズが変更された時間に対して請求されます)。

  • クレジット使用状況は時間単位で表示されます。1秒あたりの請求では、クレジットの使用状況/請求額の端数が表示されます。

クエリ構成はウェアハウス処理にどのように影響しますか?

クエリの処理に必要なサーバーの数は、クエリのサイズと複雑さに依存します。ほとんどの場合、クエリは特により大規模で複雑なクエリの場合、ウェアハウスのサイズに関して線形にスケーリングされます。クエリ処理に影響を与える要因を考慮する場合、次のことを考慮してください:

  • クエリされるテーブルの全体的なサイズは、行数よりも影響が大きくなります。

  • 述語を使用したクエリフィルタリングは、クエリ内の結合/テーブルの数と同様に、処理に影響を与えます。

ちなみに

最良の結果を得るには、同じウェアハウスで比較的同種のクエリ(サイズ、複雑さ、データセットなど)を実行してください。同じウェアハウスでさまざまなサイズや複雑さのクエリを実行すると、ウェアハウスの負荷を分析するのが難しくなり、ワークロード内のクエリのサイズ、構成、数に合わせて最適なサイズを選択することが難しくなります。

ウェアハウスのキャッシュはクエリにどのように影響しますか?

各ウェアハウスは、実行中に、クエリがウェアハウスによって処理されるときにアクセスされるテーブルデータのキャッシュを保持します。これにより、クエリ内のテーブルではなくキャッシュから読み取ることができる場合、後続のクエリのパフォーマンスが向上します。キャッシュのサイズは、ウェアハウス内のサーバーの数(つまり、ウェアハウスが大きいほど、したがって、ウェアハウス内のサーバーの数)によって決定され、キャッシュが大きくなります。

ウェアハウスが中断されると、このキャッシュは削除されるため、ウェアハウスの再開後、一部のクエリの初期パフォーマンスが低下する可能性があります。再開されたウェアハウスが実行され、より多くのクエリが処理されると、キャッシュが再構築され、キャッシュを利用できるクエリのパフォーマンスが向上します。

ウェアハウスを一時停止するか、実行したままにするかを決定するときは、このことに留意してください。つまり、ウェアハウスを一時停止することでクレジットを節約することと、パフォーマンスを向上させるために以前のクエリからのデータのキャッシュを維持することとのトレードオフを検討します。

ウェアハウスの作成

ウェアハウスを作成するとき、コストとパフォーマンスの観点から考慮する必要がある2つの最も重要な要素は次のとおりです:

  • ウェアハウスのサイズ(つまり、クラスターごとのサーバー数)。

  • 手動管理と自動管理(ウェアハウスの開始/再開および一時停止用)。

ウェアハウス内のクラスターの数は、 Snowflake Enterprise Edition (以上)および マルチクラスターウェアハウス を使用している場合にも重要です。詳細については、 スケールアップとスケールアウト (このトピック内)をご参照ください。

初期ウェアハウスのサイズの選択

ウェアハウスに選択する初期サイズは、ウェアハウスが実行しているタスクと処理するワークロードによって異なります。例:

  • データのロードの場合、ウェアハウスのサイズは、ロードされるファイルの数と各ファイルのデータ量と一致する必要があります。詳細については、 データロードに関する考慮事項 をご参照ください。

  • 小規模なテスト環境でのクエリの場合、より小さなウェアハウスサイズ(XS、S、M)で十分な場合があります。

  • 大規模な本番環境でのクエリでは、より大きなウェアハウスサイズ(L、XL、2XLなど)の方が費用対効果が高い場合があります。

ただし、1秒あたりのクレジット請求と自動サスペンドにより、より大きなサイズから始めて、ワークロードに合わせてサイズを調整する柔軟性が得られることに注意してください。ウェアハウスのサイズはいつでも縮小できます。

また、より小さく、より基本的なクエリの場合、大きくても必ずしも高速ではありません。通常、小規模/単純なクエリは、同時に処理されるクエリの数に関係なく、追加リソースの恩恵を受けないため、XL(またはより大きな)ウェアハウスを必要としません。一般に、ウェアハウスのサイズを、ウェアハウスによって処理されるクエリの予想されるサイズと複雑さに合わせてみてください。

ちなみに

複数のサイズのウェアハウス(例:XL、L、M)に対して同じクエリを実行して実験します。実験するクエリのサイズと複雑さは、通常5〜10分(またはそれ以下)以内に完了することがわかっている必要があります。

ウェアハウスの停止の自動化

ウェアハウスは、指定された期間が経過した後に、アクティビティがなくなると自動的に中断するように設定できます。自動サスペンドは、ウェアハウスの非アクティブな期間(分、時間など)を指定することにより有効になります。

ワークロードとウェアハウスの可用性の要件に応じて、自動サスペンドを設定することをお勧めします:

  • 自動一時停止を有効にする場合は、Snowflakeが1秒あたりの請求を使用するため、低い値(5または10分以下)に設定することをお勧めします。これは、使用されていないときにウェアハウスが稼働しないように(そしてクレジットを消費しないように)します。

    ただし、設定する値は、クエリワークロードのギャップ(存在する場合)と一致する必要があります。例えば、着信クエリの間隔が2または3分である場合、ウェアハウスは中断と再開の継続的な状態になるため、また、再開するたびに最小クレジット使用量(つまり、60秒)が請求されるため、自動サスペンドを1または2分に設定しても意味がありません(自動再開も有効になっている場合)。

  • 次の場合、ウェアハウスの自動サスペンドを無効にすることを検討できます:

    • ウェアハウスには、安定した重いワークロードがあります。

    • ウェアハウスを遅延や遅延時間なしで利用できるようにする必要があります。サーバーのプロビジョニングは一般的に非常に高速です(例えば、1または2秒)。ただし、ウェアハウスのサイズとプロビジョニングするサーバーの可用性によっては、時間がかかる場合があります。

重要

自動サスペンドを無効にすることを選択した場合、ウェアハウスがクエリを処理していない場合でも、ウェアハウスの継続的な実行に関連するコストを慎重に検討してください。特に大規模なウェアハウス(XL、2XLなど)の場合、コストが大きくなる可能性があります。

自動サスペンドを無効にするには、ウェブインターフェイスで明示的に Never を選択するか、 SQLで NULL を指定する必要があります。

ウェアハウス再開の自動化

ウェアハウスは、新しいクエリが送信されたときに自動的に再開するように設定できます。

特定のウェアハウスの使用をどの程度制御したいかに応じて、自動再開を有効/無効にすることをお勧めします:

  • コストとアクセスが問題にならない場合は、自動再開を有効にして、必要なときにいつでもウェアハウスが開始されるようにします。サーバーのプロビジョニングにより、ウェアハウスの再開が少し遅れることがあることに注意してください。

  • コストやユーザーアクセスを制御する場合は、自動再開を無効のままにして、必要な場合にのみ手動でウェアハウスを再開します。

スケールアップとスケールアウト

Snowflakeは、ウェアハウスを拡張する2つの方法をサポートしています:

  • ウェアハウスのサイズを変更してスケールアップします。

  • クラスターをウェアハウスに追加してスケールアウトします( Snowflake Enterprise Edition 以上が必要です)。

ウェアハウスのサイズ変更によりパフォーマンスが向上

ウェアハウスのサイズを変更すると、一般に、特に大規模で複雑なクエリのクエリパフォーマンスが向上します。また、同時に送信されるすべてのクエリを処理するのに十分なサーバーがウェアハウスにない場合に発生するキューイングを減らすのに役立ちます。ウェアハウスのサイズ変更は、並行性の問題を処理するためのものではないことに注意してください。代わりに、追加のウェアハウスを使用してワークロードを処理するか、マルチクラスターウェアハウスを使用します(この機能がアカウントで使用可能な場合)。

Snowflakeは、実行中でも、いつでもウェアハウスのサイズ変更をサポートしています。クエリの実行速度が遅く、同じウェアハウスで実行したいサイズと複雑さの類似したクエリがある場合、実行中にウェアハウスのサイズを変更することを選択できます。ただし、次のことに注意してください:

  • ウェアハウスのサイズについて前述したように、大きいほど必ずしも高速ではありません。すでに迅速に実行されている小規模で基本的なクエリの場合、サイズを変更しても大幅な改善は見られない場合があります。

  • 実行中のウェアハウスのサイズを変更しても、ウェアハウスで既に処理されているクエリには影響しません。追加のサーバーは、キューに入れられたクエリと新しいクエリにのみ使用されます。

ちなみに

実行中のウェアハウスのサイズを小さくすると、サーバーがウェアハウスから削除されます。サーバーが削除されると、サーバーに関連付けられたキャッシュが削除されます。これは、ウェアハウスの中断が再開後にパフォーマンスに影響を与えるのと同じように、パフォーマンスに影響を与える可能性があります。

実行中のウェアハウスのサイズを縮小するか、現在のサイズのままにするかを選択する際には、このことに留意してください。つまり、クレジットの保存とサーバーキャッシュの維持に関してトレードオフがあります。

マルチクラスターウェアハウスにより同時実行性が改善

マルチクラスターウェアハウス は、多数の同時ユーザーやクエリに関連するキューイングおよびパフォーマンスの問題を処理するために特別に設計されています。さらに、ユーザー/クエリの数が変動する傾向がある場合、マルチクラスターウェアハウスはこのプロセスを自動化するのに役立ちます。

マルチクラスターウェアハウスを使用するかどうか、およびウェアハウスごとに使用するクラスターの数を決定するときは、以下を考慮してください:

  • Snowflake Enterprise Edition(またはそれ以降のエディション)を使用している場合、 すべて のウェアハウスをマルチクラスターウェアハウスとして構成する必要があります。

  • 最大化モードで実行するための特定の要件がない限り、マルチクラスターウェアハウスは自動スケールモードで実行するように構成する必要があります。これにより、Snowflakeは必要に応じてクラスターを自動的に開始および停止できます。

  • マルチクラスターウェアハウスのクラスターの最小数と最大数を選択する場合:

    最小

    デフォルト値 1 のままにします。これにより、必要な場合にのみ追加のクラスターが開始されます。ただし、ウェアハウスの高可用性が懸念される場合は、値を 1 より高く設定します。これにより、万一クラスターに障害が発生した場合でも、ウェアハウスの可用性と継続性を確保できます。

    最大

    ウェアハウスのサイズと対応するクレジットコストを考慮しながら、この値をできるだけ大きく設定します。例えば、最大クラスター= 10 のXLウェアハウス(16サーバー)は、すべての10クラスターが1時間連続して実行されると、1時間で160クレジットを消費します。