タスクの紹介¶

コンピューティングリソース¶

タスクには、 SQL コードを実行するためのコンピューティングリソースが必要です。次のコンピューティングモデルのいずれかを個々のタスクに選択できます。

• サーバーレスコンピューティングモデル

• ユーザー管理の仮想ウェアハウス

ユーザー管理のタスク¶

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

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

既存のウェアハウスを使用して個々のタスクにコンピューティングリソースを提供することを選択する場合は、 ウェアハウスに関する考慮事項 で説明されているベストプラクティスに従うことをお勧めします。ウェアハウスのサイズとクラスタリングに基づいて、特定のウェアハウスを使用して単一のタスクまたは タスクグラフ の平均実行時間を分析すること、およびウェアハウスが複数のプロセスで共有されているか、この単一のタスク（または）の実行専用であるかを分析することをお勧めします。

TASK_HISTORY Account Usageビュー （SNOWFLAKE 共有データベース内）をクエリします。タスクのスケジュールされた時間と完了した時間の平均差は、タスクがキューに入れられた期間を含む、タスクの予想される平均実行時間です。現在、他のプロセスがウェアハウス内のすべてのコンピューティングリソースを使用している場合、タスクはキューに入れられます。

タスクに定義された SQL ステートメントを（ステートメントの書き換え、またはストアドプロシージャの使用により）最適化できる場合を除き、これはタスクまたはタスクグラフの予想される平均実行時間になります。分析に基づいてウェアハウスの適切なサイズを選択し、タスクまたはタスクグラフがこのウィンドウ内で実行を完了することを確認します。

次の図は、20秒間キューに入れられた単一のタスクが40秒間実行された、1分間のウィンドウを示しています。

次の図は、実行ごとに平均で5分かかるタスクグラフを示しています。この図は、タスクグラフを2回実行して完了するウィンドウを示しています。このウィンドウでは、ルートタスクの開始がスケジュールされている時間から、タスクグラフ内の最後の子タスクの実行が完了するまでが計算されます。この例では、タスクグラフは、タスクグラフ内の各3タスクの実行中にキューに入れられる他の並行操作と共有されます。これらの同時操作は、タスクグラフ内の各タスクの実行が終了し、次のタスクの実行が開始される前に、使用可能なすべてのリソースを消費します。その結果、各タスクのウィンドウには、他の操作が終了してコンピューティングリソースを放棄するのを待つ間、ある程度のキューイングが含まれます。

このタスクグラフが専用のウェアハウスで実行された場合でも、先行タスクの実行が完了して子タスクが実行された後、わずかな遅れが予想されることに注意してください。ただし、他の操作と共有したリソースのキューは発生しません。選択するウェアハウスのサイズは、先行タスクによって同時にトリガーされる複数の子タスクに対応できる大きさでなければなりません。

タスクのスケジュール¶

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

Snowflakeは、スケジュールのあるタスクのインスタンス（スタンドアロンタスクまたはタスクグラフ内のルートタスクなど）が特定の時間に1つだけ実行されるようにします。次のスケジュールされた実行時間が発生したときにタスクがまだ実行されている場合、そのスケジュールされた時間はスキップされます。

Snowflakeは、サーバーレスタスクのコンピューティングリソースのサイズを自動的に変更およびスケールします。ウェアハウスに依存してコンピューティングリソースを提供するタスクの場合は、特定のタスクに適切なウェアハウスサイズを選択して、定義されたスケジュール内でワークロードを完了します。詳細については、 ウェアハウスのサイズの選択 （このトピック内）をご参照ください。

タスクグラフ¶

タスクグラフ、または有向非巡回グラフ（DAG）は、単一のルートタスクと追加のタスクで構成され、依存関係によって編成された一連のタスクです。単一方向の DAGs フロー、つまりシリーズの後半のタスクは、前のタスクの実行を促すことができません。各タスク（ルートタスクを除く）は複数の先行タスク（依存関係）を持つことができます。各タスクは、それに依存する複数の後続（子）タスクを持つこともできます。タスクは、その先行タスクがすべて正常に実行されて完了した後にのみ実行されます。

ルートタスクには、タスクグラフの実行を開始するスケジュールが定義されている必要があります。他の各タスクには、タスクグラフ内のタスクをリンクするための少なくとも1つの定義済みの先行タスクがあります。子タスクは、その先行タスクがすべて正常に実行されて完了した後にのみ実行されます。

