Migration de Hadoop vers le Cloud : Double de capacité de stockage et moins de coûts opérationnels

Yimian est un fournisseur de services d’analyse de données alimenté par l’IA, spécialisé dans les données du commerce numérique. Nous offrons des informations en temps réel sur la stratégie commerciale, le développement de produits et les opérations de commerce numérique. Nombre de nos clients sont des leaders industriels dans les secteurs de la soins personnels, maquillage, F&B, animaux de compagnie et automobile, tels que Procter and Gamble, Unilever et Mars.

Notre architecture de technologie d’origine était un cluster big data construit à l’aide de CDH (Cloudera Distributed Hadoop) dans un centre de données on-premises. À mesure que notre entreprise a grandi, le volume de données a augmenté de manière significative.

Pour relever des défis tels que des cycles d’échelle longs, des ressources de calcul et de stockage inadéquates, et des coûts de maintenance élevés, nous avons décidé de transformer notre architecture de données et de migrer vers le cloud, adoptant une approche de séparation entre stockage et calcul. Après une évaluation attentive, nous avons adopté Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS).

Actuellement, avec JuiceFS, nous avons mis en place une architecture découplée de calcul et de stockage, doublant notre capacité de stockage totale. Remarquablement, nous n’avons constaté aucun impact significatif sur les performances, et nos coûts opérationnels ont été considérablement réduits.

Dans cet article, nous partagerons notre conception d’architecture pour migrer Hadoop vers le cloud, pourquoi nous avons choisi JuiceFS+EMR+OSS et comment nous tirons parti de la nouvelle architecture. Notre objectif est d’offrir des perspectives précieuses pour ceux qui sont confrontés à des défis similaires grâce à ce post.

Notre Ancienne Architecture et Défis

Pour répondre à nos besoins croissants en matière d’applications, nous avons été en train de ramasser des données à partir de centaines de grands sites Web, avec un nombre actuel dépassant 500. Au fil du temps, nous avons accumulé d’importantes quantités de données brutes, intermédiaires et de résultats. Alors que nous continuions à élargir nos crawls de sites Web et notre base de clients, notre volume de données augmentait rapidement. Par conséquent, nous avons décidé d’élargir notre matériel pour répondre aux besoins croissants.

L’Architecture Originale

La figure suivante montre notre architecture précédente, qui impliquait un cluster de big data basé sur CDH déployé dans un centre de données :

• Les composants clés comprenaient Hive, Spark et HDFS.
• Plusieurs systèmes de production de données, avec Kafka comme l’un d’entre eux, alimentaient le cluster.
• Nous avons utilisé d’autres solutions de stockage, telles que TiDB, HBase et MySQL, en plus de Kafka.

Original architecture at Yimian

Les données provenaient des systèmes d’application et de collecte de données en amont, où elles étaient écrites dans Kafka. Nous avons utilisé un cluster Kafka Connect pour synchroniser les données dans HDFS.

Au-dessus de cette architecture, nous avons développé une plateforme de développement de données personnalisée appelée OneWork pour gérer diverses tâches. Ces tâches étaient planifiées via Airflow et traitées dans des files d’attente de tâches.

Nos Points Sensibles

Les défis auxquels nous avons été confrontés étaient les suivants :

• Croissance rapide des données des applications et cycles de mise à l’échelle longs : Notre cluster CDH, déployé en 2016, gérait déjà des pétaoctets de données dès 2021. Cependant, la croissance des données dépassait souvent la planification des équipements, entraînant des évolutions fréquentes tous les six mois. Cela a consommé des ressources et du temps significatifs.
• Couplage entre le stockage et le calcul, et difficulté de planification des capacités : L’architecture traditionnelle Hadoop associe étroitement le stockage et le calcul, ce qui rend difficile l’échelle et la planification indépendantes en fonction des besoins en stockage ou en calcul. Par exemple, l’agrandissement du stockage nécessiterait également l’achat de ressources de calcul inutiles. Cela a conduit à une allocation des ressources inefficace.
• Peur de mettre à niveau en raison de notre version CDH : Notre version CDH était ancienne, et nous hésitions à la mettre à niveau en raison de préoccupations concernant la stabilité et la compatibilité.
• Coûts d’exploitation élevés: Avec environ 200 employés, nous n’avions qu’un seul personnel d’exploitation à temps plein. Cela a entraîné un lourd fardeau. Pour atténuer cela, nous cherchions un architecture plus stable et simple.
• Point de défaillance unique du centre de données : Toutes les données stockées dans un seul centre de données représentaient un risque à long terme. En cas de dommages aux câbles ou autres problèmes, avoir un seul centre de données crée un point de défaillance unique.

