我只对查询性能原因及其背后的体系结构差异感兴趣。我以前看到的所有答案都过时了，或者没有为我提供足够的背景来说明为什么 Impala 更适合于特殊查询。
从下面的三点考虑，只有第二点解释了为什么 Impala 在更大的数据集上更快。你能为以下陈述做些贡献吗？
impala不会错过查询预初始化的时间，这意味着impalad守护进程总是在运行并准备就绪。另一方面，spark作业服务器为相同的目的提供持久上下文。
impala在内存中，当数据没有足够的ram时，它会将数据溢出到磁盘上，性能会受到影响。spark也是如此。主要区别在于spark是在scala上编写的，并且有jvm限制，因此不建议使用大于32gb的worker（因为gc）。反过来，[错了，请参阅upd]impala是在c++上实现的，并且具有很高的硬件要求：建议使用128-256+gbs的ram。这是非常重要的，但是应该只对需要32-64+gbs内存的数据集有益。
impala与hadoop基础设施集成。afaik在另一个内存dwhs上使用impala的主要原因是能够在hadoop数据格式上运行，而无需从hadoop导出数据。意味着impala通常使用与spark相同的存储/数据/分区/bucketing，与spark相比，不会从数据结构中获得任何额外的好处。我说得对吗？
p、 2019年 Impala 比星火还要快吗？你有没有看到任何绩效基准？

升级版本：

问题更新：
一。为什么impala推荐128+gbs内存？每个 Impala 组件的实现语言是什么？文档中说“impala守护进程运行在集群中的每个节点上，每个守护进程都可以充当查询计划器、查询协调器和查询执行引擎。”。如果 impalad 是java，而不是用c++写的什么部分？impalad和columnar数据之间是否有关联？impalad或其他组件是否需要256 GB ram？
二。当涉及到集群洗牌（连接）时，impala释放了所有内存中的性能优势，对吗？与spark相比， Impala 有什么机制来提高连接性能吗？
iii.impala使用多级服务树（类似于smth的dremel引擎，请参阅此处的“执行模型”）与spark的有向无环图。就即席查询性能而言，mlst和dag究竟意味着什么？还是更适合多用户环境？