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

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

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

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

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

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

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

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

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

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

Databricks を使用したコード開発のベスト プラクティスの詳細については、Databricks の ベスト プラクティスと推奨される CI/CD ワークフローを参照してください。 Databricks アセット バンドルと共に、GitHub アクション、Azure DevOps パイプライン、または Jenkins ジョブを使用して、自動化されたデプロイ プロセスを作成できます。

MLOps プロセスを標準化する

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

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

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

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

詳しくは、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) をデプロイとメンテナンスに使用する

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

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

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

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

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

Unity カタログのマネージド テーブルを使用する

Unity カタログのテーブルは、 マネージド テーブル または 外部テーブルとして作成できます。 外部テーブルを作成するには、オブジェクトの保存場所を指定する必要があり、これらのテーブルの保守と最適化を行う必要があります。 マネージド テーブルの場合、Databricks はデータ ライフサイクル全体、ストレージの場所とファイル レイアウトを管理し、 予測の最適化を可能にします。 これにより、手動メンテナンスやメンテナンス ジョブの設定が不要になり、実際のクエリ パターンに基づいてテーブルがパフォーマンス用に自動的に最適化されます。

Databricks で管理されているすべての表形式データには 、Unity カタログのマネージド テーブル を使用することをお勧めします。

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

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

• Lakeflow ジョブ:

  Lakeflow ジョブ は、Databricks データ インテリジェンス プラットフォーム上のデータ処理、機械学習、および分析パイプラインを調整します。 これは、Databricks プラットフォームと統合されたフル マネージドオーケストレーション サービスです。

  • Lakeflow ジョブ は、Databricks ワークスペースでデータ処理および分析アプリケーションを実行する方法です。 ジョブは、1 つのタスクにすることも、複雑な依存関係を持つ多くのタスクを持つ場合もあります。 Azure Databricks が、すべてのジョブのタスク オーケストレーション、クラスター管理、監視、およびエラー レポートを管理します。
  • Lakeflow 宣言型パイプライン は、信頼性の高い保守可能でテスト可能なデータ処理パイプラインを構築するための宣言型フレームワークです。 データに対して実行する変換を定義し、Lakeflow 宣言パイプラインはタスク オーケストレーション、クラスター管理、監視、データ品質、エラー処理を管理します。

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

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

  • Apache エアフロー。
  • Azure Data Factory。

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

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

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

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

1 回限りのインジェストの場合は、代わりに COPY INTO コマンドを使うことを検討してください。

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

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

Lakeflow 宣言型パイプラインは、信頼性の高い保守可能でテスト可能なデータ処理パイプラインを構築するための宣言型フレームワークです。 データに対して実行する変換を定義すると、Lakeflow 宣言パイプラインはタスク オーケストレーション、クラスター管理、監視、データ品質、エラー処理を処理します。

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

データ品質を管理するために、Lakeflow 宣言型パイプラインは、時間の経過と共にデータ品質の傾向を監視し、定義済みのエラー ポリシーを使用した検証と整合性チェックによって、不適切なデータがテーブルに入らないようにします。 「Lakeflow 宣言型パイプライン」を参照してください。

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

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

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

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

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

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

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

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

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

ML 実験追跡を自動化する

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

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

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

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

ML 環境のデプロイを自動化するには、Databricks Terraform プロバイダーを使用します。 ML では、推論ジョブ、サービス エンドポイント、特徴量化ジョブなどのインフラストラクチャをデプロイする必要があります。 すべての ML パイプラインを ジョブとして自動化でき、多くのデータ中心の ML パイプラインでは、より特殊な 自動ローダー を使用して、イメージやその他のデータや Lakeflow 宣言パイプライン を取り込んで、機能を計算したり、メトリックを監視したりできます。

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

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

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

Databricks アセット バンドルは、Databricks プラットフォームの複雑なデータ、分析、ML プロジェクトの開発を合理化するためのツールです。 バンドルを使用すると、単一の簡潔な宣言型 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 では、この監視データをさまざまなログ記録サービスに送信できます。

• Databricks レイクハウス監視

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

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

• SQL ウェアハウスの監視

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

• Databricks SQL アラート

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

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

• 自動ローダーの監視

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

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

• ジョブ監視

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

• Lakeflow の宣言型パイプライン監視

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

• ストリーミングの監視

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

• ML と AI の監視

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

  • カスタム モデルについては、推論テーブルを参照して、モデルの監視とデバッグを行います。
  • 外部モデルまたはプロビジョニングされたスループット ワークロードについては、 AI ゲートウェイ対応の推論テーブルを使用したサービス提供モデルの監視に関するページを参照してください。

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

• セキュリティの監視。

  「セキュリティ、コンプライアンス、プライバシー - セキュリティの監視」を参照してください。

• コストの監視

  「コスト最適化 - コストの監視と制御」に関する記事を参照してください。