コンピュート構成リファレンス

この記事では、Create コンピュート UI で使用できるすべての構成設定について説明します。 ほとんどのユーザーは、割り当てられたポリシーを使用してコンピュートを作成しますが、これにより、構成可能な設定が制限されます。 UI に特定の設定が表示されない場合は、選択したポリシーでその設定を構成できないことが原因です。

GCP無制限コンピュート作成ページ

この記事で説明する構成と管理ツールは、汎用コンピュートとジョブ コンピュートの両方に適用されます。 ジョブ コンピュートの構成に関する考慮事項の詳細については、 「ジョブで Databricks コンピュートを使用する」を参照してください。

ポリシー

ポリシーは、ユーザーがコンピュートを作成するときに使用できる構成オプションを制限するために使用される一連のルールです。 ユーザーが無制限のクラスター作成権限を持っていない場合、付与されたポリシーを使用してコンピュートを作成することしかできません。

ポリシーに従ってコンピュートを作成するには、 「ポリシー」ドロップダウン メニューからポリシーを選択します。

デフォルトでは、すべてのユーザーが個人コンピュートポリシーにアクセスでき、単一マシンのコンピュート リソースを作成できます。 Personal コンピュートまたはその他のポリシーへのアクセスが必要な場合は、ワークスペース管理者にお問い合わせください。

シングルノードまたはマルチノードのコンピュート

ポリシーに応じて、単一ノードコンピュートの作成またはマルチ ノードコンピュートの作成を選択できます。

シングル ノード コンピュートは、単一ノードの機械学習ライブラリなど、少量のデータまたは非分散ワークロードを使用するジョブを対象としています。 マルチノード コンピュートは、ワークロードが分散された大規模なジョブに使用する必要があります。

シングルノードのプロパティ

単一ノードのコンピュートには次のプロパティがあります。

  • Spark をローカルで実行します。

  • ドライバーはマスターとワーカーの両方として機能し、ワーカー ノードはありません。

  • コンピュートの論理コアごとに 1 つのエグゼキューター スレッドを生成します (ドライバー用の 1 コアを差し引いたもの)。

  • すべての stderr、 stdout、 log4j ログ出力をドライバ ログに保存します。

  • マルチノードコンピュートへの変換はできません。

単一ノードまたは複数ノードの選択

単一ノードのコンピュートかマルチノードのコンピュートかを決定するときは、ユースケースを考慮してください。

  • 大規模なデータ処理は、単一ノードのコンピュート上のリソースを使い果たします。 これらのワークロードの場合、Databricks ではマルチノード コンピュートの使用を推奨します。

  • 単一ノードのコンピュートは共有されるように設計されていません。 リソースの競合を避けるために、Databricks ではコンピュートを共有する必要がある場合はマルチノード コンピュートを使用することをお勧めします。

  • マルチノード コンピュートをワーカー数 0 にスケールすることはできません。 代わりに単一ノードのコンピュートを使用してください。

  • シングルノードコンピュートはプロセス分離と互換性がありません。

  • GPU スケジューリングは、シングル ノード コンピュートでは有効になっていません。

  • 単一ノードのコンピュートでは、Spark は UDT 列を含む .parquet ファイルread.parquetことができません。 次のエラー メッセージが表示されます。

    The Spark driver has stopped unexpectedly and is restarting. Your notebook will be automatically reattached.

    この問題を回避するには、ネイティブ Parquet リーダーを無効にします。

    spark.conf.set("spark.databricks.io.parquet.nativeReader.enabled", False)

アクセスモード

アクセス モードは、コンピュートを使用できるユーザーと、コンピュートを介してアクセスできるデータを決定するセキュリティ機能です。 Databricks のすべてのコンピュートにはアクセス モードがあります。

Databricks では、すべてのワークロードに共有アクセス モードを使用することをお勧めします。 シングル・ユーザー・アクセス・モードは、必要な機能が共有アクセス・モードでサポートされていない場合にのみ使用してください。

アクセスモード

ユーザーに表示

UCサポート

対応言語

注

シングルユーザー

いつも

あり

Python、SQL、Scala、R

1 人のユーザーに割り当てて使用できます。 一部のワークスペースでは、割り当てられたアクセス モードと呼ばれます。

