パフォーマンス効率のベスト プラクティス

  • [アーティクル]

この記事では、次のセクションでアーキテクチャの原則ごとに記載された パフォーマンス効率 のベスト プラクティスについて説明します。

1.垂直スケーリング、水平スケーリング、線形スケーラビリティ

ベスト プラクティスに進む前に、水平スケーリング、垂直スケーリング、線形スケーラビリティなど、分散コンピューティングにおけるいくつかの概念を見てみましょう。

  • 垂直スケーリング: 1 台のマシンにおいて、リソース (通常は CPU、メモリ、または GPU) を追加または削除することで、垂直スケーリングが行なわれます。 これは通常、ワークロードを停止し、それをより大規模なマシンに移動してから、再起動することを意味します。 垂直スケーリングの場合、より大きなマシンがないことや、次に大きなマシンの価格が非常に高額になる可能性がある、といった制限が生じることがあります。
  • 水平スケーリング: 水平スケーリングは、分散システムにおいて、ノードを追加または削除することで行なわれます。 垂直スケーリングで制限に達した際は、水平スケーリングがソリューションとなります。分散コンピューティングでは、複数のマシン (クラスターと呼ばれます) を持つシステムを使用して、ワークロードを実行します。 これを可能にするためには、ワークロードが Databricks Data Intelligence プラットフォーム、Apache Spark、Photon のエンジンでサポートされ、並列実行用に準備される必要があることは、理解しておくべき重要な点です。 これにより、複数の安価なマシンを、大規模なコンピューティング システムの中で連結することができます。 より多くのコンピューティング リソースが必要な場合は、水平スケーリングによってクラスターにノードを追加し、不要になった際にはそれらを削除します。 ノード数に技術的な面での制限はない (そして、Spark エンジンが負荷分散の複雑な部分を実行する) ものの、その数が多くなることで管理の複雑さは増加します。
  • 線形スケーラビリティとは、システムにリソースを追加したときに、スループットと使用されるリソースの関係が線形になることを意味します。 これは、並列タスクが独立している場合にのみ可能です。 そうでない場合は、さらに計算するために、1 つのノード セットでの中間結果は、クラスター内の別のノード セットで必要になります。 このノード間のデータ交換には、あるノード セットから別のノード セットにネットワーク経由で結果を転送することが含まれ、これにはかなりの時間がかかります。 一般に、分散コンピューティングには、データの分散と交換を管理するためのオーバーヘッドが存在します。 その結果、分散システムで実行すると、単一ノードで分析できる小規模なデータ セット ワークロードがさらに遅くなる可能性があります。 Databricks Data Intelligence プラットフォームは、ワークロード固有のニーズを満たす柔軟なコンピューティング (単一ノードと分散) を提供します。

2.サーバーレス アーキテクチャを使用する

サーバーレス コンピューティングを使用する

Databricks Data Intelligence プラットフォーム上のサーバーレス コンピューティングでは、コンピューティング レイヤーはユーザーの Azure Databricks アカウントで実行されます。 このサービスはフル マネージドで、Databricks によって継続的に強化されています。 ユーザーは、使用した分だけのお支払いでよく、これにより生産性も向上します。

  • クォータの調整、ネットワーク リソースの作成と保守、請求ソースへの接続など複雑なクラウド環境の管理を、クラウド管理者が行なう必要はなくなります。 低レベルのクラウド コンポーネントを管理する代わりに、より価値の高いプロジェクトに時間を集中させることができます。
  • ユーザーは、ほぼゼロのクラスター起動待機時間と、クエリ コンカレンシーの向上からメリットを得られます。

