Documentation
搜索文档
karat

+

K

API 参考 ↗
分析代码工作簿代码工作簿常见问题解答

注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。

代码工作簿常见问题解答

以下是一些关于代码工作簿的常见问题。

有关一般信息，请查看我们的代码工作簿文档。

我可以轻松地将我所有的工作从一个工作簿移动到另一个工作簿吗？

可以。您可以在工作簿之间复制粘贴节点（工作簿图上的元素）。

  1. 按住Ctrl键，同时选择您要从一个工作簿中复制的节点。不支持复制粘贴Contour面板节点。
  2. 使用右键菜单复制所选节点。
  3. 选择目标工作簿的图形，并使用Cmd+V（macOS）或Ctrl+V（Windows）组合键粘贴节点。新节点将被导入到您的新工作簿中。

返回顶部

我可以将一个变换节点设置为变量吗？

不可以。代码工作簿图上的每个变换节点必须返回一个表格或数据框（例如具有列的二维数据结构）。

返回顶部

为什么每个变换节点都需要返回一个表格或数据框？

Foundry中的工件的原子单位是数据集。每个变换节点需要返回一个表格或数据框（例如具有列的二维数据结构），以便每个节点可以注册为Foundry数据集，从而在Foundry的其余部分中可用。此外，代码工作簿中的表格或数据框必须以有效的模式返回，以便它们能够生成数据集（例如，至少存在一列，列名称不重复，列名称不包含无效字母，等等）。

返回顶部

代码工作簿可以处理合并和合并冲突吗？

可以。有关更多信息，请查看有关分支和合并的文档。

返回顶部

初始化我的环境需要多长时间？

代码工作簿的默认配置平均初始化时间为3-5分钟。但是，如果您向代码工作簿配置文件中添加了其他包，初始化时间可能会在20-30分钟之间，具体取决于这些包的复杂性和相互依赖性。随着环境中包的数量增加，初始化时间往往会显著增加。

初始化缓慢通常表明环境定义过大或过于复杂。初始化时间随着环境中包的数量以超线性方式增加，因此您可能需要简化任何自定义环境。在某些情况下，代码工作簿可能会预先初始化常用环境以加快初始化速度。如果您基于默认配置文件创建了自定义环境，较慢的初始化时间可能是由于缺乏预初始化造成的。了解更多关于优化自定义环境初始化时间的信息。

如果浏览器标签页超过30分钟未激活，环境可能会因不活动而丢失。

返回顶部

如何恢复我之前从代码工作簿中删除的代码？

如果这些变换被构建到数据集中，您可以使用结果数据集预览的比较功能查看当时的代码。从那里您可以复制粘贴相关的变换。不幸的是，如果这段代码位于中间变换中，则无法恢复。

代码工作簿是一个比代码库更具迭代性的平台，后者具有完整的git提交和发布功能。如果您有其他可用的分支，我们建议检查它们是否有被删除的变换。

返回顶部

Spark环境和自定义库

找不到所需的Python库

默认情况下，Conda Forge ↗中可用的任何Python包都可以添加到您的工作簿自定义环境中。如果Python库包含在Conda Forge中，您可以自定义您的环境以直接包含它。

要进行故障排除，请执行以下步骤：

  1. 在右上角选择环境 > 自定义环境。
  2. 搜索所需的库，并添加自动（这将进行升级，但如果模块升级，可能会使您容易受到意外故障的影响）或该库的特定版本。
  3. 选择更新Spark环境。

请注意，环境重新加载可能需要一些时间，使用自定义环境通常会比使用标准环境慢，因为标准环境池保持“预热”，而每个自定义环境都是从头开始创建的。

返回顶部

导入Python库时遇到问题

有时可能需要使用代码工作簿中尚不可用的库。可以将这些库添加到您的可用列表中，但这需要一些动手工作。

要进行故障排除，请执行以下步骤：

  1. 确认Python库在工作簿自定义Spark环境列表中不可用。
  2. 如果不存在，检查是否有其他可用库可能提供相同的功能。
  3. 如果必须包含此库，请联系Palantir客服支持。
  4. 库可用后，您可以参考之前的故障排除步骤来添加库。

返回顶部

创建环境失败

我正在尝试更新我的工作簿环境，它显示“等待Spark / 初始化环境”一段时间，然后出错，显示“创建环境失败”消息。

