一般的なお問い合わせと所在地情報
お問い合わせ一般的なワークフローの問題
これはエッジケースではありません。これは、複数のツールでGCP Composer DAGを実行しているチームの通常の運用条件です。Control-Mがそれぞれの問題をどのように処理するかを説明します。
データ到着
Control-MはDAGを上流のワークフロー条件と調整し、実行が必要なデータを待つことができるようにします。ワークフローは依存関係が満たされると進行し、早すぎる処理と下流の失敗を防ぎます。
ツール間依存関係
Control-Mは上流の完了を追跡し、周囲のワークフローとGCP Composer DAGを調整します。ツール間の依存関係が切断されたスケジュールウィンドウを置き換えるので、処理の遅れはDAGが次のスケジュールや手動トリガーを待つことを意味しません。
障害回復
Control-MはGCP Composerジョブの状態を監視し、依存関係の作業が進む前に定義された障害処理を適用します。DAGの再実行サポート、定義された障害状態の処理(上流が失敗した場合やスキップされた場合を含む)、および下流の依存関係の制御が失敗を抑制し、盲目的に後続のワークフローステージを解放することなく処理を復元します。
DAG再実行
Control-MはGCP Composer DAGの再実行をサポートし、失敗したタスクのみを再試行するオプションを提供します。また、構成可能な再実行DAG IDの動作も提供します。回復はオーケストレーションされた生産ワークフローの一部となり、チームが上流および下流の依存関係との調整を維持しながら、制御された方法で処理を再起動するのを助けます。
SLAリスク
Control-Mはエンドツーエンドのワークフロー内でComposerジョブを管理し、配信トラッキングのためのSLAジョブをそれに添付できます。チームは上流の遅延とDAGの実行が配信にどのように影響するかを可視化でき、パイプラインの遅延がビジネスの締切を逃す前に運用が対応できるようにします。
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の追跡 · エンドツーエンドの依存関係の可視性 |
エンドツーエンドのオーケストレーション
Control-Mは、GCP Composer、Cloud Storage、Dataflow、BigQuery、Dataproc、ファイル転送、クラウドサービスを単一のジョブフローでオーケストレーションします — 依存関係の追跡、SLAの可視性、およびそれらすべてにわたる自動回復を備えています。
|
GCP Composer |
DAGを実行 · DAGを再実行 · パラメータを渡す · ステータスを監視 · 出力を取得 |
|
クラウドストレージ |
ファイル到着の調整 · 下流処理のゲート · ワークフロー依存関係のトリガー |
|
データフロー |
処理ジョブの調整 · 完了の追跡 · 下流実行の制御 |
|
BigQuery |
クエリジョブの調整 · 分析処理の順序付け · データ引き渡しの調整 |
|
Dataproc |
処理ジョブの調整 · 依存関係の管理 · ワークフローステージの接続 |
|
ファイル転送 |
ファイル配信の調整 · 依存関係の管理 · 下流処理のトリガー |
|
REST API |
外部サービスの呼び出し · アプリケーションの調整 · ワークフローステージの接続 |
airflow共存
異議は一般的です: “私たちはすでにAirflowを使用しています。” 問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。パイプラインが実際に失敗するのはその部分です。
AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
airflowは処理します
control-mが追加します
パイプラインを監視する
GCP ComposerはAirflow内の可視性を提供しますが、プロダクションパイプラインはしばしばDAGを超えたサービスにまたがります。Control-Mは、完全なデータパイプラインが成功するかどうかを決定する上流および下流ジョブとともに、Composer実行の中央ビューを提供します:
DAG実行ステータス
ジョブ結果と出力
上流および下流の依存関係
タスク出力の取得
エンドツーエンドのパイプライン可視性
SLA保証
Composer DAGは成功裏に完了することができますが、上流処理が遅れると配信目標を逃すことがあります。Control-Mは、DAG実行をより広いプロダクションワークフローに接続し、定義されたSLAに対してエンドツーエンドの配信を管理するために必要な運用コンテキストを提供します:
エンドツーエンドのSLA可視性
上流依存関係の可視性
パイプラインの締切監視
失敗を考慮した下流制御
中央集中型ワークフローモニタリング
Control-Mがチームに、より大きな可視性、調整、制御で複雑なプロセスをオーケストレーションする方法を学びます。