Databricks は、さまざまなワークロードに対してマネージド サービスを提供します。

  • SQL ワークロード用のサーバーレス SQL ウェアハウス

    ワークスペース管理者は、インスタント コンピューティングが有効で、Databricks によって管理されるサーバーレス SQL ウェアハウスを作成できます。 これは、通常の Databricks SQL ウェアハウスで行なうのと同じように、Databricks SQL クエリとともに使用できます。 サーバーレス コンピューティングは、SQL ウェアハウスの起動時間が非常に速く、そのインフラストラクチャは Databricks によって管理されます。

  • 効率的で信頼性の高いワークフローのためのサーバーレス ジョブ

    ジョブ用のサーバーレス コンピューティングを使うと、インフラストラクチャを構成およびデプロイしなくても、Databricks ジョブを実行できます。 サーバーレス コンピューティングでは、ユーザーはデータ処理と分析パイプラインの実装に集中できます。また、ワークロード用のコンピューティングの最適化やスケーリングなどコンピューティング リソースの管理は、Databricks によって効率的に行われます。 ジョブが実行されるコンピューティング リソースでは、自動スケーリングと Photon が自動的に有効になります。

    課金対象の使用状況システム テーブルのクエリを実行して、ジョブ用のサーバーレス コンピューティングを使うジョブのコストを監視できます。

  • ノートブック用のサーバーレス コンピューティング

    ワークスペースでサーバーレス対話型コンピューティングが有効になっている場合、ワークスペース内のすべてのユーザーは、ノートブックでサーバーレス コンピューティングにアクセスできます。 追加のアクセス許可は必要ありません。

エンタープライズ グレード のモデル サービスを使用する

Mosaic AI Model Serving には、AI モデルのデプロイ、管理、クエリを行うための統一インターフェイスが用意されています。 提供する各モデルは、Web またはクライアント アプリケーションに統合できる REST API として使用できます。

モデル サービスでは、モデルをデプロイするための、高可用性かつ低遅延のサービスが提供されます。 このサービスを使用するとは、需要の変化に合わせて自動的にスケールアップまたはスケールダウンされ、待機時間のパフォーマンスを最適化しながらインフラストラクチャ コストを節約することができます。 この機能からは、サーバーレス コンピューティングが使用されます。

3.パフォーマンスのためのワークロードを設計する

データ インジェストとアクセス パターンを理解する

パフォーマンスの観点からは、「集計対ポイント アクセス」や「スキャン対検索」などのデータ アクセス パターンは、データ サイズによって動作が異なります。 大きなファイルはスキャン クエリでの効率が高く、小さなファイルは検索に適しています (特定の行を見つけるのに読み取る必要があるデータが少ないため)。

インジェスト パターンに対しては、DML ステートメントを使用するのが一般的です。 DML ステートメントは、データがクラスター化されている場合に最もパフォーマンスが高く、単純ににデータのセクションを分離できます。 重要なのは、インジェスト時にデータをクラスター化して分離可能にしておくことです。自然時間の並べ替え順序を維持し、インジェスト対象のテーブルに可能な限り多くのフィルターを適用することを検討してください。 追加のみの上書きインジェスト ワークロードの場合、これは比較的安価な操作であるため、検討すべき点は多くありません。

インジェストとアクセス パターンは、多くの場合、明らかなデータ レイアウトとクラスタリングを指しています。 それ以外では、ビジネスにとって何がより重要かを決定し、その目標を適切に達成する方法に焦点を当てます。

有効な場合には並列計算を使用する

値の取得までの時間は、データを扱う上で重要なディメンションです。 多くのユース ケースは、1 台のマシンに簡単に (小さなデータ、少数の単純な計算手順を) 実装できるものですが、一方、大規模なデータ セットを処理する必要があり、複雑なアルゴリズムのために実行時間が長く、または数百から数千回繰り返す必要があるようなユース ケースも、しばしば存在します。

Databricks プラットフォームのクラスター環境は、これらのワークロードを効率的に分散するのに最適な環境です。 クラスターのすべてのノードで SQL クエリが自動的に並列化され、 Python と Scala が同じ操作を行うためのライブラリが提供されます。 内部では、Apache Spark と Photon の 2 つのエンジンがクエリを分析し、最適な並列実行の方法を判断して、回復性のある方法で分散実行を管理しています。

バッチ タスクと同じ方法で、 構造化ストリーミング は、ストリーミング ジョブをクラスター全体に分散して最適なパフォーマンスを提供します。

並列コンピューティングを使用する最も簡単な方法の一つは、Delta Live Tables の使用です。 ユーザーが SQL または Python でジョブのタスクと依存関係を宣言すると、Delta Live Tables が実行計画策定、効率的なインフラストラクチャのセットアップ、ジョブの実行、モニタリングを処理します。

データ サイエンティストにとって、Pandas は、Python プログラミング言語用の使いやすいデータ構造とデータ分析ツールを提供する Python パッケージです。 しかし、Pandas はビッグ データにスケールアウトしません。 Spark 上の Pandas API は、Apache Spark 上で機能する Pandas と同等の API を提供することで、このギャップを埋めています。

