適応型コンピューティング

適応型コンピューティングは、簡単な操作で強力なパフォーマンスを実現することに焦点を当てたコンピューティングサービスです。固定のコンピューティングエンジンを、クエリに自動的に適応するワークロード対応のエンジンに置き換えます。システムは最適なパフォーマンスを得るためにリソースを割り当てる方法を決定し、インフラストラクチャチューニングの必要性を排除します。

リソースを自動的にスケーリングし、クエリをインテリジェントにルーティングすることにより、適応型コンピューティングは、手動によるクラスターのサイズ設定、サービスの中断を生じさせるアップグレード、実践的なパフォーマンスチューニングなど、従来のウェアハウス管理に付随する運用の複雑さを解消します。また、最新のハードウェアとパフォーマンスの強化が実施されているため、適応型ウェアハウスはGen2と同様のコストで大幅に多くのクエリを実行できます。

適応型ウェアハウスを通じて適応型コンピューティングにアクセスします。適応型ウェアハウスにより、次の内容を管理する必要がなくなります。

  • ウェアハウスのサイズ(XSMALL、SMALL、MEDIUMなど)。

  • マルチクラスターウェアハウスの設定。

  • Query Acceleration Serviceの設定。

  • セマンティクスの一時停止および再開。

Snowflakeはこれらをすべて自動的に処理するため、チームはデータのインフラストラクチャの管理ではなく、データの操作に専念できます。

アカウント内のすべての適応型ウェアハウスのすべてのジョブは、コンピューティングリソースの共有プールにルーティングされます。このプールはお客様のアカウント専用です。組織内の他のアカウントと共有されることはなく、標準、インタラクティブ、Snowpark用に最適化などの他のウェアハウスタイプでは使用されません。同様のパフォーマンスとコスト特性、レポート作成機能、ガバナンスを持つワークロードをグループ化するために、1つのアカウントにつき複数の適応型ウェアハウスを引き続き保有することができます。

適応型ウェアハウスはクエリベースの課金モデルを使用します。この場合、各クエリのコストは、使用するコンピューティングリソースやソフトウェアリソースの量などの要因によって異なります。適応型ウェアハウスで実行されるすべてのクエリがそのウェアハウスの総コストの対象として加算されるため、ウェアハウスレベルのコストについて引き続き推論することができます。クエリレベルのコスト可視化機能はパブリックプレビューでは利用できませんが、一般提供を予定しています。

同じコスト管理ツールを利用できます。

  • コストガバナンスを確保するための:doc:予算</user-guide/budgets>`および:doc:`リソースモニター</user-guide/resource-monitors>

  • 詳細な可観測性を実現するACCOUNT_USAGEビュー。

新しい適応型ウェアハウスを作成するか、ダウンタイムを発生させることなく既存の標準ウェアハウスを適応型に変換することができます。既存のウェアハウスを変換することで、既存のチャージバックとショーバックの構造を保持し、ワークロードを分離できます(分析とETLのチームベースのウェアハウスなど)。たとえば、財務チームは1つの適応型ウェアハウスを使用し、エンジニアリングチームは別の適応型ウェアハウスを使用する可能性があります。

制限事項

適応型ウェアハウスにはEnterprise Edition(またはこれより上のエディション)が必要です。

公開プレビュー中、適応型ウェアハウスは次のリージョンで利用できます。US西部2(オレゴン州)、EU西部1(アイルランド)、およびAP北東部1(東京)。

次の変換も**まだ**サポートされていません。

  • X5LargeウェアハウスまたはX6Largeウェアハウスへの変換、またはそれらのウェアハウスからの変換。

  • Snowparkに最適化されたウェアハウスまたはインタラクティブなウェアハウスとの間の変換。

パフォーマンスとスループットの管理

適応型ウェアハウスは、パフォーマンスとスループットを制御するための2つの主要なプロパティを公開します。

  • MAX_QUERY_PERFORMANCE_LEVEL

  • QUERY_THROUGHPUT_MULTIPLIER

MAX_QUERY_PERFORMANCE_LEVEL

