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

注記

この記事の構成は、単純な形式のコンピュート 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アクセラレーションを使用する

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

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

ワーカーノードタイプ

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

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

important

プリエンプティブル VM インスタンスをドライバーの種類として持つプールは使用しないでください。 オンデマンド ドライバーの種類を選択して、ドライバーが再利用されないようにします。 「プールへの接続」を参照してください。

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

ヒント

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

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

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

デフォルトのプロビジョニング済みワーカー・ノード・ストレージ

Databricksは、各ワーカーノードに対して次のストレージをプロビジョニングします。

• ホストオペレーティングシステムとDatabricks内部サービスによって使用される、インスタンスごとに1つのブートディスク。ブートディスクは、非GPUインスタンスでは100 GB、GPUインスタンスでは200 GBです。
• Spark ワーカーが使用するローカル SSD。 This ホストされたSpark サービスとログ。 各ローカル SSD は 375GB です。 アタッチされたローカル SSD の数を設定するには、「 ローカル SSD のインスタンスタイプ」を参照してください。
• ストレージのオートスケールが有効になっている場合のリモートSSD。これらは作成時に150GBから始まり、必要に応じてオートスケールされます。

GPU インスタンスタイプ

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

ローカル SSD を使用したインスタンスタイプ

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

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

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

クラスターAPIを使用してコンピュートリソースを作成するときに、コンピュートリソースにアタッチするローカルSSDの数を設定することができます。

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

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

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

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

単一ノードのプロパティ

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

• 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)

Enable オートスケール

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

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

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

注記

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

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

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

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

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

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

注記

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

注記

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

オートスケールの動作

オートスケールには、次の特性があります。

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

オートスケール with プール

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

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

オートスケール Example

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

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

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

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

• 優先インスタンス
• 自動終了
• Driverのタイプ

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

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

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

1. UI を使用してコンピュートを作成する場合は、[ Advanced performance ] の [ Use preemtible instances ] チェックボックスをオンにします。
2. UIを使用してインスタンスプールを作成する場合は、[ オンデマンド/プリエンプティブル ] を [ すべてのプリエンプティブル ]、[ プリエンプティブル（フォールバックGCP） ]、または [ オンデマンドGCP ] に設定します。プリエンプティブルVMインスタンスが利用できない場合、コンピュートはデフォルトのフォールバックとしてオンデマンドVMインスタンスを使用するようになっています。フォールバック動作を構成するには、gcp_attributes.gcp_availabilityをPREEMPTIBLE_GCPまたはPREEMPTIBLE_WITH_FALLBACK_GCPに設定します。デフォルトはON_DEMAND_GCPです。

JSON

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

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

自動終了

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

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

ドライバーの種類

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

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

ヒント

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

タグ

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

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

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

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

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

詳細設定

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

• アクセスモード
• Googleサービスアカウント
• アベイラビリティゾーン
• ローカルストレージのオートスケールを有効化
• ローカルディスクの暗号化
• Spark構成
• 環境変数
• コンピュート log delivery

アクセスモード

アクセス モードは、コンピュート リソースを使用できるユーザーと、コンピュート リソースを使用してアクセスできるデータを決定するセキュリティ機能です。 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スクリプトはどこでインストールできますか?」を参照してください。 および コンピュートスコープのライブラリ。

Google サービス アカウント

Google Identity を使用してこのコンピュート リソースを Google サービス アカウントに関連付けるには、[ 詳細設定 ]、[ Google サービス アカウント ] の順にクリックし、[ Google サービス アカウント ] フィールドに Google サービス アカウントの Eメール アドレスを追加します。 この値は、 GCS データソースと BigQuery データソースでの認証に使用されます。

important

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

可用性ゾーン

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

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

高可用性ゾーン

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

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

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

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

Databricksではローカルストレージをオートスケールするため、使用コンピュートのSparkワーカーで利用可能なディスクの空き容量が監視されます。ワーカーのディスク容量が不足し始めると、Databricksはディスク容量が不足する前に、ゾーンSSD PDのサイズを自動的に変更します。Zonal-SSD PDのボリュームは、インスタンスごとに合計5 TBのディスク容量（インスタンスのローカルストレージを含む）を上限としてアタッチされます。

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

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

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

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

   

注記

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

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

コンピュート log delivery

汎用コンピュートまたはジョブ コンピュートを作成するときに、 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 権限があることを確認してください。ボリュームの権限とはを参照してください。

注記

ボリュームへのコンピュート ログ配信は、 GCPの GKE アーキテクチャではサポートされていません。 この機能を使用するには、GCE アーキテクチャを更新してください。「GCE コンピュート デプロイのアクセス許可を更新する」を参照してください。

注記

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