さらに、プラットフォームには、標準の機械学習ライブラリ MLlib 内の、並列化された機械学習アルゴリズムが付属しています。 これは、すぐに使用可能な状態で、マルチ GPU をサポートしています。 また、ディープ ラーニングを、DeepSpeed ディストリビューターまたは TorchDistributor を使用して並列化することもできます。

実行のチェーン全体を分析する

ほとんどのパイプラインまたは消費パターンには、システムのチェーンが関係します。 たとえば、BI ツールでは、次のいくつかの要因でパフォーマンスが影響を受けます。

  • BI ツール自体。
  • BI ツールと SQL エンジンを接続するコネクタ。
  • BI ツールがクエリを送信する先の SQL エンジン。

クラス最高のパフォーマンスを実現するには、チェーン全体をパフォーマンスのために考慮および選択/調整する必要があります。

より大きなクラスターを優先する

特にワークロードの拡大が線形的である場合は、より大規模なクラスターを計画します。 この場合、ワークロードに大規模なクラスターを使用しても、小規模なクラスターを使用する場合よりコストが高くなるということはありません。 ただ速くなるだけです。 重要なのは、ワークロードの期間中にクラスターをレンタルするということです。 つまり、2 つのワーカーのクラスターを起動し 1 時間使用した場合は、それらのワーカーに対して 1 時間全部の料金を支払うことになります。 同様に、4 つのワーカー クラスターを起動し 30 分しか使用しないとすれば (この場合は線形スケーラビリティが有益です)、そのコストは同じです。 SLA が非常に柔軟でコストが最も優先される場合には、通常、自動スケーリング クラスターが最も安価になりますが、必ずしも最速であるとは限りません。

Note

サーバーレス コンピューティングでは、大規模なクラスターを優先するのは必須ではありません。この場合、クラスターが自動的に管理されるためです。

ネイティブ Spark 機能を使用する

ユーザー定義関数 (UDF) は、Spark SQL の機能を拡張するための優れた方法です。 ただし、ネイティブ関数が存在する場合は、Python または Scala UDF を使用しないでください。

理由は、次のとおりです。

  • Python と Spark の間でデータを転送するには、シリアル化が必須です。 これにより、クエリの速度が大幅に低下します。
  • プラットフォームに既に存在する機能を実装してテストするための作業が増加します。

ネイティブ関数が欠落しており、Python UDF として実装する必要がある場合は、Pandas UDF を使用します。 Apache Arrow を使用すると、Spark と Python の間でデータの移動が効率的に行われます。

ネイティブのプラットフォーム エンジンを使用する

Photon は Azure Databricks 上のエンジンであり、データ インジェスト、ETL、ストリーミング、データ サイエンス、対話型クエリなど、データ レイク上で直接、低コストで高速なクエリ パフォーマンスを提供します。 Photon は Apache Spark API と互換性があるため、コードを変更することなく、ロックインされることなく、電源を入れるだけで簡単に使い始めることができます。

Photon は、高パフォーマンスのランタイムの一部分であり、ワークロードごとの総コストを削減しながら、既存の SQL と DataFrame API 呼び出しを、より高速に実行します。 Photon は、Databricks SQL ウェアハウスでは既定で使用されます。

ハードウェアとワークロードの種類を理解する

すべてのクラウド VM が同じ作りなわけではありません。 クラウド プロバイダーによって提供されるマシン ファミリーには、どれも重要な差異があります。 RAM とコアには明らかな違いがあり、プロセッサの種類と生成、ネットワーク帯域幅の保証、ローカル高速ストレージとローカル ディスクとリモート ディスクといった細かい違いもあります。 「スポット」市場にも違いがあります。 ワークロードに最適な VM の種類を決める前に理解しておく必要があります。

Note

これは、サーバーレス コンピューティングでは必要ありません。サーバーレス コンピューティングではクラスターが自動的に管理されます。

キャッシュを使用する

キャッシュでは、頻繁にアクセスされるデータは高速なメディアに格納されるため、元のデータ ソースにアクセスする場合と比較して、取得に必要な時間が短縮されます。 これにより、待機時間が短くなり、より迅速な応答時間が実現され、アプリケーションの全体的なパフォーマンスとユーザー エクスペリエンスが大幅に向上します。 元のデータ ソースへの要求の数を最小限に抑えることで、キャッシュは、ネットワーク トラフィックとデータ転送コストを削減するのに役立ちます。 この効率の向上は、外部 API または従量課金制データベースに依存するアプリケーションに対し、特にメリットとなります。 これにより、システム全体に負荷をより均等に分散させ、ボトルネックや潜在的なダウンタイムを防ぐことができます。

