メインコンテンツまでスキップ

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

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

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

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

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

  • 常にビジネス目標を念頭に置いてください。 ビジネスにおける ML の主な目的がデータドリブンな意思決定と製品を可能にすることであるのと同様に、MLOps の主な目的は、データドリブンなアプリケーションが安定した状態を保ち、最新の状態に保たれ、ビジネスにプラスの影響を与え続けるようにすることです。 MLOps の技術的な作業に優先順位を付けるときは、ビジネスへの影響を考慮してください。 データチームの生産性は向上しますか? 運用コストやリスクを軽減しますか?
  • ML モデルは、専門的でありながらオープンなツールで管理します。 ML モデルのライフサイクル用に設計された MLflow を使用して、ML モデルを追跡および管理できます。 「生成AI エージェントと 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. デプロイとワークロードを自動化する​

Infrastructure as Code (IaC) をデプロイとメンテナンスに使用​

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

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

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

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

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

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

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

  • Databricks ジョブ:

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

    • Databricksジョブは、Databricksワークスペースでデータ処理およびアナリティクスアプリケーションを実行する方法です。ジョブは、1 つのタスクでも、複雑な依存関係を持つ大規模なマルチタスク ワークフローでもかまいません。 Databricks は、すべてのジョブのタスク オーケストレーション、クラスター管理、モニタリング、およびエラー レポートを管理します。
    • DLT は、信頼性、保守性、テスト性に優れたデータ処理パイプラインを構築するための宣言型フレームワークです。データに対して実行する変換を定義すると、DLT はタスク オーケストレーション、クラスタリング管理、モニタリング、データ品質、およびエラー処理を管理します。

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

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

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

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

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

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

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

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

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

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

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

データ品質を管理するために、DLT はデータ品質の傾向を経時的に監視し、事前定義されたエラーポリシーによる検証と整合性チェックを通じて、不正なデータがテーブルに入るのを防ぎます。DLTとはを参照してください。

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

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

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

モデル展開パターンを参照してください。

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

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

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

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

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

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

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

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

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

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

Databricks Terraform プロバイダーを使用して、ML 環境のデプロイを自動化します。ML では、推論ジョブ、エンドポイントの提供、特徴付けジョブなどのインフラストラクチャをデプロイする必要があります。すべての ML パイプラインは ジョブとして自動化でき、多くのデータ中心の ML パイプラインは、より専門的な Auto Loader を使用して、画像やその他のデータや DLT をコンピュート機能に取り込んだり、メトリクスを監視したりできます。

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

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

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

3。容量とクォータを管理します​

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

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

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

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

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

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

詳細については、 Google Cloud コンソールを使用して割り当てを管理するをご覧ください。

同様に、ストレージ、ネットワーク、およびその他のクラウドサービスには、理解して考慮しなければならない制限があります。

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

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

  • テクノロジーとサービスの制限事項とクラウドの制約。 「容量とクォータの管理」を参照してください。
  • 設計で使用するサービスを決定するための SLA。
  • コスト分析により、コストが増加した場合にアプリケーションのどの程度の改善が実現されるかを判断します。 価格が投資する価値があるかどうかを評価します。

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

4. モニタリング、アラート、ログ記録を設定する​

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

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

プラットフォームモニタリングのためのネイティブツールと外部ツールの使用​

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

  • Databricks レイクハウスモニタリング

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

    レイクハウスモニタリングの費用については、 レイクハウスモニタリングの費用を表示する をご覧ください。

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

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

  • Databricks SQL アラート

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

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

  • Auto Loader モニタリング

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

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

  • ジョブ モニタリング

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

  • DLT モニタリング

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

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

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

  • セキュリティモニタリング

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

  • Cost モニタリング

    「コストの最適化 - コストの監視と管理」を参照してください。

に最終更新