DataWorks:データバックフィルに関するよくある質問

データバックフィルの仕組み

時間単位および分単位ノードでの並列実行が効かない理由

• 症状

  時間または分単位でスケジュールされたノードについて、データバックフィル時の並列実行を有効にしても、インスタンスが並列で実行されません。

• 原因

  データバックフィル時の並列実行設定は、日単位粒度で複数のデータタイムスタンプに対応するインスタンスを同時に実行するかどうかを決定します。時間単位または分単位ノードにおける同日内の同時実行制御には影響しません。これらのノードの同日内同時実行は、自己依存が設定されているかどうかによって決まります。詳細については、「シナリオ 2：前周期への依存関係の設定」をご参照ください。

• 解決策

  • 並列実行を無効にすると、異なるデータタイムスタンプのインスタンスが直列で実行されます。次のデータタイムスタンプのインスタンスは、前のインスタンスが完了後に開始されます。

  • 並列実行を有効にすると、同時実行インスタンス数（例：2、3、4、5）を設定して、複数のデータタイムスタンプに対するデータバックフィルインスタンスを並列で実行できます。

  例となるシナリオ：時間単位または分単位ノードについて、1 週間分のデータをバックフィルする必要があるとします。

  • ノードに自己依存が設定されている場合、その週のインスタンスは時系列順に逐次実行されます。

  • ノードに自己依存が設定されていない場合、各日のインスタンスがすべて並列で実行されます。

インスタンスが [保留中 (スケジュール)] 状態になる理由

• 症状

  データをバックフィルするためにデータタイムスタンプを指定した後、インスタンスが実行されず、黄色でハイライトされた [保留中 (スケジュール)] 状態のままになります。

• 原因

  これは、選択したデータタイムスタンプに対応するスケジュール実行時間が将来の時間である場合に発生します。

• 解決方法

  これらのインスタンスをすぐに実行するには、[データバックフィル] ダイアログボックスで [現在時刻以降にスケジュールされた遡及インスタンスを実行] オプションを選択します。

  説明

  • 将来の実行時間に対応するデータタイムスタンプを選択し、このチェックボックスをオンにしない場合、インスタンスは [保留中 (スケジュール)] 状態になります。

  • 将来の実行時間に対応するデータタイムスタンプを選択し、このチェックボックスをオンにした場合、インスタンスはすぐに実行されます。

最近のバックフィルが保留状態になる理由

• 症状

  昨日または今日のデータタイムスタンプのデータをバックフィルすると、インスタンスが [保留中 (スケジュール)] 状態になります。

• 原因

  プラットフォームのスケジューリングは通常 T+1 モデルに基づいており、これは昨日のデータタイムスタンプを持つデータが今日スケジュールされた実行によって処理されることを意味します。特定のデータタイムスタンプのデータをバックフィルする際には、その日付のサイクルインスタンスを再実行していることになります。

  今日スケジュールされたサイクルインスタンスを確認するには、[オペレーションセンター] > [サイクルタスク O&M] の [サイクルインスタンス] ページで、[データタイムスタンプ] フィルターを [昨日] に設定して、対応するサイクルインスタンスとそのステータスを表示します。

バックフィルで複数のインスタンスが生成される理由

• 症状

  00:00 ～ 01:00 のような時間範囲でデータをバックフィルすると、複数のインスタンスが生成されます。

• 原因

  生成されるインスタンス数は、ノードのスケジューリング構成に依存します。

  • たとえば、00:00 ～ 23:59 の間、毎時実行されるようにスケジュールされた時間単位ノードの場合、00:00 ～ 01:00 の時間範囲でデータをバックフィルすると、00:00 および 01:00 にスケジュールされた実行時刻を持つ 2 つのインスタンスが生成されます。

  • 同様に、30 分ごとに実行されるようにスケジュールされたノードの場合、00:00 ～ 01:00 の時間範囲でデータをバックフィルすると、00:00、00:30、および 01:00 にスケジュールされた実行時刻を持つ 3 つのインスタンスが生成されます。