共有

常時（プレミアムプランが必要）

あり

Python (Databricks Runtime 11.3 LTS 以降)、SQL、Scala (Databricks Runtime 13.3 LTS 以降を使用した Unity カタログ対応コンピュート上)

ユーザー間でデータを分離することにより、複数のユーザーが使用できます。

分離なし共有

管理者は、管理者設定ページで ユーザーの分離を強制 することで、このアクセス モードを非表示にできます。

なし

Python、SQL、Scala、R

No Isolation Shared コンピュートには、関連するアカウント レベルの設定があります。

カスタム

Hidden (すべての新しいコンピュート用)

なし

Python、SQL、Scala、R

このオプションは、アクセス モードが指定されていない既存のコンピュートがある場合にのみ表示されます。

アクセス モードをSingle UserまたはSharedに設定することで、既存のコンピュートをアップグレードして Unity Catalog の要件を満たすことができます。

注：

Databricks Runtime 13.3 LTS 以降では、init スクリプトとライブラリがすべてのアクセス モードでサポートされています。 要件とサポートはさまざまです。 「init スクリプトはどこにインストールできますか?」を参照してください。 およびクラスタースコープのライブラリ。

Databricks Runtimeのバージョン

Databricks Runtime は、コンピュート上で実行されるコア コンポーネントのセットです。 Databricks Runtimeバージョン]ドロップダウン メニューを使用してランタイムを選択します。 特定の Databricks Runtime バージョンの詳細については、 「Databricks Runtime リリースノートのバージョンと互換性」を参照してください。 すべてのバージョンに Apache Spark が含まれています。 Databricks では次のことをお勧めします。

  • 汎用コンピュートの場合は、最新バージョンを使用して、最新の最適化と、コードとプリロードされたパッケージ間の最新の互換性を確保してください。

  • 運用ワークロードを実行するジョブ コンピュートの場合は、長期サポート (LTS) Databricks Runtimeバージョンの使用を検討してください。 LTS バージョンを使用すると、互換性の問題が発生することがなくなり、アップグレード前にワークロードを徹底的にテストできます。

  • データサイエンスと機械学習のユース ケースでは、Databricks Runtime ML のバージョンを検討してください。

Photon アクセラレーションを使用する

Photon は、Databricks Runtime 9.1 LTS 以降を実行しているコンピュートで利用できます。

Photon アクセラレーションを有効または無効にするには、 [Use Photon Acceleration]チェックボックスをオンにします。 Photon の詳細については、 「Photon とは?」を参照してください。 。

ワーカー ノードとドライバー ノードの種類

コンピュートは、1 つのドライバー ノードと 0 個以上のワーカー ノードで構成されます。 ドライバー ノードとワーカー ノードに個別のクラウド プロバイダー インスタンス タイプを選択できますが、デフォルトではドライバー ノードはワーカー ノードと同じインスタンス タイプを使用します。 インスタンスタイプの異なるファミリーは、メモリ集中型またはコンピュート集中型のワークロードなど、さまざまなユースケースに適合します。

ワーカー ノードまたはドライバー ノードとして使用するプールを選択することもできます。 「Databricks プールとは何ですか?」を参照してください。 。

ワーカーの種類

マルチノード コンピュートでは、ワーカー ノードは Spark エグゼキューターや、コンピュートが適切に機能するために必要なその他のサービスを実行します。 Spark を使用してワークロードを分散すると、すべての分散処理がワーカー ノードで実行されます。 Databricks はワーカー ノードごとに 1 つのエグゼキューターを実行します。 したがって、Databricks アーキテクチャのコンテキストでは、エグゼキューターとワーカーという用語は同じ意味で使用されます。

ヒント

Spark ジョブを実行するには、少なくとも 1 つのワーカー ノードが必要です。 コンピュートのワーカーがゼロの場合、ドライバー ノードで非 Spark コマンドを実行できますが、Spark コマンドは失敗します。

ワーカーノードのIPアドレス

Databricks は、それぞれ 2 つのプライベート IP アドレスを使用してワーカー ノードを起動します。 ノードのプライマリ プライベート IP アドレスは、Databricks の内部トラフィックをホストします。 セカンダリ プライベート IP アドレスは、Spark コンテナーがクラスター内通信に使用します。 このモデルにより、Databricks は同じワークスペース内の複数のコンピュート間を分離できます。

