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

LakeFlow ジョブのパフォーマンスを診断

ジョブまたはタスクが予想よりも長くかかるときは、ジョブUIを使用して時間の使途を把握し、それを短縮する方法を検討してください。このページでは、サーバレスジョブの実行の内訳、ストリーミングタスクのメトリクス、およびクエリーパフォーマンスのメトリクスについて説明しています。ジョブ実行を検索して開くには、LakeFlowジョブの監視を参照してください。

フェーズごとの実行の内訳を表示

実行の内訳は、ジョブまたはタスクの実行が時間を費やす場所を示しています。ジョブ実行の詳細を表示すると、実行の**継続時間**にホバーして、次のフェーズに分解された合計継続時間を確認できます:

  • キューのステータス:
  • リソースを待機中
  • ライブラリのインストール
  • 実行中

ジョブ実行の内訳

実行の内訳は、ジョブ実行とタスク実行の両方で利用できます。複数のタスクを含むジョブでは、ジョブレベルの内訳は、最初のタスクが実行を開始するまでの間のみ Waiting for リソース をカウントします。各タスクの完全な内訳を表示するには、タスク実行の出力で実行の内訳を表示します。

内訳を使用して、どのフェーズに最も時間がかかっているかを特定し、次のセクションを使用して考えられる原因と時間を短縮するためにできることを理解してください。

注記

パイプラインタスクには、ほとんどのタスクとは異なるフェーズがあります。それらは次のとおりです:作成済み、リソース待機中、初期化中、テーブルセットアップ中、実行中。初期化とテーブルセットアップにかかる長い時間を短縮する方法については、パイプラインの長い初期化時間を修正するを参照してください。

キューに入っているフェーズ

ジョブまたはタスクは、並列性の上限により開始を待機しています。

考えられる原因:

  • 同じジョブの以前の実行がまだ進行中のため、ジョブが最大並列実行数に達しました。
  • 同時に実行されている他のジョブが、ワークスペースレベルの並列実行制限に達しました。

できること

  • ジョブの最大並列実行設定を増やしてください。
  • 重複を減らすために、ジョブのスケジュールを確認してください。ジョブが継続的にリソースを競合する場合は、開始時間をずらすことを検討してください。詳細については、Databricks リソース制限を参照してください。

リソース待機フェーズ

ジョブまたはタスクは、実行を開始する前にコンピュートが利用可能になるのを待っています。待機時間を短縮するためにできることは、コンピュートの種類によって異なります。

クラスタータイプ

考えられる原因

できること

サーバーレス

サーバレスジョブは標準パフォーマンスモードを使用します。このモードは、コンピュートの可用性、およびSparkの使用状況によって、起動レイテンシーが4~6分となります。

起動時間を短縮するには、「パフォーマンス最適化モード」に切り替えます。

クラシック

  • VMの起動時間が遅いです。
  • クォータ超過または容量不足により、クラスターの起動が遅延しています。
  • クラスターまたはコンピュートの設定を管理することなく起動時間を最適化するには、ジョブをサーバレスに移行することを検討してください。
  • VMの起動時間が遅い場合は、スケジュールされたジョブ間のギャップを埋めるために、アイドルインスタンスの自動終了を備えたインスタンスプールを設定してください。「プールのベストプラクティス」も参照してください。
  • 連続したジョブを、単一のマルチタスクジョブ内のタスクとしてグループ化します。ジョブ内のタスクは、実行期間中同じクラスターを共有するため、繰り返し発生するクラスターの起動を回避できます。これは、連続したジョブの実行や、ジョブタスク間でクラスターを再利用できないサードパーティのオーケストレーターと比較して、大幅な高速化をもたらすことができます。
  • クォータと容量の問題を処理するために、フレキシブルノードタイプを有効にして、優先タイプが利用できない場合にDatabricksが互換性のあるインスタンスタイプに自動的にフォールバックするようにしてください。一貫してクォータ上限に達する場合は、クラウドプロバイダーにクォータの引き上げをリクエストすることもできます。

ライブラリのインストールフェーズ

ジョブは、実行を開始する前にライブラリのインストールに時間を費やしています。

クラスタータイプ

考えられる原因

できること

サーバーレス

  • Databricksはまだ環境をキャッシュしておらず、作成する必要があります。
  • ジョブは多くのパッケージをインストールします。
  • 特に多くのタスクがパッケージを並行してインストールする場合、カスタムPyPIリポジトリの応答が遅くなる可能性があります。
  • 必要なパッケージの数を減らします。
  • ワークスペースの基本環境の使用をご検討ください。

クラシック

クラスターで定義された環境の規模と複雑さのため、ライブラリのインストールに時間がかかります。特に、クラスター起動時にinitスクリプトを使用してライブラリをインストールする場合に顕著です。

