次の方法で共有

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

  • [アーティクル]

この記事では、オペレーショナル エクセレンスのベスト プラクティスについて、以下のセクションで示すアーキテクチャの原則ごとにまとめて説明します。

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

レイクハウス専門の運用チームを設ける

データ チームが 1 つまたは複数のデータ プラットフォームについて作業できるように、プラットフォーム運用チームを設けるのが一般的なベスト プラクティスです。 このチームは、内部的なブループリントとベスト プラクティスを作成します。 インフラストラクチャの自動化やセルフサービス アクセスなどのためのツールを提供し、セキュリティとコンプライアンスの要件が満たされていることを確認します。 これにより、プラットフォーム データのセキュリティ保護の負担が中央のチームにまとめられ、分散型チームはデータの処理と新しい分析情報の生成に集中できます。

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

ソース コード管理 (SCM) は、開発者がより効果的に作業するのに役立ちます。これにより、リリースまでの速度が上がり、開発コストが削減される可能性があります。 変更の追跡、コードにおける整合性の維持、バグの検出、以前のバージョンへのロールバックなどに役立つツールを利用できることは、ソリューション アーキテクチャ全体にとって重要な要素となります。

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

DevOps プロセスを標準化する (CI/CD)

継続的インテグレーションと継続的デリバリー (CI/CD) とは、自動化パイプラインを使い、短いサイクルを頻繁に行うことで、ソフトウェアを開発およびデプロイすることです。 これは新しいプロセスではなく、従来のソフトウェア エンジニアリングで数十年にわたって広く見られたものですが、データ エンジニアリングおよびデータ サイエンスのチームにとって必要なプロセスになりつつあります。 データ製品を価値のあるものにするには、適切なタイミングで提供する必要があります。 さらに、コンシューマーは、これらの製品で得られる結果の有効性を信頼している必要があります。 コードのビルド、テスト、デプロイといったプロセスを自動化することで、開発チームは、データ エンジニアリングとデータ サイエンスの多くのチームでいまだに多数を占める手動プロセスより、頻繁かつ確実にリリースを配布できます。 「Azure Databricks の CI/CD とは」をご覧ください。

Databricks Git フォルダーを使用したコード開発に関するベスト プラクティスについて詳しくは、Git と Databricks Git フォルダー (Repos) を使用した CI/CD 手法に関するページをご覧ください。 これと共に、Databricks REST API を使うことで、GitHub Actions、Azure DevOps パイプライン、または Jenkins ジョブによる自動デプロイ プロセスを作成できます。

MLOps プロセスを標準化する

MLOps プロセスは ML パイプラインの再現性を提供し、データ チーム間でより密接なコラボレーションを可能にします。また、DevOps と IT との摩擦を減らし、リリースまでの速度を加速させることができます。 多くのモデルを使用して主要なビジネス上の意思決定を推進するため、MLops プロセスを標準化することで、モデルの開発、テスト、デプロイが一貫して確実に行われます。

ML モデルの構築とデプロイは複雑です。 これを実現するには多くのオプションがありますが、明確に定義された標準というものはほとんどありません。 その結果、ここ数年、機械学習の運用 (MLOps) が注目されるようになっています。 MLOps は、ML システムのパフォーマンスの安定性と長期的な効率を向上させるための、モデル、データ、コードの管理に関する一連のプロセスと自動化です。 それにおいては、データ準備、探索的データ分析 (EDA)、特徴エンジニアリング、モデル トレーニング、モデル検証、デプロイ、監視が扱われています。

Databricks プラットフォームで MLOps を使用すると、機械学習 (ML) システムのパフォーマンスと長期的な効率を最適化することができます。

  • ビジネス目標を常に念頭に置く: ビジネスにおける ML の主な目的がデータ ドリブンの意思決定と製品を可能にすることであるのと同様に、MLOps の主な目的は、それらのデータ ドリブン アプリケーションが安定を保ち、最新の状態を維持し、ビジネスにプラスの影響を与え続けられるようにすることです。 MLOps での技術的な作業の優先順位を決めるときは、ビジネスへの影響を考慮します。それによって、新しいビジネス ユース ケースは有効になりますか。 データ チームの生産性は向上しますか。 運用コストやリスクは減りますか。
  • 専用のオープン ツールで ML モデルを管理する: ML モデルのライフサイクル向けに設計された MLflow を使用して、ML モデルを追跡したり、管理したりできます。 「MLflow を使用した ML ライフサイクル管理」を参照してください。
  • モジュール形式で MLOps を実装する: 他のソフトウェア アプリケーションと同様に、ML アプリケーションでもコードの品質が最も重要です。 コードをモジュール化すると、コンポーネントを個別にテストでき、将来コードをリファクタリングするときの難しさが軽減されます。 明確なステップ (トレーニング、評価、デプロイなど)、スーパー ステップ (トレーニングからデプロイへのパイプラインなど)、ML アプリケーションのモジュール構造を明確にする責任を定義します。