Nos exigences pour la nouvelle architecture

Pour relever nos défis et répondre aux demandes croissantes, nous avons décidé de certaines modifications architecturales. Les principaux aspects que nous avons pris en compte pour la mise à niveau incluent ce qui suit :

• Adoption du cloud, évolutivité élastique et flexibilité opérationnelle: Adopter les services cloud simplifierait les opérations. Par exemple, tirer parti du stockage basé sur le cloud nous permet de nous concentrer sur l’application tout en évitant les tâches de maintenance. De plus, les ressources cloud permettent une évolutivité élastique sans déploiements de matériel longs et configurations système.
• Découplage stockage-calcul: Notre objectif était de séparer le stockage et le calcul pour obtenir une meilleure flexibilité et performances.
• Préférence pour les composants open-source, évitant le verrouillage par le fournisseur: Bien que nous utilisions des services cloud, nous avons cherché à minimiser notre dépendance à certains fournisseurs. Alors que nous utilisions AWS Redshift pour les services aux clients, nous avons plutôt favorisé les composants open-source pour les opérations internes.
• Compatibilité avec les solutions existantes, contrôle des coûts et risques: Notre objectif était d’assurer la compatibilité avec les solutions actuelles pour minimiser les coûts de développement et l’impact sur notre application.

Pourquoi Nous Avons Choisi JuiceFS+EMR+OSS

Après avoir évalué diverses solutions, nous avons choisi EMR+JuiceFS+OSS pour construire une plateforme de big data avec stockage-calcul séparé et avons progressivement migré notre centre de données on-premise vers le cloud.

New architecture at Yimian

Dans cette configuration, le stockage d’objets remplace HDFS, et JuiceFS sert de couche de protocole en raison de son support pour les protocoles POSIX et HDFS. Au sommet, nous utilisons une solution Hadoop semi-gérée, EMR. Elle inclut Hive, Impala, Spark, Presto/Trino et d’autres composants.

Alibaba Cloud vs. Autres Clouds Publics

Après notre évaluation soigneuse, nous avons choisi Alibaba Cloud au-dessus d’AWS et Azure en raison des facteurs suivants:

• Proximité : La zone de disponibilité d’Alibaba Cloud dans la même ville que notre centre de données garantit une faible latence et des coûts réduits pour le réseau.
• Composants open-source complets : Alibaba Cloud EMR offre une large gamme de composants open-source liés à Hadoop. Outre notre forte utilisation de Hive, Impala, Spark et Hue, il propose également une intégration transparente avec Presto, Hudi, Iceberg, et bien plus encore. Au cours de nos recherches, nous avons constaté que seul EMR intègre nativement Impala, tandis que AWS et Azure proposent soit des versions inférieures, soit nécessitent une installation et un déploiement manuels.

JuiceFS vs. JindoFS

Qu’est-ce que JuiceFS ?

JuiceFS est un système de fichiers distribué, cloud-native et open-source, doté d’une haute performance. Il offre une compatibilité totale avec POSIX, permettant d’utiliser le stockage d’objets comme un disque local massif à travers différentes plateformes et régions.

JuiceFS adopte une architecture séparée pour les données et les métadonnées, permettant la conception d’un système de fichiers distribué. Lors de l’utilisation de JuiceFS pour stocker des données, les données sont persistées dans le stockage d’objets comme Amazon S3, tandis que les métadonnées peuvent être stockées sur Redis, MySQL, TiKV, SQLite et d’autres bases de données.

En plus de POSIX, JuiceFS est entièrement compatible avec l’API SDK HDFS, permettant une substitution transparente de HDFS pour la séparation stockage-calcul.

The JuiceFS architecture

Pourquoi avons-nous choisi JuiceFS plutôt que JindoFS

Nous avons opté pour JuiceFS plutôt que pour JindoFS en fonction des considérations suivantes :

