ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + GCP Dataproc
あなたのGCP Dataprocワークフローは、Sparkバッチが実行される前に始まります — そして、上流で何かが壊れると失敗する可能性があります。Cloud Storageオブジェクトが遅れて到着します。BigQuery準備ジョブが期待される完了ウィンドウを逃します。Control-Mは完全なチェーンをオーケストレーションします：Cloud Storageの到着、BigQueryの準備、Dataprocの実行、そして下流の配信 — そのため、あなたのSparkバッチは実際に依存しているデータが準備できているときだけ実行されます。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。複数のツールで GCP Dataproc ジョブを実行しているチームにとって、通常の運用条件です。Control-M がそれぞれをどのように処理するかは次のとおりです。
遅延データ到着
あなたの午前 2 時の Spark ジョブが開始します。Cloud Storage オブジェクトが遅れています。
Control-M は上流のデータ到着をジョブフローの一部とし、Dataproc 処理は必要な入力の確認された到着を待つため、固定時間スケジュールで開始するのではありません。依存するワークロードは前提条件が完了したときのみ開始され、不完全なデータ処理を防ぎます。
失敗したバッチ
あなたのサーバーレス Spark バッチはキャンセルされました。下流の処理はまだ待機しています。
Control-M は Dataproc 実行を監視し、キャンセルされたバッチを失敗状態として認識します。下流の依存関係は、不完全な処理が進行するのではなく、ブロックされたままになります。これにより、オペレーターは制御された回復パスを持ち、失敗がパイプライン全体に波及するのを防ぎます。
状態ポーリング
Spark ジョブはまだ実行中です。次のステージは安全に開始できません。
Control-M は Dataproc ジョブの状態を設定可能な確認間隔でポーリングし、ジョブが Not OK で終了する前に定義された許容範囲を適用します。下流の作業は推定完了ウィンドウではなく、実際の実行状態に従います。
クロスツール依存
Dataproc は正常に終了しました。BigQuery のハンドオフはまだ調整が必要です。
Control-M は Dataproc と BigQuery のジョブを同じエンドツーエンドのワークフローに配置し、下流の処理が上流の成功した完了に依存できるようにします。ハンドオフはジョブの状態に従い、別々のスケジュールではなく、処理ステージ間のタイミングギャップを減少させます。
重複実行
サーバーレスバッチリクエストが再試行されます。重複処理のリスクはありません。
Dataproc Serverless for Spark バッチの場合、Control-M はバッチ ID とリクエスト ID パラメータをサポートします。リクエスト ID は CreateBatch リクエストを特定します。Dataproc は同じ ID を持つ 2 番目のリクエストを無視し、元のバッチに関連付けられた操作を返します。
Control-M + GCP Dataproc
Control-M + GCP Dataproc
|
workload.types |
ワークフローテンプレート · 単一のDataprocジョブ · Sparkバッチ用のDataprocサーバーレス · インタラクティブセッション · ビッグデータ処理 · 機械学習ワークロード |
|
trigger.type |
ファイル到着 · 上流ジョブの完了 · 時間スケジュール · Control-Mの依存関係 · API駆動の実行 · クロスアプリケーションジョブ状態 |
|
cross_tool.deps |
GCP BigQueryジョブ · GCP Dataflowジョブ · GCP Composer DAG · Cloud Storageファイル · ファイル転送の完了 · REST API呼び出し |
|
cloud.platforms |
Google Cloud Platform · Dataproc · Spark用のDataprocサーバーレス · Control-M SaaS · Control-M Web · 自動化API · ハイブリッド企業ワークフロー |
|
error_handling |
検証ポーリング間隔 · 設定可能な耐性 · キャンセルされたバッチの失敗検出 · 下流のカスケード防止 · 依存関係に基づく回復 · 要求されたID |
|
throughput |
並列Dataproc処理 · サーバーレスSparkバッチ · 大規模バッチ処理 · ビッグデータワークロード |
|
observability |
Dataprocジョブの状態 · 結果と出力 · 依存関係の状態 · ワークフロー監視 · 実行履歴 · エンドツーエンドのジョブ可視性 |
エンドツーエンドオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、GCP Dataproc、BigQuery、Dataflow、Cloud Composer、Cloud Storage、ファイル転送、およびすべてのクラウドサービスを単一のジョブフローでオーケストレーションします — 依存関係の追跡、SLAの可視性、すべての自動回復を含みます。
- クロスツール依存関係：Cloud Storage → BigQuery → GCP Dataproc → 分析の引き渡し
- データ認識トリガー：ファイル到着、APIイベント、上流ジョブの完了、Dataprocの完了
|
GCP Dataproc |
ワークフローテンプレート · Dataprocジョブ · Sparkバッチ用のサーバーレス · インタラクティブセッション · ステータスポーリング |
|
GCP BigQuery |
データ処理 · 分析ジョブ · アップストリーム準備 · ダウンストリーム分析 |
|
GCP Dataflow |
バッチ処理 · ストリーミングパイプライン · ジョブ間依存関係 · ワークフローハンドオフ |
|
GCP Composer |
Airflow DAG 実行 · DAG 再実行（失敗したタスクのみを再試行するオプション） · クロスプラットフォーム依存関係 · ワークフロー調整 |
|
Cloud Storage |
ファイル到着 · 入力ステージング · 出力配信 · データ駆動の依存関係 |
|
ファイル転送 |
ファイル監視 · 管理された転送 · 配信確認 · ダウンストリーム処理トリガー |
|
REST APIs |
アプリケーションコール · ワークフローハンドオフ · API駆動の自動化 · クロスプラットフォーム調整 |
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 を書き換えたり移行する必要はありません
パイプラインを監視する
Dataprocの実行を完全なデータパイプライン全体で監視します。
Dataprocは独自のサービス内で実行を報告しますが、プロダクションパイプラインはストレージ、準備、処理、配信にまたがります。Control-Mは、接続されたジョブを1つの運用ビューに統合し、チームがエンドツーエンドのコンテキストで実行を監視できるようにします：
-
Dataprocジョブステータス
-
結果とジョブ出力
-
アップストリームおよびダウンストリーム依存関係
-
クロスプラットフォーム実行可視性
-
中央集権的なワークフローモニタリング
SLA保証
Dataprocパイプラインを配信の締切に合わせて調整します。
成功したDataprocジョブは、完全なデータサービスが時間通りに完了することを保証しません。Control-Mは、より広範なワークフロー内で処理ステップを追跡し、チームが依存関係の遅延を特定し、エンドツーエンドのサービスの期待に対して配信を管理するのを助けます：
-
エンドツーエンドSLA可視性
-
アップストリーム依存関係の追跡
-
ダウンストリーム配信の監視
-
例外主導の運用対応
-
クロスプラットフォームワークフローステータス
ドキュメント
複雑なワークフローを整理する
Control-Mがチームに複雑なプロセスをより良い可視性、調整、制御でオーケストレーションする方法を学びます。