新しいタスクを作成するとき（CREATE TASK ... AFTER を使用）またはそれ以降（ALTER TASK ... ADD AFTER を使用）に先行タスクを指定できます。タスクグラフは、合計で最大1000タスク（ルートタスクを含む）に制限されます。単一のタスクには、最大100個の先行タスクと100個の子タスクを含めることができます。

SQL または Snowsight を使用してタスクグラフを表示できます。 Snowsight でタスクグラフを表示するには、 個別のタスクグラフの表示 をご参照ください。

次の基本的な例では、ルートタスクはタスクBとCに同時に実行するように促します。タスクDは、タスクBとCの両方が実行を完了したときに実行されます。

次の実践的な例は、タスクグラフを使用して、ファクトデータを集計する前に販売データベースのディメンションテーブルを更新する方法を示しています。

さらなる例は、タスクグラフ内の終了タスクが外部関数を呼び出してリモートメッセージングサービスをトリガーし、以前のすべてのタスクが完了まで正常に実行されたという通知を送信することを示しています。

タスクグラフの重複実行¶

デフォルトでは、Snowflakeは特定のタスクグラフの1つのインスタンスのみが一度に実行できるようにします。ルートタスクの次の実行は、タスクグラフ内のすべてのタスクの実行が終了した後にのみスケジュールされます。これは、タスクグラフ内のすべてのタスクを実行するために必要な累積時間がルートタスクの定義で設定された、明示的にスケジュールされた時間を超える場合、タスクグラフの少なくとも1つの実行がスキップされることを意味します。動作は、ルートタスクのALLOW_OVERLAPPING_EXECUTIONパラメータによって制御されます。デフォルト値はFALSEです。パラメーター値を TRUE に設定すると、タスクグラフの重複実行が許可されます。

さらに、子タスクは、子タスクの すべての 先行タスクが自身の実行を正常に完了した後にのみ実行を開始します。時間のかかるSQL操作を実行するタスクは、タスクを先行タスクとして識別する子タスクの開始を遅らせます。

次の例では、タスクグラフの実行は、前の実行がまだ完了していないときに開始するようにスケジュールされています。重複期間、つまり並行性は赤色で示されます。この図は、各タスクがユーザー管理のウェアハウスで実行される前にキューに入れられた期間も示しています。サーバーレスコンピューティングリソースを使用する場合、キュー期間がないことに注意してください。

タスクグラフの重複実行によって実行される読み取り/書き込み SQL 操作が誤ったデータまたは重複するデータを生成しない場合、重複する実行は許容される（または望ましい）場合があります。ただし、他のタスクグラフの場合、タスク所有者（つまり、タスクグラフ内のすべてのタスクに対して OWNERSHIP 権限を持つロール）は、ルートタスクに適切なスケジュールを設定して、適切なウェアハウス（または、サーバーレスコンピューティングリソース）サイズを選択し、ルートタスクの次回の実行予定前に、タスクグラフのインスタンスが完了するようにする必要があります。

ルートタスクで定義されたスケジュールに合わせてタスクグラフを適切に調整するには、次を実行します。

1. 可能であれば、ルートタスクの実行間のスケジュール時間を増やします。

2. コンピューティングの負荷が大きいタスクは、サーバーレスコンピューティングリソースを使用するように変更することを検討します。タスクがユーザー管理のコンピューティングリソースに依存している場合は、タスクグラフで大規模または複雑な SQL ステートメントやストアドプロシージャを実行するためのウェアハウスサイズを拡大することを検討します。

3. 各タスクによって実行されるSQLステートメントまたはストアドプロシージャを分析します。並列処理を活用するようにコードを書き直すことができるかどうかを判断します。

上記の解決策のいずれも役に立たない場合は、ルートタスクで ALLOW_OVERLAPPING_EXECUTION = TRUE を設定して、タスクグラフの同時実行を許可する必要があるかどうかを検討してください。タスクの作成時に（CREATE TASKを使用）、または後で（ALTER TASKを使用）、このパラメーターを定義できます。

CREATE TASK <TASK_NAME> ...
... FINALIZE = <ROOT_TASK_NAME>

実行のバージョニング¶

タスクグラフ内のスタンドアロンタスクまたはルートタスクが最初に再開される（または、 EXECUTE TASK を使用して手動で実行される）と、タスクの初期バージョンが設定されます。タスクがルートタスクの場合は、タスクグラフ内にあるタスクすべてのプロパティすべてを含む、タスクグラフ全体のバージョンが設定されます。スタンドアロンタスクまたはタスクグラフは、このバージョンを使用して実行されます。タスクが中断および変更された後、スタンドアロンまたはルートタスクが再開されるか、手動で実行されると、新しいバージョンが設定されます。

