Analyse de mégadonnées sur des serveurs physiques

Utiliser Hadoop ou Spark sur une infrastructure cloud, c'est une bonne idée quand on fait du prototypage. Mais quand on traite des téraoctets de données de production tous les jours, ça change la donne. Les instances cloud spot sont préemptées en plein milieu d'une tâche. Les clusters EMR gérés sont facturés à la seconde, mais ça finit par coûter des centaines ou des milliers d'euros par mois pour des charges de travail analytiques continues.

Les serveurs dédiés Bare Metal offrent aux charges de travail Big Data ce que les machines virtuelles cloud ne peuvent pas garantir : un accès direct au matériel sans surcharge de l'hyperviseur, un débit d'E/S prévisible grâce NVMe et un coût mensuel fixe qui ne grimpe pas si tes tâches ETL prennent plus de temps que prévu.

Ce qui rend Bare Metal différent pour le Big Data

La taxe hyperviseur, c'est vrai. Les machines virtuelles cloud qui tournent sur du matériel physique partagé subissent des vols de temps CPU, la pression des ballons de mémoire des locataires voisins et des fluctuations des E/S réseau qui sont invisibles au niveau de l'API, mais qui apparaissent clairement dans la variation de la durée des tâches Spark. Une étape Spark qui prend 4 minutes le lundi peut prendre 7 minutes le jeudi sans raison apparente.

Sur le métal nu, le processeur, le bus mémoire et NVMe sont entièrement dédiés à ta charge de travail. Les opérations Spark Shuffle, qui ont besoin d'un débit élevé et constant en lecture et en écriture sur le stockage local, tournent à la vitesse nominale des disques plutôt que de passer par une couche de virtualisation.

Il y a aussi la question de la mémoire. La plupart des types d'instances cloud gérées offrant 192 Go de RAM coûtent entre 800 et 1 400 dollars par mois. Le serveur dédié ExtremeInMotion Hosting offre 192 Go de RAM DDR5 ECC associée à un processeur AMD EPYC 4545P pour 349,99 dollars par mois dans un centre de données géré.

Hadoop sur du matériel dédié

Hadoop à nœud unique vs Hadoop à nœuds multiples

Les clusters HDFS multi-nœuds restent la bonne architecture pour les ensembles de données qui dépassent vraiment la capacité d'un seul serveur, généralement au-delà de 50 à 100 To de données brutes. Pour les équipes d'analyse qui bossent avec des ensembles de données de 1 à 20 To, un seul serveur dédié à haute mémoire exécutant HDFS en mode pseudo-distribué, ou plus concrètement, exécutant Spark directement sur NVMe local, élimine la surcharge de réplication et les coûts de transfert réseau d'un cluster distribué.

Les deux NVMe de 3,84 To du niveau Extreme d'InMotion vous offrent 7,68 To d'espace de stockage brut, avec RAID 1 (mdadm) fournissant 3,84 To d'espace utilisable tolérant aux pannes. Pour l'espace de travail et les données intermédiaires, vous pouvez configurer le deuxième disque en dehors du RAID comme volume de travail Spark dédié, ce qui permet de protéger vos données permanentes tout en éliminant les conflits d'écriture lors de tâches intensives.

Configuration HDFS pour les déploiements sur un seul serveur

Pour faire tourner HDFS sur une seule machine, il faut régler le facteur de réplication sur 1. Ça évite la surcharge de stockage triple de la réplication HDFS standard, ce qui est cool quand on a un RAID pour protéger les disques durs. Les paramètres de configuration clés à régler sur un système de 192 Go :

• Définissez dfs.datanode.data.dir sur le point NVMe pour un stockage en bloc rapide.
• Configurez dfs.blocksize à 256 Mo ou 512 Mo pour les gros fichiers analytiques afin de réduire la surcharge des métadonnées NameNode.
• Réglez mapreduce.task.io.sort.mb sur 512 Mo par mappeur pour réduire la fréquence des débordements sur le matériel avec beaucoup de mémoire.
• Attribuez 120 à 140 Go des 192 Go disponibles à la gestion des ressources YARN, en laissant de la marge pour le système d'exploitation et NameNode.

