当我想到以下情况时，我试图找出答案但却无法找到答案。
它涵盖了Spark，Impala，MR，Hive Multi租赁。 Impala给出的场景。我觉得它也适用于Spark，因为Impala / Spark都是内存占用。
场景1 假设我们为MR，Hive和Impala创建了一个具有多租户的10节点集群，其中40％的资源静态分配给Impala。为了运行impala，我们创建了具有256 GB RAM数据节点的集群。
问题这种配置我们正在失去低成本低GB的好处，即具有5-6核心节点的32-40 GB RAM，这是MR /的主要卖点之一Hadoop用于在以成本的一小部分处理100TB数据时进行缩放。
场景2 ：创建一个混合了256GB RAM和32-40 GB RAM节点的集群
问题在这种情况下，Impala将无法运行，因为根据我的理解，无法在我们正在运行群集中的Impala守护程序的特定数据节点中创建Hive表。
场景3 ：创建单独的群集，即无多租户。在这种情况下，我们需要将数据从Hive复制到Impala集群。
问题这将成为另一个增量进程/ ETL层。
与上述情况类似，我觉得它适用于spark ，因为SPARK也需要大量内存才能运行。
我们可以说创建一个MR，HIVE，HBASE，Streaming Multi tenant cluster＆amp;一个单独的Impala，Spark Multi租户群？
答案 0 :(得分：0)
根据我上面的评论集，这是我的答案。
我创建了一个多租户群集，其中包含基于配置单元的表（使用混合HDFS + S3）以及spark和impala。虽然我已经有几个月没有在我面前的规格了，但我发现impala通常表现不错，我相信它在数百亿条记录（数十/数百TB未压缩）上是16GB，每条约70列宽，以拼花格式同时处理一个或两个查询（每个gz压缩文件约1GB）。查询是聚合加上与较小的事实表的连接，这些事实表也是镶木地板格式。连接通常涉及一个查询中的许多其他表，范围从数亿条记录到数十条记录表，通常一次访问大约10-20列，一次使用大约一半数十亿条记录。 Spark也使用YARN做得非常好，内存不是一个大问题。数据/任务节点为17 EC2 i3.2xlarge，因为它们具有出色的性能和价值（重新NVM，价格昂贵）。
我在评论中没有提到的一个注意事项是，可能能够超额预订内存，以便通过充分利用群集资源来最大限度地提高每个工具的性能。如果/当您实际尝试一次性使用所有这些资源时，超额订购意味着更高的问题风险（参见：航空公司超额预订）。