tencent cloud

Tencent Cloud WeData

パラメータ設定と使用

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-29 16:11:24
AI翻訳

1. パラメータ概要

データ開発では、コード内で動的に変化する値を参照する必要がよくあります。例えば、毎日処理する業務日付、現在のプロジェクト識別子、上流タスクが生成した結果などです。WeDataはパラメータメカニズムを通じてこのようなニーズを統一的に解決します:ユーザーはタスクコードに${name}のようなプレースホルダーを記述し、スケジューリングシステムがタスク実行前にそれを実際の値に置き換えます。

1.1 パラメータ全体像

WeDataパラメータは「値の取得元」に基づいて3つのカテゴリに分類されます:
カテゴリー
定義
値の決定元
代表例
カスタムパラメータ
ユーザーがスコープに基づいて作成した名前付きパラメータ
ユーザーによる手動設定
プロジェクトパラメータ${project_param}、ワークフローパラメータ${workflow_param}、タスクパラメータ${task_param}
システムパラメータ
プラットフォームに組み込まれ、実行時に自動的に注入されるパラメータ
スケジューリングシステムが自動生成します
時間パラメータ${yyyyMMdd}、コンテキストパラメータ${projectIdent}
パラメータ受け渡し
上流タスクの出力が下流タスクの入力として使用されます。
上流タスクの実行結果
上流タスクがmark_idを出力します。下流タスクがスケジュール設定 > パラメータ渡し > 親タスクパラメータの参照で参照関係を定義した後、コード内で${mark_id}を使用します。詳細はパラメータ渡しを参照してください。
3種類のパラメータの参照構文はすべて${name}プレースホルダーです。ユーザーはSQL / Shell / Pythonなどのコードで同じ方法で記述するだけでよく、パラメータのソースを気にする必要はありません。
説明:
パラメータ置換はタスクがエンジンに送信されて実行される前に、スケジューリングシステムによってテキスト置換が行われます。つまり、${yyyyMMdd}のようなプレースホルダーは、Hive / Spark / Pythonのエグゼキューターに到達した時点で、すでに具体的な値(例えば20260507)に置き換わっています。これは、IDEでコードを直接デバッグ実行する場合、${name}は置換されないことを意味します。高度な実行でパラメータ値を指定するか、タスク/ワークフロー/プロジェクトレベルでデフォルト値を設定して効果を検証する必要があります。

1.2 スコープと優先順位

カスタムパラメータはスコープに応じて3つのレベルに分かれており、スコープが小さいほど優先度が高くなります:
プロジェクトパラメータ(スコープ:プロジェクト配下のすべてのワークフロー / タスク)
↓
ワークフローパラメータ(スコープ:単一ワークフロー内のすべてのタスク)
↓
タスクパラメータ(スコープ:単一タスク)
異なるスコープに同名のパラメータが存在する場合、以下の優先順位(高い順)に従います:上流タスクからの引き渡し>タスクパラメータ>ワークフローパラメータ>プロジェクトパラメータ>システムパラメータ
例:
プロジェクトでpt_date = 20260101が定義され、あるワークフローでpt_date = 20260201が定義され、そのワークフロー内のあるタスクでpt_date = 20260301が定義されている場合、そのタスクの実行時に${pt_date}の実際の値は20260301になります(タスクパラメータが有効になります)。

1.3 どのパラメータを使用すべきか(選定ガイド)

ニーズシーン
推奨パラメータタイプ
説明
複数のタスクで同じ値を共有します(テストデータベース名、共通パスなど)。
プロジェクトパラメータ
一箇所の変更で、プロジェクト全体に反映されます。
特定のワークフロー内の複数タスクで共有する値
ワークフローパラメータ
スコープはワークフロー内に限定され、グローバルへの影響を防ぎます。
現在のタスクのみで使用する一時的な値
タスクパラメータ
スコープが最も小さく、最も柔軟です。
業務日付に基づいてパーティションに動的に書き込みます(T+1など)。
時間パラメータ${yyyyMMdd-1d}
システムが自動的に注入するため、メンテナンスは不要です。
コード内で現在のプロジェクト/ワークフロー/タスクの情報を取得します。
コンテキストパラメータ${projectIdent}など
システムが自動的に注入します。
上流タスクの計算結果が下流タスクの入力として使用されます。
パラメータ受け渡し
SQLの結果、Shellの出力、Pythonのプリントなどをサポートします。
プロジェクト全体で「昨日」の日付をデフォルトの業務日付として統一して使用します。
**プロジェクトパラメータ + 時間パラメータの組み合わせ** 例:pt_date = ${yyyyMMdd-1d}
「集中メンテナンス」と「動的値取得」の両方の利点を兼ね備えています。

1.4 クイックスタート例

最も一般的な「業務日付に基づくパーティションへの書き込み」を例に挙げます:
1. パラメータを定義します(いずれか1つを選択):
方式A:システム時間パラメータを使用し、コードに直接${yyyyMMdd-1d}を記述します。
方式B:プロジェクトパラメータpt_dateを定義し、値を${yyyyMMdd-1d}に設定し、コードに${pt_date}を記述します。
1. SQLで参照します:
INSERT OVERWRITE TABLE dw.user_daily PARTITION(dt = '${pt_date}')
SELECT * FROM ods.user_log
WHERE dt = '${pt_date}';
1. タスクが毎日実行される際に、${pt_date}はスケジューリングシステムによって自動的に前日の日付(例:20260506)に置き換えられ、データは対応するパーティションに書き込まれます。

