Snowflakeインタラクティブテーブルとインタラクティブウェアハウス¶

インタラクティブウェアハウスの制限¶

• Snowflakeインタラクティブウェアハウスは、長時間実行されるクエリをサポートしていません。SELECT コマンドのクエリのタイムアウトは、デフォルトで5秒です。5秒後、クエリはキャンセルされます。クエリのタイムアウト値を減らすことはできますが、増やすことはできません。SHOW および INSERT OVERWRITE など、他の種類のコマンドは5秒間のタイムアウトの対象ではありません。

  インタラクティブウェアハウスは、長時間実行されるクエリでの使用を目的としていません。クエリが常にタイムアウトする場合は、インタラクティブウェアハウスでの使用に適していない可能性があることを示しています。そうでない場合は、パフォーマンスチューニングの手法を適用して、時間を5秒未満にする必要があります。

• インタラクティブウェアハウスは、設計上、常に実行状態にあります。アイドル状態のときに自動的に一時停止しません。インタラクティブウェアハウスを手動で一時停止することはできますが、ウェアハウスの再開時に、大幅なクエリレイテンシが発生することが予想されます。

• インタラクティブウェアハウスから標準のSnowflakeテーブルをクエリすることはできません。同じセッションで標準テーブルとインタラクティブテーブルの両方をクエリするには、 USE WAREHOUSE を実行して、テーブルのタイプに応じて、適切なウェアハウスタイプに切り替えます。

• インタラクティブウェアハウスがマルチクラスターウェアハウスの場合は、自動スケーリングされません。マルチクラスターインタラクティブウェアハウスでは、常に MIN_CLUSTER_COUNT および MAX_CLUSTER_COUNT を同じ値に設定します。

• CALL コマンドを実行して、インタラクティブウェアハウスでストアドプロシージャを呼び出すことはできません。

• ->> パイプ演算子は使用できません。この演算子は、バックグラウンドでストアドプロシージャを使用します。

• インタラクティブウェアハウスは現在、複製をサポートしていません。フェールオーバーグループや複製グループには含まれません。

インタラクティブテーブルの制限¶

• インタラクティブテーブルは以下の機能をサポートしていません。

  • UPDATE および DELETE などのデータ操作言語（ DML ）コマンド。実行できる DML は INSERT OVERWRITE だけです。

  • 複製。フェールオーバーグループや複製グループには含まれません。

• クエリインサイトは現在、インタラクティブテーブルで実行されているクエリでは収集または利用できません。

• 以下の操作は実行できません。

  • マテリアライズドビューのソースとしてインタラクティブテーブルを使用する。

  • ADD COLUMN または REMOVE COLUMN などの ALTER TABLE 句を使用して、インタラクティブテーブルのプロパティを変更する。可能な ALTER TABLE 変更は、テーブル名の変更のみ。

  • インタラクティブテーブルでデータマスキングポリシーを使用する。

  • インタラクティブテーブルで結合ポリシーを使用する。

  • インタラクティブテーブルで集約ポリシーを使用する。

  • インタラクティブテーブルで行アクセスポリシーを使用する。

  • インタラクティブテーブルでストリームを使用する。

  • ベーステーブルとしてインタラクティブテーブルを使用して動的テーブルを作成する。

  • インタラクティブテーブルのクエリに RESAMPLE 句を使用する。

インタラクティブテーブルの作成¶

テーブル作成は、標準 CTAS （ CREATE TABLE AS SELECT ）構文と、テーブルタイプを定義する追加の INTERACTIVE キーワードに従います。

CREATE INTERACTIVE TABLE コマンドには CLUSTER BY 句も必要です。CLUSTER BY 句で1つ以上の列を指定して、最もタイムクリティカルなクエリで WHERE 句と一致させます。CLUSTER BY 句で指定する列は、インタラクティブテーブルでのクエリのパフォーマンスに大きな影響を与える可能性があります。したがって、クラスタリング列を慎重に選択してください。最適なクラスタリング列の選択の詳細については、 クラスタリングキーとクラスタ化されたテーブル を参照してください。

次のコマンドは、標準テーブルと同じ列とデータを含むインタラクティブテーブルを作成します。CLUSTER BY 句は、ソーステーブルから id という列を参照します。

CREATE INTERACTIVE TABLE IF NOT EXISTS orders CLUSTER BY (id) AS SELECT * FROM demoSource; 

インタラクティブテーブルの自動リフレッシュの指定¶

他のテーブルのデータを使用してインタラクティブテーブルが自動的にリフレッシュされるようにするには、 TARGET_LAG 句と間隔を指定します。TARGET_LAG を指定する場合、 WAREHOUSE 句と、Snowflakeがリフレッシュ操作を実行するために使用する標準ウェアハウスの名前も指定する必要があります。

TARGET_LAG 句の時間間隔では、秒、分、時間、または日数の最大ラグを指定できます。

TARGET_LAG = '<num> { seconds | minutes | hours | days }' 

単位を指定しない場合、数値は秒を表します。最小値は60秒または1分です。