MAX_QUERY_PERFORMANCE_LEVELは、任意の個別クエリに関するパフォーマンスの上限を表します。ウェアハウスレベルで設定され、システムにクエリ実行の「高速化」または「速度低下」を指示するメカニズムとして機能します。

プロパティは、Tシャツのサイズ(XSMALL~X4LARGE)の単位で表されます。各Tシャツのサイズは、従来のウェアハウスサイズと同等以上のパフォーマンスを実現します。

:

{ XSMALL | SMALL | MEDIUM | LARGE | XLARGE | XXLARGE | XXXLARGE | X4LARGE }

デフォルト:

XLARGE

セマンティクス:

  • 値を引き上げると、ステートメントごとのコンピューティングヘッドルームが拡充され、大規模で複雑なクエリの遅延が改善されるとともに、単一のステートメントの潜在的な瞬時コストが増加します。

  • 値を引き下げると、ステートメントごとのコストが制限されますが、同時実行のためのより多くのヘッドルームを確保する一方で、大規模なクエリ実行の速度が低下する可能性があります。

  • この値は、特定の基盤となるコンピューティング構成にはマッピングされません。パフォーマンスレベルのみを表します。Snowflakeは、各クエリに必要な実際のリソースを決定します。

動作:

適応型コンピューティングは、クエリプランに基づいて、クエリに必要な最適なコンピューティングを決定します。最適なパフォーマンスを実現するためのコンピューティングの必要性が、MAX_QUERY_PERFORMANCE_LEVELSnowflakeの上限を超えるものであるとサービスが判断した場合、Snowflakeは上限をMAX_QUERY_PERFORMANCE_LEVELに設定します。小規模クエリの場合、Snowflakeは最適なパフォーマンスを確保するためにクエリが必要とするMAX_QUERY_PERFORMANCE_LEVEL以下のコンピューティングを選択します。

ガイダンス:

MAX_QUERY_PERFORMANCE_LEVELをユーザーが最大のクエリに対して得られることを想定している最高のクエリパフォーマンスレベルに設定します。:doc:`予算</user-guide/budgets>`および:doc:`リソースモニター</user-guide/resource-monitors>`を使用して、一定期間の総支出を管理します。

QUERY_THROUGHPUT_MULTIPLIER

QUERY_THROUGHPUT_MULTIPLIERは、特定の時間における最大スループットを計算するために使用される乗数を表します。絶対最大スループットを指定するのではなく、システムにより計算された最小値の整数スケール係数を指定します。

MAX_QUERY_PERFORMANCE_LEVELで``N``ステートメントを並列実行するには、乗数を``N``に設定します。MAX_QUERY_PERFORMANCE_LEVELは上限を表すため、この設定は通常、並列実行される``N``件より多くのクエリをサポートします。これは、多くのクエリが必要とする対象が最大値を下回るためです。

:

負でない整数

デフォルト:

2

この値を``0``に設定することは、スループットに上限がないことを表します。ウェアハウスは、上限なしで使用可能な量のバースト容量を使用できます。

セマンティクス:

正の値に設定すると、最大スループットは次のように計算されます。

MAX_THROUGHPUT = QUERY_THROUGHPUT_MULTIPLIER * MINIMUM

``MINIMUM``は、ウェアハウスに設定されているMAX_QUERY_PERFORMANCE_LEVELについてシステムによって計算された基本容量です。

  • このシステムによって計算された基本容量のスケール係数として機能します。

  • 値が高いほど、ピークスループット(より多くの同時作業)が向上し、キューイングが減少しますが、瞬時に高いコストが発生する可能性があります。

  • 値が低いほど、バーストスループットが制限され、費用が急増するリスクが軽減されますが、キューイングにつながる可能性があります。

動作:

Snowflakeは、MAX_QUERY_PERFORMANCE_LEVEL、移行履歴(従来のサイズ、最大クラスター数、QASスケール係数)、およびその他のシステム調整パラメーターに基づいてウェアハウスの内部の基本容量レートを計算します。