2. カスタムパラメータ

カスタムパラメータはユーザーがスコープに応じて作成した名前付きパラメータであり、作用範囲の大きい順にプロジェクトパラメータ、ワークフローパラメータ、タスクパラメータの3つのレベルに分けられます。
パラメータタイプ
適用範囲
設定入口
プロジェクトパラメータ
現在のプロジェクト内のすべてのワークフローとタスク
プロジェクト管理 > パラメータ設定
ワークフローパラメータ
現在のワークフロー内のすべてのタスクノード
ワークフローキャンバス > 右側 > 一般設定 > ワークフローパラメータ
タスクパラメータ
現在の単一タスクノード
タスクノード > 右側 > タスク属性 > 基本情報
説明:
3つのレベルのカスタムパラメータのコードでの参照構文は完全に同一です。いずれも${パラメータ名}です。異なるスコープに同名のパラメータが存在する場合、タスクパラメータ>ワークフローパラメータ>プロジェクトパラメータの優先順位で有効になります。

2.1 プロジェクトパラメータ

プロジェクトパラメータはプロジェクト全体に適用され、すべてのワークフロー、タスク、スクリプトから参照できます。プロジェクト内の複数タスクで共有する値(例:共通データベース名、統一された業務日付、汎用パスプレフィックスなど)の格納に適しています。

2.1.1 パラメータ設定ページへのアクセス

1. Tencent Cloud WeDataコンソールにログインします。
2. 左側の目次にあるプロジェクトリストをクリックし、対象プロジェクトを選択して、プロジェクト管理モジュールに入ります。
3. 左側の目次にあるパラメータ設定をクリックします。

2.1.2 プロジェクトパラメータの追加

ページ左上の新規作成をクリックし、リストにパラメータ名とパラメータ値を入力し、保存をクリックして作成を完了します。
典型的な使用法:システム時間パラメータをプロジェクトレベル名として固定します
例えば、プロジェクト内のほとんどのタスクで「前日」を業務日付として使用する必要がある場合、プロジェクトパラメータを作成できます:
パラメータ名
パラメータ値
pt_date
${yyyyMMdd-1d}
その後、任意のタスクのコードで${pt_date}を使用するだけで、スケジューリングシステムが実行時間に基づいて前日の日付に自動的に解析します。その後、ビジネスルールが調整された場合(例:前々日に変更)、プロジェクトパラメータpt_dateの値を変更するだけで、プロジェクト内のすべてのタスクはコードを変更する必要がありません。

2.1.3 プロジェクトパラメータの編集と削除

パラメータリストの各行のパラメータには、編集と削除の操作が提供されています。
注意:
プロジェクトパラメータを削除する前に、そのパラメータがプロジェクト内のいずれのタスクやスクリプトからも参照されていないことを確認してください。削除後、そのパラメータを使用しているタスクは、次回実行時にパラメータ値が見つからず失敗します。

2.1.4 コードでのプロジェクトパラメータの使用

スクリプト開発またはオーケストレーションタスクのコードで、${パラメータ名}を使用するだけでプロジェクトパラメータを参照できます。SQLタスクを例に挙げます:
SELECT * FROM demo_bi.user_log
WHERE dt = '${pt_date}';
タスクが実際に実行されると、${pt_date}はプロジェクトパラメータpt_dateに設定された値に置き換えられます。

2.2 ワークフローパラメータ

ワークフローパラメータは単一ワークフロー内のすべてのタスクノードに適用されます。このワークフローコンテキスト内でのみ共有される値の格納に適しており、プロジェクト全体の汚染を回避します。

2.2.1 ワークフローパラメータの設定

1. 対象ワークフローのキャンバスページに入ります。
2. キャンバス右側の一般設定をクリックします。
3. ワークフローパラメータエリアで新規作成をクリックし、パラメータ名とパラメータ値を入力し、保存をクリックします。各行のパラメータでは編集と削除の操作がサポートされています。

2.2.2 ワークフロータスクでの使用

ワークフローパラメータの参照構文はプロジェクトパラメータと同様です:${パラメータ名}。
例:ワークフローdemo_workflowでワークフローパラメータpg = test_dbを設定すると、ワークフロー内のHive SQLタスクは直接参照できます:
SELECT * FROM ${pg}.user_log
WHERE dt = '${pt_date}';
説明:
上記のコードでは、${pg}はワークフローパラメータを参照し、${pt_date}はプロジェクトパラメータを参照します。スコープの異なるパラメータは同じコード内で混在して使用できます。スケジューリングシステムが優先順位に従って自動的に解析します。

2.3 タスクパラメータ

タスクパラメータは単一タスクノードにのみ適用され、優先順位が最も高いカスタムパラメータです(パラメータの受け渡しを除く)。現在のタスクのみで使用する一時的な値や、タスク粒度でプロジェクト/ワークフローパラメータを差別化して上書きする必要があるシナリオの格納に適しています。

2.3.1 タスクパラメータの設定

