Spark en 2026 : 9 alternatives pour chaque workload data

Temps de lecture : 9 min

Points clés à retenir

• Architecture multi-moteurs : utilisez le moteur adapté à chaque workload (compaction, streaming, SQL interactif, ML) pour des performances maximales.
• Maintenance automatisée : un plan de contrôle comme LakeOps gère compaction et nettoyage 95% plus vite que Spark, sans cluster JVM.
• Formats ouverts : Iceberg et Parquet permettent à tous les moteurs de lire les mêmes tables via un catalogue partagé, sans verrouillage.

Spark a longtemps été le couteau suisse du traitement distribué. Depuis 2015, tout passait par lui : transformations massives, entraînement de modèles, requêtes SQL sur des téraoctets. Mais en août 2026, le paysage a radicalement changé. L’architecture lakehouse a découplé stockage et calcul, Iceberg est devenu le format de table standard, et des moteurs spécialisés ont émergé. Chacun excelle dans un domaine précis, et s’en tenir à Spark pour tout est désormais un choix coûteux.

Concrètement, lancer un job de compaction de 50 Mo avec Spark, c’est payer un cluster JVM pour une tâche qu’un moteur dédié exécute en quelques secondes. Les clusters Spark qui restent inactifs entre les maintenances planifiées sont un gaspillage pur. Et quand une requête interactive prend 8 secondes à cause du planificateur Catalyst pour une simple recherche de 3 lignes, on se dit qu’il y a mieux.

La plateforme data moderne : chaque workload a son moteur

La stratégie gagnante consiste à router chaque workload vers l’outil le plus adapté. Spark reste excellent pour l’ETL batch lourd. Un plan de contrôle autonome comme LakeOps gère la compaction et la maintenance des tables Iceberg, avec une vitesse 95% supérieure et sans JVM. Trino répond aux requêtes SQL interactives. DuckDB est parfait pour l’analyse locale. Flink domine le streaming. Tous lisent les mêmes tables Iceberg via le même catalogue : c’est exactement ce que l’architecture multi-moteurs permet.

Dans ce guide, je vous présente 9 alternatives à Spark. Pas pour le remplacer entièrement, mais pour l’utiliser là où il est pertinent, et le remplacer là où il ne l’est pas. Mon expérience avec GymLog et mes workflows n8n m’a appris qu’il faut choisir l’outil adapté à chaque tâche, et c’est la même philosophie pour la data.

LakeOps : le plan de contrôle autonome pour Iceberg

LakeOps remplace Spark pour la compaction, la maintenance des tables, l’expiration des snapshots, le nettoyage des fichiers orphelins et l’optimisation des manifests. C’est l’outil le plus impactant de cette liste, et celui que la plupart des équipes découvrent après avoir perdu des mois à écrire des scripts de maintenance Spark.

Chaque lakehouse Iceberg en production a besoin d’une maintenance continue : fusionner les petits fichiers via la compaction, expirer les snapshots pour alléger les métadonnées, nettoyer les fichiers orphelins issus d’écritures échouées, et optimiser les manifests. Sans cela, les performances se dégradent : les requêtes ralentissent de 5 à 12 fois, les coûts de stockage explosent et les factures S3 s’envolent à cause de listings de milliers de petits fichiers.

L’approche traditionnelle avec Spark ? Vous écrivez des jobs de compaction, vous les déployez sur Airflow ou cron, vous provisionnez des clusters EMR, vous paramétrez la mémoire JVM, et vous espérez ne pas être réveillé à 2h du matin pour un crash OOM. Mais une fois que vous dépassez 50 tables, cette approche manuelle ne tient plus.

LakeOps élimine tout ça. C’est un plan de contrôle autonome pour Apache Iceberg, écrit en Rust sur Apache DataFusion. Il gère l’intégralité du cycle de maintenance sans cluster Spark, sans JVM et sans intervention humaine. Concrètement, la compaction est 95% plus rapide que Spark. Sur un jeu de données de 200 Go, LakeOps a terminé en 221 secondes contre 1 612 secondes pour Spark. Et sur une table de 1,2 To qui avait fait planter Spark, il a réussi en 11 minutes, avec une gestion de la mémoire parfaite.

Mais ce qui différencie LakeOps, c’est sa capacité à apprendre de vos requêtes. Il observe en continu les colonnes utilisées dans les clauses WHERE, JOIN et GROUP BY de tous vos moteurs (Spark, Trino, Snowflake, etc.), puis réorganise physiquement les données pendant la compaction. Résultat : les moteurs analysent 51% de données en moins, et ce pour toutes les requêtes, sur tous les moteurs, en permanence.

