メインコンテンツまでスキップ

専用のコンピュート(旧シングルユーザーコンピュート)によるきめ細かなアクセス制御

この記事では、専用のコンピュートで実行されるクエリに対してきめ細かなアクセス制御を可能にするデータ フィルタリング機能について説明します。 専用コンピュートは、 専用 アクセスモードで構成したオールパーパスまたはジョブコンピュートです。 「アクセスモード」を参照してください。

データフィルタリング機能は、サーバレス コンピュートを使用して自動的に実行されます。

専用のコンピュートの一部のクエリでデータフィルタリングが必要なのはなぜですか?​

Unity Catalog では、次の機能を使用して、列レベルと行レベルで表形式データへのアクセスを制御できます (きめ細かなアクセス制御とも呼ばれます)。

参照されるテーブルからデータを除外するビュー、またはフィルターとマスクを適用するクエリ テーブルをクエリする場合は、次のコンピュート リソースのいずれかを制限なく使用できます。

  • SQLウェアハウス
  • Standard コンピュート (formerly shared コンピュート)

ただし、専用のコンピュートを使用してこのようなクエリを実行する場合、コンピュートとワークスペースは特定の要件を満たす必要があります。

専用のコンピュート リソースとワークスペースがこれらの要件を満たしている場合、きめ細かなアクセス制御を使用するビューまたはテーブルに対してクエリを実行するたびに、データ フィルタリングが自動的に実行されます。

マテリアライズドビュー、ストリーミングテーブル、標準ビューのサポート​

動的ビュー、行フィルター、列マスクに加えて、データ フィルターでは、 Databricks Runtime 15.3 以前で実行されている専用のコンピュートでサポートされていない次のビューとテーブルに対するクエリも有効になります。

Databricks Runtime 15.3 以前を実行している専用のコンピュートでは、ビューに対してクエリを実行するユーザーは、ビューが参照するテーブルとビューに対してSELECTを持っている必要があるため、ビューを使用してきめ細かなアクセス制御を提供することはできません。データ フィルタリングが可能な Databricks Runtime 15.4 では、ビューに対してクエリを実行するユーザーは、参照されているテーブルとビューにアクセスする必要はありません。

データフィルタリングは専用のコンピュートでどのように機能しますか?​

クエリが次のデータベース・オブジェクトにアクセスするたびに、専用のコンピュート リソースはクエリをサーバレス コンピュートに渡してデータ・フィルタリングを実行します。

  • ユーザーが SELECT 権限を持っていないテーブル上に構築されたビュー
  • ダイナミック ビュー
  • 行フィルターまたは列マスクが定義されたテーブル
  • マテリアライズド ビューとストリーミング テーブル

次の図では、ユーザーが table_1、 view_2、および table_w_rlsにSELECTがあり、行フィルターが適用されています。ユーザーは、 view_2によって参照される table_2にSELECTを持っていません。

データ フィルタリングのしくみを示す図

table_1 に対するクエリは、フィルター処理が不要なため、専用のコンピュート リソースによって完全に処理されます。view_2 と table_w_rls のクエリでは、ユーザーがアクセスできるデータを返すためにデータ フィルタリングが必要です。これらのクエリは、サーバレス コンピュートのデータ フィルタリング機能によって処理されます。

どのような費用がかかりますか?​

顧客は、データ フィルタリング操作を実行するために使用されるサーバーレス コンピュート リソースに対して課金されます。 価格情報については、 プラットフォーム ティアとアドオンを参照してください。

システム請求使用量テーブルをクエリして、請求された金額を確認できます。 たとえば、次のクエリは、コンピュートのコストをユーザー別に分類します。

SQL
SELECT usage_date,
sku_name,
 identity_metadata.run_as,
SUM(usage_quantity) AS `DBUs consumed by FGAC`
FROM system.billing.usage
WHERE usage_date BETWEEN '2024-08-01' AND '2024-09-01'
 AND billing_origin_product = 'FINE_GRAINED_ACCESS_CONTROL'
GROUP BY 1, 2, 3 ORDER BY 1;

データフィルタリングが行われているときのクエリパフォーマンスの表示​

専用のコンピュートの Spark UI には、クエリのパフォーマンスを理解するために使用できるメトリクスが表示されます。 コンピュート リソースに対して実行するクエリごとに、 SQL/Dataframe タブにクエリ グラフ表現が表示されます。 クエリがデータ フィルタリングに関与していた場合、UI ではグラフの下部に RemoteSparkConnectScan 演算子ノードが表示されます。 このノードには、クエリのパフォーマンスを調査するために使用できるメトリクスが表示されます。 「Apache Spark UI でコンピュート情報を表示する」を参照してください。

RemoteSparkConnectScan ノードを示す SparkUI

RemoteSparkConnectScan 演算子ノードを展開して、次のような質問に対処するメトリクスを表示します。

  • データのフィルタリングにはどのくらいの時間がかかりましたか? 「total remote execution time」を参照します。
  • データフィルタリング後にはいくつの行が残っていましたか? 「rows output」を参照します。
  • データ フィルタリング後に返されたデータの量 (バイト単位) はどれくらいですか? 「rows output size」を表示します。
  • パーティションプルーニングされ、ストレージから読み取る必要がなかったデータファイルはいくつありますか? 「Files pruned」と「Size of files pruned」を表示します。
  • プルーニングできず、ストレージから読み取らなければならなかったデータ・ファイルはいくつありますか。 「Files read」と「Size of files read」を表示します。
  • 読み取る必要があったファイルのうち、キャッシュにすでにいくつありましたか? 「Cache hits size」および「Cache misses size」を表示します。

制限​

  • 行フィルタまたは列マスクが適用されているテーブルに対するテーブルの書き込みまたは更新操作はサポートされていません。

    具体的には、 INSERT, DELETE、 UPDATE、 REFRESH TABLE、 MERGEなどの DML 操作はサポートされていません。 これらのテーブルからのみ (SELECT) を読み取ることができます。

  • Databricks Runtime 16.2 以前では、データフィルタリングが呼び出されると、これらのクエリが同じリモートテーブルの異なるスナップショットを返す可能性があるため、自己結合はデフォルトによってブロックされます。ただし、これらのコマンドを実行しているコンピュートで spark.databricks.remoteFiltering.blockSelfJoins を false に設定することで、これらのクエリを有効にすることができます。

    Databricks Runtime 16.3 以降では、スナップショットは dedicated リソースとサーバレス コンピュート リソース間で自動的に同期されます。この同期により、データ・フィルタリング機能を使用する自己ジョイン・クエリは同一のスナップショットを返し、デフォルトで有効になります。例外は、マテリアライズドビューと任意のビュー、マテリアライズドビュー、および Delta Sharingを使用して共有されるストリーミングテーブルです。 これらのオブジェクトの場合、自己結合はデフォルトによってブロックされますが、これらのコマンドを実行しているコンピュートで spark.databricks.remoteFiltering.blockSelfJoins を false に設定することで、これらのクエリを有効にできます。

    マテリアライズドビューと任意のビュー、マテリアライズドビュー、およびストリーミングテーブルに対して自己結合クエリを有効にする場合は、結合されるオブジェクトへの並列書き込みがないことを確認する必要があります。

  • イメージ Dockerはサポートされていません。

  • ワークスペースが 2024 年 11 月より前にファイアウォールを使用してデプロイされた場合は、ポート 8443 と 8444 を開いて、専用のコンピュートできめ細かなアクセス制御を有効にする必要があります。 「セキュリティグループ」を参照してください。

に最終更新