タスクの紹介

タスクは、次に挙げる型の SQL コードのいずれかを実行できます。

  • 単一の SQL ステートメント

  • ストアドプロシージャへの呼び出し

  • Snowflakeスクリプト を使用した手続き型ロジック

タスクを テーブルストリーム と組み合わせて、連続して ELT ワークフローを実行し、最近変更されたテーブル行を処理できます。ストリームは、テーブル内の新しいデータまたは変更されたデータのセマンティクスを1回だけ保証します。

また、行のレポートテーブルへの挿入またはマージにより定期的なレポートを生成したり、他の定期的な作業を実行したりするために、タスクを独立して使用することもできます。

このトピックの内容:

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

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

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

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

サーバーレスタスク

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

サーバーレスコンピューティングモデルを有効にするオプションは、タスクの作成時に指定する必要があります。 CREATE TASK 構文は、ユーザー管理の仮想ウェアハウスに依存するタスクとほぼ同じです。Snowflakeがタスクのコンピューティングリソースを管理できるようにするには、 WAREHOUSE パラメーターを省略します。CREATE TASK コマンドを実行するロールには、 EXECUTE MANAGED TASK グローバル権限が必要であることに注意してください。タスクのアクセス制御要件の詳細については、 タスクセキュリティ をご参照ください。

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

注釈

サーバーレスタスクは、次のオブジェクト型と関数を呼び出すことができません。

  • JavaまたはPythonコードを含むUDFs(ユーザー定義関数)。

  • Scalaで(Snowparkを使用して)作成された、またはJavaまたはPythonコードを含むUDFsを呼び出すストアドプロシージャ。

ユーザー管理のタスク

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

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

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

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

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

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

Example task batch window

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

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

Example DAG batch window

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

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

カテゴリ

サーバーレスタスク

ユーザー管理のタスク

メモ

同時タスクワークロードの数、期間、および予測可能性

同時に実行されるタスクが少なすぎるか、完了までの時間が短い(1分未満)ためウェアハウスを十分に活用できない場合に推奨されます。

選択されたコンピューティングリソースのサイズは、以前の実行の履歴に基づいているため、実行が比較的安定しているタスクは、サーバーレスタスクの候補として適しています。

使用可能なコンピューティングリソースを活用するために複数の同時タスクをスケジュールすることで、単一のウェアハウスを最大限に活用できる場合に推奨されます。

また、コンピューティングリソースの急激な負荷や予測不可能な負荷にも推奨されます。 自動一時停止と自動再開 を有効にした マルチクラスターウェアハウス は、クレジットの消費を抑えるために役立ちます。

サーバーレスタスクの場合、Snowflakeは実際のコンピューティングリソースの使用量に基づいてアカウントに請求します。

対照的に、ユーザー管理のウェアハウスの請求はウェアハウスのサイズに基づいており、使用されたコンピューティングリソースに関係なく、ウェアハウスが再開されるたびに最低60秒の請求があります。

スケジュール間隔

スケジュール間隔の順守が非常に重要な場合に推奨されます。

スタンドアロンタスクまたはスケジュールされた DAG の実行がこの間隔のほぼすべてを超える場合、Snowflakeはコンピューティングリソースのサイズを増加します(最大2XLウェアハウス相当まで)。

スケジュール間隔の順守がそれほど重要でない場合に推奨されます。

スケジュール間隔 は、スタンドアロンタスクまたは DAG 内にあるルートタスクのスケジュールされた連続実行間における時間間隔を指します。

コンピューティングリソースを増加すると、一部(すべてではなく)の SQL コードの実行時間が短縮され、バッチウィンドウ内でタスクの実行を確実に完了するには不十分な場合があることに注意してください。

サーバーレスタスク実行の最大サイズは、 XXLARGE ウェアハウスに相当することに注意してください。タスクのワークロードでより大きなウェアハウスが必要な場合は、必要なサイズのウェアハウスを参照するユーザー管理タスクを作成します。

タスクのスケジュール

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

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

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

タスクのスケジューリングと夏時間

タスク定義のcron式は、タイムゾーンの指定をサポートしています。スケジュールされたタスクは、指定されたタイムゾーンのローカル時間で指定されたcron式に従って実行されます。夏時間を認識するタイムゾーンのタスクのスケジュールに関しては、特別な注意が必要です。標準時間から夏時間への移行(またはその逆)が発生する日の特定の時間にスケジュールされたタスクは、予期しない動作をする可能性があります。