Les déclencheurs sont événementiels, pas du cron. La compaction se lance quand les conditions le justifient : trop de petits fichiers, des suppressions nombreuses, des écritures streaming fréquentes. Après avoir expiré des snapshots ou nettoyé des orphelins, le système réévalue automatiquement. Rien n’est gaspillé, aucune table n’est oubliée.

L’installation prend 10 minutes, sans modification de votre infrastructure. LakeOps se connecte à vos catalogues existants (AWS Glue, Polaris, Nessie, S3 Tables) et à votre stockage objet, et les données restent dans votre environnement. Les résultats sont là : jusqu’à 80% de réduction des coûts, et plus de 700 tables gérées chez les clients. Si vous utilisez Spark uniquement pour la maintenance Iceberg, vous payez des clusters JVM pour un travail qu’un moteur dédié fait plus vite et moins cher.

Flink : le traitement streaming véritable

Flink remplace Spark pour le streaming à faible latence, le traitement d’événements complexes et l’ingestion continue vers Iceberg. Le streaming structuré de Spark est en micro-batch : il traite les données par intervalles de 1 à 10 secondes. Si vous avez besoin de latence sous la seconde, de fenêtres avec sémantique de temps d’événement, ou de calculs d’état exactly-once à des millions d’événements par seconde, Flink est supérieur.

Avec Flink 2.0 et le Dynamic Iceberg Sink (Flink 1.20+), un seul job peut ingérer depuis plusieurs topics Kafka vers plusieurs tables Iceberg, en gérant automatiquement les nouveaux topics, l’évolution de schéma et les changements de partitionnement, sans redémarrage. C’est exactement ce qu’il faut pour des pipelines CDC robustes ou du fan-out multi-tables.

Choisissez Flink si : la latence de bout en bout sub-seconde est un prérequis, vous avez des événements désordonnés avec watermarks, vous ingérez plus de 100 000 événements par seconde par table, ou vous faites du CDC avec cohérence exactly-once. Par contre, pour le batch + streaming sur le même cluster, ou si vous ne voulez pas gérer deux moteurs, Spark reste pertinent.

Attention : les écritures streaming génèrent en continu de petits fichiers. Sans une compaction automatisée, la performance se dégrade rapidement. C’est là qu’un plan de contrôle comme LakeOps devient indispensable pour accompagner le rythme du streaming.

Trino : le SQL distribué interactif

Trino remplace Spark pour les requêtes ad-hoc, le BI multi-utilisateurs et les requêtes fédérées. C’est un moteur de requête SQL distribué, sans état, spécifiquement conçu pour l’interactivité. Là où Spark met 5 à 15 secondes pour planifier et exécuter une agrégation filtrée, Trino répond en 1 à 3 secondes, sans démarrage à froid.

Trino excelle en fédération : vous pouvez interroger Iceberg, PostgreSQL, MySQL, Elasticsearch, MongoDB et Kafka dans une seule requête SQL, sans déplacer les données. De plus, le connecteur Iceberg prend désormais en charge le mode copy-on-write pour les DELETE, UPDATE et MERGE, ce qui améliore les performances en lecture pour les workloads analytics.

Si vous utilisez Trino, vérifiez d’abord l’état physique de vos tables. Des fichiers correctement compactés et triés permettent à Trino d’ignorer 60 à 95% des données. Si vos requêtes sont lentes, le problème vient souvent de la table, pas de la requête.

DuckDB : l’analytics mono-machine sans infrastructure

DuckDB remplace Spark pour le développement local, la validation CI/CD, l’exploration de notebooks et les datasets jusqu’à 100 Go. C’est une base de données analytique embarquée, qui fonctionne dans votre script Python ou dans votre pipeline CI, sans cluster ni JVM. Une simple commande pip install duckdb suffit.

La version 1.5.3 (mai 2026) a énormément étendu le support Iceberg : MERGE INTO, évolution de schéma, transformations de partition, et intégration du format V3 avec vecteurs de suppression binaires. DuckDB couvre désormais les opérations d’écriture les plus courantes qui nécessitaient auparavant un cluster Spark.

Son intégration Arrow permet un échange de données zéro-copie avec pandas et Polars, et l’outil est gratuit et open source. Évidemment, il est mono-node : pour des très grosses tables (des millions de fichiers) ou des workloads distribués, il faut passer à Spark ou Trino. Le pattern type : DuckDB pour le développement et les petites charges, et les moteurs distribués pour la queue.

Polars : des DataFrames plus rapides sans cluster

Polars est une bibliothèque de DataFrames basée sur Rust, catégoriquement plus rapide que PySpark pour les workloads mono-nœud. Pas de JVM, pas de sérialisation Python-Java, pas de cluster. Là où PySpark passe 3 à 8 secondes à créer une session, Polars a déjà fini le job.