1. 対象タスクノードの編集ページに入ります。
2. 右側のタスクプロパティをクリックします。
3. 基本情報エリアでタスクパラメータ(スケジュールパラメータ)設定項目を見つけます。この項目は入力ボックスであり、key=value形式でパラメータを入力します。複数のパラメータを設定する場合は、;で区切ります。
例:
pt_date=20260507;qt=100

2.3.2 タスクコードでの使用

参照構文は引き続き${パラメータ名}です。Hive SQLタスクを例に、タスクパラメータqt = 100を設定した後:
SELECT * FROM demo_bi.user_log
WHERE dt = '${pt_date}'
AND user_id = ${qt};
タスク実行時:
${pt_date}はプロジェクトパラメータpt_dateの値として解析されます。
${qt}はタスクパラメータqtの値100として解析されます。
注意:
タスクパラメータがプロジェクト/ワークフローパラメータと同じ名前の場合(例えば、プロジェクトパラメータqt = 50とタスクパラメータqt = 100が同時に存在する場合)、タスク実行時にタスクパラメータが有効になります。${qt}は100として解析されます。これは優先順位による上書きの想定された動作ですが、複数人での共同作業時に混乱を招きやすいため、異なるスコープのパラメータには区別しやすい命名を採用することをお勧めします。

2.4 デバッグシナリオ:高度な実行

タスクパラメータ(およびプロジェクト/ワークフローパラメータ)の値は、スケジューリングシステムがタスクを実行するときにのみ置換されます。IDEでタスクコードを直接デバッグ実行する場合、${パラメータ名}は自動的に置換されません。この場合、2つの検証方法があります:
方法1:「高度な実行」を使用する タスク編集ページで高度な実行をクリックし、表示されるパラメータ設定ボックスで今回の実行に対して${パラメータ名}の具体的な値を一時的に指定します。今回のデバッグにのみ有効であり、タスクパラメータの実際の設定には影響しません。
方法2:タスク/ワークフロー/プロジェクトレベルでデフォルト値を設定する 2.1~2.3節に従って永続化されたパラメータ値を設定しておくと、デバッグ実行時に自動的に優先順位に従って値が取得されます。
説明:
実際の本番環境では方法2を推奨します。パラメータ値を適切なスコープに固定することで、毎回のデバッグで再入力する手間を省きます。方法1は、異なるパラメータ値を一時的に検証するシーンに適しています。例えば、特定の境界ケースをデバッグする場合です。

3. システムパラメータ

システムパラメータはプラットフォームに組み込まれ、実行時にスケジューリングシステムによって自動的に注入されるパラメータです。ユーザーが作成する必要はなく、タスクコード内で直接参照できます。システムパラメータは2種類に分けられます:
パラメータタイプ
用途
代表例
時間パラメータ
コード内でタスクの業務時間、スケジュール時間、実行時間を参照します。
${yyyyMMdd} 、$(yyyyMMdd) 、$[yyyyMMdd]
コンテキストパラメータ
コード内で現在のプロジェクト/ワークフロー/タスクの識別情報を参照します。
${projectIdent} 、${taskName}

3.1 クイックリファレンスカード

構文クイックリファレンス(3種類の時間パラメータ):
${yyyyMMdd} → インスタンスデータ時間(パーティション値として推奨)
$(yyyyMMdd) → 計画スケジュール時間(海外タイムゾーンシーンでの使用を推奨)
$[yyyyMMdd] → インスタンス実行時間(ログ/監査に適用)

オフセットクイックリファレンス:
${yyyyMMdd-1d} → 1日前
${yyyyMMdd+3M} → 3か月後
${yyyyMMdd+2w} → 2週間後
${yyyyMMddHHmmss-2H} → 2時間前

特殊オフセットクイックリファレンス:
${yyyyMMdd+ME} → 当月月末
${yyyyMMdd+MS} → 当月月初
${yyyyMMdd+PME} → 前月月末
${yyyyMMdd+YE} → 当年年末

タイムゾーンクイックリファレンス:
${UTC+0_yyyyMMdd} → UTC+0タイムゾーン
${UTC+7_yyyyMMdd} → UTC+7タイムゾーン
タイムゾーンプレフィックスを付けない場合 → デフォルトはUTC+8です。

コンテキストパラメータ:
${projectIdent} → プロジェクト識別子
${workflowName} → ワークフロー名
${taskName} → タスク名
${taskId} → タスクID
${taskInCharge} → タスク担当者
${taskType} → タスクタイプ

3.2 時間パラメータ

3.2.1 3種類の時間パラメータ概要

