Documentation
搜索文档
karat

+

K

API 参考 ↗
数据连接与集成数据健康搭建和检查常见问题解答

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

搭建和检查常见问题解答

以下是一些有关搭建和检查的常见问题。

有关一般信息，请查看我们的搭建和健康检查文档。

如何解决一般错误？

如果您在调试搭建错误时遇到困难，请考虑以下步骤：

  1. 搭建是否曾经成功过？如果是，您是否更改了生成数据集的逻辑？尝试回滚这些更改；如果搭建成功，您可能可以将问题隔离到新逻辑。您还可以在搭建应用的数据集窗格中选择日志以查看搭建历史。

  2. 底层数据最近是否更改了？您可能会看到以下几种表现：

    • 如果数据量急剧增加，您可能会因为计算资源问题而看到性能下降或搭建失败。
    • 底层数据的模式是否有任何变化？当存在依赖特定模式的逻辑时，这通常会导致搭建失败。要检查，请在搭建的数据集窗格中选择比较以比较与以前交易的差异。
    • 您失败的数据集上游的任何数据集的逻辑是否发生了变化？这可能会导致数据量增加或模式更改的下游影响。

返回顶部

如何理解冗长或令人困惑的错误信息？

Foundry中的错误信息可能很长，有时难以理解。如果您遇到难以执行的错误信息，请尝试以下步骤。

  1. 通常，错误跟踪中最有用的部分会以关键短语开头。查找错误信息中的以下短语，以找到对故障排除可能有价值的指导。请注意，重要的信息部分通常会出现在底部：

    • What went wrong:
    • Caused by:
    • Py4JJavaError
    • UserCodeError

  2. 如果您的错误引用了ErrorInstanceID而没有其他上下文，请将问题提升给Palantir支持团队。ErrorInstanceIDs也会显示用户逻辑错误，因此请先检查这是否可能是您问题的原因。

  3. 在联系支持时，请始终包括以下内容：

    • 您收到的完整错误信息
    • 您已采取的任何故障排除步骤
    • 您遇到错误的确切时间（日期、时间、时区）

返回顶部

为什么我的搭建“等待资源”？

您的搭建卡在“等待资源”状态的时间比平时长，并且没有运行。这可能是由于您运行搭建时平台上的活动增加所致。这时运行的许多搭建可能正在使用平台上的可用资源，导致您的搭建排队等待其他搭建完成并释放资源。这种行为是Spark变换讨论的Spark执行模型的副产品。

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

  • 尝试在平台活动较少的时间运行您的搭建，看看是否能改善性能。这将有助于避免您的搭建排队在其他任务之后。

  • 如果您在安排任务，避免在整点或午夜这样的常见时间运行任务。

返回顶部

为什么我的搭建运行时间变长了？

搭建性能随着时间的推移而恶化可能是由以下一个或多个原因引起的：1）变换逻辑的更改，2）输入数据规模的变化，或3）搭建时集群上计算负载的增加。

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

  • 检查您的变换逻辑——自上次运行此搭建以来发生了什么变化？即使是逻辑上的细微差异也可能导致搭建时间的差异。
  • 检查输入数据集的数据规模。如果上游数据集的大小显著增加，这可能会导致下游搭建性能下降。

返回顶部

如何解决不平衡（偏斜）的合并？

包含一个具有多个键条目的大左表和一个每个键条目较少的小右表的合并非常适合使用加盐合并，它可以将数据均匀分布到分区中。

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

  • 在Spark中，加盐合并通过将具有多个键条目的表拆分为较小的部分，同时将较小的表扩展为等量的副本来操作。这会导致与普通合并相同大小的输出，但较大表的任务大小较小，并且减少了OOM错误的风险。
  • 通过向左表添加一列0到N的随机数并制作右表的N个副本来加盐合并。如果将新随机列添加到合并中，可以将最大的桶减少到其先前大小的1/N。
  • 秘诀在于EXPLODE函数。EXPLODE是一个笛卡尔积：SELECT 'a' AS test, EXPLODE(ARRAY(1,2,3,4,5)) AS dummy2
  • 结果如下：
 test | test2
----------------
  a     |  1
  a     |  2
  a     |  3
  a     |  4
  a     |  5

此表格展示了两列数据，test和test2，其中test列的值都是a，而test2列的值是从1到5的整数。

  • 假设你有一个表现异常的合并，如下所示：
Copied!
1
2
3
4
5
6
7
8
SELECT
  left.*, right.*
FROM
  `/foo/bar/baz` AS left  -- 左表：/foo/bar/baz
JOIN
  `/foo2/bar2/baz2` AS right  -- 右表：/foo2/bar2/baz2
ON
  left.something = right.something  -- 基于left表和right表中something字段的相等条件进行连接
  • 此合并可能会失败，您的搭建报告显示一些任务花费的时间更长，并且比其他任务筛选/溢出更多数据。这表明您的数据集可能存在倾斜问题。
  • 验证倾斜的另一种方法是，在Contour中打开每个表，对something列进行透视并聚合行数，然后在something上合并左右表并乘以聚合列。这将输出每个something键的行数，理想情况下应均匀分布，但当出现倾斜时，表明需要进行加盐合并。
  • 考虑将您的代码替换为如下所示：
