一间录音室明明空着，为什么还是不能预约？

第一步：把分散的三种事实找齐

团队先找到三个来源。预约系统记录谁占了哪个时段，维修系统记录设备出了什么问题，清洁人员在另一份表里登记房间是否已经打扫。每个系统都在认真记录自己的工作，只是任何一个系统单独拿出来，都无法回答“小林到了以后能否开始录音”。

Foundry 可以连接这些来源。负责与外部系统交换数据的现成适配工具，叫连接器。它知道怎样向某种系统发出请求、按什么方式读取返回的数据。官方支持的来源包括 SAP、NetSuite 等企业管理系统，Salesforce 等客户管理系统，也包括数据库、云存储、设备事件，以及 Databricks、Snowflake、BigQuery 等数据平台。没有合适的现成连接器时，如果源系统提供 REST API，也可以通过这些约定好的网络接口交换信息。

在这个例子里，连接成功只解决了“能够取得资料”。接入程序需要哪一种权限、源系统提供哪些字段、一次能读多少记录，仍由具体系统与接口决定。比如清洁表只有一个自由填写的“房间名称”，连接器能够读到这段文字，却不会替团队决定它和预约系统里的房间编号是否相同。这个问题稍后还要处理。

还有一个容易混淆的细节：谁执行读取，与网络怎样连通，是两件事。worker 是执行接入任务的组件；Foundry worker 在 Foundry 的运行环境中完成工作。如果资料位于企业内网，Agent proxy 可以承担网络转接。原文提到的 Agent worker 则是旧版执行方式，当前官方推荐 Foundry worker，已有旧配置仍受支持。现在通路打通了，下一步才轮到决定：资料要不要真的复制过来。

本节事实核查：官方资料 [1]官方资料 [2]

第二步：资料搬过来，还是需要时再读取？

最直观的方式，是定期把外部记录同步为 Foundry 数据集。文化中心可以把每日预约、维修单和清洁记录读入，再在同一处整理。这样保存下来的数据，也可以作为后续计算和历史分析的基础。代价是需要安排同步，并承担相应的传输、存储与处理工作。

另一种方式叫虚拟表。你可以把它想成 Foundry 中通向外部数据表的入口：在支持的来源和操作下，使用者可以发起查询，而不必先把整张表复制成 Foundry 数据集。例如团队想知道本周有多少个空闲时段，可以让数据所在的系统先完成一部分筛选或汇总，再返回结果。把计算交给数据所在系统完成，就叫计算下推。

两种方式带来的依赖不同。如果查询当时需要外部系统参与，那个系统的速度和可用性就会影响结果。即使采用虚拟表，网络传输、外部计算也可能产生费用；把查询结果继续保存成一个新数据集，又会形成新的存储。能否读写、能下推哪些计算、能否处理增量，取决于具体来源与操作，当前虚拟表也不支持通过 Agent worker 或 Agent proxy 使用。

对录音室来说，长期统计和眼前的预约查询可以采用不同安排。重要的是说清正在使用哪份数据、什么时候取得，以及来源暂时不可用时还有什么可以依赖。确定了读取方式后，团队很快遇到下一个问题：昨天读对的数据，今天还算对吗？

本节事实核查：官方资料 [3]官方资料 [16]

第三步：让昨天正确的记录，跟上今天的变化

设想小林最初预约三点，后来改到四点，最后又取消。页面若只在预约创建时读过一次，就会一直认为三点被占用。数据更新因此要表达完整的业务变化：新增了一条记录、原来的时间改了，或者这条记录已经删除或取消。

全量快照的做法，是在某个时点重新读取一份完整结果，好比重新拿到当天全部预约名单。增量更新则只读取约定范围里的变化，好比问“上次读取以后，哪些预约发生了改变”。后者通常能减少重复读取，却需要可靠地识别更新范围；晚到的记录、修改和删除都可能影响最终结果。

当更新需要更及时，可以让事件持续传来，这叫流式接入。例如门禁每出现一次刷卡，就送来一条事件。CDC，即变更数据捕获，关注的是从源系统取得新增、修改和删除的变化记录。CDC 可以通过流传送；流里也可以是门禁事件。因此“流式”回答怎样持续到达，“CDC”回答取得哪一种变化，两个概念可以同时成立。

这些变化还必须能对上同一件事。系统需要一个主键，也就是唯一认出某条预约的编号；还需要知道变更先后，识别删除标记。否则“改到四点”的消息先到，“改到三点”的旧消息后到，页面就可能退回过时状态。顺序、重复和断线后的补送，都要由支持这些能力的接入与处理方案落实。

