Le monde des données, mes amis, est dans un état de flux fascinant. Depuis des années, nous poursuivons l'insaisissable "source unique de vérité", luttant contre les silos de données et jonglant avec les compromis inhérents entre la flexibilité des data lakes et la gouvernance robuste des data warehouses. Mais les développements récents, en particulier dans le domaine des formats de table ouverts et des plateformes qui les adoptent, racontent une histoire convaincante : la vision du lakehouse n'est pas seulement en train de se préciser, elle devient une réalité profondément pratique et solide.
Ayant passé d'innombrables heures à explorer les dernières itérations, à tester les limites et, oui, à me cogner la tête contre les murs, je suis sincèrement enthousiaste quant à notre situation actuelle. Il ne s'agit pas de marketing ; il s'agit de progrès techniques tangibles qui changent fondamentalement la façon dont nous construisons et exploitons les plateformes de données. Plongeons-nous au cœur de ce qui façonne réellement la pile de données ouverte en ce moment.
Le changement de paradigme du lakehouse : de la vision à la réalité de la production
L'attrait conceptuel du lakehouse a toujours été fort : combiner le stockage vaste et rentable des data lakes avec les transactions ACID, l'application de schéma et les capacités de gouvernance des data warehouses. Pendant longtemps, c'était plus facile à dire qu'à faire. Mais la maturation des formats de table ouverts, en particulier Apache Iceberg, a été la clé de voûte pour rendre ce modèle architectural non seulement viable, mais efficace et véritablement pratique pour les charges de travail de production.
Le problème central que les formats de table ouverts résolvent est d'apporter l'intégrité transactionnelle et l'intelligence des métadonnées aux fichiers stockés dans le stockage d'objets cloud. Sans eux, votre data lake est, eh bien, juste un tas de fichiers. C'est un Far West des modifications de schéma ad hoc, des lectures incohérentes et des cauchemars de gestion manuelle des données. Iceberg, Delta Lake et Hudi ont transformé cela en introduisant une riche couche de métadonnées qui suit les manifestes de fichiers, les instantanés et l'évolution du schéma, permettant les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID) directement sur vos buckets S3, ADLS ou GCS. C'est véritablement impressionnant car cela signifie que nous n'avons plus besoin de déplacer les données entre les systèmes pour différents types de charges de travail ; les mêmes données peuvent alimenter l'analyse par lots, les tableaux de bord en temps réel et les modèles d'apprentissage automatique, le tout avec une sémantique cohérente et de solides garanties de qualité des données.
L'ascension d'Apache Iceberg : performance et évolution des spécifications
Apache Iceberg poursuit sa marche implacable vers le statut de format de table ouvert de facto. L'objectif du projet fin 2025 et début 2026 a été de consolider ses capacités de base, d'améliorer les performances et d'étendre sa spécification pour gérer des types de données et des charges de travail de plus en plus complexes. Nous avons constaté des progrès significatifs dans la façon dont Iceberg gère les fichiers de données sous-jacents pour optimiser les performances des requêtes, en allant au-delà du partitionnement de base pour adopter des techniques plus sophistiquées. C'est un composant essentiel de la DuckDB, Arrow et Parquet : la pile analytique ultime pour 2026 que de nombreuses équipes adoptent.
L'une des avancées récentes les plus notables est l'introduction des vecteurs de suppression dans la version 3 du format Iceberg. C'est important pour les données mutables. Auparavant, les suppressions ou mises à jour au niveau des lignes nécessitaient souvent la réécriture de fichiers de données entiers, ce qui pouvait être coûteux en ressources et entraîner une amplification de l'écriture, en particulier dans les scénarios à fort taux de rotation. Avec les vecteurs de suppression, Iceberg peut suivre les lignes supprimées sans réécrire immédiatement les fichiers de données de base. Au lieu de cela, il maintient un fichier distinct et petit (le vecteur de suppression) qui marque des positions de lignes spécifiques comme supprimées. Les moteurs de requête appliquent ensuite ces vecteurs de suppression au moment de la lecture. Ce mécanisme améliore considérablement l'efficacité des opérations DELETE et UPDATE, rendant les tables Iceberg beaucoup plus performantes pour les charges de travail transactionnelles qui modifient fréquemment les enregistrements existants.
De plus, la version 3 du format a également étendu la prise en charge des types, notamment en incluant un type VARIANT pour les données semi-structurées et des types GEOSPATIAL. Ceci est crucial pour gérer les charges utiles de données de plus en plus diverses que nous rencontrons, en particulier à partir de sources de streaming ou d'intégrations d'API.
Planification de l'analyse via le catalogue REST : un tournant pour l'interopérabilité
J'attendais cela : l'évolution de la spécification du catalogue REST Iceberg pour inclure un point de terminaison de planification de l'analyse. Il s'agit d'un changement fondamental dans la façon dont les moteurs de requête interagissent avec les tables Iceberg et promet d'améliorer considérablement l'interopérabilité et les performances dans tout l'écosystème.
Avec le point de terminaison de planification de l'analyse, la responsabilité de générer la liste des fichiers à analyser peut être déléguée au catalogue lui-même. Cela ouvre des possibilités incroyables :
- Planification de l'analyse optimisée avec mise en cache : Le catalogue peut mettre en cache les plans d'analyse fréquemment consultés, réduisant ainsi les lectures redondantes de métadonnées.
- Interopérabilité améliorée : En centralisant la planification de l'analyse, le catalogue peut potentiellement faire le pont entre différents formats de table.
- Découplage : Cela découple davantage le moteur de requête des complexités de la disposition physique du format de table.
Le jeu hybride de Snowflake : Unistore et tables Iceberg de première classe
Snowflake, une puissance traditionnelle de l'entrepôt de données, a fait des mouvements véritablement impressionnants pour adopter le lakehouse ouvert. Initialement, la prise en charge d'Iceberg par Snowflake se faisait principalement via des tables externes. Cela a considérablement changé. Dans un développement majeur, Snowflake a annoncé une prise en charge complète de DML (INSERT, UPDATE, DELETE, MERGE) pour les tables Iceberg gérées en externe via des bases de données liées au catalogue et le catalogue REST Iceberg.
Mais le véritable point fort est l'introduction des tables hybrides dans le cadre de leur initiative Unistore. C'est véritablement impressionnant car cela brouille les frontières entre OLTP et OLAP au sein d'une seule plateforme. Les tables hybrides sont optimisées à la fois pour les charges de travail transactionnelles à faible latence et à haut débit et pour les requêtes analytiques.
La nuance technique ici réside dans leur architecture de stockage double :
- Stockage basé sur des lignes : Principalement utilisé pour les applications transactionnelles, offrant une récupération et une modification rapides des lignes individuelles.
- Stockage en colonnes : Utilisé pour les requêtes analytiques, optimisé pour l'agrégation de données et les analyses à grande échelle.
Pour s'intégrer à Iceberg externe, Snowflake utilise de nouveaux objets au niveau du compte : EXTERNAL VOLUME et CATALOG INTEGRATION. Bien que cette intégration soit robuste, une petite réserve subsiste : pour les tables Iceberg gérées en externe, si Snowflake n'est pas le catalogue principal, vous devez toujours gérer soigneusement les actualisations des métadonnées.
Databricks et le lakehouse ouvert : l'adoption d'Iceberg par Unity Catalog
Databricks, l'origine de Delta Lake, a fait des progrès significatifs dans l'adoption d'Apache Iceberg, en particulier via son Unity Catalog. Il ne s'agit pas seulement de coexistence ; il s'agit d'une intégration profonde et de la fourniture d'une couche de gouvernance unifiée entre les formats.
Une annonce majeure a été l'aperçu public de la prise en charge complète d'Apache Iceberg dans Databricks, permettant les opérations de lecture et d'écriture pour les tables Iceberg gérées via l'implémentation de l'API du catalogue REST Iceberg par Unity Catalog. Lors de la configuration de vos propriétés de catalogue, vous pouvez utiliser ce convertisseur JSON vers YAML pour vous assurer que vos fichiers de configuration sont formatés correctement pour différents environnements de déploiement.
La configuration pour connecter un client Spark à Unity Catalog en tant que catalogue REST Iceberg implique généralement la définition des propriétés Spark telles que :
spark.sql.catalog.<catalog-name> = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.<catalog-name>.catalog-impl = org.apache.iceberg.rest.RESTCatalog
spark.sql.catalog.<catalog-name>.uri = <databricks-workspace-url>/api/2.1/unity-catalog/iceberg-rest
spark.sql.catalog.<catalog-name>.credential = <oauth_client_id>:<oauth_client_secret>
spark.sql.catalog.<catalog-name>.warehouse = <path-to-uc-managed-storage>
UniForm et la réalité multi-format de Databricks
L'engagement de Databricks en faveur de l'interopérabilité est également évident dans UniForm, une fonctionnalité qui permet de lire les tables Delta Lake en tant que tables Iceberg ou Hudi sans duplication de données. UniForm génère essentiellement des métadonnées Iceberg (ou Hudi) pour une table Delta Lake existante, permettant aux moteurs qui parlent principalement Iceberg d'interroger les tables Delta.
Bien qu'UniForm soit une solution pratique pour permettre l'interopérabilité en lecture, il est important de reconnaître les compromis. Il agit comme une couche de traduction de métadonnées, mais il ne modifie pas fondamentalement l'organisation des données sous-jacentes. Par exemple, les optimisations Iceberg spécifiques avancées ou les capacités de vecteurs de suppression ne sont pas entièrement exploitées lors de la lecture d'une table Delta activée par UniForm en tant qu'Iceberg.
La force invisible : l'indexation avancée et les optimiseurs de requêtes
Au-delà des formats de table eux-mêmes, les principales plateformes de données cloud repoussent sans relâche les limites des performances des requêtes. Pour Apache Iceberg, la communauté explore activement des capacités d'indexation avancées. Bien que les métadonnées d'Iceberg fournissent déjà des statistiques au niveau des fichiers pour un élagage puissant, l'ajout de fonctionnalités telles que les filtres de Bloom pour les colonnes à cardinalité élevée est un domaine clé de développement.
Le moteur de requête de Snowflake est étendu pour fonctionner de manière transparente avec les tables Iceberg, tirant parti de son Search Optimization Service et de son Query Acceleration Service existants. Databricks dispose également d'une suite de techniques d'optimisation des requêtes, notamment :
- Optimiseur basé sur les coûts (CBO) : Tire parti des statistiques de table pour des plans d'exécution efficaces.
- Élagage dynamique des fichiers (DFP) : Ignore les fichiers de données non pertinents pendant l'exécution des requêtes en fonction des filtres d'exécution.
- Auto Optimize : Inclut Optimized Writes et Auto Compaction pour gérer la taille des fichiers.
Évolution du schéma et contrats de données : naviguer dans le changement en toute confiance
L'une des caractéristiques les plus célébrées d'Iceberg est son évolution de schéma robuste et sécurisée. Iceberg vous permet d'ajouter, de supprimer, de renommer et de mettre à jour les types de colonnes au niveau des métadonnées, ce qui ne nécessite pas de réécritures complètes et coûteuses de la table. Au lieu de modifier manuellement les fichiers Parquet, vous émettez de simples commandes SQL DDL :
ALTER TABLE my_iceberg_table
ADD COLUMN event_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP();
Ces modifications sont transactionnelles et immédiatement disponibles. Cependant, avec une grande flexibilité vient le besoin d'une gouvernance solide. Les meilleures pratiques incluent la planification de la croissance future, l'utilisation de valeurs par défaut significatives et la maintenance du contrôle de version à des fins d'audit et de restauration.
Point de vue d'expert : la couche de métadonnées convergente et l'avenir axé sur le streaming
En regardant vers 2026 et au-delà, ma prédiction d'expert est que l'écosystème de données ouvert convergera vers une couche de métadonnées convergente. Les projets tels que Apache Polaris (actuellement en incubation) sont à l'avant-garde de cette tendance. Polaris vise à être un catalogue partagé et une couche de gouvernance pour les tables Iceberg sur plusieurs moteurs de requête.
De plus, le passage à des lakehouses "streaming first" est indéniable. Nous passons de considérer le streaming comme une réflexion après coup à nous attendre à une ingestion, un traitement et un service de requêtes continus par défaut. Cela exige des commits incrémentaux robustes et une gestion efficace des journaux de modifications.
Vérification de la réalité : la voie à suivre et les bizarreries persistantes
Bien que les progrès soient passionnants, il est crucial de rester réaliste. Le voyage vers un lakehouse ouvert véritablement transparent a encore ses aspérités :
- Compromis d'interopérabilité : Les différences fondamentales entre les formats signifient que l'interopérabilité parfaite, fonctionnalité par fonctionnalité, n'est pas toujours garantie.
- Complexité opérationnelle : La gestion de la compaction et de l'expiration des instantanés nécessite toujours une planification minutieuse.
- Limitations d'Iceberg Snowflake : Les tables Iceberg gérées par Snowflake ont encore des restrictions par rapport à celles gérées en externe.
- Fragmentation du catalogue : Plusieurs catalogues existent toujours, ajoutant une couche de complexité de configuration.
Guide pratique : automatisation de la maintenance des tables Iceberg (compaction)
L'un des aspects les plus critiques de la maintenance des performances des tables Iceberg est une compaction efficace des fichiers. Nous utiliserons l'action RewriteDataFiles de Spark pour consolider les petits fichiers en fichiers plus volumineux.
-- En supposant qu'un catalogue nommé 'spark_catalog' est configuré pour Iceberg
USE spark_catalog.my_db;
-- Exécuter la compaction pour les partitions froides
-- La taille cible du fichier est définie sur 512 Mo
ALTER TABLE event_logs
EXECUTE REWRITE DATA FILES
WHERE event_hour < date_trunc('hour', current_timestamp() - INTERVAL '2 HOURS')
OPTIONS (
'target-file-size-bytes' = '536870912',
'strategy' = 'binpack'
);
Cette commande ALTER TABLE ... EXECUTE REWRITE DATA FILES est une opération transactionnelle. Elle lit les fichiers de données spécifiés, écrit de nouveaux fichiers plus volumineux, puis valide atomiquement un nouvel instantané dans les métadonnées de la table. Après une compaction réussie, vous pouvez également envisager d'exécuter REMOVE ORPHAN FILES pour libérer de l'espace. La pile de données ouverte n'est plus seulement une promesse ; c'est une réalité en évolution rapide.
Sources
Cet article a été publié par l'équipe éditoriale de DataFormatHub, un groupe de développeurs et de passionnés de 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 SQL - Préparer les données pour les lakehouses
- JSON vers YAML - Formater les définitions de schéma