Le paysage de l'analytique est en pleine effervescence, n'est-ce pas ? Juste au moment où vous pensez avoir opté pour une pile, une nouvelle vague de développements repousse les limites encore plus loin. J'ai passé la meilleure partie de la fin de 2024 et de 2025 les mains dans le cambouis des dernières itérations d'Apache Arrow, DuckDB et Parquet, et laissez-moi vous dire que la synergie qui se crée entre ces trois projets est véritablement impressionnante. Nous ne parlons pas de simples ajustements ; nous assistons à une évolution pratique de la façon dont nous gérons, traitons et déplaçons les données analytiques, rendant des tâches auparavant intimidantes sur des machines locales ou des environnements périphériques presque triviales.
Il ne s'agit pas de "révolutionner" quoi que ce soit ; il s'agit d'outils robustes, efficaces et souvent étonnamment rapides qui nous permettent de faire notre travail avec moins de tracas et moins de factures cloud. En tant qu'expert collègue qui vient de se débattre avec ces mises à jour, je suis ici pour vous exposer les détails concrets : ce qui fonctionne à merveille, où se trouvent encore les angles vifs et comment vous pouvez tirer parti de ces avancées dans votre développement quotidien.
Apache Arrow : La maturation du standard en mémoire omniprésent
Apache Arrow a consolidé sa position de standard de facto pour les données colonnaires en mémoire. Ce qui est vraiment passionnant en 2025, ce n'est pas seulement son adoption généralisée, mais la maturation significative de ses composants principaux, en particulier dans les noyaux de calcul et l'interopérabilité inter-langages. La recherche de la performance est implacable, et cela se voit.
Avec Arrow 21.0.0, sorti en juillet 2025, nous avons assisté à un changement architectural pivot : de nombreux noyaux de calcul ont été découplés dans une bibliothèque partagée séparée et facultative. Cela peut sembler être un changement de plomberie interne, mais c'est une énorme victoire pour la modularité. Pour les applications qui n'ont pas besoin de l'ensemble complet des capacités analytiques d'Arrow, cela réduit la taille de la distribution C++, rationalisant la gestion des dépendances. Il s'agit de vous permettre de choisir, plutôt que de traîner tout un arsenal.
Au-delà de l'emballage, les noyaux de calcul eux-mêmes ont connu une optimisation continue. Nous parlons de plus de fonctions tirant parti des instructions SIMD, garantissant que lorsque les données atteignent le CPU, elles sont traitées avec un parallélisme maximal. Par exemple, l'ajout de expm1 pour des calculs plus précis de exp(x) - 1 près de zéro, et une suite complète de fonctions trigonométriques hyperboliques à la fois en C++ et en PyArrow, sont des ajouts petits mais essentiels pour les tâches numériques lourdes. De plus, l'introduction des types Decimal32 et Decimal64, avec un support de conversion robuste, indique un engagement envers une précision de niveau entreprise dans tout l'écosystème. Ce type de fidélité numérique détaillée, combiné à une vitesse brute, fait d'Arrow une base solide pour une analyse sérieuse.
L'ascension de DuckDB : La puissance analytique local-first
DuckDB continue son ascension fulgurante en tant que "SQLite pour l'analytique", et en 2025, il est devenu un concurrent sérieux pour l'analytique quotidienne, comblant le fossé entre l'exploration locale et les entrepôts de données cloud. La magie, comme toujours, réside dans son modèle d'exécution en processus, columnar et vectorisé, mais les mises à jour récentes ont suralimenté son interaction avec des formats externes comme Parquet et sa danse sans copie avec Arrow.
La vitesse de DuckDB n'est pas seulement théorique ; c'est le résultat d'une ingénierie méticuleuse. Son moteur d'exécution vectorisé traite les données par lots (souvent 1024 ou 2048 valeurs) via des opérateurs compatibles SIMD, maintenant le cache du CPU chaud. Il ne s'agit pas seulement de débit brut ; il s'agit de minimiser le "taxe CPU" du déplacement des données et de la surcharge des appels de fonction. De manière cruciale, la matérialisation tardive est devenue une optimisation essentielle. Dans DuckDB 1.3 (juin 2025), cette fonctionnalité seule a permis d'obtenir des lectures 3 à 10 fois plus rapides pour les requêtes impliquant des clauses LIMIT. Le moteur retarde intelligemment la récupération des colonnes jusqu'à ce qu'elles soient absolument nécessaires, réduisant considérablement l'E/S et la pression sur la mémoire, en particulier lorsqu'un sous-ensemble de colonnes ou de lignes est nécessaire.
Analyse approfondie de la configuration : Optimisation des performances de DuckDB
Pour vraiment tirer parti des performances de DuckDB, comprendre sa configuration est essentiel. La commande SET est votre amie ici.
Par exemple, la gestion du parallélisme est simple :
SET threads = 8; -- Allouer 8 threads pour l'exécution des requêtes
Cela permet à DuckDB de mettre automatiquement à l'échelle la charge de travail sur les ressources CPU disponibles, offrant des accélérations quasi linéaires avec plus de cœurs. Cependant, le véritable tournant dans DuckDB 1.3 a été l'augmentation moyenne de ~15 % des lectures Parquet générales et une augmentation de plus de 30 % du débit d'écriture, grâce à des exportations multithread améliorées et à une combinaison plus intelligente des rowgroups. Ce ne sont pas seulement des gains incrémentaux ; ils modifient fondamentalement le calcul pour le traitement local des données, faisant de DuckDB une étape ETL viable pour les ensembles de données de taille moyenne.
La révolution du zéro copie : Interopérabilité Arrow + DuckDB
C'est là que les choses deviennent vraiment intéressantes. L'intégration entre DuckDB et Apache Arrow est un changement de paradigme, permettant un partage de données "sans copie" qui réduit considérablement la surcharge de sérialisation, l'utilisation de la mémoire et les cycles CPU. En 2025, il ne s'agit pas seulement d'un avantage théorique ; c'est une réalité pratique qui sous-tend les pipelines de données haute performance dans divers écosystèmes.
Lorsque DuckDB produit des résultats au format Arrow, ou consomme des données Arrow, il contourne la coûteuse danse sérialiser -> désérialiser. Au lieu de cela, DuckDB écrit directement dans les tampons Arrow, et d'autres outils compatibles Arrow (comme PyArrow, Pandas 2.0, Polars, PyTorch, TensorFlow) peuvent instantanément utiliser les mêmes tampons mémoire. Cela est rendu possible par le mappage mémoire, où différents processus ou bibliothèques acceptent de "mapper" la même région de mémoire, éliminant ainsi les copies physiques.
La bibliothèque pyarrow rend cela étonnamment simple. Considérez un scénario où vous rejoignez un grand fichier Parquet avec un petit tableau Arrow en mémoire :
import duckdb
import pyarrow as pa
import pyarrow.dataset as ds
# Tableau Arrow en mémoire (par exemple, des drapeaux récents d'une source de streaming)
flags_data = pa.table({
'user_id': [101, 102, 103, 104],
'is_vip': [True, False, True, False],
'feature_group': ['A', 'B', 'A', 'C']
})
# Créer une connexion DuckDB
con = duckdb.connect(database=':memory:', read_only=False)
# Enregistrer le tableau Arrow en mémoire directement avec DuckDB
con.register('in_memory_flags', flags_data)
# Supposons que 'data/orders/*.parquet' est une collection de fichiers Parquet
dummy_orders_data = pa.table({
'order_id': [1, 2, 3, 4, 5],
'user_id': [101, 102, 105, 101, 103],
'amount': [100.50, 25.75, 120.00, 50.00, 75.20],
'order_ts': pa.array([
pa.TimestampHelper.from_iso8601('2025-10-01T10:00:00Z', 'ns'),
pa.TimestampHelper.from_iso8601('2025-10-01T11:00:00Z', 'ns'),
pa.TimestampHelper.from_iso8601('2025-10-02T12:00:00Z', 'ns'),
pa.TimestampHelper.from_iso8601('2025-10-02T13:00:00Z', 'ns'),
pa.TimestampHelper.from_iso8601('2025-10-03T14:00:00Z', 'ns')
])
})
import os
if not os.path.exists('data'):
os.makedirs('data')
pa.parquet.write_table(dummy_orders_data, 'data/orders_2025.parquet')
# Maintenant, interroger les fichiers Parquet et le tableau Arrow en mémoire
result_arrow_table = con.execute("""
SELECT
o.user_id,
SUM(o.amount) AS total_spend,
ANY_VALUE(f.is_vip) AS is_vip,
ANY_VALUE(f.feature_group) AS feature_group
FROM
read_parquet('data/orders_2025.parquet') AS o
LEFT JOIN
in_memory_flags AS f ON o.user_id = f.user_id
WHERE
o.order_ts >= '2025-10-01'
GROUP BY
o.user_id
ORDER BY
total_spend DESC
LIMIT 3
""").arrow()
print("Résultat sous forme de tableau PyArrow :")
print(result_arrow_table)
import polars as pl
result_polars_df = pl.from_arrow(result_arrow_table)
print("\nRésultat sous forme de DataFrame Polars :")
print(result_polars_df)
Cette efficacité est essentielle pour les pipelines de données analytiques complexes et en plusieurs étapes. Et cela ne s'arrête pas à la mémoire locale ! Apache Arrow Flight, basé sur gRPC, étend cette philosophie du zéro copie sur le réseau. DuckDB peut diffuser les résultats des requêtes sous forme de messages Arrow Flight, que Spark, Python ou les frameworks ML peuvent consommer directement. C'est énorme pour les scénarios distribués, où les coûts de sérialisation du réseau dominent généralement.
La pertinence durable de Parquet et les optimisations modernes
Parquet reste le cheval de bataille du stockage columnar pour les charges de travail analytiques, et pour cause : sa structure hiérarchique, sa compression avancée et son support de la suppression de prédicats sont inégalés. Bien que Parquet soit au centre de l'attention ici, comprendre JSON vs YAML vs JSON5 : La vérité sur les formats de données en 2025 est essentiel pour la gestion moderne de la configuration.
Le format Parquet lui-même a connu des versions telles que 2.11.0 en mars 2025 et 2.12.0 en août 2025. La version 2 apporte de nouvelles méthodes d'encodage telles que RLE_DICTIONARY et DELTA_BYTE_ARRAY, qui peuvent entraîner des gains substantiels : la taille des fichiers diminuant de 2 à 37 %, les performances d'écriture s'améliorant de 4 à 27 % et les opérations de lecture devenant 1 à 19 % plus rapides. Ces améliorations résultent d'une compaction des données plus efficace avant l'application d'une compression générale (comme Zstandard ou Snappy).
Analyse approfondie : Optimisation des performances d'écriture Parquet
Écrire Parquet efficacement est aussi crucial que le lire. Une optimisation clé est l'utilisation intelligente de l'encodage de dictionnaire. Pour les colonnes à faible cardinalité, l'encodage de dictionnaire est fantastique. Cependant, pour les colonnes à entropie élevée comme les UUID, l'encodage de dictionnaire est contre-productif. Désactiver explicitement l'encodage pour ces colonnes évite de s'appuyer sur les valeurs par défaut dépendant de la version :
// Exemple de pseudo-code pour la configuration de l'écrivain Parquet
ParquetWriter.builder(path, schema)
.withCompressionCodec(CompressionCodecName.ZSTD)
.withPageSize(DEFAULT_PAGE_SIZE)
.withDictionaryPageSize(DEFAULT_DICTIONARY_PAGE_SIZE)
.withWriterVersion(ParquetProperties.WriterVersion.PARQUET_2_0)
.withDictionaryEncoding("event_id", false)
.build();
Une autre optimisation subtile mais percutante, en particulier dans les écrivains basés sur Java, est de préférer Utf8 à String pour les données textuelles. Bien que String soit converti en Utf8 en interne, sauter l'intermédiaire réduit les allocations de tas et améliore la vitesse de sérialisation.
La gestion de la mémoire de DuckDB : Dompter la bête (et ses limites)
Bien que DuckDB soit indéniablement rapide, une gestion efficace de la mémoire est cruciale. Le moteur de requête hors cœur de DuckDB est un composant de pointe qui lui permet de déverser les résultats intermédiaires sur le disque, lui permettant de traiter des ensembles de données plus grands que la mémoire.
L'option de configuration SET memory_limit est votre principal contrôle pour cela. Par défaut, DuckDB essaie d'utiliser 80 % de votre RAM physique. Cependant, dans certains scénarios, il peut être contre-intuitif mais bénéfique de réduire cette limite à 50-60 %.
-- Définir la limite de mémoire à 50 % de la RAM du système
SET memory_limit = '50%';
J'ai vu des opérations PIVOT sur des CSV de 1,42 milliard de lignes amener DuckDB à consommer plus de 85 Go d'espace disque temporaire. Si vous travaillez avec des ensembles de données plus petits, vous pourriez trouver un convertisseur CSV vers JSON plus efficace pour des inspections rapides. Pour les transformations massives et complexes qui génèrent d'énormes résultats intermédiaires, un système distribué pourrait encore être le choix le plus pragmatique.
Au-delà du cœur : L'écosystème en expansion de DuckDB & DX
L'expérience développeur autour de DuckDB a connu des améliorations remarquables. Une telle pépite est l'extension cache_httpfs. Si vous interrogez fréquemment Parquet ou d'autres fichiers à partir d'un stockage d'objets comme S3, cette extension est un atout. Elle ajoute de manière transparente une mise en cache locale pour les lectures distantes.
Pour l'utiliser :
INSTALL httpfs;
LOAD httpfs;
INSTALL cache_httpfs;
LOAD cache_httpfs;
SET cache_httpfs_type = 'disk';
SET cache_httpfs_path = '/tmp/duckdb_cache';
SET cache_httpfs_max_size = '100GB';
SELECT COUNT(*) FROM 's3://my-bucket/path/to/data.parquet';
De plus, l'introduction d'une nouvelle interface utilisateur DuckDB conviviale (à partir de v1.2.1) est une addition bienvenue. Cette interface de type notebook, accessible via duckdb -ui, offre une mise en évidence de la syntaxe, l'autocomplétion et un explorateur de colonnes, rendant l'exploration locale des données plus intuitive.
Aperçu d'expert : Les sables mouvants des formats de données & L'avenir hybride
Le paysage des données en 2025 est dynamique. Nous voyons de nouveaux formats de stockage comme Lance et Vortex gagner du terrain, spécifiquement conçus pour résoudre certaines des limitations de Parquet dans le contexte des piles de données natives S3 et de la gestion des embeddings.
Ma prédiction pour 2026 et au-delà est une montée continue des architectures analytiques hybrides. Nous verrons DuckDB agir de plus en plus comme un accélérateur analytique local-first puissant, complétant plutôt que remplaçant les entrepôts de données cloud. Les analystes et les ingénieurs lanceront DuckDB pour une exploration rapide, une ingénierie des fonctionnalités locale et une analyse périphérique, en pointant directement vers les fichiers Parquet et Arrow.
Un autre aperçu essentiel : la standardisation de Zstandard (ZSTD) pour la compression Parquet devient le choix pragmatique par défaut pour la plupart des charges de travail analytiques en 2026. Bien que Snappy offre une excellente vitesse, ZSTD fournit constamment un meilleur équilibre entre le taux de compression et la vitesse de décompression, ce qui réduit les coûts de stockage et accélère souvent les temps de requête globaux.
Conclusion
Les développements récents dans Apache Arrow, DuckDB et Parquet représentent un bond en avant significatif dans le traitement pratique et performant des données analytiques. Des noyaux de calcul raffinés d'Arrow à l'exécution locale suralimentée de DuckDB et à l'évolution continue de Parquet, l'écosystème est plus puissant et plus convivial que jamais. Il ne s'agit pas seulement de vitesse brute ; il s'agit de resserrer les boucles de rétroaction, de réduire les frictions opérationnelles et de permettre aux développeurs de se concentrer sur les informations, et non sur l'infrastructure.
Sources
Cet article a été publié par l'équipe éditoriale de DataFormatHub, un groupe de développeurs et d'enthousiastes des données dédiés à rendre la transformation des données accessible et privée. Notre objectif est de fournir des informations techniques de haute qualité ainsi que notre suite d'outils de développement axés sur la confidentialité.
🛠️ Outils connexes
Explorez ces outils DataFormatHub liés à ce sujet :
- CSV vers JSON - Traiter les ensembles de données pour l'analytique
- JSON vers CSV - Exporter les résultats analytiques
- Excel vers CSV - Préparer les feuilles de calcul pour DuckDB