apache-spark - 临时查询的Impala vs Spark性能

Question

我只对查询性能原因及其背后的体系结构差异感兴趣。我以前见过的所有答案都已过时或没有为我提供足够的WHY Impala上下文，这对于临时查询更好。

从下面的3个考虑因素中，只有第二点可以解释为什么Impala在较大的数据集上速度更快。您能否对以下陈述做出贡献？

Impala不会浪费时间进行查询预初始化，这意味着impalad守护程序始终在运行并准备就绪。另一方面，Spark Job Server provide persistent context出于相同的目的。

Impala处于内存中，当数据没有足够的RAM时，可能会在磁盘上泄漏数据，从而降低性能。 Spark也是如此。主要区别在于Spark是在Scala上编写的，并且具有JVM限制，因此不建议使用大于32 GB的工作器(由于GC)。反过来， [错误，请参见UPD] Impala在C++上实现，并具有high hardware requirements:建议使用128-256 + GB的RAM。这非常重要，但是仅在需要32-64 + GB RAM的数据集上才使Impala受益。

Impala已与Hadoop基础架构集成。 AFAIK在其他内存DWH上使用Impala的主要原因是能够在Hadoop数据格式上运行而无需从Hadoop导出数据的能力。意味着Impala通常使用与Spark可以使用的相同的存储/数据/分区/存储，并且与Spark相比，数据结构不会带来任何额外的好处。我对吗？

附言Impala在2019年比Spark快吗？您是否看到任何性能基准？

UPD:

问题更新:

I.为什么Impala建议使用128+ GB以上的RAM？每个Impala组件的实现语言是什么？文档说:“Impala守护程序在集群中的每个节点上运行，并且每个守护程序都能够充当查询计划程序，查询协调器和查询执行引擎。”如果 impalad是Java，那么用C++编写什么部分？穿刺数据和柱状数据之间是否存在污点？ impalad或其他组件是否需要256 GB RAM？

二。当涉及集群改组(JOIN)时，Impala释放了所有内存性能优势，对吗？与Spark相比，Impala是否有任何机制可以提高JOIN性能？

三， Impala使用多级服务树(类似于Dremel Engine，请参见“执行模型” here)对比Spark的有向无环图。就临时查询性能而言，MLST vs DAG实际上意味着什么？还是更适合多用户环境？

Answer 1

首先，我认为通用分布式计算框架与分布式DBMS(SQL引擎)的比较没有太大意义。但是，如果我们仍然想比较单用户模式下的单个查询执行(？!)，那么IMO的最大区别就是您已经提到的-Impala查询协调器拥有一切(Hive MetaStore中的表元数据+块来自NameNode的位置)缓存在内存中，而Spark需要一些时间来提取此数据才能执行查询计划。

第二个大问题可能是洗牌实现，Spark在阶段边界将临时文件写入磁盘，以防Impala尝试将所有内容保留在内存中。导致 flex 上的根本差异-虽然Spark可以从丢失执行程序中恢复并通过重新计算丢失的块继续运行，但Impala在单个impalad守护程序崩溃后将使整个查询失败。

在性能上不太重要(因为与其他方法相比，通常花费的时间要少得多)，但在工作上重要的是工作分配机制，即在Spark中发送给工作人员的已编译的整个阶段代码生成与在Impala中传递给守护程序的声明性查询片段。

就特定的查询优化技术(查询矢量化，动态分区修剪，基于成本的优化)而言，它们可能会在今天或不久的将来达到同等水平。