QUERY_THROUGHPUT_MULTIPLIERは、この基本容量に乗算して、同時に実行できるクエリの総数を決定します。システムがこのターゲットを下回ると、クエリの実行が許可されます。ターゲットに達すると、クエリをキューに入れます。

ガイダンス:

永続的なキューイングオンロード時間が見られ、より高いスループットが必要な場合は、QUERY_THROUGHPUT_MULTIPLIERの値を引き上げます。一時的な費用の上限設定について懸念がある場合は、QUERY_THROUGHPUT_MULTIPLIERの値を引き下げて、絶対的なコストを管理するための予算とリソースモニターに準拠します。

適応型ウェアハウスを作成する

Snowsight、SQLまたは:doc:`Cortex Code</user-guide/cortex-code/cortex-code>`を使用して適応型ウェアハウスを作成できます

|sf-web-interface|を使用して適応型ウェアハウスを作成するには:

  1. Snowsight にサインインします。

  2. ナビゲーションメニューで Compute » Warehouses を選択します。

  3. +Warehouse を選択します。

  4. Type ドロップダウンで、 Adaptive を選択します。

  5. オプションで、:ui:`Advanced`を選択して次のように構成します。

    • :ui:`Maximum query performance level`(デフォルト: XLarge)

    • :ui:`Query throughput multiplier`(デフォルト: 2)

ウェアハウスが作成され、通常どおり使用できます。

標準ウェアハウスを適応型ウェアハウスに変換する

Snowsight、SQLまたは:doc:`Cortex Code</user-guide/cortex-code/cortex-code>`を使用して、標準ウェアハウスを適応型に変換できます。

注釈

ウェアハウスと適応型ウェアハウス間の変換は*オンライン操作*であり、ダウンタイムは発生しません。この変換により、ウェアハウスが使用できなくなったり、実行中のクエリが中断されたりすることはありません。

ウェアハウスを適応型ウェアハウスに変換するか、標準ウェアハウスに戻すと、そのウェアハウスで実行されていた既存のクエリは、既存のコンピューティングリソースを使用して完了するまで実行され続けます。同時に、ウェアハウスは新しいウェアハウスタイプのコンピューティングリソースに対して新しいクエリを実行します。既存のクエリの実行中は、両方のコンピューティングリソースのセットに対して課金されます。ウェアハウスを変換して標準型に戻す場合は、新しいコンピューティングリソースを使用しているクエリであるかどうかを問わず、この期間中ウェアハウスは自動的に一時停止されません。既存のクエリが完了すると、ワークロードは完全に新しいコンピューティングリソースに移行します。

|sf-web-interface|を使用して標準ウェアハウスを適応型ウェアハウスに変換するには:

  1. Snowsight にサインインします。

  2. ナビゲーションメニューで:ui:Compute » Warehouses » :ui:`<warehouse_identifier>`を選択します。

  3. その他のメニュー:ui:`...`(3点リーダー)|raa| :ui:`Convert to Adaptive`を選択します。

  4. 操作を確定します。

変換時のプロパティの動作

標準ウェアハウスを適応型ウェアハウスに変換する場合に、変更する必要があるプロパティはWAREHOUSE_TYPEのみです。Snowflakeは、MAX_QUERY_PERFORMANCE_LEVELおよびQUERY_THROUGHPUT_MULTIPLIERの適切な値を自動的に計算します。

システムは、標準ウェアハウスの既存の構成からこれらを派生します。

  • ウェアハウスのサイズ

  • MAX_CLUSTER_COUNT(マルチクラスターウェアハウスの場合)。

  • QASスケール係数。

  • ウェアハウスの生成(ハードウェア/ソフトウェアの生成)。

元の標準ウェアハウスと比較してパフォーマンスを維持または向上させ、典型的な負荷の急増に十分なバースト容量を確保し、適応型に切り替えるときに手動のチューニングを必要としないようにすることを目標としています。

変換後、オプションでALTERWAREHOUSEを使用してMAX_QUERY_PERFORMANCE_LEVELおよびQUERY_THROUGHPUT_MULTIPLIERをオーバーライドすることができます。WAREHOUSE_SIZEおよびMAX_CLUSTER_COUNTなどの標準ウェアハウスのプロパティは、適応型への変換後には適用されなくなり、変換により標準に戻すと、適応型プロパティは適用されなくなります。

