我正在建立一个Spark束。我在相同的示例上有hdfs数据节点和spark主节点。
当前设置为1-master（spark和hdfs）6-spark worker和hdfs数据节点
所有示例都是相同的，16gig双核（很不幸）。
我还有3台机器，同样的规格。现在我有三个选择1。只需在这3台机器上部署es。集群看起来像1-master（spark和hdfs）6-spark worker和hdfs数据节点3-elasticsearch节点
在1上部署es master，在所有其他服务器上扩展spark和hdfs以及es。集群看起来像1-master（spark和hdfs）1-master elasticsearch 8-spark worker、hdfs数据节点、es数据节点
我的应用程序是大量使用连接，ml等Spark，但我们正在寻找搜索功能。搜索我们绝对不需要实时和刷新间隔高达30分钟是我们甚至好。
同时，spark-cluster除了es索引外还有其他长期运行的任务。
解决方案不必是上述任何一个，如果有人建议，我对实验持开放态度。这将是方便其他开发人员也一旦结束。
我也在尝试es-hadoop，es-spark项目，但是我觉得如果我做3个专用节点的话，摄入会非常慢，大约60万条记录/分钟。
1条答案
按热度按时间uhry853o1#
这里的最佳方法主要取决于你的网络带宽，我认为这是否是你运营的瓶颈。
我只想检查一下我的网络连接是否饱和
iftop -i any或类似的，并检查是否是这样。如果您看到数据速率接近网络的物理容量，那么您可以尝试在运行es的相同计算机上运行hdfs+spark，以节省网络往返时间并加快速度。如果网络不是这里的瓶颈，我将研究下一步spark和hdfs的部署方式。您是否使用了所有可用的ram（JavaXMX设置得足够高？spark内存限制？Yarn内存限制（如果通过Yarn部署spark？）
此外，你应该检查是否es或Spark是这里的瓶颈，在所有可能的es。也许你可以产生额外的es示例，3个es节点喂养6个spark工人似乎是非常次优的。如果有什么不同的话，我可能会尝试反转这个比率，减少Spark执行器，增加es容量。es在提供数据方面可能比hdfs在写入数据方面慢得多（尽管这实际上取决于两者的配置。。。这只是一个有根据的猜测：））。很可能更多的es节点和更少的spark worker将是更好的方法。
简而言之：
添加更多es节点并减少spark worker计数
检查你的网络链接是否饱和，如果是这样，把两个在同一台机器上（这可能是有害的只有2个核心，但我还是给它一个机会。。。你得试试这个）
添加更多es节点是您可以做的两件事中最好的选择：）