问题标签 [foundry-code-repositories]

Foundry 的 SQL 转换提供了至少 2 种编写逻辑代码的方法：Python 和纯文本 SQL。

我已经注意到一些不同之处：

• SQL 不允许增量计算，
• SQL 不允许使用变量、常量或分解函数，
• SQL 不允许向输出数据集添加参数，例如“列描述”。

我在某些方面错了，是否还有其他差异（例如执行时间、消耗的资源）？

我们编写了一个 pyspark 代码来创建我们需要的特定格式的报告。要求是在作业成功执行后使用报告链接发送电子邮件。我了解如何发送失败通知，但是否可以发送成功电子邮件。提前致谢！

我可以判断我的工作是否使用静态分配，但是我想实际改变我的工作以使用它。我该怎么做呢？

我有一个文件夹，我每个月都会上传一个文件。该文件将在每个月具有相同的格式。

第一个问题

这个想法是将这个文件夹中的所有文件连接到一个文件中。目前我正在硬编码文件名（文件名 [0]、文件名 [1]、文件名 [2]..），但想象一下我以后会有 50 个文件，我应该将它们显式添加到 transform_df 装饰器中吗？有没有其他方法来处理这个？

第二个问题：

目前，我假设有 4 个文件（2021_07、2021_08、2021_09、2021_10），每当我添加显示 2021_12 数据的文件时，我都希望避免更改代码。如果我添加input_5 = Input(path_to_2021_12_do_not_exists) 代码将不会运行并给出错误。

如果没有每月手动向我的代码添加一个新值，我如何为将来的文件实现代码并让代码忽略输入（如果它不存在）？

谢谢

我的工作似乎需要很长时间才能运行。我听说这可能是由于一种叫做“偏斜”的东西。

我怎么知道我是否受到此影响？

我知道这通常与连接、窗口和其他会导致洗牌的操作相关联，但我不知道如何识别它。

我调查了我的工作，并确定我确实有一个倾斜的任务。如何确定导致偏斜的此任务中的实际值是什么？

我的 Python 转换代码如下所示：

我有以下脚本返回正确排序的结果：

通知df = df.coalesce(1)前sort。

问题。由于两者都df.coalesce(1)应该df.repartition(1)导致一个分区，所以我尝试df = df.coalesce(1)用df = df.repartition(1). 但随后结果出现未排序。为什么？

额外细节

如果我不干扰分区，结果也显示为未排序：

物理计划使用coalesce(1)：

物理计划使用repartition(1)：

我知道repartition(1) 和 coalesce(1) 之间的问题，这个人说他由于某种原因不能使用coalesce(1)。就我而言，情况恰恰相反。

我的一个构建目前正在OOMing。为了更好地确定优化的下一步，我需要确定执行者或驱动程序是否OOMing。

确定执行程序或驱动程序是否在 Foundry 内 OOMing 的最佳方法是什么？

我的工作是接收一个巨大的数据集并将其与另一个数据集连接起来。第一次运行时，它花了很长时间，SparkFileScan parquet在读取数据集时执行了 a，但在未来的作业中，查询计划显示Scan ExistingRDD并且构建需要几分钟。

Spark 为什么以及如何能够扫描现有的 RDD？它会退回到扫描支持数据集的 parquet 文件（并因此恢复到更差的性能）吗？

我从我的工作概述页面中看到，我的工作似乎停留在某个阶段（大多数其他人都花费了合理的时间，其中一个要慢得多）。

当我的一个阶段需要这么长时间才能完成时，这意味着什么？