ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Apache NiFi
あなたのApache NiFiワークフローは、プロセッサが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。ListSFTPによって期待されるSFTP配信は遅れて到着します。Kafka取り込みジョブはその処理ウィンドウを逃します。Control-Mは、ファイルの到着、上流の変換、Apache NiFiの実行、下流の配信という完全な連鎖を編成します。
一般的なワークフローの問題
これはあなたの週のように聞こえますか？
これらはエッジケースではありません。複数のツールでApache NiFiパイプラインを実行するチームにとっては通常の運用条件です。Control-Mがそれぞれをどのように処理するかをご覧ください。
遅延ファイル到着
午前2時のSFTPファイルが遅れています。NiFiは待機しています。
Control-Mは必要なNiFiプロセッサを開始する前にファイル依存関係を調整し、下流処理が早まらないようにします。パイプラインは上流条件が満たされてからのみ進行し、失敗した実行と手動介入を減らします。
プロセッサの失敗
NiFiプロセッサが失敗しました。下流のジョブは安全に続行できません。
Control-MはNiFiジョブのステータスを監視し、プロセッサの実行周囲でワークフロー依存関係を適用します。失敗した作業は依存するジョブの進行を妨げる可能性があり、Control-Mは周囲のワークフロー内で失敗を集中化し、迅速な回復を実現します。
ツール間依存関係
NiFiが取り込みを完了しました。あなたの下流データジョブはまだ調整が必要です。
Control-MはApache NiFiジョブを他のControl-Mジョブと1つのスケジューリング環境で統合し、依存関係を評価し、必要なNiFi実行が完了したときに下流処理を解放します — プラットフォーム間の切り離されたスケジュールと手動ハンドオフを排除します。
プロセッサ制御
プロセッサは次の生産データ実行の前に更新が必要です。
Control-Mは定義されたApache NiFiジョブを通じてNiFiプロセッサを開始、停止、無効化、または更新できます。チームはプロセッサの実行を孤立した運用タスクとして管理するのではなく、広範な生産ワークフローと調整します。
SLAリスク
NiFiは実行中ですが、ビジネス配信ウィンドウが遅れています。
Control-MはApache NiFiジョブにSLA管理を付加し、広範なワークフロー内での貢献を追跡します。オペレーションチームはNiFi実行を超えたタイミングと依存関係を可視化でき、下流配信が危険にさらされる前に行動するのに役立ちます。
Control-M + Apache NiFi
Control-M + Apache NiFi
|
workload.types |
プロセッサ実行 · プロセッサ起動操作 · プロセッサ停止操作 · プロセッサ無効化操作 · プロセッサ更新 · リアルタイムデータフロー · バッチデータパイプライン |
|
trigger.type |
時間スケジュール · 上流ジョブの完了 · ファイル到着 · Control-M依存条件 · 高度なスケジューリング基準 |
|
cross_tool.deps |
Apache Airflow DAG · Apache Kafka取り込み · Amazon S3データフロー · SFTP転送 · データベースロード · 下流分析ジョブ |
|
cloud.platforms |
AWS · Microsoft Azure · Google Cloud Platform · オンプレミス · ハイブリッド環境 |
|
error_handling |
設定可能な障害耐性 · ステータスポーリング · 下流依存関係の制御 · Control-Mアラート · リソース制御 · ワークフロー復旧 |
|
throughput |
リアルタイムデータフロー · バッチパイプライン · 設定可能なステータスポーリング · クロスプラットフォームジョブ調整 |
|
observability |
NiFiジョブステータス · ジョブ結果 · ジョブ出力 · SLAトラッキング · エンドツーエンドの依存関係の可視性 · Control-M監視 |
エンドツーエンドのオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、Apache NiFi、Kafka、SFTP、Amazon S3、Airflow、Snowflake、およびクラウドサービス間でワークフローを編成します—依存関係の追跡、SLAの可視性、および自動復旧を伴って。
- クロスツール依存関係: SFTP → Apache NiFiプロセッサ → Snowflakeロード → 分析ハンドオフ
- データ対応トリガー: ファイル到着、上流ジョブの完了、スケジュール、APIイベント
|
Apache NiFi |
プロセッサを実行 · プロセッサを停止 · プロセッサを更新 · プロセッサを1回実行 · ステータスを監視 |
|
Apache Kafka |
依存関係の調整 · 下流処理の順序 |
|
SFTP |
ファイル到着依存関係 · 管理された転送調整 |
|
Amazon S3 |
オブジェクトベースのデータパイプラインの調整 · 下流依存関係 |
|
Apache Airflow |
DAGをトリガー · DAG依存関係の調整 · 実行の監視 |
|
Snowflake |
データロードの調整 · 下流処理の順序 |
airflow共存
Control-MはあなたのAirflow DAGを置き換えません。上層レイヤーを実行します。
一般的な異議は「私たちはすでにAirflowを使用しています。」です。問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。そこがパイプラインが実際に失敗するところです。
AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
AIRFLOW HANDLES
DAGレベルのオーケストレーションデータパイプライン内
- DAGレベルのタスクオーケストレーションデータパイプライン内
- Pythonオペレーター、センサー、およびタスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一のDAGコンテキスト内でのリトライを管理
control-m adds
DAG周囲の調整レイヤー
- DAG周囲の調整レイヤー — 上流条件（ファイル到着、APIイベント、他のツールの完了）に基づいてAirflowをトリガー
- 各DAGのSLA貢献をフルエンドツーエンドワークフロー全体で追跡し、自身のルーチンだけではない
- 上流依存関係がAirflowが開始する前に失敗した場合の障害回復を管理
- 既存のDAGは書き換えたり移行したりする必要はない
パイプラインを監視する
全パイプラインでApache NiFiの実行を監視します。
NiFiは詳細なフローとプロセッサのステータスを公開しますが、プロダクションの依存関係はその境界を超えることがよくあります。Control-MはNiFiジョブの集中監視を提供し、周囲のエンタープライズワークフローと共に、データチームに次のものを提供します:
-
NiFiジョブ実行ステータス
-
ジョブ結果と出力
-
クロスプラットフォームワークフローステータス
-
SLAの可視性
SLA保証
NiFiパイプラインを配信の約束に沿わせておく。
健全なNiFiプロセッサは、完全なデータ製品が時間通りに到着することを保証しません。Control-MはNiFiの実行をエンドツーエンドのスケジューリングとSLA管理に接続し、チームが次のものを通じて全ての配信経路を管理するのを支援します:
-
エンドツーエンドSLA追跡
-
高度なスケジューリング基準
-
クロスツール依存関係管理
-
リソースとロックの制御
-
集中化されたワークフロー監視
ドキュメント
複雑なワークフローに秩序をもたらす
Control-Mがチームにどのように複雑なプロセスを視認性、調整、制御の向上をもってオーケストレートさせるかを学ぶ。