タスクグラフ内にある任意のタスクを変更または再作成するには、最初にルートタスクを中断する必要があります（ALTERTASK ... SUSPEND を使用）。ルートタスクが中断されると、将来のスケジュールされたルートタスクの実行はすべてキャンセルされます。ただし、現在実行中のタスク（つまり、 EXECUTING 状態のタスク）がある場合、これらのタスクと子孫タスクは、現在のバージョンを使用して引き続き実行されます。

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

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

タスクのセッションパラメーターの設定¶

タスクを実行するセッションのセッションパラメーターを設定できます。これを実行するには、既存のタスクを変更し、目的のパラメーター値を設定します（ALTER TASK ... SET session_parameter = value[, session_parameter = value ... ] を使用）。

タスクは、すべてのセッションパラメーターをサポートします。完全なリストについては、 パラメーター をご参照ください。

タスクは、アカウントまたはユーザーのパラメーターを サポートしない ことに注意してください。

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

必要に応じて、指定された数の連続したタスクの実行が失敗するかタイムアウトになると、タスクを自動的に中断します。この機能は、Snowflakeクレジットを消費するタスクを中断することでコストを削減しますが、タスクは完了しません。失敗したタスク実行には、タスク本体の SQL コードがユーザーエラーを生成するかタイムアウトになった実行が含まれます。スキップ、キャンセル、またはシステムエラーが原因で失敗したタスク実行は不確定と見なされ、失敗したタスク実行の数には含まれません。

スタンドアロンタスクまたはタスクグラフのルートタスクに SUSPEND_TASK_AFTER_NUM_FAILURES = num パラメーターを設定します。パラメーターが 0 より大きい値に設定されている場合、次の動作がタスクグラフ内のスタンドアロンタスクまたはルートタスクの実行に適用されます。

• スタンドアロンタスクは、指定された数の連続したタスクの実行が失敗するかタイムアウトになると、自動的に中断します。

• タスクグラフ内の いずれかの 子タスクが連続して失敗するか、指定された回数だけタイムアウトになると、ルートタスクは自動的に中断されます。失敗またはタイムアウトした子タスクは中断されません。

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

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

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

EXECUTE TASK コマンドは、タスクに定義されたスケジュールとは関係なく、スケジュールされたタスク（スタンドアロンタスクまたはタスクグラフのルートタスクのいずれか）の単一の実行を手動でトリガーします。先行タスクが完了するにつれて、ルートタスクが正常に実行されると、ルートタスクが定義されたスケジュールで実行されたかのように、タスクグラフ内にある子タスクのカスケード実行がトリガーされます。

この SQL コマンドは、運用環境で SQL コードを実行できるようにする前に、新規または変更されたスタンドアロンタスクとタスクグラフをテストするのに役立ちます。

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

アカウントのタスク履歴を表示する¶

SQL または Snowsight を使用して、アカウントのタスク履歴を表示できます。 Snowsight でタスク履歴を表示するには、 Snowsight でのタスク履歴の表示 をご参照ください。

次のロール（または指定された権限を持つロール）は、 SQL を使用して、指定された日付範囲内のタスク履歴を表示できます。

• アカウント管理者（つまり、ACCOUNTADMIN ロールを持つユーザー）。

• タスク所有者（つまり、タスクに対する OWNERSHIP 権限を持つロール）。

• グローバル MONITOR EXECUTION 権限を持つ任意のロール。

単一のタスクの実行履歴を表示するには、

SQL:

TASK_HISTORY テーブル関数（ Snowflake Information Schema 内）をクエリします。

現在スケジュールまたは実行されているタスクグラフ実行の詳細を表示するには、次を実行します。

SQL:

CURRENT_TASK_GRAPHS テーブル関数（ Snowflake Information Schema 内）をクエリします。

過去60分間に正常に実行された、失敗した、またはキャンセルされたタスクグラフの実行の履歴を表示するには、次を実行します。

SQL:

COMPLETE_TASK_GRAPHS テーブル関数（ Snowflake Information Schema 内）をクエリします。

COMPLETE_TASK_GRAPHS ビュー ビュー（Account Usage 内）をクエリします。

タスクのコスト¶

SQL コードを実行するためのタスク実行に関連するコストは、タスクのコンピューティングリソースのソースによって異なります。

ユーザー管理のウェアハウス

