オペレーショナル エクセレンスのベスト プラクティス

この記事では、次のセクションに示すアーキテクチャの原則別に整理された 、オペレーショナル エクセレンスのベスト プラクティスについて説明します。

1. ビルドとリリースのプロセスを最適化する

レイクハウス専用の運用チームを編成する

一般的なベスト プラクティスは、データ チームが 1 つ以上のデータ プラットフォームで作業できるようにするために、プラットフォーム運用チームを配置することです。 このチームは、ブループリントとベストプラクティスを社内で作成する責任があります。 インフラストラクチャの自動化やセルフサービス アクセスなどのツールを提供し、セキュリティとコンプライアンスの要件が満たされていることを保証します。 これにより、プラットフォーム データのセキュリティ保護の負担が中央チームに移り、分散チームはデータの処理と新しい知見の生成に集中できるようになります。

エンタープライズソースコード管理（SCM）を使用する

ソース コード管理 (SCM) は、開発者がより効率的に作業するのに役立ち、リリース速度の高速化と開発コストの削減につながります。 変更を追跡し、コードの整合性を維持し、バグを検出し、以前のバージョンにロールバックするのに役立つツールを持つことは、全体的なソリューション アーキテクチャの重要なコンポーネントです。

Databricks Git フォルダーを使用すると、ユーザーはノートブックやその他のファイルを Git リポジトリに保存でき、リポジトリのクローン作成、コミットとプッシュ、プル、ブランチ管理、ファイルの差分の表示などの機能が提供されます。 コードの可視性と追跡を向上させるには、Git フォルダーを使用します。

DevOps プロセスの標準化 (CI/CD)

継続的インテグレーションと継続的デリバリー (CI/CD) とは、自動化されたパイプラインを使用して、短い頻繁なサイクルでソフトウェアを開発および展開することを指します。 これは新しいプロセスではありませんが、従来のソフトウェア エンジニアリングでは数十年にわたって広く行われており、データエンジニアリング チームやデータサイエンス チームにとってますます必要なプロセスになりつつあります。 データ製品が価値あるものになるためには、タイムリーに提供されなければなりません。 さらに、消費者はこれらの製品内の結果の妥当性に自信を持たなければなりません。 コードの構築、テスト、およびデプロイのプロセスを自動化することで、開発チームは、多くのデータエンジニアリングおよびデータサイエンス チームで依然として主流となっている手動プロセスよりも頻繁かつ確実にリリースを提供できます。 Databricks の CI/CD とは何ですか?を参照してください。

フォルダーを使用したコード開発のベストDatabricksGit プラクティスの詳細については、 を使用したCI/CD テクニック」およびGit DatabricksGitフォルダー (Repos )」 を参照してください。Databricks REST APIと組み合わせて、 GitHub Actions 、 Azure DevOpsパイプライン、または Jenkins ジョブを使用して自動化されたデプロイメント プロセスを作成できます。

MLOps プロセスを標準化する

MLOpsプロセスは、機械学習パイプラインの再現性を提供し、データ チーム間の緊密な連携を可能にし、DevOps とITとの競合を減らし、リリース速度を加速します。 重要なビジネス上の意思決定を促進するために多くのモデルが使用されるため、MLops プロセスを標準化することで、モデルの開発、テスト、デプロイが一貫して確実に行われるようになります。

ML モデルの構築と展開は複雑です。 これを実現するための選択肢はたくさんありますが、明確に定義された標準はほとんどありません。 その結果、過去数年間で機械学習オペレーション (MLOps) が登場しました。 MLOps は、モデル、データ、コードを管理して ML システムのパフォーマンスの安定性と長期的な効率性を向上させるための一連のプロセスと自動化です。 データ準備、探索的データ分析 ( EDA )、機能エンジニアリング、モデルトレーニング、モデル検証、デプロイメント、モニタリングをカバーします。

