タスクの紹介¶

サーバーレスタスク¶

タスクにサーバーレスコンピューティングモデルを使用すると、ユーザーが管理する仮想ウェアハウスではなく、Snowflakeが管理するコンピューティングリソースに依存できるようになります。Snowflakeは、ワークロードごとに必要なサーバーレスコンピューティングリソースのサイズ変更を自動的に行います。Snowflakeは、同じタスクの最近の実行に対する統計の動的分析に基づいて、特定の実行に対するサーバーレスコンピューティングリソースの理想的なサイズを決定します。サーバーレスタスクの最大コンピューティングサイズは、 XXLARGE ユーザー管理の仮想ウェアハウスと同等です。アカウント内の複数のワークロードが、共通のコンピューティングリソースのセットを共有します。

サーバーレスコンピューティング・モデルを使用するには、 CREATE TASK を使ってタスクを作成する際に、WAREHOUSE パラメーターを省略します。CREATE TASK コマンドを実行するロールには、 EXECUTE MANAGED TASK グローバル権限が必要であることに注意してください。タスクのアクセス制御要件の詳細については、 タスクセキュリティ をご参照ください。

サーバーレスタスクの実行に対する請求は、コンピューティングリソースを仮想ウェアハウスに依存するタスクの標準的なクレジット消費モデルとは異なります。詳細については、 タスクのコスト をご参照ください。

ユーザー管理のタスク¶

タスクの作成時に既存の仮想ウェアハウスを指定することで、個々のタスクのコンピューティングリソースを管理することもできます。このオプションでは、タスクによって実行される SQL アクションに適したサイズのウェアハウスを選択する必要があります。

ウェアハウスのサイズの選択¶

既存のウェアハウスを使用して個々のタスクにコンピューティングリソースを提供することを選択する場合は、 ウェアハウスに関する考慮事項 で説明されているベストプラクティスに従ってください。タスクに必要なコンピューティングクラスタを理解するには、ウェアハウスのサイズとクラスタリングに基づいて異なるウェアハウスを使用して、単一のタスクまたは タスクグラフ の平均実行時間を分析します。ウェアハウスが複数のプロセスで共有されているかどうかも考慮する必要があります。

タスクの平均実行時間を分析するには、 TASK_HISTORY アカウント使用状況表示 をクエリします。タスクのスケジュールされた時間と完了した時間の平均差は、タスクの予想される平均実行時間です。この差には、他のプロセスがウェアハウスのコンピューティングリソースを使用している間、タスクがキューに入っていた時間も含まれます。

タスクグラフの場合、先行タスクの実行が完了し、子タスクが起動された後、短いラグがあります。ウェアハウスの大きさは、複数の子タスクが同時に実行できる大きさを選びます。

次の図は、20秒間キューに入れられた単一のタスクが40秒間実行された、1分間のウィンドウを示しています。これは、タスクがスケジュールされてから最初の20秒間、他のプロセスがウェアハウスのリソースを使用していたことを意味します。

次の図は、実行ごとに平均で5分かかるタスクグラフを示しています。この図は、タスクグラフを2回実行して完了するウィンドウを示しています。このウィンドウでは、ルートタスクの開始がスケジュールされている時間から、最後の子タスクの実行が完了するまでが計算されます。

この例では、タスクグラフが実行されているウェアハウスは、他の並行処理と共有されています。これらの同時操作は、タスクグラフ内の各タスクの実行が終了し、次のタスクの実行が開始される前に、使用可能なすべてのリソースを消費します。その結果、各タスクのウィンドウには、他の操作が終了してコンピューティングリソースの放棄を待つ間、ある程度のキューイングが含まれます。

コンピューティングモデルの選択に関する推奨事項¶

次のテーブルでは、サーバーレスタスクとユーザー管理タスクのどちらを使用するかを決定するために役立つ、さまざまな要因について説明します。

サーバーレスタスク実行の最大サイズは、 XXLARGE ウェアハウスに相当します。タスクのワークロードでより大きなウェアハウスが必要な場合は、必要なサイズのウェアハウスを持つユーザー管理タスクを作成します。