詳しくは、Databricks 電子ブック「The Big Book of MLOps」をご覧ください。

環境分離戦略を定義する

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

分離の標準は組織によって異なりますが、通常は次の要件が含まれます。

  • ユーザーは、指定されたアクセス規則に基づいてのみデータにアクセスできる。
  • データは、指定されたユーザーまたはチームのみが管理できる。
  • データは、ストレージ内で物理的に分離される。
  • データは、指定された環境でのみアクセスできる。

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

  • ワークスペース管理者の共有を避け、Databricks 内の資産がビジネス ユニット間で意図せず共有されないようにするために、異なるビジネス ユニットを独自のワークスペースに分離します。
  • ソフトウェア開発ライフサイクル環境 (開発、ステージング、運用など) を分離します。 たとえば、運用ワークスペースを分けて使用すると、新しいワークスペース設定を運用環境に適用する前に、それらをテストできます。 運用環境では、開発環境よりも厳しいワークスペース設定が必要になる場合もあります。 開発、ステージング、運用環境を異なる仮想ネットワークにデプロイする必要がある場合は、3 つの環境に異なるワークスペースが必要になります。
  • リソースの制限を克服するためにワークスペースを分割します。クラウド アカウントやサブスクリプションには、リソースの制限があります。 ワークスペースを異なるサブスクリプションやアカウントに分割することは、ワークスペースごとに十分なリソースを使用できるようにするための 1 つの方法です。 さらに、Databricks ワークスペースには、リソースの制限もあります。 ワークスペースを分割すると、各ワークスペース内のワークロードが常にリソースのセット全体にアクセスできるようになります。

しかし共有ワークスペースには、考慮しなければならない、いくつかの欠点もあります。

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

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

  • 各ワークスペースをネットワーク層でセキュリティ保護する必要がある場合 (たとえば、データ流出から保護するため)、特にワークスペースの数が多くなると、必要なネットワーク インフラストラクチャのコストがかかる可能性があります。

分離とコラボレーションのそれぞれの必要性と、それらを維持するために必要とされる労力のバランスを見極めることが重要です。

大規模組織のカタログ戦略を定義する

環境分離戦略と共に、組織にはメタデータとデータを構造化し、分離するための戦略が必要です。 個人を特定できる情報、支払い、健康情報を含むデータには、常に高い潜在的なリスクが伴います。さらに、データ侵害の脅威が増え続ける中で、どのような組織の戦略を選択するとしても、機密データを分離して保護することは重要です。 機密データを機密データ以外から論理的にも物理的にも分離します。

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

多くの場合、組織の要件やコンプライアンス要件では、特定のデータを特定の環境内で保持することが指示されています。 また、運用データが開発データから分離された状態を維持するか、特定のデータ セットとドメインが結合されないようにする必要もあります。 Databricks では、ワークスペースは主なコンピューティング環境で、カタログは主なデータ ドメインです。 Unity Catalog メタストアを使用すると、管理者とカタログ所有者は、カタログを指定のワークスペースにバインドすることができます。 環境によって認識されるこれらのバインドにより、ユーザーに付与されている特定のデータ オブジェクトのアクセス許可に関係なく、ワークスペース内で特定のカタログだけが使用できるようにすることができます。

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

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

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

コードとしてのインフラストラクチャ (IaC) を使用すると、開発者と運用チームは、ハードウェア デバイス、オペレーティング システム、アプリケーション、サービスを手動で構成することなく、リソースを自動的に管理、監視、プロビジョニングできます。

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