たとえば、次の CREATE INTERACTIVE TABLE ステートメントは、指定されたソーステーブルから20分以上遅れない動的インタラクティブテーブルを定義し、 my_standard_warehouse という標準ウェアハウスを使用してリフレッシュ操作を実行します。

CREATE INTERACTIVE TABLE my_dynamic_interactive_table CLUSTER BY (c1, c2) TARGET_LAG = '20 minutes' WAREHOUSE = my_standard_warehouse AS SELECT c1, SUM(c2) FROM my_source_table GROUP BY c1; 

データのコストと鮮度のバランスをとる適切なラグタイムの選択に関する詳細については、 動的テーブルの最適ターゲットラグの決定 をご参照ください。インタラクティブテーブルにも動的テーブルと同様の考慮事項が適用されます。

インタラクティブウェアハウスの作成¶

インタラクティブテーブルを作成した後、そのテーブルを最適なパフォーマンスでクエリするには、インタラクティブウェアハウスが必要です。CREATE WAREHOUSE で INTERACTIVE キーワードを指定するか、 CREATE OR REPLACE WAREHOUSE コマンドを指定します。

オプションで、インタラクティブテーブル名のコンマ区切りリストで TABLES 句を指定できます。その句を使用すると、これらのインタラクティブテーブルがインタラクティブウェアハウスにすぐに関連付けられます。

次のコマンドは、 orders というインタラクティブテーブル名と関連付けられているインタラクティブウェアハウスを作成します。この場合、すぐにインタラクティブウェアハウスの USE WAREHOUSE コマンドを実行でき、インタラクティブテーブルのクエリの実行を開始できます。

CREATE OR REPLACE INTERACTIVE WAREHOUSE interactive_demo TABLES (orders) WAREHOUSE_SIZE = 'XSMALL'; 

次のコマンドは、関連付けられたインタラクティブテーブルのないインタラクティブウェアハウスを作成します。この場合、後で ALTER WAREHOUSE コマンドを実行して、インタラクティブテーブルをインタラクティブウェアハウスに関連付けます。

CREATE or REPLACE INTERACTIVE WAREHOUSE interactive_demo WAREHOUSE_SIZE = 'XSMALL'; 

インタラクティブウェアハウスを作成した後、ウェアハウスはデフォルトで無期限にアクティブなままになります。従来のウェアハウスとは異なり、インタラクティブウェアハウスには、一定期間アイドル状態になった場合に自動的に一時停止するオプションが含まれていません。

インタラクティブウェアハウスのクエリのベストプラクティス¶

インタラクティブウェアハウスは、 選択的なワークロード を使用するクエリに最適化されています。つまり、選択性の高いクエリでは、他のクエリタイプよりもパフォーマンスが大幅に向上します。

SELECT col1, col4, AVG(col_x) FROM my_table GROUP BY col1, col2; 

SELECT * FROM my_table; 

SELECT col1, col2 FROM my_table WHERE col_x IN (1,4,7,8) AND event_time >= DATEADD(hour, -1, CURRENT_TIMESTAMP()); 

SELECT col1, col2 FROM my_table WHERE event_time >= DATEADD(day, -365, CURRENT_TIMESTAMP()); 

大規模な結合（2つのファクトテーブルを結合するなど）や正規表現などの計算負荷の高い式など、その他の複雑な状況では、コンピューティングリソースの使用量が多くなるため、同時実行性が低下する可能性があります。このような状況での最適化については、 インタラクティブウェアハウスのサイズの選択 をご参照ください。

インタラクティブテーブルのデータレイアウトのベストプラクティス¶

インタラクティブテーブルは、パフォーマンスのための標準的なSnowflakeベストプラクティスに従います。特に、インタラクティブテーブルは、 適切にクラスター化されたテーブル を活用します。これは、フィルタリングする同じ列に基づいてソートされるテーブルです。たとえば、クエリが sale_date などの TIMESTAMP 列で頻繁にフィルタリングする場合、インタラクティブテーブルを作成するときにその列をクラスタリングキーとして使用することは理にかなっています。たとえば、インタラクティブテーブルは次のように作成することができます。

CREATE INTERACTIVE TABLE product_sales (<column definitions>) CLUSTER BY (sale_date); 

そうすると、 sale_date でフィルタリングする SELECT クエリは、関係のないすべてのデータをすばやくスキップして結果を返すことができます。たとえば、次のクエリは sale_date 列をテストすることにより、日付範囲でフィルターします。

SELECT... WHERE sale_date > '2025-10-24' AND ... 

最適なクラスタリングキーの選択の詳細については、 クラスタリングキーとクラスタ化されたテーブル をご参照ください。

ポイントルックアップでの検索最適化の使用¶

インタラクティブテーブルでポイントルックアップクエリを実行する場合は、 検索最適化 を追加することをお勧めします。ポイントルックアップは、1つまたは数行のデータを取得するために単一の列でフィルタリングするクエリです。良い例として WHERE some_id = some_UUID があります。

インタラクティブウェアハウスのサイズの選択¶