Databricks プラットフォーム上の MLOps は、機械学習 (ML) システムのパフォーマンスと長期的な効率を最適化するのに役立ちます。

  • ビジネス目標を常に念頭に置いてください。 ビジネスにおける Computational の主な目的がデータドリブンな意思決定と製品を可能にすることであるのと同様に、Simulation Ops の主な目的は、これらのデータドリブンなアプリケーションの安定性を保ち、最新の状態に保ち、ビジネスにプラスの影響を与え続けることです。 MLOps の技術的な作業に優先順位を付けるときは、ビジネスへの影響を考慮してください。 新しいビジネスユースケースが可能になりますか? データチームの生産性が向上しますか? 運用コストやリスクを軽減しますか?

  • 専門的でありながらオープンなツールを使用して ML モデルを管理します。MLモデルのライフサイクル用に設計された MLflow を使用して、ML モデルを追跡および管理できます。 MLflow を使用した ML ライフサイクル管理を参照してください。

  • 機械学習 Ops をモジュール方式で実装する: 他のソフトウェアアプリケーションと同様に、コード品質は機械学習アプリケーションにとって最も重要です。 モジュール化されたコードにより、個々のコンポーネントのテストが可能になり、将来のコードリファクタリングの問題が軽減されます。 明確なステップ (トレーニング、評価、デプロイなど)、スーパーステップ (トレーニングからデプロイまでのパイプラインなど)、責任を定義して、機械学習アプリケーションのモジュール構造を明確にします。

これについては、Databricks の電子書籍『The Big Book of MLOps』で詳しく説明されています。

環境分離戦略の定義

組織がDatabricksのようなデータプラットフォームを使用する場合、多くの場合、環境間（開発と運用など）または組織の運用単位間にデータ分離境界を設ける必要があります。

分離の基準は組織によって異なる場合がありますが、通常は次のことが期待されます。

  • ユーザーは、指定されたアクセスルールに基づいてのみデータにアクセスできる。

  • データは、指定された人物またはチームのみが管理できる。

  • データはストレージ内で物理的に分離されている。

  • データは指定された環境でのみアクセスできる。

Databricksでは、 ワークスペース が主要なデータ処理環境であり、個別の ワークスペース によって全体的なセットアップが改善されるシナリオがいくつかあります。次に例を示します。

  • ワークスペース管理者の共有を避け、 Databricks内の資産がビジネス ユニット間で意図せず共有されないよう、各ビジネス ユニットを独自のワークスペースで分離します。

  • ソフトウェア開発ライフサイクル環境 (開発、ステージング、本番運用など) を分離します。 たとえば、別の本番運用ワークスペースを使用すると、新しいワークスペース設定を本番運用に適用する前にテストできます。 または、本番運用環境では開発環境よりも厳密なワークスペース設定が必要になる場合があります。 開発環境、ステージング環境、本番運用環境を異なる仮想ネットワークにデプロイする必要がある場合は、3 つの環境に異なるワークスペースも必要です。

  • リソース制限を克服するためにワークスペースを分割する: クラウド アカウント/サブスクリプションにはリソース制限があります。 ワークスペースを異なるサブスクリプション/アカウントに分割することは、各ワークスペースに十分なリソースが確保されるようにするための 1 つの方法です。 さらに、Databricks ワークスペースにもリソース制限があります。 ワークスペースを分割すると、各ワークスペースのワークロードが常にリソースの完全なセットにアクセスできるようになります。

ただし、共有ワークスペースには考慮すべき欠点もいくつかあります。

  • ノートブックのコラボレーションはワークスペース間では機能しません。

  • 開発用、ステージング用、本番運用用のワークスペースを分け、ワークスペースごとにビジネスユニットを分ける場合は、ワークスペースの数の制限を考慮してください。

  • 複数のワークスペースの場合、セットアップとメンテナンスの両方を完全に自動化する必要があります (Terraform、ARM、REST API、またはその他の手段による)。 これは、移行の目的で特に重要です。

  • 各ワークスペースをネットワーク層で保護する必要がある場合 (たとえば、データの流出を防ぐため)、特にワークスペースの数が多い場合は、必要なネットワーク インフラストラクチャが非常に高価になる可能性があります。

孤立の必要性と、コラボレーションの必要性とそれを維持するために必要な労力のバランスを見つけることが重要です。