WeDataは3種類の時間パラメータを提供し、それぞれ異なる「時間意味」に対応します。3つは異なる括弧で区別されます:
パラメータタイプ
構文
意味
補録/再実行のシナリオでは
推奨シーン
インスタンスデータ時間
${ }
業務データの基準時間であり、タスク粒度で切り捨てられます。
常に変わりません。
パーティション値、業務時間フィールド
計画スケジュール時間
$( )
スケジュール設定で指定された起動時間
常に変わりません。
海外タイムゾーンシナリオ、完全なスケジュール時刻を保持する必要がある場合
インスタンス実行時間
$[ ]
インスタンスが実際に実行を開始した時間
毎回異なります。
ログ記録、監査追跡
注意:
${} / $() / $[] の3種類の括弧は混用できません。同じフォーマット文字列を異なる括弧に入れると、3つの完全に異なるパラメータとなり、解析結果が大きく異なる可能性があります。
主な違いの例: 毎日02:00にスケジュール実行される日次タスク。
シナリオ
実際の実行時間
${yyyyMMddHHmmss}<br>インスタンスデータ時間
$(yyyyMMddHHmmss)<br>計画スケジュール時間
$[yyyyMMddHHmmss]<br>インスタンス実行時間
2026-03-22 正常稼働
2026-03-22 02:00:15
20260322000000
20260322020000
20260322020015
2026-03-25 2026-03-20のインスタンスを補録
2026-03-25 10:30:22
20260320000000
20260320020000
20260325103022
2026-03-26 2026-03-22のインスタンスを再実行
2026-03-26 14:05:12
20260322000000
20260322020000
20260326140512
確認できます:
インスタンスデータ時間は常にビジネス日付であり、日単位に切り捨てると00:00:00になります。補録/再実行でも変わりません。
計画スケジュール時間には具体的なスケジュール時刻02:00:00が保持されます。補録/再実行でも変わりません。
インスタンス実行時間は実際にいつ実行を開始するかによって決まり、「実際の実行時間」列に対応する時刻と等しくなります。毎回異なります。

3.2.2 インスタンスデータ時間 ${}

意味: 業務データを処理する基準時間です。同一インスタンスのデータ時間は、周期実行、補録、再実行において常に同じです。
構文: ${}でフォーマット文字列を囲みます。例:${yyyyMMddHHmmss}。
テスト実行: データ時間は実行を送信した時間です。
データ時間切り捨てルール:
タスク粒度
計画スケジュール時間(例)
インスタンスデータ時間
截断説明
分タスク
2026-03-22 14:30:00
2026-03-22 14:30:00
分まで保持します。
時間タスク
2026-03-22 14:30:00
2026-03-22 14:00:00
1時間単位に切り捨てます。
日次タスク
2026-03-22 02:00:00
2026-03-22 00:00:00
日単位に切り捨てます。
週次タスク
2026-03-22 02:00:00
2026-03-22 00:00:00
日単位に切り捨てます。
月次タスク
2026-03-22 02:00:00
2026-03-22 00:00:00
日単位に切り捨てます。
年次タスク
2026-03-22 02:00:00
2026-03-22 00:00:00
日単位に切り捨てます。

3.2.3 計画スケジュール時間 $()

意味: タスクスケジュール設定で設定されたスケジュール時間であり、周期インスタンス生成時刻の基準でもあります。例えば日次タスクが毎日2時に実行される場合、計画スケジュール時間は毎日02:00:00です。
構文: $()でフォーマット文字列を囲みます。例:$(yyyyMMddHHmmss)。
インスタンスデータ時間との関係: 計画スケジュール時間には完全なスケジュール時刻が保持されます(例:02:00:00)。一方、インスタンスデータ時間はタスク粒度に応じて切り捨てられます(日次タスクでは00:00:00に切り捨てられます)。分単位タスクの場合、両者は等しくなります。

3.2.4 インスタンス実行時間 $[]

意味: インスタンスが実際に実行を開始した時間であり、動的に変化します。同じインスタンスでも、周期実行と補録/再実行では、インスタンス実行時間は必ず異なります。
構文: $[]でフォーマット文字列を囲みます。例:$[yyyyMMddHHmmss]。

3.2.5 共通構文ルール

