Time travel avec les politiques ABAC
Bêta
Le time travel sur les tables avec des politiques ABAC est en version Beta. Pour utiliser cette fonctionnalité, activez la version préliminaire Time Travel on UC Managed Tables with Attribute-Based Access Controls . Les queries sur le compute standard nécessitent Databricks Runtime 19 ou version supérieure ; le serverless compute est également pris en charge.
Time travel vous permet de query les données de table historiques à l'aide d'un Timestamp spécifique ou d'un numéro de version provenant du journal des transactions Delta Lake.
À partir de Databricks Runtime 19, les time travel queries sur les tables éligibles appliquent des politiques de filtre de ligne et de masquage de colonne ABAC. Les requêtes SQL peuvent utiliser TIMESTAMP AS OF, VERSION AS OF ou la syntaxe @ dans un identificateur de table, tel que table_name@v1 ou table_name@20240101000000000. Les requêtes DataFrame peuvent utiliser l'option timestampAsOf ou versionAsOf.
Prérequis
La table et le compute doivent satisfaire à toutes les exigences suivantes :
- The query runs on standard compute using Databricks Runtime 19 or above, or serverless compute. Queries on dedicated compute aren't supported.
- La table est une table Delta gérée par Unity Catalog avec les commits de catalogue activés, ou une table Iceberg gérée.
- Pour les tables Delta gérées, le mappage des colonnes est activé à la fois dans la version actuelle de la table et dans la version historique interrogée, en utilisant le même mode de mappage des colonnes.
Comment fonctionne le time travel avec les politiques ABAC
Pour les requêtes de time travel qui appliquent des politiques ABAC, Databricks lit la version de table historique demandée et compare son schéma avec le schéma de table actuel. Databricks renvoie uniquement les colonnes qui existent dans les deux schémas, de sorte que les colonnes qui n'existent que dans le schéma historique ou actuel ne sont pas exposées. Il applique ensuite les politiques ABAC actuellement définies sur la table aux données historiques pour l'utilisateur effectuant la requête.
Si une politique actuelle dépend d’une colonne manquante ou incompatible dans la version historique, la requête échoue par sécurité plutôt que de renvoyer des données non protégées.
Bonnes pratiques
- Maintenez le mappage des colonnes activé et utilisez le même mode de mappage de colonnes pour chaque version de table que les utilisateurs sont susceptibles de query.
- Avant d'appliquer ou de modifier une politique, vérifiez que chaque colonne référencée par la politique existe avec une définition compatible dans chaque version historique que les utilisateurs doivent query.
- Testez des requêtes time travel représentatives après avoir modifié le schéma de table ou ses politiques pour confirmer les colonnes, le filtrage des lignes et le masquage attendus.
Limitations
Le time travel sur les tables avec des filtres de lignes ou des masques de colonnes au niveau de la table n'est pas pris en charge.