Apache Iceberg : table format pour data lake — tutoriel 2026

Introduction

Imaginez un entrepôt de données stocké sur un simple bucket S3 ou MinIO, que vous pouvez lire simultanément depuis Spark, DuckDB et Trino, en bénéficiant de transactions ACID, d’un historique complet des modifications et d’une évolution du schéma sans migration laborieuse. C’est exactement ce que promet Apache Iceberg — et en 2026, la promesse est tenue.

Apache Iceberg est un table format open source pour les grands ensembles de données analytiques. Créé initialement par Netflix puis donné à la fondation Apache, il ne remplace pas votre moteur de requête (Spark, Trino, DuckDB) ni votre stockage (S3, MinIO, HDFS) : il constitue la couche de métadonnées qui rend ces deux éléments interopérables et fiables. Concrètement, Iceberg stocke à côté de vos fichiers Parquet ou ORC un ensemble de fichiers JSON de métadonnées qui décrivent l’état de la table à chaque instant, les partitions, le schéma courant et l’historique complet des snapshots.

Pour une PME ou une startup tech en Afrique de l’Ouest qui veut construire un data lake sérieux sans budget Oracle ou Snowflake, Iceberg représente une opportunité concrète : stocker des téraoctets sur MinIO auto-hébergé à Hetzner pour quelques euros par mois, lire ces données depuis n’importe quel outil BI sans lock-in, et garantir la cohérence des données même sous des écritures concurrentes. Ce tutoriel vous guide pas à pas, de l’installation du catalog REST jusqu’aux opérations ACID avancées, en passant par le time travel et la lecture multi-moteur.

Prérequis

• Python 3.11+ avec pip — ou Spark 3.5 si vous préférez JVM
• MinIO opérationnel (local via Docker ou distant) — ou tout bucket S3-compatible
• Un catalog Iceberg REST : Nessie (recommandé) ou le serveur REST Iceberg officiel
• DuckDB 1.x pour la lecture analytique légère
• Niveau : intermédiaire (vous avez déjà manipulé S3/MinIO et des DataFrames)
• Temps estimé : environ 40 minutes pour les étapes 1 à 7

Étape 1 — Iceberg vs Delta Lake vs Hudi : choisir son table format

Avant d’investir du temps dans un table format, il est utile de comprendre pourquoi trois projets concurrents coexistent et ce qui distingue Iceberg des deux autres. En 2026, le marché s’est consolidé autour de trois acteurs : Apache Iceberg (Netflix/Apple/Databricks), Delta Lake (Databricks), et Apache Hudi (Uber/Onehouse). Les trois résolvent le même problème fondamental — donner des propriétés ACID à des fichiers Parquet stockés sur S3 — mais avec des philosophies différentes.

Apache Iceberg privilégie l’interopérabilité moteur. Sa spécification ouverte (Iceberg Table Spec v3 à date) est implémentée nativement dans Spark, Trino, Flink, DuckDB, StarRocks, Snowflake et bien d’autres. Le catalog est découplé du moteur — vous pouvez utiliser Nessie, AWS Glue, le serveur REST officiel ou même un simple fichier sur S3. C’est l’option la plus portable si votre équipe utilise plusieurs moteurs de requête différents.

Delta Lake est excellemment intégré à l’écosystème Databricks et Spark. Sa force est le DML avancé (MERGE, Z-Order, Deletion Vectors) et une adoption enterprise massive. En revanche, la gouvernance reste très proche de Databricks, et bien que le projet soit open source, certaines fonctionnalités avancées (Liquid Clustering, etc.) arrivent en priorité sur la plateforme commerciale.

Apache Hudi brille sur les cas d’usage de streaming incrémental : il a été conçu pour ingérer des mises à jour quasi-temps-réel à très haute fréquence. Sa complexité de configuration est supérieure aux deux autres, et son écosystème de lecture multi-moteur est moins mature qu’Iceberg.

Pour un data lake self-hosted en contexte PME Afrique de l’Ouest — MinIO sur un VPS Hetzner, lectures depuis DuckDB local et Metabase, ingestion via Airbyte — Iceberg est le choix le plus cohérent : déploiement léger, catalog REST minimaliste, lecture sans Spark depuis DuckDB ou Trino, et absence de lock-in propriétaire.

Étape 2 — Déployer un Catalog REST avec Nessie

