Databricks

Databricks Single User computeの権限境界とML/SQL実行の違い

2026-03-26
更新: 2026-03-27
NicheeLab編集部

Databricksのコンピュートには複数のアクセスモードがありますが、Single Userモードは「1人のユーザー専用」で動作する最も柔軟なモードです。 ML開発・分散学習・低レベルSpark API(RDD / SparkContext)のすべてを利用できる唯一のモードであり、 Unity Catalog下では「アタッチしたユーザーの資格情報」でデータアクセスが制御されます。

この記事では、Single Userモードの実行アイデンティティの仕組み、UC下での権限境界、 MLワークロードとSQL実行パスの具体的な違いを整理し、試験で問われるポイントと実務設計の判断基準を解説します。

Single Userアクセスモードとは

Single Userは、クラスタを1人のユーザーに専有させるアクセスモードです。 クラスタ作成時に「Single User」を選択し、対象ユーザーを指定すると、そのユーザー以外はクラスタにアタッチできません。 ノートブックの同時利用ができないため、チーム共有には向きませんが、以下の点で他のモードにはない優位性があります。

  • MLランタイム(DBR ML)が利用可能:GPU / 分散学習 / ML系ライブラリの完全サポート
  • RDD・SparkContext・低レベルAPIの使用が可能
  • カスタムUDF(Python / Scala)の制限なし
  • init scripts / ライブラリインストールの制限なし
  • クレデンシャルパススルー相当の動作:アタッチユーザーの権限でデータにアクセス

実行アイデンティティの仕組み

Single Userモードの最も重要な特性は「実行アイデンティティ」です。 このモードでは、クラスタ上で実行されるすべてのコード(SQL / Python / Scala / R)が、 アタッチされたユーザーの資格情報(credential)で実行されます。

具体的には、以下のような動作になります。

操作使用されるアイデンティティ影響
ノートブックからUCテーブルにSELECTアタッチしたユーザーそのユーザーへのGRANTが必要
ノートブックからクラウドストレージを直接読み取りアタッチしたユーザー(External Location経由)READ_FILES権限が必要
ジョブとして実行ジョブオーナー(≠ クラスタ指定ユーザーの場合あり)ジョブオーナーのGRANTが必要
DLTパイプラインパイプラインオーナーDLTはSingle User専用クラスタを内部で起動

この「誰の権限でアクセスするか」を正確に理解することが、試験でも実務でも重要です。 特にジョブ実行時は、クラスタにアタッチされたユーザーではなくジョブオーナーの権限が使われるため、 「ノートブックでは読めたテーブルがジョブにすると読めない」というトラブルの原因になります。

Unity Catalog下での権限境界

Unity Catalog(UC)環境では、Single Userモードはデータガバナンスの最小単位として機能します。 UCが有効なワークスペースでは、データアクセスは必ずUCの権限モデル(GRANT / DENY)を通過します。

権限境界を理解するための重要ポイントは以下の通りです。

  • カタログ→スキーマ→テーブルの3層権限:上位でUSE CATALOGとUSE SCHEMAを持たないと、 テーブルへのSELECT権限があっても実質アクセスできない
  • クラスタのアクセスモードとUC権限は独立:Single Userモードだからといって すべてのデータが見えるわけではなく、あくまでそのユーザーに付与されたGRANTの範囲に制限される
  • External Locationの権限:クラウドストレージを直接読み書きする場合は、 UCのExternal Locationに対するREAD_FILES / WRITE_FILESが必要
  • ストレージクレデンシャルとの関係:Single Userモードではストレージクレデンシャルが 透過的に使われるが、ユーザーがcredentialに対するACCESS権限を持つ必要がある

MLワークロードとSQL実行パスの違い

Single Userクラスタ上でMLワークロードを実行する場合と、SQLを実行する場合では、 内部的な処理パスが大きく異なります。この違いを以下の比較表で整理します。

項目MLワークロード(Python / DBR ML)SQL実行(ノートブックSQL / Spark SQL API)
実行エンジンSparkドライバ上のPythonプロセス + SparkワーカーSpark SQLエンジン(Catalyst → Photon)
Photon高速化非対応(Pandas UDF等はPythonプロセスで実行)対応(Photon有効クラスタの場合)
UC権限チェックテーブル読み書き時にチェッククエリ解析時にチェック
分散処理Horovod / TorchDistributor / Spark ML PipelineSparkの標準並列処理
ライブラリ制限なし(pip install自由)なし(UDF定義も可能)
GPU利用対応(GPUクラスタ選択時)非対応(GPU活用されない)
MLflow連携自動ログ対応(autolog)手動で記録する必要あり

SQL実行のパス:ノートブックSQL vs SQL Warehouse

Databricksで「SQLを実行する」場合、Single Userクラスタ上でSQLを実行する方法と、 Databricks SQL Warehouse(Serverless / Pro / Classic)を使う方法の2つがあります。 両者の違いを整理します。

比較項目Single UserクラスタでのSQLSQL Warehouse
コンピュートリソースユーザー専有クラスタ共有型のSQL最適化エンジン
PhotonPhoton有効クラスタのみ標準搭載
Python / Scala混在可能不可(SQL専用)
コスト特性クラスタ起動中は常に課金Serverlessなら自動停止・按分課金
実行アイデンティティアタッチユーザークエリ実行ユーザー
BI接続(JDBC/ODBC)非推奨推奨

試験では「ETLパイプラインでPythonとSQLを混在させたい場合はどのコンピュートを使うべきか」 という形で問われます。答えはSingle Userクラスタ(またはJob Cluster)であり、SQL WarehouseではPythonが使えません。

