ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Azure Databricks
あなたのAzure Databricksワークフローは、ジョブが実行される前に始まります — 上流の何かが壊れると失敗する可能性があります。ファイルは、ジョブが読み取るAzure Data Lake Storageコンテナに到着しません。Azure Data Factoryパイプラインがそれを供給するのに時間がかかり、ウィンドウを逃しました。Control-Mは、データ取り込み、上流の変換、Databricksの実行、下流のデリバリーという完全なチェーンをオーケストレーションします。
一般的なワークフローの問題
これがあなたの週のように聞こえますか？
これらはエッジケースではありません。これは、複数のツールでAzure Databricksジョブを実行しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するか見てみましょう。
UPSTREAM DEPENDENCIES
あなたのDatabricksジョブはスケジュールされています。到着するはずのファイルはまだ届いていません。
Azure Databricksは、ストレージに到達しなかったデータを処理できません。Control-Mは、ノートブックやジョブを起動する前に、検証されたファイル到着または上流の完了イベントを待機し、失敗した実行、不必要なクラスター起動、下流の遅延を防ぎます。
PIPELINE RECOVERY
ノートブックは午前2時14分に失敗しました。データパイプライン全体が停止しました。
Control-Mはノートブックの終了ステータスを検出し、構成可能な再試行ポリシーを適用し、失敗を下流のワークフローから隔離し、パイプライン全体を最初から再起動するのではなく、適切なポイントから処理を再開します。回復は自動化され、一貫性があり、完全に監査可能です。
CROSS-PLATFORM ORCHESTRATION
Azure Data Factoryが完了しました。あなたのDatabricksワークロードは開始されませんでした。
Control-MはAzure Data Factory、Azure Storage、API、データベース、Azure Databricks全体の完了を追跡します。すべての依存条件が満たされると、ポーリングスクリプト、手動介入、または壊れやすいスケジューリングロジックなしで自動的に次のワークロードを起動します。
SLA VISIBILITY
あなたの朝のダッシュボードは遅れています。どの依存関係が滑ったのか誰も知りません。
Control-Mは、Azure Databricksだけでなく、完全なワークフロー全体のエンドツーエンドの可視性を提供します。SLAリスクを予測し、遅延を引き起こしている上流のジョブを特定し、配信ウィンドウの見逃しが報告や下流の消費者に影響を与える前にオペレーターに警告します。
HYBRID DATA FLOWS
クラウド処理が終了しました。オンプレミスのバッチは結果を受け取っていませんでした。
現代のデータパイプラインは、Azureサービス、オンプレミスシステム、データベース、ファイル転送、分析プラットフォームにまたがります。Control-Mは、環境間のすべての引き渡しをオーケストレーションし、依存関係を検証し、単一の本番ワークフローを通じてデータの移動を調整します。
統合情報
Control-M + Azure Databricks
|
workload.types |
Databricksジョブ · ノートブック · Delta Live Tables · Sparkバッチ処理 · Delta Live Tablesパイプライン（ジョブ経由） · MLモデルのトレーニング |
|
trigger.type |
ファイル到着（Azure Data Lake Storage Gen2 · Azure Blob Storage · SFTP） · Azure Event Gridイベント · REST API/ウェブフック · 時間スケジュール · 上流ジョブの完了 · パイプラインの終了コード |
|
cross_tool.deps |
Azure Data Factoryパイプラインの完了 · Azure Synapse Analytics · Azure Data Lake Storage Gen2 · Apache Airflow DAG · dbt Cloud実行 · Azure Functions · REST API呼び出し |
|
cloud.platforms |
Microsoft Azure · Azure Databricks · Azure Data Lake Storage Gen2 · Azure Blob Storage · Azure SQL Database · Azure Synapse Analytics · Control-M SaaS + オンプレミス |
|
error_handling |
設定可能な再試行回数 · 再試行間隔 · ノートブックの終了状態検出 · 下流のカスケード防止 · 上流の失敗による自動ジョブ保持 · SLAの事前違反アラート · PagerDuty · Slack |
|
throughput |
高ボリュームのSparkバッチ処理 · 分散コンピュート · 構造化ストリーミング · Delta Lakeワークロード · 並列ノートブック実行 · スケーラブルなクラスターオーケストレーション |
|
observability |
ジョブレベルの監査ログ · ワークフロー依存関係の系譜 · SLAトラッキングと違反予測 · 実行履歴 · Datadog/Splunk統合 · SIEM互換のイベントストリーム · 中央集権的な運用ダッシュボード |
エンドツーエンドオーケストレーション
1つの本番ワークフロー。スタック内のすべてのツール。
Control-Mは、Azure Databricks、Azure Data Factory、Azure Data Lake Storage、Azure Blob Storage、dbt Cloud、Apache Airflow、API、ファイル転送、そしてクラウドサービスを単一のジョブフローでオーケストレーションします — すべての依存関係の追跡、SLAの可視性、そして自動回復を備えて。
- クロスツール依存関係: Azure Data Factoryパイプライン → Azure Databricksジョブ → Delta Live Tables → SQL Warehouse → Power BIの更新
- データ認識トリガー: ファイル到着、Azure Event Gridイベント、REST APIイベント、上流ジョブの完了、ノートブックの終了状態
|
Azure Databricks |
ジョブオーケストレーション · ノートブック実行 · ワークフローのスケジューリング · ジョブステータスのモニタリング · 自動回復 |
|
Azure Data Factory |
パイプライン完了トリガー · 依存関係追跡 · クロスプラットフォームオーケストレーション · 障害伝播制御 |
|
Azure Data Lake Storage Gen2 |
ファイル到着検知 · データ利用可能性検証 · イベント駆動型ワークフロー開始 · データセット準備チェック |
|
dbt Cloud |
実行完了検知 · 変換依存関係管理 · 自動下流実行 |
|
Apache Airflow |
DAGトリガー · DAGステータス監視 · クロスワークフローオーケストレーション · エンドツーエンドSLA調整 |
|
Power BI |
データセットリフレッシュトリガー · レポート公開シーケンシング · 分析配信自動化 |
|
REST APIおよびエンタープライズアプリケーション |
API呼び出し · ステータスポーリング · イベント駆動型トリガー · エンタープライズワークフロー統合 |
airflow coexistence
Control-MはあなたのAirflow DAGを置き換えることはありません。それはその上のレイヤーを実行します。
一般的な異議があります: 「私たちはすでにAirflowを使っています。」問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。パイプラインが実際に失敗するのはその部分です。
AirflowはそのDAGを管理します。Control-Mはそれを取り巻くすべてを管理します。
AIRFLOW HANDLES
データパイプライン内のDAGレベルのオーケストレーション
- DAGレベルのタスクオーケストレーションをデータパイプライン内で
- Pythonオペレーター、センサー、およびタスク依存関係
- パイプライン内で実行されるジョブの実行グラフィック
- 単一のDAGコンテキスト内での再試行を管理
CONTROL-M ADDS
あなたのDAGの周りの調整層
- DAGの周りの調整層 — 上流条件に基づいてAirflowをトリガーします: ファイル到着、APIイベント、他のツールの完了
- 各DAGのSLA貢献をフルエンドツーエンドワークフロー全体で追跡します。自分のルーチンだけではありません
- Airflowが開始する前に、上流の依存関係が失敗した場合の障害回復を管理します
- 既存のDAGは書き直したり移行したりする必要はありません
ワークフローを監視する
Azure Databricksジョブをデータパイプライン全体で監視します。
Azure Databricksは、個々のジョブとワークフローの可視性を提供しますが、本番パイプラインはストレージ、取り込み、変換、および下流分析にまたがることがよくあります。Control-Mは、単一のインターフェースから完全なワークフロー全体にわたって集中監視、依存関係追跡、および運用可視性を提供します:
-
エンドツーエンドのワークフロー可視性
-
ノートブック実行状況
-
ランタイム履歴とトレンド
-
上流および下流依存関係
-
SLAリスク予測
SLA保証
パイプラインを再構築することなくAzure Databricksワークフローを回復します。
ネイティブジョブの再試行は、個々の実行失敗を解決しますが、依存するシステム全体の回復を調整しません。Control-Mは再試行を自動化し、クロスプラットフォーム依存関係を管理し、下流の失敗を防止し、適切な回復ポイントからワークフローを再開します:
-
設定可能な再試行ポリシー
-
依存関係を考慮した回復
-
下流カスケード防止
-
自動例外処理
-
ポリシーベースの通知
複雑なワークフローを整理する
Control-Mがチームに複雑なプロセスをオーケストレーションし、可視性、調整、および制御を向上させる方法を学びましょう。