タスクのスケジュール¶

通常、タスクはスケジュールに基づいて実行されます。 CREATE TASK を使用してタスクの作成時に、または ALTER TASK を使用してそれ以降にスケジュールを定義できます。

スタンドアロンタスクまたはタスクグラフのルートタスクは、通常、スケジュールに従って実行されます。 CREATE TASK を使用してタスクの作成時に、または ALTER TASK を使用してそれ以降にスケジュールを定義できます。

Snowflakeは スケジュールのタスクのうち1つのインスタンスのみが一度に実行されるようにします。次のスケジュールされた実行時間が発生したときにタスクがまだ実行されている場合、そのスケジュールされた時間はスキップされます。

Snowflakeは、サーバーレスタスクのコンピューティングリソースのサイズを自動的に変更およびスケールします。ユーザー管理タスクの場合、スケジュール内でワークロードを完了するために、タスクに適切なウェアハウスサイズを選択します。詳細については、 ウェアハウスのサイズの選択 をご参照ください。

トリガーされるタスク¶

トリガータスクを使用して、定義されたストリームに新しいデータがあるときだけ実行することができます。これにより、新しいデータがあるかどうか予測できないソースに頻繁にポーリングする一般的なユースケースが簡素化され、新しいデータがあるときに即座に処理することで遅延が短縮されます。

トリガーされたタスクは、定義されたストリームがデータを持ち、タスクの実行をトリガーするまで、計算リソースを使用しません。

トリガータスクの実行条件を以下に示します。

• 関連ストリームが追跡するテーブルでデータが変更されたとき。

• タスクが最初に再開されたとき、ストリームにすでにあるデータを消費します。

• トリガータスクは、ストリームが 古くなる のを防ぐために、12時間ごとにヘルスチェックを自動的に実行します。ストリームにデータがない場合、Snowflakeは計算リソースを使用せずに実行をスキップします。

CREATE TASK triggeredTask  WAREHOUSE = my_warehouse
  WHEN system$stream_has_data('my_stream')
  AS
    INSERT INTO my_downstream_table
    SELECT * FROM my_stream;

ALTER TASK triggeredTask RESUME;

ALTER TASK task SUSPEND;
ALTER TASK task UNSET SCHEDULE;
ALTER TASK task RESUME;

手動によるタスクの実行¶

EXECUTE TASK コマンドは手動でタスクの単一実行をトリガーします。このSQLコマンドは、運用環境でSQLコードを実行できるようにする前に、新規または変更されたタスクとをテストするのに役立ちます。

このSQLコマンドは、スクリプトまたはストアドプロシージャで直接呼び出すことができます。さらに、このコマンドは、外部データパイプライン内でタスクの統合をサポートします。Snowflakeアカウントへの認証と SQL アクションの承認が可能なサードパーティのサービスは、 EXECUTE TASK コマンドを実行してタスクを実行できます。

タスク実行のバージョニング¶

内のスタンドアロンタスクが最初に再開されると、タスクの初期バージョンが設定されます。スタンドアロンタスクは、このバージョンを使用して実行されます。タスクが中断および変更された後、スタンドアロンタスクが再開されるか、手動で実行されると、新しいバージョンが設定されます。

タスクが中断されると、今後スケジュールされるタスクの実行はすべてキャンセルされます。現在実行中のタスクは現在のバージョンを使用して実行され続けます。

例えば、タスクが中断されているが、このタスクのスケジュールされた実行がすでに開始されているとします。タスクの所有者は、タスクの実行中に、タスクによって呼び出されたSQLコードを変更します。タスクが実行され、タスクが実行を開始したときに最新だったバージョンのタスクを使用して、定義内の SQL コードが実行されます。タスクが再開されるか、手動で実行されると、タスクの新しいバージョンが設定されます。この新しいバージョンには、タスクへの変更が含まれています。

タスクバージョンの履歴を取得するには、 TASK_VERSIONS Account Usageビュー （SNOWFLAKE 共有データベース内）をクエリします。

失敗した実行後のタスクの自動中断¶

