EXECUTE TASK¶

構文¶

EXECUTE TASK <name>
  [ USING CONFIG = <configuration_string> ]

EXECUTE TASK <name> RETRY LAST

パラメーター¶

name

実行するスタンドアロンタスクまたはルートタスクの識別子。識別子にスペースまたは特殊文字が含まれる場合は、文字列全体を二重引用符で囲む必要があります。二重引用符で囲まれた識別子も大文字と小文字が区別されます。

USING CONFIG = configuration_string

この1回の実行のための有効なJSON形式の構成文字列を指定します。このパラメーターは、動的に指定された構成で新しい実行を作成しますが、タスク定義は変更しません。

Snowflakeは、動的構成を デフォルト 構成とマージします。これは、CREATEまたはALTERを使用してタスク定義で設定したCONFIGパラメーターです。フィールドの照合のために、Snowflakeは動的に指定された値を使用します。一致しないフィールドの場合、Snowflakeはデフォルト構成の値を使用します。例については、 動的CONFIGを使用する をご参照ください。

構成文字列は、 CREATE TASK または ALTER TASK のCONFIGパラメーターと同じ形式に従います。

CONFIG = $${"string1": value1 [, "string2": value2, ...] }$$

Copy

Example:

CONFIG = $${"learning_rate": 0.2, "environment": "testing"}$$

Copy

RETRY LAST

失敗した name の タスクグラフ の最終タスクを失敗したタスクから再実行します。

タスクを再実行するには、以下の条件を満たす必要があります。

• 最後のタスクグラフ実行は状態が FAILED か CANCELED であること。

• タスクグラフは最後に実行されてから変更されていないこと。

• タスクグラフは過去14日以内に実行または再試行されていること。

To view task history, see either the TASK_HISTORY table function or the Tasks page on Snowsight.

注釈

RETRY LAST は、最後に失敗したタスクから実行を開始する新しいグラフ実行を作成します。

具体的には、 FAILED または CANCELED タスクの実行はすべて直ちに再実行され、関連する子タスクは、それらの先行タスクがすべて正常に実行された場合にスケジュールされます。

さらに、再試行によって生成される新しいタスクグラフ実行は、前回失敗したグラフ実行よりも1つ大きい ATTEMPT NUMBER を持ち、再試行された、つまり元のタスクグラフ実行と同じ GRAPH_RUN_GROUP_ID を共有します。

使用上の注意¶

• タスクを実行するには、タスクの OWNERSHIP または OPERATE 権限が必要です。

  EXECUTE TASK コマンドがタスク実行をトリガーすると、Snowflakeは、タスクに対する OWNERSHIP 権限を持つロールが、タスクに割り当てられたウェアハウスに対する USAGE 権限、およびグローバル EXECUTE TASK 権限を持っていることを確認します。それ以外の場合は、エラーが生成されます。

  OPERATE 権限を持つ別のロールが EXECUTE TASK を使用してタスクを実行する場合でも、タスクは常に元の所有者ロールの権限で実行されます。

• デフォルトでは、Snowflakeはタスク所有者ロールの権限を持つシステムユーザーを使用してタスクを実行します。特定のユーザーとしてタスクを実行するには、 EXECUTE AS USER でタスクを設定します。詳細については、 ユーザー権限でタスクを実行する をご参照ください。

• USING CONFIGオプションの場合:

  • タスクグラフが現在実行中で、このコマンドを実行すると、Snowflakeは現在の実行が完了するのを待ってから、動的構成で新しい実行を開始します。

  • タスクの実行中にこのコマンドを複数回実行すると、Snowflakeは次の実行で最新のコマンドの構成を使用します。以前の構成は置換され、実行されません。

  • 動的構成は、このコマンドによってトリガーされた単一の実行にのみ適用されます。それ以降のスケジュールされた実行では、タスク定義からのデフォルトのCONFIGパラメーターが使用されます。

• SQL コマンドは、スタンドアロンタスクまたはタスクグラフ内のルートタスクのみを実行できます。子タスクが入力された場合、コマンドはユーザーエラーを返します。