企業のカタログ戦略を定義する

組織には、環境隔離戦略に加えて、メタデータとデータを構造化して分離するための戦略が必要です。 個人情報、支払い情報、健康情報などのデータは潜在的なリスクが高く、データ侵害の脅威がますます高まる中、どのような組織戦略を選択する場合でも、機密データを分離して保護することが重要です。 機密データと非機密データを論理的にも物理的にも分離します。

組織では、特定の種類のデータをクラウド テナント内の特定のアカウントまたはバケットに保存することを要求できます。 Unity Catalogメタストアを使用すると、メタデータを 3 レベルの catalog > schema > tables/views/volumes 名前空間で構造化でき、ストレージの場所は、このような要件を満たすようにメタストア、カタログ、またはスキーマ レベルで構成されます。

組織やコンプライアンスの要件により、特定のデータを特定の環境にのみ保存することが求められることがよくあります。 また、本番運用データを開発環境から分離したり、特定のデータ セットとドメインが結合されないようにしたりすることもできます。 Databricks では、ワークスペースが主要なコンピューティング環境であり、カタログが主要なデータ ドメインです。 Unity Catalogメタストアを使用すると、管理者とカタログ所有者はカタログを特定のワークスペースにバインドできます。 これらの環境認識バインディングは、ユーザーに付与された特定のデータ オブジェクトのアクセス許可に関係なく、ワークスペース内で特定のカタログのみが使用可能であることを保証するのに役立ちます。

これらのトピックの詳細については、 Unity Catalogのベストプラクティスを参照してください。

2. デプロイとワークロードを自動化する

デプロイメントとメンテナンスにインフラストラクチャをコードとして利用 (IaC)

Infrastructure as Code (IaC) を使用すると、開発者と運用チームは、ハードウェア デバイス、オペレーティング システム、アプリケーション、およびサービスを手動で構成する代わりに、リソースを自動的に管理、監視、およびプロビジョニングできます。

HashiCorp Terraform 、複数のクラウド プロバイダーにわたって安全で予測可能なクラウド インフラストラクチャを作成するための人気の OSS ツールです。 Databricks Terraform プロバイダーは、柔軟で強力なツールを使用して、Databricks ワークスペースと関連するクラウド インフラストラクチャを管理します。 Databricks Terraformプロバイダーの目標は、すべてのDatabricks REST APIsをサポートし、データ プラットフォームの展開と管理の最も複雑な側面の自動化をサポートすることです。 Databricks Terraform プロバイダーは、クラスターとジョブを確実にデプロイおよび管理し、Databricks ワークスペースをプロビジョニングし、データ アクセスを構成するための推奨ツールです。

コンピュート構成の標準化

コンピューティング環境を標準化すると、すべての環境で同じソフトウェア、ライブラリ、構成が使用されるようになります。 この一貫性により、結果の再現、問題のデバッグ、および環境間でのシステムの保守が容易になります。 標準化された環境により、チームは環境を最初から構成してセットアップする必要がなくなり、時間とリソースを節約できます。 これにより、手動セットアップ中に発生する可能性のあるエラーや不整合のリスクも軽減されます。 標準化により、すべての環境で一貫したセキュリティ ポリシーとプラクティスを実装することも可能になります。 これにより、組織はリスクをより適切に管理し、規制要件に準拠することができます。 最後に、標準化により、無駄が削減され、リソースの使用率が最適化されるため、組織はコストをより適切に管理できるようになります。

標準化には、環境のセットアップと継続的なリソース管理の両方が含まれます。 一貫したセットアップのために、Databricks ではインフラストラクチャをコードとして使用することを推奨しています。 時間の経過とともに起動されるコンピュート リソースが一貫して構成されるようにするには、コンピュート ポリシーを使用します。 Databricksワークスペース管理者は、一連のポリシー ルールに基づいて、ユーザーまたはグループのコンテンツ作成権限を制限できます。 Spark 構成設定を適用し、クラスタースコープのライブラリのインストールを適用できます。 コンピュートポリシーを使用して、プロジェクトの標準作業環境として T シャツのサイズ (S、M、L) を定義することもできます。