Le catalog est le composant central d’Iceberg : c’est lui qui maintient le registre des tables (leurs métadonnées, leurs snapshots, leur localisation dans le stockage). Sans catalog, chaque moteur de requête devrait pointer vers des fichiers de métadonnées en dur sur S3, ce qui casse l’abstraction. Iceberg supporte plusieurs implémentations de catalog : Hive Metastore, AWS Glue, JDBC, et le protocole REST standardisé (Iceberg REST Catalog Spec).

Project Nessie est le catalog REST le plus utilisé en self-hosted. Développé par Dremio, il implémente le protocole REST Iceberg et ajoute en plus un système de branches Git-like sur les tables — vous pouvez expérimenter sur une branche, valider, puis merger vers main. Pour un usage PME simple, vous n’aurez pas forcément besoin des branches, mais c’est un avantage notable. Nessie démarre en un seul conteneur Docker avec SQLite ou RocksDB comme backend de persistance.

Voici comment démarrer Nessie avec persistance RocksDB et le connecter à MinIO. Créez d’abord un fichier docker-compose.yml dédié :

# docker-compose.yml — Nessie + MinIO pour Iceberg
version: "3.8"
services:
  nessie:
    image: ghcr.io/projectnessie/nessie:0.99.0
    ports:
      - "19120:19120"
    environment:
      - QUARKUS_PROFILE=prod
      - NESSIE_VERSION_STORE_TYPE=ROCKSDB
      - NESSIE_VERSION_STORE_PERSIST_ROCKS_DB_PATH=/nessie/rocksdb
    volumes:
      - nessie-data:/nessie/rocksdb

  minio:
    image: minio/minio:RELEASE.2024-11-07T00-52-20Z
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    command: server /data --console-address ":9001"
    volumes:
      - minio-data:/data

volumes:
  nessie-data:
  minio-data:

Lancez la stack avec docker compose up -d. Une fois démarrée, ouvrez la console MinIO sur http://localhost:9001 (login minioadmin/minioadmin) et créez un bucket nommé iceberg-warehouse. Nessie est accessible via son API REST sur http://localhost:19120 — vous pouvez vérifier qu’il répond avec un simple curl http://localhost:19120/api/v2/config qui doit retourner un objet JSON décrivant le serveur.

Étape 3 — PyIceberg : créer une première table sur MinIO

PyIceberg est la bibliothèque Python officielle d’Apache Iceberg, maintenue dans le dépôt apache/iceberg-python sur GitHub. Elle permet de créer, lire et modifier des tables Iceberg sans Spark, directement depuis Python. En 2026, la version 0.8.x est stable et supporte les catalogs REST, JDBC et AWS Glue, ainsi que la lecture/écriture en Parquet via pyarrow.

Commencez par installer les dépendances dans un environnement virtuel propre :

# Créer et activer un virtualenv Python 3.11+
python3 -m venv .venv && source .venv/bin/activate

# Installer PyIceberg avec le support REST catalog + S3/MinIO
pip install "pyiceberg[pyarrow,s3fs,nessie]>=0.8.0"

L’installation tire pyarrow (lecture/écriture Parquet), s3fs (accès S3-compatible) et les dépendances Nessie. Vérifiez que tout s’est bien installé avec python -c "import pyiceberg; print(pyiceberg.__version__)" — vous devez voir 0.8.x ou supérieur.

Créez ensuite un fichier de configuration PyIceberg ~/.pyiceberg.yaml qui pointe vers votre Nessie local et votre MinIO :

# ~/.pyiceberg.yaml
catalog:
  nessie:
    uri: http://localhost:19120/iceberg
    type: rest
    s3.endpoint: http://localhost:9000
    s3.access-key-id: minioadmin
    s3.secret-access-key: minioadmin
    s3.path-style-access: true
    warehouse: s3://iceberg-warehouse/

Le paramètre s3.path-style-access: true est indispensable avec MinIO : contrairement à AWS S3 qui supporte le style virtual-hosted (bucket.s3.amazonaws.com), MinIO utilise le path-style (localhost:9000/bucket). Oubliez ce paramètre et toutes vos requêtes échoueront avec une erreur de résolution DNS cryptique.

Maintenant, créons une table Iceberg réelle depuis Python :

from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import (
    NestedField, StringType, LongType, TimestamptzType, DoubleType
)
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import DayTransform

# Charger le catalog Nessie défini dans ~/.pyiceberg.yaml
catalog = load_catalog("nessie")

