タスクの紹介¶

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

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

• Snowflake管理（つまり、サーバーレスコンピューティングモデル）

• ユーザー管理（つまり、仮想ウェアハウス）

ユーザー管理のタスク¶

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

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

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

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

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

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

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

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

タスクのスケジュール¶

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

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

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

タスクのDAG¶

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

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

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

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

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

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

重複するDAGの実行¶

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

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

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

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

ルートタスクで定義されたスケジュールに合わせてDAGを適切に調整するには、

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

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

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

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

実行のバージョニング¶

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

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

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

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

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

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

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

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

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

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

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

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

• ルートタスクは、DAG の 任意 の単一タスクの実行が、連続した実行で指定された回数失敗するかタイムアウトした後、自動的に中断します。

タスクの作成時に（CREATE TASK を使用して）、または後から（ALTER TASK を使用して）、このパラメーターを定義できます。この設定は、Snowflakeが管理するコンピューティングリソース（サーバーレスコンピューティングモデル）またはユーザー管理のコンピューティングリソース（仮想ウェアハウス）に依存するタスクに適用されます。

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

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

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

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

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

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

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

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

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

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

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

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

SQL

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

現在スケジュールまたは実行されている DAG 実行の詳細を表示するには、

SQL

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

過去60分間に正常に実行された、失敗した、またはキャンセルされた DAG の実行の履歴を表示するには、

SQL

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

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

タスクのコスト¶

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

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

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

Snowflake管理のリソース（つまり、サーバーレスコンピューティングモデル）

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

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

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

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

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

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 ビューをクエリします。アカウント管理者（つまり、 ACCOUNTADMIN ロールを持つユーザー）として、次のステートメントを実行します。

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

• 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 を実行して、タスク定義で指定されたパラメーターに基づいてタスクを実行できるようにします。