ジョブに自動化されたワークフローを使用する

ジョブの自動ワークフローを設定すると、不要な手動タスクが削減され、ジョブの作成と展開の DevOps プロセスを通じて生産性が向上します。 Data Intelligence Platform には、これを行う方法が 2 つあります。

  • Databricks Workflows :

    Databricks Workflows Databricks Data Intelligence Platform 上でデータ処理、機械学習、アナリティクス パイプラインを調整します。 これは、 Databricksプラットフォームと統合されたフルマネージド オーケストレーション サービスです。

    • Databricksジョブは、 Databricksワークスペースでデータ処理およびアナリティクス アプリケーションを実行する方法です。 ジョブは単一のタスクの場合もあれば、複雑な依存関係を持つ大規模なマルチタスク ワークフローの場合もあります。 Databricks 、すべてのジョブのタスクオーケストレーション、クラスター管理、モニタリング、エラーレポートを管理します。

    • Delta Live Tables は、信頼性が高く、保守性とテスト性に優れたデータ処理パイプラインを構築するための宣言型フレームワークです。 データに対して実行する変換を定義すると、 Delta Live Tablesタスク オーケストレーション、クラスター管理、モニタリング、データ品質、およびエラー処理を管理します。

  • 外部オーケストレーター:

    包括的な Databricks REST API は、外部ワークフロー エンジンによって使用され、Databricks アセット、ノートブック、およびジョブを調整します。 たとえば、 Apache Airflow を参照してください。

Databricks Workflowsのすべてのタスク依存関係にはDatabricks を使用し、必要に応じてこれらのカプセル化されたワークフローを外部オーケストレーターに統合することをお勧めします。

自動化されたイベント駆動型のファイル取り込みを使用する

