コンピュート コンフィギュレーション リファレンス

注記

この記事の構成は、単純な形式のコンピュート UI を使用していることを前提としています。 簡易フォームの更新の概要については、「 簡易フォームを使用してコンピュートを管理する」を参照してください。

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

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

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

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

1. ワークスペースのサイドバーで、 [コンピュート] をクリックします。
2. [コンピュートを作成] ボタンをクリックします。
3. コンピュートリソースを構成します。
4. 作成 をクリックします。

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

コンピュート ポリシー

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

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

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

パフォーマンス設定

次の設定は、シンプルフォームのコンピュートUIの [パフォーマンス ]セクションに表示されます。

• Databricks Runtime のバージョン
• Photonアクセラレーションを使用する
• ワーカーノードタイプ
• シングルノードコンピュート
• オートスケールを有効化
• パフォーマンスの詳細設定

Databricks Runtime のバージョン

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

• 汎用コンピュートの場合は、コードとプリロードされたパッケージ間の最新の互換性を確保するために、最新の最適化と、最新バージョンを使用してください。
• 運用ワークロードを実行しているジョブコンピュートの場合は、Databricks Runtimeの長期サポート（LTS）バージョンの使用を検討してください。LTSバージョンを使用すれば、互換性の問題が発生せず、アップグレードする前にワークロードを徹底的にテストできます。
• データサイエンスと機械学習のユースケースでは、Databricks Runtime MLバージョンを検討してください。

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

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

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

ワーカーノードタイプ

コンピュート リソースは、1 つのドライバー ノードと 0 個以上のワーカー ノードで構成されます。 ドライバーノードとワーカーノードに別々のクラウドプロバイダーインスタンスタイプを選択できますが、デフォルトでは、ドライバーノードはワーカーノードと同じインスタンスタイプを使用します。 ドライバー ノードの設定は、[ 高度なパフォーマンス ] セクションの下にあります。

インスタンスタイプのファミリーが異なれば、メモリ集約型またはコンピュート集約型のワークロードなど、さまざまなユースケースに適合します。 ワーカーノードまたはドライバーノードとして使用するプールを選択することもできます。

important

ドライバータイプとしてスポットインスタンスを含むプールは使用しないでください。 オンデマンド ドライバーの種類を選択して、ドライバーが再利用されないようにします。 「プールへの接続」を参照してください。

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

ヒント

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

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

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

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対応のコンピュートをサポートします：

• Databricks Runtime 9.1 LTS 以降(非Photon)、Databricks Runtime 10.2(EoS)以降(Photon)の場合。
• Databricks Runtime 15.4 LTS for Machine Learning で、Databricks Runtime for Machine Learning の場合。
• すべてのAWSリージョン。ただし、すべてのインスタンスタイプがすべてのリージョンで利用できるわけではないことに注意してください。リージョンでは利用できないインスタンスタイプをワークスペースに選択すると、コンピュート作成が失敗します。
• AWS Graviton2およびGraviton3プロセッサ対応。

注記

DLT は 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
• DLT
• Databricks SQL
• AWS GovCloud上のDatabricks
• WebターミナルからGitフォルダ内のファイルを含むワークスペースファイルへのアクセス

AWS Fleet インスタンスタイプ

注記

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

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

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

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

フリートの制限

• スポットインスタンスの入札率を API または JSON を使用して更新しても、ワーカーノードタイプがフリートインスタンスタイプに設定されている場合は効果がありません。 これは、スポット価格の参照ポイントとして使用するオンデマンドインスタンスが 1 つも存在しないためです。
• フリートインスタンスは GPU インスタンスをサポートしていません。
• ごく一部の古いワークスペースでは、まだフリートインスタンスタイプをサポートしていません。ワークスペースがこのような場合は、フリートインスタンスタイプを使用してコンピュートまたはインスタンスプールを作成しようとしたときに、このことを示すエラーが表示されます。私たちは、残りのワークスペースにサポートを提供できるよう取り組んでいます。

シングルノードコンピュート

「単一ノード 」チェック・ボックスを使用すると、単一ノード・コンピュート・リソースを作成できます。

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

単一ノードのプロパティ

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

• Sparkをローカルで実行します。
• ドライバーはマスターとワーカーの両方の役割を果たし、ワーカーノードはありません。
• コンピュートリソースの論理コアごとに 1 つのエグゼキュータースレッドを生成し、ドライバー用に 1 コアを引いたものです。
• すべてのstderr、 stdout、およびlog4jログ出力をドライバーログに保存します。
• マルチノードのコンピュートリソースに変換することはできません。

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

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

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

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

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

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

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

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

  Console

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

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

  Python

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

オートスケールの有効化

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

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

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

注記

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

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

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

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

• ワークロードは、固定サイズのプロビジョニング不足のコンピュートリソースと比較して高速に実行できます。
• オートスケールを使うことで、静的にサイズ調整されたコンピュートリソースと比較して全体的なコストを削減できます。

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

注記

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

注記

コンピュート Auto-Scaling には、構造化ストリーミング ワークロードのクラスタリング サイズをスケールダウンする制限があります。 Databricks では、ストリーミング ワークロードに拡張オートスケールの DLT を使用することをお勧めします。 拡張オートスケールによる DLT パイプラインのクラスタリング利用の最適化を参照してください。

オートスケールの動作

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

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

• 2つのステップで最小から最大にスケールアップします。
• コンピュートリソースがアイドル状態になくても、シャッフルファイルの状態を調べることでスケールダウンできます。
• 現在のノードの割合に基づいてスケールダウンします。
• ジョブコンピュートでは、コンピュートリソースが過去 40 秒間に十分に活用されていない場合はスケールダウンします。
• All-Purpose コンピュートは、過去 150 秒間にコンピュートリソースが十分に活用されていない場合にスケールダウンします。
• spark.databricks.aggressiveWindowDownS Spark 構成プロパティは、コンピュートがダウンスケーリングの決定を行う頻度を秒単位で指定します。値を大きくすると、コンピュートのスケールダウンが遅くなります。最大値は600です。

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

• まず8ノードを追加します。その後、指数関数的にスケールアップし、最大値に達するまでに必要なステップ数を踏みます。
• ノードの90%が10分間ビジー状態でなく、コンピュートも30秒以上アイドル状態である場合にスケールダウンします。
• 1 ノードから指数関数的にスケールダウンします。

オートスケール with プール

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

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

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

オートスケール Example

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

初期サイズ	再構成後のサイズ
6	6
12	10
3	5

パフォーマンスの詳細設定

次の設定は、単純な形式のコンピュートUIの[ 高度なパフォーマンス ]セクションの下に表示されます。

• スポットインスタンス
• 自動終了
• Driverのタイプ

スポットインスタンス

スポットインスタンスを使用するかどうかを指定するには、[ Advanced performance] (アドバンストパフォーマンス ) の [ Use spot instance] (スポットインスタンスを使用 ) チェックボックスをオンにします。スポット価格AWSを参照してください。

自動終了

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

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

ドライバーの種類

[高度なパフォーマンス ] セクションでドライバーの種類を選択できます。ドライバー ノードは、コンピュート リソースに接続されているすべてのノートブックの状態情報を保持します。 ドライバー ノードは、SparkContext も保持し、コンピュート リソース上のノートブックまたはライブラリから実行するすべてのコマンドを解釈し、Apache Spark Sparkエグゼキューターと調整する マスターを実行します。

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

ヒント

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

タグ

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

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

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

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

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

詳細設定

次の設定は、シンプル フォーム コンピュート UI の [詳細設定 ] セクションの下に表示されます。

• アクセスモード
• インスタンスプロファイル
• アベイラビリティゾーン
• ローカルストレージのオートスケールを有効化
• EBS ボリューム
• ローカルディスクの暗号化
• Spark構成
• 環境変数
• コンピュートログのデリバリー

アクセスモード

アクセス モードは、コンピュート リソースを使用できるユーザーと、コンピュート リソースを使用してアクセスできるデータを決定するセキュリティ機能です。 Databricks内のすべてのコンピュート リソースにはアクセス モードがあります。アクセスモードの設定は、シンプルフォームのコンピュートUIの [詳細設定 ]セクションにあります。

アクセスモードの選択は Auto by Default で、選択した Databricks Runtimeに基づいてアクセスモードが自動的に選択されます。 機械学習ランタイムと Databricks ランタイムが 14.3 より低い デフォルトから Dedicated に、それ以外の場合は Standard が使用されます。

Databricks では、すべてのワークロードに標準アクセス モードを使用することをお勧めします。 専用アクセスモードは、必要な機能が標準アクセスモードでサポートされていない場合にのみ使用してください。

アクセスモード	ユーザーに表示	UCサポート	対応言語	注
専用 (以前のシングルユーザー)	いつも	あり	Python、SQL、Scala、R	1 人のユーザーまたはグループに割り当てて使用できます。
スタンダード(旧共有)	いつも	あり	Python、 SQL、 Scala ( Databricks Runtime 13.3 LTS 以降を使用した Unity Catalog 対応コンピュート)	ユーザー間でデータを分離することにより、複数のユーザーが使用できます。

これらの各アクセス モードの機能サポートの詳細については、「Unity Catalogのコンピュート アクセス モードの制限」を参照してください。

注記

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

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

注記

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

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

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

Python

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

警告

コンピュート リソースがインスタンスプロファイルを使用して起動すると、このコンピュート リソースへのアタッチ アクセス許可を持つすべてのユーザーが、このロールによって制御される基になるリソースにアクセスできます。 不要なアクセスを防ぐには、 コンピュート パーミッション を使用して、コンピュート リソースへのパーミッションを制限します。

可用性ゾーン

アベイラビリティーゾーンの設定を見つけるには、「 Advanced 」セクションを開き、「 Instances」 タブをクリックします。 この設定では、コンピュート リソースで使用するアベイラビリティーゾーン (AZ) を指定できます。 デフォルトでは、この設定は auto に設定されており、ワークスペースサブネットで使用可能な IP に基づいて AZ が自動的に選択されます。 自動 AZ は、AWS が容量不足エラーを返した場合、他のアベイラビリティーゾーンで再試行します。

注記

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

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

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

「オートスケール・ローカル・ストレージを有効にする 」を構成するには、「 詳細 」セクションを開き、「 インスタンス 」タブをクリックします。

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

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

注記

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

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ボリュームタイプ」を参照してください。

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

備考

プレビュー

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

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

important

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

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

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

Spark の構成

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

1. コンピュートの設定ページで、[ 詳細設定 ] トグルをクリックします。

2. [ Spark ] タブをクリックします。

   

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

クラスターAPI を使用してコンピュートを設定する場合は、Spark spark_confcreate クラスターAPI []または[Update クラスター]API の [] フィールドに プロパティを設定します。

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

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

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

ini

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

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

ini

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

詳細については、「 シークレットの管理」を参照してください。

環境変数

コンピュート リソース上で実行されている initスクリプト からアクセスできるカスタム環境変数を設定します。 Databricks には、initスクリプトで使用できる定義済みの 環境変数 も用意されています。 これらの事前定義された環境変数を上書きすることはできません。

1. コンピュートの設定ページで、[ 詳細設定 ] トグルをクリックします。

2. [ Spark ] タブをクリックします。

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

   

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

コンピュート ログのデリバリー

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

ログの配信場所を設定するには、以下の手順に従ってください。

1. [コンピュート] ページで、[ 詳細設定 ] トグルをクリックします。
2. [ ロギング ] タブをクリックします。
3. 宛先タイプを選択します。
4. ログパス を入力します。

ログを保存するために、 Databricks は選択したログ パスに、コンピュートのcluster_idにちなんで名付けられたサブフォルダを作成します。

たとえば、指定したログパスが /Volumes/catalog/schema/volumeの場合、 06308418893214 のログは /Volumes/catalog/schema/volume/06308418893214。

注記

ボリュームへのログの配信は パブリック プレビュー 段階であり、Unity Catalog 対応のコンピュート (Standard または Dedicated アクセス モード) でのみサポートされます。 パスとしてボリュームを選択する場合は、ボリュームに対する READ VOLUME 権限と WRITE VOLUME 権限があることを確認してください。ボリュームの権限とはを参照してください。

S3 バケットの送信先

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

JSON

{
  "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を参照してください。