請求と価格設定

適応型ウェアハウスは、クエリベースの課金モデルを使用します。各クエリのコストは、クラスタサイズやQuery Acceleration Service(QAS)といった機能によって使用される追加容量など、使用するコンピューティングおよびソフトウェアに関するリソース量をはじめとする要因によって異なります。適応型ウェアハウスの作成に対しては課金されません。最初のクエリが実行されたときに課金が開始されます。

適応型ウェアハウスで実行されるすべてのクエリは、そのウェアハウスの総コストに加算されるため、既存のチャージバックとショーバックの構造を引き続き使用できます。適応型ウェアハウスの使用状況は、仮想ウェアハウスクレジットを使用した使用状況ステートメントのCOMPUTEの一部として報告されます。

主に次の要因に基づいてパフォーマンスと費用を制御します。

  • MAX_QUERY_PERFORMANCE_LEVEL: ステートメントごとのパフォーマンスレベルの上限を設定します。

  • QUERY_THROUGHPUT_MULTIPLIER: 任意の時点でのバースト容量全体の上限を設定します。

  • 予算およびリソースモニター: アカウントまたはウェアハウスのレベルで、時間の経過に伴う総費用を管理します。

典型的な構成パターン:

ワークロードのタイプ

設定

レイテンシの影響を受けやすい重要なワークロード

高いMAX_QUERY_PERFORMANCE_LEVEL(XLARGE以上)。高いQUERY_THROUGHPUT_MULTIPLIER。計画の範囲内で費用の集計を継続するためのリソースモニターまたは予算。

コスト依存型、高スループットのワークロード

中程度のMAX_QUERY_PERFORMANCE_LEVEL(MEDIUMまたはLARGE)。費用の急増に対してスループットのバランスを確保するための中程度のQUERY_THROUGHPUT_MULTIPLIER。

予算制約の厳格なワークロード

低いMAX_QUERY_PERFORMANCE_LEVEL。低いQUERY_THROUGHPUT_MULTIPLIER。厳密な予算とリソースモニター。

ACCOUNT_USAGE </sql-reference/account-usage>`ビューを使用して、特定の適応型ウェアハウスのクレジット消費に関する詳細データを取得することができます。:doc:/sql-reference/account-usage/warehouse_metering_history`を使用して、ウェアハウスのクレジット消費量を表示します。関連ビューの全リストについては、:ref:`label-adaptive_warehouse_account_usage`をご参照ください。

コンピューティングコストの詳細については、:doc:`/user-guide/cost-understanding-compute`をご参照ください。

SQL リファレンス

CREATE ADAPTIVE WAREHOUSE

新しい適応型仮想ウェアハウスを作成します。

CREATE [ OR REPLACE ] ADAPTIVE WAREHOUSE [ IF NOT EXISTS ] <name>
  [ [ WITH ] adaptiveProperties ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , ... ] ) ]
  [ objectParams ]

adaptiveProperties ::=
  COMMENT = '<string_literal>'
  MAX_QUERY_PERFORMANCE_LEVEL = { XSMALL | SMALL | MEDIUM | LARGE
                                | XLARGE | XXLARGE | XXXLARGE | X4LARGE }
  QUERY_THROUGHPUT_MULTIPLIER = <integer>

objectParams ::=
  STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <num>
  STATEMENT_TIMEOUT_IN_SECONDS = <num>

``WAREHOUSE_TYPE = 'ADAPTIVE'``に設定されている標準の:doc:`CREATE WAREHOUSE </sql-reference/sql/create-warehouse>`構文を使用して、適応型ウェアハウスを作成することもできます。

CREATE [ OR REPLACE ] WAREHOUSE [ IF NOT EXISTS ] <name>
  [ [ WITH ] WAREHOUSE_TYPE = 'ADAPTIVE'
    [ adaptiveProperties ]
  ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , ... ] ) ]
  [ objectParams ]

