ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Tajo
あなたのTajoワークフローは分散SQLクエリが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。HDFSパーティションが不完全に到着します。Spark変換が処理ウィンドウの後に終了します。Control-Mは完全なチェーンをオーケストレーションします—HDFSデータの到着、Spark変換、Control-M for Hadoopを介したTajoクエリの実行、そして下流の配信まで。
一般的なワークフローの問題
今週のあなたの状況のように聞こえますか？
これは特異なケースではありません。 これらは、複数のツールでTajoクエリを実行しているチームの通常の運用条件です。 Control-Mがそれぞれをどのように処理するかを紹介します。
HDFS到着
あなたの02:00のTajoクエリが開始します。 HDFS入力はまだ不完全です。
Control-MのHDFSファイルウォッチャーは、Tajoジョブをリリースする前に必要なパスと最小ファイルサイズを待ちます。 不足または小さいデータは実行を制限し、不完全な入力に対してクエリの開始を防ぎます。
上流の遅延
あなたのSpark変換が遅れて実行されます。 Tajoはすでに下流で待っています。
Control-MはSparkとTajoを同じワークフロー内の依存ジョブとしてモデル化します。 Tajoクエリは、固定のcronウィンドウに依存するのではなく、上流の成功した完了を待ちます。 これにより、実際のデータの準備に合わせて実行が調整されます。
コマンド失敗
HDFSの準備コマンドがTajoクエリが開始される前に失敗します。
Control-MはTajoの実行前にHDFSのプレコマンドを実行し、準備コマンドが失敗した場合はジョブを失敗させることができます。 クエリは、損なわれた入力を処理する前に停止し、オペレーターには明確なジョブの失敗を通知して調査を促します。
クエリ失敗
本番のTajoクエリが夜間処理チェーンの途中で失敗します。
Control-Mはワークフロー全体内でジョブの結果をキャプチャし、依存する処理が進行するのを防ぎ、運用のために失敗を表示します。 回復は、別々のスケジュールを追跡するのではなく、同じワークフローコンテキストから調整できます。
SLAリスク
クエリは成功しますが、下流の納品は遅れがちです。
Control-MはTajoを孤立したクエリではなく、完全なサービスの一部として追跡します。 SLA管理は重要なジョブチェーンを監視し、最終的な納品期限を過ぎる前に遅延リスクを表示できます。
統合ファクト
Control-M + Tajo
|
workload.types |
Tajoオープンクエリ · Tajo入力ファイルジョブ · 分散SQLクエリ · HDFS分析 · バッチETL · アドホッククエリ実行 |
|
trigger.type |
HDFSファイルの到着 · HDFS最小サイズの閾値 · 時間スケジュール · 上流ジョブの完了 · Control-Mイベント · 自動化APIの送信 |
|
cross_tool.deps |
すべてControl-M for Hadoopを通じて提供されます：HDFSファイルウォッチャー · HDFSコマンド · Apache Spark · Apache Hive · Sqoop · Java MapReduce · Pig · Oozieワークフロー · ファイル配信 |
|
cloud.platforms |
オンプレミスHadoopクラスター（HDFS） · クラスターごとにControl-M/Agentが少なくとも1つ必要 · HadoopクラスターのControl-M SaaSオーケストレーション |
|
error_handling |
前コマンド失敗検出 · 後コマンド失敗処理 · 下流依存関係ゲート · ジョブ失敗アラート · SLA監視 · 管理された回復 |
|
throughput |
分散SQLワークロード · 大規模HDFSデータセット · バッチETL · アドホック分析 · 入力ファイル駆動のSQL実行 |
|
observability |
ジョブ実行ステータス · ジョブ出力 · 依存関係の可視化 · ワークフロー履歴 · SLA追跡 · 失敗アラート · エンドツーエンドのワークフロー監視 |
エンドツーエンドオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-MはTajo、HDFS、Spark、Hive、Sqoop、ファイル転送、およびHadoopサービス全体でワークフローをオーケストレーションします—依存関係の追跡、SLAの可視化、およびそれらすべてにわたる自動回復を伴う単一のジョブフローで。
- クロスツール依存関係：HDFS到着 → Spark変換 → Tajoクエリ → 分析の受け渡し
- データ認識トリガー：HDFSファイルの到着、最小ファイルサイズ、上流ジョブの完了、スケジュールされた処理
|
Tajo（Hadoopジョブタイプ） |
オープンクエリ実行 · 入力ファイル実行 · 前/後HDFSコマンド · |
|
ワークフローディペンデンシー HDFS |
ファイル到着監視 · 最小サイズ基準 · HDFSコマンド · データ準備ゲーティング |
|
Apache Spark |
Python実行 · Java/Scalaアプリケーション · アップストリーム変換オーケストレーション |
|
Apache Hive |
Hiveジョブ実行 · スクリプトパラメータ · Hadoopワークフローディペンデンシー |
|
Sqoop |
コマンド実行 · データ移動オーケストレーション · 依存処理 |
|
Oozie |
ワークフロー実行 · ジョブプロパティ · 調整されたHadoop処理 |
|
Control-M MFT |
管理されたファイル移動 · デリバリーディペンデンシー · ダウンストリームワークフローのトリガー |
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は再構築または移行する必要がない
パイプラインを監視
完全なデータパイプライン内でのTajoの実行を見る
Tajoは、その分散クエリ環境内で何が起こっているかを示します; それはそのクエリを取り巻くすべての外部依存関係の運用ビューを提供しません。Control-MはTajoの実行をより広いプロダクションワークフローに接続し、データチームに可視性を提供します:
-
Tajoジョブ実行ステータス
-
アップストリームおよびダウンストリームの依存関係
-
ジョブ出力と失敗
-
エンドツーエンドワークフロー履歴
-
クロスプラットフォーム処理ステータス
SLA保証
Tajo依存データサービスをスケジュール通りに保つ
成功したTajoクエリは、アップストリーム処理が遅れて開始されるか、ダウンストリーム作業が停止する場合に、配信の遅れに寄与する可能性があります。Control-Mは完全な依存関係チェーンを通じてサービスを管理し、チームが配信に影響を与える前にスケジュールリスクを特定できるようにします:
-
エンドツーエンドSLAトラッキング
-
クリティカルパス依存関係の可視性
-
予測遅延検出
-
自動失敗アラート
-
調整されたダウンストリーム回復
複雑なワークフローに秩序をもたらす
Control-Mがチームにどのように視認性、調整、制御の向上を持たせて複雑なプロセスをオーケストレーションするかを学ぶ。