タスクの紹介

現在、タスクは、ストアドプロシージャの呼び出しを含む単一の SQL ステートメントを実行できます。

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

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

このトピックの内容:

タスクのスケジューリング

タスクをトリガーできるイベントソースはありません。代わりに、タスクは( CREATE TASK を使用して)またはそれ以降( ALTER TASK を使用して)作成するときに定義できるスケジュールで実行されます。

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

ウェアハウスの選択

ウェアハウスを構成するときに推奨されるベストプラクティスについては、 ウェアハウスに関する考慮事項 で説明しています。ウェアハウスのサイズとクラスタリングに基づいて、特定のウェアハウスを使用して特定のタスクまたはタスクのツリーの平均実行時間を分析すること、およびウェアハウスが複数のプロセスで共有されているか、この単一のタスク(またはタスクのツリー)の実行専用であるかを分析することをお勧めします。

情報スキーマの TASK_HISTORY テーブル関数をクエリします。タスクのスケジュールされた時間と完了した時間の平均差は、タスクがキューに入れられた期間を含む、タスクの予想される平均実行時間です。現在、他のプロセスがウェアハウス内のすべてのサーバーを使用している場合、タスクはキューに入れられます。

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

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

Example task batch window

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

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

Example tree of tasks batch window

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

タスク定義の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式を手動で調整して、夏時間による時間の変更を補正します。

タスクの単純なツリー

ユーザーはルートタスクで始まり、タスクの依存関係によってリンクされている単純なツリーのようなタスク構造を定義できます。現在の実装では、2つのノード間の単一パスがサポートされています。つまり、個々のタスクは単一の先行タスク(親)のみを持つことができます。これは、1つのノードが複数の親を持つことができる有向非巡回グラフ(DAG)構造とは異なります。

Tree of tasks

タスクの作成時に( CREATE TASK ... AFTER を使用)、または後で( ALTER TASK ... ADD AFTER を使用)、先行タスクを定義できます。ツリーのルートタスクにはスケジュールが定義されている必要があります。ツリー内の他の各タスクには、それらを相互にリンクするための定義済みの先行があります。先行タスクの実行が正常に完了すると、このタスクを定義で先行タスクとして識別される子タスクの実行がトリガーされます。

単純なタスクのツリーは、再開状態において、合計で最大1000タスク(ルートタスクを含む)に制限されます。ツリー内の個々のタスクは、単一の先行タスクに制限されています。ただし、タスクには最大100 タスク(つまり、タスクを先行タスクとして識別する他のタスク)を含めることができます。

現在、 先行タスク が定義されたタスクのインスタンスが特定の時間に実行されることを保証することはできません。

注釈

親タスクの実行が完了し、子タスクが実行された後、短いラグが発生します。

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

タスクとタスク所有権の単純なツリー

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

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

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

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

タスクツリー実行のバージョニング

ルートタスクがスケジュールされた実行を開始すると、タスクツリー全体のバージョンが確立されます。ツリー内のタスクすべてのプロパティすべてが設定されます。タスクのツリー全体が、このセットバージョンのプロパティを使用して現在の実行を完了します。

タスクのツリー内のタスクで DDL ステートメントを実行する前に、ルートタスクを一時停止する必要があります( ALTER TASK ... SUSPEND を使用)。ルートタスクが中断されると、今後スケジュールされたルートタスクの実行はすべてキャンセルされます。ただし、現在実行中のタスク(つまり、 EXECUTING 状態のタスク)がある場合、これらのタスクと子孫タスクは引き続き実行されます。

ツリーのタスクプロパティが変更され、ルートタスクが再開された後、 次回 スケジュールされた実行までそれらの変更は適用されません。その時点で、タスクツリーの新しいバージョンが設定されます。

注釈

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

たとえば、次のタスクツリーの所有者、または適切な権限を持つ別のロールがルートタスク(タスクA)を一時停止したときに、スケジュールされたタスクの実行が既に開始されているとします。ツリーの所有者は、ルートタスクの実行中にタスクB(子タスク)によって呼び出される SQL ステートメントを変更します。ルートタスクが現在の実行を開始すると、ツリー全体のバージョンが設定されます。ルートタスクが実行を開始したときに、タスクBはタスクツリーのバージョンの定義で SQL ステートメントを実行します(またはストアドプロシージャを呼び出します)。

ルートタスクが再開されると、ルートタスクが次回の実行を開始するときに、タスクツリーの新しいバージョンが設定されます。この新しいバージョンには、タスクBの変更が含まれています。

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

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

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

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

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

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

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

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

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

タスク履歴を表示するには:

SQL

TASK_HISTORY テーブル関数( 情報スキーマ 内)をクエリします。

システムサービスの理解

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

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

タスク DDL

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

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

タスク関数

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

タスクセキュリティ

必要なアクセス権限

タスクを作成、管理、および実行するには、少なくとも次のロール権限を持つロールが必要です:

オブジェクト

権限

注意

アカウント

EXECUTE TASK

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

データベース

USAGE

スキーマ

USAGE, CREATE TASK

ウェアハウス

USAGE

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

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

使いやすくするために、カスタムロール(例: 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 EXECUTE TASK privilege to the new role
USE ROLE accountadmin;

GRANT EXECUTE 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;

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

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

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

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

ワークフロー

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

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

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

    注釈

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

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