Impala 与临时查询的 Spark 性能对比
Impala vs Spark performance for ad hoc queries
我只对查询性能原因及其背后的架构差异感兴趣。我之前看到的所有答案都已过时或没有为我提供足够的上下文，说明为什么 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 基础架构集成。据我所知，在另一个内存 DWH 上使用 Impala 的主要原因是能够在 Hadoop 数据格式上 运行 而无需从 Hadoop 导出数据。意味着 Impala 通常使用与 Spark 相同的 storage/data/partitioning/bucketing，并且与 Spark 相比，不会从数据结构中获得任何额外的好处。我说的对吗？
P.S。 Impala 在 2019 年比 Spark 快吗？您看过任何性能基准吗？
更新：
问题更新：
我。 为什么 Impala 推荐 128+ GB RAM？每个 Impala 组件的实现语言是什么？ 文档说 "Impala daemons run on every node in the cluster, and each daemon is capable of acting as the query planner, the query coordinator, and a query execution engine."。如果 impalad 是 Java，那么哪些部分是用 C++ 编写的？ impalad 和柱状数据之间有什么关系吗？ impalad 或某些其他组件是否需要 256 GB RAM？
二． Impala 在集群洗牌 (JOIN) 方面失去了所有内存中的性能优势，对吧？与 Spark 相比，Impala 是否有任何机制可以提高 JOIN 性能？
三。 Impala 使用多级服务树（类似于 Dremel 引擎，参见 "Execution model" here）与 Spark 的有向无环图。 就临时查询性能而言，MLST 与 DAG 究竟意味着什么？或者它更适合多用户环境？
首先，我认为比较通用分布式计算框架和分布式 DBMS（SQL 引擎）没有多大意义。但是，如果我们仍然想比较 单用户 模式下的单个查询执行（？！），那么 IMO 最大的区别就是您已经提到的 - Impala 查询协调器将所有内容（table 来自 Hive MetaStore 的元数据 + 来自 NameNode 的块位置）缓存在内存中，而 Spark 将需要时间来提取此数据以执行查询计划。
第二个大问题可能是 shuffle 实现，Spark 在阶段边界将临时文件写入磁盘，而不是 Impala 试图将所有内容保存在内存中。导致弹性的根本差异 - 虽然 Spark 可以从丢失执行程序中恢复并通过重新计算丢失的块继续前进，但 Impala 将在单个 impalad 守护程序崩溃后使整个查询失败.
在性能方面不太重要（因为与其他所有事情相比，它通常花费的时间要少得多）但在体系结构上重要的是工作分配机制——编译后的整个阶段代码生成发送给 Spark 中的工作人员，而不是声明性查询片段传递给守护进程在 Impala.
就具体的查询优化技术（查询向量化、动态分区修剪、基于成本的优化）而言——它们可能在今天或在不久的将来达到同等水平。
我只对查询性能原因及其背后的架构差异感兴趣。我之前看到的所有答案都已过时或没有为我提供足够的上下文，说明为什么 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 基础架构集成。据我所知，在另一个内存 DWH 上使用 Impala 的主要原因是能够在 Hadoop 数据格式上 运行 而无需从 Hadoop 导出数据。意味着 Impala 通常使用与 Spark 相同的 storage/data/partitioning/bucketing，并且与 Spark 相比，不会从数据结构中获得任何额外的好处。我说的对吗？
P.S。 Impala 在 2019 年比 Spark 快吗？您看过任何性能基准吗？
更新：
问题更新：
我。 为什么 Impala 推荐 128+ GB RAM？每个 Impala 组件的实现语言是什么？ 文档说 "Impala daemons run on every node in the cluster, and each daemon is capable of acting as the query planner, the query coordinator, and a query execution engine."。如果 impalad 是 Java，那么哪些部分是用 C++ 编写的？ impalad 和柱状数据之间有什么关系吗？ impalad 或某些其他组件是否需要 256 GB RAM？
二． Impala 在集群洗牌 (JOIN) 方面失去了所有内存中的性能优势，对吧？与 Spark 相比，Impala 是否有任何机制可以提高 JOIN 性能？
三。 Impala 使用多级服务树（类似于 Dremel 引擎，参见 "Execution model" here）与 Spark 的有向无环图。 就临时查询性能而言，MLST 与 DAG 究竟意味着什么？或者它更适合多用户环境？
首先，我认为比较通用分布式计算框架和分布式 DBMS（SQL 引擎）没有多大意义。但是，如果我们仍然想比较 单用户 模式下的单个查询执行（？！），那么 IMO 最大的区别就是您已经提到的 - Impala 查询协调器将所有内容（table 来自 Hive MetaStore 的元数据 + 来自 NameNode 的块位置）缓存在内存中，而 Spark 将需要时间来提取此数据以执行查询计划。
第二个大问题可能是 shuffle 实现，Spark 在阶段边界将临时文件写入磁盘，而不是 Impala 试图将所有内容保存在内存中。导致弹性的根本差异 - 虽然 Spark 可以从丢失执行程序中恢复并通过重新计算丢失的块继续前进，但 Impala 将在单个 impalad 守护程序崩溃后使整个查询失败.
在性能方面不太重要（因为与其他所有事情相比，它通常花费的时间要少得多）但在体系结构上重要的是工作分配机制——编译后的整个阶段代码生成发送给 Spark 中的工作人员，而不是声明性查询片段传递给守护进程在 Impala.
就具体的查询优化技术（查询向量化、动态分区修剪、基于成本的优化）而言——它们可能在今天或在不久的将来达到同等水平。