DLTパイプラインとジョブクラスタの関係

Delta Live Tables(DLT)パイプラインは、内部でSingle User相当のクラスタを自動的に起動します。 ユーザーがクラスタを明示的に構成する必要はなく、DLTランタイムが適切な設定を行います。 この場合の実行アイデンティティはパイプラインオーナーです。

ジョブクラスタ(Job Cluster)も通常はSingle Userモードで作成されます。 ジョブ定義時に「Single User」を指定し、ジョブオーナーの権限でデータにアクセスします。 All-Purpose Clusterとは異なり、ジョブ終了後に自動的にクラスタが破棄されるため、コスト効率が高くなります。

実務での設計指針

Single Userモードを実務で使う際のベストプラクティスは以下の通りです。

  • ML開発には常にSingle User + DBR ML:SharedモードではMLランタイムを選択できないため、 ML系の開発は必ずSingle Userで行う
  • Cluster Policyで自動終了を強制:Single Userは1人専用のためアイドル時間が長くなりやすい。 autotermination_minutesをPolicy経由で10〜30分に制限する
  • 開発用と本番ジョブ用を分離:開発はAll-Purpose Cluster(Single User)、 本番はJob Cluster(Single User)で分けることで、コスト追跡と権限管理を明確化する
  • Instance Poolとの併用:Single Userクラスタは頻繁に起動・停止されるため、 Instance Poolでインスタンスを事前確保しておくと起動時間を30秒〜1分程度に短縮できる

試験で問われるポイント

Single Userモードに関する出題は、Data Engineer Associate / ML Associate / ML Professionalで頻出です。 主な出題パターンは以下の通りです。

  • 「MLモデルの分散学習を行うために必要なアクセスモードは?」→ Single User
  • 「SharedモードとSingle Userモードの違いは?」→ RDD使用可否、ML対応、同時利用不可など
  • 「ジョブ実行時の実行アイデンティティは?」→ ジョブオーナー(クラスタアタッチユーザーではない)
  • 「DLTパイプラインのコンピュートモードは?」→ 内部でSingle User相当が自動構成される
  • 「UCテーブルにアクセスできない原因は?」→ USE CATALOG / USE SCHEMA権限の不足

問題で確認

ML Associate / ML Professional

問題 1

データサイエンティストがDatabricksノートブックでPyTorchを使った分散学習を行いたい。Unity Catalogが有効な環境で最も適切なクラスタ構成はどれか。

  1. Sharedモードのクラスタにアタッチし、PyTorchをpip installする
  2. Single Userモードのクラスタ(DBR MLランタイム)を作成し、TorchDistributorを使用する
  3. SQL Warehouseに接続し、PyTorch UDFを登録する
  4. No Isolation Sharedモードのクラスタを使い、GPUノードを追加する

正解: B

PyTorchの分散学習にはDBR MLランタイムとTorchDistributorが必要であり、これらはSingle Userモードでのみサポートされます。SharedモードではMLランタイムが選択できず、SQL WarehouseはSQL専用です。No Isolation SharedモードはUCが有効な環境では使用できません。

よくある質問

Single UserモードでUnity Catalogの権限チェックはどのように行われますか?

クラスタにアタッチしたユーザーの資格情報(credential)がすべてのデータアクセスに使用されます。ノートブックからUCテーブルへSELECTを発行すると、そのユーザーに対するGRANT有無がチェックされ、権限がなければAccessDeniedになります。ジョブとして実行する場合はジョブオーナーの資格情報が使われるため、開発者とジョブオーナーで見えるデータが異なる点に注意が必要です。

Single UserクラスタでMLライブラリ(scikit-learn, TensorFlowなど)を使うことはできますか?

はい。Single Userモードは唯一MLランタイム(DBR ML)を完全サポートするアクセスモードです。scikit-learn、TensorFlow、PyTorch、Hugging Faceなどのライブラリに加え、分散学習(Horovod / TorchDistributor)もSingle Userでのみ利用できます。SharedモードではMLランタイム自体が選択できないため、ML系ワークロードにはSingle Userが必須です。

Single UserモードとSharedモードのどちらを選ぶべきですか?

判断軸は「ML/分散学習/カスタムUDFが必要か」と「コスト効率を優先するか」の2つです。ML開発や低レベルAPI(RDD, SparkContext)が必要ならSingle User一択です。ETLやSQLベースの分析で複数人が同じクラスタを共有してコストを抑えたい場合はSharedが適します。試験ではこの使い分けが頻出です。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Databricks

Databricks資格一覧|全7試験・難易度・勉強法

Databricks認定資格全7試験の一覧・難易度・出題範囲・合格ラインを徹底解説。2026年最新版の公式試験ガイドに準...

Databricks

Databricks試験の難易度ランキング|全7資格を徹底比較

Databricks認定全7試験の難易度をランキング形式で徹底比較。合格率・学習時間・出題傾向から難易度を分析。...

Databricks

Databricks資格の勉強方法|最短合格ルートと学習時間の目安

Databricks認定資格に最短で合格するための勉強方法を完全ガイド。公式リソース・問題集・学習スケジュールを徹底解説...

Databricks

Databricks Data Engineer Associate完全解説|出題範囲・問題例・合格戦略

Databricks Certified Data Engineer Associate試験を徹底解説。5つの出題ドメイ...

Databricks

Databricks Data Engineer Professional完全解説|上級試験の攻略法

Databricks Certified Data Engineer Professional試験を徹底解説。10の出題...

Databricksの記事一覧 (105件)
© 2026 NicheeLab All rights reserved.