Databricksクラスターメトリクスの解読: 解釈と対策のガイド

Posted at 2025-06-03

Decoding Databricks Cluster Metrics: A Guide to In... - Databricks Community - 120215の翻訳です。

本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

ビッグデータ分析の領域において、Databricksは大規模なデータセットを効率的に管理、処理するための最先端のプラットフォームとなりました。Databricksランタイムはすぐに利用でき、高度に最適化されており、サーバレスコンピュートのような機能はさらにクラスター管理をシンプルにしますが、クラスターメトリクスの理解は、特定のシナリオにおける高度なトラブルシュートやファインチューンにおいて依然として重要なものとなっています。

このブログ記事では、特にDatabricksクラスターにおけるハードウェアメトリクス(CPU、メモリー、ネットワーク使用率など)とSparkメトリクス(タスク実行、シャッフルオペレーションなど)の解読にフォーカスします。GPU有効化クラスターにおける特殊な機械学習ワークロードではGPUメトリクスを利用できますが、この議論の範疇外とします。

この記事の最後までには、これらのキーとなるメトリクスに対する深い理解と、それらの解釈や最適化に関する実践的な戦略を手に入れることができ、お使いのDatabricksクラスターを最も効率的で最適化された方法で、ワークロードを実行するように適切に利用できるようにします。

それでは、それぞれのセクションを深く見ていきましょう。

Databricksクラスターメトリクスの概要

Databricksクラスターのメトリクスは、パフォーマンスの監視、ボトルネックの特定、リソース使用の最適化において重要なものです。これらのメトリクスは、あなたのクラスターがどのように動作しているのかに関する洞察を提供し、スケーリング、設定、タスクの最適化に関して、情報に基づいた意思決定を行う助けとなります。このメトリクスはニアリアルタイムで更新され、通常は1分以内の遅延です。汎用とジョブコンピュートの両方で利用でき、これらのメトリクスはお客様のストレージではなく、Databricks管理のストレージに格納されます。現時点のメトリクスシステムは、かつてのGanglia UIと比較してクラスターリソース使用に関してより包括的なビューを提供します。この強化された可視性によって、データエンジニアやプラットフォームチームは、パフォーマンスのパターンをより理解し、クラスターの効率性を最大化することができます。

メトリクスへのアクセス

これらのメトリクスを参照するには、サイドバーの「コンピュート」セクションに移動し、対象のコンピュートリソースを選択し、「メトリクス」タブをクリックします。デフォルトではハードウェアメトリクスが表示されますが、ユーザーはドロップダウンメニューを用いて、SparkメトリクスやGPUメトリクス(GPU有効化インスタンスの場合)に表示を切り替えることができます。過去のメトリクスを参照するために、最大過去30日まで様々な日付けレンジでフィルタリングすることができます。

Databricksクラスターメトリクスの理解

ハードウェアメトリクス

コンピュートや個々のドライバー/ワーカーレベルで監視可能なハードウェアメトリクスは、お使いのクラスターノードの物理的なパフォーマンスの評価で重要となります。これらのメトリクスを理解することで、リソースのボトルネックを特定したり、クラスターの設定を最適化することができます。

CPU使用率

CPU使用率は、あなたのクラスターの処理能力に直接影響を与えるので最も重要なメトリクスの一つとなります。CPU使用率における様々なモードの理解が重要です:

User Mode: Databricksノートブックにおけるスクリプトの実行、クエリーの実行、計算処理の実行のようなアプリケーションレベルの処理を含む、ユーザーレベルのコードの実行に費やされたCPU時間を表現します。ここには、通常ほとんどのアプリケーションロジックが含まれることになります。
System Mode: メモリーの管理、I/Oリクエストの対応、ハードウェアとのやり取りのようなカーネルレベルのオペレーションを含むシステムレベルのコードに費やされたCPU時間を表現します。
Idle Mode: 処理するアクティブなタスクがない場合のアイドル状態に費やされたCPU時間を表現します。
IOWait Mode: I/Oオペレーション(ディスクの読み書きなど)の完了まで待ち時間に費やされたCPU時間を表現します。
その他のモード: Databricksは以下を含む他のCPU使用モードを追跡します:
- irq (割り込みリクエストに消費された時間)
- softirq (ソフトウェア割り込みリクエストに費やされた時間)
- nice (低優先度プロセスに費やされた時間)
- steal (他のVMがあなたのCPUから奪った時間)