要进行故障排除，请执行以下步骤：

  1. 确认工作簿的Spark环境是否有任何自定义更新。如果有，那么您的调查应该集中在添加的任何自定义库上。
  2. 确保没有模块固定到特定版本。通常，使用模块的最新版本是一个好习惯。
  3. 删除任何自定义库，看看Spark环境是否加载。
  4. 如果某个特定库阻止您的Spark环境加载，请将问题提升到Palantir客服支持。

返回顶部

Python代码出错

本节讨论通常特定于代码工作簿的出错。

有关更多信息，您还可以参考我们关于搭建和检查出错的指南。

返回顶部

重试器错误

运行导入包或任何基本命令返回以下错误：“com.github.rholder.retry.RetryException: 重试在3次尝试后未能成功完成。 在com.github.rholder.retry.Retryer.call(Retryer.java:174)”。在Pandas中使用工作簿时，代码工作簿应用程序将在您的变换之前仍然从Spark数据框转换为Pandas数据框，这会消耗驱动程序上显著更多的内存，并且可能导致OOM。

要进行故障排除，请执行以下步骤：

  1. 验证您的变换单元格正在使用Pandas，并且此问题是否在运行Pandas特定代码时表现出来。
  2. 如果可以在Spark中进行此计算，我们强烈建议重新配置您的代码以使用Spark，因为它是并行的并且更具可扩展性。
  3. 当必须在驱动程序上执行此计算时，建议使用增加驱动程序内存的配置文件作为最后的手段。

返回顶部

保存为数据集失败

此问题可能由于多种原因而发生，但最常见的情况是返回的表格或数据框具有有效的模式。如果以下步骤都无法帮助识别您看到的特定错误，请参考我们关于搭建和检查出错的指南。

要进行故障排除，请执行以下步骤：

  1. 确保变换节点返回一个表格或数据框。
  2. 确认表格或数据框符合写入Foundry为数据集的基本要求：例如：
    1. 至少有一列。
    2. 所有列名都是有效的（例如，它们不包含空格或无效字符）。
    3. 没有重复的列名。
  3. 如果您确定此变换节点应该能够作为数据集写出，请尝试运行另一个变换节点或构建一个新的、非常简单的变换节点。
    1. 这可以帮助识别它是本地问题（例如，该特定变换节点发生了意外情况）还是更系统性的问题（例如，变换节点在一般情况下无法保存到Foundry）。
    2. 如果是本地问题，继续调试用于创建此表格/数据框的代码。
    3. 如果是系统性问题，请将问题提升到Palantir客服支持，并提供您调查的所有相关信息。

返回顶部

更新输入数据集预览后，工作簿未自动重新计算

当选择更新表格预览用于输入表格时，仅更新输入数据集的视图，Foundry中的基础数据集不会自动刷新。

要进行故障排除，请执行以下步骤：

  1. 如果选择更新表格预览后输入数据集没有刷新，请：
    • 打开这些数据集并查看它们是否一直无法搭建。
    • 如果输入数据集一直无法搭建，那么这就是您没有在工作簿中看到更新信息的原因。从这里继续调试。
    • 如果输入数据集按预期搭建，并且您在代码工作簿中看到的预览与实际不符，请：
      • 尝试从代码工作簿中删除输入表格并重新添加。
      • 如果这不起作用，并且预览与实际表格之间仍有差异，请联系Palantir客服支持。
  2. 如果选择更新表格预览时变换节点没有更新，这是预期行为，因为这些操作不受此操作的影响。要更新代码工作簿中的所有变换节点，请选择运行 -> 运行所有。这将运行代码工作簿中的所有变换节点，同时尊重搭建依赖关系。

返回顶部

无法将我的分支合并到主分支

当您发现无法将分支合并回主分支时，最常见的问题是master分支受到保护。可能存在合并冲突问题，但这将在其他部分中进行介绍。

要进行故障排除，请执行以下步骤：

  1. 确定分支是否受到保护。
  2. 如果分支受到保护，请识别所有者并请求他们合并您的分支。
    • 对于给定的工作簿，在master上启用分支保护，并确保您想要限制合并分支的用户只有工作簿的compass:edit权限。
    • 在内部，代码工作簿具有与分支相关的四个权限级别：view、edit、maintain和manage。默认情况下，compass:read扩展为view，compass:edit扩展为edit，compass:manage扩展为maintain和manage。
    • 创建分支并准备合并到父分支始终只需要edit权限。合并到受保护的分支需要maintain权限。更改分支保护设置需要manage权限。
    • 更多信息可在我们的分支概述中找到。
  3. 如果分支未受保护，您遇到了合并冲突，其中这是与master分支代码冲突的非附加代码。
    • 在这些情况下，解决这些合并冲突，然后将您的分支合并回master。
    • 更多信息可在我们的合并分支文档中找到。
  4. 如果master分支未受保护，且没有合并冲突，仍然无法将分支合并到master，请联系Palantir客服支持。