Azure Databricks では、いくつかの種類のキャッシュを使用できます。 それぞれの種類には、次の特徴があります。

  • ディスク キャッシュを使用する

    ディスク キャッシュ (旧称「Delta キャッシュ」) は、仮想マシンのローカル ディスク (SSD など) にリモート データのコピーを格納します。 これは、さまざまなクエリのパフォーマンスを向上させることができますが、任意のサブクエリの結果を保存するために使用することはできません。 ディスク キャッシュは、データ ファイルが作成または削除されるタイミングを自動的に検出し、それに応じて内容を更新します。 ディスク キャッシュを使用するために推奨される (そして最も簡単な) 方法は、クラスターを構成する際に、SSD ボリュームを使用するワーカーの種類を選択することです。 このようなワーカーは、ディスク キャッシュ用に有効にされ、構成されます。

  • Spark キャッシュを避ける

    Spark キャッシュには、(.persist() と .unpersist() を使用することで) サブクエリ データの結果および Parquet 以外の形式 (CSV、JSON、ORC など) で保存されているデータを保存できます。 ただし、クエリ内の間違った場所で使用すると、すべてのメモリが消費され、クエリの速度も大幅に低下する可能性があります。 経験則としては、その影響を正確に把握していない限り、Spark キャッシュは避けるようにします。

  • クエリ結果キャッシュ

    SQL ウェアハウスを介したすべてのクエリに対するクラスターごとの、クエリ結果のキャッシュです。 クエリ結果のキャッシュの恩恵を受けるには、たとえば、= NOW() のような述語を使用しない決定論的なクエリに焦点を当てます。 クエリが決定論的で、基になるデータが Delta 形式で変更されていない場合、SQL Warehouses はクエリ結果キャッシュから直接結果を返します。

  • Databricks SQL UI キャッシュ

    すべてのクエリとレガシ ダッシュボードの結果の、ユーザーごとのキャッシュは、Databricks SQL UI で取得できます。

圧縮を使用する

Delta Lake on Azure Databricks では、テーブルからの読み取りクエリの速度を向上できます。 1 つの方法は、小さなファイルを、より大きなファイルに結合することです。 圧縮をトリガーするには、OPTIMIZE コマンドを実行します。 「データ ファイル レイアウトを最適化する」を参照してください。

Delta Lake には、書き込みや OPTIMIZE 操作のために、ターゲット ファイル サイズを自動で構成するオプションがあります。 Azure Databricks は、これらの設定の多くの調整と、適切なファイル サイズを見つけてテーブルのパフォーマンスを自動的に向上させる機能の有効化を、自動的に行ないます。

  • 自動圧縮では、Delta テーブル パーティション内の小さなファイルを結合し、小さなファイルの問題を自動的に軽減します。 自動圧縮は、テーブルへの書き込みが成功した後に発生し、その書き込みを実行したクラスター上で同期的に実行されます。 自動圧縮は、前に圧縮されていないファイルのみを圧縮します。
  • 最適化された書き込みでは、データ書き込み時にファイル サイズを改善し、テーブルの後続の読み取りを向上させます。 最適化された書き込みは、各パーティションに書き込まれる小さなファイルの数を減らすため、パーティション テーブルに最も効果的です。

詳細については、「データ ファイル サイズを制御するように Delta Lake を構成する」を参照してください。

データ スキップを使用する

データのスキップでは、クエリ条件を満たしていないデータをスキップすることで、クエリのパフォーマンスを大幅に向上させることができます。 これにより、読み取りと処理が必要なデータの量が削減されるので、クエリの実行時間の短縮につながります。

これを実現するために、Delta テーブルへのデータ書き込時に、データ スキップ情報が自動的に収集されます (既定では、Delta Lake on Azure Databricks が、テーブル スキーマで定義されている最初の 32 列の統計情報を収集します)。 Delta Lake on Azure Databricks では、クエリ時にこの情報 (最小値と最大値) を利用してクエリを迅速化します。 「Delta Lake に対するデータのスキップ」を参照してください。