Snowflakeは、タスク実行中のウェアハウスの使用量に基づいて、アカウントに クレジット使用状況 を請求します。これは、クライアントまたはSnowflakeウェブインターフェイスで、同じ SQL ステートメントを実行する際のウェアハウスの使用量と類似しています。秒あたりのクレジット請求と自動中断により、より大きなウェアハウスサイズから始めて、ワークロードに合わせてサイズを調整する柔軟性が得られます。

サーバーレスコンピューティングモデル

Snowflakeは、実際のコンピューティングリソースの使用量に基づいてアカウントに請求します。アクティブなときにクレジットを消費し、待機状態や過剰使用の可能性がある、顧客管理の仮想ウェアハウスとは対照的です。料金は、 コンピューティング時間 のクレジット使用状況で測定されたリソースの合計使用状況（クラウドサービスの使用状況を含む）に基づいて計算されます。

Snowflakeは、タスク履歴内のタスク実行を動的に分析して、サーバーレスコンピューティングリソースの理想的なサイズを決定し、これらのコンピューティングリソースを中断して、コストを節約します。Snowflakeはロード容量を管理し、需要を満たす最適なコンピューティングリソースを確保します。サーバーレスコンピュートリソースの管理コストを回収するため、Snowflakeはリソース消費量に 1.2倍の乗数 を適用します。サーバーレスコンピューティングモデルでも、ユーザー管理のウェアハウスよりもコンピューティングコストを大幅に削減できる場合があります。

タスクにより消費されたクレジット量を知る方法については、 Snowflakeサービス利用テーブル の「サーバーレス機能クレジットテーブル」をご参照ください。

請求 は、テーブルの自動クラスタリング、複製とフェールオーバー/フェールバック、Snowpipeなどの他のSnowflake機能と同様です。

特定のタスクに対する現在のクレジット使用状況を取得するには、 SERVERLESS_TASK_HISTORY テーブル関数をクエリします。タスク所有者として、次のステートメントを実行します。

SET num_credits = (SELECT SUM(credits_used)
  FROM TABLE(<database_name>.information_schema.serverless_task_history(
    date_range_start=>dateadd(D, -1, current_timestamp()),
    date_range_end=>dateadd(D, 1, current_timestamp()),
    task_name => '<task_name>')
    )
  );

Copy

条件:

<データベース名>

タスクを含むデータベースの名前です。

<タスク名>

タスクの名前。

すべてのサーバーレスタスクに対する現在のクレジット使用状況を取得するには、 SERVERLESS_TASK_HISTORY ビューをクエリします。アカウント管理者として、次のステートメントを実行します。

SELECT start_time,
  end_time,
  task_id,
  task_name,
  credits_used,
  schema_id,
  schema_name,
  database_id,
  database_name
FROM snowflake.account_usage.serverless_task_history
ORDER BY start_time, task_id;

システムサービスについて¶

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

タスクは、OPERATE 権限を持つ別のロールによってスケジュールされているか、EXECUTE TASK によって手動で実行されているかに関係なく、タスク所有者の権限で実行されます。

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

タスク DDL¶

タスクの作成と管理をサポートするために、Snowflakeは次の一連の特別な DDL コマンドを提供します：

• CREATE TASK

• ALTER TASK

• DROP TASK

• DESCRIBE TASK

• SHOW TASKS

さらに、プロバイダーは、次の標準アクセス制御 DDL を使用して、ELT に必要なデータベースオブジェクトへのアクセスを表示、許可、または取り消すことができます。

• GRANT <権限>

• REVOKE <権限>

• SHOW GRANTS

タスク関数¶

タスクに関する情報の取得をサポートするために、Snowflakeは次の SQL 関数のセットを提供します：

• SYSTEM$CURRENT_USER_TASK_NAME

• SYSTEM$TASK_RUNTIME_INFO

• TASK_HISTORY

• TASK_DEPENDENTS

タスクセキュリティ¶

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;

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

-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

ワークフロー¶

このセクションでは、タスク設定のワークフローの概要を説明します。

1. タスク管理者ロールの作成 （このトピック）のステップを完了して、次のステップのコマンドの実行に使用できるロールを作成します。

2. CREATE TASK を使用してタスクを作成します。タスクはデフォルトで中断されています。

   注釈

   タスクを作成する 前に 、タスクで参照する SQL ステートメントが期待どおりに実行されることを確認します。タスクは、すでに徹底的にテストされている SQL ステートメントまたはストアドプロシージャを自動化することを目的としています。

3. ALTER TASK ... RESUME を実行して、タスク定義で指定されたパラメーターに基づいてタスクを実行できるようにします。