注釈

WAREHOUSE_SIZE、MIN_CLUSTER_COUNT、MAX_CLUSTER_COUNTおよびSCALING_POLICYなどの標準ウェアハウスプロパティを適応型ウェアハウスで設定することはできません。同様に、MAX_QUERY_PERFORMANCE_LEVELおよびQUERY_THROUGHPUT_MULTIPLIERなどの適応型ウェアハウスプロパティを標準ウェアハウスで設定することはできません。

必須パラメーター

name

適応型仮想ウェアハウスの識別子。アカウントに対して一意である必要があります。先頭がアルファベット文字であることが必要であり、二重引用符で囲まない限り、スペースや特殊文字を配置することはできません。詳細については オブジェクト識別子 をご参照ください。

オプションのプロパティ

MAX_QUERY_PERFORMANCE_LEVEL = { XSMALL | SMALL | MEDIUM | LARGE | XLARGE | XXLARGE | XXXLARGE | X4LARGE }

単一ステートメントのパフォーマンスレベルの上限。Tシャツのサイズとして表されます。デフォルト: XLARGE

Snowflakeは、ステートメントの特性に基づいて、この境界を上限としてパフォーマンスレベルを選択します。より小さなステートメントは、費用を削減するために、より低いパフォーマンスレベルで実行される可能性があります。最大サイズのクエリに適した値を選択します。

詳細については、 パフォーマンスとスループットの管理 をご参照ください。

QUERY_THROUGHPUT_MULTIPLIER = <integer>

任意の時間における最大スループットを計算するために使用される乗数。システムが計算した最小値の負ではない整数スケール係数として表されます。値が高いほど、ピークスループット(より多くの同時作業)が向上し、キューイングが減少しますが、瞬時に高いコストが発生する可能性があります。値が低いほど、バーストスループットが制限され、費用が急増するリスクが軽減されますが、キューイングにつながる可能性があります。``0``の値はスループットに上限が設定されていないことを表します。

デフォルト: 2

詳細については、 パフォーマンスとスループットの管理 をご参照ください。

STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <num>

最大時間(秒)のSQLステートメントについては、Snowflakeがキャンセルするまで、ウェアハウスのキューに保持することができます。詳細については パラメーター をご参照ください。

STATEMENT_TIMEOUT_IN_SECONDS = <num>

最大時間(秒)の実行中のSQLステートメントについては、Snowflakeがキャンセルするまで実行できます。詳細については パラメーター をご参照ください。

デフォルト設定の適応型ウェアハウスを作成します。

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh;

特定のパフォーマンスレベルで作成します。

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = XXLARGE;

両方のプロパティで作成します。

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = MEDIUM
       QUERY_THROUGHPUT_MULTIPLIER = 6;

標準のCREATE WAREHOUSE構文を使用して作成します。

CREATE WAREHOUSE my_adaptive_wh
  WITH WAREHOUSE_TYPE = 'ADAPTIVE'
       MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 3;

ALTER WAREHOUSE(適応型)

:doc:`ALTER WAREHOUSE </sql-reference/sql/alter-warehouse>`を使用して、標準ウェアハウスを適応型に変換する、適応型ウェアハウスのプロパティを変更する、または適応型ウェアハウスを変換して標準に戻すことができます。

標準のウェアハウスを適応型に変換します。

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'ADAPTIVE';

作成または変換後に適応型ウェアハウスのプロパティを変更します。

ALTER WAREHOUSE my_adaptive_wh SET
  MAX_QUERY_PERFORMANCE_LEVEL = XLARGE
  QUERY_THROUGHPUT_MULTIPLIER = 8;

適応型ウェアハウスを変換して標準に戻します。

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'STANDARD';

SHOW WAREHOUSES

適応型ウェアハウスの機能により、:doc:`SHOW WAREHOUSES </sql-reference/sql/show-warehouses>`コマンドに新しい列が導入されます。適応型ウェアハウスに適用されないプロパティは、``NULL``として表示されます。

適応型ウェアハウスに固有の列には、次のものがあります。

