Control-M + Databricks

あなたのデータパイプラインは、Databricksが実行されるずっと前から始まります。上流で何かが壊れると失敗する可能性があります。ファイルが遅れて到着します。依存関係がエラーで終了します。Control-Mは、すべてのワークフローを調整します：前提条件の検証、Databricksのジョブとワークフローのトリガー、クロスプラットフォームの依存関係の調整、障害からの回復、そして下流プロセスが時間通りに実行されることを保証します。

あなたのようなパイプラインで見る統合の事実を表示

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

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

これらはエッジケースではありません。複数のツールでDatabricksジョブを実行しているチームのための通常の運用条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。

上流の遅延

あなたのDatabricksジョブはスケジュールされています。ソースデータはまだ準備ができていません。

スケジュールされたジョブは、上流の取り込み、ファイル転送、またはETLプロセスが完了する前に開始され、失敗したノートブックや不完全なデータセットにつながります。Control-Mは確認された上流の完了を待機し、依存関係を評価し、データが準備できたときにのみDatabricksを起動します。

失敗した依存関係

Sparkはエラーで終了しました。下流の分析はそれでも実行され続けました。

失敗したSparkプロセスや上流のワークフローは、不完全または不正確な下流処理を引き起こす可能性があります。Control-Mは終了ステータスを検出し、失敗の連鎖を防ぎ、構成可能な回復を自動化し、成功した修正の後にのみ依存ワークフローを再開します。

クロスプラットフォームフロー

1つのワークフローがDatabricks、dbt、API、クラウドストレージ、およびSQLにまたがります。

生産パイプラインは、単一のプラットフォーム内に存在することはほとんどありません。Control-Mは、単一のワークフローで中央集権的な可視性と制御を持って、Databricks、クラウドストレージ、データ統合ツール、データベース、API、および分析プラットフォームの間の依存関係をオーケストレーションします。

SLAプレッシャー

朝のダッシュボードの締切が近づいています。ジョブはまだ実行中です。

上流の遅延が報告の締切を脅かすとき、チームはジョブのステータス以上のものを必要とします。Control-MはSLAリスクを予測し、クリティカルパスの遅延を特定し、違反が発生する前にオペレーターに警告し、ビジネスのコミットメントを順調に保つために回復アクションを優先します。

失敗の回復

ノートブックが夜間に失敗しました。誰もビジネス時間まで気づきませんでした。

手動回復は貴重な時間を浪費し、下流の消費者を遅延させます。Control-Mは失敗したDatabricksの実行を自動的に検出し、構成可能な再試行ポリシーを適用し、通知または修正ワークフローをトリガーし、パイプライン全体を再実行するのではなく、適切なポイントから処理を再起動します。

統合の事実