Lakehouse auto-hébergé sur Scaleway

Résumé

Scaleway fournit l’object storage, des bases PostgreSQL managées, Kubernetes et plusieurs moteurs, mais aucun catalogue Iceberg managé (d’après la documentation consultée le 22 octobre 2026) : il faut l’auto-héberger. Trois montages sont possibles : un moteur avec un catalogue JDBC sur PostgreSQL (A), plusieurs moteurs avec un catalogue REST (B), ou un lakehouse qui alimente un moteur BI dédié (C). Un déploiement réel (Kubernetes, Nessie, Trino) fonctionne, mais un seul nœud permanent coûte 57,53 €/mois.

Prérequis

Data lake vs lakehouse (format de table, catalogue) et Choisir entre lake, lakehouse et warehouse pour savoir si le lakehouse est justifié.

Pourquoi le catalogue n’est pas un détail

Sur de l’object storage, un catalogue basé sur de simples fichiers n’offre pas toujours un commit atomique fiable : l’atomicité du changement de pointeur dépend des garanties du stockage. Dès qu’il y a plusieurs writers, un catalogue dédié est le choix prudent pour Iceberg. Les écritures conditionnelles de certains stockages compatibles S3 peuvent changer cette conclusion ; leur disponibilité chez Scaleway est à vérifier. C’est le point où Scaleway coûte le plus d’exploitation par rapport à une offre managée.

Les briques

Brique Scaleway	Rôle dans un lakehouse
Object Storage (compatible S3)	Fichiers Parquet et métadonnées Iceberg
Managed PostgreSQL	Base du catalogue (JDBC, Lakekeeper, Polaris)
Serverless Jobs / Containers / Functions	Exécuter dbt ou des scripts, héberger un service de catalogue
Kubernetes Kapsule	Héberger Trino, un catalogue REST ou Spark
Clusters for Apache Spark	Spark managé avec notebook JupyterLab
Data Warehouse for ClickHouse	Moteur analytique managé
Data Orchestrator	Orchestration de workflows en YAML

Statuts relevés le 22 octobre 2026, à revérifier

• Clusters for Apache Spark : connexion distante au cluster non supportée ; le statut du service n’est pas précisé ici.
• Data Warehouse for ClickHouse : disponibilité générale, avec SLA, facturé en vCPU et object storage.
• Data Orchestrator : bêta publique d’après la page des bêtas de Scaleway. Il exécute des Serverless Jobs, Functions et Containers ainsi que des appels HTTP, sans jobs Spark ni déclencheurs sur événement.
• Dagster : le dépôt scaleway/dagster-scaleway, marqué WIP, fournit un run launcher qui exécute les ops Dagster comme des Serverless Jobs. Seule l’exécution est serverless : le webserver, le daemon et le stockage de l’instance Dagster restent à héberger ailleurs.

Options de catalogue auto-hébergeables

Option	Principe	Exploitation	Multi-moteurs et sécurité
Catalogue JDBC sur PostgreSQL managé	Pointeur de table stocké dans une base SQL	La plus légère : une base managée, aucun service	Multi-moteurs si chacun parle JDBC ; pas de permissions fines, pas d’API REST
Lakekeeper	Service REST Iceberg en Rust, licence Apache, sur PostgreSQL	Un conteneur sans état plus PostgreSQL ; sur Kapsule ou Serverless Containers	Tout moteur compatible REST ; OIDC, autorisation fine via OpenFGA
Apache Polaris	Service REST Iceberg open source	Un service plus PostgreSQL ; plus lourd	Rôles, OAuth2, distribution de crédentiels de stockage
Project Nessie	Catalogue REST avec branches façon Git	Un service plus stockage ; offre managée non vérifiée	Utile pour isoler des environnements ou des backfills
Hive Metastore	Historique, hérité de Hadoop	Lourd	Plus lent et moins riche que les catalogues modernes

Moteurs déployables et compatibilité dbt

Moteur	Où	Catalogue REST Iceberg	Adapter dbt	Effort
Trino	Kapsule	Oui, connecteur Iceberg	dbt-trino	Élevé : déploiement et réglage du cluster
Spark	Clusters for Apache Spark ou Kapsule	Oui, avec les bibliothèques Iceberg ; à tester sur le service managé	dbt-spark	Moyen en managé
DuckDB	Serverless Jobs, un nœud	Oui, écriture récente	dbt-duckdb	Faible ; adapté à des volumes modestes (ordre de grandeur à valider)
ClickHouse	Data Warehouse managé	Lecture solide, écriture plus récente et partielle ; à vérifier selon la version	dbt-clickhouse	Faible côté exploitation

La matrice exacte entre la version de chaque moteur et le catalogue doit être testée avant de s’engager : c’est le principal risque de compatibilité. Voir dbt et le lakehouse.

Trois architectures cibles

