ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + GCP Dataprep
あなたのGCP Dataprepワークフローは、フローが実行される前に始まります - 上流で何かが壊れると失敗する可能性があります。BigQueryステージングテーブルが準備されていません。Cloud Storageの配信が処理ウィンドウ後に到着します。Control-Mは、Cloud Storageデータの到着、BigQueryステージング、GCP Dataprepフローの実行、および下流の分析配信を調整します。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。これらは、複数のツールでGCP Dataprepフローを実行しているチームの通常の運用条件です。Control-Mが各ケースをどのように処理するかを見てみましょう。
上流データ
クラウドストレージの配信が遅れています。あなたのDataprepフローは02:00に開始します。
Control-Mは、Dataprepフローを孤立した時計の時間ではなく、上流の配信に依存させます。フローは、その前提条件が正常に完了した後にのみ開始され、早すぎる処理を防ぎ、手動で再起動されたデータ準備の実行を回避します。
スキーマの変化
ソーススキーマが一晩で変更されました。あなたの準備フローは盲目的に続行すべきではありません。
Control-Mは、実行時にパラメータリストまたはパラメータファイルの定義を使用してDataprepフローにランタイムパラメータを渡すことができます。実行が失敗した場合、Control-Mはジョブの状態をキャプチャし、無効な上流結果で依存処理が続行されるのを防ぎます。
重複実行
回復がフローを再び開始します。最初のリクエストはまだ実行中かもしれません。
Control-Mは、GCP Dataprep実行のための冪等性トークンをサポートし、ジョブが一度だけ実行されることを保証するユニークな識別子を提供します。回復は、同じフローに対して重複処理が誤って開始されることなく進行できます。
ステータス失敗
Dataprepの応答が停止しました。下流のBigQueryジョブはまだ待機中です。
Control-Mは、設定可能な頻度でDataprepジョブのステータスをポーリングし、ジョブが「Not OK」で終了する前に定義された失敗許容を適用します。下流の依存関係は不確実な実行状態で進行するのではなく、制御されたままです。
SLAリスク
フローが遅れて完了しました。あなたの朝の分析配信は今や危険にさらされています。
Control-Mは、Dataprepの実行をその広範なワークフローに接続し、チームがそれにSLAジョブを添付できるようにします。オペレーターは、孤立した準備タスクをトラブルシューティングするのではなく、エンドツーエンドサービスの一部として実行を評価できます。
Control-M + GCP Dataprep
Control-M + GCP Dataprep
|
workload.types |
GCP Dataprepフロー · データ準備ジョブ · フローパラメータのオーバーライド · 実行時パラメータのオーバーライド（パラメータリスト / パラメータファイル）· 実行時フローパラメータのオーバーライド |
|
trigger.type |
時間スケジュール · 上流ジョブの完了 · ファイル到着依存性 · API駆動の順序付け · 高度なスケジューリング基準 · Control-M条件 |
|
cross_tool.deps |
GCP BigQueryジョブ · GCP Dataflowジョブ · Cloud Storage配信 · Apache Airflow DAGs · ファイル転送 · 下流の分析ジョブ |
|
cloud.platforms |
Google Cloud Platform · Control-M SaaS · Control-Mセルフホステッド · ハイブリッド環境 |
|
error_handling |
ステータスポーリングの頻度 · 失敗耐性 · 冪等性トークン · エラー時の停止パラメータ · 下流依存性の制御 · SLAモニタリング |
|
throughput |
エージェントあたり50の同時Dataprepジョブ · 設定可能なステータスポーリング · 設定可能なステータスポーリングの頻度· フローごとの実行制御 |
|
observability |
ジョブステータスの監視 · ジョブ結果 · ジョブ出力 · モニタリングドメイン · SLAジョブ添付 · エンドツーエンド依存性の可視性 |
エンドツーエンドオーケストレーション
1つの本番ワークフロー。スタック内のすべてのツール。
Control-Mは、GCP Dataprep、BigQuery、Cloud Storage、Dataflow、Airflow、および分析サービス全体でワークフローを調整し、単一のジョブフローで依存関係の追跡、SLAの可視性、および自動回復を実現します。
- ツール間の依存関係: Cloud Storage → BigQuery → GCP Dataprep → 分析の引き渡し
- データ対応トリガー: ファイル到着、上流ジョブの完了、Dataprepフローの完了、クエリ結果
|
GCP Dataprep |
フロー実行 · 実行時パラメータ · ステータス監視 · 冪等性制御 |
|
GCP BigQuery |
クエリ · ロード · 抽出 · ストアドプロシージャの実行 |
|
Google Cloud Storage |
管理されたファイル配信 · 上流データ依存 · 下流引き渡し |
|
GCP Dataflow |
クラシックテンプレートの実行 · フレックステンプレートの実行 · ステータス監視 |
|
Apache Airflow |
DAG調整 · 上流依存管理 · 下流ワークフロー引き渡し |
|
分析サービス |
完了依存 · スケジュールされた配信 · SLA対応引き渡し |
エアフローの共存
Control-MはあなたのエアフローDAGを置き換えるものではありません。それはその上のレイヤーを実行します。
一般的な異議があります: 「私たちはすでにエアフローを使用しています。」問題はエアフローが何をするかではなく、エアフローが実行される前後に何が起こるかです。それがパイプラインが実際に失敗するところです。
エアフローはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
エアフローの管理
データパイプライン内のDAGレベルのオーケストレーション
- データパイプライン内のDAGレベルのタスクオーケストレーション
- Pythonオペレーター、センサー、およびタスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一のDAGコンテキスト内での再試行を管理
Control-Mを追加します
DAGの周囲の調整レイヤー
- DAGの周囲の調整レイヤー — 上流の条件（ファイルの到着、APIイベント、他のツールの完了）に基づいてエアフローをトリガーします。
- 自分のルーチンだけでなく、エンドツーエンドのワークフロー全体にわたる各DAGのSLA貢献を追跡します。
- エアフローが開始する前に、上流の依存関係が失敗した場合の失敗回復を管理します。
- 既存のDAGを再記述したり移行したりする必要はありません。
分析を監視する
GCP Dataprepの実行を広範なパイプラインで監視する
Dataprepの実行はプロダクションデータパイプラインの1つのステージに過ぎません。Control-Mはそのステータス、結果、出力を周囲のジョブと同じ運用ビューに統合し、データチームが依存関係を理解し、完全なワークフローをトラブルシュートできるようにします：
-
Dataprepジョブの実行ステータス
-
ジョブの結果と出力
-
上流と下流の依存関係
-
クロスプラットフォームのワークフロー可視性
SLA保証
Dataprepフローを配信SLAに合わせて保つ
成功したDataprepの実行でも、それがサポートするビジネス結果には遅すぎる可能性があります。Control-Mは準備ジョブをエンドツーエンドのサービスコミットメントに接続し、チームに下流配信を保護するために必要なスケジューリング、依存関係、SLA制御を提供します：
-
SLAジョブの添付
-
高度なスケジューリング基準
-
複雑な依存関係管理
-
エンドツーエンドサービスの可視性
ドキュメント
複雑なワークフローに秩序をもたらす
Control-Mがチームに可視性、調整、および制御をもたらし、複雑なプロセスをオーケストレーションする方法を学ぶ。