説明:
以下の規則は3種類の時間パラメータに共通して適用されます。括弧マーカー${}/$()/$[]を置き換えるだけで済みます。以下では、インスタンスデータ時間${}を例として説明します。
時間フォーマット
必要に応じてパラメータ形式を調整し、年、月、日、時、分、秒を自由に組み合わせることができます:
形式文字列
説明
例(データ時間は2026-03-22 14:30:45)
${yyyy}
4桁の年
2026
${MM}
2桁の月
03
${dd}
2桁の日付
22
${HH}
2桁の時間(24h)
14
${mm}
2桁の分
30
${ss}
2桁の秒
45
${yyyyMMdd}
コンパクトな日付
20260322
${yyyy-MM-dd}
書式化された日付を-で連結します。
2026-03-22
${HH:mm:ss}
時間を書式化し、:で連結します。
14:30:45
${yyyy-MM-dd HH:mm:ss}
完全な日付と時刻
2026-03-22 14:30:45
${yyyyMMddHHmmss}
コンパクトで完全な時刻
20260322143045
時間オフセット
必要に応じてオフセット計算を行うことができます。構文は${<フォーマット文字列><±N><単位>}です。
オフセット方向
構文
例
N年後
${yyyyMMdd+Ny}
${yyyyMMdd+2y} → 2年後
N年前
${yyyyMMdd-Ny}
${yyyyMMdd-1y} → 1年前
Nか月後
${yyyyMMdd+NM}
${yyyyMMdd+3M} → 3か月後
Nか月前
${yyyyMMdd-NM}
${yyyyMMdd-1M} → 1か月前
N週間後
${yyyyMMdd+Nw}
${yyyyMMdd+1w} → 1週間後
N週間前
${yyyyMMdd-Nw}
${yyyyMMdd-2w} → 2週間前
N日後
${yyyyMMdd+Nd}
${yyyyMMdd+7d} → 7日後
N日前
${yyyyMMdd-Nd}
${yyyyMMdd-1d} → 1日前
N時間後
${yyyyMMddHHmmss+NH}
${yyyyMMddHHmmss+6H} → 6時間後
N時間前
${yyyyMMddHHmmss-NH}
${yyyyMMddHHmmss-2H} → 2時間前
N分後
${yyyyMMddHHmmss+Nm}
${yyyyMMddHHmmss+30m} → 30分後
N分前
${yyyyMMddHHmmss-Nm}
${yyyyMMddHHmmss-15m} → 15分前
タイムスタンプ(秒)
${timestamp}
10桁のUnixタイムスタンプで、±N<単位>演算をサポートします。
タイムスタンプ(ミリ秒)
${timestamp_ms}
13桁のUnixタイムスタンプで、±N<単位>演算をサポートします。
特殊オフセット
現在時刻に対応する月末、四半期末、年末などの特別な時点を計算できます:
オフセット識別子
正式名称
説明
例(データ時間は2026-03-22)
+TE
TENDAY END
当旬の旬末
20260331(3月下旬末)
+ME
MONTH END
当月月末
20260331
+QE
QUARTER END
当四半期末
20260331(Q1末)
+HYE
HALF YEAR END
当半期末
20260630
+YE
YEAR END
当年年末
20261231
+TS
TENDAY START
当旬の旬初
20260321(3月下旬初)
+MS
MONTH START
当月月初
20260301
+HYS
HALFYEAR START
当半期初
20260101
+YS
YEAR START
当年年初
20260101
+PME
PRI MONTH END
前月末
20260228
+PYE
PRI YEAR END
前年末
20251231
構文例:
${yyyyMMdd+ME}:インスタンスデータ時間に対応する当月月末
$(yyyyMMdd+PME):計画スケジュール時間に対応する前月月末
$[yyyyMMdd+YE]:インスタンス実行時間に対応する当年年末
タイムゾーン設定
時間パラメータのタイムゾーン変換をサポートしています。構文は、フォーマット文字列の前にUTC+N_プレフィックスを追加します:
${UTC+0_yyyyMMdd} → インスタンスデータ時間のUTC+0時間
$(UTC+7_yyyyMMdd) → 計画スケジュール時間のUTC+7時間
$[UTC+9_yyyyMMdd] → インスタンス実行時間のUTC+9時間
デフォルトの動作:タイムゾーンプレフィックスを追加しない場合、デフォルトはUTC+8(北京時間)です。
タイムゾーンとオフセットの組み合わせ:タイムゾーンプレフィックスとオフセットを同時に使用できます。例えば、${UTC+0_yyyyMMdd-1d}はUTC+0タイムゾーンにおける前日の日付を表します。
完全な構文ルール
パラメータ構文:
インスタンスデータ時間:${[UTC+N_]<format>[±N<unit>][+<special>]}
計画スケジュール時間:$([UTC+N_]<format>[±N<unit>][+<special>])
インスタンス実行時間:$[[UTC+N_]<format>[±N<unit>][+<special>]]

ここで:
[UTC+N_] はオプションです。タイムゾーンプレフィックスで、Nは整数です。デフォルトはUTC+8です。
<format> yyyy、MM、dd、HH、mm、ssおよびそれらの自由な組み合わせ(区切り文字をサポート)
[±N<unit>] オプション、オフセット量
<unit> y(年)、M(月)、w(週)、d(日)、H(時間)、m(分)
[+<special>] オプション、特殊オフセット識別子
TE, ME, QE, HYE, YE, TS, MS, HYS, YS, PME, PYE

3.2.6 使用推奨事項

選定推奨
シナリオ
推奨パラメータ
説明
パーティション値/業務時間フィールド
インスタンスデータ時間${}
周期実行、補録、再実行のシナリオでは値が同じであり、データが常に正しいパーティションに書き込まれることを保証します。
海外/非UTC+8シナリオ
計画スケジュール時間$() + タイムゾーンプレフィックス
$(UTC+0_yyyyMMdd)のようにして、極端なクロスサイクルシナリオにおける時間エラーを回避します。
ログ/監査
インスタンス実行時間$[]
このデータがいつ生成されたかを記録します。
グローバルT+1モード
プロジェクトパラメータ + 時間パラメータの組み合わせ
プロジェクトパラメータでpt_date = ${yyyyMMdd-1d}を定義し、全プロジェクトのタスクで共用します。
典型的なシナリオ例
シナリオ1:T+1パーティション書き込み(最も一般的)
-- 日次タスクは2026-03-22に実行され、dt='20260321'パーティションに書き込まれます。
INSERT OVERWRITE TABLE dw.user_daily PARTITION(dt = '${yyyyMMdd-1d}')
SELECT * FROM ods.user_log
WHERE dt = '${yyyyMMdd-1d}';
シナリオ2:当日パーティション書き込み
-- 日次タスクは2026-03-22に実行されます。
-- ${yyyy-MM-dd} は '2026-03-22' に解析されます。
SELECT '${yyyy-MM-dd}' AS p_date, user_id, action
FROM ods.user_events
WHERE dt = '${yyyyMMdd}';
シナリオ3:月次集計(月初に前月データを実行)
-- 毎月1日にタスクを実行し、前月の月間データを集計します。
-- ${yyyyMMdd+PME} → 前月末、${yyyyMMdd+MS} → 当月初
SELECT COUNT(*) AS order_cnt
FROM dw.order_detail
WHERE dt >= '${yyyyMMdd+PME}' AND dt < '${yyyyMMdd+MS}';
シナリオ4:海外タイムゾーンシナリオ
-- 海外ビジネスはUTC+0を基準とし、計画スケジュール時間+タイムゾーンプレフィックスを使用します。
SELECT * FROM ods.global_events
WHERE event_date = '$(UTC+0_yyyy-MM-dd)';

