ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + 天文学者
あなたの天文学者ワークフローは、Airflow DAGが実行される前に始まります。上流で何かが壊れると失敗する可能性があります。Amazon S3オブジェクトが遅れて到着します。dbt Cloudの変換が期待される完了ウィンドウを逃します。Control-Mは、S3データの到着、dbt Cloudの変換、天文学者DAGの実行、Snowflakeの読み込みを調整します。
一般的なワークフローの問題
これはあなたの週のように聞こえますか？
これは特異なケースではありません。これは、複数のツールでAstronomer DAGを実行しているチームのための通常の運用条件です。Control-Mが各ケースをどのように処理するかを以下に示します。
上流遅延
あなたの2:00 a.m. DAGは準備ができています。しかし、S3データはまだです。
Control-Mは必要な上流データが到着するまでAstronomer DAGを保持し、依存関係が満たされたときにそれを起動します。ワークフローは切り離された時計のスケジュールではなく、実際のデータの準備状況に従い、早すぎる実行や回避可能な下流の失敗を防ぎます。
DAG失敗
1つのAirflowタスクが失敗しました。下流の報告チェーンはすでに待機しています。
Control-MはAstronomerのジョブステータスを監視し、DAGを再実行できます。失敗したタスクのみを再実行することも含まれます。下流のControl-Mジョブは依存関係によって管理され、失敗したDAGが他の企業ワークフローに不完全なデータを静かに伝播するのを防ぎます。
ツール間依存性
dbtが遅れて終了しました。あなたのAstronomer DAGにはまだ正しいトリガーが必要です。
Control-MはdbtジョブとAstronomer DAGを1つのワークフローでモデル化し、上流の完了状態を評価し、依存関係が満たされたときのみDAGを開始します — 脆弱な時間オフセットや独立してスケジュールされたプラットフォーム間の手動調整を排除します。
SLAリスク
DAGは実行中ですが、7:00 a.m.の配信が遅れています。
Control-MはAstronomerジョブにSLA管理を追加し、広範なワークフローに対するその貢献を追跡します。チームは文脈内でスケジュールリスクを特定し、遅延したDAGがエンドツーエンドのデータ配信を必要なビジネスウィンドウを超えて押し出す前に介入できます。
失敗回復
DAGは3:17 a.m.に失敗しました。運用には文脈が必要であり、もう1つのコンソールは必要ありません。
Control-MはAstronomerワークフローステータス、結果、出力、ログをオーケストレーション環境内で表示します。オペレーターは失敗を特定し、必要に応じて中止し、複数のスケジューリングおよび監視ツール間で周囲の依存関係チェーンを再構築することなく回復を調整できます。
Control-M + 天文学者
Control-M + 天文学者
|
workload.types |
Airflow DAGの実行 · DAGの再実行 · 失敗したタスクの再実行 · パラメータ化されたDAGの実行 · 手動JSON実行 · 複数の天文学者ジョブ |
|
trigger.type |
上流ジョブの完了 · ファイル到着 · API/イベント条件 · 時間スケジュール · Control-M依存関係 · ビジネスカレンダー · 手動実行 |
|
cross_tool.deps |
dbt Cloudジョブ · Snowflakeジョブ · Databricksジョブ · Amazon S3ファイル到着 · REST API呼び出し · 管理されたファイル転送 |
|
cloud.platforms |
Astro · 天文学者ソフトウェア · AWS接続ワークフロー · Microsoft Azure接続ワークフロー · Google Cloud接続ワークフロー |
|
error_handling |
DAGの再実行 · 失敗したタスクのみの再実行 · 設定可能な失敗許容 · ステータスポーリング · ワークフロー中止 · 下流のカスケード防止 · ログの取得 |
|
throughput |
エージェントごとに複数の天文学者ジョブを同時に実行 · パラメータ化された実行 · 大規模企業スケールのクロスワークフロー調整 |
|
observability |
天文学者ジョブのステータス · ワークフロー結果 · ジョブ出力 · ログの取得 · SLAトラッキング · エンドツーエンドの依存関係の可視性 · Control-Mモニタリング |
エンドツーエンドのオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、天文学者、dbt Cloud、Snowflake、Databricks、ファイル転送、およびクラウドサービス全体でワークフローを1つのジョブフローで調整します。依存関係の追跡、SLAの可視性、および自動回復を備えています。
- ツール間の依存関係: dbt Cloud → 天文学者DAG → Snowflakeの読み込み → 分析の引き渡し
- データ対応トリガー: ファイル到着、APIイベント、上流ジョブの完了、スケジュール条件
|
天文学者 |
DAGを実行 · DAGを再実行 · 失敗したタスクを再実行 · JSONパラメータを渡す · ステータスを監視 · ログを取得 |
|
dbt Cloud |
ジョブをトリガー · 完了を監視 · ダウンストリーム依存関係を調整 |
|
Snowflake |
ジョブをオーケストレーション · データ処理を調整 · ダウンストリーム依存関係を管理 |
|
Databricks |
ジョブをオーケストレーション · 処理を調整 · ダウンストリームワークフローを接続 |
|
Amazon S3 |
ファイル到着を検出 · ダウンストリーム処理を制御 · 取り込みを調整 |
|
Managed File Transfer |
安全なファイル移動 · 配信依存関係 · 転送監視 |
|
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は書き換えたり移行したりする必要はありません
パイプラインを監視
ワークフロー全体のコンテキストでAstronomer DAGを監視します。
AstronomerはAirflow環境内の可視性を提供しますが、プロダクションデータパイプラインはしばしば多くのプラットフォームにまたがります。Control-MはAstronomerの実行を上流および下流のジョブと同じ運用ビューに持ち込み、チームにワークフロー全体のエンドツーエンドのコンテキストを提供します:
-
Astronomerジョブ実行状況
-
ワークフロー結果と出力
-
上流および下流の依存関係
-
Astronomerログ取得
-
クロスプラットフォームのワークフロー可視性
SLA保証
ビジネスの納期に対するAstronomer DAGの管理。
成功したDAGは、上流処理が遅れたり、下流作業が長引いたりすると、ビジネスの締切を逃す要因となることがあります。Control-Mは、AstronomerジョブをエンドツーエンドのSLA管理に接続し、チームがDAG完了だけでなく配信結果を管理できるようにします:
-
エンドツーエンドのSLA追跡
-
Astronomer SLAジョブの関連付け
-
クロスプラットフォーム依存関係の監視
-
自動化された失敗処理
-
ビジネスの締切の可視性
-
調整された失敗回復
ドキュメント
複雑なワークフローに秩序をもたらす
Control-Mがチームに複雑なプロセスをより大きな可視性、調整、制御でオーケストレーションする方法を学ぶ。
