Acquisition de données dans elasticsearch à partir de hdfs, de la configuration du cluster et de l'utilisation

Question

Je suis en train de configurer un cluster spark. J'ai des nœuds de données hdfs et des nœuds spark master sur les mêmes instances.

configuration actuelle est 1-maître (allumage et HDFS) travailleurs 6 bougies et données de HDFS noeuds

Toutes les instances sont identiques, dual core 16Gig (malheureusement).

J'ai encore 3 machines, toujours les mêmes spécifications. Maintenant, j'ai trois options 1. Il suffit de déployer es sur ces 3 machines. Le cluster ressemblera 1-maître (allumage et HDFS) travailleurs 6 bougies et HDFS nœuds de données noeuds 3 ElasticSearch

2. Déployer le maître sur 1, étendre étincelle et hdfs et es sur tous les autres. Cluster ressemblera 1-maître (allumage et HDFS) 1-maître ElasticSearch travailleurs 8 bougies, HDFS nœuds de données, es noeuds de données

Mon application est d'utiliser beaucoup étincelle pour les jointures, ml, etc, mais nous recherchons des capacités de recherche. Nous n'avons certainement pas besoin de temps réel de recherche et un intervalle de rafraîchissement de 30 minutes est même bien avec nous.

En même temps, le cluster d'amorçage a d'autres tâches de longue durée en dehors de l'indexation.

La solution ne doit pas nécessairement être l'une des précédentes, je suis ouverte à l'expérimentation si quelqu'un le suggère. Ce serait pratique pour d'autres développeurs aussi une fois conclu.

Aussi j'essaye avec es hadoop, projet d'es-étincelle mais j'ai senti l'ingestion est très lente si je fais 3 noeuds dédiés, c'est comme 0,6 million d'enregistrements/minute.

Answer 1

L'approche optimale ici dépend principalement de la bande passante de votre réseau et du fait que c'est ou non le goulot d'étranglement dans votre exploitation selon moi.

Je voudrais juste vérifier si mes liens de réseau sont saturés via dis iftop -i any ou similaire et vérifiez si c'est le cas. Si vous constatez que les débits de données sont proches de la capacité physique de votre réseau, vous pouvez essayer d'exécuter hdfs + spark sur les mêmes ordinateurs qu'ES pour économiser le réseau et accélérer les choses.

Si le réseau s'avère ne pas être le goulot d'étranglement ici, je voudrais regarder dans la façon dont Spark et HDFS sont déployés ensuite. Utilisez-vous toute la RAM disponible (Java Xmx réglé suffisamment haut ?, Limites de mémoire Spark? Limites de mémoire de fil si Spark est déployé via Yarn?)

Vous devriez également vérifier si ES ou Spark est le goulot d'étranglement ici, dans tous probabilité c'est ES. Peut-être que vous pourriez générer des instances ES supplémentaires, 3 nœuds ES alimentant 6 travailleurs spark semble très sous-optimale. Si quoi que ce soit, je vais probablement essayer d'inverser ce ratio, moins d'exécuteurs Spark et plus de capacité ES. ES est probablement beaucoup plus lent à fournir les données que HDFS est à l'écriture (bien que cela dépend vraiment de la configuration des deux ... juste une supposition éclairée ici :)). Il est très probable que plus de nœuds ES et moins de travailleurs Spark seront la meilleure approche ici.

Donc, en résumé:

• Ajouter plusieurs noeuds ES et réduire le nombre des travailleurs Spark
• Vérifiez si vos liens de réseau sont saturés, le cas échéant mis à la fois sur les mêmes machines (cela pourrait être préjudiciable seulement 2 noyaux, mais je donne toujours un coup de feu ... tu dois essayer cela)
• Ajout de nœuds plus ES est le meilleur pari des deux choses que vous pouvez faire :)