2 Les performances du stockage objet déterminent la vitesse à laquelle un moteur de requêtes fournit des réponses aux analystes. Les moteurs de requêtes SQL distribués modernes lisent les données directement dans le stockage objet, dans des formats de fichiers ouverts comme Parquet et ORC, généralement organisés par un format de table ouvert. Ils n’ont pas de stockage propre derrière lequel s’abriter : chaque requête dépend de la vitesse à laquelle le stockage objet peut livrer des données à des dizaines ou des centaines de workers simultanément. Un cluster de requêtes bien réglé sur un stockage lent reste un cluster lent. Cet article explique comment les moteurs de requêtes distribués lisent dans le stockage objet, quels indicateurs de stockage comptent, comment dimensionner le stockage et le réseau d’un déploiement et comment l’organisation des fichiers et le cache influent sur les performances. Il s’applique à tout moteur qui sépare le calcul du stockage et lit via l’API S3. Pour l’architecture d’ensemble, consultez notre guide sur l’exploitation d’un data lakehouse sur un stockage objet sur site. Comment un moteur de requêtes distribué lit dans le stockage objet Lorsqu’une requête s’exécute, un moteur type : Planifie la requête à partir des métadonnées de table du catalogue et des fichiers manifestes du format de table. Élimine les partitions et les fichiers qui ne peuvent pas contenir de lignes correspondantes, grâce aux statistiques stockées dans les métadonnées. Découpe les fichiers restants en unités de travail et les attribue aux workers. Fait émettre par chaque worker des requêtes GET S3 en parallèle, souvent des lectures partielles de blocs de colonnes précis. Renvoie les résultats en flux à travers le cluster jusqu’au coordinateur. Deux conséquences en découlent. D’abord, une seule requête peut émettre des milliers de petites lectures partielles simultanées : le traitement des requêtes compte autant que la bande passante brute. Ensuite, les lectures de métadonnées (consultations du catalogue, listes de manifestes, listages de fichiers) ont lieu avant tout mouvement de données : des opérations de métadonnées lentes ajoutent de la latence à chaque requête. Les indicateurs de stockage qui comptent Débit de lecture agrégé Pour les gros balayages, la limite est le nombre de gigaoctets par seconde que le stockage objet peut servir à l’ensemble des workers. Une règle pratique consiste à estimer le débit que chaque worker peut absorber lorsqu’il est limité par le processeur pour la décompression et le filtrage, à le multiplier par le nombre de workers, puis à vérifier que le cluster de stockage et le réseau peuvent fournir ce chiffre avec de la marge. Requêtes par seconde et latence des petites lectures Les formats en colonnes favorisent les lectures partielles de quelques mégaoctets ou moins. Une requête qui touche des milliers de fichiers peut émettre des dizaines de milliers de requêtes GET. Un stockage qui gère bien les grosses lectures séquentielles mais peine face à des taux de requêtes élevés bridera les requêtes. Demandez des chiffres de performance pour des tailles d’objets et de plages réalistes, pas seulement pour de gros transferts séquentiels. Délai avant le premier octet Les tableaux de bord interactifs exécutent de nombreuses requêtes courtes. Pour elles, le délai entre l’envoi d’une requête et la réception du premier octet compte davantage que le débit maximal. Une latence du premier octet faible et régulière garde les requêtes courtes rapides. Listage et opérations de métadonnées Les anciennes organisations de tables reposent sur le listage des répertoires pour trouver les fichiers. Les formats de tables modernes réduisent ce besoin en suivant les fichiers dans des manifestes, mais les catalogues et les moteurs émettent encore des appels HEAD et LIST. Un stockage dont le listage est lent avec un grand nombre d’objets crée un goulot d’étranglement caché. Cohérence Les moteurs supposent qu’une fois une écriture terminée, les lecteurs la voient. Une cohérence forte en lecture après écriture sur le stockage objet évite les requêtes en échec et les résultats périmés, surtout lorsque l’ingestion et les requêtes tournent en même temps. Dimensionner le stockage et le réseau Partez de la charge de travail plutôt que de la capacité : Concurrence : combien de requêtes tournent simultanément au pic, et combien de workers chacune utilise. Volume balayé : la quantité de données qu’une requête lourde type lit après élagage. Temps de réponse cible : ce qu’attendent les analystes et les tableaux de bord. À partir de là, estimez le débit de lecture nécessaire. Vérifiez ensuite trois endroits où le tuyau peut se rétrécir : Nœuds de stockage : chaque nœud fournit un certain débit, limité par les disques, le processeur et les interfaces réseau. Ajoutez des nœuds jusqu’à ce que le total dépasse la cible. Fabric réseau : les liens entre calcul et stockage, y compris les liaisons montantes spine ou top-of-rack, doivent supporter la totalité du débit agrégé. Les liens sursouscrits sont un plafond caché fréquent. Répartition de charge (en anglais) : les requêtes doivent se répartir uniformément entre les points de terminaison du stockage. La planification de la capacité (en anglais) reste importante, mais pour les clusters analytiques, ce sont généralement les performances qui déterminent le nombre de nœuds avant la capacité. L’organisation des fichiers : votre principal levier La vitesse du stockage ne peut pas compenser une mauvaise organisation des fichiers. Le réglage le plus efficace se fait généralement dans la table, pas dans le matériel. Taille des fichiers : les très petits fichiers multiplient les requêtes et la surcharge de métadonnées. Beaucoup d’équipes visent des fichiers de quelques centaines de mégaoctets pour les grandes tables et lancent régulièrement un compactage pour fusionner les petits fichiers écrits par l’ingestion en flux. Partitionnement : partitionnez selon les colonnes sur lesquelles les requêtes filtrent, comme la date, mais évitez des partitions si fines que chacune ne contient que quelques fichiers minuscules. Tri et regroupement : trier les données dans les fichiers selon les colonnes de filtre courantes rend les statistiques min et max plus sélectives, ce qui permet d’ignorer davantage de fichiers et de groupes de lignes. Taille des groupes de lignes et des pages : des valeurs par défaut raisonnables conviennent à la plupart des charges ; des groupes de lignes très petits augmentent le nombre de requêtes. Compression : les codecs modernes échangent du temps processeur contre moins de données lues. Sur un stockage rapide, une compression plus légère peut être plus rapide ; sur un réseau contraint, une compression plus forte peut l’emporter. Les formats de tables ouverts aident en suivant des statistiques au niveau des fichiers et en permettant compactage et maintenance sans réécrire des tables entières. Le cache La plupart des moteurs de requêtes prennent en charge une forme de cache, ce qui modifie le besoin en stockage : Le cache de métadonnées garde en mémoire les informations du catalogue et des manifestes, ce qui réduit les lectures de métadonnées répétées. Le cache de données sur les SSD locaux des workers garde les segments de fichiers fréquemment lus près du calcul. Les tableaux de bord sollicités peuvent lire surtout depuis le cache, tandis que les requêtes ad hoc vont toujours au stockage objet. Le cache de résultats au niveau de l’outil décisionnel ou du moteur évite de réexécuter des requêtes identiques. Le cache allège la charge sur le stockage objet mais ne supprime pas le besoin d’un débit élevé. Les balayages à froid, les nouvelles données et les défauts de cache après un redémarrage sollicitent directement le stockage. Stockage objet sur site ou en cloud public Dans le cloud public, les clusters de requêtes lisent dans un service partagé dont vous ne contrôlez ni les limites de requêtes par préfixe ni les chemins réseau, et le transfert de données entre régions ou hors du cloud ajoute des coûts. Sur site, vous maîtrisez le réseau entre calcul et stockage et pouvez le concevoir pour le débit nécessaire, mais il vous revient de le dimensionner correctement. Beaucoup d’organisations qui exploitent des charges analytiques importantes et régulières choisissent un stockage objet sur site pour un coût et des performances prévisibles, et gardent leurs données sensibles dans un lieu connu. Tester avant de s’engager Les bancs d’essai synthétiques reflètent rarement les vrais schémas de requêtes. Un plan de test pragmatique : Charger une copie représentative d’une vraie table, avec des tailles de fichiers et un partitionnement réalistes. Exécuter vos vraies requêtes lourdes et celles des tableaux de bord avec la concurrence attendue. Mesurer les temps de requête de bout en bout, le débit du stockage, les taux de requêtes et les percentiles de latence. Recommencer avec le cache désactivé pour observer le comportement brut du stockage. Ajouter des nœuds de stockage ou des workers et vérifier que les performances progressent de façon à peu près linéaire. Surveillez aussi les erreurs et les nouvelles tentatives. Des réponses de limitation ou des délais d’attente dépassés sous charge sont les premiers signes que le stockage ou le réseau est le goulot d’étranglement. Les goulots d’étranglement courants et comment les repérer Workers inactifs en attente d’E/S : le débit du stockage ou le traitement des requêtes est la limite. Processeur des workers saturé, stockage sous-utilisé : le calcul est la limite ; ajoutez des workers ou réduisez le travail de décompression. Planification lente avant tout mouvement de données : les opérations de métadonnées ou de catalogue sont lentes, ou les tables contiennent trop de petits fichiers. Débit qui plafonne malgré l’ajout de nœuds : cherchez un lien réseau sursouscrit ou une répartition de charge inégale. Performances qui se dégradent avec le temps : les petits fichiers s’accumulent ; planifiez un compactage. Liste de contrôle : stockage objet pour un moteur de requêtes distribué Débit de lecture agrégé dimensionné pour la concurrence maximale, avec de la marge. Taux de requêtes élevés et faible latence pour les petites lectures partielles. Listage et opérations HEAD rapides avec un grand nombre d’objets. Cohérence forte en lecture après écriture. Réseau non sursouscrit entre calcul et stockage. Répartition de charge homogène entre les points de terminaison du stockage. Tailles de fichiers saines, partitionnement adapté et compactage régulier. Cache de métadonnées et de données configuré sur les workers. Tests avec de vraies requêtes et une concurrence réelle avant la production. En résumé Un moteur de requêtes distribué n’est jamais plus rapide que le stockage dans lequel il lit. Le stockage doit fournir un débit agrégé élevé, traiter un grand nombre de petites requêtes avec une faible latence et répondre rapidement aux appels de métadonnées, le tout sur un réseau qui ne devient pas le goulot d’étranglement. L’organisation des fichiers et le cache font le reste. Avec ces bases, un stockage objet sur site peut offrir une analytique interactive à l’échelle du pétaoctet. Pour l’architecture complète, consultez l’exploitation d’un data lakehouse sur un stockage objet sur site, et pour déplacer des données existantes, la migration de HDFS vers le stockage objet. Questions fréquentes Quelles performances de stockage un moteur de requêtes SQL exige-t-il ? Un débit de lecture agrégé suffisant pour la concurrence maximale, des taux de requêtes élevés pour les petites lectures partielles, une faible latence du premier octet et des opérations de métadonnées rapides. Les chiffres exacts dépendent du nombre de workers et des schémas de requêtes. Le débit ou la latence compte-t-il le plus pour les requêtes analytiques ? Les deux. Les gros balayages dépendent du débit ; les tableaux de bord interactifs dépendent de la latence et du traitement des requêtes. La plupart des déploiements ont besoin des deux. Les petits fichiers nuisent-ils aux performances des requêtes sur le stockage objet ? Oui. Les petits fichiers multiplient les requêtes et la surcharge de métadonnées. Le compactage régulier en fichiers plus gros est l’une des optimisations les plus efficaces. Le cache dispense-t-il d’un stockage objet rapide ? Non. Le cache aide les requêtes répétées, mais les balayages à froid, les nouvelles données et les défauts de cache lisent toujours dans le stockage objet. Un stockage objet sur site peut-il égaler le cloud public pour l’analytique ? Oui, lorsque les nœuds de stockage et le réseau sont dimensionnés pour la charge. Le sur site apporte aussi un coût prévisible et la maîtrise de la localisation des données.