Copied!
1
2
3
4
5
6
7
8
SELECT
    left.*, right.*
  FROM
    (SELECT *, FLOOR(RAND() * 8) AS salt FROM `/foo/bar/baz`) AS left -- 从 `/foo/bar/baz` 表中选择所有列，并生成一个 0 到 7 的随机整数作为 salt
    JOIN
    (SELECT *, EXPLODE(ARRAY(0,1,2,3,4,5,6,7)) AS salt FROM `/foo2/bar2/baz2`) AS right -- 从 `/foo2/bar2/baz2` 表中选择所有列，并将 0 到 7 的数组展开为多行，每行的 salt 从数组中取值
    ON
      left.something = right.something AND left.salt = right.salt -- 根据 something 列和 salt 列进行连接

  • 调优：

    • 您应该通过有根据的猜测来选择扩展的因素。2的幂是找到正确估算值的好方法：8、16、32等。
    • 您可以使用 Contour 检查您尝试合并的两个数据集。在您合并的键上绘制直方图是否显示最大桶是下一个最大桶的 X 倍？将 explode 因素至少设为 X。
    • 类似的方法是查看在您的无盐任务运行时每个执行器的行数。

  • 注意以下事项：

    • 确保在为合并添加盐时不出现偏差一的错误。这样会导致您丢失一部分记录。
    • CEIL(RAND() * N) 给您 1 到 N 之间的整数。FLOOR(RAND() * N) 给您 0 到 N — 1 之间的数字。确保在加盐合并中扩展正确的数字集。

  • 加盐的开销

    • 为合并加盐并不一定会加快您的搭建速度；它只是增加了成功的可能性。
    • 如果您不必要地为合并加盐，可能会导致性能下降。

返回顶部

错误信息中提到的“shrinkwrap”是什么意思？

每个存储库都包含一个“shrinkwrap”文件，该文件定义了每个引用路径、该路径引用的数据集的唯一ID以及该数据集的当前路径之间的映射。这在数据集移动到文件夹之间时非常有用。例如，生成该数据集的存储库中的 shrinkwrap 文件将更新；下次运行搭建时，数据集将在正确的位置搭建。您可能会因为几个原因看到 shrinkwrap 错误，比如数据集删除、重命名或重新定位。

要进行故障排除，请查看以下注意事项和相关操作：

  • 要查找给定仓库的 shrinkwrap 文件：

    • 选择屏幕左上角附近的齿轮图标。
    • 切换到 显示隐藏文件和文件夹
    • transforms-shrinkwrap.yml 文件应如下所示：

    transforms.shrinkwrap.yml

  • 可能是存储库的 shrinkwrap 文件中引用的数据集不再存在。通常情况下，shrinkwrap 错误会告诉您哪些数据集不存在以及它们在存储库中的引用位置。

    • 检查存储库中引用的任何数据集是否被移到回收站并恢复它们。

  • 在您对分支进行迭代时，可能有更改已合并到 master 中，这些更改向存储库添加了一个文件并更新了 shrinkwrap 文件。要解决此问题，请执行以下操作：

    • 导航到 transforms-shrinkwrap.yml 文件。
    • 搜索在您对分支进行迭代时合并到存储库的更改。
    • 选择仅接受您的更改、仅接受传入的更改或同时接受两者。
    • 您还可以删除 shrinkwrap 文件，当运行检查时会自动重新生成。

返回顶部

错误信息中出现“PERMISSION_DENIED”

要运行搭建，触发它的用户必须拥有所需的权限。具体来说，用户必须是输出数据集的 Editor，因为运行搭建实际上是编辑输出文件。

一种简单的方法来查看您在给定数据集上拥有什么权限是通过在数据沿袭中调出数据集，启用 权限 筛选，并选择 资源权限 来为节点着色。

返回顶部

我该如何解决“等待输入依赖项计算”错误信息？

此错误发生在由于上游数据集搭建失败而导致的搭建计划被取消时，数据集搭建失败。

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

  1. 前往失败搭建的搭建报告。
  2. 查找此搭建中第一个失败的数据集。
  3. 尝试解决此错误信息并重新运行搭建。

返回顶部

我的 CI 任务失败，因为存储库不拥有数据集

您尝试搭建的数据集认为它是由另一个存储库控制的。您可以在数据集预览页面的 详细信息 选项卡中，在 Job spec 部分的 sourceProvenance 块中查看哪个存储库控制着数据集。当多个存储库创建相同的输出数据集时，会发生这种情况。

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

  • 如果您想将数据集的所有权转移到当前存储库：
    1. 删除数据集现有的任务规范。为此，请打开数据集，转到 详细信息 > 任务规范 并选择 编辑 > 删除。
    2. 再次从当前存储库触发 CI 搭建。
    3. 从另一个存储库中删除数据集源文件，以防止将来产生混淆。
  • 如果您想保留数据集所有者为另一个存储库（数据集最初创建的存储库）：
    • 删除当前存储库中的数据集源文件。

返回顶部

为什么我的检查因超时失败？

检查可能由于多种原因超时失败，但您可以采取一些常见步骤，这些步骤通常可以解除阻塞：

  1. 尝试重新运行 CI 检查。它是否始终以相同的错误失败？
  2. 尝试升级存储库，然后重新运行 CI 检查。它是否以相同的错误失败？
  3. 如果 CI 检查仍然失败，选择文件夹结构顶部的齿轮图标，然后选择 显示隐藏文件。在 ci.yml 中添加行 —refresh-dependencies。

返回顶部