コンピューティング構成を標準化する

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

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

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

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

  • Databricks ジョブ:

    Databricks ジョブでは、Databricks Data Intelligence Platform でデータ処理、機械学習、分析のパイプラインが調整されます。 これは、Databricks プラットフォームと統合されたフル マネージドオーケストレーション サービスです。

    • Databricks ジョブは、Databricks ワークスペースでデータ処理および分析アプリケーションを実行する手段です。 ジョブは単一タスクにすることも、複雑な依存関係がある大規模なマルチタスク ワークフローにすることもできます。 Databricks が、すべてのジョブのタスク オーケストレーション、クラスター管理、監視、エラー レポートを管理します。
    • Delta Live Tables は、信頼性、保守性、テスト可能性に優れたデータ処理パイプラインを構築するための宣言型フレームワークです。 ユーザーはデータに対して実行したい変換を定義し、Delta Live Tables は、タスクのオーケストレーション、クラスターの管理、監視、データの品質、エラー処理を管理します。

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

    外部オーケストレーターが Databricks の資産、Notebooks、ジョブを調整するには、包括的な Azure Databricks REST API が使われます。 参照トピック

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

自動化されたイベント ドリブン ファイル インジェストを使用する

イベント ドリブン (対照的なのはスケジュール ドリブン) ファイル インジェストには、効率が良い、データの鮮度が向上する、リアルタイムでデータ インジェストを行えるなど、いくつかの利点があります。 イベントが発生した場合にのみジョブを実行すると、リソースを無駄にしないで済み、コストを節約できます。

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

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 とは」を参照してください。

ML ワークロードのコードのデプロイ アプローチに従う

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

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

「モデルのデプロイ パターン」をご覧ください。

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

  • Git や CI/CD システムなどの馴染みのツールを使って、従来のソフトウェア エンジニアリング ワークフローに適合します。
  • ロックダウンされた環境での自動再トレーニングをサポートします。
  • 運用環境でのみ、運用トレーニング データへの読み取りアクセスが必要です。
  • トレーニング環境を完全に制御できるため、再現性を簡略化するのに役立ちます。
  • データ サイエンス チームはモジュール式コードと反復テストを使用でき、これは大規模なプロジェクトでの調整と開発に役立ちます。

詳しくは、Databricks 電子ブック「The Big Book of MLOps」をご覧ください。

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

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

ML 実験追跡を自動化する

ML 実験の追跡は、各実験に関連するメタデータを保存し、実験を整理するプロセスです。 このメタデータには、実験の入力/出力、パラメーター、モデル、およびその他の成果物が含まれます。 実験追跡の目的は、ML モデル開発プロセスのすべての段階で再現可能な結果を作成することです。 このプロセスを自動化すると、実験の数を簡単に増減できるようになります。また、すべての実験でキャプチャされたメタデータの一貫性が確保されます。

Databricks Autologging は、MLflow 自動ログ記録を拡張して、Azure Databricks 上の機械学習トレーニング セッションの自動実験追跡を提供する、ノーコード ソリューションです。 MLflow の追跡実行として記録されたトレーニング実行を使ってモデルをトレーニングすると、Databricks Autologging により、モデルのパラメーター、メトリック、ファイル、系列の情報が自動的にキャプチャされます。

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

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

ML 環境のデプロイを自動化するには、Databricks Terraform プロバイダーを使います。 ML では、推論ジョブ、サービス エンドポイント、特徴量化ジョブなどのインフラストラクチャをデプロイする必要があります。 すべての ML パイプラインはジョブとして自動化でき、多くのデータ中心 ML パイプラインでは、さらに特殊な自動ローダーを使ってイメージや他のデータを取り込み、Delta Live Tables を使って特徴量の計算やメトリックの監視を行うことができます。

ML モデルのエンタープライズ レベルのデプロイには、モデルの提供を使用してください。

複合データおよび ML プロジェクトに宣言型管理を利用する

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

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

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

サービスの制限とクォータを管理する

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

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

Databricks プラットフォームの制限: これらは、Azure Databricks リソースに固有の制限です。 プラットフォーム全体の制限については、「リソース制限」をご覧ください。

Unity Catalog の制限: Unity Catalog のリソース クォータ

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

詳しくは、「VM ファミリの vCPU クォータを増やす」をご覧ください。

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