ドライバーの種類

ドライバー ノードは、コンピュートに接続されているすべてのノートブックの状態情報を維持します。 また、ドライバー ノードは SparkContext を維持し、コンピュート上のノートブックまたはライブラリから実行するすべてのコマンドを解釈し、Spark エグゼキューターと連携する Apache Spark マスターを実行します。

ドライバーノードタイプのデフォルト値は、ワーカーノードタイプと同じです。 Sparkワーカーから大量のデータをcollect()により収集してノートブックで分析する場合は、より多くのメモリを備えたより大きなドライバーノードの種類を選択できます。

ヒント

ドライバーノードは、アタッチされているノートブックのすべての状態情報を保持するため、未使用のノートブックは必ずドライバーノードからデタッチしてください。

GPUインスタンスタイプ

ディープラーニングに関連するタスクなど、高いパフォーマンスを要求する計算が難しいタスクの場合、Databricks はグラフィックス プロセッシング ユニット (GPU) で高速化されたコンピュートをサポートします。 詳細については、 「GPU 対応コンピュート」を参照してください。

プリエンプティブルインスタンス

プリエンプティブルVMインスタンスは、通常のインスタンスよりもはるかに低価格で作成および実行できるインスタンスです。ただし、Google クラウドは、他のタスクのためにこれらのリソースにアクセスする必要がある場合、これらのインスタンスを停止(プリエンプト)することがあります。 プリエンプティブル インスタンスは Google コンピュート エンジンの容量を余分に使用するため、その可用性は使用状況によって異なります。

新しいコンピュートを作成する場合、次の 2 つの異なる方法でプリエンプティブル VM インスタンスを有効にすることができます。

  1. UI を使用してコンピュートを作成する場合は、ワーカー タイプの詳細の横にあるプリエンプティブル インスタンスをクリックします。

  2. UI を使用してインスタンス プールを作成する場合は、オンデマンド/プリエンプティブルをすべてのプリエンプティブル、プリエンプティブルとフォールバック GCP 、またはオンデマンド GCPに設定します。 プリエンプティブル VM インスタンスが利用できない場合、コンピュートはオンデマンド VM インスタンスの使用にフォールバックします。 フォールバック動作を設定するには、 gcp_attributes.gcp_availability を PREEMPTIBLE_GCP または PREEMPTIBLE_WITH_FALLBACK_GCPに設定します。 デフォルトはON_DEMAND_GCPです。

{
  "instance_pool_name": "Preemptible w/o fallback API test",
  "node_type_id": "n1-highmem-4",
  "gcp_attributes": {
      "availability": "PREEMPTIBLE_GCP"
  }
}

次に、新しいコンピュートを作成し、プールをプリエンプティブル インスタンス プールに設定します。

ローカル SSD を使用するインスタンスタイプ

インスタンスタイプの最新リスト、それぞれの価格、ローカル SSD のサイズについては、 GCP の料金見積もりツールをご覧ください。

ローカル SSD を持つインスタンスタイプは、デフォルトの Google クラウドサーバー側の暗号化で暗号化され、パフォーマンス向上のために ディスクキャッシュ が自動的に使用されます。 すべてのインスタンスタイプのキャッシュサイズが自動的に設定されるため、ディスク使用量を明示的に設定する必要はありません。

コンピュート用にローカル SSD を構成する

Clusters APIを使用してコンピュートを作成するときに、コンピュートに接続するローカル SSD の数を構成できます。

ローカル SSD の数を設定するには、gcp_attributes オブジェクトの local_ssd_count の値を設定します。各インスタンスタイプは、アタッチされたローカル SSD の数のみをサポートできます。 local_ssd_count で指定する値は、ドライバーとワーカーの両方のインスタンスタイプで有効である必要があります。詳細については、 ローカル SSD とマシンタイプに関する GCP ドキュメントを参照してください。

オートスケールを有効化する

[オートスケールを有効にする]がチェックされている場合、コンピュートのワーカーの最小数と最大数を指定できます。 次に、Databricks はジョブの実行に必要な適切なワーカー数を選択します。