すべてのクエリとレイアウトの最適化を完了したら、需要を満たすために ウェアハウスのスケーリング を検討します。インタラクティブウェアハウスには、 XSMALL から 3XLARGE までさまざまなサイズがあり、 マルチクラスターウェアハウス にも対応しています。

インタラクティブテーブルの 作業データセット のおおよそのサイズに基づいて、ウェアハウスのサイズを設定することから始めることをお勧めします。作業データセットとは、頻繁にクエリされるデータの部分を指します。たとえば、クエリが通常、過去7日間の売上データのみをクエリする場合、作業セットはその7日間に対応するインタラクティブテーブルの一部です。

これは、インタラクティブウェアハウスが ローカルストレージキャッシュ を利用するためです。データセット（テーブル）全体のデータには常にアクセスできますが、キャッシュされていないデータにアクセスすると、最初の読み込み時に高い読み込みレイテンシが発生します。

ワークロードのニーズに合わせてウェアハウスのサイズを選択します。特定のデータとワークロードを試して、インタラクティブウェアハウスの最適なサイズを決定します。インタラクティブなマルチクラスターウェアハウスを作成できます。ただし、現在、最小クラスター数と最大クラスター数は等しくなければなりません。つまり、インタラクティブマルチクラスターウェアハウスは自動的にスケーリングされません。

作業データセットのサイズに基づいて、次のウェアハウスサイズから始めることをお勧めします。

インタラクティブウェアハウスへのインタラクティブテーブルの追加¶

インタラクティブテーブルで最適なクエリパフォーマンスを得るには、インタラクティブウェアハウスを使用する必要があります。

インタラクティブウェアハウスからインタラクティブテーブルをクエリするには、1回限りの操作を実行してインタラクティブテーブルをインタラクティブウェアハウスに追加する必要があります。そうしないと、インタラクティブウェアハウスからそのようなテーブルに対してクエリを実行すると、「オブジェクトが見つかりません」というエラーが表示されます。CREATE INTERACTIVE WAREHOUSE コマンドで TABLES 句を使用してインタラクティブウェアハウスに関連付けるインタラクティブテーブルを指定しなかった場合は、後で ALTER WAREHOUSE コマンドを使用して指定できます。

次のコマンドは orders テーブルを interactive_demo ウェアハウスに関連付けます。ADD TABLES 句を使用して、コンマで区切って複数のテーブル名を指定できます。

ALTER WAREHOUSE interactive_demo ADD TABLES (orders); 

このアクションにより、キャッシュのウォームアッププロセスが開始されます。そのプロセスはかなりの時間がかかる場合があります。

インタラクティブテーブルがインタラクティブウェアハウスに既に関連付けられている場合、コマンドは成功しますが、効果は反映されません。

インタラクティブテーブルは、複数のインタラクティブウェアハウスに関連付けることができます。

インタラクティブウェアハウスからのインタラクティブテーブルの削除¶

インタラクティブウェアハウスから1つ以上のインタラクティブテーブルをデタッチするには、 DROP TABLES 句を使用して ALTER WAREHOUSE コマンドを実行します。

ALTER WAREHOUSE interactive_demo DROP TABLES (orders, customers); 

ウェアハウスの再開または一時停止¶

次のコマンドは、インタラクティブウェアハウスを再開します。ウェアハウスは一時停止状態で作成されるため、作成後にこれを行う必要があります。

ALTER WAREHOUSE interactive_demo RESUME; 

また、ウェアハウスを手動で一時停止した場合は、同じようにしてウェアハウスを介してクエリの実行を開始します。

再開後のキャッシュのウォームアップ中、クエリは遅くなります。そのテーブルにあるデータの量によっては、数分から1時間ほどかかる場合があります。

次のコマンドは、インタラクティブウェアハウスを一時停止します。

ALTER WAREHOUSE interactive_demo SUSPEND; 

インタラクティブウェアハウスが長時間使用されない開発およびテスト環境では、ウェアハウスを一時停止することができます。実稼働環境では、通常、24時間多数の同時クエリを実行するワークロードや、クエリにとって低レイテンシが重要な場合に、インタラクティブウェアハウスを使用します。したがって、通常、実稼働環境で使用するインタラクティブウェアハウスを一時停止することはありません。Snowflakeは、インタラクティブウェアハウスを自動的に一時停止することはありません。

インタラクティブウェアハウスのドロップ¶

DROP WAREHOUSE コマンドを実行して、インタラクティブウェアハウスを完全に削除することができます。インタラクティブウェアハウスをドロップすると、そのウェアハウスとインタラクティブテーブルとの関連付けが削除されます。ただし、他のインタラクティブウェアハウスを使用して、それらの同じインタラクティブテーブルをクエリすることはできます。

インタラクティブテーブルのクエリ¶

クエリセッションでは、現在のセッションのウェアハウスがインタラクティブウェアハウスであることを確認してください。

USE WAREHOUSE interactive_demo; 

確認後、インタラクティブテーブルを通常通りにクエリできます。