解釈と対策:

高いCPU使用率が常に悪いわけではありません。クラスターが最適に利用されていることも示しています。しかし、85-90%以上の定常的な高い使用率は、処理能力でタスクが競合しているボトルネックを示している場合もあります。
- インスタンスのスケールアップ: CPU使用率が定常的にたい場合には、ワークロードを分散させるためにノード数を増やすかよりパワフルなクラスターインスタンスにアップグレードすることが必要かもしれません。
高いIOWaitは、シャッフルファイルの読み書きやストレージからの大規模なデータセットの読み込みのように、遅いディスクI/Oオペレーションによってタスクがボトルネックになっていることを示しています。
- より高速な読み書きのために Delta Lake を用いることで、データストレージフォーマットを最適化しましょう。
- Deltaテーブルのデータレイアウトを最適化するためにOPTIMIZE テーブル名を使うか、DatabricksにおけるUnity Catalog管理のテーブルのメンテナンスオペレーションを手動で管理する必要をなくしてくれる予測的最適化を用いましょう。
- z-orderかリキッドクラスタリングのようなデータスキッピングテクニックを用いることで、ストレージからスキャンするデータの総量を減らしましょう。
- シャッフルを回避するように、小規模なデータセットには broadcast join を使いましょう。
- シャッフルオペレーションの際のディスクI/Oに影響を与える重要な要素は、Sparkプロパティのspark.sql.shuffle.partitionsです。この設定は、joinや集計のような幅広の変換処理においていくつのパーティションが作成されるのかを制御します。
シャッフルパーティションが低すぎる数に設定されている場合、それぞれのパーティションは大きくなり、データがメモリーに収まらなくなり、ディスクに溢れる可能性が高まります。このディスク溢れは、タスクがメモリー内で処理を行うのではなく、ディスクの読み書きに多くの時間を費やすことになるので、高いIOWaitを引き起こします。逆に、パーティションの数を多く設定してしまうと、タスクのスケジューリングや調整コストの増加による、また別の方法でパフォーマンスにインパクトを与えることになる、膨大な小規模なタスクの管理からの過度のオーバーヘッドにつながります。

spark.sql.shuffle.partitionsのチューニングはこれらのトレードオフのバランスの助けとなります:
- -> 少なすぎるパーティション: 大規模なパーティション、更なるディスク溢れ、高いIOWait。
- -> 多すぎるパーティション: スケジューリングのオーバーヘッドの増加。
あるいは、パーティションを自動調整するためにAQE(Apache Spark™ 3.2.0以降ではデフォルトで有効化されています)を用いるか、クエリー計画とクエリーの入力データサイズに基づいて、この数値を自動で決定することでシャッフルの自動最適化を行うように、Sparkプロパティspark.sql.shuffle.partitionsをautoに設定します。
高いアイドル時間はクラスターリソースが利用されていないことを意味している場合があり、クラスターが過剰に配備されており、クラスターをダウンサイズできる可能性を示しています。
- ワークロードの需要に基づいてワーカーの数を動的に調整する オートスケーリングを有効化 します。
  - 注意: SparkはCPU使用率が低いからといって常にアイドル状態であるとは限りません。さらに調査するには、Spark UIをチェックしましょう。
- インタラクティブクラスターでは、アイドル時間を削減するために自動停止の値を設定することができます。

メモリー使用率

適切なメモリー管理によって、スムーズなワークロード実行を確実にし、メモリー不足(OOM)エラーを回避し、クラスターの安定性を維持することができます。

Used Memory: Sparkのエグゼキューターとワーカーを含むプロセスに現在割り当てられているメモリーを表現します。
Free Memory: 割り当て可能なメモリーの総量を示します。高いFree Memoryはリソースが利用されていないことを示す場合があります。
Buffer Memory: I/Oオペレーションの過程で一時的にデータを格納するバッファによって使用されるメモリーを表現します。
Cached Memory: 繰り返しのディスクI/Oを回避することで読み込み性能を改善するために、データのキャッシュのために割り当てられたメモリーを表現します。

解釈と対策:

定常的に高いメモリー使用率は、あなたのワークロードがメモリーを大量に必要としているか、大量のメモリーが使用されていることに非効率性(大規模なシャッフルや膨大なデータのキャッシュなど)が存在している可能性があることを示している場合があります。
定常的にフリーメモリーが低い場合、当該クラスターがキャパシティの限界に近づいており、ワークロードのピークの際にOOMエラーのリスクが増加させていることを意味する場合があります。
- メモリーの増強: メモリーを大量に必要とするタスクに対応可能なより高いRAMキャパシティを持つように、あなたのクラスターのインスタンスタイプをアップグレードしましょう。
バッファメモリーの高い使用率は、シャッフルファイルの書き込みやストレージからの大規模データセットの読み込みのような、頻繁なI/Oオペレーションを示している場合があります。
- 対策に関しては、CPU使用率の高IOWaitセクションで議論されたのと同じアプローチに従います。上をご覧ください。
パフォーマンスの改善にはキャッシュメモリーは有益ですが、過度のキャッシュは特に不必要に大規模なデータがキャッシュされると、メモリーの取り合いにつながる場合があります。
- df.cache()やdf.persist()の後にdf.unpersist()を使うことで、頻繁にアクセスされるデータセットのみをキャッシュすることによる 選択的キャッシュ を用いましょう。
  - 注意: よりキャッシュを理解し、いつキャッシュを用いるべきかを理解するにはこちらを参照ください。

ネットワークメトリクス

ネットワークメトリクスは、Databricksクラスターにおけるデータ転送アクティビティの監視で重要となります。これらは、クラスターノードによって送受信されるデータのボリュームに対する洞察を提供し、非効率的なデータ移動やネットワーク渋滞によって引き起こされるボトルネックを特定する助けとなります。

Received Data: クラスターノードによってネットワークを通じて受信されるデータの合計ボリュームを表現します。
ransmitted Data: クラスターノードによってネットワークを通じて送信されるデータの合計ボリュームを表現します。

解釈と対策:

高いネットワーク使用量は、頻繁な大規模シャッフルオペレーションやリージョン横断のデータ転送のような非効率的なデータ転送パターンから発生することがあります。これは、ネットワーク渋滞によるタスク実行の遅延につながることがあります。
リージョン間のデータ転送は、あるリージョンにある計算リソースと別のリージョンのストレージに存在するため、外向き通信の追加コストとレイテンシーを発生させます。
- リージョン横断の転送コストを回避するために、計算リソースとストレージリソースは同じリージョンに保持しましょう。

その他のハードウェアメトリクス

その他の重要なハードウェアメトリクスは:

サーバー負荷の分布: ドライバーノードとワーカーのーどの両方を含むクラスターにおける各ノードのCPU使用率を表現します。

解釈と対策:
- ワーカーと比較してドライバーノードの利用率が高い場合、作業がワーカー分散されていない(多くの場合、クラスターメトリクスにおいて青い四角の中で一つの赤い四角で視覚化されます)、あるいはストリーミングジョブにおいて、ドライバーが多すぎるストリームや短いトリガー間隔に圧倒されている場合があります。
  - ドライバーにデータを配置する.collect()のようなオペレーションを避けましょう。
  - ドライバーのリソースを増強する、ストリームの数や設定を最適化するなど、クラスターでのストリームの分割を検討しましょう。
- いくつかのワーカーが他のワーカーよりも過度に使用されている場合、非効率的な並列処理を引き起こすデータの偏りやバランスの悪いパーティショニングを示している場合があります。
  - データのパーティショニングを最適化し、非ストリーミングジョブでの偏りの対応を自動化するためにAdaptive Query Execution (AQE)を活用しましょう。
    - 注意: AQEはバッチクエリーにおいてはDatabricksランタイム(DBR)バージョン7.3以降ではデフォルトで有効化されています。ForeachBatchシンクを用いたストリーミングワークロードでは、非PhotonクラスターではDBR 13.1、PhotonクラスターではDBR 13.2以降でAQEはデフォルトで有効化されます。
ファイルシステムの空き容量: 溢れの管理やディスクキャッシュの両方において重要となる、クラスターノードにおけるすべてのマウントポイントで利用可能なストレージを計測します。

