ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Hadoop
あなたのHadoopワークフローは、Spark、Hive、またはMapReduceジョブが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。期待したデータセットはHDFSに到着しません。運用データベースからのSqoopインポートは遅れて終了します。Control-Mは、HDFSデータの到着、Sqoopの取り込み、Hadoopの実行、および下流の配信を調整します。
一般的なワークフローの問題
これがあなたの週に聞こえますか？
これらはエッジケースではありません。複数のツールを使ってHadoopジョブを実行しているチームの通常の運用条件です。Control-Mが各ケースをどのように処理するかをご覧ください。
HDFSデータ到着
あなたの午前2時のSparkジョブが開始されます。HDFS入力はまだありません。
Control-Mはファイル監視を使用してHDFSデータの到着を検出し、要求されたデータがリリースされるまで依存処理を待機します。Spark、Hive、またはMapReduceジョブは、ファイル条件が満たされるまでゲートされ、未完成の入力が下流に伝播するのを防ぎます。
取り込み遅延
あなたのSqoopインポートが遅れています。下流のHive処理はすでに待機しています。
Control-Mは同じワークフロー内でSqoopとHiveを追跡し、彼らの間に依存関係を適用します。Hive処理は、仮定されたcronウィンドウではなく、実際の上流の完了から開始され、手動チェックや脆弱なスケジュールオフセットを排除します。
SPARK失敗
あなたのSparkジョブが夜間に失敗します。すべての下流が停止する必要があります。
Control-Mは失敗したジョブ状態を検出し、依存処理が進むのを防ぎます。回復ロジックは、下流のジョブがリリースされる前に適用でき、失敗を含み、悪いまたは欠落した出力がパイプラインを通じて伝播するのを防ぎます。
OOZIE調整
あなたのOozieワークフローは長時間実行されます。下流の配信ウィンドウはますます縮小しています。
Control-MはOozieワークフローを抽出し、そのアクションをControl-Mスケジューリング環境に持ち込みます。オペレーションチームは、それらのジョブを周囲の依存関係やSLA要件と調整でき、Oozieワークフローを孤立して管理する必要がなくなります。
SLAリスク
Hadoop処理はまだ実行中です。あなたの午前6時の配信は危険にさらされています。
Control-MはHadoopジョブを企業のSLA管理や広範な生産ワークフローに接続します。チームは遅延したクラスター処理が配信期限にどのように影響するかを確認し、長時間実行されるジョブがビジネスSLAの失敗になる前に行動できます。
統合の事実
Control-M + Hadoop
|
workload.types |
Spark Python · Spark Scala/Java · Pig · Sqoop · Hive · DistCp · HDFSコマンド · MapReduce · Oozie |
|
trigger.type |
HDFSファイル到着 · 時間スケジュール · 上流ジョブ完了 · Control-Mイベント · ワークフロー依存関係 |
|
cross_tool.deps |
Sparkジョブ · Sqoopインポート/エクスポート · Hiveジョブ · Oozieワークフロー · データベースジョブ · ファイル転送 · 下流アプリケーション |
|
cloud.platforms |
Hadoopクラスター · Linuxエッジノード · Control-M SaaS · Control-Mセルフホステッド |
|
error_handling |
コマンド前の失敗処理 · コマンド後の失敗処理 · 依存関係ゲーティング · 復旧アクション · リソース制御 · SLA監視 |
|
throughput |
分散バッチ処理 · 大規模データセット · クラスター実行 · 分散コピー · Hadoopストリーミング |
|
observability |
中央集権的ジョブ監視 · YARN集約ログ · 実行出力 · 依存関係の可視性 · SLA追跡 · ジョブ履歴 |
エンドツーエンドオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-Mは、Hadoop、Spark、Hive、Sqoop、データベース、ファイル転送、クラウドサービス全体にわたるワークフローを単一のジョブフローで調整します。これにより、依存関係の追跡、SLAの可視性、およびすべての自動復旧が可能になります。
- クロスツール依存関係: Sqoop → Spark → Hive → 分析の引き渡し
- データ認識トリガー: HDFSファイル到着、上流完了、APIイベント、ジョブステータス
|
Hadoop |
分散処理 · 依存関係オーケストレーション · SLA調整 |
|
スパーク |
Python 実行 · Scala/Java 実行 · アプリケーション引数 & Spark-submit オプション |
|
Hive |
クエリ実行 · パラメータ · 依存関係管理 |
|
Sqoop |
コマンド実行 · インポート/エクスポート · ワークフローシーケンシング |
|
HDFS |
ファイル監視 · HDFS コマンド · データ依存関係 |
|
Oozie |
ワークフロー実行 · ワークフロー抽出 · アクション調整 |
|
ファイル転送 |
インバウンドデータ · アウトバウンドデリバリー · 完了依存関係 |
airflow共存
Control-MはあなたのAirflow DAGを置き換えません。上のレイヤーを実行します。
一般的な異議です: “私たちはすでにAirflowを使っています。” 問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。そこがパイプラインが実際に失敗する場所です。
AirflowはそのDAGを管理します。Control-Mはその周囲のすべてを管理します。
airflowは処理します
データパイプライン内のDAGレベルのオーケストレーション
- データパイプライン内のDAGレベルのタスクオーケストレーション
- Pythonオペレーター、センサー、タスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一のDAGコンテキスト内でのリトライを管理
control-mが追加します
あなたのDAGの周りの調整レイヤー
- DAGの周囲の調整レイヤー - 上流の条件（ファイルの到着、APIイベント、他のツールの完了）に基づいてAirflowをトリガー
- 各DAGのSLA貢献をフルエンドツーエンドのワークフロー全体で追跡し、単なるルーチンにとどまらない
- Airflowが開始される前に上流の依存関係が失敗した場合の失敗回復を管理
- 既存のDAGは書き換えたり移行する必要がない
パイプラインを監視する
データパイプライン全体にわたって Hadoop ジョブを監視します。
Hadoop 処理は、プロダクションデータパイプラインの一段階に過ぎません。Control-M は、Hadoop および周辺システム全体の集中ビューを提供し、チームが上流のデータ到着から処理、下流の配信までの実行を追跡できるようにします：
-
Hadoop ジョブ実行ステータス
-
ジョブの実行時間と履歴
-
上流および下流の依存関係
-
パイプラインの失敗可視性
-
SLA リスク指標
SLA アシュアランス
Hadoop 処理を配信 SLA に合わせて整合させる。
ネイティブジョブステータスは、Hadoop 処理が実行されたかどうかを示しますが、ビジネスパイプライン全体が時間通りに終了するかどうかは示しません。Control-M は、Hadoop ジョブをエンドツーエンドの SLA 管理に接続し、チームが配信リスクを特定し対処できるようにします：
-
エンドツーエンド SLA トラッキング
-
クリティカルパスジョブの可視性
-
遅延ジョブアラート
-
依存関係を考慮した下流制御
-
集中復旧アクション
ドキュメント
複雑なワークフローに秩序をもたらす
Control-M がチームがより高い可視性、調整、制御で複雑なプロセスをオーケストレーションする方法を学ぶ。