也不是每种资料都需要同样快。麦克风刚报修，预约页面应及时反映；上个月各房间的使用总时长，通常不必每秒重算。现在资料能不断更新了，问题又往前推进了一步：三个系统中的“1 号房”，到底是不是同一间房？

本节事实核查：官方资料 [4]官方资料 [15]官方资料 [16]

第四步：把不同系统的写法，整理成同一个意思

预约系统把房间写成 A-01，维修单写“1号录音室”，清洁表写“东侧一号房”。如果简单按文字相等来匹配，维修单就接不到预约上。页面可能继续显示可用，因为它“没有找到故障”；真正发生的却是“没有认出这就是同一间房”。

所以取得原始记录之后，还需要加工。团队建立房间编号的对应关系，把日期和时区统一，再把维修与清洁记录关联到正确房间，最后根据明确条件计算可用时段。按顺序执行这些步骤的过程，就是数据管道。它把原始资料变成下一项工作能够直接使用的数据。

Pipeline Builder 提供可视化方式组织这条管道。使用者可以看到读取、筛选、匹配与计算之间的关系，也能管理管道的变更版本。需要代码实现的逻辑，则可放在 Code Repositories 中编写和评审。当前官方概览列出 Python、Java、SQL 数据转换；原文也提到 R，但不能据此理解为所有代码仓库都支持 R，需要结合具体工具确认。

可视化与代码之间也有衔接路径。官方支持把默认的 Spark 批处理管道导出为 Java 转换代码。Spark 是处理数据的计算引擎，批处理表示把一批资料一起计算。这种导出有适用范围，不能推断成任何管道都能完整转换。

经过这些处理，A-01 终于能找到它的维修单了。不过有些维修信息并不规整：一位使用者写“录到一半总有杂音”，还附了一张设备照片。团队现在要解决的，已经从匹配编号变成了理解内容。

本节事实核查：官方资料 [5]官方资料 [6]官方资料 [13]官方资料 [17]

第五步：文字、图片和录音，怎样参与同一件事？

房间编号的对应规则可以事先写清，但“声音断断续续”“底噪很大”“设备不好用”表达的含义并不完全一样。这时，语言模型可以帮助从自由文本中提取问题类型或归纳现象。Pipeline Builder 的 LLM 节点，就是在数据加工过程中调用大语言模型的一种方式。

例如管道保留原始投诉，同时增加“疑似音频设备问题”这一分类。维修人员随后能够查到同一设备的相关反馈，并回看每条原话。保留原文很有用：如果分类不准确，人仍然能理解用户到底说了什么，也能修改分类规则或提示词。

输入只有“不太好用”时，资料不足以判断哪件设备损坏。一个合理的处理结果可以是“原因待确认”，让工作人员继续询问。模型在这里帮助整理材料，真正的设备状态还需要维修记录或人工确认。把不确定的判断直接当成事实，会把错误继续传到预约页面。

原文所说的 Multimodal Data Plane，指的是平台处理文字、图片、音频等多种资料的基础能力。不同形式的材料可以参与同一条业务链，但仍有各自的处理方式：图片可能需要识别设备，录音可能需要转写，表格则需要核对字段。资料统一接入之后，质量如何判断，仍要围绕它在当前业务中的用途。

现在团队已经有了一条能计算“可预约”的管道。下一次页面再出错时，他们还得回答一个关键问题：错误最早是在哪一步出现的？

本节事实核查：官方资料 [7]官方资料 [18]

第六步：沿着结果，找回它的来龙去脉

假设下周又有人发现一间维修中的房间被标成可预约。错误可能来自维修系统没更新，也可能是数据读取停了、房间编号匹配错了，或者最后的可用规则漏掉了维修条件。只盯着页面，无法分清这些可能性。

Data Lineage，也就是数据血缘，把来源、加工步骤和使用结果连接成依赖关系。团队可以从“可预约时段”往回追到关联后的房间数据，再追到维修记录的接入步骤；也可以从某个出错的数据源向前看，找到受影响的结果。它让“这个数字从哪里来”有一条可以追查的路径。

如果还要解释昨天的具体一次判断，就需要结合版本和时间。今天的维修记录可能已经修正，今天的规则也可能已升级。原始记录、当时的数据版本、规则版本和发布时间放在一起，才有机会还原昨天为什么得到那个结果。依赖关系说明怎样算，历史版本帮助说明当时用什么算。