ジョブが実行に必要なパッケージのみを使用していることを確認してください。

実行フェーズ

実行は、多くの理由により予想よりも時間がかかる場合があります。次のリストはすべてを網羅しているわけではありませんが、一般的な原因と可能性のある対処法をいくつかカバーしています。

考えられる原因:

  • データ量が増加したため、ランタイムが長くなることが予想されます。
  • ジョブまたはコンピュートの設定が変更されました。
  • コードの変更により、クエリの速度低下や非効率的な操作が発生しました。

できること

  • Databricks システムテーブル (たとえば、ジョブシステムテーブルコンピュートシステムテーブル) を使用して、最近の変更を確認してください。
  • サーバレスジョブの場合は、クエリー履歴を使用して最も時間がかかったクエリーを見つけ、それらのクエリープロファイルを開いて最適化の機会を特定してください。関連するクエリーを見つけるには、各タスクの**コンピュート**セクションにあるリンクを使用するか、クエリープロファイルと統合されているジョブのタイムラインビュー を開いてください。
  • クラシックコンピュートで実行されているジョブの場合、遅いステージとタスクを診断するには、Spark UIを使用します。イベントタイムラインから、長時間実行されているジョブ、アイドル状態のギャップ、または失敗を特定し、個々のステージとタスクを詳しく調べてください。

サーバレスジョブの場合、追加のタスクメトリクス(パブリックプレビュー)とクエリパフォーマンスメトリクス(ベータ版)を取得できます。

ストリーミングタスクのメトリクスを表示

備考

プレビュー

Lakeflowジョブのストリーミング オブザーバビリティは パブリック プレビュー段階です。

LakeFlow Jobs UIは、**ジョブ実行の詳細**ページで、ストリーミングワークロードのストリーミング可観測性メトリクスを提供します。これらのメトリクスには、Apache Kafka、Amazon Kinesis、Auto Loader、Google Pub/Sub、およびDeltaテーブルを含む、Spark構造化ストリーミングでサポートされているソースのバックログ秒数、バックログバイト数、バックログレコード数、およびバックログファイルが含まれます。タスクの実行詳細を表示すると、メトリクスが右側のペインにグラフとして表示されます。各グラフは、過去48時間までの最大値を分単位で集計して表示します。

各ストリーミングソースは、特定のメトリクスのみをサポートしています。UIには、ストリーミングソースがサポートしているメトリクスのみが表示されます。以下の表に、サポートされているストリーミングソースで利用可能なメトリクスを示します。

source

バックログバイト

バックログレコード

バックログ秒

バックログファイル

Kafka

Kinesis

Delta

Auto Loader

Google Pub/Sub

各ストリーミングメトリクスごとにしきい値を指定し、タスクの実行中にストリームがしきい値を超えた場合に通知を設定することもできます。低速ジョブの通知を構成するを参照してください。

サポートされている構造化ストリーミング ソースのいずれかからデータをストリームするタスク実行のストリーミング メトリクスを表示するには:

  1. **ジョブ実行の詳細**ページで、メトリクスを表示するタスクをクリックします。
  2. タスク実行 ペインの メトリクス タブをクリックします。
  3. メトリクスのグラフを開くには、メトリクス名の横にある 右キャレット をクリックします。
  4. 特定のストリームのメトリクスを表示するには、 Filter by stream_id テキストボックスにストリーム ID を入力します。ストリーム ID は、ジョブ実行の出力で見つけることができます。
  5. メトリクスグラフの期間を変更するには、時間のドロップダウンメニューを使用します。
  6. 実行に10個を超えるストリームが含まれている場合、ストリーム間を移動するには、「**次へ**」または「**前へ**」をクリックします。

ストリーミングのオブザーバビリティの制限事項

  • Databricksは、実行に4つを超えるストリームがない限り、メトリクスを毎分更新します。実行に4つを超えるストリームがある場合、Databricksはメトリクスを5分ごとに更新します。
  • Databricks は、各実行で最初の50のストリームについてのみメトリクスを収集します。
  • Databricksは1秒間隔でメトリクスを収集します。triggerInterval設定が1秒未満の場合、メトリクスが表示されない可能性があります。
  • ほとんどのデータソースは、デフォルトでストリーミングメトリクスを収集します。ただし、その他の場合は、この機能を有効にする必要があります。データソースがストリーミングメトリクスを収集していない場合は、spark.sql.streaming.metricsEnabled フラグを True に設定します。

サーバレスジョブのクエリパフォーマンスのメトリクスを表示

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

サーバレスジョブを実行すると、Databricks は選択された Query Profile メトリクスと パフォーマンスの知見 をジョブ実行 UI に直接表示するため、クエリごとに個別のクエリ プロファイルを開かなくてもパフォーマンスの問題を特定できます。これらのメトリクスを使用して、実行が遅い理由を調査したり、2 つの実行間のパフォーマンスを比較したりできます。

