Control-M + Apache Kafka via Confluent

あなたのKafkaデータフローは、メッセージがトピックに到達する前に始まり、上流で何かが壊れたときに失敗します。ファイルが届かなかった。プロデューサーのジョブが停止した。スキーマの更新が適用されなかった。Control-Mは全体のチェーンを調整します：取り込み、Kafkaの公開、ストリーム処理、下流の分析、そして配信。

あなたのようなパイプラインで見る統合情報を見る

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

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

これらはエッジケースではありません。複数のツールでKafkaストリーミングパイプラインを実行しているチームの通常の運営条件です。Control-Mがそれぞれをどのように処理するかは以下の通りです。

生産者の失敗

一晩の取り込みが遅れて終了しました。6 AMにKafkaトピックは空のままでした。

Control-Mは生産者の実行前に上流ジョブの完了を追跡します。取り込みがウィンドウを逃すと、Control-Mは依存ワークフローを遅らせ、利害関係者に警告し、不完全なデータの処理を下流の消費者から防ぎます。

ストリーム依存関係

Kafkaメッセージが到着しました。Spark処理は開始されませんでした。

Control-MはKafka、Spark、Databricks、および分析ワークロード間のクロスプラットフォーム依存関係を評価します。イベントの完了はカスタムスクリプト、ポーリングループ、または手動介入なしに下流の処理を自動的にトリガーします。

スキーマの変更

スキーマレジストリが更新されました。下流の消費者が予期せず失敗しました。

Control-MはKafkaトピックへの公開前に上流の依存関係チェックをシーケンスします。前提条件のジョブが正常に完了していない場合、依存するKafkaの公開ステップは保持され、不整合な状態でメッセージが消費者に届くのを防ぎます。

SLAリスク

ストリーミングのバックログが一晩で増加しました。ビジネスレポートが締切に間に合いませんでした。

Control-MはSLA目標に対してワークフロー実行を監視し、違反が発生する前に予測し、エスカレーションパスや回復アクションをトリガーして、報告および運用の締切が順調に進むようにします。

障害回復

1つの消費者グループが失敗しました。5つの下流プロセスが停止しました。

Control-Mは失敗したワークフローセグメントを隔離し、構成可能な再試行ポリシーを適用し、不必要なカスケード障害を防ぎます。回復アクションは影響を受けたプロセスのみを再開し、運用への影響とトラブルシューティングの手間を減らします。

統合情報