ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + AWS S3
あなたのAmazon S3ワークフローは、PutObject操作がオブジェクトをバケットに書き込む前に始まります。そして、上流で何かが壊れると失敗する可能性があります。Amazon Kinesis Data Firehose配信ストリームは、バッファされたレコードをターゲットプレフィックスにフラッシュしません。AWS Transfer Family SFTPセッションは、アップロードを完了する前に接続タイムアウトを超えます。Control-Mは、Amazon Kinesis Data Firehoseの取り込み、AWS Glue ETL変換、Amazon S3実行、およびAmazon Redshift配信の全体を調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。これらは、複数のツールにわたって AWS S3 データパイプラインを実行しているチームの通常の運用条件です。Control-M がそれぞれをどのように処理するかを示します。
ファイル到着
上流のエクスポートが S3 に到達しませんでした。下流のジョブはまだ開始されました。
アプリケーション、ETL プラットフォーム、またはパートナー転送が配信ウィンドウを逃し、期待されるオブジェクトがバケットから欠落しています。Control-M は検証されたオブジェクトの到着を待ち、必要な条件を確認し、正しいファイルが利用可能になるまで下流のワークフローをリリースしません - 失敗したジョブと不必要な再実行を排除します。
データ依存関係
ファイルが S3 に到着しました。Spark が早すぎてトリガーされました。
オブジェクトは、アップロードが完了する前や、必要なデータセットがすべて到着する前に表示される場合があります。Control-M は、Spark、AWS Glue、EMR、Databricks、または他の下流のワークロードをトリガーする前に、ファイルの可用性、命名パターン、タイムスタンプ、および上流の完了を含む複数の依存関係条件を評価します。
障害回復
失敗したコピー ジョブが、6 つの下流のワークフローを一晩で壊しました。
上流の取り込み、複製、または変換ジョブが失敗すると、Control-M は即座に終了ステータスを検出し、下流の実行を防ぎ、構成可能なリトライポリシーを適用し、成功した回復の後のみワークフローを再開します - パイプライン全体でカスケード失敗を回避します。
クロスツール フロー
ワークフローは AWS、データベース、API、および分析プラットフォームにまたがっています。
S3 はパイプラインの単なる一段階です。Control-M は、クラウドストレージ、データベース、ETL ツール、データウェアハウス、分析プラットフォーム、REST API、管理されたファイル転送、およびカスタムアプリケーション全体にわたって依存関係をオーケストレーションします。単一のエンドツーエンドワークフローで中央集権的に監視します。
SLA 可視性
朝のダッシュボードが遅れました。誰も実行がどこで停止したのかを知りませんでした。
ネイティブサービスの監視は、個々のタスクのステータスを示しますが、ビジネスワークフローの進捗は示しません。Control-M は、完全なパイプライン全体を通じてエンドツーエンドの可視性を提供し、期限が切れる前に SLA リスクを予測し、適切なチームに警告し、完全な依存関係の追跡でトラブルシューティングを加速します。
統合の事実
Control-M + AWS S3
|
workload.types |
オブジェクトの取り込み · データレイクパイプライン · ETL/ELTワークフロー · バッチファイル処理 · イベント駆動型データ処理 · バックアップおよびアーカイブワークフロー · 分析データのステージング · 機械学習データの準備 |
|
trigger.type |
S3オブジェクト到着 · ファイルパターンマッチ · REST API呼び出し · 上流ジョブの完了 · 管理されたファイル転送の完了 · 時間スケジュール · アプリケーション終了コード |
|
cross_tool.deps |
AWS Glueジョブトリガー · Amazon EMRジョブ · Apache Sparkワークフロー · Apache Airflow DAGトリガー · Databricksジョブ · Amazon Redshiftロード · REST API統合 · 管理されたファイル転送確認 |
|
cloud.platforms |
Amazon Web Services (AWS) · Microsoft Azure · Google Cloud Platform · ハイブリッドクラウド · Control-M SaaS · Control-Mオンプレミス |
|
error_handling |
構成可能な再試行ポリシー · 自動ワークフロー回復 · 下流のカスケード防止 · 上流の失敗時のジョブ保持 · SLA違反予測 · Slack通知 · PagerDuty統合 |
|
throughput |
高ボリュームオブジェクト処理 · 並列ワークフロー実行 · 大規模バッチオーケストレーション · イベント駆動型処理 · マルチテラバイトデータパイプライン · スケーラブルなクラウドストレージワークロード |
|
observability |
エンドツーエンドのワークフローモニタリング · ジョブレベルの監査トレイル · 依存関係系譜の可視化 · SLA追跡と予測 · 中央集権的な運用ダッシュボード · Datadog統合 · Splunk統合 |
エンドツーエンドのオーケストレーション
1つの生産ワークフロー。スタック内のすべてのツール。
Control-Mは、AWS S3、AWS Glue、Amazon EMR、Apache Airflow、Databricks、Spark、管理されたファイル転送、REST API、およびクラウドサービス全体でワークフローを調整します。依存関係の追跡、SLAの可視性、そしてそれら全体での自動回復を伴う単一のジョブフローで。
- クロスツール依存関係: 管理されたファイル転送 → AWS S3 → AWS Glue → Amazon EMR/Spark → Amazon Redshift → BIプラットフォーム
- データ認識トリガー: S3オブジェクト到着、ファイルパターンマッチ、REST APIイベント、AWS Glue完了、上流ジョブ完了、スケジュール実行
|
AWS S3 |
オブジェクト到着検出 · ファイルパターン検証 · バケットモニタリング · イベント駆動型ワークフローのトリガー · オブジェクトベースの依存関係管理 |
|
AWS Glue |
ETLジョブをトリガーする · ジョブの完了を監視する · 実行状況をキャプチャする · 下流依存関係を管理する · 回復を自動化する |
|
Amazon EMR |
Spark/Hadoopワークロードを起動する · クラスタージョブを監視する · バッチ処理を調整する · 下流分析をトリガーする |
|
Apache Airflow |
DAG実行をトリガーする · DAGステータスを監視する · クロスプラットフォーム依存関係を同期する · DAGの前後のアクティビティを調整する |
|
Databricks |
ノートブックとジョブを起動する · 実行を監視する · レイクハウスワークフローを調整する · 依存関係の処理を自動化する |
|
Amazon Redshift |
COPY操作をトリガーする · データウェアハウスのロードを調整する · 完了を監視する · 下流レポートを調整する |
|
管理されたファイル転送 / API |
安全なファイル配信 · REST APIの調整 · パートナー間のデータ交換 · 配信確認 · ワークフローの開始 |
airflow coexistence
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 を書き直したり、移行したりする必要はありません
ワークフローを監視する
単一の運用ビューからAWS S3ワークフローを監視する。
Amazon S3はストレージメトリクスとイベント通知を提供しますが、データがエンドツーエンドのワークフローを通じてどのように移動するかは表示しません。Control-Mは、ファイル到着から下流処理と配信まで、パイプラインの各段階に対する中央集権的な可視性を提供し、実用的な運用インサイトを提供します。
-
エンドツーエンドのワークフローステータス
-
S3オブジェクト到着の監視
-
上流および下流の依存関係
-
ジョブの実行時間と履歴
-
中央集権的な運用ダッシュボード
SLA保証
AWS S3データパイプラインを予定通りに保つ。
納期を守るには、単なるファイルのアップロード成功だけでは不十分です。Control-Mはワークフローの進捗を継続的に評価し、SLAリスクがビジネスの問題になる前に予測し、データパイプライン全体の遅延や障害に自動的に対応します。
-
SLA違反予測
-
自動化された障害回復
-
設定可能なリトライポリシー
-
依存関係を考慮した実行
-
プロアクティブな運用アラート
ドキュメント
複雑なワークフローを整理する
Control-Mがチームに複雑なプロセスをより高い可視性、調整、および制御でオーケストレーションする方法を学ぶ。