列名

説明

STATE

次のいずれか:

  • ENABLED(アクティブ/実行中)

  • DISABLED(非アクティブ)

MAX_QUERY_PERFORMANCE_LEVEL

Tシャツのサイズとして表されます。ステートメントごとのパフォーマンスレベルの上限。

QUERY_THROUGHPUT_MULTIPLIER

ウェアハウスが任意の時点で使用できるバースト容量を制御する整数のスケール係数。

DISABLED_REASONS

適応型ウェアハウスが無効になった1つ以上の理由。

アカウント使用状況ビュー

次のACCOUNT_USAGEビューは適応型ウェアハウスで利用できます。

注釈

適応型ウェアハウスの場合、QASの使用状況はコンピューティングクレジットに含まれ、個別のクレジット列としては表示されません。:doc:`/sql-reference/account-usage/warehouse_load_history`を使用してキューの動作をモニタリングし、MAX_QUERY_PERFORMANCE_LEVELまたはQUERY_THROUGHPUT_MULTIPLIERを調整する必要があるかどうかを把握します。

次のサンプルクエリは、指定されたルックバック期間内に``ADAPTIVE``状態のクエリを少なくとも1つ実行したウェアハウスについて、ウェアハウスレベルのパフォーマンスデータの時系列を生成しています。

WITH adaptive_whs AS (
  SELECT DISTINCT warehouse_name
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
  WHERE q.warehouse_size = 'ADAPTIVE'
    AND q.start_time >= DATEADD(day, -7, CURRENT_DATE())
)
SELECT
  q.end_time::DATE AS ds,
  q.warehouse_name,
  IFF(q.warehouse_size = 'ADAPTIVE', 'ADAPTIVE', 'STANDARD') AS warehouse_type,
  AVG(q.total_elapsed_time) AS avg_query_time,
  AVG(q.execution_time) AS avg_exec_time,
  AVG(q.queued_overload_time) AS avg_queued_overload_time,
  AVG(q.queued_provisioning_time) AS avg_queued_provisioning_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
WHERE q.start_time >= DATEADD(day, -7, CURRENT_DATE())
  AND q.warehouse_name IN (SELECT warehouse_name FROM adaptive_whs)
GROUP BY ALL;

適応型への標準ウェアハウスの一括移行

多くの標準ウェアハウスを同時に適応型に移行する必要がある場合は、SYSTEM$BULK_UPDATE_WH関数を使用します。

SYSTEM$BULK_UPDATE_WH関数のパラメーター

パラメーター

説明

許可された値

property_name

更新するウェアハウスのプロパティ。

'WAREHOUSE_TYPE'

new_value

プロパティの新しい値。

'ADAPTIVE' または 'STANDARD'

property_filter

ウェアハウスのプロパティに適用されるJSONフィルター(名前パターン、サイズなど)。すべてのフィルターに一致するウェアハウスは更新の対象とみなされます。

'{"name": "TEST.*"}'

tag_filter

タグに適用されるJSONフィルター。ウェアハウスが選択されるには、指定されたすべてのタグに一致する必要があります。

'{"cost-centre": "sales"}'

execution_mode

操作モード: 更新またはドライランを実行します。

'ACTIVE''DRY_RUN'

提案された使用法:

  1. まず、ドライランを実行し結果を確認します。

    SELECT SYSTEM$BULK_UPDATE_WH(
      'WAREHOUSE_TYPE',
      'ADAPTIVE',
      '{"WAREHOUSE_TYPE": "STANDARD"}',
      'DRY_RUN'
    );
    
  2. 出力を確認し、必要に応じてフィルターを調整します。

  3. ドライランを確認した後、アクティブモードを使用して関数を再度呼び出します。

    SELECT SYSTEM$BULK_UPDATE_WH(
      'WAREHOUSE_TYPE',
      'ADAPTIVE',
      '{"WAREHOUSE_TYPE": "STANDARD"}',
      'ACTIVE'
    );
    
  4. 処理を繰り返すまたは移行範囲を拡大する前に、結果とエラーを慎重に確認してください。