コンピュートがオートスケールするワーカーの最小数と最大数を設定するには、ワーカー タイプドロップダウンの横にある[最小ワーカー]フィールドと[最大ワーカー]フィールドを使用します。

オートスケールを有効にしない場合は、ワーカー タイプ ドロップダウンの横にある ワーカー フィールドに固定数のワーカーを入力します。

注：

コンピュートの実行中、コンピュートの詳細ページには割り当てられたワーカーの数が表示されます。 割り当てられたワーカーの数をワーカー構成と比較し、必要に応じて調整できます。

オートスケールのメリット

オートスケーリングを使用すると、Databricksはジョブの特性を考慮してワーカーを動的にアカウントに再割り当てします。パイプラインの特定の部分は他の部分よりも計算負荷が高い場合があり、Databricksはジョブのこれらのフェーズ中にワーカーを自動的に追加（さらに、ワーカーが不要になったときにワーカーを削除）します。

オートスケールを使用すると、ワークロードに合わせてコンピュートをプロビジョニングする必要がないため、高い使用率を達成しやすくなります。 これは、要件が時間の経過とともに変化するワークロード (1 日の中でのデータセットの探索など) に特に当てはまりますが、プロビジョニング要件が不明な 1 回だけ短いワークロードにも適用される可能性があります。 したがって、オートスケールには次の 2 つの利点があります。

  • ワークロードは、一定サイズのアンダープロビジョニングのコンピュートと比較して高速に実行できます。

  • オートスケールは、静的なサイズのコンピュートに比べて全体的なコストを削減できます。

コンピュートの一定のサイズとワークロードに応じて、オートスケールはこれらの利点の一方または両方を同時に提供します。 コンピュート サイズは、クラウド プロバイダーがインスタンスを終了するときに選択されたワーカーの最小数を下回る可能性があります。 この場合、Databricks はワーカーの最小数を維持するためにインスタンスの再プロビジョニングを継続的に再試行します。

注：

オートスケーリングはspark-submitジョブでは使用できません。

注：

コンピュートの自動スケーリングには、構造化ストリーミング ワークロードのクラスター サイズをスケールダウンする制限があります。 Databricks 、ストリーミング ワークロードに拡張オートスケールを備えたDelta Live Tablesを使用することをお勧めします。 「拡張オートスケールDelta Live Tables Pipeline のクラスター使用率を最適化する」を参照してください。

オートスケーリングの動作

Premium および Enterprise 料金プランのワークスペースでは、最適化されたオートスケールが使用されます。 標準料金プランのワークスペースでは、標準のオートスケールが使用されます。

最適化されたオートスケールには、次の特性があります。

  • 2つのステップで最小から最大にスケールアップします。

  • コンピュートがアイドル状態でなくても、シャッフルファイルの状態を見てスケールダウンすることができます。

  • 現在のノードの割合に基づいてスケールダウンします。

  • ジョブ コンピュートでは、最後の 40 秒間でコンピュートが十分に活用されていない場合、スケールダウンします。

  • 汎用コンピュートでは、最後の 150 秒間でコンピュートが十分に活用されていない場合、スケールダウンします。

  • spark.databricks.aggressiveWindowDownS Spark 構成プロパティは、コンピュートがダウンスケーリングの決定を行う頻度を秒単位で指定します。 値を増やすと、コンピュートのスケールダウンが遅くなります。 最大値は 600 です。

Standard オートスケールは、Standard プランのワークスペースで使用されます。 標準オートスケールには、次の特徴があります。

  • 8 つのノードを追加することから始めます。 その後、指数関数的にスケールアップし、最大値に達するために必要な数のステップを実行します。

  • ノードの 90% が 10 分間ビジー状態でなく、コンピュートが少なくとも 30 秒間アイドル状態である場合、スケールダウンします。

  • 1 ノードから指数関数的にスケールダウンします。

プールのついたオートスケール

コンピュートをプールに接続する場合は、次の点を考慮してください。

  • 要求されたコンピュート サイズが、プール内のアイドル状態のインスタンスの最小数以下であることを確認してください。 これより大きい場合、コンピュートの起動時間はプールを使用しないコンピュートと同等になります。

  • 最大コンピュート サイズがプールの最大容量以下であることを確認してください。 これより大きいとコンピュートの作成に失敗します。