イベントドリブン (vs. スケジュール駆動型のファイル取り込みには、効率性、データ鮮度の向上、リアルタイムデータの取り込みなど、さまざまな利点があります。 イベントが発生したときにのみジョブを実行すると、リソースが無駄にならず、コストを節約できます。

Auto Loader、 クラウドストレージに到着した新しいデータファイルを増分的かつ効率的に処理します。JSON、CSV、PARQUET、AVRO、ORC、TEXT、などの多くのファイル形式を取り込むことができます BINARYFILE。 クラウドストレージ上の入力フォルダーを使用すると、 Auto Loader は新しいファイルが到着すると自動的に処理します。

1 回限りの取り込みの場合は、代わりにコマンド`COPY INTO`の使用を検討してください。

データパイプラインにETLフレームワークを使用する

ETL タスクを手動で実行することも可能ですが、フレームワークを使用すると多くの利点があります。 フレームワークは、ETL プロセスに一貫性と再現性をもたらします。 フレームワークは、事前に構築された機能とツールを提供することで、一般的なタスクを自動化し、時間とリソースを節約できます。 ETL フレームワークは大量のデータを処理でき、必要に応じて簡単にスケールアップまたはスケールダウンできます。 これにより、リソースの管理が容易になり、変化するビジネス ニーズに対応できるようになります。 多くのフレームワークにはエラー処理機能とログ機能が含まれており、問題の特定と解決が容易になります。 また、多くの場合、データウェアハウスやデータレイクにデータがロードされる前に、データが特定の基準を満たしていることを確認するためのデータ品質チェックと検証が含まれます。

Delta Live Tables は、信頼性が高く、保守性とテスト性に優れたデータ処理パイプラインを構築するための宣言型フレームワークです。 データに対して実行する変換を定義すると、 Delta Live Tablesタスク オーケストレーション、クラスター管理、モニタリング、データ品質、エラー処理を処理します。

Delta Live Tablesを使用すると、 SQLまたはPythonでエンドツーエンドのデータパイプラインを定義できます。データソース、変換ロジック、およびデータのターゲット状態を指定します。 Delta Live Tables は依存関係を維持し、ジョブを実行するインフラストラクチャを自動的に決定します。

データ品質を管理するために、Delta Live Tables は、データ品質の傾向を長期にわたって監視し、事前定義されたエラー ポリシーによる検証と整合性チェックを通じて、不良データがテーブルに入力されるのを防ぎます。 「Delta Live Tables とは何ですか?」を参照してください。

機械学習ワークロードのデプロイコードアプローチに従う

コードとモデルは、ソフトウェア開発の各段階を通じて非同期的に進行することがよくあります。 これを実現するには、次の 2 つの方法があります。

  • コードのデプロイ: ML プロジェクトは開発環境でコーディングされ、その後このコードはステージング環境に移動されてテストされます。 テストが成功すると、プロジェクト コードは本番運用環境にデプロイされ、そこで実行されます。

  • モデルのデプロイ: 開発環境でモデルのトレーニングが実行されます。 生成されたモデル成果物は、モデルを本番運用環境にデプロイする前に、モデル検証チェックのためにステージング環境に移動されます。

「 モデルのデプロイ パターン」を参照してください。

Databricks では、ほとんどのユースケースに対してデプロイコード アプローチを推奨しています。 このモデルの主な利点は次のとおりです。

  • これは、Git や CI/CD システムなどの使い慣れたツールを使用する従来のソフトウェア エンジニアリング ワークフローに適合します。

  • ロックダウンされた環境での自動再トレーニングをサポートします。

  • 本番運用環境のみに製品トレーニング データへの読み取りアクセス権が必要です。

  • トレーニング環境を完全に制御できるため、再現性が簡素化されます。

  • これにより、データサイエンス チームはモジュール コードと反復テストを使用できるようになり、より大規模なプロジェクトの調整と開発に役立ちます。

これについては、Databricks の電子書籍『The Big Book of MLOps』で詳しく説明されています。

モデルレジストリを使用してコードとモデルのライフサイクルを分離する

モデルのライフサイクルはコードのライフサイクルと 1 対 1 で対応していないため、Unity Catalog MLのホストされたバージョンでMLflow Model Registry モデルのライフサイクル全体を管理できます。Unity Catalogのモデルは、ワークスペース全体での集中アクセス制御、監査、リネージ、モデル検出などUnity Catalogの利点をMLモデルに拡張します。 Unity Catalog のモデルは、オープンソースの MLflow Python クライアントと互換性があります。

MLエクスペリメントの追跡を自動化

MLエクスペリメントの追跡は、各エクスペリメントに関連するメタデータを保存し、エクスペリメントを整理するプロセスです。 このメタデータには、拡張機能の入力/出力、ビルド、モデル、その他の成果物が含まれます。 実験追跡の目標は、 MLモデル開発プロセスのすべての段階で再現可能な結果を作成することです。 このプロセスを自動化すると、エクスペリメントの数のスケーリングが容易になり、すべてのエクスペリメントでキャプチャされたメタデータの一貫性が確保されます。

Databricks Autologging は、 MLflow自動ログ記録を拡張して、 Databricksでの機械学習トレーニング セッションの自動エクスペリメント追跡を実現するコード不要のソリューションです。 Databricks Autologging は、 MLflowトラッキング実行として記録されたトレーニング実行を使用してモデルをトレーニングすると、モデルの パラメーター、メトリック、ファイル、および リネージ情報 を自動的にキャプチャします。

同じインフラストラクチャを再利用して機械学習パイプラインを管理する

機械学習パイプラインに使用されるデータは、通常、他のデータパイプラインに使用されるデータと同じソースから取得されます。 MLとデータパイプラインは、どちらもビジネス ユーザー分析またはモデル トレーニング用にデータを準備するという点で似ています。 また、どちらもスケーラブルで、安全で、適切に監視する必要があります。 どちらの場合も、使用するインフラストラクチャはこれらのアクティビティをサポートする必要があります。

Databricks Terraform プロバイダーを使用して、ML 環境のデプロイメントを自動化します。 ML では、推論ジョブ、サービス エンドポイント、特徴付けジョブなどのインフラストラクチャを展開する必要があります。 すべての機械学習パイプラインはジョブを使用して自動化することができ、多くのデータ中心の機械学習パイプラインでは、より特化されたAuto Loaderを使用して画像やその他のデータ、 Delta Live Tables取り込んで機能をコンピュートしたりメトリックを監視したりすることができます。

モデルのエンタープライズ グレードの展開には、必ず モデル サービング MLを使用してください。

複雑なデータとMLプロジェクトに宣言型管理を活用する

MLOps 内の宣言型フレームワークにより、チームは望ましい結果を高レベルで定義し、実行の詳細をシステムに処理させることができるため、ML モデルの展開とスケーリングが簡素化されます。 これらのフレームワークは、継続的な統合とデプロイメントをサポートし、テストとインフラストラクチャ管理を自動化し、モデルのガバナンスとコンプライアンスを確保することで、最終的には市場投入までの時間を短縮し、ML ライフサイクル全体の生産性を向上させます。

DatabricksAsset Bundles (DAB) は、 プラットフォームの複雑なデータ分析およびML Databricksプロジェクトの開発を効率化するためのツールです。バンドルを使用すると、単一の簡潔な宣言型 YAML 構文を使用してソフトウェア開発ワークフローに CI/CD 機能が提供され、アクティブな開発中に複雑なプロジェクトを簡単に管理できるようになります。 バンドルを使用してプロジェクトのテスト、展開、構成管理を自動化することで、エラーを減らしながら、テンプレート化されたプロジェクトとして組織全体にソフトウェアのベスト プラクティスを推進できます。

3. 容量とクォータを管理する

マネージドサービスの制限とクォータ

サービス制限とクォータを管理することは、インフラストラクチャが正常に機能し続けるように維持し、予期しないコストを防ぐために重要です。 クラウド上で起動されるすべてのサービスには、アクセス レート制限、インスタンス数、ユーザー数、メモリ要件などの制限を考慮する必要があります。 クラウド プロバイダーについては、 クラウドの制限を確認してください。 ソリューションを設計する前に、これらの制限を理解する必要があります。

具体的には、Databricks プラットフォームには、さまざまな種類の制限があります。

Databricks プラットフォームの制限:これらは Databricks リソースに固有の制限です。 プラットフォーム全体の制限については、 「リソース制限」に記載されています。

Unity Catalog制限: Unity Catalogリソース割り当て

サブスクリプション/アカウント クォータ: Databricks はサービスにクラウド リソースを活用します。 たとえば、Databricks 上のワークロードはクラスター上で実行され、Databricks プラットフォームはクラウド プロバイダーの仮想マシン (VM) を起動します。 クラウド プロバイダーは、同時に起動できる VM の数についてデフォルトのクォータを設定します。 必要に応じて、これらのクォータを調整する必要があります。

詳細については、「 Amazon EC2 サービスクォータ」を参照してください。

同様に、ストレージ、ネットワーク、その他のクラウド サービスにも制限があるため、理解し、考慮する必要があります。

キャパシティ プランニングへの投資

キャパシティ プランニングには、ストレージ、コンピュート、ネットワークなどのクラウド リソースを管理して、コストを最適化しながらパフォーマンスを維持することが含まれます。 突然のビジネスの変化や世界的な出来事など、さまざまな理由で発生する可能性のある予想される負荷の変動を計画します。 負荷の変動 (予期しないものを含む) をテストして、ワークロードをスケーリングできることを確認します。 すべてのリージョンが、1 つのリージョンで障害が発生した場合に合計負荷をサポートできるように十分にスケーリングできることを確認します。 考える：

  • テクノロジーとサービスの制限、およびクラウドの制約。 「 容量とクォータの管理」を参照してください。

  • 設計で使用するサービスを決定するための SLA。

  • コストが増加した場合に、アプリケーションでどの程度の改善が実現されるかを判断するためのコスト分析。 価格が投資に見合う価値があるかどうかを評価します。

優先度の高い (ボリューム) イベントを理解し、計画することが重要です。 プロビジョニングされたクラウド リソースが十分でなく、ワークロードを拡張できない場合、ボリュームの増加によって停止が発生する可能性があります。

4. モニタリング、アラート、ログの設定

モニタリングプロセスの確立

データ プラットフォームのモニタリング プロセスを確立することは、いくつかの理由から重要です。 モニタリング プロセスにより、データ品質の問題、パフォーマンスのボトルネック、システム障害などの問題を早期に検出できるため、ダウンタイムやデータ損失を防ぐことができます。 これらは、データ プラットフォームの非効率性を特定し、無駄を減らしてリソースの使用率を向上させることでコストを最適化するのに役立ちます。 さらに、モニタリング プロセスは、規制要件への準拠を保証し、データ アクセスと使用の監査証跡を提供するのに役立ちます。

プラットフォームモニタリングにネイティブツールと外部ツールを使用する

Databricks Data Intelligence Platform には組み込み モニタリング ソリューションがあり、外部 モニタリング システムを統合します。

  • SQLウェアハウス モニタリング

    SQL ウェアハウスを監視することは、時間の経過に伴う負荷プロファイルを理解し、SQL ウェアハウスを効率的に管理するために不可欠です。 SQLウェアハウスモニタリングでは、ウェアハウスが処理したクエリ数やウェアハウスに割り当てられたクラスター数などの情報を確認できます。

  • Databricks SQLアラート

    Databricks SQL アラートは定期的にクエリを実行し、定義された条件を評価し、条件が満たされた場合に通知を送信します。 アラートを設定してビジネスを監視し、報告されたデータが予想される制限を超えた場合に通知を送信できます。

さらに、Databricks SQL モニター メトリック テーブルの メトリック に基づいて アラートを作成し、たとえば、統計が特定の範囲から外れた場合や、ベースライン テーブルと比較してデータが変動した場合に通知を受け取ることができます。

  • Auto Loaderモニタリング

    Auto Loader には、ストリームの状態を検査するための SQL API が用意されています。 SQL 関数を使用すると、 Auto Loader ストリームによってディスカバーされたファイルに関するメタデータを検索できます。 詳しくは、 モニタリング Auto Loaderを参照してください。

    Apache Spark ストリーミング クエリー リスナー インターフェイスを使用すると、 Auto Loader ストリームをさらに監視できます。

  • ジョブ モニタリング

    ジョブ モニタリングは、障害、遅延、パフォーマンスのボトルネックなど、 Databricksジョブの問題を特定して対処するのに役立ちます。 ジョブ モニタリングは、ジョブ のパフォーマンスに関する知見を提供し、リソースの使用率を最適化し、無駄を減らし、全体的な効率を向上させることを可能にします。

  • Delta Live Tablesモニタリング

    すべての Delta Live Tables パイプラインに対してイベント ログが作成および維持されます。 イベント ログには、監査ログ、データ品質チェック、パイプラインの進行状況、データリネージなど、パイプラインに関連するすべての情報が含まれます。 イベント ログを使用し て、データ パイプラインの状態を追跡、把握、監視できます。

  • ストリーミング モニタリング

    ストリーミングは、取り込みと分析のための最も重要なデータ処理技術の 1 つです。 ユーザーと開発者に、アナリティクスとトリガーアクションのための低レイテンシとリアルタイムデータ処理機能を提供します。 Databricks データ インテリジェンス プラットフォームを使用すると、構造化ストリーミング クエリを監視できます。

  • MLとAIモニタリング

    モニタリング 本番運用ワークフローにおけるモデルのパフォーマンスは、 AIおよびMLモデルのライフサイクルの重要な側面です。 推論テーブルは、 エンドポイントからの提供要求入力と応答 (予測)Mosaic AI Model Serving DeltaUnity Catalogを継続的にログに記録し、 の テーブルに保存することで、モデルのモニタリングと診断を簡素化します。その後、DBSQL クエリ、データベース、レイクハウスモニタリングなどのDatabricksプラットフォームのすべての機能を使用して、モデルを監視、デバッグ、最適化できます。

    モニタリング モデルサービングの詳細については、 「モデルの品質とエンドポイントの健全性の監視」を参照してください。