我仅对查询性能原因及其背后的体系结构差异感兴趣。我之前看到的所有答案都已过时或没有为我提供足够的WHY Impala上下文，这对于临时查询而言更好。
[仅从第二点以下的3个考虑因素解释了为什么Impala在更大的数据集上更快。 您能否对以下陈述作出贡献？
Impala不会浪费时间进行查询预初始化，这意味着impalad守护程序始终处于运行状态并准备就绪。另一方面，Spark Job Server provide persistent context出于相同的目的。
Impala处于内存中，当数据没有足够的RAM时，可能会在磁盘上泄漏数据，从而降低性能。 Spark也是如此。主要区别在于Spark是在Scala上编写的，并且具有JVM限制，因此不建议使用大于32 GB的工作器（因为是GC）。反过来，Impala在C ++上实现，并具有high hardware requirements：建议使用128-256 + GB的RAM。这非常重要，但仅在需要32-64 GB以上RAM的数据集上才应使Impala受益。
Impala与Hadoop基础架构集成。 AFAIK在其他内存DWH上使用Impala的主要原因是能够在Hadoop数据格式上运行而无需从Hadoop导出数据的能力。意味着Impala通常使用与Spark可以使用的相同的存储/数据/分区/存储，并且与Spark相比，数据结构不会带来任何额外的好处。我说的对吗？
P.S。 Impala在2019年比Spark快吗？您是否看到过任何性能基准？
首先，我认为比较通用的分布式计算框架和分布式DBMS（SQL引擎）没有太大的意义。但是，如果我们仍然想比较single-user模式（？！）下的单个查询执行，那么IMO的最大区别就是您已经提到的-Impala查询协调器拥有一切（表元数据来自Hive MetaStore + NameNode的块位置）缓存在内存中，而Spark需要时间提取此数据才能执行查询计划。
第二个大问题可能是洗牌实施，Spark在阶段边界将临时文件写入磁盘，以防Impala尝试将所有内容保留在内存中。导致完全不同的弹性-尽管Spark通过重新计算丢失的块并继续执行而从丢失执行程序的状态中恢复过来，但Impala在单个imapalad守护程序崩溃后将使整个查询失败。
在性能上没有明显的优势（因为与其他事物相比，通常花费的时间要少得多），但是在结构上很重要的是工作分配机制-在Spark中发送给工作人员的编译的整个阶段代码生成与在Impala中传递给守护程序的声明性查询片段。
就特定的查询优化技术（查询矢量化，动态分区修剪，基于成本的优化）而言，它们可能会在今天或不久的将来达到同等水平。