解釈と対策:
- 空き容量が少ないと、中間データがディスクに溢れた際にSparkのオペレーションの失敗を引き越したり、(データ読み込みを加速するために用いられる)ディスクキャッシュの効果を制限する場合があります。
  - 定期的にディスク容量を監視し、溢れを最小化するようにジョブを最適化しましょう(シャッフルパーティションやメモリー設定のチューニングなど)。
  - 読み込みを加速するためには主にディスクキャッシュを活用しましょう。しかし、大規模データセットの不必要な、あるいは繰り返しの読み込みでクラスターを圧倒しないように注意しましょう。
Memory swap utilization: メモリースワップの使用パターンを表現します(バイトで計測されます)。
Number of active nodes: コンピュートクラスターで現在アクティブなノードの数です。

Sparkメトリクス

Sparkメトリクスは、あなたのDatabricksクラスターで実行されているSparkジョブの実行やパフォーマンスに対する重要な洞察を提供します。これらのメトリクスは、非効率性の特定、リソース使用の最適化、スムーズなジョブ実行の確保の助けとなります。ハードウェアメトリクスとは異なり、Sparkメトリクスは個々のノードレベルではなく、コンピュートレベルで集計され、ワークロードのパフォーマンスに対するより広範なビューを提供します。

タスクメトリクス

タスクメトリクスは、Sparkジョブにおける個々のタスクの実行ステータスとパフォーマンスを追跡します。以下が含まれます:

Active Tasks: 特定の時間に実行中のタスクの合計数を表現します。
Total Failed Tasks: 特定の時間間隔において失敗したタスクの合計数を追跡します。
Total Completed Tasks: 特定の時間間隔において、エグゼキューターで成功したタスクの合計数を表現します。
Total Number of Tasks: 特定の時間間隔において実行された全タスク(アクティブ、失敗、完了)を集計します。タスクのボリュームやワークロードの分布に対する全体的なビューを提供します。

解釈と対策:

アクティブなタスクの数が多いことは、クラスターが大規模なワークロードに対応していることを意味する場合があります。しかし、これはタスク実行の遅延やリソース競合につながることになり、非効率的なタスクのスケジューリングや不十分なリソースを示している場合があります。
タスクの失敗率が高い場合、多くの場合はデータの偏り(不均衡なデータ分布)やメモリーの制約、間違った設定のような問題によるものとなります。
- 均等にデータセットを再パーティショニングするか、非常に偏っているキーでソルティングテクニックを用いることでデータの偏りに対応しましょう。

シャッフル読み込み/書き込み

シャッフルオペレーションには、Sparkジョブにおけるノードへのデータの再配分が含まれます。キーとなるシャッフルメトリクスには以下が含まれます:

Shuffle Read: シャッフルオペレーションで読み込まれたデータの合計サイズを表現します。
Shuffle Write: シャッフルオペレーションで書き込まれたデータの合計サイズを表現します。

解釈と対策:

シャッフルの読み書きサイズが多い場合、ディスクI/Oとネットワークトラフィックの増加によって、パフォーマンスに重大な影響を与えます。
- フィルタリングとプロジェクションを通じて シャッフルデータを削減 しましょう。シャッフルステージに投入されるデータボリュームを削減するために、あなたのクエリーで可能な限りフィルター(WHERE句など)を適用し、シャッフルの前に不要なカラムを切り落とすためにSELECTを使用しましょう。常に可能なわけではありませんが、このアプローチは特に多くのカラムを持つ幅広のデータセットで効果的です。
- パーティションにおいてデータが均等に分配されるようにすることで、パーティショニング戦略を最適化 しましょう。
- シャッフルを完全に回避するために、小規模なデータセットでは broadcast join を使用しましょう。

タスクの所要時間

このメトリックは、エグゼキューターにでタスクを実行する際にJVMが費やす合計経過時間を追跡します。

解釈と対策:

タスクの所要時間チャートが迅速かつ指数関数的に増加する場合、長いタスク所要時間は多くの場合において調査が必要な非効率性を指し示すので、ボトルネックの処理やリソース割り当ての問題の兆候を示している場合があります。
- コードの効率性を最適化しましょう: パフォーマンスを改善するためにコードをレビューし最適化しましょう。
- リソース割り当てを調整しましょう: タスクに十分なリソース(CPU、メモリー)が割り当てられていることを確認しましょう。

