ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Amazon QuickSight
あなたのAmazon QuickSightワークフローは、SPICEデータセットの更新が実行される前に始まります — そして、上流で何かが壊れると失敗する可能性があります。Amazon S3に期待されるデータが不完全に到着します。AWS Glueの変換が長引きます。Control-Mは、ソースデータの到着、上流変換、QuickSightデータセットの更新、そして下流の分析配信を調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。それは、複数のツールを通じてAmazon QuickSightデータセットのリフレッシュを実行しているチームのための通常の運用条件です。Control-Mが各ケースをどう処理するかは次のとおりです。
古いデータ
あなたの8:00 AMダッシュボードが開かれました。昨日のデータがまだそこにあります。
Control-MはQuickSightのリフレッシュを成功した上流処理に依存させ、リフレッシュの状態を監視します。ビジネスユーザーは、期待される上流のワークフローが完了した後にダッシュボードがリフレッシュされるのを取得し、切り離されたスケジュールに依存して古い情報を発見することはありません。
上流の遅延
AWS Glueは長引きました。QuickSightは新しいデータが到着する前にリフレッシュされました。
Control-Mは上流の処理とQuickSightデータセットのリフレッシュ間の依存関係を調整します。リフレッシュは、必要なジョブが成功裏に完了した後にのみ開始され、遅れた変換が不完全なデータに基づいて明らかに現在のダッシュボードに変わることを防ぎます。
リフレッシュ失敗
SPICEの取り込みが夜間に失敗しました。ビジネスユーザーは古いダッシュボードを開きました。
Control-MはQuickSightジョブのステータス、結果、および出力を監視し、その実行状態をより広いワークフロー内で使用します。チームは、失敗したリフレッシュを文脈内で特定し、成功した完了に依存する下流プロセスが進むのを防ぐことができます。
SLAリスク
エグゼクティブダッシュボードは7:00 AMに期限があります。リフレッシュが遅れています。
Control-MはQuickSightジョブをビジネスワークフロー全体のSLAに接続します。チームは、期限リスクを文脈内で特定し、遅延したデータセットのリフレッシュが見逃された分析の配信コミットメントになる前に介入できます。
リフレッシュコントロール
新しい行のみを読み込む必要があるときに完全なリフレッシュが実行されました。
Control-MはチームがQuickSightの完全または増分データセットのリフレッシュを実行し、それらをより広いワークフローと調整できるようにします。サポートされている増分SPICEデータセットについて、チームは上流処理とリフレッシュの実行を調整でき、孤立したスケジュールとして管理する必要はありません。
Control-M + Amazon QuickSight
Control-M + Amazon QuickSight
|
プラットフォームとOSのカバレッジ |
Amazon QuickSight · AWSリージョン設定 · AWSアカウントターゲット設定 · Control-M · Control-M SaaS |
|
サポートされるジョブタイプ |
QuickSightデータセットの更新 · フルリフレッシュ · インクリメンタルリフレッシュ · SPICEの取り込み · データセットIDの選択 · 自動化API: Job: AWS QuickSight |
|
SLA監視とアラート |
SLAジョブ添付 · 高度なスケジューリング基準 · クロスワークフロー依存関係 · ジョブステータスの監視 · ビジネスの締切管理 |
|
監査証跡とアクセス制御 |
安全な接続プロファイル · AWS IAMロール認証 · AWSアクセスキーとシークレット · 外部ボールト統合 · AWSアカウントとリージョン設定 |
エンドツーエンドオーケストレーション
1つの本番ワークフロー。スタック内のすべてのツール。
Control-Mは、Amazon QuickSight、Amazon S3、AWS Glue、Amazon Redshift、Amazon Athena、ファイル転送、およびクラウドサービス全体でワークフローを調整します — 依存関係の追跡、SLAの可視性、すべての自動回復を備えた単一のジョブフローで。
- クロスツール依存関係: AWS Glue → Amazon Redshift → Amazon QuickSightの更新 → 分析の引き渡し
- データ意識のトリガー: S3ファイルの到着、AWS Glueの完了、Redshiftワークロードの完了、上流ジョブの完了
|
Amazon QuickSight |
フルデータセットの更新 · インクリメンタルデータセットの更新 · 取り込み状況の監視 · ワークフロー依存関係の調整 |
|
Amazon S3 |
ファイル到着の検出 · 上流データ依存関係 · ワークフローのトリガー |
|
AWS Glue |
ジョブオーケストレーション · 完了依存関係 · 下流の引き渡し |
|
Amazon Redshift |
ワークロード調整 · 依存関係管理 · 分析の引き渡し |
|
Amazon Athena |
クエリワークフロー調整 · 上流依存 · 下流引き渡し |
|
Managed File Transfer |
安全なファイル移動 · 到着監視 · ワークフロー統合 |
|
Control-M |
高度なスケジューリング · 複雑な依存関係 · SLA管理 · 中央集中的な監視 |
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は再作成したり、移行したりする必要がありません
モニター分析
QuickSightデータが実際に準備されているときがわかります。
QuickSightはデータセットの取り込みを可視化しますが、ビジネス成果はリフレッシュの前後で実行されるプロセスに依存します。Control-Mはワークフローのレベルで可視性を追加し、オーナーが完全な分析配信が順調かどうかを確認できるようにします:
-
データセットリフレッシュステータス
-
上流および下流の依存関係
-
ジョブ結果と出力
-
エンドツーエンドのワークフロー可視性
-
ビジネスSLAステータス
SLA保証
ビジネスダッシュボードを意思決定の締切に合わせる。
技術的に成功したリフレッシュでも、サポートするビジネスプロセスには遅すぎる場合があります。Control-MはQuickSightの実行をエンドツーエンドのワークフローSLAに接続し、チームが文脈で遅延を確認し、ビジネスユーザーが実際に依存している納期を管理できるようにします:
-
ビジネス期限追跡
-
クロスプラットフォーム依存関係の可視化
-
SLAリスクの特定
-
中央集中的なワークフロー監視
-
調整された失敗の回復
複雑なワークフローに秩序をもたらす
Control-Mがチームがより高い可視性、調整、制御で複雑なプロセスをオーケストレーションする方法を学ぶ。