flowchart LR
    subgraph A["A : un moteur, catalogue JDBC"]
      A1[Un moteur] --> A2[("PostgreSQL<br/>catalogue")]
      A1 --> A3[("Object Storage")]
    end
    subgraph B["B : plusieurs moteurs, catalogue REST"]
      B1[Trino] --> B3["Lakekeeper ou Polaris"]
      B2[Spark] --> B3
      B3 --> B4[("PostgreSQL")]
      B1 --> B5[("Object Storage")]
      B2 --> B5
    end
    subgraph C["C : mixte"]
      C1[("Lakehouse<br/>brut et historique")] --> C2["Moteur de serving BI<br/>ex. ClickHouse"]
    end

Montage	Avantages	Contreparties	Convient quand
A	Peu de pièces à exploiter	Pas de permissions fines, pas d’API REST	Une équipe, un moteur, peu de gouvernance
B	Catalogue standard interchangeable, droits par table, plusieurs moteurs	Un service à déployer, sécuriser, sauvegarder, mettre à jour	Plusieurs moteurs ou profils, gouvernance exigée
C	Brut et historique ouverts, BI sur un moteur adapté	Deux couches à synchroniser, un moteur de plus	Historique long et BI exigeante en temps de réponse

Retour d’expérience : Kapsule, Nessie et Trino

Un projet personnel documenté par Marcel-Jan Krijgsman : partie 1, le plan (5 janvier 2026) et partie 2, Scaleway (7 janvier 2026, mise à jour du 30 mars 2026).

Ce que l’auteur a monté. Un cluster Kubernetes (control plane gratuit), un bucket privé, Nessie et Trino installés avec Helm. Validation : création d’un schéma et d’une table Iceberg en Parquet, INSERT et SELECT fonctionnent sur le catalogue iceberg. Le billet conclut que le lakehouse est faisable chez Scaleway, avec un prix proche de celui des clouds américains.

Points relevés. Le compte doit être vérifié (pièce d’identité) pour obtenir des quotas suffisants ; l’application a besoin du permission set KubernetesFullAccess, sinon kubectl refuse les identifiants. L’installation de Trino a pris le plus de temps : des paramètres de configuration inexistants dans la version générée par un assistant IA, et des workers qui ne trouvaient pas le coordinateur. Leçon retenue : confronter toute configuration générée à la documentation officielle.

Prix et essais relevés dans l'article (janvier 2026), à revérifier

Nœud le moins cher DEV-M1 : 57,53 €/mois. L’auteur indique qu’on ne peut pas arrêter le cluster pour économiser (un pool réduit à zéro nœud n’est pas documenté par l’article). Essai gratuit de 52 jours ; object storage gratuit 90 jours jusqu’à 750 Go.

Limites de ce montage de démonstration.

• Coût. Un nœud permanent à 57,53 €/mois pèse lourd pour un usage d’essai. À comparer à une exécution sans cluster dédié (DuckDB sur Serverless Jobs, catalogue JDBC sur PostgreSQL managé).
• Pas de production. Un nœud de développement porte catalogue, coordinateur et workers : ni haute disponibilité, ni isolation.
• Sécurité. L’accès à Trino passe par kubectl port-forward, sans authentification décrite, et les clés S3 sont dans des fichiers values.yaml. Une mise en production prévoirait des Secrets Kubernetes et une authentification.
• Maintenance et dbt. Ni compaction, ni expiration des snapshots (Maintenance d’un lakehouse), ni dbt, ni orchestrateur dans le montage décrit.
• Catalogue. Nessie est défendable ; le choix se tranche selon la gouvernance voulue (tableau plus haut). Le statut actuel du projet est à vérifier.

Sources

Statuts relevés dans la documentation en ligne le 22 octobre 2026 ; ceux qui touchent aux bêtas et aux adapters dbt v2 sont à revérifier avant décision.

• dbt : versions, contribuer un adapter v2, licences, stratégies incrémentales, catalogues Iceberg, catalogs.yml, DuckDB et Iceberg, passer à la v2.
• Scaleway : concepts du Data Orchestrator, démarrage, bêtas, Clusters for Apache Spark, FAQ Apache Spark, Data Warehouse for ClickHouse.
• Catalogues : Lakekeeper, Lakekeeper sur GitHub, Apache Polaris, comparatif de catalogues Iceberg.
• ClickHouse : matrice de support, fonction iceberg.
• Éditeurs : BigQuery, tables Iceberg, Lakehouse, notes de version, Snowflake, tables Iceberg, Databricks, lecture Iceberg des tables Delta, Databricks, deletion vectors, Databricks, accès externe Iceberg, OVHcloud, Lakehouse Manager.
• Iceberg : évolution de schéma.

Notes liées

• Data lake vs lakehouse : les concepts.
• Écosystème lakehouse, formats, catalogues et moteurs : formats, catalogues et moteurs comparés.
• Choisir entre lake, lakehouse et warehouse : décider, et offres managées.
• Maintenance d’un lakehouse : ce que cette infrastructure laisse à la charge de l’équipe.
• dbt et le lakehouse : matérialisations et état de dbt v2.
• Staging, ODS, DWH et architecture médaillon : l’architecture en couches à déployer.
• MOC Data Engineering : carte du vault.