はじめに

ETL（Extract, Transform, Load）処理は、データ基盤の安定稼働を支える重要なプロセスです。
しかし、処理失敗時のリカバリ設計が曖昧なままでは、再実行時に二重登録や不整合が発生し、運用トラブルに直結します。

本記事では、JP1 × DataSpider構成を前提に、以下の観点からリカバリ設計を体系的に解説します。

再実行設計（全件・差分・部分）
差分抽出とリカバリ方針の決め方
DataSpiderでのエラーハンドリング構成
マスタ不整合や論理チェックの考え方

💡 対象読者

DataSpider / JP1 を利用してETL処理を設計・運用している方

「再実行時の安全性」「差分再処理」「エラー再投入」などに課題を感じている方

1. ETLリカバリ設計の全体像

リカバリ設計は、ツールの役割ごとに責務を分けて構築します。

レイヤー	主なツール	役割	設計ポイント
ジョブ制御層	JP1/AJS	ジョブ順序・再実行制御・通知	ステップ単位でリカバリ可能に設計
データ変換層	DataSpider Servista	抽出／変換／ロード・エラーハンドリング	冪等性・差分制御・ログ出力
データ整合層	DB（SQL Server / Oracle）	トランザクション・差分抽出・論理チェック	MERGEや一意制約で不整合防止

2. JP1によるリカバリ構成

JP1/AJSは「実行順序と再実行制御」を担います。

🔹 構成例

ジョブネット（全体制御）
├── 抽出ジョブ（DataSpider呼出）
├── 変換ジョブ（DataSpider呼出）
├── ロードジョブ（DataSpider呼出）
└── 終了判定ジョブ（ステータス更新）

🔹 設計ポイント

ステップ単位再実行：失敗箇所からの再開が容易。
異常検知・通知連携：JP1のイベント通知→メール／Slackなど。
依存関係制御：前ジョブ正常終了時のみ後続を起動。

💡 JP1は「いつ・どの範囲を再実行するか」を制御する上位層。
実際のデータ処理はDataSpiderに委譲します。

3. DataSpiderによるリカバリ設計と冪等性保持

DataSpiderは「どのレコードをどう再処理するか」を担う実行層です。

🔹 基本構成

[入力フロー]
 → [変換フロー]
   → [ロードフロー]
     → [完了 or エラーフロー]

🔹 実装のコツ

トランザクション設計：テーブル単位ではなく業務単位でコミット。
ログテーブル：開始・終了・異常情報を記録。再実行時に参照可能。
再実行パラメータ化：処理日付・キー範囲などを引数化し部分再実行を可能に。

例：処理日付をパラメータで指定

SELECT * 
FROM source_table 
WHERE last_updated > :last_exec_time

🧩 再実行を想定したDataSpider設計のポイント

成功・失敗のログを明示的に残す

処理単位をモジュール化（ジョブ単位再実行に対応）

データ件数・更新件数をリターン値でJP1に返却

4. 差分処理時のリカバリ方針

差分設計のリカバリ方針は、「どの段階で差分管理するか」で異なります。

対象段階	リカバリ方法	実装例
抽出	再抽出	`last_updated > last_exec_time` 条件で再取得
変換	一時テーブル再変換	中間テーブルに変換結果を保持
ロード	差分再登録	MERGE文やUPSERT構文を使用

差分再処理SQL例（SQL Server）

MERGE INTO target_table AS T
USING source_table AS S
ON T.id = S.id
WHEN MATCHED THEN
  UPDATE SET T.value = S.value
WHEN NOT MATCHED THEN
  INSERT (id, value) VALUES (S.id, S.value);

💡 再実行範囲の考え方
失敗時は「前回バッチ＋α（1時間・1日など）」で再実行する設計が安全。
時刻ずれやトランザクション遅延による取りこぼしを防ぎます。

5. 論理チェック設計とエラーデータ再投入

ETLでは「通信・SQLエラー」よりも、「業務ロジックエラー（論理エラー）」の方が再実行設計を複雑にします。

🔹 よくある論理チェック例

チェック内容	タイミング	処理方針
マスタ未登録データをINSERT対象にしている	変換時	エラーログ出力＋スキップ or 強制エラー終了
NULL禁止項目欠損	抽出 or 変換	デフォルト値設定 or エラー扱い
重複キー	ロード	MERGE文または一意制約で防止

🔹 設計のポイント

エラー行は専用エラーテーブルに退避
エラー件数が閾値超過 → ジョブ異常終了（JP1で検知）
修正後のデータのみ再投入可能なようにDataSpider側で再抽出条件をパラメータ化

💬 実運用のコツ

「論理修正後の再投入」を明示的に区別する（物理再実行とは別）

ETL全体で「どの層で検知・除外するか」を統一しておく

6. 設計まとめ

JP1 × DataSpiderでのETLリカバリ構成は、下図のように分層化して設計するのがポイントです。

層	役割	主な設計観点
JP1 (制御層)	ジョブ制御・再実行・通知	再実行単位・依存関係・異常通知
DataSpider (実行層)	データ抽出・変換・ロード	冪等性・差分管理・ログ化
DB (整合層)	整合性担保	MERGE構文・制約・論理チェック

これにより、障害発生時にも次のような運用が可能になります。

どの段階で失敗したか明確
再実行範囲を柔軟に指定可能
データ整合性が担保されたまま再投入可能

7. まとめ

ETLのリカバリ設計は「誰が・どこで・どのように再実行するか」を明確にすることが鍵です。

JP1：再実行の範囲と順序を制御
DataSpider：再実行対象データを特定・処理
DB：冪等性と整合性を保証

この三層分離ができていれば、障害時もトラブルを最小限に抑え、安定稼働が実現できます。

参考資料

🧠 関連記事

🌐 運営ブログのご紹介

📘 MyWay Going（マイウェイ・ゴーイング）
データ連携・ETL・DB設計を専門とするフリーランスエンジニアのポートフォリオサイト。
Qiita発信と連携しながら、実務ノウハウ・活動実績・キャリア構築戦略を掲載しています。