Stack analytique
Tables gérées, inférence de schéma, classification et l'entrepôt OLAP qui les alimente.
La stack analytique est ce qui permet de réaliser de bout en bout le principe « déposez un CSV, obtenez une table typée gouvernée ». Elle combine un service de tables gérées, un pipeline d'ingestion sensible aux colonnes, une couche de classification et masquage, et un moteur de requêtes OLAP.
Ce qu'elle fait
- Ingestion — téléversez un CSV / JSON / JSONL via l'interface Analytics ou un workflow, et la plateforme infère un schéma à la première arrivée de données.
- Gouvernance — chaque table possède une classification des données et un bundle de politiques contrôlant quelles colonnes sont masquées ou refusées par utilisateur / par espace de travail.
- Requête — les chemins de lecture sont exposés à la fois comme API typées (utilisées par les workflows et la couche ontologie) et comme SQL brut (avec protection par autorisation et masquage par gouvernance).
- Profil — les tables gérées portent des instantanés de profil (comptages de lignes, taux de valeurs nulles, valeurs distinctes) que l'interface affiche.
- Notebook — des notebooks Python s'exécutent côte à côte avec l'entrepôt pour des analyses ad hoc. Voir Notebooks Marimo.
Composants
| Composant | Rôle |
|---|---|
| Service Analytics | L'hôte de l'interface et l'orchestrateur d'ingestion. Se trouve dans l'espace de noms scrydon-analytics. |
| Service de tables gérées | L'API HTTP qui gère le cycle de vie des tables, l'inférence de schéma, la classification, le masquage et l'exécution SQL. Service à service uniquement — non accessible aux clients directement. |
| StarRocks | Moteur OLAP qui stocke les lignes des tables gérées. Le déploiement par défaut est une image groupée en pod unique ; la HA en production utilise l'opérateur StarRocks. |
| SeaweedFS / S3 | Stockage d'objets pour les téléversements intermédiaires (CSV/JSON/JSONL) avant leur matérialisation. |
| OPA (Open Policy Agent) | Point de décision de politique par tenant. Chaque lecture évalue un bundle Rego spécifique au tenant. |
| Sidecar Marimo | Environnement d'exécution de notebooks Python, limité à votre espace de travail et à vos tables. |
Chemins de lecture
Trois points d'entrée, tous passant par la même couche d'autorisation + masquage :
- Outils de workflow — le produit
scrydon:tablesexpose des outils typésget-schema,query,writeetdeletequ'un agent peut appeler. - Projection ontologie — lorsque la couche ontologie lit un
Objecttypé dont la liaison est une table gérée, la projection passe par le même pipeline de masquage. - Notebooks — les notebooks Marimo appellent la surface SQL analytique ; les mêmes politiques Rego s'appliquent.
Aucun chemin ne contourne la gouvernance. Le masquage des colonnes, le filtrage des lignes et la classification des données sont évalués à chaque lecture, quel que soit l'appelant.
Évolution du schéma
L'initialisation du schéma est additive :
- La première arrivée de données crée la table.
- L'ajout d'une nouvelle colonne dans un téléversement ajoute une colonne nullable.
- Le renommage ou la suppression de colonnes n'est jamais automatique — les changements de schéma non additifs nécessitent une migration explicite via l'interface.
Cette garantie est contraignante : les tables de production ne se réduisent jamais silencieusement.
Tables créées par les agents
Les workflows peuvent créer eux-mêmes des tables gérées — utile pour un agent qui souhaite persister une liste d'entités dédupliquées, une matrice de scores ou un échantillon d'une longue exécution. Ces tables suivent une convention de nommage distincte et portent toujours une classification confidential, avec des métadonnées d'acteur explicites enregistrées sur chaque ligne.
Voir Analytics → Tables créées par les agents pour la politique complète.
Voir aussi
- Analytics — vue d'ensemble du produit des tables gérées.
- Ontologie — couche typée au-dessus des tables gérées.
- Sécurité → Autorisation — comment les politiques Rego sont appliquées.