• スタンドアロンまたはルートタスクを手動で実行すると、タスクのバージョンが確立されます。スタンドアロンタスクまたはタスクグラフ全体が、このバージョンで実行を完了します。タスクバージョンの詳細については、 タスク実行のバージョニング をご参照ください。

• 中断されたルートタスクは、タスクを再開 することなく 実行されます。この SQL コマンドを実行する前に、ルートタスクを明示的に再開する必要はありません。ただし、 EXECUTE TASK は、タスクグラフ内の子タスクを自動的に再開 しません。このコマンドは、中断されている子タスクをスキップします。

  タスクグラフでルートタスクに関連付けられたすべての依存タスクを再帰的に再開するには、各タスクを個別に有効にするのではなく、 SYSTEM$TASK_DEPENDENTS_ENABLE 関数をクエリします（ALTER TASK ... RESUME を使用）。

  新規または変更されたタスクグラフをテストする際のベストプラクティスとしては、ルートタスクを目的の運用スケジュールで実行するように設定しますが、 中断状態のままにします。タスクグラフのテストに成功した後、ルートタスクを再開します。テストのために、タスクグラフ内で中断された子タスクを再開する必要があることに注意してください。そうしないと、タスクグラフの実行中にスキップされます。

• タスクのインスタンスが実行されていない場合、新しい実行が直ちに開始されます。

• 別のインスタンスがスケジュールされている場合（つまり、タスクが TASK_HISTORY 出力で SCHEDULED 状態を示している場合）、リクエストされた実行はスケジュールされた実行に置き換わります。リクエストされた実行は、現在のタイムスタンプをスケジュール時刻として、直ちに開始されます。

• タスクまたはタスクグラフが現在キュー中または実行中である場合（すなわち、 TASK_HISTORY 出力でタスクが EXECUTING 状態を示している場合）、コマンドが実行されたときに現在であった タスクバージョン を使って現在の実行が継続されます。その後、タスクタイプに応じた時間に、新しい実行がスケジュールされます。

  • スタンドアロンタスクの場合、現在の実行が完了した後、新しい実行がスケジュールされます。

  • タスクグラフの場合:

    • ALLOW_OVERLAPPING_EXECUTION = FALSE （デフォルト）の場合、現在のタスクグラフが完了した後、新しい実行がスケジュールされます。

    • ALLOW_OVERLAPPING_EXECUTION = TRUE で、現在実行中のタスクがルートタスクの場合、ルートタスクの完了後に新しい実行が開始されるようにスケジュールされます。

    • ALLOW_OVERLAPPING_EXECUTION = TRUE で、現在実行中のタスクが子タスクの場合、新しい実行が直ちに開始されます。

  次のスケジュール実行が開始される前に EXECUTE TASK コマンドが再度実行されると、リクエストされた実行はスケジュールされた実行に置き換わります。

• タスクが予期しないエラーで失敗した場合、エラーに関する通知を受け取ることができます。タスクエラー通知の構成の詳細については、 タスクの通知の有効化 をご参照ください。

• タスク情報を表示するには、以下のいずれかを実行します。

  • Snowsight のナビゲーションメニューで、Transformation » Tasks を選択します。

  • COMPLETE_TASK_GRAPHS テーブル関数を呼び出し、結果を調べます。

例¶

次の例は、タスクの実行を手動でトリガーする方法と、動的CONFIGの使用方法を示しています。

EXECUTE TASK mytask;

CREATE OR REPLACE TASK my_root_task
  WAREHOUSE = regress
  SCHEDULE = '10 m'
  CONFIG = $${
    "environment": "production",
    "output_paths": {
      "logs": "/prod/logs",
      "results": "/prod/results"
    }
  }$$
  AS ...;

EXECUTE TASK my_root_task
  USING CONFIG=$${
    "output_paths": {
      "results": "/temp/testing"
    }
  }$$;

{
  "environment": "production",
  "output_paths": {
    "logs": "/prod/logs",
    "results": "/temp/testing"
  }
}