はじめに
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発信と連携しながら、実務ノウハウ・活動実績・キャリア構築戦略を掲載しています。