Get best of the week

10 idées fausses sur le portage de Hadoop dans le cloud


De nombreuses entreprises et sociétés souhaitent utiliser le cloud pour traiter des données pour des raisons évidentes: flexibilité, évolutivité, vous ne pouvez payer que ce que vous utilisez, etc.

En effet, le transfert d'un projet avec un système de traitement de données à plusieurs composants, à l'échelle du pétaoctet, de l'environnement local vers le cloud est un solide «mais». Il existe de nombreux produits pour la migration: Hadoop , Hive , Yarn , Spark , Kafka , Zookeeper , Jupyter , Zeppelin . Étant donné la différence fondamentale de l'environnement, il est facile de se perdre et de commettre des erreurs dans cette variété.

Dans cet article, je vais parler des idées fausses courantes et donner quelques conseils sur la migration de qualité vers le cloud. Personnellement, j'utilise AWS , mais toutes les astuces sont pertinentes pour d'autres fournisseurs avec des solutions similaires, par exemple, pour Azure ou GCP .

1. La copie de données dans le cloud est facile


Transférer plusieurs pétaoctets de données vers le cloud public (par exemple, S3 ), qui dans notre cas fonctionnera comme un lac de données, n'est pas une tâche facile. Cela peut prendre beaucoup de temps et consommer beaucoup de ressources.

Malgré le grand nombre de solutions, commerciales et open source, je n'en ai pas trouvé une seule qui couvrirait tous les besoins:

  • transmission
  • intégration de données
  • verification des données
  • rapports

Si une certaine partie des données est principalement statique ou modérément dynamique, vous pouvez utiliser une solution comme AWS Snowball , qui vous permet de copier des tableaux sur un appareil physique. Les données seront téléchargées à partir de votre réseau local, après quoi le disque sera renvoyé au centre de données AWS et les données seront versées dans le stockage S3 .

Texte masqué
, , AWS.

Il est recommandé de diviser le transfert de données en deux phases. Une fois que la plupart des baies ont été envoyées et téléchargées dans le référentiel, utilisez une connexion directe depuis le fournisseur de cloud pour décharger le reste. Vous pouvez utiliser les méthodes Hadoop DistCP ou Kafka Mirroring pour cela . Les deux méthodes ont leurs propres nuances. DistCP nécessite une planification constante et un réglage approfondi.En outre, tous les objets ne peuvent pas être placés dans des listes noires et blanches. Kafka MirrorMaker , en plus d'un réglage approfondi, doit exporter des métriques via l'extension de gestion JMX pour mesurer le débit, la latence et la stabilité globale.

Texte masqué
. — , .

2. Le cloud fonctionne comme le stockage local


Le stockage local et le stockage cloud ne sont pas la même chose. Un bon exemple est Zookeeper et Kafka . La bibliothèque cliente ZK met en cache les adresses autorisées des serveurs ZK pendant toute la durée de vie: c'est un gros problème de déploiement dans le cloud, qui nécessitera des béquilles - les interfaces réseau ENI statiques pour les serveurs ZK .

Pour la surveillance des performances, il est judicieux d'exécuter une série de tests NFT non fonctionnels dans l'infrastructure cloud pour vous assurer que les paramètres et la configuration s'adapteront à vos charges de travail.

Texte masqué
, , .

3. Le stockage d'objets remplace à 100% HDFS


La séparation des couches de stockage et de calcul est une excellente idée, mais il y a une mise en garde.

À l'exception de Google Cloud the Storage , qui utilise une forte cohérence des données (forte cohérence) , la plupart des autres installations de stockage fonctionnent sur le modèle de la «cohérence à terme» (éventuellement cohérente) . Cela signifie qu'ils peuvent être utilisés pour saisir des données brutes et traitées et pour générer des résultats, mais pas comme stockage temporaire.

Texte masqué
, HDFS.

4. Vous pouvez déployer une infrastructure cloud à partir de l'interface utilisateur


Pour un petit environnement de test, cela peut être facile, mais plus les besoins en infrastructure sont élevés, plus il est probable d'écrire du code. Vous voudrez peut-être avoir plusieurs environnements (Dev, QA, Prod) . Cela peut être implémenté en utilisant CloudFormation et Terraform , mais la copie des morceaux de code nécessaires échouera, vous devrez refaire beaucoup pour vous-même.

Texte masqué
— CI/CD . , .

