ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + IBM DataStage
あなたのIBM DataStageワークフローは、並列またはシーケンスジョブが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。IBM Db2の抽出が期待される納品を逃す。IBM MQの取り込みプロセスが一晩の処理ウィンドウの後に終了します。Control-Mは、ソースデータの到着、上流の抽出、IBM DataStageの実行、および下流の納品の全チェーンを調整します。
一般的なワークフローの問題
これはあなたの週のように聞こえますか？
これらは例外的なケースではありません。これは、複数のツールでIBM DataStageジョブを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかを示します。
遅延データ到着
あなたのDb2抽出は遅れています。DataStageは午前2時に予定されています。
Control-Mは上流の完了をDataStage実行の前提条件とし、ジョブは独立したクロックに依存するのではなく、必要なデータを待ちます。下流の処理は依存関係が満たされるまでブロックされ、遅延抽出がパイプラインを通じて波及するのを防ぎます。
失敗したジョブ回復
あなたのDataStageジョブは夜間に中止されました。6つの下流ジョブが待っています。
Control-MはDataStageジョブの結果を検出し、失敗した実行の後に依存ワークロードの実行を防ぎます。実行前リセットおよび再起動モードオプションは、手動で下流の依存関係を調整することなく、オペレーターが処理を復元するのを支援します。
パラメータ管理
ジョブは準備ができています。本番は異なるパラメータセットが必要です。
Control-Mはパラメータリスト、パラメータファイル、またはその両方を通じてDataStageに実行時値を渡します。プロジェクト、ジョブ、呼び出しID、およびパラメータは管理されたジョブ定義の一部となり、異なる本番入力で同じ処理ロジックが実行されるときに手動変更を減少させます。
警告閾値
DataStageは200の警告を記録しました。下流の処理はまだ続行するべきですか？
Control-MはDataStageジョブが中止される原因となる警告の数を定義し、結果として得られるジョブ状態を使用して下流の実行を制御します。チームは警告の解釈を夜間のオペレーターに任せるのではなく、繰り返し可能な本番動作を確立します。
SLAリスク
DataStageはまだ実行中です。あなたの午前7時の引き渡しが近づいています。
Control-MはDataStageの実行をより広範なワークフローとそのサービスレベルのコミットメントに接続します。中央集中的な監視は、上流および下流の依存関係と共にジョブのステータスを公開し、チームが文脈内で遅延を特定し、遅いETLプロセスが配信を危険にさらす前に行動できるようにします。
Control-M + IBM DataStage
Control-M + IBM DataStage
|
workload.types |
並列ジョブ · シーケンスジョブ · ETL処理 · パラメータ化されたジョブ · 複数のジョブ呼び出し |
|
trigger.type |
時間スケジュール · 上流ジョブの完了 · ファイル到着 · Control-Mイベント · API呼び出し · 依存条件 |
|
cross_tool.deps |
IBM Db2ジョブ · 管理されたファイル転送 · Apache Airflow DAG · Sparkジョブ · REST API呼び出し · 分析の納品 |
|
cloud.platforms |
Linuxエージェント · Windowsエージェント · Control-M SaaS · オンプレミスControl-M · ハイブリッド環境 |
|
error_handling |
警告しきい値 · 実行前のリセット · 再起動モード · 戻りコード処理 · 依存関係制御 · SLA監視 |
|
throughput |
並列ジョブの実行 · 複数のジョブ呼び出し · リソースプール · ロックリソース · ワークロード同時実行制御 |
|
observability |
DataStageジョブの状態 · ジョブ結果 · ジョブ出力 · 追加されたDataStageログ · SLA監視 · 実行履歴 |
エンドツーエンドオーケストレーション
1つの生産ワークフロー。スタック内のすべてのツール。
Control-Mは、IBM DataStage、IBM Db2、Airflow、Spark、ファイル転送、クラウドサービス全体でワークフローを調整し、依存関係の追跡、SLAの可視性、および自動回復を実現します。
- クロスツール依存関係: IBM Db2 → IBM DataStage → Spark → 分析の引き渡し
- データ認識トリガー: ファイル到着、APIイベント、上流ジョブの完了、DataStageジョブの状態
|
IBM DataStage |
ジョブ実行 · パラメータ化 · 再起動/リセット · ステータス監視 |
|
IBM Db2 |
データベース処理 · アップストリーム依存関係 · 完了主導の引き渡し |
|
Managed File Transfer |
セキュア転送 · ファイル到着 · ダウンストリームトリガー |
|
Apache Airflow |
DAGトリガー · ステータストラッキング · クロスツール依存関係 |
|
Apache Spark |
ジョブ処理 · 依存関係調整 · ダウンストリーム引き渡し |
|
Cloud services |
クラウドワークロード実行 · イベント依存関係 · ハイブリッドオーケストレーション |
airflow共存
Control-MはあなたのAirflow DAGを置き換えることはありません。上にあるレイヤーを実行します。
一般的な異議があります：「私たちはすでにAirflowを使用しています。」問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。それがパイプラインが実際に失敗する場所です。
AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
AIRFLOWが処理
データパイプライン内のDAGレベルのオーケストレーション
- DAGレベルのタスクオーケストレーションをデータパイプライン内で
- Pythonオペレーター、センサー、タスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一DAGコンテキスト内でのリトライを管理
control-mが追加
DAGの周囲の調整レイヤー
- DAGの周囲の調整レイヤー - 上流の条件（ファイル到着、APIイベント、他のツールの完了）に基づいてAirflowをトリガー
- 各DAGのSLA貢献をフルエンドツーエンドワークフロー全体で追跡し、単独のルーチンだけでなく
- Airflowが開始する前に上流の依存関係が失敗した場合の障害回復を管理
- 既存のDAGは書き直したり移行したりする必要がない
パイプラインの監視
完全なパイプラインを通じてIBM DataStageジョブを監視する。
DataStageは自身のジョブの実行情報を提供しますが、生産パイプラインはしばしばファイル、データベース、処理エンジン、ダウンストリーム消費者にまたがります。Control-MはDataStageを完全なワークフローの中央運用ビューに取り込む:
-
DataStage実行ステータス
-
ジョ結果と出力
-
アップストリームおよびダウンストリーム依存関係
-
ランタイム実行履歴
-
クロスプラットフォームワークフロー可視性
SLA保証
DataStage処理を配信SLAに整合させ続ける。
DataStageジョブは成功裏に実行されることがありますが、それでもビジネスサービスに依存しているために遅れて終了することがあります。Control-MはDataStage処理をエンドツーエンドのワークフロー依存関係およびサービスレベルのコミットメントに接続し、チームがパイプライン全体での納品リスクを管理するのを助けます:
-
エンドツーエンドSLA監視
-
DataStageジョブステータス
-
依存関係レベルの遅延可視性
-
中央集権的な例外監視
-
ダウンストリーム配信追跡
ドキュメント
複雑なワークフローに秩序をもたらす
Control-Mがチームにどのように複雑なプロセスを可視化、調整、制御するかを学ぶ。
