Control-M + GCP Dataplex

あなたのGCP Dataplexワークフローは、データ品質スキャンが実行される前に始まります—上流で何かが壊れると失敗することがあります。Cloud Storageデータセットが不完全に到着する。BigQuery変換が長時間実行される。Control-Mは完全なチェーンを調整します：Cloud Storageの取り込み、BigQueryの変換、Dataplexの実行、および下流の配信。

あなたのようなパイプラインで見る統合の事実を表示

一般的なワークフローの問題

これがあなたの週のように聞こえますか？

これらはエッジケースではありません。それらは複数のツールでGCP Dataplexジョブを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかは次のとおりです。

データ品質

あなたのBigQueryロードが完了しました。Dataplexの品質スキャンは開始されませんでした。

Control-MはBigQueryジョブとDataplexスキャンを依存関係のあるワークフロー手順としてモデル化し、上流の条件が満たされてからのみ事前定義されたスキャンを開始します。見逃したハンドオフは、静かなデータ品質のギャップではなく、目に見えるワークフローステートになります。

失敗したスキャン

午前2時のデータ品質スキャンが失敗しました。下流のレポートが待機しています。

Control-MはDataplexジョブのステータス、結果、出力を監視し、定義された失敗処理を適用し、失敗した実行で依存する作業が進むのを防ぎます。オペレーションは文脈内で失敗したステップを確認し、チェーンを再構築することなくワークフローを回復できます。

SPARKの遅延

あなたのカスタムSparkタスクが長く実行されました。すべての下流依存関係がシフトしました。

Control-Mはエンドツーエンドワークフロー内でDataplexタスクを監視し、下流の納品 commitmentsへの貢献を追跡します。SLA監視は遅延の影響を早期に露呈させるので、チームは遅れたSparkタスクが遅れたビジネス結果になる前に介入できます。

プロファイルハンドオフ

プロファイルが完了しました。あなたの次のBigQueryプロセスはまだ待機しています。

Control-Mは事前定義されたデータプロファイリングスキャンの完了を追跡し、次のワークフロー依存関係を自動的に評価します。必要な状態に達すると、下流処理は別のポーリングスクリプト、cronスケジュール、または手動ハンドオフなしで進みます。

ステータスポーリング

Dataplexはまだ実行中です。あなたのスケジューラはすでに失敗を仮定しています。

Control-MはGCP Dataplexジョブのステータスポーリング頻度と失敗許容を構成可能です。一時的なステータスチェックの問題は、ジョブが終了する前に処理されることができ、周囲の生産ワークフローを集中管理の下に保ちながら、偽の失敗を減らします。

統合の事実