Apache Spark : là où le bare metal est le plus rentable

Allocation de mémoire sur les systèmes de 192 Go

Les performances de Spark dépendent vraiment de la mémoire. La partie d'une tâche qui est transférée sur le disque plutôt que d'être finie en mémoire détermine si une tâche prend 3 minutes ou 30. Sur les instances cloud avec 32 ou 64 Go de RAM, le transfert est courant. Sur un système de 192 Go, la plupart des charges de travail analytiques sont finies entièrement en mémoire.

Une allocation pratique sur un serveur Extreme de 192 Go avec 16 cœurs :

• Mémoire du pilote Spark : 8 Go (assez pour la plupart des tâches d'analyse)
• Mémoire de l'exécuteur Spark : 160 Go répartis entre les exécuteurs (ce qui laisse 24 Go pour le système d'exploitation, le service de mélange et les frais généraux)
• spark.memory.fraction : 0 ,8 (alloue 80 % du tas de l'exécuteur pour l'exécution et la mémoire de stockage)
• Cœurs d'exécuteur : 4 cœurs par exécuteur, 4 exécuteurs = 16 cœurs au total utilisés

Cette configuration permet à un seul exécuteur de garder un DataFrame de 100 Go en mémoire sans débordement, ce qui change le profil de performance des algorithmes multi-passes comme l'apprentissage automatique itératif et l'analyse de graphes.

Performances NVMe

Les transformations de tri-fusion et de largeur de Spark écrivent les données de shuffle sur le disque local. Sur les SSD SATA, les écritures aléatoires atteignent un pic d'environ 500 Mo/s. NVMe ont un débit d'écriture séquentiel de 3 000 à 5 000 Mo/s. Pour une tâche qui écrit 200 Go de données aléatoires, la différence est d'environ 40 secondes sur NVMe 6 minutes sur SATA. Cet écart s'accumule sur des dizaines de tâches quotidiennes.

Configurez spark.local.dir pour pointer vers le NVMe pour les écritures aléatoires. Si vous avez un deuxième NVMe disponible en dehors du RAID, utilisez-le juste pour le répertoire aléatoire Spark pour éviter les conflits entre les E/S aléatoires et les lectures de données à partir du volume principal.

Analyse en temps réel : Kafka et Spark Streaming

Spark Structured Streaming, qui utilise Kafka, a besoin d'un traitement par micro-lots à faible latence. Sur une infrastructure cloud, la latence réseau vers un cluster Kafka géré, combinée à la variabilité du CPU des machines virtuelles, peut faire grimper le temps de traitement par micro-lots à plus de 5 secondes, même pour un débit modeste. En exécutant Kafka et Spark sur le même serveur physique ou sur des serveurs dédiés colocalisés, on élimine la variable réseau.

Un système AMD EPYC à 16 cœurs traite entre 50 000 et 200 000 messages par seconde via Kafka sans saturer le processeur, ce qui laisse une marge de manœuvre importante aux utilisateurs de Spark Structured Streaming pour traiter et agréger les données en parallèle.

Stockage en colonnes et performances NVMe

Les fichiers Parquet et ORC tirent un avantage énorme du NVMe. Les deux formats utilisent le prédicat pushdown et le column pruning, ce qui veut dire qu'une requête qui lit 5 % des colonnes d'un ensemble de données de 1 To peut ne faire que 50 Go d'E/S réelles. Sur NVMe qui supportent des lectures séquentielles de 5 Go/s, ce scan de 50 Go se fait en à peu près 10 secondes. Sur un volume cloud connecté au réseau à 1 Gbit/s plafonné à 125 Mo/s, le même scan prend près de 7 minutes.

Pour les charges de travail analytiques basées sur Parquet ou ORC, NVMe sur bare metal n'est pas une simple amélioration. Ça change le type de requêtes qui sont interactives par rapport à celles qui sont traitées par lots.