最良の結果を得るには、同じファイル セットに関連情報を併置する手法である、Z オーダーを使用します。 この併置は、Delta Lake のデータのスキップ アルゴリズムによって、Azure Databricks 上で自動的に使用されます。 この動作により、Delta Lake が読み取る必要があるデータ量が大幅に削減されます。

または、新しい リキッド クラスタリング を使用します。これで、データ レイアウトの決定が簡略化され、クエリのパフォーマンスが最適化されます。 パーティション分割と Z オーダーが、時間の経過とともに置き換えられます。 Databricks では、すべての新しい Delta テーブルに対してリキッド クラスタリングが推奨されています。 リキッド クラスタリングでは、既存のデータを書き換えることなくクラスタリング キーを再定義できる柔軟性が提供されており、時間の経過と共に分析ニーズに沿ってデータ レイアウトを発展させることができます。 Databricks では、すべての新しい Delta テーブルに対してリキッド クラスタリングが推奨されています。

次のような特性を持つテーブルについて、リキッド クラスタリングには利点があります。

  • カーディナリティが高い列でフィルター処理されている。
  • 大幅に歪んだデータ分散が含まれている。
  • 拡大が急速で、メンテナンスとチューニングの作業を必要とする。
  • 同時書き込み要求がある。
  • アクセス パターンが時間の経過と共に変化する。
  • 一般的なパーティション キーでは、パーティションが多すぎるか、少なすぎるテーブルが残ってしまう可能性がある。

詳細と手法については、「Databricks、Spark、Delta Lake のワークロードを最適化する包括的ガイド」を参照してください。

Delta Lake の予測最適化を有効にする

予測最適化は、Databricks での Delta テーブルのメンテナンス操作を、手動で管理する必要性を除去します。 予測最適化を有効にすると、Azure Databricks はメンテナンス操作が有益なテーブルを自動的に特定し、その操作をユーザーの代わりに実行します。 メンテナンス操作は必要な場合にのみ実行されるため、メンテナンス操作のための不必要な実行と、パフォーマンスの追跡やトラブルシューティングに関連する負担の両方が排除されます。

過剰なパーティション分割の回避

以前は、パーティション分割がデータをスキップするための最も一般的な方法でした。 ただし、パーティション分割は静的であり、それ自体がファイル システムの階層となるものです。 アクセス パターンが時間的に変化しても、パーティションを簡単に変更する方法はありません。 過剰なパーティション分割 (言い換えると、小さ過ぎるファイルでの多過ぎるパーティション分割) が行わた場合、しばしば、クエリのパフォーマンス低下を引き起こします。

Databricks では、サイズが 1 TB 未満のテーブルはパーティション分割しないことと、各パーティションのデータが 1 GB 以上になると予想される場合は、列ごとにパーティション分割することが推奨されています。

一方、Z オーダーまたは新しいリキッド クラスタリング (上記参照) は、パーティション分割に比べて良い選択肢です。

結合のパフォーマンスを最適化する

  • 範囲結合の最適化を検討する。

    "範囲結合" は、2 つのリレーションが間隔内のポイントまたは間隔の重複条件を使用して結合されるときに実行されます。 Databricks Runtime での範囲結合の最適化サポートでは、クエリのパフォーマンスが桁違いに向上される可能性がありますが、手動での慎重なチューニングが必要とされます。

  • アダプティブ クエリの実行を使用する。

    アダプティブ クエリ実行 (AQE) は、クエリの実行中に行われるクエリの再最適化です。 4 つの主要な機能があります。

    • 並べ替えマージ結合をブロードキャスト ハッシュ結合に動的に変更します。
    • シャッフル交換後にパーティションが動的に結合されます。
    • 並べ替えマージ結合とシャッフル ハッシュ結合の傾斜を動的に処理します。
    • 空の関係を動的に検出して伝達します。

    AQE は有効のままにしておくことをお勧めします。 異なる機能を 個別に構成できます。

詳細については、「Databricks、Spark、Delta Lake のワークロードを最適化する包括的ガイド」を参照してください。

ANALYZE TABLE を実行してテーブル統計を収集する

ANALYZE TABLE ステートメントは、指定されたスキーマ内のテーブルに関する統計情報を収集します。 これらの統計はクエリ オプティマイザーによって使用され、最適なクエリ プランの生成、正しい結合の種類の選択、ハッシュ結合での正しいビルド側の選択、または複数手法の結合においての結合順序の較正が行なわれます。