# Créer un namespace (équivalent d'une base de données)
catalog.create_namespace_if_not_exists("analytics")

# Définir le schéma de la table
schema = Schema(
    NestedField(1, "event_id",   StringType(),      required=True),
    NestedField(2, "user_id",    StringType(),      required=True),
    NestedField(3, "event_type", StringType(),      required=True),
    NestedField(4, "amount",     DoubleType(),      required=False),
    NestedField(5, "created_at", TimestamptzType(), required=True),
)

# Partition par jour sur created_at (champ ID 5)
partition_spec = PartitionSpec(
    PartitionField(source_id=5, field_id=1000, transform=DayTransform(), name="created_at_day")
)

# Créer la table
table = catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec,
    location="s3://iceberg-warehouse/analytics/events",
)

print(f"Table créée : {table.identifier}")
print(f"Schéma : {table.schema()}")

L’exécution de ce script crée la table dans le catalog Nessie et initialise sa structure de métadonnées sur MinIO. Si vous consultez le bucket iceberg-warehouse dans la console MinIO, vous verrez apparaître un dossier analytics/events/metadata/ contenant un fichier JSON de métadonnées — c’est le premier snapshot, vide pour l’instant. La table est prête à recevoir des données.

Étape 4 — INSERT, UPDATE et DELETE ACID

La vraie valeur d’Iceberg par rapport à de simples fichiers Parquet sur S3 réside dans ses garanties ACID. Chaque opération d’écriture est atomique : soit elle réussit complètement et crée un nouveau snapshot, soit elle échoue et la table reste dans son état précédent. Il n’y a pas d’état intermédiaire corrupu, même si le processus est tué en plein milieu d’une écriture.

Commençons par insérer des données (append) avec pyarrow :

import pyarrow as pa
from datetime import datetime, timezone

# Charger la table existante
catalog = load_catalog("nessie")
table = catalog.load_table("analytics.events")

# Créer un batch de données au format Arrow
batch = pa.table({
    "event_id":   ["evt-001", "evt-002", "evt-003"],
    "user_id":    ["usr-dakar-01", "usr-abidjan-07", "usr-dakar-01"],
    "event_type": ["login", "purchase", "logout"],
    "amount":     [None, 4500.0, None],          # en FCFA
    "created_at": [
        datetime(2026, 4, 27, 8, 0, 0, tzinfo=timezone.utc),
        datetime(2026, 4, 27, 9, 15, 0, tzinfo=timezone.utc),
        datetime(2026, 4, 27, 9, 30, 0, tzinfo=timezone.utc),
    ]
})

# Appender les données — crée un nouveau snapshot
table.append(batch)
print(f"Snapshot courant : {table.current_snapshot().snapshot_id}")

L’opération append crée un nouveau fichier Parquet dans la partition correspondante (ici created_at_day=2026-04-27) et met à jour les métadonnées atomiquement. Pour les opérations de mise à jour ou de suppression, PyIceberg expose table.overwrite() pour remplacer des données dans une partition, et l’API DataFrame via table.to_daft() ou via Spark pour les UPDATE/DELETE SQL complets. Les opérations de row-level delete (supprimer des lignes individuelles sans réécriture complète du fichier) sont disponibles via les delete files d’Iceberg — Iceberg v2 et v3 supportent les position deletes et equality deletes, permettant de marquer des lignes supprimées sans réécrire le fichier Parquet sous-jacent, ce qui est bien plus efficace pour des tables volumineuses.

Étape 5 — Time travel : interroger les snapshots historiques

Le time travel est l’une des fonctionnalités les plus puissantes d’Iceberg pour un data lake analytique. Parce que chaque opération d’écriture crée un nouveau snapshot immuable, vous pouvez à tout moment interroger l’état de la table à n’importe quel instant passé — pour déboguer une anomalie de données, comparer deux états ou rejouer un pipeline. Aucune sauvegarde externe n’est nécessaire : l’historique est intrinsèque à la table.

Avec PyIceberg, listez d’abord l’historique des snapshots pour identifier les IDs qui vous intéressent :

# Afficher l'historique des snapshots
catalog = load_catalog("nessie")
table = catalog.load_table("analytics.events")

for snap in table.history():
    print(f"Snapshot {snap.snapshot_id} — "
          f"{snap.timestamp_ms} — "
          f"{snap.summary.get('operation', '?')}")