いくつかのベストプラクティス

インスタンスタイプ

ワークロードのタイプに応じたインスタンスタイプを選択しましょう:

より高い処理能力が必要な場合には、コンピュート最適化インスタンスを使いましょう。(フルスキャンを伴い、データの再利用がないETL、構造化ストリーミングジョブ、OPTIMIZEやZ-order Deltaコマンドの実行など)
大量のメモリーを必要とするタスクではメモリー最適化インスタンスを使いましょう。(多くのシャッフルや溢れが含まれる、Sparkキャッシュが必要な場合など)
アドホックでインタラクティブなデータ分析や、Deltaキャッシュを活用するにはストレージ最適化インスタンスを使いましょう。
とてつもなく高いメモリー要件を持つML、DLワークロードではGPU最適化インスタンスを使いましょう。
特別な要件がない場合やVACUUM Deltaコマンドを実行する際にのみ汎用を使いましょう。

Photon

Photonは、低コストで非常に高速なクエリー性能を提供するDatabricksレイクハウスプラットフォームの次世代エンジンです。PhotonはApache Spark™ APIと互換性があり、既存のSparkコードですぐに利用でき、標準のDatabricksランタイムよりもはるかに優れたパフォーマンスを提供します。

以下の特性を持つワークロードでは(評価とパフォーマンスのテストの後に)Photonを有効化することをお勧めします:

Delta MERGEオペレーションから構成されるETLパイプライン
クラウドストレージに大量のデータを書き込む(Delta/Parquet)
大規模データセットのスキャン、集計、数値計算
ストレージに到着する新規データをインクリメンタルに効率的に処理するAuto Loader
SQLを用いたインタラクティブ/アドホックなクエリー

注意: Photonを使用する際には少なくとも4GB/コアのインスタンスタイプを使用することをお勧めします。

オートスケーリング

ワークロードの需要に基づいて動的にワーカー数を調整するためにオートスケーリングを有効化しましょう。これによって、アイドル期間の無駄なリソースの使用を回避し、ピーク負荷の際には適切なリソースを確保します。

注意: レーテンシーの要件が厳しいワークロードや、従来の構造化ストリーミングジョブでは通常、オートスケーリングは推奨されません。スケーリングアップやスケーリングダウンによって新たなノードが配備あるいは削除されるので、これらのワークロードにおいて必要な定常的な低レーテンシーに影響を与える場合があるので、遅延を導入する場合があります。このようなシナリオでは、予測可能なレスポンス時間を確実にするために、固定サイズのクラスターを使いましょう。

ワーカー数

適切なワーカー数の選択には、Sparkジョブのコンピュートとメモリーの要件を特定するための試行錯誤が必要となります。詳細はこちらをご覧ください。

コンピュート要件の厳しいワークロード: 膨大な処理能力を必要とするワークロードにおいては、ワーカー数を増やすことで、負荷をより効果的に分散させ、優れた並列性を達成することができます。
メモリー要件の厳しいワークロード: 膨大な量のメモリーを必要とするジョブ(大規模なデータセットをキャッシュする、メモリー消費の多い変換処理の実行など)においては、多くの場合、少数かつよりメモリー容量の大きいパワフルなワーカーノードを使用する方が良いです。
オペレーションのタイプによります: また、あなたのワークロードにおけるSparkオペレーションのタイプもワーカーの設定に影響を与えます:
- 狭い変換処理(シャッフルなし): シャッフルを必要としないワークロード(シンプルなマッピングやフィルタリングのオペレーション)は、多数の小規模なインスタンスを用いることによるメリットを享受できます。この環境では、データはノード間の移動の必要がないので、重大なネットワークのオーバーヘッドを引き起こすことなしに、並列度を最大化します。
- 広い変換処理(多数のシャッフル): 広いオペレーションを含むワークロード(groupBy、join、reduceByKeyなど)は、データをノード間で交換する必要のあるシャッフルをトリガーします。この場合、少数の大規模なインスタンスを用いることで、より多くのデータがそれぞれのノードローカルで処理することができ、ネットワーク転送料を削減し、シャッフルのパフォーマンスを改善するのでメリットがあります。
注意: 通常は、少数の大規模なバーチャルマシンを使うことが推奨されます。