これらのクエリの最適化を適切に活用するには、 ANALYZE TABLE コマンドを定期的に (できれば 1 日に 1 回、またはデータが 10% を超えて変更された場合のいずれか早い方で) 実行する必要があります。

4.開発の範囲内でパフォーマンス テストを実行する

本番データを代表するデータでのテスト

本番データ (読み取り専用) または類似のデータに対してパフォーマンス テストを実行します。 類似のデータを使用する場合、パフォーマンスに大きな影響を与える特性 (ボリューム、ファイル レイアウト、データ スキューなど) は、本番環境のデータと同様にする必要があります。

リソースの事前ウォーミングを検討する

クエリとデータの形式に関係なく、クラスターでの最初のクエリは、常に後続のクエリよりも遅くなります。 これは、すべての異なるサブシステムが起動され、必要なすべてのデータを読み取っているためです。 事前ウォーミングは、パフォーマンス テストの結果に大きな影響を与えます。

  • クラスターの事前ウォーミング: クラスター リソースは、複数のレイヤーで初期化される必要があります。 Databricks プール が、アイドル状態ですぐに使用できるインスタンスのセットの場合に、クラスターの事前ウォーミングを使用できます。 これらアイドル状態のインスタンスを使ってクラスター ノードを作成すると、クラスターの起動時間と自動スケーリング時間が短縮されます。
  • キャッシュの事前ウォーミング: キャッシュが起動処理の一部である場合、最初の実行がキャッシュ内にデータがあることを確認するので、後続のジョブが高速化されます。 キャッシュの事前ウォーミングは、(クラスターの再起動後などに) キャッシュを初期化する特定のクエリを実行することで行なえます。 これにより、最初のいくつかのクエリのパフォーマンスを大幅に向上させられます。

さまざまなシナリオでの動作を理解するには、最初の (事前ウォーミングがある場合とない場合の) 実行と、その後の実行のパフォーマンスをテストします。

ボトルネックの特定

ボトルネックとは、運用環境における負荷の増加に伴って全体的なパフォーマンスを低下させる可能性がある、ワークロード内の領域のことです。 設計時にこれらを特定し、より高いワークロードに対してテストを行うことで、本番環境でワークロードを安定させるのに役立ちます。

5.パフォーマンスの監視

クエリ パフォーマンスを監視する

クエリのパフォーマンスのモニタリングは、さまざまなクエリでリソースがどのように使用されているかを理解するのに役立ちます。 実行速度が遅いクエリを特定できるため、システムのパフォーマンス ボトルネックを特定できるようになります。 また、大量のシステム リソースを消費していて、不安定性またはダウンタイムを引き起こす可能性があるクエリを特定できます。 この情報は、リソース割り当ての最適化や無駄の削減に役立ち、リソースが効率的に使用されることを保証します。

Databricks Data Intelligence プラットフォームには、モニタリングのさまざまな機能が備わっており (「オペレーショナル エクセレンス - モニタリング、アラート、ログを設定する」を参照)、その一部はパフォーマンスの監視に使用できます。

  • クエリ プロファイル: クエリの実行時におけるパフォーマンスのボトルネックをトラブルシューティングするには、クエリ プロファイル機能を使用します。 これは、各クエリ タスクと関連メトリック (所要時間、処理された行数、使用メモリなど) を可視化します。
  • SQL ウェアハウス のモニタリング: ライブ統計、ピーク時のクエリ数のグラフ、実行中のクラスター数のグラフ、クエリ履歴テーブルを表示して SQL ウェアハウスをモニターします

ストリーミング ワークロードをモニターする

ストリーミングをモニタリングすると、データを分析し、発生した時点で問題を検出できるので、システムのパフォーマンスと動作に関するリアルタイムの分析情報が提供されます。 ストリーミング データを分析することで、傾向、パターン、および最適化の機会を特定できます。 これは、システムの微調整に役立ち、リソース使用率を向上させ、コストを削減します。

ストリーミング クエリの場合は、Spark UI で 組み込みの構造化ストリーミング モニタリングを使用するか、Apache Spark ストリーミング クエリ リスナー インターフェイスを使用して、メトリックを外部サービスにプッシュします。

ジョブのパフォーマンスを監視する

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