コンピュート(レガシー)の設定
これらは、従来のクラスター作成 UI の手順であり、履歴の精度のためにのみ含まれています。 すべてのお客様は、 更新されたクラスター作成 UI を使用する必要があります。
CLI機能は、このリリースの時点でDatabricks on Google Cloudでは使用できません。
この記事では、 Databricks クラスターを作成および編集するときに使用できる構成オプションについて説明します。 UI を使用したクラスターの作成と編集に重点を置いています。 その他の方法については、 Databricks CLI、 クラスター ・ API、および Databricks Terraform ・プロバイダーを参照してください。
ニーズに最も適した構成オプションの組み合わせを決定する方法については、 クラスター構成のベスト・プラクティスを参照してください。
クラスターポリシー
クラスターポリシー は、一連のルールに基づいてクラスターを構成する機能を制限します。ポリシー ルールは、クラスターの作成に使用できる属性または属性値を制限します。 クラスターポリシーには、特定のユーザーとグループの使用を制限する ACL があるため、クラスターの作成時に選択できるポリシーが制限されます。
クラスターポリシーを設定するには、 ポリシー ドロップダウンでクラスターポリシーを選択します。
ワークスペースにポリシーが作成されていない場合、[ ポリシー ] ドロップダウンは表示されません。
お持ちの場合:
- クラスター create アクセス許可では、 Unrestricted ポリシーを選択し、完全に構成可能なクラスターを作成できます。 Unrestricted ポリシーは、クラスター属性や属性値を制限しません。
- クラスター作成権限とクラスターポリシーへのアクセスの両方で、 Unrestricted ポリシーとアクセス権を持つポリシーを選択できます。
- クラスターポリシー のみにアクセスするには、アクセスできるポリシーを選択できます。
クラスター モード
Databricks は、標準、高同時実行性、 単一ノードの 3 つのクラスター モードをサポートしています。 デフォルト クラスター モードは Standard です。
クラスターの作成後にクラスター モードを変更することはできません。 別のクラスター モードが必要な場合は、新しいクラスターを作成する必要があります。
クラスター構成には、 デフォルト値が クラスター モードに依存する自動終了 設定が含まれています。
- Standard クラスターと Single Node クラスターは、デフォルトによって 120 分後に自動的に終了します。
- High Concurrencyクラスター do not terminate automatically by デフォルト.
Standard クラスター
Standard モード クラスター (No Isolation Shared クラスターとも呼ばれます) は、ユーザー間の分離を行わずに、複数のユーザーで共有できます。 テーブル ACL なしで High Concurrencyクラスター モードを使用する場合は、Standard モードのクラスターと同じ設定が使用されます。アカウント 管理者は、これらの種類のクラスターでDatabricksワークスペース管理者の内部資格情報が自動的に生成されるのを防ぐことができます。より安全なオプションについては、 Databricks は High Concurrencyクラスターとテーブル ACL などの代替手段を推奨します。
Standard クラスターは、シングル ユーザーのみにお勧めします。 Standard クラスターでは、 Python、 SQL、R、 Scalaで開発されたワークロードを実行できます。
High Concurrencyクラスター
A High Concurrencyクラスターは、マネージド クラウド リソースです。 High Concurrencyクラスターの主な利点は、リソースの使用率を最大化し、クエリのレイテンシを最小限に抑えるためのきめ細かな共有を提供することです。
High Concurrencyクラスターは、 SQL、 Python、およびRで開発されたワークロードを実行できます。High Concurrencyクラスターのパフォーマンスとセキュリティは、ユーザーコードを別々のプロセスで実行することで提供されますが、これは Scalaでは不可能です。
さらに、High Concurrencyクラスターのみが テーブルアクセスコントロールをサポートします。
High Concurrencyクラスターを作成するには、 クラスター Mode を High Concurrency に設定します。
Single Node クラスター
Single Node クラスターには、ドライバー ノード上にワーカーと実行 Spark ジョブはありません。
これに対し、Standard クラスターでは、ジョブを実行するために、ドライバー ノードに加えて 、少なくとも 1 つの Spark ワーカー ノードSpark必要です。
シングル ノード クラスターを作成するには、 クラスター [ Mode ] を [シングル ノード ] に設定します。
Single Node クラスターの操作の詳細については、「 Single-node コンピュート」を参照してください。
プール
クラスターの開始時間を短縮するために、アイドル状態のインスタンスの事前定義された プール にクラスターをアタッチできます。 クラスターは、プール内のインスタンスを使用して作成されます。 要求されたドライバーまたはワーカーを作成するのに十分なアイドル状態のリソースがプールにない場合、プールはインスタンス プロバイダーから新しいインスタンスを割り当てることによって拡張されます。 アタッチされたクラスターが終了すると、そのインスタンスが使用していたインスタンスはプールに戻され、別のクラスターで再利用できます。
でのプールの操作の詳細については、プール設定リファレンスDatabricks を参照してください。
Databricks Runtime
Databricks ランタイムは、 クラスターで実行されるコアコンポーネントのセットです。 すべての Databricks ランタイムには Apache Spark が含まれており、使いやすさ、パフォーマンス、セキュリティを向上させるコンポーネントと更新プログラムが追加されています。 詳細については、Databricks Runtimeリリースノートのバージョンと互換性を参照してください。
Databricks では、クラスターを作成または編集するときに、いくつかのタイプのランタイムとそれらのランタイムタイプのいくつかのバージョンを [Databricks Runtimeバージョン ] ドロップダウンに用意しています。
Photon 加速
Photonは、Databricks Runtime 9.1LTS 以降 実行中のクラスターに使用できます。
Photonアクセラレーションを有効にするには、[ Photonアクセラレータを使用 ] チェックボックスを選択します。
必要に応じて、[ワーカータイプ]ドロップダウンでインスタンスタイプを指定できます。
Photonのアクティビティは Spark UIで表示できます。 次のスクリーンショットは、クエリの詳細 DAG を示しています。 DAGにはPhotonの2つの表示があります。 まず、Photon 演算子は "Photon" で始まります (例: PhotonGroupingAgg
)。 次に、DAGでは、Photonのオペレーターとステージは桃色で表示され、Photon以外のオペレーターとステージは青色で表示されます。
クラスターノードタイプ
クラスターは、1つのドライバーノードと0個以上のワーカーノードで構成されます。
ドライバーノードとワーカーノードに別々のクラウドプロバイダーインスタンスタイプを選択できますが、デフォルトでは、ドライバーノードはワーカーノードと同じインスタンスタイプを使用します。インスタンスタイプのファミリーが異なれば、メモリ集約型またはコンピュート集約型のワークロードなど、さまざまなユースケースに適合します。
ドライバーノード
ドライバー ノードは、クラスターに接続されているすべてのノートブックの状態情報を保持します。 また、ドライバー ノードは SparkContext を保持し、クラスター上のノートブックまたはライブラリから実行するすべてのコマンドを解釈し、Apache Spark Sparkエグゼキューターと調整する マスターを実行します。
ドライバーノードタイプのデフォルト値は、ワーカーノードタイプと同じです。Sparkワーカーから大量のデータをcollect()
により収集してノートブックで分析する場合は、より多くのメモリを備えたより大きなドライバーノードの種類を選択できます。
ドライバーノードは、アタッチされているノートブックのすべての状態情報を保持するため、未使用のノートブックは必ずドライバーノードからデタッチしてください。
ワーカーノード
Databricks ワーカー ノードは、クラスターが適切に機能するために必要な Spark エグゼキューターおよびその他のサービスを実行します。 Spark を使用してワークロードを分散すると、すべての分散処理がワーカー ノードで行われます。 Databricks ワーカー ノードごとに 1 つのエグゼキューターを実行します。したがって、 エグゼキューター と ワーカー という用語は、 Databricks アーキテクチャのコンテキストで同じ意味で使用されます。
Spark ジョブを実行するには、少なくとも 1 つのワーカーノードが必要です。クラスターのワーカーがゼロの場合、ドライバーノードでSpark以外のコマンドは実行できますが、Sparkコマンドは失敗します。
GPU インスタンスタイプ
ディープラーニングに関連するタスクのように、高いパフォーマンスが求められる計算難易度の高いタスクに対して、 Databricks はグラフィックス プロセッシング ユニット (GPU) で高速化されたクラスターをサポートしています。 詳細については、「 GPU 対応コンピュート」を参照してください。
ローカルSSDを使用したインスタンスタイプのクラスター
インスタンスタイプの最新リスト、それぞれの価格、ローカルSSDのサイズについては、GCPの料金見積もりを参照してください。
ローカルSSDを持つインスタンスタイプは、デフォルトのGoogle Cloudサーバー側暗号化で暗号化されます。
ローカル SSD を使用するインスタンスタイプでは、パフォーマンス向上のために ディスクキャッシュ が自動的に使用されます。 すべてのインスタンスタイプのキャッシュサイズは自動的に設定されるため、ディスク使用量を明示的に設定する必要はありません。
クラスター size and オートスケール
Databricksクラスターの作成時に、クラスターに一定数のワーカーを指定するか、クラスターのワーカーの最小数と最大数を指定できます。
固定サイズのクラスターを指定すると、Databricksによって、指定された数のワーカーがクラスターに配置されます。ワーカー数の範囲を指定すると、Databricksはジョブの実行に必要なワーカーの適切な数を選択します。これは オートスケーリング と呼ばれます。
オートスケールを使用すると、Databricksはジョブの特性を考慮してワーカーを動的にアカウントに再割り当てします。パイプラインの特定の部分は他の部分よりも計算負荷が高い場合があり、Databricksはジョブのこれらのフェーズ中にワーカーを自動的に追加(さらに、ワーカーが不要になったときにワーカーを削除)します。
オートスケーリングを使用すると、ワークロードに合わせてクラスターをプロビジョニングする必要がないため、クラスターの使用率を簡単に上げられます。これは、要件が時間の経過と共に変化するワークロード(1日の間にデータセットを探索するなど)の場合に特に当てはまりますが、プロビジョニング要件が不明な1回限りの短いワークロードの場合に当てはまります。オートスケーリングには次の2つの利点があります。
- ワークロードは、固定サイズのプロビジョニング不足のクラスターと比較して高速に実行できます。
- クラスターのオートスケーリングでは、静的サイズのクラスターと比較して全体的なコストを削減できます。
クラスターとワークロードの固定サイズに応じて、オートスケーリングでは、これらの利点の一方または両方が同時に実現されます。クラスターのサイズは、クラウドプロバイダーがインスタンスを終了するときに選択されたワーカーの最小数を下回る可能性があります。 この場合、Databricks は、ワーカーの最小数を維持するために、インスタンスの再プロビジョニングを継続的に再試行します。
オートスケールはspark-submit
ジョブでは使用できません。
オートスケールの動作
- 2つのステップで最小から最大にスケールアップします。
- クラスターがアイドル状態でない場合でも、シャッフル ファイルの状態を調べることでスケールダウンできます。
- 現在のノードの割合に基づいてスケールダウンします。
- ジョブクラスターでは、過去40秒間にクラスターが十分に活用されていない場合にスケールダウンします。
- All-Purposeクラスターでは、過去150秒間にクラスターが十分に活用されていない場合にスケールダウンします。
spark.databricks.aggressiveWindowDownS
Spark 構成プロパティは、クラスターがダウンスケーリングの決定を行う頻度を秒単位で指定します。値を大きくすると、クラスターのスケールダウンが遅くなります。 最大値は600です。
オートスケールの有効化と構成
Databricksでクラスターのサイズを自動的に変更できるようにするには、クラスターのオートスケーリングを有効にし、ワーカーの最小範囲と最大範囲を指定します。
-
オートスケーリングを有効にします。
-
All-Purposeクラスター - [Create clustering]ページで、[ Autopilot Options ]ボックスの[ Enable autoscale ]チェックボックスをオンにします。
-
ジョブ クラスター - [クラスターの構成] ページで、[ オートパイロット オプション ] ボックスの [ オートスケールを有効にする ] チェック ボックスをオンにします。
-
-
ワーカーの最小数と最大数を設定します。
クラスターが実行中の場合、割り当てられたワーカーの数がクラスターの詳細ページに表示されます。割り当てられたワーカーの数をワーカーの設定と比較し、必要に応じて調整を行うことができます。
インスタンス・プールを使用している場合:
- 要求されたクラスター サイズが アイドル インスタンスの最小数以下であることを確認してください プールで。 これより大きい場合、クラスターの開始時間は、プールを使用しないクラスターと同じになります。
オートスケール Example
静的クラスターをオートスケーリングクラスターとして再構成すると、Databricksは最小範囲と最大範囲内でクラスターのサイズをただちに変更し、オートスケーリングを開始します。例として、次の表は、5~10ノードをオートスケーリングするようにクラスターを再構成した場合に、特定の初期サイズのクラスターに何が起こるかを示しています。
初期サイズ | 再構成後のサイズ |
---|---|
6 | 6 |
12 | 10 |
3 | 5 |
Google Cloud の構成
クラスターの Google Cloud インスタンスを設定するときに、Google Cloud 固有のオプションを指定できます。
プリエンプティブル インスタンスの使用
プリエンプティブル VM インスタンスは、通常のインスタンスよりもはるかに低価格で作成および実行できるインスタンスです。ただし、Google Cloud は、他のタスクのためにこれらのリソースにアクセスする必要がある場合、これらのインスタンスを停止(プリエンプト)することがあります。 プリエンプティブルインスタンスは Google コンピュートエンジンの容量を余分に使用するため、可用性は使用状況によって異なります。
新しいクラスターを作成するときは、次の 2 つの方法でプリエンプティブル VM インスタンスを有効にできます。
- UI を使用してクラスターを作成する場合は、 ワーカーの [タイプ ] 詳細の横にある [プリエンプティブル インスタンス ] をクリックできます。
- 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": {
"gcp_availability": "PREEMPTIBLE_GCP"
}
}
次に、新しいクラスターを作成し、 プール をプリエンプティブル インスタンス プールに設定します。
Google サービス アカウント
Google Identity を使用してこのクラスターを Google サービス アカウントに関連付けるには、[ 詳細オプション ] をクリックし、[ Google サービス アカウント ] フィールドに Google サービス アカウントの Eメール アドレスを追加します。 この値は、 GCS データソースと BigQuery データソースでの認証に使用されます。
GCSおよびBigQueryデータソースへのアクセスに使用するサービスアカウントは、Databricksアカウントの設定時に指定したサービスアカウントと同じプロジェクトである必要があります。
ローカルディスクの暗号化
ローカル SSD を持つインスタンスタイプは、デフォルトの Google Cloud サーバー側の暗号化で暗号化されます。 「ローカルSSDを使用したインスタンスタイプのクラスター」を参照してください。
Spark の構成
ジョブ Spark 微調整するために、クラスター構成でカスタム Spark 構成プロパティ を指定できます。
-
クラスター構成ページで、[ 詳細オプション ] トグルをクリックします。
-
[ Spark ] タブをクリックします。
Spark構成 では、1行に1つのキーと値のペアとして設定プロパティを入力します。
クラスターを使用してクラスターを設定する場合は、API Sparkspark_conf
新しいクラスターAPI データの作成API または クラスター設定の更新 の フィールドで プロパティを設定します。
シークレットから Spark 構成プロパティを取得する
Databricks では、パスワードなどの機密情報をプレーンテキストではなく シークレット に格納することをお勧めします。 Spark 構成でシークレットを参照するには、次の構文を使用します。
spark.<property-name> {{secrets/<scope-name>/<secret-name>}}
たとえば、password
というSpark構成プロパティをsecrets/acme_app/password
に保存されているシークレットの値に設定するには、次のようにします。
spark.password {{secrets/acme-app/password}}
詳細については、「 シークレットの管理」を参照してください。
環境変数
クラスタで実行されている initスクリプト からアクセスできるカスタム環境変数を設定できます。 Databricks には、initスクリプトで使用できる定義済みの 環境変数 も用意されています。 これらの事前定義された環境変数を上書きすることはできません。
-
クラスター構成ページで、[ 詳細オプション ] トグルをクリックします。
-
[ Spark ] タブをクリックします。
-
[ 環境変数 ] フィールドで環境変数を設定します。
「 Create new クラスター API 」または「 Update clustering」設定 APIの spark_env_vars
フィールドを使用して、環境変数を設定することもできます。
クラスタータグ
クラスタータグを使用すると、組織内のさまざまなグループで使用されるクラウド リソースのコストを簡単に監視できます。 クラスターの作成時にキーと値のペアとしてタグを指定でき、Databricks はこれらのタグを GKE クラスター上の Databricks Runtime Pod と永続ボリュームに適用し、Databricks DBU の使用状況レポートで使用します。
アカウントコンソールのDatabricks課金利用グラフでは、タグごとに利用状況を集計できます。同じページからダウンロードした課金利用 CSV レポートには、デフォルトタグとカスタムタグも含まれています。 タグは GKE ラベルと GCE ラベルにも伝播します。
プールタグとクラスタータグのタイプがどのように連携するかについての詳細な情報については、「 タグを使用した属性の使用」を参照してください。
便宜上、 Databricks では、Vendor
、Creator
、ClusterName
、ClusterId
の 4 つのデフォルト タグを各クラスターに適用します。
さらに、ジョブ クラスターでは、 Databricks は RunName
と JobId
の 2 つのデフォルト タグを適用します。
キー Name
を持つカスタム タグをクラスターに割り当てないでください。 すべてのクラスターには、 Databricksによって値が設定されるタグ Name
があります。 キー Name
に関連付けられた値を変更すると、クラスターは Databricksで追跡できなくなります。 その結果、クラスターはアイドル状態になった後に終了せず、引き続き使用コストが発生します。
クラスターを作成するときに、カスタムタグを追加できます。 クラスタータグを設定するには:
-
クラスター構成ページで、[ 詳細オプション ] トグルをクリックします。
-
ページの下部にある [ タグ ] タブをクリックします。
-
各カスタムタグにキーと値のペアを追加します。 最大 54 個のカスタムタグを追加できます。
クラスターへのSSHアクセス
クラスター SSH は、このリリースではサポートされていません。
関連する機能については、Databricks Webターミナルの実行 シェル コマンドを参照してください。
クラスター ログ配信
クラスターを作成するときに、 Spark ドライバーノード、ワーカーノード、およびイベントのログを配信する場所を指定できます。 ログは、選択した宛先に 5 分ごとに配信されます。 クラスターが終了すると、 Databricks は、クラスターが終了するまでに生成されたすべてのログを配信することを保証します。
ログの保存先は、クラスター ID によって異なります。 指定した宛先が
dbfs:/cluster-log-delivery
、 0630-191345-leap375
のクラスターログは
dbfs:/cluster-log-delivery/0630-191345-leap375
。
ログの配信場所を設定するには、以下の手順に従ってください。
-
クラスター構成ページで、[ 詳細オプション ] トグルをクリックします。
-
[ ロギング ] タブをクリックします。
-
宛先タイプを選択します。
-
クラスター ログ パスを入力します。
ログパスは
dbfs:/
で始まるDBFSパスでなければなりません。
この機能は、REST APIでも使用できます。クラスターAPIを参照してください。
initスクリプト
クラスターノードの初期化(initスクリプト)は、Sparkドライバまたはワーカー が起動する 前の 各クラスターノードの起動中に実行されるシェルスクリプトです。JVMinitスクリプトを使用して、 Databricks ランタイムに含まれていないパッケージとライブラリをインストールしたり、 JVM システムクラスパスを変更したり、 JVMが使用するシステムプロパティと環境変数を設定したり、 Spark 構成パラメーターを変更したりできます。
initスクリプトをクラスターにアタッチするには、 Advanced Options セクションを展開し、 initスクリプト タブをクリックします。
詳細な手順については、 initスクリプトとはを参照してください。