大規模バックフィルがリソース待ちになる理由

• 症状

  大規模なデータバックフィル操作中に、一部のインスタンスが黄色でハイライトされた [保留中 (リソース)] 状態になります。

• 原因

  各リソースグループには、実行中のノードの最大同時実行数制限があります。同時に実行されているノード数がこの制限を超えると、新しいインスタンスは [保留中 (リソース)] 状態でキューに入れられます。

  説明

  この問題のトラブルシューティングについては、「リソース待ち」をご参照ください。

「実行時間が範囲外」というエラーが発生する理由

• 症状

  データバックフィル中に、「トリガーされたノードの実行時間が選択した時間範囲外である」というエラーが発生することがあります。

• 原因

  このエラーは、ノードの実際のスケジュール実行時間が指定した時間範囲外にある場合に発生します。時間単位および分単位ノードでは、データバックフィルのために実行時間ウィンドウを指定する必要があります。[データバックフィル] ダイアログボックスで [実行時間ウィンドウの選択] を 00:00 ~ 01:00 に設定したにもかかわらず、トリガーされたノードが別の時刻にスケジュールされている場合、バックフィル操作は失敗します。これを解決するには、ノードのスケジュール実行時間を含むように実行時間ウィンドウを調整してください。

バックフィルインスタンスが生成されない理由

• 症状

  ノードに対してデータバックフィル操作を開始しましたが、バックフィルインスタンスが生成されませんでした。

• 原因

  データタイムスタンプがノードの有効日付範囲外である場合、インスタンスは生成されません。バックフィルのデータタイムスタンプがノードの有効日付範囲内にあることを確認してください。ノードの スケジューリング構成 パネルでは、次のような設定が確認できます：時間属性 は [通常スケジューリング]、再実行属性 は未選択、エラー時の自動再実行 は未選択、有効日付範囲 は 1999-09-09 ～ 1999-10-22（この範囲内でのみスケジューリングが有効）、スケジューリングの一時停止 は未選択、スケジューリング周期 は [日次]、スケジュール時刻は 00:19。データバックフィルのデータタイムスタンプが 有効日付範囲 外である場合、バックフィルインスタンスは生成されません。

週次および月次ノードのバックフィル

• 説明：週次または月次ノードのデータをバックフィルする際には、データタイムスタンプをスケジュール実行日の前日に設定する必要があります。特定の曜日または月の日にスケジュールされたノードは、その指定された日だけ実行されます。他の日にはドライランインスタンスが生成されますが、ノードは実際に実行されません。このようなインスタンスのステータスは、週次または月次のドライランサイクルを示します。詳細については、「シナリオ 1：週次/月次のドライランサイクル」をご参照ください。

  説明

  • バックフィルのデータタイムスタンプは、次の式で計算されます：data timestamp = Scheduled run date - 1 day。

  • スケジューリングパラメーター、データタイムスタンプ、スケジュール時刻、実際の実行時刻の関係については、「スケジューリングパラメーターでサポートされるフォーマット」をご参照ください。

• 例：月次ノードのデータバックフィル

  毎月の第 1 日の 00:00 に実行されるようにスケジュールされたノードの場合、データタイムスタンプを前月の最終日に設定する必要があります。スケジューリング周期 が [月次] で実行時刻が 00 00 00 1 * ? である月次ノードの場合、2022 年 11 月のデータを処理するために、[データバックフィル] ダイアログボックスで [データタイムスタンプ] の開始日と終了日を両方とも 2022-11-30 に設定し、[OK] をクリックします。

並列インスタンス数の上限がバックフィルに与える影響

• ノードに対して 最大並列インスタンス数 設定が有効になっている場合、この上限はデータバックフィルインスタンスと通常のサイクルインスタンスの両方に適用されます。これらは同じ同時実行クォータを共有します。

• インスタンスの同時実行数が上限を超えると、システムは主に今日以前のデータタイムスタンプを持つ既存データバックフィルインスタンスをスロットルします。

