一般的なワークフローの問題

これがあなたの週のように聞こえますか?

これはエッジケースではありません。これは、複数のツールでGCP Composer DAGを実行しているチームの通常の運用条件です。Control-Mがそれぞれの問題をどのように処理するかを説明します。

データ到着

あなたのCloud Storageオブジェクトは遅れています。Composer DAGはそれでもスケジュールされています。

Control-MはDAGを上流のワークフロー条件と調整し、実行が必要なデータを待つことができるようにします。ワークフローは依存関係が満たされると進行し、早すぎる処理と下流の失敗を防ぎます。

ツール間依存関係

あなたのDataflowジョブは遅れて終わりました。Composerの実行はすでに終了しています。

Control-Mは上流の完了を追跡し、周囲のワークフローとGCP Composer DAGを調整します。ツール間の依存関係が切断されたスケジュールウィンドウを置き換えるので、処理の遅れはDAGが次のスケジュールや手動トリガーを待つことを意味しません。

障害回復

あなたのDAGは午前2時13分に失敗しました。下流のジョブはまだ待っています

Control-MはGCP Composerジョブの状態を監視し、依存関係の作業が進む前に定義された障害処理を適用します。DAGの再実行サポート、定義された障害状態の処理(上流が失敗した場合やスキップされた場合を含む)、および下流の依存関係の制御が失敗を抑制し、盲目的に後続のワークフローステージを解放することなく処理を復元します。

DAG再実行

DAGは途中で失敗しました。今、あなたは制御された再実行が必要です。

Control-MはGCP Composer DAGの再実行をサポートし、失敗したタスクのみを再試行するオプションを提供します。また、構成可能な再実行DAG IDの動作も提供します。回復はオーケストレーションされた生産ワークフローの一部となり、チームが上流および下流の依存関係との調整を維持しながら、制御された方法で処理を再起動するのを助けます。

SLAリスク

DAGはまだ実行中です。あなたの午前7時の配信は危険にさらされています

Control-Mはエンドツーエンドのワークフロー内でComposerジョブを管理し、配信トラッキングのためのSLAジョブをそれに添付できます。チームは上流の遅延とDAGの実行が配信にどのように影響するかを可視化でき、パイプラインの遅延がビジネスの締切を逃す前に運用が対応できるようにします。

Control-M + GCP Composer

Control-M + GCP Composer

workload.types

Airflow DAGの実行 · DAGの再実行(失敗したタスクのみを再試行) · JSONペイロードDAGの実行 · スケジュールされたデータパイプライン · クロスプラットフォームのデータワークフロー

trigger.type

上流のジョブの完了 · ファイルの到着 · 時間スケジュール · ワークフローの依存関係 · API駆動の実行 · Control-Mの条件

cross_tool.deps

Cloud Storageの到着 · Dataflowジョブの完了 · BigQueryジョブ · Dataprocジョブ · REST API呼び出し · ファイル転送の完了

cloud.platforms

Google Cloud Platform · GCP Composer · Cloud Storage · Dataflow · BigQuery · Dataproc

error_handling

DAGの再実行 · 失敗したタスクのみを再試行 · 失敗ステータス処理(上流失敗、スキップ) · DAG ID制御の再実行 · 下流のカスケード防止 · 添付されたSLAジョブ

throughput

スケジュールされたバッチパイプライン · パラメータ化されたDAGの実行 · クロスツールワークフローの実行 · 自動データ引き渡し · タスクログをジョブ出力にキャプチャ

observability

DAGの実行状況 · ジョブ出力 · タスク出力の取得 · Control-Mの監視 · SLAの追跡 · エンドツーエンドの依存関係の可視性

エンドツーエンドのオーケストレーション

1つのプロダクションワークフロー。スタック内のすべてのツール。

Control-Mは、GCP Composer、Cloud Storage、Dataflow、BigQuery、Dataproc、ファイル転送、クラウドサービスを単一のジョブフローでオーケストレーションします — 依存関係の追跡、SLAの可視性、およびそれらすべてにわたる自動回復を備えています。

  • クロスツール依存関係:Cloud Storage → Dataflow → GCP Composer DAG → BigQuery
  • データ対応トリガー:ファイル到着、APIイベント、上流ジョブの完了、DAG結果

GCP Composer 

DAGを実行 · DAGを再実行 · パラメータを渡す · ステータスを監視 · 出力を取得

クラウドストレージ 

ファイル到着の調整 · 下流処理のゲート · ワークフロー依存関係のトリガー

データフロー 

処理ジョブの調整 · 完了の追跡 · 下流実行の制御

BigQuery 

クエリジョブの調整 · 分析処理の順序付け · データ引き渡しの調整

Dataproc

処理ジョブの調整 · 依存関係の管理 · ワークフローステージの接続

ファイル転送 

ファイル配信の調整 · 依存関係の管理 · 下流処理のトリガー

REST API 

外部サービスの呼び出し · アプリケーションの調整 · ワークフローステージの接続

airflow共存

Control-MはあなたのAirflow DAGを置き換えません。それはそれらの上のレイヤーを実行します。

異議は一般的です: “私たちはすでにAirflowを使用しています。” 問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。パイプラインが実際に失敗するのはその部分です。

AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。

airflowは処理します

データパイプライン内のDAGレベルのオーケストレーション

  • DAGレベルのタスクオーケストレーションをデータパイプライン内で
  • Pythonオペレーター、センサー、およびタスクの依存関係
  • パイプライン内で実行されるジョブの実行グラフ
  • 単一のDAGコンテキスト内でのリトライを管理

control-mが追加します

あなたのDAGの周りの調整レイヤー

  • DAGを中心とした調整レイヤー — 上流の条件に基づいてAirflowをトリガーします: ファイルの到着、APIイベント、他のツールの完了
  • 全体のエンドツーエンドワークフローにわたって各DAGのSLA貢献を追跡し、単独のルーチンだけではありません
  • Airflowが開始する前に上流の依存関係が失敗した場合の障害回復を管理
  • 既存のDAGは書き直したり移行したりする必要はありません
未定義

パイプラインを監視する

フルパイプラインでGCP Composer DAGを監視します。

GCP ComposerはAirflow内の可視性を提供しますが、プロダクションパイプラインはしばしばDAGを超えたサービスにまたがります。Control-Mは、完全なデータパイプラインが成功するかどうかを決定する上流および下流ジョブとともに、Composer実行の中央ビューを提供します:

  • DAG実行ステータス

  • ジョブ結果と出力

  • 上流および下流の依存関係

  • タスク出力の取得

  • エンドツーエンドのパイプライン可視性

未定義

SLA保証

ビジネスSLAに合わせてGCP Composerのパイプラインを維持する。

Composer DAGは成功裏に完了することができますが、上流処理が遅れると配信目標を逃すことがあります。Control-Mは、DAG実行をより広いプロダクションワークフローに接続し、定義されたSLAに対してエンドツーエンドの配信を管理するために必要な運用コンテキストを提供します:

  • エンドツーエンドのSLA可視性

  • 上流依存関係の可視性

  • パイプラインの締切監視

  • 失敗を考慮した下流制御

  • 中央集中型ワークフローモニタリング

複雑なワークフローに秩序をもたらす

Control-Mがチームに、より大きな可視性、調整、制御で複雑なプロセスをオーケストレーションする方法を学びます。