注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
以下指南旨在提供优化 Foundry 使用的方法和最佳实践。本文档首先涵盖了如何确定 Foundry 中的使用情况，其次是如何识别使用浪费和优化管道。一般建议可能也会对项目经理或平台管理员感兴趣，因为他们专注于监控和优化组织的使用消耗。
除了这里列出的最佳实践外，Linter 会检查 Foundry 中的反模式状态，并提供有见地的建议以改善资源状态。您可以评估并采取这些建议来降低成本，优化您的 Ontology，并提高管道的稳定性和弹性。
在考虑如何为您的工作流程实施这些最佳实践时，重要的是不要陷入过早优化管道或工作流程的常见陷阱。用户应避免过早优化管道，并且不应期望有一种万能的优化策略。
我们建议按照以下心理步骤来检查您的方法的有效性：
如果这些问题中的一些尚未得到回答，这可能表明需要更多的前期工作以确保优化工作的成功。
考虑到这一点，以下是优化工作的好坏示例：
优化您的 Foundry 使用的一些一般实践包括：
Foundry 使用由三个组成部分组成：Foundry 计算、Ontology 体积和 Foundry 存储。
大多数账户都采用这种三维模型；然而，某些账户的使用标准可能有所不同。与您的 Palantir 代表审查条款以确认。
Foundry 计算 由用于数据集成和分析的工具驱动。Foundry 计算有三种主要类型：批处理、交互式和流处理。
批处理计算表示以“批处理”方式运行的查询或任务，意味着它们在某个计划的节奏或临时基础上在后台触发运行。当批处理计算任务未运行时，它们不会消耗任何计算资源。批处理计算的几个示例包括所有变换任务、从 Contour 构建数据集、代码工作簿、数据健康检查以及同步到 Ontology/索引存储。
交互式计算表示实时评估的查询，通常作为交互式用户会话的一部分。为了向用户提供快速响应，交互式计算系统保持始终开启的空闲计算状态，这意味着交互式查询往往会占用更多的计算资源。主要的交互式计算形式是 Contour - Contour 仪表盘、分析和嵌入的 Contour 图表都是交互式计算的示例。
流计算表示始终开启的处理任务，持续接收消息并使用任意逻辑处理它们。流计算的测量方式是流准备接收消息的时间长度；与批处理和交互式计算相比，流计算的成本最高。流计算的示例包括流变换和 Pipeline Builder 流。
批处理、交互式和流计算的计算使用量由以下因素驱动：
Foundry 使用的第二个组成部分是 Ontology 体积。Foundry 最独特的功能之一是 Ontology 层。Ontology 是企业数据和组织关心的对象之间的翻译层。Ontology 是对数据世界的分类，使组织能够以更具体的术语（如“飞机”或“汽车”）来考虑其数据，而不是描述它们的许多行和列的聚合。如果您不熟悉 Ontology，您可以从文档中了解更多。
Ontology 体积由以下因素驱动：
Foundry 存储 测量在 Foundry 中非 Ontology 变换层中存储的一般用途数据，有时称为“冷存储”。
数据集分支和以前的事务（以及视图）会影响单个数据集消耗的磁盘空间。Foundry 提供各种保留规则，以帮助您保持 Foundry 实例的精简。当通过 DELETE 事务从视图中删除文件时，文件不会从底层存储中删除，因此会继续累积存储成本。减少大小的唯一方法是使用保留规则清理不必要的事务。提交 DELETE 事务或更新分支不会减少使用的存储量。
清楚了解构成 Foundry 使用的内容及其影响因素，可以为您提供优化机会的洞察。
| Foundry 应用程序 | 使用影响类型 |
|---|---|
| 代码库 | Foundry 计算 |
| Pipeline Builder | Foundry 计算 |
| 代码工作簿 | Foundry 计算 |
| Contour | Foundry 计算 |
| 实时模型 | Foundry 计算 |
| Ontology | Ontology 体积 |
| 数据集 | Foundry 存储 |
资源管理应用程序 提供了组织了解其 Foundry 使用情况的可见性和透明度。该应用程序使用户能够查看按每种 Foundry 使用类型（Foundry 计算、Ontology 体积和 Foundry 存储）划分的 Foundry 使用情况。用户可以按资源（项目）、来源（应用程序）和用户查看使用情况。
在尝试确定 Foundry 使用优化的地方时，首先要检查的是资源管理应用程序。这使您能够看到哪些资源占用了最多的计算资源，并确定您有瓶颈的地方。从这里，您可以利用 Foundry 使用优化最佳实践 来识别潜在的减少使用的方法，但始终记住——专注于瓶颈。
如上所述，计算资源默认在资源管理（RMA）中按项目级别管理；在 RMA 中，我们看到每个项目测量的 Foundry 计算、Ontology 体积和 Foundry 存储指标。因此，正确的项目设置对于有效跟踪数据管道中的使用指标至关重要。正确的设置将使数据工程师或平台管理员能够在管道的关键阶段监控这些使用指标，以识别优化区域。不正确的设置将导致无法识别资源密集和计算成本高的数据管道部分。
Foundry 项目应被用于启用结构合理的数据管道。推荐的项目设置和管道阶段的最佳实践在 推荐的项目和团队结构文档 中有详细介绍。确保项目遵循推荐的结构，从导入数据源的原始数据到实际工作流程，将使用户能够分析管道关键阶段的计算和存储指标。
在寻找使用减少策略时，管理员应考虑他们团队中谁应有权创建项目和资源。将此访问权限限制为少数了解设置最佳实践的个人，将减少项目和资源的扩散，从而减少不必要的存储和计算。允许任何用户在平台上创建项目可能会导致项目未按推荐的结构创建，从而导致不必要且昂贵的管道，最终增加使用量。组织可以根据平台上用户的数量和数据访问限制来管理项目创建访问权限；制定确定此访问权限的流程，并教育那些有访问权限的人正确的项目结构，这对于这些资源的正确使用监控至关重要。
资源管理应用程序中的一个关键功能，使您能够控制 Foundry 中的支出，是 资源队列。为了限制与特定项目或多个项目相关的计算资源数量，您可以将项目捆绑到队列中。每个队列将被分配一个特定的资源限制，定义一次使用的最大 vCPU 数量。例如，您可以为给定队列分配 XXX 个 vCPU，这是分配的项目在任何给定时间运行的最大 vCPU 数量。这将确保您对每个项目的使用量有可见性和意识。
增量管道 通常用于处理随着时间显著变化的输入数据集。通过避免对所有未更改的数据行或文件进行不必要的计算，增量管道能够降低端到端延迟，同时最小化计算成本。实现这一目标的方法是了解 SNAPSHOT 和 APPEND 事务之间的区别。
默认事务类型是 SNAPSHOT。快照事务被视为数据集中的所有数据的替换。这意味着当您打开一个最新事务类型为 SNAPSHOT 的数据集时，预览将仅包含该最新快照事务中接收的数据。同样，当您在数据变换或 Contour 分析中尝试读取该数据集时，您将仅看到来自最新事务的数据。
快照是默认事务类型，因为它是最容易使用的——每次同步运行时，它都会下载数据库查询返回的所有数据，并创建一个快照事务，有效地替换数据集中之前的所有数据。以前事务中存在的文件当然仍然可以在数据集的历史版本中使用，但预览和使用数据的下游变换现在默认访问新事务。
当然，正确使用快照事务是简单的，但每次复制所有数据可能非常低效。一种潜在的效率改进是使用 APPEND 事务类型。
当一个数据集由附加事务组成时，它的默认视图是所有事务的总和。这意味着使用 APPEND 事务类型时，您不必同步已上传的文件——仅同步新数据到 Foundry。这导致 Foundry 存储减少，因为每个事务仅包含新增文件，而不是源系统中所有可用数据的快照。
另一种优化 Foundry 使用的方法是通过计划。计划 在调度工具中配置，用于在定期基础上运行 构建，以确保数据在 Foundry 中持续流动。
计划应设置为满足您的组织需求，但为了优化 Foundry 使用，必须确保计划设置高效，并且不会运行超过必要。例如，如果您设置一个数据集每天早上 8 点刷新，但实际上不需要每天早上 8 点更新数据——您的组织正在浪费 Foundry 使用。相反，您可以将计划设置为需要更新数据的频率，例如，每隔一天的早上 8 点。进行此调整将使 Foundry 使用量减半。
考虑优化计划的最佳实践时，需牢记的两个主要主题是 1）消除重复的计划，2）消除不必要的计划。
要识别冗余计划，请首先进入 数据沿袭 应用程序并将节点颜色更改为 Schedule Count。如果选择的节点有多个计划与之关联，请选择该节点并查看 Manage schedule 工具。在那里，您可以查看关联的计划，确定其所有者，以及是否可以合并。
最佳实践是确保管道中的每个数据集只有一个计划的构建与之关联。 由两个不同计划构建的数据集可能会导致排队并减慢两个计划的速度，并且浪费批处理计算。
减少冗余计划的另一个最佳实践是避免完全构建并使用连接构建。一个例子是包括原始数据集、清理数据集、数据变换，然后最终以 Ontology 结束的 Ontology 管道。您只需要一个计划，其中原始数据集是触发器，Ontology 数据集是目标，而不是设置三个计划，一个运行原始数据集，第二个运行清理数据集，第三个运行变换数据集。
要识别不必要的计划，请进入数据沿袭应用程序并按 Time since last built 着色节点。这使您可以查看哪些数据更新最频繁，并确定这是否是您组织的最优频率。
计划的频率和时间是优化使用的关键因素。您的组织需要多频繁更新数据？
另外，最好不要尝试在同一时间安排所有的构建，以确保调试更高效并使用更少的计算资源。考虑频率和时间时，重要的是回到您的组织需求，并确保您设置的刷新率符合您的组织需求，但不超过。
最后，在设置计划时查看高级选项也很重要。考虑强制执行失败时中止构建以减少浪费的批处理计算。您还可以将失败任务的允许尝试次数更新为三次或更少，而不是最大尝试次数 5 次。还建议将重建之间的分钟数设置为至少一到三分钟，以便有时间解决导致失败的任何故障。
Spark 是一个开源的分布式集群计算框架，用于快速的大规模数据处理和分析。Spark 通过将工作分配到不同的系统并并行处理它们，而不是线性等待完成所有工作，使计算机更容易和更快地处理大量数据或分析。
作为初步声明，并作为优化的一般最佳实践，我们建议仅在识别出特定瓶颈时手动调整 Spark 配置，而不是在整个平台上普遍应用。这是因为新的优化功能正在逐步添加并启用 Foundry 中没有手动覆盖的变换功能。一个简单的例子是 Spark 3 上的动态分配引入。以前手动设置变换的执行者数量非常重要，而现在这个数量在执行时会自动调整以避免浪费。
优化 Spark 只应由熟悉 Spark 概念并对其在管道中的使用有深刻理解的用户进行。
优化 Spark 的第一步是审查和理解