Interrogation des données
Lisez les tables gérées depuis les workflows, les notebooks et le SQL brut — même autorisation, même masquage des colonnes, même piste d'audit.
Il existe trois façons de lire une table gérée. Toutes passent par la même couche d'autorisation, le même pipeline de masquage des colonnes et la même piste d'audit.
Depuis un workflow
Les workflows utilisent le produit scrydon:tables (voir Fournisseurs → Scrydon). Outils courants :
| Outil | Objectif |
|---|---|
get-schema | Retourne les colonnes, types, classifications et stratégies de masque applicables à l'appelant |
query | Exécuter une requête structurée (filtres, tris, pagination) — ensemble de résultats typé |
query-sql | Exécuter une chaîne SQL — pour les cas où la requête structurée n'est pas suffisamment expressive |
write | Ajouter / remplacer / upsert / supprimer |
delete | Supprimer la table (autorisation administrateur d'espace de travail requise) |
Les workflows lisent toujours en utilisant l'autorisation d'exécution — l'acteur à des fins de gouvernance est l'utilisateur qui a déclenché l'exécution, pas le workflow lui-même.
Depuis un notebook
Les notebooks Marimo se connectent à la même surface de tables gérées. La session du notebook est authentifiée par rapport à l'utilisateur qui l'a ouvert, de sorte que les lectures appliquent les masques et filtres de cet utilisateur.
En SQL brut
Les administrateurs et analystes d'espace de travail peuvent émettre du SQL brut via la surface SQL de l'interface Analytics. La requête est analysée, réécrite pour appliquer les masques et filtres de lignes, puis exécutée contre l'entrepôt.
Restrictions sur le SQL brut :
- Les requêtes inter-tenants sont rejetées (le réécriveur n'autorise que les tables dans le catalogue de votre organisation).
- Le DDL (
CREATE,ALTER,DROP) est rejeté — le cycle de vie des tables passe par l'API du catalogue. - Les requêtes qui exposeraient des colonnes refusées échouent avec une erreur de permission (pas un NULL silencieux).
Ce que vous ne voyez pas
Trois choses sont délibérément invisibles :
- Les données des autres tenants. Même avec des autorisations administrateur, vous ne pouvez pas voir les tables d'une autre organisation.
- Les colonnes système internes. Les colonnes d'implémentation utilisées par l'entrepôt ne sont pas exposées au SQL.
- Les valeurs de colonnes masquées sans le bon rôle. Un masque
redactaffiche[REDACTED]; un masquenullafficheNULL; un masquedenyfait échouer la requête.
Vous voulez savoir si une colonne est masquée pour vous ? Appelez get-schema — il retourne la stratégie de masque applicable à l'acteur appelant pour chaque colonne.
Performance
L'entrepôt est optimisé pour l'OLAP (stockage en colonnes, exécution vectorisée). Pour la plupart des requêtes analytiques — agrégats, jointures, scans — il est rapide. Pour les recherches ponctuelles sur des tables volumineuses, préférez une query structurée avec un filtre sur la clé primaire.
Audit
Chaque lecture émet un événement RESOURCE_ACCESS. Voir Journal d'audit.
Voir aussi
- Tables gérées — le cycle de vie contre lequel ces requêtes s'exécutent.
- Classification et masquage — ce que les politiques font à votre requête.
- Notebooks Marimo — interrogation pilotée par Python.