Contrôle d’accès affiné sur le calcul dédié

Le contrôle d’accès affiné vous permet de restreindre l’accès à des données spécifiques à l’aide de vues, de filtres de lignes et de masques de colonne. Cette page explique comment le calcul serverless est utilisé pour appliquer des contrôles d’accès affinés sur des ressources de calcul dédiées.

Spécifications

Pour utiliser le calcul dédié pour interroger une vue ou une table avec des contrôles d’accès affinés :

• La ressource de calcul dédiée doit se trouver sur Databricks Runtime 15.4 LTS ou version ultérieure.
• L’espace de travail doit être activé pour le calcul serverless.

Si votre ressource de calcul dédiée et votre espace de travail répondent à ces exigences, le filtrage des données est exécuté automatiquement.

Fonctionnement du filtrage des données sur le calcul dédié

Chaque fois qu’une requête accède à un objet de base de données avec des contrôles d’accès affinés, la ressource de calcul dédiée transmet la requête au calcul serverless de votre espace de travail pour effectuer le filtrage des données. Les données filtrées sont ensuite transférées entre le calcul serverless et dédié à l’aide de fichiers temporaires sur le stockage cloud interne de l’espace de travail.

Cette fonctionnalité s’applique aux objets de base de données suivants :

• Vues dynamiques
• Tableaux avec des filtres de lignes ou des masques de colonne
• Vues construites sur des tables sur lesquelles l’utilisateur ne dispose pas du privilège SELECT
• Vues matérialisées
• Tables de streaming

Dans le diagramme suivant, un utilisateur a le SELECT privilège sur table_1, view_2et table_w_rls, qui a des filtres de lignes appliqués. L’utilisateur n’a pas le SELECT privilège sur table_2, qui est référencé par view_2.

La requête sur table_1 est entièrement gérée par la ressource de calcul dédiée, car aucun filtrage n’est requis. Les requêtes sur view_2 et table_w_rls nécessitent le filtrage des données pour retourner les données auxquelles l’utilisateur a accès. Ces requêtes sont gérées par la capacité de filtrage des données sur le calcul serverless.

Prise en charge des opérations d’écriture

Dans Databricks Runtime 16.3 et versions ultérieures, vous pouvez écrire dans des tables qui ont des filtres de lignes ou des masques de colonne appliqués à l’aide des options suivantes :

• La commande SQL MERGE INTO, que vous pouvez utiliser pour les fonctionnalités INSERT, UPDATE et DELETE.
• Opération de fusion Delta.
• L'API DataFrame.write.mode("append").

Pour obtenir les fonctionnalités de INSERT, UPDATE et DELETE, vous pouvez utiliser une table intermédiaire ainsi que les clauses MERGE INTO et WHEN MATCHED de l'instruction WHEN NOT MATCHED.

Voici un exemple d’utilisation de UPDATE avec MERGE INTO:

MERGE INTO target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN MATCHED THEN
  UPDATE SET
    t.column1 = s.column1,
    t.column2 = s.column2;

Voici un exemple d’utilisation de INSERT avec MERGE INTO:

MERGE INTO target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN NOT MATCHED THEN
INSERT (id, column1, column2) VALUES (s.id, s.column1, s.column2);

Voici un exemple de DELETE à l’aide de MERGE INTO :

MERGE INTO target_table AS t
USING source_table AS s ON t.id = s.id
WHEN MATCHED AND s.some_column = TRUE THEN DELETE;

Prise en charge de DDL, SHOW, DESCRIBE et d’autres commandes

Dans Databricks Runtime 17.1 et versions ultérieures, vous pouvez utiliser les commandes suivantes en combinaison avec des objets contrôlés par accès précis sur le calcul dédié :

• Déclarations DDL
• Instructions SHOW
• Instructions DESCRIBE
• OPTIMIZE
• DESCRIBE HISTORY
• FSCK REPAIR TABLE (Databricks Runtime 17.2 et versions ultérieures)

Si nécessaire, ces commandes s’exécutent automatiquement sur le calcul serverless.

Certaines commandes ne sont pas prises en charge, notamment VACCUM, RESTOREet REORG TABLE.

Coûts de calcul serverless

Les clients sont facturés pour les ressources de calcul serverless qui effectuent des opérations de filtrage des données. Pour plus d’informations sur la tarification, consultez Niveaux et modules complémentaires de plateforme.

Les utilisateurs disposant d’un accès peuvent interroger la system.billing.usage table pour voir combien ils ont été facturés. Par exemple, la requête suivante décompose les coûts de calcul par utilisateur :

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;