これらのメトリクスを表示する前に:

  • **Lakeflowのパフォーマンスオブザーバビリティの改善**プレビューは、ワークスペースで有効にする必要があります。 ワークスペース管理者は、プレビューページから有効にできます。
  • ワークスペースは、クエリパフォーマンスの知見にアクセスできる必要があります。それがなければ電球インジケーターは表示されませんが、集計メトリクス(読み取られた行、書き込まれた行、合計クエリ数)は引き続き表示されます。

Databricksは、サーバレスジョブの実行におけるクエリから集計された次のメトリクスを表示します。

  • タスク実行ごとの**読み取り行数**と**書き込み行数**。
  • タスク実行ごとの**[クエリーの総数]**。
  • タスク内の1つ以上のクエリにパフォーマンスに関する知見がある場合に、タスクに表示される**パフォーマンスインサイトインジケーター**(電球)。

これらのメトリクスは、実行の表示方法に応じて異なる場所に表示されます。

表示される場所

表示される内容

タスク 実行 サイドバー

読み書きされた行、合計クエリ数、およびタスク実行に関する知見のインジケーター。

DAGビュー

タスクのクエリーにパフォーマンスに関する知見がある場合、タスクノードに電球バッジが表示されます。

タイムライン ビュー

タスク名横の電球アイコンには、タスクのクエリー全体の知見の数が表示され、さらに知見を含むタスク内の各クエリーにも電球アイコンが表示されます。

リストビュー

タスクのクエリにパフォーマンスに関する知見がある場合に、 [知見] 列に電球アイコンが表示されます。この列が表示されない場合は、列ピッカーから追加してください。

注記

このベータ版の一部として、シングルタスクジョブのタイムラインビューが利用可能になりました。以前は、マルチタスク ジョブのみがタイムライン ビューを持っていました。

クリックとホバーの動作:

  • タイムラインビュー 」で、タスクにカーソルを合わせると、その集約メトリクスとタスクのクエリーに関するパフォーマンスの知見が表示されます。
  • **[DAG ビュー]** または **[リスト ビュー]** で、タスクの電球アイコンをクリックすると、そのタスクのクエリーが展開された**[タイムライン ビュー]** が開きます。
  • **タイムラインビュー**で、電球の付いたクエリの**クエリテキスト**をクリックすると、そのクエリのパフォーマンスに関する知見の概要を示すペインが開きます。

サーバレスジョブの実行が予想よりも遅い理由を調査するには:

  1. ジョブ実行を開きます。

  2. 「**タイムラインビュー**」に切り替えます。

  3. 期間分布に基づいて、予想よりも時間がかかっているタスクを特定します。

  4. 長時間実行されるタスクにカーソルを合わせると、以下が表示されます。

    • 読み取られた行数書き込まれた行数 : タスクが通常よりも多くのデータを処理したかどうかを確認してください。
    • **クエリーの総数**:ワークロードの形状の変化を特定します。
    • The パフォーマンス知見インジケーター :リグレッションまたは非効率なコード変更を特定します。
  5. データ量が多いことが処理時間の増加の原因である場合、処理速度の低下は予期される可能性があります。そうでない場合は、タイムラインでタスクを展開して、個々のクエリを確認します。知見が検出されたクエリの横には、電球が表示されます。

  6. 電球アイコンの付いたクエリの「 クエリテキスト 」をクリックすると、そのクエリのパフォーマンスに関する知見が表示されたペインが開きます。

  7. 推奨される変更を適用し、ジョブを再実行して問題が解決されたことを確認します。

知見の完全なリストとそれが何を意味するのかについては、「クエリパフォーマンスのインサイト」を参照してください。より詳細なクエリ実行の詳細については、「クエリプロファイル」を参照してください。

ヒント

2つの実行を比較

これらの同じメトリクスにより、遅い実行と以前の速い実行の違いを簡単に見つけることができます。両方の実行を並べて開き、比較します。

  • 読み取られた行書き込まれた行 を使用して、データ量の変更を特定します。
  • ワークロードの形状の変化を特定するための**[クエリーの総数]**。
  • 前回の実行以降に発生した非効率性を特定する ためのパフォーマンス知見

クエリーパフォーマンスメトリクスの制限

  • これらのメトリクスと知見は、サーバレス LakeFlowジョブにのみ適用されます。クラシック コンピュートで実行されるジョブには、この情報は表示されません。
  • Databricks はジョブ実行の**最初の 100 クエリ**にわたってメトリクスを集計します。実行にそれ以上のクエリがある場合、合計は最初の 100 件のみを反映します。