キャパシティ プランニングに投資する

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

  • テクノロジとサービスに関する制限およびクラウドの制限。 「容量とクォータを管理する」をご覧ください。
  • 設計で使用するサービスを決定する SLA。
  • コストが増えた場合に、アプリケーションでどの程度の改善が実現されるかを特定するコスト分析。 その価格に投資するだけの価値があるかどうかを評価します。

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

4.監視、アラート、ログを設定する

監視プロセスを確立する

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

プラットフォームの監視にネイティブ ツールと外部ツールを使用する

Databricks Data Intelligence Platform には、組み込みの監視ソリューションがあり、外部監視システムが統合されています。

  • Azure 監視ソリューションを使用したプラットフォームの監視

    監視は、どのような運用レベル ソリューションでも重要なものです。Azure Databricks では、カスタム アプリケーション メトリック、ストリーミング クエリ イベント、アプリケーション ログ メッセージを監視するための堅牢な機能が提供されます。 Azure Databricks では、この監視データをさまざまなログ記録サービスに送信できます。 以下の記事では、Azure Databricks から Azure Monitor (Azure の監視データ プラットフォーム) に監視データを送信する方法が説明されています。

  • Databricks レイクハウス監視

    Databricks レイクハウス監視を使用すると、アカウント内のすべてのテーブルにおいてデータの統計プロパティと品質を監視できます。 データ品質の監視は、時間の経過に伴うデータの整合性を追跡および確認するための定量的な手段を提供し、データ分散とモデルのパフォーマンスにおける変化を識別し、ユーザーに通知するのに役立ちます。 モデルの入力や予測を含む、推論テーブルを監視することで、機械学習モデルのパフォーマンスを追跡することもできます。

    レイクハウス監視のコストを理解するには、「レイクハウス監視費用を確認する」を参照してください。

  • SQL ウェアハウスの監視

    SQL ウェアハウスの監視は、負荷プロファイルを経時的に把握し、SQL ウェアハウスを効率的に管理するために不可欠です。 SQL ウェアハウスの監視を使うと、ウェアハウスによって処理されたクエリの数や、ウェアハウスに割り当てられたクラスターの数などの情報を見ることができます。

  • Databricks SQL アラート

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

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

  • 自動ローダーの監視

    自動ローダーは、ストリームの状態を検査するための SQL API を提供します。 SQL 関数を使って、自動ローダー ストリームによって検出されたファイルに関するメタデータを見つけることができます。 「自動ローダーの監視」をご覧ください。

    Apache Spark のストリーミング クエリ リスナー インターフェイスを使うと、自動ローダー ストリームをさらに詳しく監視できます。

  • ジョブの監視

    ジョブの監視は、Databricks ジョブの問題 (エラー、遅延、パフォーマンスのボトルネックなど) を特定して対処するのに役立ちます。 ジョブの監視は、ジョブのパフォーマンスに関する分析情報を提供し、リソース使用率を最適化し、無駄を減らし、全体的な効率を向上させることができます。

  • Delta Live Tables の監視

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

  • ストリーミングの監視

    ストリーミングは、インジェストと分析に関する最も重要なデータ処理手法の 1 つです。 これにより、分析およびアクションのトリガーのための低遅延でリアルタイムのデータ処理機能が、ユーザーと開発者に提供されます。 Databricks Data Intelligence Platform を使用すると、構造化ストリーミング クエリを監視できます。

  • ML と AI の監視

    運用環境ワークフローでモデルのパフォーマンスを監視することは、AI および ML モデルのライフサイクルの重要な側面です。 推論テーブルは、Mosaic AI Model Serving エンドポイントから提供される要求の入力と応答 (予測) を継続的にログし、Unity Catalog の Delta テーブルにそれらを保存することで、モデルの監視と診断を簡略化しています。 これで、DBSQL クエリ、ノートブック、Lakehouse Monitoring など、Databricks プラットフォームのすべての機能を使って、モデルの監視、デバッグ、最適化を実行できるようになります。

    監視モデルの提供の詳細については、「モデルの品質とエンドポイントの正常性を監視する」を参照してください。

  • セキュリティの監視

    セキュリティ、コンプライアンス、プライバシーでのセキュリティ監視に関する記事をご覧ください。

  • コストの監視

    コスト最適化でのコストの監視と制御に関する記事をご覧ください。