2 Les formats de tables ouverts sur un stockage S3 sur site sont désormais une base courante pour les data lakehouses qui restent dans les centres de données de l’organisation. Un format de table ouvert ajoute des fonctions de type base de données à des ensembles de fichiers stockés en mode objet : schémas, transactions, snapshots et planification efficace des requêtes. Les principaux formats sont open source et conçus pour fonctionner avec tout stockage exposant l’API S3 : ils ne sont donc pas liés à un cloud public. La réponse courte à la question de savoir si les formats de tables ouverts fonctionnent sur un stockage compatible S3 sur site est oui, à condition que le stockage remplisse quelques exigences. Cet article explique comment les formats de tables utilisent le stockage objet, ce que le stockage doit prendre en charge, le rôle des catalogues, les tâches de maintenance importantes et comment tester un déploiement. Pour l’architecture d’ensemble, consultez notre guide sur l’exploitation d’un data lakehouse sur un stockage objet sur site. Ce que fait un format de table ouvert Les fichiers bruts stockés en mode objet, comme Parquet ou ORC, n’ont aucune notion de table. Les premiers data lakes s’appuyaient sur l’arborescence des répertoires et le listage des fichiers pour définir les tables, ce qui rendait les modifications risquées et les requêtes lentes à grande échelle. Les formats de tables ouverts résolvent ce problème en ajoutant une couche de métadonnées : Les métadonnées de table enregistrent le schéma, le partitionnement et le snapshot courant. Les manifestes listent les fichiers de données de chaque snapshot, avec des statistiques comme le nombre de lignes et les valeurs minimale et maximale des colonnes. Les snapshots capturent l’état de la table à chaque commit, ce qui permet le voyage dans le temps et le retour arrière. Les commits atomiques garantissent que les lecteurs voient soit l’ancienne table, soit la nouvelle, jamais une écriture partielle. Les moteurs de requêtes utilisent ces métadonnées pour planifier les requêtes sans lister les répertoires et pour ignorer les fichiers qui ne peuvent pas correspondre à un filtre. Comment les formats de tables utilisent le stockage objet Toutes les données et métadonnées sont stockées sous forme d’objets. Une écriture type : Écrit de nouveaux fichiers de données dans le stockage objet. Écrit de nouveaux fichiers manifestes qui les décrivent. Écrit un nouveau fichier de métadonnées de table pointant vers le nouveau snapshot. Met à jour atomiquement le catalogue pour que la table pointe vers le nouveau fichier de métadonnées. Les lectures suivent le pointeur du catalogue vers le fichier de métadonnées, puis vers les manifestes, puis vers les fichiers de données nécessaires. Comme la bascule dans le catalogue constitue le point de commit, le stockage objet n’a pas besoin de gérer les transactions. Il doit stocker et servir les objets de façon fiable et cohérente. Ce que le stockage S3 sur site doit prendre en charge Cohérence forte en lecture après écriture Lorsqu’un processus d’écriture valide un snapshot, les lecteurs doivent voir immédiatement les nouveaux fichiers de métadonnées et de données. Un stockage à cohérence éventuelle peut faire manquer des fichiers aux lecteurs ou faire échouer des requêtes. Vérifiez que le stockage offre une cohérence forte pour les nouveaux objets, les écrasements et les listages. Couverture des opérations S3 essentielles Les formats de tables et les moteurs s’appuient sur des opérations standard : PUT, GET avec plages d’octets, HEAD, DELETE, suppression multi-objets, téléversement en plusieurs parties et listage. Les GET partiels sont particulièrement importants, car les lecteurs en colonnes récupèrent des blocs de colonnes précis. Testez aussi la gestion des erreurs, car les clients relancent les requêtes selon des codes d’erreur (en anglais) précis. Performances pour les petits et les gros objets Les fichiers de métadonnées et les manifestes sont petits et souvent lus ; les fichiers de données sont plus gros et lus par des requêtes partielles en parallèle. Le stockage doit gérer des taux de requêtes élevés avec une faible latence ainsi qu’un débit agrégé élevé. Montée en charge en nombre d’objets Avec le temps, les grandes tables accumulent des millions de fichiers de données et de nombreux fichiers de métadonnées. Le stockage doit gérer un grand nombre d’objets par bucket sans ralentir les listages ni les recherches. Sécurité et contrôle d’accès Les buckets analytiques contiennent souvent des données sensibles. Recherchez des politiques de bucket fines, l’intégration aux annuaires d’identité, le chiffrement au repos et en transit et la journalisation d’audit. Le rôle du catalogue Chaque format de table ouvert a besoin d’un catalogue pour suivre l’emplacement des métadonnées courantes de chaque table et effectuer la bascule atomique au moment du commit. Les options comprennent des services de catalogue REST, des services de metastore hérités d’anciennes plateformes de data lake et des catalogues adossés à une base de données. Sur site, le catalogue fonctionne comme un service aux côtés des moteurs de requêtes, généralement adossé à une base de données qui doit elle-même être hautement disponible et sauvegardée. Le catalogue est petit, mais critique : s’il est perdu, les tables deviennent introuvables alors que toutes les données sont intactes dans le stockage objet. Les tâches de maintenance qui touchent le stockage Les formats de tables ouverts génèrent des fichiers au fil du temps. Une maintenance régulière maîtrise les performances et la capacité : Le compactage fusionne les petits fichiers de données en fichiers plus gros, ce qui réduit le nombre de requêtes et accélère les balayages. L’expiration des snapshots supprime les anciens snapshots au-delà de la durée de conservation nécessaire au voyage dans le temps et à l’audit. Le nettoyage des fichiers orphelins supprime les fichiers qui ne sont plus référencés par aucun snapshot, comme les restes d’écritures échouées. La réécriture des manifestes consolide les métadonnées pour une planification plus rapide. La durée de conservation pour le voyage dans le temps doit être fixée délibérément. Conserver tous les snapshots indéfiniment consomme de la capacité ; les faire expirer trop vite supprime la possibilité d’auditer ou de revenir en arrière. Le versionnage (en anglais) des buckets sur le stockage objet ajoute une couche de protection, mais augmente aussi la capacité consommée. Les problèmes courants sur site et comment les éviter Adressage par chemin ou par hôte virtuel : configurez les clients selon le point de terminaison du stockage, souvent avec l’accès par chemin pour les points de terminaison sur site. TLS et certificats : les autorités de certification internes doivent être approuvées par chaque moteur et chaque client du catalogue. Point de terminaison et région : les clients attendent souvent une valeur de région même sur site ; définissez-la de façon cohérente. Délais d’attente et nouvelles tentatives : ajustez les pools de connexions et les paramètres de relance des clients pour les charges très concurrentes. Décalage d’horloge : la signature des requêtes échoue si les horloges dérivent ; gardez l’heure synchronisée entre calcul et stockage. Choisir un format de table Les principaux formats de tables ouverts partagent les mêmes idées de base, mais diffèrent par la prise en charge de leur écosystème, leur gestion des mises à jour et des suppressions et la maturité de leurs outils pour certains moteurs. Côté stockage, les exigences sont presque identiques : le choix dépend généralement des moteurs utilisés par vos équipes, de la fréquence des mises à jour sur place et du catalogue que vous comptez exploiter. Beaucoup d’organisations standardisent un format pour les nouvelles tables tout en gardant la possibilité d’en lire d’autres. Comme les données restent de toute façon dans des formats de fichiers ouverts sur un stockage compatible S3, changer de format plus tard est un projet de conversion de données, pas une migration de stockage. Quitter les anciennes organisations de tables Beaucoup d’organisations disposent déjà de données dans un stockage objet ou dans un ancien data lake fondé sur des tables organisées en répertoires. Celles-ci peuvent généralement être converties sur place ou migrées progressivement : L’enregistrement sur place ajoute les métadonnées du format de table aux fichiers Parquet ou ORC existants sans les réécrire, lorsque l’organisation des fichiers le permet. La réécriture lors de la migration copie les données dans de nouvelles tables avec de meilleures tailles de fichiers, un meilleur partitionnement et un meilleur tri, ce qui améliore souvent les performances. Le fonctionnement en parallèle garde anciennes et nouvelles tables côte à côte pendant la bascule des requêtes et des pipelines et la comparaison des résultats. Planifiez d’abord le catalogue, pour que les nouvelles tables soient enregistrées dans le système que les moteurs utiliseront désormais. Tester un déploiement Avant de déplacer des tables de production, menez un test structuré : Créer des tables avec des schémas, un partitionnement et des tailles de fichiers réalistes. Lancer des écritures et lectures concurrentes pour vérifier la cohérence et le comportement des commits. Exécuter des requêtes représentatives et mesurer le temps de planification et le débit de balayage. Lancer les tâches de maintenance et vérifier que suppressions, compactage et expiration des snapshots fonctionnent comme prévu. Simuler des pannes, comme la perte d’un nœud de stockage ou le redémarrage du catalogue, et vérifier la reprise. Souveraineté et contrôle Parce qu’ils sont ouverts et indépendants du stockage, les formats de tables ouverts permettent de garder les données analytiques sur une infrastructure maîtrisée sans renoncer aux fonctions modernes du lakehouse. C’est important pour les secteurs réglementés et les organismes publics soumis à des exigences de résidence des données. Cela réduit aussi la dépendance, puisque les mêmes tables peuvent être lues par plusieurs moteurs. Liste de contrôle : formats de tables ouverts sur S3 sur site Cohérence forte en lecture après écriture, listages compris. Couverture complète des opérations S3 essentielles, dont les GET partiels et les téléversements en plusieurs parties. Taux de requêtes élevés et faible latence pour les petits objets de métadonnées. Débit agrégé élevé pour les lectures de données en parallèle. Capacité à gérer des millions d’objets par bucket. Un service de catalogue hautement disponible et sauvegardé. Compactage, expiration des snapshots et nettoyage des fichiers orphelins planifiés. Paramètres clients corrects pour le style d’adressage, TLS, la région et les délais d’attente. Contrôle d’accès fin, chiffrement et journalisation d’audit. En résumé Les formats de tables ouverts fonctionnent bien sur un stockage objet compatible S3 sur site. Le stockage doit être cohérent, compatible avec les opérations S3 qu’utilisent les formats de tables et rapide aussi bien pour les petites lectures de métadonnées que pour les gros balayages parallèles. Ajoutez un catalogue fiable et une maintenance régulière, et vous obtenez un lakehouse aux fonctions modernes qui reste sous votre contrôle. Pour la vue d’ensemble, consultez l’exploitation d’un data lakehouse sur un stockage objet sur site. Questions fréquentes Les formats de tables ouverts exigent-ils un stockage objet en cloud public ? Non. Ils fonctionnent avec tout stockage qui implémente l’API S3 avec une cohérence forte, y compris un stockage objet sur site. De quelles fonctions S3 les formats de tables ouverts ont-ils besoin ? Cohérence forte, opérations standard sur les objets, GET partiels, téléversements en plusieurs parties, suppression multi-objets et listage efficace. Le stockage objet doit-il gérer les transactions ? Non. Les commits sont rendus atomiques par le catalogue, qui bascule un pointeur vers les nouvelles métadonnées. Le stockage objet doit stocker et servir les objets de façon fiable et cohérente. Quelle maintenance les formats de tables ouverts nécessitent-ils ? Compactage, expiration des snapshots, nettoyage des fichiers orphelins et réécriture périodique des manifestes. Un catalogue est-il nécessaire ? Oui. Le catalogue suit les métadonnées courantes de chaque table et effectue le commit atomique.
