当我想到下面的问题时，我试图找出答案，但却找不到答案。
它包括Spark， Impala ，先生，Hive多租户。 Impala 的场景。我觉得它可以应用于Spark也因为 Impala /Spark都是内存占用。
场景1假设我们为mr、hive和impala创建一个10节点集群，其中40%的资源静态分配给impala。为了运行impala，我们在集群中创建了256gbram数据节点。
问题是，在这种配置中，我们失去了低成本低gb的优势，即32-40 gb ram，具有5-6个核心节点，这是mr/hadoop的主要卖点之一，可以在处理100TB数据时以很少的成本进行扩展。
场景2：创建一个混合了256gbram和32-40gbram节点的集群
问题是在这种情况下，impala将不会运行，因为我们无法按照我的理解指导在特定数据节点中创建配置单元表，在这些节点中我们正在集群中运行impala守护程序。
场景3：创建单独的集群，即没有多租户。在这种情况下，我们需要将数据从Hive复制到 Impala 集群。
问题是，这将成为另一个增量流程/etl层。
与上面的场景类似，我觉得它适用于spark，因为spark也需要大内存才能运行。
我们可以说创建一个mr、hive、hbase、流式多租户集群&一个独立的impala、spark多租户集群吗？
1条答案
按热度按时间uurity8g1#
以下是我根据上述评论收集的答案。
我用基于配置单元的表（使用混合hdfs+s3）以及spark和impala创建了一个多租户集群。虽然我已经几个月没有这些规范了，但我发现impala通常在上百亿条记录（几十tb/数百tb未压缩）上都有16gb的性能，每个记录大约70列宽，同时处理一个或两个parquet格式的查询（每个gz压缩文件约1gb）。这些查询是聚合，再加上与同样采用Parquet格式的较小事实表的联接。连接通常涉及一个查询中的许多其他表，从数亿条记录到几十条记录表，通常一次访问大约10-20列，一次使用大约50亿条记录。spark在使用Yarn方面也做得很好，而且记忆也不是什么大问题。数据/任务节点是17个ec2 i3.2xlarge，因为它们有很好的性能和价值（nvmes，价格优惠）。
我在评论中没有提到的一点是，您可以超额订阅内存，这样就可以通过充分利用集群的资源来最大限度地提高每个工具的性能。在这里自然要注意的是，如果你真的试图一次使用所有这些资源，超额预订意味着更高的问题风险（参见：航空公司超额预订）。