必要に応じて、指定された数の連続したタスクの実行が失敗するかタイムアウトになると、タスクを自動的に中断します。この機能は、Snowflakeクレジットを消費するタスクを中断することでコストを削減しますが、タスクは完了しません。

タスクに SUSPEND_TASK_AFTER_NUM_FAILURES = num パラメーターを設定します。パラメーターが 0 より大きい値に設定されると、タスクは指定された数の連続したタスクの実行が失敗するかタイムアウトになると、自動的に中断します。

CREATE TASK を使用してタスクの作成時に、または ALTER TASK を使用して後から、このパラメーターを定義できます。この値は Snowsight でも変更できます。

SUSPEND_TASK_AFTER_NUM_FAILURES パラメータは、アカウント、データベース、およびスキーマレベルでも設定できます。この設定は、変更されたオブジェクト内のすべてのタスクに適用されます。パラメーターをより低いレベルで明示的に設定すると、より高いレベルで設定されたパラメーター値が上書きされることに注意してください。

失敗したタスクの実行を自動的に再試行¶

タスクがFAILEDの状態で完了した場合、Snowflakeは自動的にタスクを再試行できます。タスクの自動再試行はデフォルトでは無効になっています。この機能を有効にするには、TASK_AUTO_RETRY_ATTEMPTSを0より大きい値に設定します。

エラー通知を使用するタスクは、再試行が失敗するたびに通知を送信します。詳細については、 エラー通知を送信するタスクの構成 をご参照ください。

アカウント、データベース、またはスキーマレベルで TASK_AUTO_RETRY_ATTEMPTS パラメーター値を明示的に設定すると、その変更は、次のスケジュールされた実行時に、変更されたオブジェクト内のタスクに適用されます（進行中の実行のすべての子タスクを含む）。

アクセス制御権限¶

タスクの権限を管理するためのカスタムロールの作成¶

カスタムロールを使用すると、Snowflakeの各アカウントまたはロールに付与された権限を簡単に管理できます。カスタムロールを使用するすべてのアカウントまたはロールの権限を変更するには、カスタムロールを更新します。または、カスタムロールを削除することで権限を取り消します。

USE SYSADMIN;

CREATE ROLE warehouse_task_creation
  COMMENT = 'This role can create user-managed tasks.';

USE ACCOUNTADMIN;

GRANT CREATE TASK
  ON SCHEMA schema1
  TO ROLE warehouse_task_creation;

GRANT USAGE
  ON WAREHOUSE warehouse1
  TO ROLE warehouse_task_creation;

USE SYSADMIN;

CREATE ROLE serverless_task_creation
  COMMENT = 'This role can create serverless tasks.';

USE ACCOUNTADMIN;

GRANT CREATE TASK
  ON SCHEMA schema1
  TO ROLE serverless_task_creation;

GRANT EXECUTE MANAGED TASK ON ACCOUNT
  TO ROLE serverless_task_creation;

USE ROLE securityadmin;

CREATE ROLE taskadmin;

USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;

USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

タスク所有者ロールのドロップ¶

タスクの所有者ロールをドロップすると、タスクは所有者ロールをドロップしたロールに所有権を移します。タスクの所有権が移ると、タスクは自動的に一時停止され、新しい所有者がタスクを再開するまで新しい実行はスケジュールされません。

タスクの実行中にロールを削除すると、タスクの実行はドロップされたロールの下で完了します。

システムサービスタスクの実行¶

Snowflakeは、タスク所有者の権限でタスクを実行しますが、タスクの実行はユーザーに関連付けられていません。代わりに、各実行はシステムサービスによって実行されます。タスクは特定のユーザーから切り離され、ユーザーのドロップ、認証の問題が原因によるロック、ロールの削除などにより発生する可能性のある複雑さを回避します。

タスクの実行はユーザーから切り離されているため、タスクの実行のクエリ履歴はシステムサービスに関連付けられています。そのため、このサービスにはユーザー認証情報がなく、いかなる個人もそのIDを引き受けることはできません。システムサービスのアクティビティはアカウントに制限されています。他の操作に適用されるのと同じ暗号化保護および他のセキュリティプロトコルがこのサービスに組み込まれています。