Données et SQL

Le principe tient en une phrase : vos fichiers restent sur votre stockage objet. graal Data Platform les catalogue et les rend interrogeables ; elle ne les héberge pas et ne les recopie pas ailleurs.

Buckets et explorateur

Chaque projet dispose de buckets sur le stockage compatible S3 que vous fournissez. L’explorateur sert aux deux gestes de tous les jours : déposer un jeu de données, et regarder ce qu’un run vient de produire.

Les jobs y écrivent en Parquet par défaut. C’est un format ouvert, lisible par Spark, Pandas, DuckDB et Trino sans conversion.

Catalogue : couches, bases, tables, champs

Le catalogue est organisé en quatre niveaux :

couche — l’étage de raffinage (brut, nettoyé, exposé, selon votre convention) ;
base — le regroupement logique à l’intérieur d’une couche ;
table — le jeu de données lui-même, adossé à des fichiers du bucket ;
champ — les colonnes, leur type et leur description.

Ce n’est pas seulement un annuaire : c’est ce qui permet de savoir ce qu’on a et qui y a droit, projet par projet. La connaissance des données ne reste pas dans la tête de la personne qui les a déposées.

Les droits se posent par couche, par base et par table, avec les mêmes rôles et affectations que le reste de la plateforme (voir rôles et permissions).

Tables Apache Iceberg

Les tables sont au format Apache Iceberg, sur votre stockage objet : transactions, évolution de schéma et voyage dans le temps, dans un format que tout l’écosystème lit.

Le catalogue Iceberg est un catalogue REST standard, adossé à la base PostgreSQL de la Data Platform, avec un espace de noms par locataire. Trino, Spark, Flink, Dask et PyIceberg le lisent tous, par le nom de la table. Quand un job écrit une table, ses champs apparaissent au catalogue sans saisie. Le détail est dans Le catalogue de données.

Lire et écrire une table par son nom depuis un job

Un job reçoit le catalogue Iceberg graal de son locataire sans rien configurer : ni chemin S3, ni clé, ni adresse de catalogue. Le run porte un jeton qui ne vaut que pour lui, et les accès au stockage sont signés par la plateforme. Le schéma par défaut est celui du locataire.

# Spark (job spark, PySpark)
df = spark.table("ventes")
df.groupBy("region").count().writeTo("ventes_par_region").append()

# Python, notebook, Ray : le module graal est fourni au run
import graal
df = graal.read_table("ventes")                  # pandas
graal.write_table(df, "ventes_nettoyees")         # crée la table au premier appel

# Dask : une partition par fichier, lue par les workers
ddf = graal.read_table_dask("ventes")

// Flink : le catalogue est fourni au run en SQL
tEnv.executeSql(Files.readString(Path.of(System.getenv("GRAAL_FLINK_CATALOG_SQL"))));
tEnv.useCatalog("graal");
tEnv.executeSql("SELECT count(*) FROM ventes").print();

Entrepôt SQL : Trino

L’entrepôt interroge vos tables en SQL avec Trino, déployé par le chart de la plateforme dans le namespace applicatif. Une table du catalogue devient interrogeable sans copie ni chargement préalable, et Trino joint vos tables Iceberg à vos bases existantes.

Les requêtes se lancent depuis l’éditeur SQL de la console, depuis un notebook, ou depuis votre outil BI par l’accès JDBC standard de Trino. Les tables Parquet ou ORC existantes au format Hive se lisent sur le même catalogue.

Lignage

Le catalogue dit d’où vient chaque table : le lignage se suit au niveau colonne, du job qui l’a produite jusqu’aux sources qu’il a lues. La page Lakehouse et SQL du site présente aussi la documentation des jeux de données générée par IA.