オートスケーリングの例

静的コンピュートをオートスケールに再構成すると、Databricks はすぐに最小範囲と最大範囲内でコンピュートのサイズを変更し、オートスケールを開始します。 例として、次の表は、5 ～ 10 ノードの間でコンピュートをオートスケールに再構成した場合に、特定の初期サイズでコンピュートに何が起こるかを示しています。

初期サイズ

再構成後のサイズ

6

6

12

10

3

5

オートスケールのローカルストレージを有効にする

Google クラウド コンピュート インスタンスは、ゾーン ソリッド ステート永続ディスクを使用して、ワーカー レベルで追加のストレージで補完できます。

オートスケール ローカル ストレージを使用して、Databricks はコンピュートの Spark ワーカーで利用可能な空きディスク容量を監視します。 ワーカーの実行が開始されるディスク容量が少なすぎると、Databricks はディスク領域が不足する前にゾーン SSD PD のサイズを自動的に変更します。 ゾーン SSD PD ボリュームは、インスタンスあたり合計ディスク容量の制限として 5 TB まで接続されます (インスタンスのローカル ストレージを含む)。

オートスケールストレージを設定するには、[ Enable autoscale local storage] (オートスケールローカルストレージを有効にする) を選択します。

デフォルト プロビジョニングされたストレージ

Databricks では、ワーカー ノードごとに次のストレージがプロビジョニングされます。

  • ホスト オペレーティング システムと Databricks 内部サービスによって使用されるインスタンスごとに 1 つのブート ディスク。 ブートディスクは、非GPUインスタンスの場合は100GB、GPUインスタンスの場合は200GBです。

  • Spark ワーカーによって使用されるローカル SSD。 このホストされた Spark サービスとログ。 各ローカルSSDは375GBです。 アタッチされたローカル SSD の数を設定するには、「 ローカル SSD を使用するインスタンスタイプ」を参照してください。

  • ストレージオートスケールが有効な場合のリモート SSD。 これらは、作成時に 150 GB から始まり、必要に応じてオートスケールされます。

ローカルディスクの暗号化

ローカル SSD を持つインスタンスタイプは、デフォルトの Google クラウドサーバー側の暗号化で暗号化されます。 「 ローカル SSD を使用するインスタンスタイプ」を参照してください。

自動終了

コンピュートの自動終了を設定できます。 コンピュートの作成中に、コンピュートを終了するまでの非アクティブ期間を分単位で指定します。

現在の時刻とコンピュートで実行された最後のコマンドの差が、指定された非アクティブ期間を超えている場合、Databricks はそのコンピュートを自動的に終了します。 コンピュートの終了の詳細については、 「コンピュートの終了」を参照してください。

タグ

タグを使用すると、組織内のさまざまなグループが使用するクラウド リソースのコストを簡単に監視できます。 コンピュートの作成時にタグをキーと値のペアとして指定すると、 Databricksこれらのタグを GKE クラスター上のDatabricks Runtimeポッドと永続ボリューム、およびDBU使用状況レポートに適用します。

アカウント コンソールの Databricks 課金利用グラフ では、個々のタグごとに使用状況を集計できます。 同じページからダウンロードされた課金利用CSVレポートには、デフォルトタグとカスタムタグも含まれます。 タグ は GKE ラベルと GCE ラベルにも反映されます。

プール タグ タイプとコンピュート タグ タイプがどのように連携するかについての詳細は、 「タグを使用した使用状況の監視」を参照してください。

コンピュートにタグを追加するには:

  1. [ タグ] セクションで、各カスタム タグのキーと値のペアを追加します。

  2. 「追加」をクリックします。

Google サービス アカウント

Google ID を使用してこのコンピュートを Google サービス アカウントに関連付けるには、 [詳細オプション]をクリックし、Google サービス アカウントの電子メール アドレスを[Google サービス アカウント]フィールドに追加します。 この値は、 GCSおよびBigQueryデータソースでの認証に使用されます。

重要

GCS および BigQuery データソースへのアクセスに使用するサービスアカウントは、Databricks アカウントの設定時に指定したサービスアカウントと同じプロジェクトに存在する必要があります。

可用性ゾーン