Mes benchmarks TPC-H montrent que Polars surpasse pandas de 10 à 50x selon les requêtes, et bat PySpark pour les données de moins de 10 Go. Au-delà, Spark prend le relais efficacement. La règle générale : mono-nœud sous 50 Go → Polars ; distribué au-dessus de 100 Go → Spark. Beaucoup d’équipes combinent les deux : Polars pour l’itération rapide et l’ETL léger, Spark pour les gros volumes.

Apache DataFusion : le moteur Rust pour systèmes embarqués

DataFusion n’est pas un concurrent direct de Spark : c’est une bibliothèque de moteur de requête, un socle sur lequel d’autres systèmes s’appuient. Il est derrière LakeOps, InfluxDB 3.0 et RisingWave. Le crate iceberg-datafusion (projet Apache) fournit une intégration Iceberg native avec poussée de prédicats, DDL et DML, et résolution des fichiers de suppression.

Si vous construisez un produit data (moteur de compaction, service de requêtes, backend analytique), DataFusion vous évite de livrer la JVM et vous offre des performances vectorisées sur Arrow. C’est un choix stratégique pour une infrastructure moderne et évolutive.

Ray : le calcul distribué pour l’IA et le ML

Ray a détrôné Spark pour les workloads d’IA sérieux : entraînement distribué, tuning d’hyperparamètres, serving de modèles LLM, apprentissage par renforcement, inférence par lots. Son architecture orientée tâches et acteurs est optimisée pour Python, avec un support GPU natif et un lancement de tâches en ~200 microsecondes, contre 1 à 3 secondes pour Spark.

Avec Ray Train, Ray Tune et Ray Serve, vous obtenez une stack IA intégrée. Databricks Runtime 15+ inclut Ray en natif. Pour la préparation de données, Spark reste pertinent, mais pour l’entraînement et le serving, Ray est imbattable. Le pattern type : Spark pour l’ETL, Ray pour le ML, avec un stockage partagé S3.

dbt et SQLMesh : transformations SQL sans Spark

Beaucoup de jobs Spark ne nécessitent pas de calcul distribué. Ce sont des SELECT, JOIN, GROUP BY classiques. dbt et SQLMesh les expriment en SQL pur, gèrent les dépendances et l’incrémentalité, et s’exécutent sur Snowflake, BigQuery, Trino, DuckDB ou même Spark si nécessaire. La logique est découplée du moteur.

dbt est le standard avec un vaste écosystème de packs. SQLMesh, maintenant un projet Linux Foundation, adopte une approche différente : détection des changements au niveau des colonnes, ce qui évite de re-construire des modèles inchangés et fait économiser sur les factures cloud. Pour 80% des transformations purement SQL, ces outils sont largement suffisants, et Spark devient un surcoût.

ClickHouse et StarRocks : l’OLAP temps réel

Pour des centaines d’utilisateurs concurrents, avec des réponses en moins d’une seconde sur des données fraîches, Spark n’est pas adapté. ClickHouse et StarRocks sont des moteurs OLAP columnar spécifiquement conçus pour ce pattern. Ils lisent Iceberg via des catalogues natifs, sans copie des données.

ClickHouse excelle dans l’analyse d’événements temps réel : logs, observabilité, clickstream, avec agrégations pré-calculées et latence millisecondes. StarRocks est idéal pour le BI multi-utilisateurs à haute concurrence, avec une architecture MPP. Tous deux bénéficient de tables bien entretenues. Si vos requêtes sont imprévisibles et nécessitent une exploration brute, Spark reste utile, mais pour le reporting temps réel, ces moteurs sont imbattables.

Construire la plateforme data de 2026

L’architecture lakehouse a rendu ce monde multi-moteurs possible. Avec des formats ouverts et des catalogues standards, aucun verrouillage n’existe. Mais cette diversité crée un nouveau défi : la maintenance. Chaque moteur dépend de tables bien compactées, triées et propres.

C’est là qu’un plan de contrôle comme LakeOps intervient : il surveille l’ensemble de vos moteurs, apprend de leurs patterns de requêtes et maintient chaque table dans une forme optimale. Fini les clusters Spark pour la maintenance : tout est automatisé, continu et bien moins cher.

Les meilleures équipes data de 2026 ne choisissent pas Spark pour tout. Elles choisissent le bon moteur pour chaque workload, avec une couche opérationnelle qui assure la santé des tables. C’est l’architecture vers laquelle je vous recommande de tendre, pour des performances maximales et des coûts maîtrisés.