5. Pour une visibilité correcte dans le cloud, il vous suffit d'utiliser $ {SaaS_name}


Une bonne visibilité (journalisation et surveillance) de l'ancien et du nouvel environnement est une condition critique pour une migration réussie.

Cela peut être difficile en raison de l'utilisation de différents systèmes dans les environnements. Par exemple, Prometheus et ELK pour l'environnement local, et NewRelic et Sumologic pour le cloud. Même si une solution SaaS est appliquée dans les deux environnements, elle est difficile à mettre à l'échelle.

Texte masqué
, ( , , JMX, , ).

6. Le nuage évolue à l'infini


Les utilisateurs se réjouissent souvent lorsqu'ils sont enfants lorsqu'ils apprennent la fonction de mise à l'échelle automatique et pensent qu'ils l'appliqueront immédiatement sur leurs plateformes de traitement des données. Il est vraiment facile à configurer pour les nœuds EMR sans HDFS , mais cela nécessitera des connaissances supplémentaires pour le stockage persistant (par exemple, le courtier logiciel Kafka ). Avant de transférer tout le trafic vers l'infrastructure cloud, vous devez vérifier les limites de ressources actuelles: le nombre d'instances de classe, de disques, vous devez également préchauffer les équilibreurs de charge. Sans une telle formation, le potentiel de travail ne peut pas être utilisé comme il se doit.

Texte masqué
, — , — .

7. Je déplace simplement mon infrastructure sans changement


En effet, au lieu de se concentrer uniquement sur les capacités d'un fournisseur de services potentiel, il est préférable de se concentrer sur vos propres référentiels, par exemple DynamoDB . Mais n'oubliez pas les services compatibles avec l'API. Vous pouvez également utiliser le service cloud Amazon RDS pour la base de données Hive Metastore .

Un autre bon exemple est la plate-forme Big Data EMR optimisée pour le cloud . À première vue, simple, il nécessite un réglage fin à l'aide de scripts de post-installation. Vous pouvez personnaliser la taille du segment de mémoire , les archives tierces JAR , UDFmodules complémentaires de sécurité. Notez également qu'il n'y a toujours aucun moyen de fournir une haute disponibilité (HA) pour les nœuds NameNode ou YARN ResourceManager principaux .

Texte masqué
, , .

8. Transférez les tâches Hadoop / Spark vers le cloud - c'est facile


Pas vraiment. Pour réussir le transfert des tâches, vous devez avoir une idée claire de votre logique métier et de vos pipelines: de la réception initiale des données brutes aux baies de haute qualité. Tout devient encore plus compliqué lorsque les résultats des pipelines X et Y sont les données d'entrée du pipeline Z. Tous les composants des flux et des relations doivent être affichés aussi clairement que possible. Cela peut être implémenté à l'aide de DAG .

Texte masqué
SLA.

9. Le cloud réduira les coûts d'exploitation et le budget du personnel


Le propre équipement nécessite des coûts physiques et des salaires pour les employés. Après le passage au cloud, tous les coûts ne disparaîtront pas: vous devez toujours répondre aux besoins de l'entreprise et embaucher des personnes qui seront impliquées dans le développement, le support, le dépannage, la planification budgétaire. Vous devrez également investir dans des logiciels et des outils pour la nouvelle infrastructure.

Le personnel doit être une personne qui comprend le fonctionnement des nouvelles technologies. Cela implique un employé hautement qualifié. Par conséquent, même en tenant compte de la réduction du personnel, vous pouvez dépenser autant, sinon plus, sur le salaire d'un bon spécialiste.

Texte masqué
— (, EMR), . , , .

10. No-Ops close ...


No-Ops est le rêve de toute entreprise. Un environnement entièrement automatisé sans besoin de services et de produits de tiers. C'est possible?

Une équipe modeste de plusieurs personnes n'est pertinente que pour les petites entreprises dont les activités ne sont pas directement liées aux données. Tout le monde aura besoin d'au moins un spécialiste qui intègre et emballe tous les systèmes, les compare, automatise, offre une visibilité et élimine tous les bugs qui surviennent en cours de route.

Texte masqué
Data-Ops , .


Résumer. Le transfert de pipelines de traitement de données vers le cloud est une bonne chose. Pour que la migration fonctionne comme il se doit, vous devez planifier soigneusement le processus, en tenant compte de tous les pièges décrits ci-dessus. Réfléchissez à quelques pas et tout ira bien.

More articles:


All Articles