Comparaison des coûts : Bare Metal vs Cloud pour le Big Data

Configuration	Coût mensuel	RAM	Stockage	Notes
AWS EMR (nœuds r5.4xlarge x2)	Environ 980 $ par mois	256 Go au total	EBS (coût supplémentaire)	Les prix au comptant, ça peut être risqué
AWS EC2 r6i.4xlarge (dédié)	Environ 780 $ par mois	128 Go	EBS (coût supplémentaire)	Pas de gestion incluse
InMotion Extreme dédié	349,99 $ par mois	192 Go DDR5 ECC	3,84 To NVMe RAID 1)	Coût fixe
InMotion Advanced dédié	149,99 $ par mois	64 GO DDR4	1,92 To NVMe RAID 1)	Convient aux ensembles de données de moins de 500 Go en mémoire

L'avantage en termes de coûts est énorme, mais le plus important, c'est la prévisibilité. Les tâches ETL qui prennent plus de temps que prévu ne génèrent pas de factures surprises sur le matériel nu.

Quand utiliser plusieurs serveurs plutôt qu'un seul serveur à mémoire élevée

Un serveur puissant gère la plupart des charges de travail analytiques inférieures à 3 To de données actives. Les cas où une architecture multi-serveurs devient nécessaire :

• La taille des données brutes dépasse vraiment NVMe d'un seul serveur (plus de 7 To de données sources).
• Le nombre d'utilisateurs analytiques simultanés dépasse ce que Spark sur un seul serveur peut gérer sans faire la queue.
• Quand on a besoin d'une haute disponibilité, un seul serveur, c'est un risque de temps d'arrêt pas acceptable pour les pipelines de production.
• Il faut séparer les tâches entre Kafka pour l'ingestion, Spark pour le traitement et les couches de service.

Pour la plupart des équipes d'analyse de taille moyenne, un seul serveur dédié Extreme suffit pour gérer la charge de travail, avec une marge de manœuvre pour se développer. Si tu as besoin d'un deuxième serveur, l'équipe APS d'InMotion peut t'aider à concevoir une configuration multi-nœuds.

Infrastructure gérée pour les équipes d'ingénierie des données

Les équipes d'ingénierie des données devraient se concentrer sur la création de pipelines, pas sur les alertes à 3 heures du matin à propos de l'espace disque du serveur ou des interruptions OOM. L'équipe d'assistance produit avancée d'InMotion s'occupe des problèmes au niveau du système d'exploitation sur les serveurs dédiés, ce qui veut dire que votre équipe reçoit une alerte et une solution plutôt qu'un ticket à traiter.

Premier Care ajoute 500 Go de stockage de sauvegarde automatique pour les configurations de pipeline, les instantanés de données et les fichiers jar des applications Spark, ainsi que la protection contre les logiciels malveillants Monarx pour l'environnement serveur. Pour les équipes chargées des données qui stockent des infos commerciales sensibles, cette protection est super importante.

La consultation mensuelle d'une heure avec InMotion Solutions incluse dans Premier Care vaut vraiment le coup, surtout pour optimiser Spark et Hadoop. Les erreurs de configuration, comme des répertoires de tri trop petits ou des limites de mémoire YARN mal configurées, sont courantes et coûtent cher en temps de travail.

Pour commencer

La première étape, c'est de comparer la durée de tes tâches actuelles sur l'infrastructure cloud, puis de les exécuter sur une configuration d'essai InMotion Extreme. La différence de performance dans les tâches Spark qui demandent beaucoup de shuffle justifie généralement la migration dès le premier mois.

Pour les équipes qui lancent plusieurs tâches Spark par jour sur des ensembles de données de plus de 100 Go, les économies mensuelles par rapport à une infrastructure cloud équivalente couvrent généralement plusieurs fois le coût du serveur. La constance des performances est plus difficile à chiffrer, mais elle se reflète chaque jour dans la fiabilité du SLA du pipeline.