Nous sommes toujours étonnés du nombre de clients qui nous contactent pour migrer de HDFS vers un stockage objet moderne tel que MinIO. On pensait désormais que tout le monde avait fait la transition, mais chaque semaine, nous discutons avec une grande organisation très technique qui a décidé de faire la transition.
Très souvent, dans ces discussions, ils souhaitent conserver des éléments de leur infrastructure après leur migration. Il existe des frameworks et des logiciels issus de l'écosystème HDFS qui bénéficient d'une grande adhésion des développeurs et qui ont toujours leur place dans la pile de données moderne. En effet, nous avons souvent dit que beaucoup de bien était ressorti de l’écosystème HDFS. Le problème fondamental réside dans le stockage et le calcul étroitement couplés, pas nécessairement avec les outils et services issus de l’ère du Big Data.
Cet article de blog se concentrera sur la façon dont vous pouvez effectuer cette migration sans supprimer ni remplacer les outils et services qui ont de la valeur. La réalité est que si vous ne modernisez pas votre infrastructure, vous ne pouvez pas réaliser les progrès en matière d'IA/ML dont votre organisation a besoin, mais vous n'êtes pas obligé de tout jeter pour y parvenir.
Nous avons déjà traversé certains
Nœuds de calcul : Kubernetes gère efficacement les conteneurs Apache Spark et Apache Hive sans état sur les nœuds de calcul, garantissant une utilisation optimale des ressources et une mise à l'échelle dynamique.
Couche de stockage : MinIO
Couche d'accès : tous les accès au stockage d'objets MinIO sont unifiés via l'API S3, fournissant une interface transparente pour interagir avec les données stockées.
Couche de sécurité : la sécurité des données est primordiale. MinIO crypte toutes les données à l'aide de clés par objet, garantissant ainsi une protection robuste contre les accès non autorisés.
Gestion des identités : MinIO Enterprise s'intègre entièrement aux fournisseurs d'identité tels que WSO2, Keycloak, Okta, Ping Identity pour permettre aux applications ou aux utilisateurs de s'authentifier.
Un remplacement entièrement modernisé pour Hadoop qui permet à votre organisation de conserver Hive, YARN et tout autre produit de données de l'écosystème Hadoop pouvant s'intégrer au stockage objet qui constitue presque tout dans la pile de données moderne.
S3a est un point de terminaison essentiel pour les applications cherchant à s'éloigner de Hadoop, offrant une compatibilité avec un large éventail d'applications au sein de l'écosystème Hadoop. Depuis 2006, les backends de stockage objet compatibles S3 ont été intégrés de manière transparente à de nombreuses plates-formes de données au sein de l'écosystème Hadoop en tant que fonctionnalité par défaut. Cette intégration remonte à l'incorporation d'une implémentation client S3 dans les technologies émergentes.
Sur toutes les plateformes liées à Hadoop, l'adoption du module hadoop-aws
et aws-java-sdk-bundle
est une pratique courante, garantissant une prise en charge robuste de l'API S3. Cette approche standardisée facilite la transition en douceur des applications depuis les backends de stockage HDFS et S3. En spécifiant simplement le protocole approprié, les développeurs peuvent facilement faire passer leurs applications de Hadoop au stockage d'objets moderne. Le schéma de protocole pour S3 est indiqué par s3a://, tandis que pour HDFS, il est noté hdfs://.
Il est possible de parler longuement des avantages de la migration de Hadoop vers un stockage objet moderne. Si vous lisez ceci, vous savez déjà que sans migration hors des plates-formes héritées comme Hadoop, les avancées en matière d'IA et d'autres produits de données modernes seront probablement hors de question. La raison se résume aux performances et à l’échelle.
Il ne fait absolument aucun doute que les charges de travail modernes nécessitent des performances exceptionnelles pour rivaliser avec le volume de données traitées et la complexité des tâches désormais requises. Lorsque la performance n'est pas seulement une question d'analyse comparative vaniteuse, mais une exigence stricte, le champ des prétendants aux remplacements Hadoop
L’autre élément qui stimule les migrations est l’échelle cloud native. Lorsque le concept de cloud est moins un lieu physique qu'un lieu
Une partie intégrante de ce concept réside dans les avantages économiques découlant de la libération du verrouillage du fournisseur, qui permet à une organisation de choisir les meilleures options pour des charges de travail spécifiques. Sans oublier la dispense de conserver trois copies distinctes des données pour les protéger, une chose du passé avec
Avant de plonger dans les spécificités de notre architecture, vous devrez rendre quelques composants opérationnels. Pour migrer hors de Hadoop, vous devrez évidemment l'avoir installé au préalable. Si vous souhaitez simuler cette expérience, vous pouvez démarrer ce didacticiel en configurant la distribution Hortonworks de Hadoop ici .
Sinon, vous pouvez commencer par les étapes d'installation suivantes :
Configurer Ambari : Ensuite,
Installez Apache Spark : Spark est essentiel pour traiter des données à grande échelle. Suivre la
Installer MinIO : En fonction de votre environnement, vous pouvez choisir entre deux approches d'installation :
Après avoir installé avec succès ces éléments, vous pouvez configurer Spark et Hive pour utiliser MinIO au lieu de HDFS. Accédez à l'interface utilisateur Ambari http://<ambari-server>:8080/ et connectez-vous à l'aide des informations d'identification par défaut : username: admin, password: admin
,
Dans Ambari, accédez aux services, puis à HDFS, puis au panneau Configs comme dans la capture d'écran ci-dessous. Dans cette section, vous configurez Ambari pour utiliser S3a avec MinIO au lieu de HDFS.
Faites défiler vers le bas et accédez à Custom core-site
. C'est ici que vous configurerez S3a.
sudo pip install yq alias kv-pairify='yq ".configuration[]" | jq ".[]" | jq -r ".name + \"=\" + .value"'
À partir de là, votre configuration dépendra de votre infrastructure. Mais ce qui suit pourrait représenter un moyen pour core-site.xml
de configurer S3a avec MinIO fonctionnant sur 12 nœuds et 1,2 TiB de mémoire.
cat ${HADOOP_CONF_DIR}/core-site.xml | kv-pairify | grep "mapred" mapred.maxthreads.generate.mapoutput=2 # Num threads to write map outputs mapred.maxthreads.partition.closer=0 # Asynchronous map flushers mapreduce.fileoutputcommitter.algorithm.version=2 # Use the latest committer version mapreduce.job.reduce.slowstart.completedmaps=0.99 # 99% map, then reduce mapreduce.reduce.shuffle.input.buffer.percent=0.9 # Min % buffer in RAM mapreduce.reduce.shuffle.merge.percent=0.9 # Minimum % merges in RAM mapreduce.reduce.speculative=false # Disable speculation for reducing mapreduce.task.io.sort.factor=999 # Threshold before writing to drive mapreduce.task.sort.spill.percent=0.9 # Minimum % before spilling to drive
De nombreuses optimisations peuvent être explorées en consultant la documentation sur ce modèle de migration.
Redémarrez tout lorsque vous êtes satisfait de la configuration.
Vous devrez également accéder au panneau de configuration Spark2.
Faites défiler jusqu'à Custom spark-defaults
et ajoutez la propriété suivante à configurer avec MinIO :
spark.hadoop.fs.s3a.access.key minio spark.hadoop.fs.s3a.secret.key minio123 spark.hadoop.fs.s3a.path.style.access true spark.hadoop.fs.s3a.block.size 512M spark.hadoop.fs.s3a.buffer.dir ${hadoop.tmp.dir}/s3a spark.hadoop.fs.s3a.committer.magic.enabled false spark.hadoop.fs.s3a.committer.name directory spark.hadoop.fs.s3a.committer.staging.abort.pending.uploads true spark.hadoop.fs.s3a.committer.staging.conflict-mode append spark.hadoop.fs.s3a.committer.staging.tmp.path /tmp/staging spark.hadoop.fs.s3a.committer.staging.unique-filenames true spark.hadoop.fs.s3a.committer.threads 2048 # number of threads writing to MinIO spark.hadoop.fs.s3a.connection.establish.timeout 5000 spark.hadoop.fs.s3a.connection.maximum 8192 # maximum number of concurrent conns spark.hadoop.fs.s3a.connection.ssl.enabled false spark.hadoop.fs.s3a.connection.timeout 200000 spark.hadoop.fs.s3a.endpoint http://minio:9000 spark.hadoop.fs.s3a.fast.upload.active.blocks 2048 # number of parallel uploads spark.hadoop.fs.s3a.fast.upload.buffer disk # use disk as the buffer for uploads spark.hadoop.fs.s3a.fast.upload true # turn on fast upload mode spark.hadoop.fs.s3a.impl org.apache.hadoop.spark.hadoop.fs.s3a.S3AFileSystem spark.hadoop.fs.s3a.max.total.tasks 2048 # maximum number of parallel tasks spark.hadoop.fs.s3a.multipart.size 512M # size of each multipart chunk spark.hadoop.fs.s3a.multipart.threshold 512M # size before using multipart uploads spark.hadoop.fs.s3a.socket.recv.buffer 65536 # read socket buffer hint spark.hadoop.fs.s3a.socket.send.buffer 65536 # write socket buffer hint spark.hadoop.fs.s3a.threads.max 2048 # maximum number of threads for S3A
Redémarrez tout une fois les modifications de configuration appliquées.
Accédez au panneau Hive pour terminer la configuration.
Faites défiler jusqu'à Custom hive-site
et ajoutez la propriété suivante :
hive.blobstore.use.blobstore.as.scratchdir=true hive.exec.input.listing.max.threads=50 hive.load.dynamic.partitions.thread=25 hive.metastore.fshandler.threads=50 hive.mv.files.threads=40 mapreduce.input.fileinputformat.list-status.num-threads=50
Vous pouvez trouver des informations de configuration plus précises
Ça y est vous pouvez maintenant tester votre intégration.
Cet article de blog présente une approche moderne de la migration depuis Hadoop sans qu'il soit nécessaire de remanier complètement vos systèmes existants. En tirant parti de Kubernetes pour gérer Apache Spark et Apache Hive, et en intégrant MinIO pour le stockage d'objets avec état, les organisations peuvent obtenir une architecture équilibrée qui prend en charge une mise à l'échelle dynamique et une utilisation efficace des ressources. Cette configuration non seulement conserve mais améliore les capacités de vos environnements de traitement de données, les rendant plus robustes et évolutifs.
Avec MinIO, vous bénéficiez d'une solution de stockage qui offre des performances élevées sur le matériel standard, réduit les coûts grâce au codage d'effacement (éliminant la redondance de la réplication des données de Hadoop) et contourne les limitations telles que le verrouillage du fournisseur et le besoin de magasins de métadonnées basés sur Cassandra. Ces avantages sont cruciaux pour les organisations qui cherchent à tirer parti des charges de travail avancées d’IA/ML sans abandonner les éléments essentiels de leurs systèmes de données existants.
N'hésitez pas à nous contacter pour des discussions plus détaillées ou des conseils spécifiques sur la manière dont vous pouvez adapter cette stratégie de migration pour répondre aux besoins uniques de votre organisation. Que ce soit par email à [email protected] ou sur notre communauté