# Lire les données au niveau d'un snapshot spécifique (par ID)
snap_id = table.history()[0].snapshot_id   # le premier snapshot
df_historique = table.scan(snapshot_id=snap_id).to_arrow()
print(df_historique.to_pandas())

Vous pouvez aussi faire du time travel par timestamp — utile quand vous savez qu’il y a eu un problème à 14h30 et que vous voulez voir l’état de la table avant cet instant. L’API table.scan(snapshot_id=...) ou table.scan(as_of_timestamp=...) vous y donne accès directement. Du côté Spark, la syntaxe est encore plus naturelle : spark.read.option("as-of-timestamp", "1745740800000").table("analytics.events"). Du côté DuckDB via l’extension Iceberg, le time travel se fait avec SELECT * FROM iceberg_scan('...', version => 'SNAP_ID').

Notez que les vieux snapshots ne sont pas conservés indéfiniment par défaut. La procédure de nettoyage (expiration) supprime les snapshots plus anciens qu’un certain délai via table.expire_snapshots(). Configurez cette rétention en fonction de vos besoins — en Afrique de l’Ouest où le stockage reste un coût réel, une rétention de 7 jours est souvent un bon compromis entre sécurité et économie.

Étape 6 — Schema evolution sans rewrite des données

L’évolution du schéma est le cauchemar classique des data lakes basés sur des fichiers Parquet bruts : ajouter une colonne force souvent à réécrire tous les fichiers existants, ou à gérer des incohérences de schéma entre les anciens et les nouveaux fichiers. Iceberg résout ce problème élégamment en dissociant le schéma des données : le schéma est stocké dans les métadonnées, et Iceberg gère lui-même la projection et les valeurs par défaut lors de la lecture.

Voici comment ajouter une nouvelle colonne à une table existante sans toucher aux fichiers Parquet déjà écrits :

from pyiceberg.types import StringType

catalog = load_catalog("nessie")
table = catalog.load_table("analytics.events")

# Ajouter une colonne 'country_code' (nullable) — sans réécriture des données
with table.update_schema() as update:
    update.add_column(
        path="country_code",
        field_type=StringType(),
        doc="Code pays ISO-3166 de l'utilisateur"
    )

print(f"Nouveau schéma : {table.schema()}")

# Les anciennes données lues avec le nouveau schéma retournent NULL pour country_code
df = table.scan().to_arrow()
print(df.to_pandas()[["event_id", "country_code"]])
# → evt-001  None
# → evt-002  None  (NULL, pas d'erreur)

L’opération update_schema() est purement une modification de métadonnées — elle prend quelques millisecondes, quel que soit le volume de données. Les anciennes lignes retournent NULL pour la nouvelle colonne lors de la lecture, et les nouvelles écritures peuvent renseigner la valeur. Iceberg supporte aussi le renommage de colonnes, la promotion de types (par exemple int → long), et la réorganisation de l’ordre des colonnes — toujours sans réécriture des fichiers sous-jacents.

Étape 7 — Lecture multi-moteur : Spark, DuckDB, Trino

L’un des arguments les plus forts pour Iceberg dans un environnement hétérogène est sa capacité à être lu par des moteurs très différents sans conversion. Le même fichier Parquet sur MinIO, décrit par les mêmes métadonnées Iceberg, peut être interrogé simultanément par Spark depuis un cluster, DuckDB depuis un laptop d’analyste, et Trino depuis un service de requête partagé — sans aucune copie ni synchronisation.

Lecture avec DuckDB : DuckDB intègre une extension Iceberg native depuis la version 0.10. Pour lire directement depuis MinIO :

-- Dans DuckDB CLI ou depuis Python duckdb
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

-- Configurer l'accès MinIO
SET s3_endpoint='localhost:9000';
SET s3_access_key_id='minioadmin';
SET s3_secret_access_key='minioadmin';
SET s3_use_ssl=false;
SET s3_url_style='path';

-- Lire la table Iceberg via son chemin de métadonnées
SELECT event_type, COUNT(*) AS nb, SUM(amount) AS total_fcfa
FROM iceberg_scan('s3://iceberg-warehouse/analytics/events/')
WHERE created_at >= TIMESTAMPTZ '2026-04-27 00:00:00+00'
GROUP BY event_type;