• Conception de stockage : JuiceFS adopte une architecture de stockage séparée pour les données et les métadonnées, permettant une conception de système de fichiers distribué. Les données sont persistées dans un stockage d’objets, tandis que les métadonnées peuvent être stockées dans divers bases de données comme Redis, MySQL, TiKV et SQLite, offrant une plus grande flexibilité. En revanche, les métadonnées de JindoFS sont stockées sur le disque dur local du cluster EMR, ce qui rend la maintenance, les mises à niveau et les migrations moins pratiques.
• Flexibilité de stockage : JuiceFS propose divers solutions de stockage, supportant la migration en ligne entre différents schémas et augmentant la portabilité. JindoFS ne supporte que le stockage OSS pour les données de bloc.
• Support de la communauté open-source : JuiceFS est basé sur une communauté open-source, supportant tous les environnements de cloud public. Ceci facilite l’expansion future vers une architecture multi-cloud.

La conception de l’architecture entière

Considérant que certaines applications seront encore maintenues dans le cluster Hadoop du centre de données, nous employons en réalité une architecture de cloud hybride, comme illustré dans la figure ci-dessous.

A hybrid cloud architecture

Dans le schéma architectural :

• En haut se trouvent Airflow et OneWork, tous deux supportant le déploiement distribué, ils peuvent donc être facilement échelonnés horizontalement.
• À gauche se trouve l’IDC, qui utilise l’architecture CDH traditionnelle et quelques clusters Kafka.
• À droite se trouve le cluster EMR déployé sur Alibaba Cloud.

L’IDC et le cluster EMR sont connectés par une ligne dédiée à haut débit.

Comment nous bénéficions de la nouvelle architecture

Avantages de la séparation stockage-calcul

Avec la mise en œuvre de la découplage entre stockage et calcul, notre capacité de stockage totale a doublé tandis que les ressources de calcul restent stables. Parfois, nous activons des nœuds de tâches temporaires en fonction des besoins. Dans notre scénario, le volume de données connaît une croissance rapide tandis que les demandes de requêtes restent stables. Depuis 2021, notre volume de données a doublé. Nous avons effectué des modifications minimes des ressources de calcul depuis le début jusqu’à présent, à l’exception de l’activation occasionnelle de ressources élastiques et de nœuds de tâches temporaires pour répondre à des besoins d’applications spécifiques.

Changements de Performance

Pour notre scénario d’application, qui implique principalement le traitement par lots à grande échelle pour le calcul hors ligne, il n’y a pas d’impact significatif sur la performance. Cependant, pendant la phase de PoC, nous avons constaté des améliorations des temps de réponse pour les requêtes ad hoc Impala.

Pendant la phase de PoC, nous avons effectué quelques tests simples. Cependant, interpréter précisément les résultats est difficile en raison de divers facteurs influents:

• Le passage de HDFS à JuiceFS
• Mises à niveau de la version des composants
• Modifications du moteur Hive
• Modifications de la charge du cluster

Tout cela rend difficile de tirer des conclusions définitives sur les différences de performance par rapport à notre précédente mise en œuvre de CDH sur des serveurs nus.

Facilité d’utilisation et Stabilité

Nous n’avons rencontré aucun problème avec JuiceFS.

En utilisant EMR, nous avons eu quelques petits problèmes. Dans l’ensemble, CDH est perçu comme plus stable et convivial.

Complexité de la mise en œuvre

Dans notre scénario, les processus les plus chronophages sont l’écriture différentielle duale et la vérification des données. Avec le recul, nous avons investi excessivement dans la vérification et pourrions la simplifier.

Plusieurs facteurs influencent la complexité:

• Scénarios d’application (hors ligne/temps réel, nombre de tables/tâches, applications de haut niveau)
• Versions des composants
• Outils de support et réserves

Plans futurs

Nos plans futurs incluent:

• Poursuivre la migration des applications restantes vers le cloud.
• Explorer une stratégie de stockage hiérarchisé chaud/froid en utilisant JuiceFS+OSS. Les fichiers JuiceFS sont entièrement démontés sur OSS, ce qui rend difficile la mise en place d’une hiérarchisation au niveau des fichiers. Notre approche actuelle consiste à migrer les données froides de JuiceFS vers OSS, à les définir en stockage d’archivage et à modifier le LOCATION des tables Hive ou des partitions sans affecter l’utilisation.
• Si le volume de données augmente et qu’il y a une pression sur l’utilisation de Redis, nous pourrions envisager de passer à TiKV ou à d’autres moteurs à l’avenir.
• Explorer les instances de calcul élastiques d’EMR pour réduire les coûts d’utilisation tout en respectant les accords de niveau de service des applications.