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

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

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

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

新しい汎用コンピュートリソースを作成する

新しい汎用コンピュートリソースを作成するには、次の手順を実行します。

  1. ワークスペースのサイドバーで、[コンピュート] をクリックします。

  2. [コンピュートを作成] ボタンをクリックします。

  3. コンピュートリソースを構成します。

  4. [コンピュートを作成] をクリックします。

新しいコンピュートリソースは自動的にスピンアップを開始し、すぐに使用できるようになります。

ポリシー

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

ポリシーに従ってコンピュートリソースを作成するには、[ポリシー] ドロップダウンメニューから目的のポリシーを選択します。

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

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

ポリシーに応じて、シングルノードのコンピュートリソースを作成するかマルチノードのコンピュートリソースを作成するかを選択できます。

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

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

シングルノードのコンピュートリソースには次のプロパティが含まれます。

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

  • ドライバーはマスターとワーカーの両方の役割を果たし、ワーカーノードはありません。

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

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

  • マルチノードのコンピュートリソースに変換することはできません。

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

シングルノードとマルチノードのコンピュートのどちらを使用するかは、ユースケースに応じて決定してください。

  • 大規模なデータ処理では、シングルノードのコンピュートリソースのリソースが枯渇してしまいます。このようなワークロードの場合、Databricks ではマルチノードのコンピュートの使用を推奨しています。

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

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

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

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

  • 単一ノードコンピュートの場合、SparkはUDT列を含む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 Catalog対応コンピュート上)

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

分離なし共有

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

いいえ

Python、SQL、Scala、R

分離なし共有コンピュートに関連するアカウントレベルの設定があります。

カスタム

非表示（すべての新しいコンピュート）

いいえ

Python、SQL、Scala、R

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

既存のコンピュートリソースをアップグレードしてUnity Catalogの要件を満たすには、アクセスモードを[シングルユーザー]または[共有]に設定します。Unity Catalog対応のワークスペースで、各アクセスモードでサポートされる機能の詳細については、「Unity Catalogのコンピュートアクセスモードの制限事項」を参照してください。

注：

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

Databricks Runtimeのバージョン

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

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

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

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

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

Databricks Runtime 9.1 LTS以降を実行しているコンピュートでは、Photonはデフォルトで有効になっています。

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

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

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

ワーカーノードまたはドライバーノードとして使用するプールを選択することもできます。 スポットインスタンスをワーカータイプとして持つプールのみを使用してください。 ドライバーが再利用されないように、別のオンデマンド ドライバーの種類を選択します。 「プールへの接続」を参照してください。

ワーカーの種類

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

ヒント

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

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

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

Driverのタイプ

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

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

ヒント

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

GPUインスタンスタイプ

ディープラーニングに関連するタスクなど、高いパフォーマンスを必要とする計算量が多いタスクの場合、Databricks はグラフィックス処理装置（GPU）で高速化されたコンピュートリソースをサポートします。詳細については、「GPU対応コンピュート」を参照してください。

Databricksは、Amazon EC2 P2インスタンスを使用したコンピュートのスピンアップをサポートしなくなりました。

AWS Gravitonインスタンスタイプ

Databricks は AWS Graviton のインスタンスをサポートしています。AWS Graviton インスタンスは、Arm64 命令セットアーキテクチャに基づいて構築された AWS 設計の Graviton プロセッサを使用しています。AWS によると、これらのプロセッサを搭載したインスタンスタイプは、Amazon EC2 のどのインスタンスタイプのなかで最も優れた価格性能比を提供します。Graviton インスタンスタイプを使用するには、 ワーカータイプ、 ドライバータイプ、またはその両方で使用可能な AWS Graviton インスタンスタイプのいずれかを選択します。

Databricksは、以下のAWS Graviton対応のコンピュートをサポートします：

  • Photon以外の場合Databricks Runtime 9.1 LTS以上、Photonの場合、Databricks Runtime 10.2 (EoS) 以上。

  • Databricks Runtime 15.4 LTS for Machine Learning で、Databricks Runtime for Machine Learning の場合。

  • すべてのAWSリージョン。ただし、すべてのインスタンスタイプがすべてのリージョンで利用できるわけではないことに注意してください。リージョンでは利用できないインスタンスタイプをワークスペースに選択すると、コンピュート作成が失敗します。

  • AWS Graviton2およびGraviton3プロセッサ対応。

注：

Delta Live Tablesは、Graviton対応コンピュートではサポートされていません。

ARM64 ISA の制限事項

  • 浮動小数点の精度の変更：加算、減算、乗算、除算などの一般的な演算では精度は変更されません。sinやcosなどの単一の三角形関数の場合、Intelインスタンスとの精度の差の上限は1.11e-16です。

  • サードパーティのサポート：ISAの変更は、サードパーティのツールやライブラリのサポートに何らかの影響を与える可能性があります。

  • 混合インスタンスコンピュート：Databricksでは、AWS Gravitonインスタンスタイプと非AWS Gravitonインスタンスタイプの混在はサポートされていません。各タイプには異なるDatabricks Runtimeが必要であるためです。

Gravitonの制限

次の機能はAWS Gravitonインスタンスタイプをサポートしていません。

  • Python UDF（Python UDFはDatabricks Runtime 15.2以降で使用できます）

  • Databricks Container Services

  • Delta Live Tables

  • Databricks SQL

  • AWS GovCloud上のDatabricks

  • WebターミナルからGitフォルダ内のファイルを含むワークスペースファイルへのアクセス

AWSフリートインスタンスタイプ

注：

ワークスペースが2023年5月より前に作成された場合は、フリートインスタンスタイプにアクセスできるようにIAMロールの権限を更新する必要がある場合があります。詳細については、フリートインスタンスタイプの有効化を参照してください。

フリートインスタンスタイプは、同じサイズの利用可能な最適なインスタンスタイプに自動的に解決される可変インスタンスタイプです。

たとえば、フリートインスタンスタイプ m-fleet.xlarge を選択した場合、ノードは、その時点でスポット容量と価格が最も優れた汎用インスタンスタイプの .xlarge に割り当てられます。コンピュートリソースが解決されるインスタンスタイプは、常に選択したフリートインスタンスタイプと同じメモリとコア数を持ちます。

フリートインスタンスタイプは、AWS のスポットプレイスメントスコア API を使用して、コンピュートリソースに最適で最も成功する可能性が高いアベイラビリティゾーンを起動時に選択します。

フリートの制限

  • ワーカーノードタイプがフリートインスタンスタイプに設定されている場合、[詳細オプション] の [最大スポット価格] 設定は影響しません。これは、スポット価格の参照ポイントとして使用できる単一のオンデマンドインスタンスが存在しないためです。

  • フリートインスタンスは GPU インスタンスをサポートしていません。

  • ごく一部の古いワークスペースでは、まだフリートインスタンスタイプをサポートしていません。ワークスペースがこのような場合は、フリートインスタンスタイプを使用してコンピュートまたはインスタンスプールを作成しようとしたときに、このことを示すエラーが表示されます。私たちは、残りのワークスペースにサポートを提供できるよう取り組んでいます。

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

「オートスケールを有効にする」をチェックすると、コンピュートリソースのワーカーの最小値と最大値を指定できます。その後で、ジョブの実行に必要な適切な数のワーカーを Databricks は選択します。

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

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

注：

コンピュートリソースが実行中の場合、コンピュートの詳細ページに割り当てられたワーカーの数が表示されます。割り当てられたワーカーの数をワーカーの設定と比較し、必要に応じて調整を行うことができます。

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

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

オートスケーリングを使用すると、ワークロードに合わせてコンピュートをプロビジョニングする必要がないため、使用率を簡単に上げられます。これは、要件が時間の経過と共に変化するワークロード（1日の間にデータセットを探索するなど）の場合に特に当てはまりますが、プロビジョニング要件が不明な1回限りの短いワークロードの場合に当てはまります。オートスケーリングには次の2つの利点があります。

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

  • オートスケールを使うことで、静的にサイズ調整されたコンピュートリソースと比較して全体的なコストを削減できます。

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

注：

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

注：

コンピュートのオートスケーリングは、構造化ストリーミングワークロードのクラスターサイズのスケールダウンに対して制限があります。Databricksでは、ストリーミングワークロードの強化オートスケーリングでDelta Live Tablesを使用することを推奨しています。「強化オートスケールを使用してDelta Live Tablesパイプラインのクラスター使用率を最適化する」を参照してください。

オートスケールの動作

プレミアムプラン以上のワークスペースでは、最適化された自動スケーリングが使用されます。スタンダードプランのワークスペースでは、標準の自動スケーリングが使用されます。

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

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

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

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

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

  • All-Purpose コンピュートは、過去 150 秒間にコンピュートリソースが十分に活用されていない場合にスケールダウンします。

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

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

  • まず8ノードを追加します。その後、指数関数的にスケールアップし、最大値に達するまでに必要なステップ数を踏みます。

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

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

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

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

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

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

オートスケールの例

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

初期サイズ

再構成後のサイズ

6

6

12

10

3

5

ローカルストレージのオートスケールを有効化

コンピュート作成時に固定数のEBSボリュームを割り当てたくない場合は、オートスケールローカルストレージを使用します。Databricksではローカルストレージをオートスケールするため、使用コンピュートのSparkワーカーで利用可能なディスクの空き容量が監視されます。ディスクでのワーカーの実行速度が過度に低くなり始めると、Databricksでは容量不足に陥る前に、新しいEBSボリュームがワーカーに自動的にアタッチされます。EBSボリュームは、インスタンスごとに合計5 TBのディスク容量（インスタンスのローカルストレージを含む）を上限としてアタッチされます。

ストレージのオートスケールを設定するには、[ローカルストレージのオートスケールを有効化] を選択します。

インスタンスにアタッチされたEBSボリュームは、インスタンスがAWSに返却されたときにのみデタッチされます。つまり、EBSボリュームは、実行中のコンピュートの一部である限り、インスタンスから切り離されることはありません。EBSの使用量をスケールダウンするために、Databricksは、オートスケールコンピュートまたは自動ターミネーションで構成されたコンピュートでこの機能を使用することを推奨します。

注：

Databricksは、スループット最適化HDD（st1）を使用してインスタンスのローカルストレージを拡張します。これらのボリュームのデフォルトのAWS容量制限は20TiBです。この制限に達しないようにするには、管理者は使用要件に基づいてこの制限の引き上げをリクエストする必要があります。

ローカルディスク暗号化

プレビュー

この機能はパブリックプレビュー段階です。

コンピュートを実行するために使用するインスタンスタイプによっては、ディスクがローカルに接続されている場合があります。Databricks は、これらのローカルに接続されたディスクにシャッフルデータまたは一時データを保存する場合があります。コンピュートリソースのローカルディスクに一時的に保存されているシャッフルデータを含め、保存中のすべてのデータをすべてのストレージタイプで確実に暗号化するには、ローカルディスク暗号化を有効にします。

重要

ローカルボリュームとの間で暗号化されたデータを読み書きするとパフォーマンスに影響を与え、ワークロードの実行が遅くなる可能性があります。

ローカルディスクの暗号化が有効な場合、Databricksは各コンピュートノードに固有の暗号化キーをローカルに生成し、ローカルディスクに保存されたすべてのデータを暗号化するために使用します。キーのスコープは各コンピュートノードに対してローカルであり、コンピュートノード自体と共に破棄されます。鍵の有効期間中、鍵は暗号化と復号化のためにメモリに存在し、ディスクに暗号化されて保存されます。

ローカルディスクの暗号化を有効にするには、クラスターAPIを使用する必要があります。コンピュートの作成または編集中に、enable_local_disk_encryptionをtrueに設定します。

自動終了

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

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

インスタンスプロファイル

注：

Databricksでは、インスタンスプロファイルではなく、Unity Catalog外部ロケーションを使用してS3に接続することをお勧めします。Unity Catalogは、アカウント内の複数のワークスペースにわたるデータアクセスを一元的に管理および監査するための場所を提供することで、データのセキュリティとガバナンスを簡素化します。「Unity Catalogを使用したクラウドオブジェクトストレージへの接続」を参照してください。

AWSキーを使用せずにAWSリソースに安全にアクセスするには、インスタンスプロファイルを使用してDatabricksコンピュートを起動できます。インスタンスプロファイルを作成および設定する方法については、「チュートリアル：インスタンスプロファイルを使用したS3アクセスの設定」を参照してください。インスタンスプロファイルを作成したら、[インスタンスプロファイル]ドロップダウンリストで選択します。

コンピュートリソースを起動したら、次のコマンドを使用して S3 バケットにアクセスできることを確認してください。コマンドが成功すると、そのコンピュートリソースは S3 バケットにアクセスできるようになります。

 dbutils.fs.ls("s3a://<s3-bucket-name>/")

警告

コンピュートリソースがインスタンスプロファイルと共に起動すると、このコンピュートリソースへのアタッチ権限を持つユーザーであれば誰でも、このロールによって制御されるベースのリソースにアクセスすることができます。不要なアクセスから保護するために、コンピュート権限を使用してコンピュートリソースへに対する権限を制限してください。

タグ

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

プールから起動されたコンピュートの場合、カスタムタグはDBU使用状況レポートにのみ適用され、クラウドリソースには伝わりません。

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

コンピュートリソースにタグを追加する方法は次のとおりです。

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

  2. [追加] をクリックします。

AWSの構成

コンピュートを作成するときは、アベイラビリティーゾーン、最大スポット価格、EBSボリュームタイプを選択できます。これらの設定は、[インスタンス]タブの[詳細オプション]トグルの下にあります。

アベイラビリティゾーン

この設定では、コンピュートリソースにどのアベイラビリティゾーン（AZ）を使用するかを指定できます。デフォルトではこの設定は自動に設定されており、ワークスペースのサブネットで利用可能なIPに基づいて AZ が自動的に選択されます。AWS が容量不足エラーを返す場合、Auto-AZ は他のアベイラビリティゾーンで再試行します。

注：

Auto-AZ はコンピュート起動時にのみ動作します。コンピュートリソースが起動した後、コンピュートリソースが終了または再起動されるまで、すべてのノードは元のアベイラビリティーゾーンに残ります。

コンピュートリソースに特定の AZ を選択する方法は、主に特定のアベイラビリティゾーンのリザーブドインスタンスを組織が購入している場合に便利です。AWS アベイラビリティゾーンの詳細についてお読みください。

スポットインスタンス

スポットインスタンスを使用するかどうかを指定できます。また、スポットインスタンスを起動するときに使用する最大スポット料金を、対応するオンデマンド料金に対するパーセンテージで指定できます。デフォルトでは、最大料金はオンデマンド料金の100%です。「AWSスポット料金」を参照してください。

EBSボリューム

このセクションでは、ワーカーノードのデフォルトのEBSボリューム設定、シャッフルボリュームの追加方法、およびDatabricksがEBSボリュームを自動的に割り当てるようにコンピュートを構成する方法について説明します。

EBSボリュームを構成するには、コンピュートでローカルストレージのオートスケールが有効になっていない必要があります。コンピュート構成の[インスタンス]タブをクリックし、[EBSボリュームタイプ]ドロップダウンリストでオプションを選択します。

デフォルトのEBSボリューム

Databricksは、次のようにすべてのワーカーノードに対してEBSボリュームをプロビジョニングします。

  • ホストオペレーティングシステムとDatabricks内部サービスによって使用される、30 GBの暗号化されたEBSインスタンスルートボリューム。

  • Sparkワーカーが使用する150 GBの暗号化されたEBSコンテナルートボリューム。これは、Sparkサービスとログをホストします。

  • （HIPAAのみ）Databricks内部サービスのログを保存する75 GBの暗号化されたEBSワーカーログボリューム。

EBSシャッフルボリュームの追加

シャッフルボリュームを追加するには、[EBSボリュームタイプ] ドロップダウンリストで [汎用SSDボリューム] を選択します。

デフォルトでは、Sparkシャッフルの出力内容はインスタンスのローカルディスクに送信されます。インスタンスがローカルディスクを持たないタイプである場合や、Sparkシャッフルのストレージ容量を増やしたい場合は、追加のEBSボリュームを指定できます。この措置は、大きなシャッフル出力を生成するSparkジョブの実行において、ディスク容量不足エラーが発生する事態を回避したい場合に、特に有効です。

Databricksは、オンデマンドインスタンスとスポットインスタンスの両方でこれらのEBSボリュームを暗号化します。AWS EBSボリュームの詳細についてお読みください。

必要に応じて、Databricks EBSボリュームを顧客マネージドキーで暗号化する

オプションとして、カスタマが管理するキーでコンピュートEBSボリュームを暗号化することができます。

暗号化用のカスタマーマネージドキーを参照してください。

AWS EBSの制限

AWS EBSの上限が、デプロイされたすべてのコンピュートですべてのワーカーのランタイム要件を満たすのに十分であることを確認してください。デフォルトのEBS制限とその変更方法については、「Amazon Elastic Block Store（EBS）の制限」を参照してください。

AWS EBS SSDボリュームタイプ

AWS EBS SSDボリュームタイプとしてgp2またはgp3を選択します。この操作について詳しくは、「SSDストレージの管理」を参照してください。Databricksでは、gp2よりもコスト削減できるgp3への切り替えを推奨しています。

注：

デフォルトでは、Databricks構成はgp3ボリュームのIOPSとスループットIOPSを、同じボリュームサイズのgp2ボリュームの最大パフォーマンスと一致するように設定されます。

gp2およびgp3の技術情報については、「Amazon EBSボリュームタイプ」を参照してください。

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. [環境変数] フィールドで環境変数を設定します。

    環境変数フィールド

クラスター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. コンピュートログのパスを入力します。

S3バケットの宛先

S3 の宛先を選択した場合は、バケットにアクセスできるインスタンスプロファイルを使用してコンピュートリソースを設定する必要があります。このインスタンスプロファイルには、 PutObject権限とPutObjectAcl権限の両方が必要です。便宜上、インスタンスプロファイルの例が含まれています。インスタンスプロファイルの設定方法については「インスタンスプロファイルを使用して S3 アクセスを設定する」を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::<my-s3-bucket>"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<my-s3-bucket>/*"
      ]
    }
  ]
}

注：

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