返回顶部

加快单元计算速度

假设我有数据集输入（1000行30列）+（100万行30列），并且有许多窗口/列推导步骤的变换，我如何加快计算速度？

要进行故障排除，请执行以下步骤：

1. 重构

对于实验或快速迭代，通常是个好主意将代码重构为几个较小的步骤，而不是一个大的步骤。

这样，您可以先计算上游单元格，将数据写回Foundry，并在后续步骤中使用此预计算的数据。如果您要在不更改这些早期步骤的逻辑的情况下重新计算，这会产生过多的工作。

具体来说：

Copied!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
workbook_1:
  cell_A:
    work_1 : input -> df_1
      # 需要进行4次迭代才能正确
      (takes 4 iterations to get right): 4 * df_1
    work_2: df_1 -> df_2
      # 需要进行4次迭代才能正确
      (takes 4 iterations to get right): 4 * df_2 + 4 * df_1
        = 4 df_2 + 4 df_1
    work_3: df_2 -> df_3
      # 需要进行4次迭代才能正确
      (takes 4 iterations to get right): 4 * df_3 + 4 * df_2 + 4 * df_1
  total work:
    cell_A
     = work_1 + work_2 + work_3
     = 4 * df_1 + (4 * df_2 + 4 * df_1) + (4 * df_3 + 4 * df_2 + 4 * df_1)
     = 12 * df_1 + 8 * df_2 + 4 * df_3

该代码段描述了一个工作簿中单元A的操作过程，其中涉及三个主要工作步骤（work_1、work_2、work_3），每个步骤都需要进行4次迭代才能达到正确结果。最后计算出单元A的总工作量。 相反，如果您将work_1和work_2分别写入它们自己的单元格，您执行的工作将看起来像：

Copied!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
workbook_2:
  cell_A:
    work_1: input -> df_1
      (takes 4 iterations to get right): 4 * df_1
      # 需要4次迭代才能正确：4 * df_1
  cell_B:
    work_2: df_1 -> df_2
      (takes 4 iterations to get right): 4 * df_2
      # 需要4次迭代才能正确：4 * df_2
  cell_C:
    work:3: df_2 -> df_3
      (takes 4 iterations to get right): 4 * df_3
      # 需要4次迭代才能正确：4 * df_3
  total_work:
    cell_A + cell_B + cell_C
       = work_1 + work_2 + work_3
       = 4 * df_1 + 4 * df_2 + 4 * df_3
    # 总工作量等于cell_A、cell_B和cell_C的工作量之和
    # = work_1 + work_2 + work_3
    # = 4 * df_1 + 4 * df_2 + 4 * df_3

如果假设 df_1、df_2 和 df_3 的计算成本相同，workbook_1.total_work = 24 * df_1，而 workbook_2.total_work = 12 * df_1，因此可以预期迭代速度提高接近2倍。

2. 缓存

对于任何“小”数据集，您应该通过选择工作簿并选择操作 > 缓存来缓存它们。

添加多个输入数据集选项。

这将使工作簿中的行保留在内存中，而不需要从写回的数据集中获取。根据需要考虑的几个因素，“小”是一个任意的判断，但 Code Workbook 在尝试缓存时做得很好，并会在太大时发出警告。

3. 函数调用

您应尽可能使用原生的 PySpark 方法，切勿直接在数据上使用 Python 方法（例如循环遍历单个行，执行 UDF）。PySpark 方法调用的是用 Scala 编写的底层 Spark 方法，并直接针对数据运行，而不是针对 Python 运行时；如果您只是使用 Python 作为与该系统交互的层，而不是作为与数据交互的系统本身，您将获得 Spark 本身的所有性能优势。

4. 降采样

如果您能够从大型输入数据集中得出自己的准确样本，则可以将其用作变换的模拟输入，直到完善逻辑并希望针对完整数据集进行测试。

在编写 PySpark 代码之前，考虑对超过一百万行的数据集进行降采样和缓存；由于数据集大小较大，您可能会在不慢慢捕获语法错误的情况下体验到更快的周转时间。

5. 总结

一个好的代码工作簿看起来如下：

  • 离散的代码块，执行您期望稍后重用但不需要重复计算的特定实现。
  • 降采样到“小”尺寸。
  • 缓存“小”数据集以实现非常快速的获取。
  • 仅使用利用快速底层 Spark 库的原生 PySpark 代码。

返回顶部