即席查询的 Impala 与 Spark 性能

Question

我只对查询性能原因及其背后的架构差异感兴趣。我之前看到的所有答案都已过时，或者没有为我提供足够的背景信息来说明为什么 Impala 更适合即席查询。

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

1. Impala 不会错过查询预初始化的时间，这意味着 impalad 守护进程始终运行并准备就绪。另一方面， Spark Job Server出于相同目的提供持久上下文。

2. Impala 位于内存中，当数据没有足够的 RAM 时，可能会将数据溢出到磁盘上，从而导致性能下降。Spark 也是如此。主要区别在于 Spark 是在 Scala 上编写的并且有 JVM 限制，因此不建议使用大于 32 GB 的工作线程（因为 GC）。反过来，[错误，请参阅 UPD] Impala 是在 C++ 上实现的，并且对硬件要求很高：建议使用 128-256+ GB 的 RAM。这非常重要，但 Impala 仅适用于需要 32-64 GB 以上 RAM 的数据集。

3. Impala 与 Hadoop 基础设施集成。据我所知，使用 Impala 而不是其他内存 DWH 的主要原因是能够运行 Hadoop 数据格式，而无需从 Hadoop 导出数据。意味着 Impala 通常使用与 Spark 相同的存储/数据/分区/存储桶，并且与 Spark 相比，并没有从数据结构中获得任何额外的好处。我对吗？

PS 2019 年 Impala 比 Spark 更快吗？您见过任何性能基准吗？

更新：

问题更新：

一、为什么 Impala 推荐 128+ GB RAM？Impala 的每个组件的实现语言是什么？文档称“Impala 守护进程在集群中的每个节点上运行，每个守护进程都能够充当查询规划器、查询协调器和查询执行引擎”。如果impalad是Java，那么哪些部分是用C++编写的？impalad 和柱状数据之间有什么关系吗？impalad 或其他组件是否需要 256 GB RAM？

二. 当涉及到集群洗牌（JOIN）时，Impala 失去了所有内存中的性能优势，对吧？与 Spark 相比，Impala 是否有任何机制可以提高 JOIN 性能？

三．Impala 使用多级服务树（类似于 Dremel Engine，请参阅此处的“执行模型” ）与 Spark 的有向非循环图。就即席查询性能而言，MLST 与 DAG 实际上意味着什么？或者它更适合多用户环境？

Answer 1

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

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

性能方面不太重要（因为与其他所有事情相比，它通常花费的时间要少得多），但架构上重要的是工作分配机制 - 编译后的整个阶段代码生成发送给 Spark 中的工作人员，而不是与 Impala 中的守护进程通信的声明式查询片段。

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