# Treasure ワークフロー の用語と概念

Treasure ワークフロー は、ワークフロープロセスのベストプラクティスを提供し、業界標準の用語を使用しています。Treasure ワークフロー は、オープンソースのワークフロープログラムである Digdag の機能を拡張および強化しているため、ワークフローの概念は同じです。以下の用語と概念のリストをリファレンスとして使用できます。

## タスク

ワークフロー定義ファイルで指定される、実行されるアクションです。タスク構文はタスク名とオペレータで構成され、変数とパラメータを含むこともできます。

タスクは他のタスクをグループ化でき、その場合はグループ化専用タスクになります。タスクは追加のタスクを生成でき、その場合はタスク生成タスクになります。タスクがタスクの生成を完了すると、子を持つようになるためグループ化タスクに変わります。タスクは他のタスクに依存関係を持つことができます。タスクが独立している場合、それはタスクです。

## タスク名

ワークフロー定義ファイル内の各タスクにラベルを付ける、ユーザーが指定する説明的な名前です。Treasure ワークフロー構文では、各タスク名の前に +（プラス）記号が付きます。

## オペレータ

ワークフロータスクの一部である命令です。Treasure ワークフロー構文では、各オペレータの後に >（大なり）記号が付きます。事前定義されたオペレータのタイプには、Digdag からのワークフロー制御オペレータ（`call>`、`loop>`、`echo>` など）、Treasure Data オペレータ（`td>`、`td_run>`、`td_load>`、`td_table_export` など）、およびデータベースとネットワーク用のオペレータがあります。

オペレータはパラメータとスクリプト（クエリやその他の呼び出しなど）を含むことができ、複数のワークフローで再利用できるプラグインのように動作するように設計されています。

## パラメータ

オペレータをさらに指定する定数または変数です。Treasure ワークフロー構文には、local、export、store の3種類のパラメータがあります。

- Local パラメータはタスクに直接設定されます。
- Export パラメータは、親タスクが子に値を渡すために使用されます。
- Store パラメータは、タスクが子を含む後続のすべてのタスクに値を渡すために使用されます。


パラメータは、タスクの実行時に1つのオブジェクトにマージされます。Local パラメータが最も優先度が高くなります。Export パラメータと Store パラメータは互いにオーバーライドするため、後のタスクで設定されたパラメータが優先度が高くなります。Store パラメータはグローバル変数ではありません。2つのタスクが並列で実行される場合、異なる Store パラメータを使用します。これにより、実際の実行タイミングに関係なく、ワークフローの動作が一貫します。

## 変数

クラスまたはオブジェクトのセットのキーワードです。Treasure ワークフロー構文では、各変数の前に $（ドル）記号が付き、値は `{}` 括弧内に含まれます。Treasure ワークフロー にすでに組み込まれている変数には、`timezone`、`session_id`、`task_name` などがあります。独自の変数を定義することもできます。

変数は3つの方法で定義できます：YAML で `_export` パラメータを使用する方法、API を使用してプログラム的に定義する方法、または `-p KEY=VALUE` を使用してセッションを開始するときに定義する方法です。`${...}` 構文で基本的な JavaScript スクリプトを使用して変数を計算できます。

## プロジェクト

一連のワークフローで使用されるワークフローとファイルのコンテナです。ファイルには、SQL、Python、Ruby、シェルスクリプト、設定ファイルなど、ほぼすべてのスクリプトを含めることができます。プロジェクトは、特定のアクションを完了するワークフローや互いに依存関係を持つワークフローなど、関連するワークフローをグループ化するために使用されます。新しいリビジョンをアップロードすると、プロジェクト内のすべてのワークフローが一緒に更新されます。

## リビジョン

プロジェクトのバージョンです。プロジェクト内のワークフローまたはプロジェクトの一部であるファイルを編集すると、新しいリビジョンが作成されます。プロジェクトのリビジョン履歴は、Treasure コンソール の Workflows エリアにあります。以前のリビジョンを選択して復元できます。

## セッション

Workflow UI でワークフローを実行するプランです。セッションはデータの日付を指定し、ワークフローが操作するデータセットを識別します。セッションはスケジュールされていないか、スケジュールされている場合がありますが、一意である必要があります。ワークフローでは、同じデータセットに対して同じ日付を指定する2つのセッションを持つことはできません。Treasure Data では、デフォルトのセッション値は現在のタイムスタンプです。スケジュールされていないワークフローは、現在のタイムスタンプであるデフォルトのセッション値を使用します。

## セッション時間

セッションが実行される `session_time` と呼ばれるタイムスタンプです。`session_time` はワークフローの履歴で一意です。同じ `session_time` で2つのセッションを送信すると、後のリクエストは拒否されます。これにより、同じ時間に以前実行されたセッションを誤って送信することを防ぎます。同じ時間にワークフローを実行する必要がある場合は、新しいセッションを送信する代わりに、過去のセッションを再試行してください。

## 実行時間

ワークフローが正常に完了したかどうかにかかわらず、ワークフローが実行された時刻を記録するタイムスタンプです。

例：毎日スケジュールされるワークフローがあるとします。`session_time` は 2017-01-01 00:00:00 のような日の 00:00:00 です。実際の実行時間は同じ時間ではない場合があります。一部のデータの準備に1時間かかるため、実行を2時間遅らせたい場合があります。

## 試行

セッションの実際の実行です。失敗したワークフローを再試行すると、セッションには複数の試行があります。セッションが失敗した場合、試行を確認し、ログから問題をデバッグできます。問題を修正するために新しいリビジョンをアップロードし、その後新しい試行を開始できます。

## プール

アカウント内で同時に実行できるワークフローアテンプトの数を、特定のグループごとに制御します。すべてのアカウントには、管理者が追加のプールを作成するまでアカウントの並行実行数の上限すべてを保有するデフォルトプールがあります。各プールは独自の名前、並行実行数の上限、およびキューを持ちます。詳細は[プールについて](/ja/products/customer-data-platform/data-workbench/workflows/pool)を参照してください。

## プールルール

新しく作成されたアテンプトをどのプールに割り当てるかを決定する、管理者が設定するルールです。ルールは優先度順に評価され、最初にマッチしたルールが採用されます。どのルールにもマッチしないアテンプトはデフォルトプールに割り当てられます。詳細は[プールルールを管理する](/ja/products/customer-data-platform/data-workbench/workflows/pool/managing-pool-rules)を参照してください。