コンピュート構成ページの[詳細オプション]で、コンピュートのアベイラビリティ ゾーンを選択します。 この設定では、コンピュートで使用するアベイラビリティ ゾーンを指定できます。 デフォルトでは、アベイラビリティーゾーン設定は[自動]に設定されています。 [ 自動] に設定すると、1 つの可用性ゾーンが自動的に選択されます。

特定のゾーンを選択することもできます。 特定のゾーンの選択は、主に、組織が特定のアベイラビリティーゾーンでリザーブドインスタンスを購入している場合に便利です。

高可用性ゾーン

アベイラビリティーゾーンとして HA を選択することもできます。 高可用性 (HA) は、長期間にわたって一貫したレベルのアップタイムを提供するように設計されたシステム機能です。 HAゾーン構成を使用すると、ゾーンが使用できない、ゾーン内のインスタンス容量をソースにできないなど、単一ゾーンの可用性の問題が発生する可能性を減らすことができます。

可用性ゾーンとして HA が選択されている場合、Databricks はリージョン内のゾーン間でインスタンスの配置のバランスを取ります。 これにより、ゾーン間エグレス料金による価格の上昇につながる可能性があります。

Spark の構成

Spark ジョブを微調整するために、カスタムSpark 構成プロパティを提供できます。

  1. コンピュート構成ページで、 「詳細オプション」トグルをクリックします。

  2. 「 Spark 」タブをクリックします。

    Spark の構成

    [Spark 構成] で、構成プロパティを 1 行に 1 つのキーと値のペアとして入力します。

クラスター APIを使用してコンピュートを構成する場合は、 クラスター作成 APIまたはクラスター更新 API のspark_confフィールドに Spark プロパティを設定します。

コンピュートに Spark 構成を強制するために、ワークスペース管理者はコンピュート ポリシーを使用できます。

シークレットから Spark 構成プロパティを取得する

Databricks では、パスワードなどの機密情報をプレーンテキストではなく シークレット に格納することをお勧めします。 Spark 構成でシークレットを参照するには、次の構文を使用します。

spark.<property-name> {{secrets/<scope-name>/<secret-name>}}

たとえば、 password という Spark 構成プロパティを secrets/acme_app/passwordに格納されているシークレットの値に設定するには、次のようにします。

spark.password {{secrets/acme-app/password}}

詳細については、「 Spark 構成プロパティまたは環境変数でシークレットを参照するための構文」を参照してください。

環境変数

コンピュートのinit スクリプト実行からアクセスできるカスタム環境変数を構成します。 Databricksは、init スクリプトで使用できる事前定義された 環境変数も提供されます。 これらの事前定義された環境変数をオーバーライドすることはできません。

  1. コンピュート構成ページで、 「詳細オプション」トグルをクリックします。

  2. 「 Spark 」タブをクリックします。

  3. 「環境変数」フィールドで 環境変数 を設定します。

    [環境変数(Environment Variables)] フィールド

    注：

    ENV は予約語であり、環境変数の名前として使用することはできません。

クラスターの作成 APIまたはクラスターの更新 API のspark_env_varsフィールドを使用して環境変数を設定することもできます。

コンピュートログ配信

コンピュートを作成するときに、Spark ドライバー ノード、ワーカー ノード、およびイベントのログを配信する場所を指定できます。 ログは 5 分ごとに配信され、選択した宛先に 1 時間ごとにアーカイブされます。 コンピュートが終了すると、Databricks はコンピュートが終了するまでに生成されたすべてのログを配信することを保証します。

ログの宛先はコンピュートのcluster_idによって異なります。 指定された宛先がdbfs:/cluster-log-deliveryの場合、 0630-191345-leap375のコンピュート ログはdbfs:/cluster-log-delivery/0630-191345-leap375に配信されます。

ログの配信場所を構成するには、次のようにします。

  1. [コンピュート] ページで、 [詳細オプション]トグルをクリックします。

  2. 「 ロギング 」タブをクリックします。

  3. 宛先タイプを選択します。

  4. コンピュートログのパスを入力します。

    ログ・パスは、 dbfs:/で始まる DBFS パスでなければなりません。

注：

この機能は、REST API でも使用できます。 クラスター API を参照してください。