Tables gérées
Téléversez un fichier, obtenez une table typée et gouvernée — inférence de schéma, cycle de vie et états qu'une table peut traverser.
Une table gérée est une table typée et gouvernée, propriété de Scrydon. Vous téléversez un fichier, la plateforme infère un schéma à la première arrivée de données, et à partir de ce moment la table est interrogeable, gouvernable et liée à la couche ontologique.
Créer une table
Le flux par défaut est données d'abord : vous téléversez un fichier, la table est créée à partir des données.
Cliquez sur Nouvelle table et choisissez un nom, une classification et une description facultative.
Déposez un fichier CSV / JSON / JSONL. La plateforme met le fichier en attente dans le stockage d'objets et exécute l'inférence de schéma sur un échantillon.
Examinez les colonnes inférées — noms, types, nullabilité, valeurs d'exemple. Si une colonne a été mal classifiée (par ex. une colonne numérique de type chaîne), corrigez-la avant de confirmer.
Lors de la validation, la plateforme crée la table dans l'entrepôt et charge les lignes en attente. La table est maintenant interrogeable depuis les workflows, la couche ontologique et les notebooks.
Vous pouvez également créer une table vide en passant un schéma explicitement, mais la méthode données d'abord est la plus courante.
États du cycle de vie
Une table peut traverser ces états :
| État | Signification |
|---|---|
| En attente | La table existe dans le catalogue mais aucun schéma n'a encore été inféré. |
| Active | Schéma inféré, interrogeable, acceptant les écritures. |
| Archivée | Masquée des listes par défaut, n'accepte plus de nouvelles écritures, les requêtes existantes fonctionnent toujours. |
| Restaurée | Une table archivée qui a été remise en actif. |
L'archivage est réversible : les données ne sont pas supprimées, la table cesse simplement d'apparaître dans les listes par défaut. Pour récupérer les données d'une table archivée, restaurez-la.
Écritures — ce qui est pris en charge
Les tables gérées prennent en charge quatre modes d'écriture :
| Mode | Ce qu'il fait |
|---|---|
| Ajout | Ajouter des lignes. Mode par défaut. |
| Remplacement | Supprimer les lignes existantes et charger le nouveau fichier. Le schéma reste inchangé. |
| Upsert | Mettre à jour les lignes correspondant à la clé primaire, insérer le reste. |
| Suppression | Supprimer les lignes correspondant à un prédicat. |
Les écritures passent par la même couche d'autorisation que les lectures. Un membre de l'espace de travail avec accès en écriture peut ajouter ; seuls les administrateurs d'espace de travail peuvent remplacer ou supprimer.
Évolution du schéma
L'initialisation du schéma est additive. La plateforme applique cette règle :
- Un nouveau fichier avec des colonnes supplémentaires → ces colonnes sont ajoutées comme nullable au schéma.
- Un nouveau fichier avec des colonnes manquantes → les colonnes existantes restent, ces lignes ont des nulls.
- Un nouveau fichier avec une colonne renommée → traitée comme une nouvelle colonne. Les renommages sont explicites, pas automatiques.
- Un nouveau fichier avec un type réduit (par ex. précédemment NUMERIC, maintenant INT uniquement) → rejeté. Seul l'élargissement de type est autorisé.
C'est contraignant : les tables de production ne se réduisent jamais silencieusement.
Voir Inférence de schéma pour les règles d'inférence et les remplacements.
Stockage
Les tables gérées sont sauvegardées par un moteur OLAP (StarRocks) pour des requêtes rapides. Les téléversements en attente atterrissent dans le stockage d'objets (SeaweedFS / S3) avant d'être matérialisés dans l'entrepôt.
Vous n'interagissez pas directement avec l'entrepôt. Les lectures passent par la couche de gouvernance ; les écritures aussi.
Instantanés de profil
Chaque table peut être profilée — la plateforme produit un instantané du nombre de lignes, des taux de nulls, des comptes distincts et des statistiques de base par colonne. Les profils sont visibles dans l'interface de détail de la table et actualisables à la demande.
Les profils sont informatifs. Ils n'appliquent pas de contraintes. Pour appliquer des contraintes (par ex. « cette colonne ne doit jamais être nulle »), utilisez le bloc Évaluateur ou le bloc Garde-fous au moment de la lecture.
Où vous lisez depuis
- Outils de workflow — le produit
scrydon:tables. Voir Fournisseurs → Scrydon. - Projections ontologiques — objets typés sauvegardés par un binding
silver_table. Voir Ontologie. - Notebooks Marimo — notebooks Python. Voir Notebooks Marimo.
- SQL brut — autorisé, masqué par la gouvernance. Voir Requêtes.
En rapport
- Inférence de schéma — comment les types sont choisis.
- Classification et masquage — comment l'accès et le masquage des colonnes fonctionnent.
- Noms de colonnes — gestion des en-têtes avec des points / non compatibles SQL.
- Tables créées par l'agent — lorsqu'un workflow crée les siennes.