Aller au contenu principal
Dernière mise à jour le

Contrôle d'accès granulaire sur un compute dédié

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

remarque

Le compute dédié est un compute polyvalent ou Job configuré avec le mode d’accès **Dédié** (anciennement mode d’accès utilisateur unique). Consultez Modes d'accès.

Exigences​

Pour utiliser du compute dédié afin de query une vue ou une table avec des contrôles d'accès précis :

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

Comment le filtrage des données fonctionne sur le compute dédié​

Contrairement au compute standard, qui applique en mode natif des contrôles d'accès précis, le compute dédié utilise l'architecture Spark traditionnelle, dans laquelle le code utilisateur partage une JVM qui a un accès privilégié à la machine sous-jacente. L'application de filtres de ligne et de masques de colonne directement sur un compute dédié risquerait une sur-extraction des données, car un utilisateur pourrait accéder aux données de base non filtrées avant l'exécution des filtres.

Pour appliquer des contrôles d’accès granulaires sans ce risque, le compute dédié délègue le filtrage au compute serverless de votre Workspace, qui est isolé par Lakeguard. Chaque fois qu'une query accède à un objet de base de données avec des contrôles d’accès granulaires, la ressource de compute dédiée transmet la query au compute serverless de votre Workspace pour effectuer le filtrage des données. Les données filtrées sont ensuite transférées entre les ressources de compute serverless et dédiées à l’aide de fichiers temporaires sur le stockage cloud interne au Workspace.

Databricks transfère les données filtrées à l’aide de Cloud Fetch, une fonctionnalité qui écrit des jeux de résultats temporaires dans le stockage interne du workspace (la racine DBFS de votre workspace). Databricks collecte automatiquement ces fichiers, les marquant pour suppression après 24 heures et les supprimant définitivement après 24 heures supplémentaires.

Si vous activez le versioning de compartiment S3 sur votre racine DBFS, Databricks ne peut pas collecter les anciennes versions des jeux de résultats temporaires. Cela peut entraîner une croissance exponentielle du stockage à mesure que les versions de fichiers non actuelles s’accumulent. Voir les Considérations sur la gestion des versions des compartiments S3 pour les recommandations de configuration.

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

Dans le diagramme suivant, un utilisateur dispose du privilège SELECT sur table_1, view_2 et table_w_rls, auxquels des filtres de ligne ont été appliqués. L'utilisateur ne dispose pas du privilège SELECT sur table_2, référencé par view_2.

Diagramme qui montre comment fonctionne le filtrage des données.

La query sur table_1 est entièrement gérée par la ressource de compute dédiée, car aucun filtrage n'est requis. Les query sur view_2 et table_w_rls nécessitent un filtrage des données pour renvoyer les données auxquelles l'utilisateur a accès. Ces query sont gérées par la capacité de filtrage des données sur le compute serverless.

Prise en charge des opérations d'écriture​

Dans Databricks Runtime 16.3 et versions supérieures, vous pouvez écrire dans des tables qui ont des filtres de ligne ou des masques de colonne appliqués, en utilisant ces options :

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

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

Voici un exemple de UPDATE utilisant MERGE INTO:

SQL
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'instruction INSERT utilisant MERGE INTO :

SQL
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 utilisant MERGE INTO :

SQL
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 des commandes 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ôle d'accès granulaire sur un compute dédié :

Si nécessaire, ces commandes s'exécutent automatiquement sur le compute serverless.

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

Coûts du compute Serverless​

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

Les utilisateurs ayant accès peuvent query la table system.billing.usage pour voir le montant qui leur a été facturé. Par exemple, la query suivante ventile les coûts de compute par utilisateur :

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;
attention

Cette query montre les coûts de compute pour l'utilisation du contrôle d'accès granulaire (FGAC) mais n'inclut pas les coûts de stockage pour les fichiers de résultats temporaires accumulés. Si le versioning de compartiment S3 est activé, les versions de fichier non actuelles ne sont pas comptées dans les queries de facturation standard, mais entraînent toujours des frais de stockage.

Afficher les performances de query lorsque le filtrage des données est activé​

La Spark UI pour le compute dédié affiche des métriques que vous pouvez utiliser pour comprendre les performances de vos querys. Pour chaque query que vous exécutez sur la ressource de compute, l'onglet SQL/Dataframe affiche la représentation du graphe de query. Si une query est impliquée dans le filtrage des données, l'interface utilisateur affiche un nœud d'opérateur **RemoteSparkConnectScan** au bas du graphe. Ce nœud affiche des métriques que vous pouvez utiliser pour analyser les performances des query. Consultez Afficher les informations de compute dans la Spark UI.

