タスクの紹介

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

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

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

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

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

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

このトピックの内容:

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

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

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

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

サーバーレスタスク

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

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

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

注釈

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

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

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

Tip

サーバーレスタスクはハイブリッドテーブルの使用をサポートしていますが、ハイブリッドテーブルの使用中に最適なパフォーマンスや効率が得られない場合があります。

ユーザー管理のタスク

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

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

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

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

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

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

タスクバッチウィンドウの例

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

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

タスクグラフバッチウィンドウの例

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

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

カテゴリ

サーバーレスタスク

ユーザー管理のタスク

メモ

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

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

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

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

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

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

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

スケジュール間隔

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

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

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

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

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

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

タスクのスケジュール

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

Snowflakeは、スケジュールのあるタスクのインスタンス(スタンドアロンタスクまたはタスクグラフ内のルートタスクなど)が特定の時間に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)は、単一のルートタスクと追加のタスクで構成され、依存関係によって編成された一連のタスクです。単一方向の DAGs フロー、つまりシリーズの後半のタスクは、前のタスクの実行を促すことができません。各タスク(ルートタスクを除く)は複数の先行タスク(依存関係)を持つことができます。各タスクは、それに依存する複数の後続(子)タスクを持つこともできます。タスクは、その先行タスクがすべて正常に実行されて完了した後にのみ実行されます。

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

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

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

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

基本的なタスクグラフの例

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

販売データベースのタスクグラフの例

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

クラウドメッセージング通知タスクグラフの例

タスクの所有権

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

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

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

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

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

タスクグラフの重複実行

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

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

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

タスクグラフの重複実行

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

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

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

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

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

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

タスクグラフでの依存タスクの表示

ルートタスクの直接の子タスクまたはタスクグラフ内のすべてのタスクを表示するには、次を実行します。

SQL:

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

中断された子タスクでのタスクグラフの実行

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

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

タスクグラフでの中断されたタスクの再開

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

ファイナライザータスク

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

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

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

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

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

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

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

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

注釈

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

実行のバージョニング

タスクグラフ内のスタンドアロンタスクまたはルートタスクが最初に再開される(または、 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;
Copy

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

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

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

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

タスク DDL

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

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

タスク関数

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

タスクセキュリティ

アクセス制御権限

タスクの作成

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

オブジェクト

権限

メモ

アカウント

EXECUTE MANAGED TASK

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

データベース

USAGE

スキーマ

USAGE, CREATE TASK

ウェアハウス

USAGE

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

所有タスク

タスクが作成された後、タスク所有者はタスクを実行するために次の権限を持つ必要があります。

オブジェクト

権限

メモ

アカウント

EXECUTE TASK

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

アカウント

EXECUTE MANAGED TASK

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

データベース

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