3.3 コンテキストパラメータ

コンテキストパラメータは、現在のタスク実行時のプロジェクト、ワークフロー、タスク識別情報を提供します。SQLでこれらの情報を照会するために使用でき、またはYARNタスク名などを動的に指定するために使用できます。

3.3.1 パラメータリスト

パラメータ
意味
サンプル値
${projectIdent}
プロジェクトID
my_project
${workflowName}
ワークフロー名
daily_etl
${taskName}
タスク名
user_sync_task
${taskId}
タスクID
task-abc123
${taskInCharge}
タスク責任者(テスト実行時は現在の操作者、周期実行時はタスク責任者)
zhangsan
${taskType}
タスクタイプ
SparkSQL

3.3.2 使用例

例1:SQLでタスクコンテキスト情報を取得する
SELECT
'${projectIdent}' AS project_ident,
'${workflowName}' AS workflow_name,
'${taskName}' AS task_name,
'${taskId}' AS task_id,
'${taskInCharge}' AS task_in_charge,
'${taskType}' AS task_type,
user_id
FROM wedata_demo_db.user_info
LIMIT 10;
例2:Yarnタスク名を動的に指定します
SparkSQL、PySpark、Sparkタスクでは、--name + コンテキストパラメータを使用してYARN上のタスク名を指定します:
--name ${projectIdent}-${workflowName}-${taskInCharge}
SparkSQLでKyuubiデータソースに接続する際は、spark.app.nameパラメータを使用して指定します:
spark.app.name=${projectIdent}-${workflowName}-${taskInCharge}

3.4 よくある質問

補録時にパラメータが取得されるのはいつの日付ですか?

インスタンスデータ時間${}と計画スケジュール時間$():取得するのは補録の業務日付(つまり、指定した補録の日付)であり、実際に補録操作を実行した日付ではありません。
インスタンス実行時間$[]:取得するのは補録操作が実際に実行を開始した時間です。

${yyyyMMdd} と $(yyyyMMdd) に日次タスクでの違いはありますか?

日付部分は同じですが、時分秒を含む場合、違いは明らかです。毎日02:00に実行される日次タスクを例にします:
${yyyyMMdd} → 20260322(データ時間、日単位で切り捨て)
$(yyyyMMdd) → 20260322(スケジュール時間、日付部分は同じ)
${yyyyMMddHHmmss} → 20260322000000(00:00:00に切り捨て)
$(yyyyMMddHHmmss) → 20260322020000(スケジュール時刻02:00:00を保持)

なぜ私のパラメータが置換されないのですか?

よくある原因:
1. 括弧の種類の誤り:${} / $() / $[] の3種類の括弧は混用できません。
2. フォーマット文字列のスペルミス:例:${YYYY}は${yyyy}にすべきです(大文字と小文字は区別されます)。
3. プレースホルダの先頭と末尾にスペースがある:${の直後の右側、}の直前の左側にはスペースを入れることはできません。例えば、${ yyyyMMdd}、${yyyyMMdd }、${ yyyyMMdd }はいずれも無効であり、パラメータが認識されなくなります。
4. オフセット式にスペースがある:例えば、${yyyyMMdd - 1d}、${yyyyMMdd -1d}は解析に失敗します。オフセット記号+/-とフォーマット文字列、数字、単位の間にはスペースを入れることはできません。必ず密着させて${yyyyMMdd-1d}のように記述してください。
5. 非スケジューリング環境:パラメータ置換はスケジューリングシステムがタスクを実行するときにのみ有効になります。IDEで直接実行しても置換されないため、高度な実行でパラメータ値を指定する必要があります。
説明:
フォーマット文字列内部で区切り文字として使用されるスペースは有効です。スケジューリングシステムはそれをそのまま出力に保持します。例:
-- インスタンスデータの時刻は2026-05-07です。
SELECT "${yyyy MM dd}";
-- 実際の実行時に置換されます:
SELECT "2026 05 07";
この特性を利用することで、ユーザーは日付出力形式を柔軟にカスタマイズできます。

UTC+N_ タイムゾーンプレフィックスを付けない場合、デフォルトは何ですか?

デフォルトはUTC+8(北京時間)です。

特殊オフセット +ME と +PME の違いは何ですか?

+ME(MONTH END):現在の月の月末日です。例えば、データ時刻が2026-03-15の場合、${yyyyMMdd+ME}は20260331になります。
+PME(PRI MONTH END):前月の月末日です。例えば、データ時刻が2026-03-15の場合、${yyyyMMdd+PME}は20260228になります。

オフセット計算とタイムゾーンプレフィックスは同時に使用できますか?

