问题标签 [catalyst-optimizer]

Youtube上有一个旧的（2014 年）演讲，演讲者在 Databricks 笔记本中可视化了一个查询计划。这是屏幕截图：

我正在使用 databricks 运行时 5.5 LTS ML，每当我尝试调用viz查询计划时，都会出现这种错误：

Spark 2.0+ 中是否已弃用此功能，或者我是否需要安装/导入其他库才能获得此功能？

我定义了一个UDF，它将输入值增加一，命名为“inc”，这是我的udf的代码

这是我的测试 sql

这是那个sql的优化方案

我想重写计划，并从“sum”中提取“inc”，就像 python udf 一样。所以，这是我想要的优化计划。

我发现源代码文件“ExtractPythonUDFs.scala”提供了与PythonUDF类似的功能，但它插入了一个名为“ArrowEvalPython”的新节点，这是pythonudf的逻辑计划。

我要插入的只是一个“项目节点”，我不想定义一个新节点。

这是我项目的测试代码

我ScalaUDF从Aggregate节点中提取，

因为ProjectNode 需要的参数是Seq[NamedExpression]

但它未能投射ScalaUDF到NamedExpression,

所以我不知道如何构建Project节点。

有人可以给我一些建议吗？

谢谢。

假设我有一个图 G 和以下查询：

其中{?a, ?b, ?c, ..., ?h}是变量，{x, y, z, w, q, r, s}是弧标签。

在存储级别，每个标签都有一个表格，但也有两个标签的组合。例如，我可能有一个带有列|a|b|的表x ，但我也有一个带有列|a|b|c|的表xy . 是的，我有多余的桌子。

基于此设置，我有两个问题：

a）我需要找到表，以便它们之间的连接导致最佳执行时间（最小）。让 {xy zw, q, rs} 成为上面示例的那些表。

b) 我必须按照给定的顺序执行连接，所以我需要找到那个顺序，例如：(rs ⨝ q) ⨝ (zw ⨝ xy)（⨝ 是自然连接）。

假设我知道要使用哪些表，即我已经解决了 a)，我的问题是如何处理第二个表。Spark API 允许我在一行中执行所有连接：

但我也可以分几行执行它：

res1.count 和 res2.count 的执行时间（几次运行的平均值）在我的实验中是不同的。树的构建方式似乎对执行有影响。

1) 我可以使用哪种策略来构建一棵树，从而在 Spark 中实现最佳执行时间？

2）如果每棵不同的树似乎会导致不同的性能，那么查询优化器的作用是什么？加入排序。它似乎什么也没做，尤其是在我将所有连接都放在一行代码中的情况下：

和

在一种情况下，我可以有一个合理的执行时间。在另一个超时。Catalyst 没有做任何事情吗？

我读过这个问题，其中 OP 试图转换这个逻辑计划：

对此：

我有一些问题：

1. 为什么他想要项目操作员？它有什么好处？
2. 据我所知，Project 是表示 SELECT 语句的运算符，那么计划怎么可能不包含 Project 运算符？

我正在尝试在 spark SQL 中调试一个返回不正确数据的简单查询。

在这种情况下，查询是两个 hive 表之间的简单连接。问题似乎与 spark 生成的物理计划（使用催化剂引擎）看起来已损坏的事实有关，其中物理计划中的某些步骤有未分配订单 ID，因此连接右侧的所有评估都未在 spark 查询中完成

这是示例查询

这是spark返回的物理计划示例

请注意，连接右侧的所有数据源扫描、过滤器交换和排序都没有分配订单 ID。

谁能帮我解释一下这个问题.. 为什么看起来正确的物理计划不会被分配评估订单 ID？

我正在阅读高性能 Spark，作者提出以下主张：

尽管 Catalyst 优化器非常强大，但它目前遇到的挑战之一是具有非常大的查询计划。这些查询计划往往是迭代算法的结果，如图形算法或机器学习算法。一个简单的解决方法是在每次迭代结束时将数据转换为 RDD 并返回 DataFrame/Dataset，如示例 3-58 所示。

示例 3-58 被标记为“Round trip through RDD to cut query plan”，复制如下：

有谁知道使这种解决方法成为必要的根本原因是什么？

作为参考，已为此问题提交了一份错误报告，可在以下链接中找到： https ://issues.apache.org/jira/browse/SPARK-13​​346

似乎没有修复，但维护者已经关闭了这个问题，并且似乎不相信他们需要解决它。

我正在阅读高性能 Spark，作者介绍了一种技术，该技术可用于对高度倾斜的数据执行连接，方法是有选择地过滤数据以使用包含最常用键的数据构建 HashMap。然后将此 HashMap 发送到所有分区以执行广播连接。结果数据在最后与联合操作连接起来。

提前致歉，但文中没有给出使用代码的这种技术的例子，所以我不能分享一个代码片段来说明它。

正文如下。

有时，并非所有较小的 RDD 都适合内存，但某些键在大型数据集中的表现如此之多，以至于您只想广播最常见的键。如果一个键太大以至于不能放在单个分区上，这将特别有用。在这种情况下，您可以在大型 RDD 上使用 countByKeyApprox 来大致了解哪些键最能从广播中受益。然后，您只为这些键过滤较小的 RDD，在 HashMap 中本地收集结果。使用 sc.broadcast，您可以广播 HashMap，以便每个工作人员只有一个副本并手动执行对 HashMap 的连接。然后，使用相同的 HashMap，您可以过滤大型 RDD 以不包含大量重复键并执行标准联接，将其与手动联接的结果结合起来。

对于那些不知道的人，广播连接是一种技术，用户可以通过将较小的数据块发送给每个执行程序来避免连接两个数据块时发生的洗牌。然后每个执行者自己执行连接。这个想法是，洗牌是如此昂贵，以至于让每个执行者执行连接然后丢弃它不需要的数据有时是最好的方法。

文本描述了可以使用广播连接提取和连接数据块的一部分的情况。然后将连接的结果与其余数据合并。

这可能是必要的原因是，通常可以通过确保由两个块中的相同键组成的数据都存在于同一个分区中来避免过度洗牌，以便同一个执行程序处理它。但是，在某些情况下，单个键太大而无法容纳在单个分区上。在这种情况下，作者建议将过度表示的键分离为 HashMap 并仅对过度表示的键执行广播连接可能是一个好主意。

这是一个好主意吗？而且，像这样的技术看起来非常有情景，所以 Catalyst 可能不会使用这种技术。那是对的吗？Catalyst 是否真的不使用这种技术？如果是这样，这是否意味着在高度倾斜的数据上，这种使用 RDD 的技术可以击败在 Dataframes 或 Datasets 上运行的 Catalyst？

可以导出数据帧/集的 Spark 逻辑或物理计划，将其序列化并将其保存在某处（作为文本、xml、json ...）。然后重新导入它，并基于它创建一个数据框？

这里的想法是，我有兴趣为 Spark 数据帧建立一个元存储，我可以在其中保存数据帧的逻辑或物理计划，以便其他人可以使用它们。

以 Dataframe API 格式而不是 Spark.sql 查询编写代码是否有任何显着优势？

想知道 Catalyst 优化器是否也可以处理 spark.sql 查询。

我不清楚 Catalyst 优化器和 Project Tungsten 的作用。

我的理解是 Catalyst 优化器将从逻辑计划生成优化的物理计划。然后代码生成器将采用优化的物理计划来发出 Rdd。

代码生成器是 Project Tungsten 或 Catalyst Optimizer 的一部分吗？代码生成器是否也称为“全阶段代码生成器”？