例:

  • 夏時間から標準時間への秋の変更中に、米国/ロサンゼルスタイムゾーンの1 AM (つまり 0 1 * * * America/Los_Angeles)で開始するようにスケジュールされたタスクは、 2回 実行されます。1 AM そして、1:59:59 AM が現地時間の1:00:00 AM にシフトしたときに再び実行されます。つまり、現地時間が1 AMである時点は2つあります。

  • 春から標準時間への夏時間の変更中、米国/ロサンゼルスタイムゾーンの2 AM (つまり 0 2 * * * America/Los_Angeles)で開始するようにスケジュールされたタスクは、ローカル時間が1:59:59 AM から3:00:00 AMへシフトするため まったく実行されません 。つまり、その日のローカル時間が2 AMであるポイントはありません。

夏時間による予期しないタスクの実行を避けるため、 次のいずれかを使用します:

  • 次のタイミングでに実行するようにタスクをスケジュールしないでください:1 AM と3 AM の間の特定の時間(毎日、または日曜日を含む曜日)、 または

  • 毎年2回、これらの時間帯にスケジュールされたタスクのcron式を手動で調整して、夏時間による時間の変更を補正する、 または

  • UTC など、夏時間を適用しない時刻形式を使用する。

タスクのDAG

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

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

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

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

Basic DAG example

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

Sales database DAG example

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

Cloud messaging notification DAG example

タスクの所有権

DAGのすべてのタスクには、同じタスク所有者が必要で(つまり、単一のロールにはすべてのタスクに対するOWNERSHIP権限が必要)、同一のデータベースとスキーマに保存されていなければなりません。

タスクの所有権を譲渡すると、このタスクと先行タスクおよび子タスクの間の依存関係が切断されます。詳細については、 先行タスクと子タスクの間で切断されたリンク (このトピック内)をご参照ください。

DAG 内にある すべて のタスクの所有権が、次のアクティビティのいずれかを介して一度に転送されると、 DAG 内にあるすべてのタスク間のリンクが保持されます。

  • DAGを構成するすべてのタスクの現在の所有者は削除されます(DROP ROLE を使用)。ドロップされたロールが所有するオブジェクトの所有権は、 DROP ROLE コマンドを実行するロールに転送されます。

  • DAGを構成するすべてのタスクの所有権は、明示的に別のロールに譲渡されます(例えば、スキーマ内のすべてのタスクで GRANT OWNERSHIP を実行することにより)。

重複するDAGの実行

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

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

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

Overlapping DAG runs

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での依存タスクの表示

ルートタスクの直接の子タスクまたは DAG 内のすべてのタスクを表示するには、

SQL

TASK_DEPENDENTS テーブル関数(Snowflake Information Schema 内)をクエリします。DAG内の すべての タスクを取得するには、関数を呼び出すときにルートタスクを入力することに注意してください。子タスクを入力すると、関数は指定されたタスクの子(およびそれらの子の子など)を返します。

中断された子タスクでのDAGの実行

ルートタスクが一時停止されている場合、 ALTER TASK ... RESUME | SUSPENDを使用して子タスクを再開または一時停止できます。ルートタスクを再開する前に、中断された子タスクを再開する必要はありません。

DAGが1つ以上の中断された子タスクで実行される場合、実行はそれらのタスクを無視します。複数の先行タスクを持つ子タスクは、 少なくとも1つ の先行タスクが再開状態にある限り実行され、再開されたすべての先行タスクは正常に完了します。

DAGでの中断されたタスクの再開

DAG内のすべてのタスクを再帰的に再開するには、各タスクを個別に再開するのではなく、 SYSTEM$TASK_DEPENDENTS_ENABLE 関数をクエリします(ALTER TASK ... RESUMEを使用)。

ファイナライザタスク

ファイナライザタスクは DAG が使用するリソースのリリースとクリーンアップを処理します。ファイナライザタスクは DAG が実行された場合に実行が保証され、すべてのシナリオで適切なリソースのクリーンアップと必要なステップの完了が保証されます。例えば、 DAG の実行が中間テーブルを使用して処理対象のデータを追跡し、テーブルの行が消費される前に失敗した場合、次の実行で重複行が発生し、データが再処理されるため、実行時間が長くなることや、コンピューティングリソースが浪費されることがあります。ファイナライザタスクは、必要に応じて行を削除したり、テーブルを切り詰めたりすることで、この問題に対処できます。

ファイナライザタスクは DAG 内の他のタスクと同じように動作しますが、次の違いがあります。

  • ファイナライザタスクは常にルートタスクと関連付けられます。各ルートタスクにはファイナライザタスクを1つのみ指定でき、ファイナライザタスクは1つのルートタスクのみに関連付けることができます。

  • ファイナライザタスクは、現在の DAG の実行で他のタスクが実行中またはキューに入っておらず、グラフ内の少なくとも1つのタスクが実行を開始している場合にのみスケジュールされます。グラフがスキップされた場合(例えば、ルートタスクがスキップされた場合)、ファイナライザタスクは実行されません。ALLOW_OVERLAPPING_EXECUTION がtrueの場合、ファイナライザタスクは他のタスクと同じように動作し、他に進行中の DAG の実行があったとしてもスケジュールされます。

  • ファイナライザタスクには子タスクを指定できません。ファイナライザタスクを先行タスクにしようとするコマンドは失敗します。ファイナライザタスクの作成には FINALIZE キーワードを含める必要がありますが、これは SCHEDULEAFTER キーワードの両方と互換性がありません。