• 最大並列インスタンス数の上限は、設定を有効にした後に生成されたインスタンスにのみ適用されます。すでに実行中またはキューに入っているインスタンスには影響しません。

• 最大並列インスタンス数の値は 1 ～ 10,000 の範囲で設定でき、デフォルト値は 1 です。

OpenAPI による並列データバックフィルで Can't update ObjectId BeginTs less than lastCommitTs または「ODPS-0429311 metadata transaction conflict」が報告された場合の対処方法

• 原因

  並列データバックフィル中に、異なるデータタイムスタンプのタスクが同時に実行され、テーブル DDL 操作（例：同時実行の ALTER TABLE 文）、自動マージと手動 DDL 操作の衝突、またはスケジュールの重複などが発生すると、MaxCompute のメタデータトランザクション競合または DDL 競合が発生します。

• 解決策

  データバックフィル API の Parallelism パラメーターを false に設定して、タスクをシリアルに実行し、メタデータを同時に変更しないようにします。競合がまれにしか発生しない場合は、リトライで通常解決します。

• 追加情報

  Parallelism を false に設定すると、複数のデータタイムスタンプに対するデータバックフィルワークフローは厳密なシリアル順序で実行されます。つまり、次のデータタイムスタンプのインスタンスは、前のデータタイムスタンプのすべてのインスタンスが成功した後にのみ開始されます。上流のデータタイムスタンプのタスクが失敗した場合、下流のデータタイムスタンプのデータバックフィルインスタンスは [未実行] 状態（旧バージョンの API では「作成中」と表示）のままになります。現在、タスク全体のステータスを直接照会する API は提供されていません。データタイムスタンプごとのインスタンスステータスを照会する必要があります。

実行が遅いデータバックフィルタスクのトラブルシューティング方法

• リソースグループの負荷を確認

  リソースグループの使用量を確認します。使用量が高い場合、リソースグループが完全に占有されており、タスクがキューに入れられています。同時実行タスク数を減らすか、リソースグループをスケールアップしてください。

• MaxCompute ジョブログ (Logview) の分析

  リソースグループが完全に占有されていないにもかかわらずタスクが遅い場合は、Logview URL を取得して SQL 実行効率を分析します。たとえば、JOIN 操作の出力が入力よりもはるかに大きいといったデータ肥大化が発生していないかを確認します。[Input information] を使用して、具体的な SQL ノードや関連テーブル（例：結合キー値のディストリビューションが不均等なためデカルト積が発生するディメンションテーブルとファクトテーブルの JOIN）を特定します。SQL 最適化については、MaxCompute 公式ドキュメントをご参照ください。

データバックフィル結果とローカルで SQL ステートメントを実行した結果が一致しない場合のトラブルシューティング方法

• 環境の一貫性を確認

  DataWorks の本番環境に接続されているデータソースが、ローカルで接続しているものと完全に同一であるかを確認します。テストデータベースと本番データベースを区別してください。

• パーティション値を確認

  データバックフィルタスクで使用されているパーティション値（例：ds='20260212'）が、ローカルクエリで使用されているパーティション値と一致しているかを確認します。SQL ステートメント内のパーティションフィールドに値を割り当てるロジックとデータタイムスタンプのフォーマットを確認してください。

• タイムゾーン構成を統一

  ローカルクエリの先頭に SET odps.sql.timezone = <time zone>;（例：SET odps.sql.timezone = America/Cancun;）を追加して、時間フィールドがデータバックフィルタスクと同じ方法で解析されるようにします。これにより、TO_CHAR や DATEADD などの関数における計算の違いを回避できます。

• 完全な SQL ロジックを再現

  送信先テーブルの行数をカウントするだけではなく、DataWorks の実行ログから完全な SQL ステートメント（すべての JOIN や CASE ロジック、および SET パラメーターを含む）をローカルで実行します。

• コンソールで検証

  ローカル環境からの干渉を排除するために、同じ SQL ステートメントを DataWorks コンソールで直接実行します。