可能です。構文は${UTC+N_<フォーマット文字列><オフセット>}です。例:
${UTC+0_yyyyMMdd-1d}:UTC+0タイムゾーンにおける前日の日付です。
$(UTC+9_yyyyMMddHHmmss+6H):UTC+9タイムゾーンにおける6時間後です。

4. 各種タスクでのパラメータ使用

タスクタイプによって、パラメータ取得メカニズムは異なります。ほとんどのタスクタイプでは${パラメータ名}プレースホルダを使用し、スケジューリングシステムが実行前にテキスト置換を行います。ただし、NotebookタスクはDLCエンジンでPythonセル方式で実行されるため、関数形式のdlcutils.widgets.get()を使用してパラメータを読み取ります。
本章では、タスクタイプ別にパラメータの使用例を示します。より詳細なタスク設定方法については、各タスクタイプの個別ドキュメントを参照してください。

4.1 SQLタスク

適用タスクタイプ:Hive SQL、Spark SQL、Impala、Trino、DLC SQL、JDBC SQL、TCHouse-P、TDSQL PostgreSQL。
パラメータ取得メカニズム:SQLコード内で${パラメータ名}を直接埋め込み、スケジューリングシステムがSQLを送信する前にテキスト置換を完了します。
例:業務日付に基づいてパーティションに書き込み、指定ユーザーの注文をクエリします:
INSERT OVERWRITE TABLE dw.user_daily PARTITION(dt = '${pt_date}')
SELECT * FROM ods.user_log
WHERE dt = '${pt_date}'
AND user_id = ${qt};
パラメータ解析ルール:
${pt_date}:プロジェクトパラメータpt_dateを参照します(値は${yyyyMMdd-1d}で、最終的に20260506として解析されます)。
${qt}:タスクパラメータqtを参照します(値は100です)。
注意:
文字列型のパラメータには引用符を付ける必要があります。例えば、dt = '${pt_date}'で単一引用符を書き忘れると、SQLはdt = 20260506になり、構文エラーが発生します。数値型パラメータには引用符を付けません。例えば、user_id = ${qt}です。

4.2 Shellタスク

パラメータ取得メカニズム:スケジューリングシステムはShellタスクコード内で${パラメータ名}プレースホルダに対して純粋なテキスト置換を行います。置換はタスク送信前に発生します。Shellでは${パラメータ名}の構文はShellのネイティブ変数構文と一致しますが、実際にはWeDataスケジューリングのテキスト置換メカニズムが使用され、Shell環境変数メカニズムとは無関係です。
例:Shellで時間パラメータとカスタムパラメータを使用します:
#!/bin/bash
# 時間パラメータを使用する
echo "Processing data for date: ${yyyyMMdd}"
hdfs dfs -ls /data/warehouse/dt=${yyyyMMdd-1d}/

# プロジェクト/タスクパラメータを使用する
echo "Business date: ${pt_date}"
echo "Project: ${projectIdent}"
注意:
純粋なテキスト置換であるため、WeDataパラメータはShellタスクのメインコードでのみ有効です。メインスクリプトがsourceまたは.などの方法でサブスクリプトを読み込む場合、サブスクリプト内の${パラメータ名}はWeDataによって置換されず、Shellによって通常の環境変数として解析されるだけです。

4.3 Python / PySpark / DLC PySparkタスク

パラメータ取得メカニズム:パラメータは${パラメータ名}の形式でコードテキスト内で直接置換され、SQLタスクと同様です。
例:Pythonタスクでパラメータを使用します
# スケジューリングシステムは実行前にパラメータを実際の値に置換します
pt_date = "${pt_date}"
project = "${projectIdent}"

print(f"Processing data for {project} on {pt_date}")

# ロジックでパラメータを使用する
threshold = ${qt}
if threshold > 50:
print("High threshold mode")
例:PySparkタスクでパーティションデータを読み取ります
pt_date = "${yyyyMMdd-1d}"
df = spark.sql(f"SELECT * FROM ods.events WHERE dt = '{pt_date}'")
df.write.mode("overwrite").saveAsTable("dw.events_daily")
注意:
Pythonコード内の文字列型パラメータは引用符で囲む必要があります(例:"${pt_date}")。そうしないと、スケジューリングシステムによる置換後に裸の文字列20260506となり、Pythonの構文エラーが発生します。数値型パラメータ(例:${qt})は直接数値として使用できます。

4.4 Notebookタスク(DLC専用)

Notebookのパラメータメカニズムは他のタスクタイプとは完全に異なります。${name}によるテキスト置換は行わず、dlcutils関数ライブラリを通じてPython関数呼び出しの方式で読み取ります。
注意:
Notebookパラメータ機能はDLCエンジン + 機械学習リソースグループ(Spark MLlibタイプ)のみをサポートし、かつエンジンイメージバージョンは2026-03-12以上である必要があります。

4.4.1 パラメータの読み取り:dlcutils.widgets.get()

プロジェクトパラメータ、ワークフローパラメータ、タスクパラメータのいずれであっても、Notebookでは統一してdlcutils.widgets.get("パラメータ名")を使用して読み取ります:
project_param = dlcutils.widgets.get("project_param") # プロジェクトパラメータ
workflow_param = dlcutils.widgets.get("workflow_param") # ワークフローパラメータ
task_param = dlcutils.widgets.get("task_param") # タスクパラメータ