健康检查可以监测数据是否及时更新、接入与计算是否成功。至于发现问题之后要提醒谁、是否停止发布结果，还需要对应配置。在我们的虚构方案里，维修数据长时间没有更新时，页面显示“设备状态待确认”；团队据此避免把“没有收到故障消息”误当成“已经确认一切正常”。

走到这里，资料已经能够被追查和维护。文化中心准备让更多部门一起使用，又出现了最后一组问题：哪些内容能分享，原来的分析工具还能不能继续用？

本节事实核查：官方资料 [8]官方资料 [9]

第七步：让更多人使用，同时保留清楚的边界

运营人员需要知道房间能否开放，维修人员需要看到故障详情，普通预约者通常不需要看到内部人员信息。Foundry 的资源权限之外，还可以使用 Markings，即安全标记，增加访问必须满足的条件，并按规则沿文件层级或数据依赖继承。一个人有查看某份资料的角色权限，还需要满足相应标记的要求。

例如资料同时带有“人事”和“受限项目”两个标记，通常要同时满足两项访问资格。官方另有 CBAC，即基于分类的访问控制，可以表达分级等规则，其中一些分发类别采用满足其中一个条件的方式。这套能力默认不启用，配置需要 Palantir 参与。理解安全共享时，要知道正在使用哪种规则，不能只看到“权限”两个字就把它们视为同一种机制。

分享也可能发生在工具之间。原来做分析的同事也许还要继续使用 Power BI、Tableau 或 Jupyter。开放的表格式有助于不同数据工具交换表数据；Apache Iceberg 就提供了一套共同遵守的表组织规则。Foundry 支持平台管理的 Iceberg 表，也支持指向外部表的虚拟表。对指定记录做更新、删除或合并，属于行级修改；Iceberg REST 目录则提供发现与访问这些表的目录服务，具体读写能力仍受来源和权限约束。

数据能被另一种工具读取之后，业务含义也要保持一致。一个报表统计“最终确认的预约”，另一个把取消记录也算进去，即使来自同样的数据，结果也会不同。开放表格式帮助流通表数据，业务规则、页面和权限则仍需各自维护或迁移。

再回到小林的预约。现在页面之所以能说“下午三点可以使用”，是因为排期、维修和清洁信息已经找齐，记录被认作同一间房，更新能及时到达，判断规则也有来源可查。为了持续做到这些，团队需要维护连接、计算和权限，并承担两端的资源成本。Foundry 的价值要放在这条完整链中理解：它把散落的记录整理成可共同使用的信息，为之后的业务本体、分析与应用提供基础。

本节事实核查：官方资料 [10]官方资料 [11]官方资料 [12]官方资料 [14]

适用边界与容易误解的地方

术语速查

CDC

通过变更记录传播数据更新的接入方式。

虚拟表

指向外部数据表的资源。

计算下推

将部分运算交给数据所在系统执行。

数据血缘

说明资料的来源与加工依赖。

Markings

限制哪些人具备访问资格的安全标记。

来源与核查

对应原文

Rahul Garg · 2026-06-11 · Vanyar

1. Palantir：连接器目录核对连接器分类及系统名称。
2. Palantir：Foundry worker 与 Agent worker核对旧版状态、推荐计算方式与代理区别。
3. Palantir：虚拟表核对源类型、连接模式、下推及存储限制。
4. Palantir：CDC核对变更记录与源系统支持前提。
5. Palantir：Pipeline Builder核对可视化加工与版本管理。
6. Palantir：Code Repositories核对当前概览列出的数据转换语言。
7. Palantir：LLM 节点核对管道中的语言模型调用。
8. Palantir：Data Lineage核对依赖关系查看能力。
9. Palantir：健康检查核对监测类型，不推断所有检查自动阻断。
10. Palantir：Markings核对强制标记与权限关系。
11. Palantir：CBAC核对非默认启用与分类规则。
12. Palantir：Iceberg 表核对托管表和外部虚拟表的区别。
13. Palantir：导出管道代码核对导出 Java 的适用范围与结果验证要求。
14. Palantir：Iceberg 表与目录核对行级修改、托管与虚拟表以及 REST 目录。
15. Palantir：Streams核对持续接入事件与流的概念。
16. Palantir：Datasets核对数据集及数据版本的概念。
17. Apache Spark：官方文档核对 Spark 作为数据处理计算引擎的含义。
18. Palantir：平台概览核对平台处理多类资料的能力背景。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。