ファイナライザタスクを作成するには、 FINALIZE キーワードを使用してタスクを作成し、ルートタスクとの関係を設定します。

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

詳細については、 CREATE TASK をご参照ください。

注釈

Snowsight では、ファイナライザタスクは独自の実行履歴と構成詳細を持つ別のタスクとして表示されます。タスクグラフビューには、ファイナライザタスクや、ルートタスクとファイナライザタスクの関係は表示されません。

実行のバージョニング

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

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

注釈

タスクのDAGの実行中にタスクによって呼び出されるストアドプロシージャの定義が変更された場合、現在実行中のタスクによってストアドプロシージャが呼び出されたときに、新しいプログラミングを実行できます。

例えば、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_NUM_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;
Copy

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

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

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

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

タスク DDL

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

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

タスク関数

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

タスクセキュリティ

アクセス制御権限

タスクの作成

タスクを作成するには、少なくとも次の権限を持つロールが必要です。

オブジェクト

権限

メモ

アカウント

EXECUTE MANAGED TASK

Snowflakeが管理するコンピューティングリソース(サーバーレスコンピューティングタスク)に依存するタスクにのみ必要です。

データベース

USAGE

スキーマ

USAGE, CREATE TASK

ウェアハウス

USAGE

コンピューティングリソースをユーザー管理のウェアハウスに依存するタスクにのみ必要です。

所有タスク

タスクが作成された後、タスクの所有者(つまり、タスクに対する OWNERSHIP 権限を持つロール)には、次の権限が必要です。

オブジェクト

権限

メモ

アカウント

EXECUTE TASK

ロールが所有するタスクを実行するために必要です。ロールの EXECUTE TASK 権限を取り消すと、それ以降、すべてのタスクの実行はそのロールで開始できなくなります。

アカウント

EXECUTE MANAGED TASK

Snowflake管理のコンピューティングリソースに依存するタスクにのみ必要です。

データベース

USAGE

スキーマ

USAGE

タスク

OWNERSHIP

ウェアハウス

USAGE

またロールは、タスクによって実行される SQL ステートメントの実行に必要な権限を持っている必要があります。

タスクの再開または一時停止

タスクの所有者に加えて、タスクに対するOPERATE権限を持つロールは、タスクを一時停止または再開できます。このロールには、タスクを含むデータベースとスキーマに対するUSAGE権限が必要です。他の権限は必要ありません。

タスクが再開されると、Snowflakeは、タスクの所有者のロールが 所有タスク (このトピック内)にリストされている権限を持っていることを確認します。

タスク管理者ロールの作成

使いやすくするために、カスタムロール(例: taskadmin)を作成し、このロールに EXECUTE TASK 権限を割り当てることをお勧めします。権限を付与できるロール(例: SECURITYADMIN または MANAGE GRANTS 権限を持つ任意のロール)は、このカスタムロールを任意のタスク所有者ロールに付与して、自身のタスクの変更を許可できます。タスク所有者ロールがタスクを実行する機能を削除するには、このカスタムロールをタスク所有者ロールから取り消すだけです。このカスタムロールを作成しないことを選択した場合、アカウント管理者はタスク所有者ロールから EXECUTE TASK 権限を取り消す必要があることに注意してください。

たとえば、カスタムロール名 taskadmin を作成し、そのロールに EXECUTE TASK 権限を付与します。 myrole という名前のタスク所有者ロールに taskadmin ロールを割り当てます。

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;
Copy

カスタムロールとロール階層の作成の詳細については、 アクセス制御の構成 をご参照ください。

タスク所有者ロールの削除

特定のタスクの所有者のロール(つまり、タスクに対する OWNERSHIP 権限を持つロール)が削除されると、所有者のロールをドロップしたロールによってタスクが「再所有」されます。これにより、所有権がロール階層のルートにより近いロールに移動します。タスクが再所有されると、タスクは自動的に一時停止します。つまり、現在実行中のすべての実行は処理を完了しますが、新しい所有者によってタスクが明示的に再開されるまで、新しい実行はスケジュールされません。これの理由は、特定のロールへのアクセス権限を持つユーザーが、ロールが削除されたときに、高いアクセス許可で突然実行されるタスクを残さないようにすることです。

実行中のタスクが実行されているロールがタスクの実行中に削除された場合、タスクは削除されたロールの下で処理を完了します。

ワークフロー

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

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

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

    注釈

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

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