Iceberg et données ouvertes
Les tables gérées Scrydon reposent sur Apache Iceberg — un format de table qui vous appartient. Exportez vers n'importe quel moteur, apportez votre propre catalogue et conservez une souveraineté totale sur vos données.
Scrydon Analytics stocke les tables gérées dans Apache Iceberg — un format de table ouvert doté d'une sémantique de catalogue REST standardisée. Cela signifie que les données structurées que vous ingérez via Scrydon ne sont pas enfermées dans un entrepôt propriétaire : elles résident dans des fichiers Parquet dans votre stockage objet, décrites par un catalogue Iceberg que tout moteur conforme peut lire.
Ce que cela signifie en pratique
Souveraineté et portabilité
Chaque table gérée possède une représentation Iceberg ouverte. Les fichiers Iceberg résident dans le même bucket de stockage objet que celui que vous avez déjà configuré pour Scrydon — S3, Azure ADLS ou le stockage SeaweedFS fourni pour les déploiements auto-hébergés. Si vous choisissez de quitter Scrydon, les données et tout l'historique de leur schéma partent avec vous.
Le test de sortie : pip install pyiceberg && pyiceberg --catalog <your-catalog-uri> describe <your-namespace>.<your-table> doit renvoyer la définition de votre table en utilisant uniquement des outils open source et vos propres identifiants.
Une façade de catalogue REST gouvernée
Scrydon expose le protocole de catalogue REST Iceberg à l'adresse :
https://<your-host>/api/table/iceberg/v1/Cette surface est gouvernée : chaque requête exige un jeton de moteur (une clé d'API à portée limitée émise dans l'interface Platform), et chaque requête est isolée à l'organisation émettrice. La façade relaie les opérations de catalogue vers une instance interne de Lakekeeper — un catalogue REST Iceberg en Rust sous licence Apache-2.0 que Scrydon gère pour vous.
Deux modes
| Mode | Description |
|---|---|
| Iceberg géré (par défaut) | Scrydon crée et possède les entrées du catalogue Iceberg. Votre entrepôt StarRocks, tout outil de BI connecté et vos pipelines de données lisent tous la même table gouvernée. |
| Catalogue BYO | Connectez un catalogue Iceberg existant (REST, AWS Glue, Nessie) comme source de données Scrydon. Scrydon le lit à l'aide d'un identifiant unique de principal de service que vous fournissez ; la gouvernance de votre catalogue existant constitue la limite extérieure. |
Modèle de gouvernance à deux niveaux
Le modèle de gouvernance ci-dessous est propre au chemin Iceberg géré. Les catalogues BYO s'appuient sur les contrôles d'accès propres au catalogue externe.
Scrydon applique la gouvernance des données à deux niveaux :
| Niveau | Mécanisme d'application | Ce qu'il couvre |
|---|---|---|
| Accès au catalogue | Façade REST Scrydon (/api/table/iceberg/v1/*) | Qui peut accéder au catalogue, et s'il peut écrire. Les jetons de moteur portent l'organizationId et un indicateur canWrite facultatif. |
| Données au niveau des lignes | Chemin de lecture StarRocks (le moteur de confiance) | Masquage de colonnes, filtres de lignes et DLP — appliqués à chaque lecture SQL, quel que soit l'outil à l'origine de la requête. |
Les moteurs externes — Spark, Trino, DuckDB, PyIceberg — se connectent via la façade de catalogue gouvernée. Ils reçoivent toutes les lignes autorisées via la planification de scan Iceberg standard. Le masquage fin (rédaction partielle, hachage) que Scrydon applique au niveau SQL n'est pas appliqué aux lectures Parquet brutes via le plan de données Iceberg. C'est une propriété assumée du format ouvert : si une colonne est stockée en clair dans Parquet, un moteur ayant accès au stockage objet peut la lire. Le masquage de colonnes de Scrydon est appliqué au niveau SQL de StarRocks ; pour les données qui doivent être masquées pour tous les appelants, y compris les moteurs Iceberg, utilisez les contrôles de classification des données pour restreindre l'accès au niveau de la table plutôt que de vous appuyer sur un masquage partiel.
Exigences de stockage
| Stockage | Comportement |
|---|---|
| AWS S3 | Distribution d'identifiants STS — les moteurs Iceberg reçoivent des identifiants de courte durée à chaque accès à une table. Aucune clé statique n'est requise dans la configuration du moteur. |
| Azure ADLS | Identifiants SAS de courte durée distribués par Lakekeeper à chaque accès. |
| SeaweedFS (auto-hébergé, fourni) | Signature à distance — Lakekeeper signe les requêtes S3 pour le compte du moteur. SeaweedFS ne dispose pas de service STS. |
| Stockage personnalisé compatible S3 | Signature à distance (comme pour SeaweedFS). L'accès de type chemin (path-style) est configuré automatiquement. |
Les lectures du plan de données de l'extension Iceberg de DuckDB via des URL signées à distance (SeaweedFS / stockages personnalisés compatibles S3) peuvent ne pas fonctionner dans toutes les versions de DuckDB. Les opérations sur les métadonnées du catalogue — SHOW TABLES, DESCRIBE — fonctionnent dans tous les cas. Consultez la matrice de compatibilité pour connaître l'état actuel des tests.
Pour aller plus loin
Émettez un jeton de moteur et configurez PyIceberg, DuckDB, Trino ou Spark.
Connectez votre catalogue Glue, Nessie ou REST existant comme source de données Scrydon.
Comment les tables sont créées, gouvernées et font évoluer leur schéma.
Masquage de colonnes et filtres de lignes — ce que le plan de données Iceberg applique ou non.