Lecture avec Spark 3.5 : Le connecteur Iceberg pour Spark s’ajoute au classpath. Dans votre spark-defaults.conf ou en session :

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("iceberg-demo") \
    .config("spark.sql.extensions",
            "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
    .config("spark.sql.catalog.nessie",
            "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.nessie.catalog-impl",
            "org.apache.iceberg.nessie.NessieCatalog") \
    .config("spark.sql.catalog.nessie.uri", "http://localhost:19120/api/v1") \
    .config("spark.sql.catalog.nessie.ref", "main") \
    .config("spark.sql.catalog.nessie.warehouse",
            "s3://iceberg-warehouse/") \
    .getOrCreate()

# Requête SQL Iceberg depuis Spark
spark.sql("SELECT * FROM nessie.analytics.events").show()

Lecture avec Trino : Trino supporte Iceberg via un connecteur dédié. Dans votre fichier etc/catalog/iceberg.properties sur le nœud Trino, configurez le catalog REST et le connecteur S3. Une fois la configuration en place, la syntaxe SQL standard s’applique : SELECT * FROM iceberg.analytics.events WHERE day(created_at) = DATE '2026-04-27'. Trino bénéficie du pruning de partitions Iceberg pour ne lire que les fichiers nécessaires, ce qui est déterminant sur des tables de plusieurs centaines de gigaoctets.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Un data lake Iceberg sur MinIO auto-hébergé est particulièrement bien adapté aux contraintes et aux opportunités du marché tech ouest-africain. Voici comment tirer parti de cette architecture dans le contexte local.

Hébergement économique chez Hetzner. Un serveur Hetzner Dedicated BX61 (AMD Ryzen, 64 Go RAM, 2 × 1 To NVMe) coûte environ 45 EUR/mois — soit moins qu’une heure de cluster EMR sur AWS. Configurez MinIO en mode standalone sur ce serveur et vous obtenez facilement 1 To de stockage data lake opérationnel pour un coût mensuel qui rentre dans le budget d’une startup sénégalaise ou ivoirienne. Pour les équipes qui démarrent avec un budget encore plus restreint, un VPS Hetzner CX22 (2 vCPU, 4 Go RAM, 40 Go SSD) à 4,35 EUR/mois est suffisant pour un data lake de 50-100 Go en phase pilote — MinIO stocke les données sur un volume attaché séparé.

Partitionnement adapté au fuseau horaire. En Afrique de l’Ouest, la majorité de vos données événementielles (clics, transactions, connexions) suivent des rythmes locaux en heure Africa/Dakar (GMT+0 toute l’année, sans changement d’heure). Partitionner par DayTransform() sur un timestamp UTC fonctionne, mais si vous voulez des partitions qui correspondent aux journées locales, convertissez les timestamps à l’ingestion. PyIceberg stocke les TimestamptzType en UTC — documentez cette convention dans le schéma de chaque table.

Lecture multi-moteur pour les équipes BI hétérogènes. Dans une PME tech à Abidjan ou Dakar, les analystes BI utilisent souvent Metabase, Grafana ou Excel pour leurs rapports, tandis que les ingénieurs data préfèrent Python ou SQL. Iceberg permet à Trino d’exposer l’ensemble du data lake comme une source SQL standard accessible depuis n’importe quel outil compatible JDBC/ODBC — vous pouvez connecter Metabase directement à Trino, qui lit Iceberg sur MinIO, sans aucune copie de données. Cette architecture évite le syndrome du « silo BI » où chaque équipe maintient sa propre copie des données.

Gestion des coupures électriques et de réseau. Dans les contextes où la connectivité Internet est intermittente, le fait qu’Iceberg garantisse l’atomicité des écritures est particulièrement précieux. Si une ingestion Airbyte est interrompue en cours de route (coupure électrique, timeout réseau), la table Iceberg reste dans son dernier état cohérent — aucune donnée partielle n’est lisible, et il suffit de relancer le job Airbyte depuis le dernier checkpoint.

Tutoriels frères

• Airbyte : ingestion vers data lake self-hosted — tutoriel 2026 — comment alimenter vos tables Iceberg depuis vos bases de production via Airbyte
• dbt Core : transformation de données SQL — tutoriel 2026 — transformer les données de votre data lake Iceberg avec dbt et des tests de qualité
• Dagster : orchestration de pipelines data — tutoriel 2026 — planifier et monitorer les jobs d’ingestion et de maintenance Iceberg

Pour aller plus loin

• Retour au pilier : Data engineering self-hosted 2026 : Airbyte, dbt, Dagster, Iceberg
• Documentation Iceberg officielle : iceberg.apache.org/docs/latest — spec complète, guides par moteur (Spark, Trino, Flink), référence des propriétés de table
• PyIceberg : py.iceberg.apache.org — référence complète de l’API Python officielle
• Project Nessie : projectnessie.org — documentation du catalog REST avec versioning Git-like
• Prochaine étape dans le cluster : une fois votre data lake Iceberg en production, lisez le tutoriel dbt Core pour automatiser les transformations SQL sur vos tables Iceberg

FAQ

Q : Apache Iceberg est-il gratuit et open source ?
R : Oui, Apache Iceberg est un projet de la fondation Apache, distribué sous licence Apache 2.0. La bibliothèque principale, les connecteurs Spark, Flink et Trino, ainsi que PyIceberg sont tous open source et gratuits. Des services managés Iceberg existent (Tabular, Snowflake Open Catalog, AWS S3 Tables) mais ne sont pas nécessaires pour un déploiement self-hosted.

Q : Quelle est la différence entre un catalog et un warehouse Iceberg ?
R : Le warehouse désigne le stockage physique des données et métadonnées — c’est votre bucket MinIO ou S3, le chemin de base où tous les fichiers Parquet et JSON de métadonnées sont écrits. Le catalog est le service d’annuaire qui connaît l’existence et la localisation de chaque table — c’est lui que vous interrogez pour lister les tables, résoudre analytics.events vers son chemin de métadonnées actuel, et assurer l’atomicité des écritures concurrentes. Sans catalog, chaque outil devrait connaître le chemin exact des fichiers de métadonnées.

Q : Iceberg supporte-t-il les upserts (INSERT OR UPDATE) ?
R : Oui, via la sémantique MERGE INTO de Spark SQL, ou via les opérations overwrite par filtre dans PyIceberg. Pour des upserts à haute fréquence sur de très petits lots de lignes (< 1000 lignes par batch), Iceberg est moins efficace que Hudi — l'overhead de la création d'un snapshot par écriture devient sensible. Pour des batchs quotidiens ou horaires de milliers à millions de lignes, Iceberg est parfaitement adapté.

Q : Comment maintenir les performances sur une table Iceberg qui grossit ?
R : Deux opérations de maintenance sont essentielles. La compaction (ou rewrite data files) fusionne les nombreux petits fichiers générés par des écritures fréquentes en fichiers plus grands, améliorant les performances de lecture. L’expiration des snapshots supprime les anciens snapshots et les fichiers orphelins pour récupérer de l’espace disque. Ces deux opérations se programment facilement dans Dagster ou Airflow.

Q : Puis-je utiliser Iceberg avec PostgreSQL comme catalog à la place de Nessie ?
R : Oui. Iceberg supporte un catalog JDBC qui fonctionne avec n’importe quelle base de données compatible JDBC, dont PostgreSQL. C’est une alternative plus simple si vous avez déjà un PostgreSQL en production : pas de service supplémentaire à gérer, la table de catalog est une simple table SQL. L’inconvénient est l’absence des fonctionnalités avancées de Nessie (branches, merges). Configurez via type: jdbc et jdbc.uri: postgresql://... dans PyIceberg.

Q : Iceberg fonctionne-t-il sans connexion Internet continue pendant les lectures ?
R : Oui. Une fois le catalog (Nessie ou autre) accessible et le stockage MinIO/S3 accessible, toutes les opérations Iceberg sont locales à votre infrastructure — aucune dépendance externe n’est requise à l’exécution. Pour un data lake sur un VPS Hetzner à Francfort avec Nessie et MinIO sur le même serveur, toutes les requêtes Iceberg fonctionnent même sans accès à Internet, tant que l’intranet de votre organisation peut atteindre ce serveur.

Q : Quelle taille de données Iceberg gère-t-il raisonnablement avec PyIceberg seul (sans Spark) ?
R : PyIceberg avec le moteur de lecture pyarrow gère efficacement des tables jusqu’à quelques centaines de gigaoctets sur une machine avec 8-16 Go de RAM, à condition d’utiliser les projections de colonnes (selected_fields) et les filtres row-group Parquet (row_filter) dans table.scan() pour ne pas charger tout le fichier en mémoire. Au-delà de 500 Go ou pour des jointures complexes, préférez DuckDB ou Trino en lecture — ils gèrent la pagination et la parallélisation que PyIceberg seul ne fait pas.