SparkUI affichant le nœud RemoteSparkConnectScan

Développez le nœud d'opérateur RemoteSparkConnectScan pour afficher les indicateurs qui répondent à des questions telles que les suivantes :

  • Combien de temps a duré le filtrage des données ? Afficher le « temps total d’exécution à distance ».
  • Combien de lignes sont restées après le filtrage des données ? Afficher « la sortie des lignes ».
  • Combien de données (en octets) ont été renvoyées après le filtrage des données ? Afficher la « taille des lignes de sortie ».
  • Combien de fichiers de données ont été élagués par partition et n'ont pas eu besoin d'être lus depuis le stockage ? Affichez « Fichiers élagués » et « Taille des fichiers élagués ».
  • Combien de fichiers de données n'ont pas pu être élagués et ont dû être lus depuis le stockage ? Afficher « Fichiers lus » et « Taille des fichiers lus ».
  • Parmi les fichiers qui devaient être lus, combien étaient déjà dans le cache ? Affichez « Cache hits size » et « Cache misses size ».

Limitations​

  • Seules les lectures par batch sont prises en charge sur les tables de streaming. Les tables avec filtres de lignes ou masques de colonnes ne prennent pas en charge les workloads de streaming sur compute dédié.

  • Le catalogue default (spark.sql.catalog.spark_catalog) ne peut pas être modifié.

  • spark.catalog.listColumns() n'est pas pris en charge. Au lieu de cela, vous pouvez utiliser SHOW COLUMNS IN pour lister les noms de colonnes, SHOW PARTITIONS pour lister les colonnes de partition, ou DESCRIBE TABLE [EXTENDED [AS JSON]] pour obtenir une description détaillée de la table.

  • Dans Databricks Runtime 17.0 et versions inférieures, spark.catalog.tableExists() n'est pas pris en charge pour les tables avec des contrôles d'accès précis.

  • Dans Databricks Runtime 16.2 et versions antérieures, il n'y a pas de prise en charge pour les opérations d'écriture ou de refresh de table sur les tables ayant des filtres de ligne ou des masques de colonne appliqués.

    Plus précisément, les opérations DML, tels 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, les opérations d'écriture de table telles que INSERT, DELETE et UPDATE ne sont pas prises en charge, mais peuvent être effectuées à l'aide de MERGE, ce qui est pris en charge.

  • Lorsque vous utilisez DeltaTable.forName() ou DeltaTable.forPath() sur un compute dédié avec des tables activées FGAC, seules les opérations merge() et toDF() sont prises en charge. Pour les autres opérations DeltaTable, utilisez plutôt les commandes SQL correspondantes. Par exemple, au lieu de history(), utilisez DESCRIBE HISTORY, et au lieu de clone(), utilisez SHALLOW CLONE ou DEEP CLONE.

  • Dans Databricks Runtime 16.2 et versions antérieures, les auto-jointures sont bloquées par default lorsque le filtrage des données est appelé, car ces queries peuvent renvoyer différents instantanés de la même table distante. Cependant, vous pouvez activer ces requêtes en définissant spark.databricks.remoteFiltering.blockSelfJoins sur false sur le compute 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 compute 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 renvoient des instantanés identiques et sont activées par default. Les exceptions sont les vues matérialisées et toutes les vues, vues matérialisées et tables de streaming partagées à l'aide d'OpenSharing. Pour ces objets, les jointures automatiques sont bloquées par default, mais vous pouvez activer ces requêtes en définissant spark.databricks.remoteFiltering.blockSelfJoins sur false sur le compute sur lequel vous exécutez ces commandes.

    Si vous activez les requêtes d'auto-jointure pour les vues matérialisées et toute vue, vue matérialisée et table de streaming, vous devez vous assurer qu'il n'y a pas d'écritures concurrentes sur les objets joints.

  • Aucun support dans les images Docker.

  • Aucun support lors de l'utilisation de Databricks Container Services.

  • Si votre Workspace a été déployé avec un pare-feu avant novembre 2024, vous devez ouvrir les ports 8443 et 8444 pour activer le contrôle d'accès précis sur le compute dédié. Voir Groupes de sécurité.

Sur cette page