注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
Foundry 收集存储在 Foundry 内部的资源元数据。Linter 从各种元数据存储中提取并合并元数据。Linter 规则是一种针对资源元数据运行的逻辑，用于确定资源是否通过逻辑测试。如果资源未通过测试，Linter 会提出资源修改建议，以更改逻辑结果。
每个 Linter 规则都属于一个模式。
在资源节省模式中，每个规则都遵循一种方法来估算遵循建议后的节省。这种方法支持优先级排序；假设在许多情况下通常有效，但可能不适用于您的应用案例。要验证资源使用量的任何减少，请使用资源管理应用程序。
逻辑： 下游数据集在代码工作簿中构建，但不在同一计划上。
原因： 代码工作簿具有使用现成的热 Spark 模块的能力。当工作簿变换任务在同一计划内时，可以在模块处于活动状态时重用此模块，并跳过从磁盘加载物化数据。这导致更快的管道和降低的成本。
建议： 将代码工作簿变换直接下游移动到此数据集中的同一计划。
节省估算方法： Linter 生成读取数据集所需时间的大致估算。此估算基于观察测试的启发式方法，可能不完全适用于您的特定计算环境。
逻辑： 在过去七天内，此资源的任务实际运行时间百分比超过了 70%。这可能包括许多短时间内经常触发的任务，或较少的长时间任务。
原因： 不断构建的数据集可能是使用量的主要来源。对这些资源的任何频率降低或性能改进都可以带来大量节省。
建议： 考虑减少构建频率。
节省估算方法： 上一个日历月的总资源使用量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量）。
逻辑： 数据集的 JobSpec 提交与存储库中 master 分支的最新提交不同。
原因： 如果不修复，数据集的构建不反映存储库中的最新逻辑。
建议： 从计划中移除数据集，或在 master 分支上重新提交其变换逻辑。
逻辑： Contour 仪表盘没有在其起始增量数据集之一上进行数据集投影。
原因： 使用投影可以使仪表盘填充速度更快，从而在使用稳定的情况下节省重复的筛选计算。
建议： 查看 Contour 仪表盘以确认其使用、重要性和筛选列的排序。启用 Foundry 注册中的数据集投影，然后在底层 Foundry 数据集上添加一个投影，该投影经过优化以便在标记列的有序列表上进行筛选。确保定期刷新您的投影。您的 Contour 仪表盘现在应通过利用数据集投影更快地填充。
逻辑： 变换的输入和输出数据集的统计数据显示没有应用逻辑。
原因： 读取数据集到 Spark 然后写回会使用资源。可以通过跳过任何计算并使用 Foundry 视图来避免这种情况。
建议： 将此数据集转换为 Foundry 视图，以减少管道运行时间、数据重复和成本。
节省估算方法： 上一个日历月的总资源使用量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量）。
逻辑： 与数据集关联的变换在其 @configure 块中包含一个执行器内存基础的配置文件，并且尚未与 Velox 关联。
建议： 通过将这些任务切换到 Velox 后端，可能会产生潜在的节省。进行此更改时，重要的是检查消耗的资源以验证 Linter 建议的任何潜在节省。
逻辑： 代码存储库的默认分支未受保护。
原因： 保护默认分支对于跟踪更改、版本控制和防止意外更改非常重要。
建议： 将默认分支添加到存储库设置中的受保护分支列表中。
逻辑： 变换使用的内存与核心比率高于每核心 7.5 GB 的默认值。
原因： 当超过默认内存与核心比率时，会导致成本增加。许多用户增加执行器内存是为了应对与内存无关的问题，或者可以通过更便宜的方式解决问题。通过使用默认内存与核心比率执行变换，通常可以节省资源。然而，在某些情况下（例如行爆炸），需要增加每个执行器的内存以避免内存不足错误和/或执行器之间过多的洗牌。在这种情况下，通过增加执行器核心数量以匹配执行器内存配置文件，可以通过增加并行性和减少分区大小来加快构建时间并显著降低成本。
建议： 我们建议通过将 EXECUTOR_MEMORY_X Spark 配置文件与 EXECUTOR_CORES_X Spark 配置文件对齐来减少内存与核心比率。如果这导致内存问题，请检查您的 Spark 图以识别问题阶段。如果是数据集读取阶段问题，请考虑增加输入数据集的分区数量，以便将较小的分区大小提供给每个执行器。如果是洗牌阶段问题，请考虑禁用自适应 Spark 分配（ADAPTATIVE_DISABLED Spark 配置文件），如果任务少于洗牌分区设置，或增加洗牌大小（SHUFFLE_PARTITIONS_LARGE Spark 配置文件），以便将较小的任务提供给执行器。了解有关 Spark 配置文件的更多信息这里。
节省估算方法： 估算使用默认核心到内存比率而不是检测到的比率时，上一个日历月的资源使用量。将该值从观察到的资源使用量中减去以估算节省。
逻辑： 数据集正在增量更新，并且具有不理想的分区大小，意味着平均分区大小过大或过小。
原因： 最佳分区大小各不相同。如果分区大小太小，每个分区带来的开销可能会占据处理时间。如果分区太大，内存管理操作可能会增加运行时间和/或导致内存不足问题，从而增加任务时长，并在读取数据集数据的下游数据集或分析中增加过多的资源使用。
建议： 我们建议包括逻辑以检查分区大小，并以更好的分区大小存储数据集中的数据。在 APPEND 数据集的情况下，检查输出数据集中已有文件的数量。如果数据集不是由 Python 或 Java 变换逻辑文件支持，创建一个投影也可以解决此问题。优化投影以进行筛选就足以实现所需的压缩，但根据下游查询计划，通过优化合并可以获得额外的好处。
节省估算方法： 最近任务中读取文件所花费时间的比例与通常情况下读取该大小数据集所需时间的估算进行比较。此比例乘以上周读取此数据集的每个下游变换发生的次数。
逻辑： 数据集使用静态分配，这是一种使用固定数量执行器的 Spark 设置。最近任务运行的任务并行性低于阈值（默认：70%）。
原因： 静态配置资源可能导致并行性差；资源空闲并等待其他任务完成后才可使用。使用动态分配 Spark 设置可以确保空闲执行器不再专用于此任务，从而提高任务并行性。
建议： 我们建议通过应用 DYNAMIC_ALLOCATION_MAX_N Spark 配置文件来使用动态分配进行变换。
节省估算方法： 计算的并行性乘以上一个日历月的资源消耗量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量），以估算如果达到完美并行性时的节省。如果一个数据集最近的并行性为 70%，则预计可以节省上个月 30% 的资源使用。
类似于 增量追加数据集文件过多，但适用于使用 replace 增量变换输出写入模式的数据集。如果 UPDATE 事务不仅仅是添加文件，则不建议使用数据投影作为解决方案；修改或删除现有文件会导致数据集投影的完整重计算。要了解更多关于增量 Python 变换模式的信息，请访问这里。
逻辑： 计划构建的数据集由另一个计划构建。
原因： 相同的数据集由两个不同的计划构建，可能导致计算浪费、排队和不可靠的延迟。
建议： 更改计划的构建操作以消除重叠。
逻辑： 在此存储库中，未启用 压缩和合并 git 行为。
建议： 在存储库设置中启用 压缩和合并。
逻辑： 代码存储库有一个无法合并的打开存储库升级 PR。
原因： 存储库升级对于管道保持使用最新可用功能至关重要。不当前的存储库可能会导致管道故障，影响工作流程的稳定性并导致计算浪费。
建议： 调查 PR 未合并的原因，并修复升级。
逻辑： 代码存储库的设置已禁用自动合并升级拉取请求。
原因： 存储库升级对于管道保持使用最新可用功能至关重要。不当前的存储库可能会导致管道故障，影响工作流程的稳定性并导致计算浪费。
建议： 使用修复助手允许升级 PR 自动合并。否则，手动导航到存储库的设置，选择 Settings > Repository > Upgrades，并勾选 Automatically merge upgrade pull requests 选项。
逻辑： 计划在过去 30 天内未成功过。列出了在此期间构建失败的数据集。
原因： 在每次运行中，计划尝试重建一个在过去 30 天内从未成功的数据集，表明资源浪费。
建议： 暂停计划，修复失败的数据集，或从计划中移除失败的数据集。
节省估算方法： 过去 30 天内在分支上失败数据集的计算成本之和。
逻辑： 数据集具有代码工作簿 JobSpec。
原因： 生产中的数据集和计划中的数据集不应在代码工作簿中构建；相反，它们应该迁移到专为生产管道构建设计的应用程序，如管道构建器或代码存储库。
建议： 如果需要计划数据集，请将逻辑迁移到管道构建器或代码存储库中。
逻辑： 数据集具有 Contour JobSpec。
原因： 生产中的数据集和计划中的数据集不应在 Contour 中构建，应迁移到专为管道构建设计的应用程序中，如管道构建器或代码存储库。
建议： 如果需要计划数据集，请将逻辑迁移到管道构建器或代码存储库中。
节省估算方法： 过去 30 天内在分支上失败数据集的计算成本之和。
逻辑： 数据集位于回收站中。
原因： 尽管数据集已被放入回收站，计划仍试图构建它。
建议： 调查为什么数据集仍在计划中，并将其从回收站中移除或更新计划。
逻辑： 计划未启用 失败时中止。
原因： 如果未启用 失败时中止，监控将在计划完成后等待，即使计划中有失败的数据集。
建议： 启用 失败时中止 模式。此功能允许更快地通知监控失败并加快补救速度。
逻辑： 计划未启用 超出时长 模式。
原因： 当设置时长时，此模式可防止数据连接构建在网络波动期间无限期运行，并防止下游中断。
建议： 在计划上启用 超出时长模式。
逻辑： 计划不构建任何数据集。
原因： 计划可能是资源浪费，并为监控产生噪音。
建议： 调查计划是否有用，并决定是否删除或将其从监控范围中移除。
逻辑： 计划声明了被忽略的数据集，这些数据集不会修改构建操作。
建议： 从计划的忽略列表中移除违规数据集。
逻辑： 计划指定了输入数据集，但这些输入数据集实际上不是计划构建的任何数据集的输入。
原因： 此问题通常是由于排除的数据集引起的。
建议： 修改排除的数据集，或从连接构建操作中移除输入。
逻辑： 计划中有可构建的、未计划的、非 Fusion 支持的输入数据集。
建议： 计划标记的数据集，或移除其代码和 JobSpec 以使其成为原始数据集。如果数据集需要有 JobSpec，但不应被计划（如自由快照），请添加一个例外。
逻辑： 计划没有描述。
建议： 根据计划的目的和功能输入描述。
逻辑： 计划没有名称。
建议： 根据构建中的数据集名称和路径生成一个名称。这可以自动生成。
逻辑： 计划在一个不是 master 的分支上运行。
原因： master 分支在 Foundry 中被用作数据的规范版本。通常，计划应在分支上运行以提供数据的备用版本或实验替代逻辑。这种行为可能导致许多在分支上设置的计划运行时间长于所需。
建议： 理解分支上的计划是否需要，如果不需要，考虑暂停或删除计划。您还可以考虑减少非 master 分支计划的触发频率以降低成本。例如，如果计划在 master 上每天运行一次，是否可以在非 master 分支上每周运行一次以提供相同的结果？
节省估算方法： 上个月在此分支上运行的任务数量与上个月在 master 上运行的任务数量之比用于重新标准化此计划构建的数据集的资源使用。通过分支重新标准化的使用总和得出节省估算。
逻辑： 计划的一些解析输出未标记为目标，或反之亦然。
建议： 更新计划以使目标与实际计划输出匹配。
逻辑： 检查计划中所有资源的谱系，以确定最近是否发生过下游使用，无论是在计划管道中，在交互分析（如 Contour）、对象存储目标，还是通过外部 API 调用。
原因： Foundry 随时间变化，计算永远不会被用来做决策的结果没有意义。关闭未使用的管道是确保您的 Foundry 实例仅在主动使用来推动您的目标的计算结果上花费资源的一种方式。
建议： 未使用的计划被暂停。建议有时会揭示计划中未使用的子集，如果移除将可能减少计算。
节省估算方法： 过去一个日历月中未使用资源的资源使用总和。
逻辑： 计划未启用重试。
原因： 某些失败，例如由环境设置问题引起的失败，通常不会在第二次运行中出现。计划中没有重试可能导致数据集无法构建，而实际上可以构建。
建议： 启用重试。我们建议设置三次重试尝试。
逻辑： 计划相对于其构建操作的范围无效。其范围排除了应该由此计划构建的数据集。
建议： 编辑计划并修改其项目范围，以包括所有包含此计划构建的数据集的项目。如果无法实现，请移除计划的项目范围。
逻辑： 计划声明了一个数据集作为触发器，但不是作为输入。
建议： 修改连接构建操作以移除数据集从触发器或将其添加到输入。
逻辑： 计划声明了一个数据集作为触发器，同时也在构建。
建议： 修改构建操作以移除问题数据集从触发器或输出数据集。
逻辑： 计划有多个触发条件。
原因： 计划通常在新数据可用时运行。例如，如果您的计划有两个每小时更新一次的输入数据集，则可能导致计划每小时运行两次。如果计划在多个数据集更新时运行，可能会显著降低成本。
建议： 考虑将计划更改为使用 AND 触发器而不是 OR，或切换为基于时间的触发器以每小时运行一次。
逻辑： 计划使用强制构建设置，即使它不是数据连接摄取计划。
原因： Foundry 通过一个系统跟踪输入谱系中的事务性更改，该系统允许在输入未更改时跳过计算。强制构建设置确保无论输入事务分析的结果如何都运行变换，可能导致不必要的任务重复产生相同的结果。
建议： 检查变换中是否有任何未跟踪的外部依赖项（例如 API 调用）需要使用此设置。如果没有找到依赖项，请从计划中移除该设置。
节省估算方法： 计划中数据集的上一个日历月的总资源使用量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量）乘以其任务输入更改百分比。数据集的任务输入更改百分比是上周有更新输入的任务数量除以上周的任务总数（不是获取消耗数据的上个月）。
类似于 增量追加数据集文件过多，但适用于使用 SNAPSHOT 事务添加的数据集。在这种情况下，我们不建议使用数据投影。
类似于 增量过度配置的核心，但适用于使用 SNAPSHOT 事务运行的数据集。
逻辑： 检测到由 Spark 构建的数据集的可能不稳定查询计划。
原因： Spark 查询计划中有几个边缘情况可能导致不一致、非确定性或其他不稳定的数据。
建议： 每个建议应提供有关潜在不稳定性的性质的更多信息。调查具有潜在不稳定 Spark 计划的数据集的逻辑，并修复潜在的不稳定逻辑。
逻辑： 与这些数据集关联的变换不使用 Spark 上下文或 Spark 数据框，或者已经与基于 Pandas 的变换关联。
建议： 将这些变换切换为使用轻量级变换将带来潜在节省。进行此更改时，重要的是检查消耗的资源以验证 Linter 建议的任何潜在节省。
逻辑： 数据集构建为 SNAPSHOT，但直接下游至少有一个纯追加新数据的增量数据集。
原因： SNAPSHOT 事务处理所有历史数据。增量事务仅处理新数据并将结果添加到先前的值中。切换到增量事务可以显著减少交付结果所需的资源。
建议： 考虑将此数据集转换为增量变换以节省计算成本。如果数据集配置为增量运行，请了解并解决数据集频繁构建为 SNAPSHOT 的原因。
节省估算方法： 上一个日历月的总资源使用量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量）乘以输入大小总和（如果输入是增量的则是增量大小总和）与输入总大小总和（无论输入的增量性如何）的比率。这返回了如果数据集以增量运行的资源使用估算。因此，此建议的估计节省是过去一个月资源使用与此资源使用估算之间的差异。
逻辑： 变换使用的数据集小于 300Mb。
原因： 默认情况下，Foundry 使用分布式计算以便于扩展和速度。这比本地计算使用更多资源。在数据集大小较小且将保持较小的情况下，应使用本地执行（而不是分布式）以便需要更少的资源来执行变换。
建议： 为此变换或存储库中输入和输出数据集小于阈值大小的所有变换启用本地执行。这可以通过使用特定设置来启用，例如 KUBERNETES_NO_EXECUTORS Spark 配置文件。
节省估算方法： 上一个日历月的总资源使用量（例如，从 6 月 21 日起计算，提供的值是从 5 月 1 日到 5 月 31 日期间此资源的消耗量）除以核心更改的比率。例如，如果一个变换以前使用五个核心（两个执行器，每个执行器两个核心，一个驱动器，一个驱动核心），并且本地运行可以使用一个核心，则估计节省是总资源使用量乘以 0.8 ((5-1)/5)。
逻辑： 计划不是项目范围的。
建议： 修改计划以在范围词元模式下运行；默认情况下，范围是构建数据集的项目 RID。