Afficher le niveau de performance des requêtes lorsque le filtrage des données est activé

L’interface utilisateur Spark pour le calcul dédié affiche les métriques que vous pouvez utiliser pour comprendre les performances de vos requêtes. Pour chaque requête que vous exécutez sur la ressource de calcul, l’onglet SQL/Dataframe affiche la représentation du graphique de requête. Si une requête a été impliquée dans le filtrage des données, l’interface utilisateur affiche un nœud opérateur RemoteSparkConnectScan au bas du graphique. Ce nœud affiche les métriques que vous pouvez utiliser pour examiner le niveau de performance des requêtes. Consultez Afficher les informations de calcul dans l’interface utilisateur Spark.

Développez le nœud d’opérateur RemoteSparkConnectScan pour voir les métriques qui répondent aux questions suivantes :

• Combien de temps le filtrage des données a-t-il pris ? Afficher la « durée totale d’exécution à distance ».
• Combien reste-t-il de lignes après le filtrage des données ? Afficher la « sortie des lignes ».
• Quelle quantité de données (en octets) a été retournée après le filtrage des données ? Afficher la « taille de la sortie des lignes ».
• Combien de fichiers de données ont été supprimés de la partition et n’ont pas eu besoin d’être lus à partir du stockage ? Afficher les « fichiers nettoyés » et la « taille des fichiers nettoyés ».
• Combien de fichiers de données n’ont pas pu être nettoyés et ont dû être lus à partir du stockage ? Afficher les « fichiers lus » et la « taille des fichiers lus ».
• Parmi les fichiers qui devaient être lus, combien étaient déjà présents dans le cache ? Afficher la « taille des correspondances dans le cache » et « taille des absences de correspondance dans le cache ».

Limitations

• Seules les lectures par lots sont prises en charge sur les tables de streaming. Les tables avec des filtres de lignes ou des masques de colonne ne prennent pas en charge les charges de travail de streaming sur le calcul dédié.

• Impossible de modifier le catalogue par défaut (spark.sql.catalog.spark_catalog).

• Dans Databricks Runtime 16.2 et ci-dessous, il n’existe aucune prise en charge des opérations d’écriture ou d’actualisation des tables sur les tables qui ont des filtres de lignes ou des masques de colonne appliqués.

  Plus précisément, les opérations DML, telles que INSERT, DELETE, UPDATE, REFRESH TABLE et MERGE, ne sont pas prises en charge. Vous pouvez uniquement lire (SELECT) à partir de ces tables.

• Dans Databricks Runtime 16.3 et versions ultérieures, écrivez des opérations de table telles que INSERT, DELETEet UPDATE ne sont pas prises en charge, mais peuvent être effectuées à l’aide MERGE, qui est prise en charge.

• Dans Databricks Runtime 16.2 et ci-dessous, les jointures autonomes sont bloquées par défaut lorsque le filtrage des données est appelé, car ces requêtes peuvent retourner des captures instantanées différentes de la même table distante. Toutefois, vous pouvez activer ces requêtes en définissant spark.databricks.remoteFiltering.blockSelfJoinsfalse sur le calcul sur lequel vous exécutez ces commandes.

  Dans Databricks Runtime 16.3 et versions ultérieures, les instantanés sont automatiquement synchronisés entre les ressources de calcul dédiées et serverless. En raison de cette synchronisation, les requêtes de jointure automatique qui utilisent la fonctionnalité de filtrage des données retournent des instantanés identiques et sont activées par défaut. Les exceptions sont des vues matérialisées et toutes les vues, vues matérialisées et tables de diffusion en continu partagées via Delta Sharing. Pour ces objets, les jointures autonomes sont bloquées par défaut, mais vous pouvez activer ces requêtes en définissant spark.databricks.remoteFiltering.blockSelfJoins la valeur false sur le calcul sur lequel vous exécutez ces commandes.

  Si vous activez des requêtes de jointure réflexive pour les vues matérialisées et toutes les vues, vues matérialisées et tables de diffusion en continu, vous devez vérifier qu’il n’existe pas d’écritures simultanées dans les objets joints.

• Aucune prise en charge dans les images Docker.
• Aucune prise en charge lors de l’utilisation de Databricks Container Services.

• Vous devez ouvrir les ports 8443 et 8444 pour activer le contrôle d’accès affiné sur le calcul dédié. Consultez Déployer Azure Databricks dans votre réseau virtuel Azure (injection de réseau virtuel).