モニタリングのためのDatabricksシステムテーブルの活用

クラスターメトリクスを監視し、ボトルネックを特定するために活用できるいくつかのシステムテーブルをDatabricksは提供しています。

system.compute.clustersテーブル
- ワーカー数、インスタンスタイプ、オートスケーリング設定を含むクラスター設定の時間変化を追跡します。
- クラスターの変更を監査したり、ワークロードの要件に設定が合致していることを確認するためにこのテーブルを使用します。
system.compute.node_timelineテーブル
- ノードごとのCPU、メモリー、ネットワーク使用量のような分単位のリソース使用量メトリクスを捕捉します。
- 使用されていないリソースや高い競合状態を体験しているノードを特定するためにこのテーブルを分析します。
system.compute.node_typesテーブル
- vCPU数やメモリーキャパシティのような利用可能なノードタイプに関する詳細情報を提供します。
- ワークロードの要件に対して最適なインスタンスタイプを選択するためにこのテーブルを使用します。

サンプルクエリー

過去30日で最高のDBUを消費したジョブの特定

SELECT

  usage_metadata.job_id AS job_id,

  SUM(usage_quantity) AS total_dbus_consumed

FROM system.billing.usage

WHERE usage_metadata.job_id IS NOT NULL AND usage_date >= NOW() - INTERVAL 30 DAY

GROUP BY usage_metadata.job_id

ORDER BY total_dbus_consumed DESC;

クラスターごとのDBU使用量の監視

SELECT

   sku_name,

   SUM(usage_quantity) AS total_dbus_consumed,

   DATE_TRUNC('day', usage_date) AS day

FROM system.billing.usage

WHERE usage_date >= NOW() - INTERVAL 30 DAY

GROUP BY sku_name, DATE_TRUNC('day', usage_date)

ORDER BY total_dbus_consumed DESC;

クラスターリソース使用量の監視

SELECT

   cluster_id,

   AVG(cpu_user_percent) AS avg_cpu_utilization_percent,

   AVG(mem_used_percent) AS avg_memory_utilization_percent,

   DATE_TRUNC('hour', end_time) AS hour

FROM system.compute.node_timeline

WHERE end_time >= NOW() - INTERVAL 1 DAY

GROUP BY cluster_id, DATE_TRUNC('hour', end_time)

ORDER BY avg_cpu_utilization_percent DESC;

使用率の低いクラスターの特定

SELECT

   cluster_id,

   AVG(cpu_user_percent) AS avg_cpu_utilization_percent,

   COUNT(*) AS data_points

FROM system.compute.node_timeline

WHERE end_time >= NOW() - INTERVAL 7 DAY

GROUP BY cluster_id

HAVING avg_cpu_utilization_percent < 0.2

ORDER BY avg_cpu_utilization_percent ASC;

まとめ

Databricksのクラスターメトリクスを理解、解釈することは、パフォーマンスとリソース使用率の最適化において重要となります。このガイドで説明された戦略を適用することで、あなたのクラスターが効率的に動作し、コストを削減し、全体的な生産性を改善することを確実にすることができます。覚えておいてください、積極的なモニタリングとタイムリーな対策が、高いパフォーマンスで動作するDatabricks環境の維持においては鍵となります。

Databricksクラスターメトリクスの解読: 解釈と対策のガイド

Databricksクラスターメトリクスの概要

メトリクスへのアクセス

Databricksクラスターメトリクスの理解

ハードウェアメトリクス

CPU使用率

メモリー使用率

ネットワークメトリクス

その他のハードウェアメトリクス

Sparkメトリクス

タスクメトリクス

シャッフル読み込み/書き込み

タスクの所要時間

いくつかのベストプラクティス

インスタンスタイプ

Photon

オートスケーリング

ワーカー数

モニタリングのためのDatabricksシステムテーブルの活用

サンプルクエリー

過去30日で最高のDBUを消費したジョブの特定

クラスターごとのDBU使用量の監視

クラスターリソース使用量の監視

使用率の低いクラスターの特定

まとめ

リファレンス

はじめてのDatabricks

Databricks無料トライアル