4.4.2 Notebookでのシステムパラメータの使用

Notebookは${yyyyMMdd}、${projectIdent}などのシステムパラメータを直接参照することをサポートしていません。「タスクパラメータブリッジ」の方式を通じて行う必要があります:
ステップ1:タスク属性 > 基本情報のタスクパラメータで、ブリッジパラメータを定義し、システムパラメータをタスクパラメータに割り当てます:
パラメータ名
パラメータ値
pt_date
${yyyyMMdd-1d}
projectIdent
${projectIdent}
taskName
${taskName}
ステップ2:Notebookコード内で、widgets.get()を使用してブリッジパラメータを読み取ります:
pt_date = dlcutils.widgets.get("pt_date") # "20260506"
project = dlcutils.widgets.get("projectIdent") # "my_project"
task = dlcutils.widgets.get("taskName") # "user_sync_task"

# パラメータを使用する
df = spark.sql(f"SELECT * FROM ods.user_log WHERE dt = '{pt_date}'")

4.4.3 デバッグシナリオ:widgets.text() を使用したデフォルト値の設定

Notebookはタスク未関連のIDEデバッグシナリオでは、widgets.get()で値が読み取れないとエラーが発生します。事前にwidgets.text()を使用してパラメータとデフォルト値を定義する必要があります:
# パラメータとデフォルト値を定義します(デバッグ時のみ有効)
dlcutils.widgets.text("pt_date", "20260507", "業務日付")

# パラメータを読み取る
pt_date = dlcutils.widgets.get("pt_date")
説明:
Notebookがスケジュールタスクとして実行される場合、タスクパラメータの値はwidgets.text()で定義されたデフォルト値を上書きします。したがって、widgets.text()はデバッグ動作にのみ影響し、本番運用には影響しません。
Notebookの使用方法の詳細については、Notebook開発を参照してください。

4.5 データ統合タスク

適用範囲:オフライン同期、リアルタイム同期。
パラメータ取得メカニズム:Data Integrationタスクのフィールドマッピング、フィルタ条件、ファイルパス、マーカーファイル名などの設定項目で、${パラメータ名}プレースホルダーを使用します。スケジューリングシステムがタスク開始前に置換を完了します。
例1:オフライン同期のWhereフィルタ条件
Kudu、MySQLなどのデータソースの増分同期シナリオでは、時間パラメータを使用して時間範囲を指定します:
create_time >= '${yyyy-MM-dd-1d HH:mm:ss}'
AND create_time < '${yyyy-MM-dd HH:mm:ss}'
例2:ターゲットファイル名を動的に生成します
FTP、HDFSなどのデータソースの同期タスクでは、完了マークファイル名は時間パラメータを使用して日付名の.okファイルを生成します:
/user/test/data_${yyyyMMdd}.ok
例3:組み込みファイル変数との連携
ファイル転送モードでは、Data Integrationの組み込み変数${filetrans_di_src}(ソースファイル名)と時間パラメータを組み合わせることができます:
/user/test/${filetrans_di_src}_${yyyyMMdd}.ok
説明:
Data Integrationがサポートするパラメータ参照構文は、WeDataの汎用時間パラメータと完全に一致しており、オフセット(例:${yyyyMMdd-1d})、タイムゾーンプレフィックス(例:${UTC+0_yyyyMMdd})などが含まれます。各データソースがサポートするパラメータの使用位置については、対応するデータソースの個別ドキュメントを参照してください。

4.6 制御フローノード

4.6.1 分岐ノード

分岐ノードの判断条件にはPython式を使用し、条件内で${パラメータ名}を参照できます。スケジューリングシステムはノード実行前にパラメータを実際の値に置換し、Python構文に従って評価します。
例:
# 数値比較(タスクパラメータqt = 100)
${qt} > 50

# 文字列比較(文字列パラメータは引用符で囲む必要があります)
'${pt_date}' == '20260507'

# 組み合わせ条件
${qt} > 50 and '${pt_date}' >= '20260501'
注意:
文字列型パラメータはPython式内で引用符で囲む必要があります(例:'${pt_date}')。そうしないと、置換後に裸のリテラル20260506となり、Python構文に適合せず解析に失敗します。

4.6.2 For-eachノード

For-eachノードはリストに従ってサブタスクをループ実行することをサポートしており、ループ変数はサブタスク内で${パラメータ名}を通じて参照できます。詳細な使用方法については、For-eachノードを参照してください。

4.7 WeDataパラメータ体系に属さない概念

以下の2種類の「パラメータ」はWeDataパラメータ体系に属しません。区別に注意してください:
Sparkアプリケーションパラメータ:spark.app.name、--nameなどが含まれ、Sparkエンジン設定レベルのパラメータに属し、SparkSQL、PySpark、Sparkタスクで使用され、Yarnアプリケーション名、リソース割り当てなどの制御に用いられます。詳細については、各Sparkタスクノードのドキュメントを参照してください。
コード言語のネイティブ変数:Pythonのローカル変数dt = "20260507"、Shell変数$varなどが含まれ、コード言語自体の変数概念に属し、WeDataパラメータとは相互に影響しません。


ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック