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

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

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

この記事で説明する構成と管理ツールは、汎用コンピュートとジョブ コンピュートの両方に適用されます。 ジョブ コンピュートの構成に関する考慮事項の詳細については、 「ジョブで 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 アクセラレーションを使用する

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

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 対応コンピュート」を参照してください。

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

AWSグラビトンインスタンスタイプ

Databricks コンピュートは、 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 (サポート対象外) 以降。

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

  • AWS Graviton2 および Graviton3 プロセッサの場合。

注：

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

ARM64 ISA の制限事項

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

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

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

Gravitonの制限

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

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

注：

ワークスペースが 2023 年 5 月より前に作成された場合、アカウント管理者は、フリート インスタンス タイプを許可するようにワークスペースの IAMroll アクセス ポリシー権限を更新する必要がある場合があります。 必要な権限については、 「アクセス ポリシーの作成」を参照してください。

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

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

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

フリートの制限

  • ワーカー ノード タイプがフリート インスタンス タイプに設定されている場合、 [詳細オプション]の[最大スポット価格]設定は効果がありません。 これは、スポット価格の基準点として使用するオンデマンドインスタンスが 1 つもないためです。

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

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

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

[オートスケールを有効にする]がチェックされている場合、コンピュートのワーカーの最小数と最大数を指定できます。 次に、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

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

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

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

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

注：

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

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

プレビュー

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

コンピュートの実行に使用する一部のインスタンス タイプには、ローカルに接続されたディスクがある場合があります。 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) を指定できます。 デフォルトでは、この設定はautoに設定されており、ワークスペースのサブネットで使用可能な IP に基づいて AZ が自動的に選択されます。 AWS が容量不足エラーを返した場合、Auto-AZ は他のアベイラビリティーゾーンで再試行します。

注：

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

コンピュートに特定の AZ を選択すると、組織が特定のアベイラビリティ ゾーンでリザーブド インスタンスを購入した場合に主に役立ちます。 AWS アベイラビリティーゾーンについて詳しくは、こちらをご覧ください。

スポットインスタンス

スポットインスタンスを使用するかどうか、およびスポットインスタンスの起動時に使用する最大スポット料金を、対応するオンデマンド料金の割合として指定できます。 デフォルトでは、上限価格はオンデマンド価格の100%です。 AWSスポット価格を参照してください。

EBS ボリューム

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

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

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

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

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

  • Spark ワーカーによって使用される 150 GB の暗号化された EBS コンテナーのルートボリューム。 このホストされた Spark サービスとログ。

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

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

シャッフルボリュームを追加するには、[EBS Volume Type] ドロップダウンリストで [汎用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. 「環境変数」フィールドで 環境変数 を設定します。

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

クラスターの作成 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 を参照してください。