ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Amazon Redshift
Amazon Redshiftワークフローは、COPYコマンドが実行される前から始まります。上流で何かが壊れると失敗する可能性があります。Amazon S3オブジェクトが遅れて到着します。AWS Glue変換が長時間実行されます。Control-Mは、S3データの到着、AWS Glue変換、Redshift実行、そして下流の分析配信までの完全な連鎖を調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これはエッジケースではありません。これは、複数のツールを使用してAmazon Redshiftパイプラインを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかをご覧ください。
S3 · REDSHIFT
あなたのS3データは遅れて到着しました。RedshiftのCOPYウィンドウはすでに通過しました。
Control-MはS3データの可用性をダウンストリーム実行と調整し、上流条件が満たされたときにRedshiftのロードをリリースします。データが準備できたときにCOPYが実行され、壊れやすいタイミングの仮定を排除し、手動介入を減らします。
GLUE · REDSHIFT
あなたのAWS Glue変換は長引きました。Redshiftはまだスケジュール通りです。
Control-Mは上流の完了を追跡し、Redshift処理をリリースする前に、切り離されたスケジュールを明示的な依存関係に置き換えます。AWS Glueが遅れて終了した場合、ダウンストリーム実行は必要な引き継ぎを待機し、不完全または利用できないデータをロードするのではありません。
LOAD FAILURE
COPYは午前2時13分に失敗しました。ダウンストリームの分析はまだ待機中です。
Control-Mは失敗したRedshiftジョブを検出し、そのステータスと出力を公開し、Control-Mで定義した回復アクション（再実行など）を適用し、失敗が解決されるまで依存処理を保持します。オペレーターはワークフローコンテキスト内で失敗を診断し、そのダウンストリームへの影響を抑制できます。
WORKFLOW HANDOFF
Redshiftは成功裏に完了しました。次のパイプラインステージは引き継ぎを受け取っていません。
Control-MはRedshift実行をエンドツーエンドワークフローの明示的な依存関係とし、成功裏に完了した後にダウンストリーム処理をリリースします。チームは孤立したスケジュールと手動チェックを、ツール間で管理された観測可能な引き継ぎに置き換えます。
SLA RISK
午前7時の報告期限が近づいています。Redshiftはまだ処理中です。
Control-MはRedshift処理をエンドツーエンドワークフローのSLAに接続し、ダウンストリームの配信が失われる前に遅延の可視性をチームに提供します。オペレーターは影響を受けた依存関係チェーンを確認し、回復する時間がまだあるうちに介入できます。
Control-M + Amazon Redshift
Control-M + Amazon Redshift
|
workload.types |
SQL文の実行 · S3からRedshiftへのCOPY（データロード） · RedshiftからS3へのUNLOAD（データエクスポート） · ストアドプロシージャの実行 |
|
trigger.type |
ファイル到着 · 時間スケジュール · 上流ジョブの完了 · イベントベースのトリガー · 依存条件 |
|
cross_tool.deps |
Amazon S3データ到着 · AWS Glueジョブの完了 · Apache Airflow DAG · dbt変換 · 下流分析ジョブ |
|
cloud.platforms |
AWS（Amazon Redshift、Amazon S3、AWS Glue） · Control-M SaaS · Control-M自己ホスト（Control-M Webでサポートされるジョブタイプ） |
|
error_handling |
ジョブ失敗検出 · 設定可能な再実行 · 下流カスケード防止 · 上流依存関係保持 · SLAアラート · ジョブ出力キャプチャ |
|
throughput |
スケジュールされたETL/ELTオーケストレーション · マルチジョブワークフロー調整 · パイプライン全体での並列ジョブ実行 · バッチスケジューリング |
|
observability |
ジョブステータス · 結果と出力 · 実行履歴 · 依存関係の可視性 · SLAトラッキング · 中央集権的なワークフローモニタリング |
エンドツーエンドのオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、Amazon Redshift、Amazon S3、AWS Glue、Airflow、dbt、ファイル転送、クラウドサービスのワークフローを単一のジョブフローで調整します。依存関係トラッキング、SLAの可視性、ユーザー定義の再実行および回復アクションがすべてにわたって行われます。
- クロスツール依存関係: Amazon S3 → AWS Glue → Amazon Redshift → 分析ハンドオフ
- データ認識トリガー: ファイル到着、APIイベント、AWS Glueの完了、Redshiftジョブの完了
|
Amazon Redshift |
SQL実行 · COPY · UNLOAD · ストアドプロシージャ · ジョブモニタリング |
|
Amazon S3 |
ファイル到着 · データ可用性依存 · 上流引き渡し |
|
AWS Glue |
変換調整 · ジョブ完了依存 · 下流トリガー |
|
Apache Airflow |
DAG調整 · 上流トリガー · ワークフロー依存 |
|
dbt |
変換調整 · 完了依存 · 下流引き渡し |
|
分析ツール |
配信依存 · スケジュールされた引き渡し · ワークフロー完了 |
|
ファイル転送 |
管理された配信 · 到着依存 · パイプライントリガー |
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を再作成または移行する必要はありません
パイプラインを監視する
フルパイプラインコンテキストでRedshiftジョブを監視する
Amazon Redshiftは倉庫実行の可視性を提供しますが、プロダクションパイプラインはRedshiftを超えています。Control-Mは各ロード、クエリ、引き渡しの周囲のツール全体で実行情報を中央集約し、データチームが完全なワークフローを監視できるようにします：
-
Redshiftジョブ実行ステータス
-
ジョブ結果と出力
-
上流および下流依存性
-
エンドツーエンドの実行履歴
-
クロスプラットフォームワークフロー可視性
SLA保証
Redshiftジョブを超えるSLAを保護する
成功したRedshiftクエリは、完全なデータサービスが時間通りに終了することを保証しません。Control-MはRedshiftの実行を上流および下流依存性と接続し、チームが配信リスクを特定し管理するために必要なワークフローレベルの可視性を提供します：
-
エンドツーエンドのSLA追跡
-
依存性に基づくワークフロー監視
-
早期遅延可視性
-
自動失敗回復
-
下流カスケード防止
ドキュメント
複雑なワークフローに秩序をもたらす
Control-Mがチームがより大きな可視性、調整、制御を持って複雑なプロセスをオーケストレーションするのにどう役立つかを学ぶ。
