深度解析palantir（二）

Palantir Foundry 数据集核心概念

这份文档是Palantir Foundry数据集成体系的底层核心原理手册，完整定义了Foundry中数据的最小载体「数据集」的核心能力、底层实现逻辑与配套概念。它是之前讲解的Pipeline Builder、Code Repositories等所有上层数据应用的底层基础，所有数据开发、集成、治理操作都围绕这套核心规则运行。

以下是文档内容的逐模块深度拆解，同时结合你提供的数据集界面截图，完成原理与实操的对应讲解。

一、数据集的核心定位与基础定义

1. 核心本质

数据集是Foundry中数据从接入平台到映射至Ontology语义层的最基础、最核心的载体。 从底层实现来看，数据集本质是对底层兼容文件系统中存储的一组文件的逻辑包装层。它不直接存储文件，而是维护文件的元数据、逻辑映射与管理能力，将底层复杂的存储细节与上层应用解耦。

2. 核心价值（原生自带的4大核心能力）

这是Foundry数据集区别于普通文件/文件夹的核心优势，也是企业级数据管理的基础：

• 统一的权限管理：细粒度控制谁能查看、编辑、管理数据集
• 标准化的模式（Schema）管理：统一规范数据的解析规则、字段类型
• 完整的版本控制：基于事务实现数据的全生命周期历史追溯、回滚
• 原生的增量更新支持：适配批处理、增量处理等全场景数据更新需求

3. 数据集支持的3类数据格式

Foundry数据集可统一存储和管理全类型数据，不同类型数据的处理规则有明确差异：

二、事务（Transaction）：数据集版本控制的核心

事务是Foundry实现「数据的Git」的核心底层机制，数据集的所有内容变更，都是通过事务实现的。用户在界面上看到的数据集，本质是「最新事务提交后形成的数据集视图」。

1. 事务的核心定义

事务是对数据集底层文件的原子性修改操作，要么全部生效，要么全部不生效，不会出现中间状态。它完全类比Git中的提交（Commit），是Foundry数据版本控制的基础。

2. 事务的完整生命周期

事务有3种核心状态，形成固定的流转流程：

1. OPEN（打开状态）：事务启动后进入该状态，此时可向数据集的底层文件系统中写入、修改文件；
2. COMMITTED（已提交状态）：事务提交后进入该状态，事务中写入的所有文件正式生效，会出现在数据集的最新视图中；
3. ABORTED（已中止状态）：事务被中止后进入该状态，事务期间写入的所有文件都会被忽略，不会对数据集视图产生任何影响。

3. 4种核心事务类型（决定数据的更新方式）

事务的核心差异在于对数据集底层文件的修改方式，官方定义了4种类型，覆盖所有数据更新场景，也是批处理/增量管道的底层基础：

4. 事务类型示例（直观理解视图的生成逻辑）

文档中给出了标准事务历史示例，最终数据集视图的计算逻辑如下：

1. 初始事务：SNAPSHOT 写入文件A、B → 当前视图：[A, B]
2. 第二个事务：APPEND 新增文件C → 当前视图：[A, B, C]
3. 第三个事务：UPDATE 将文件A修改为A' → 当前视图：[A', B, C]
4. 第四个事务：DELETE 删除文件B → 当前视图：[A', C]
5. 第五个事务：SNAPSHOT 写入文件D → 当前视图：[D]（快照完全重置了视图，之前的所有文件都不再生效）

三、保留策略（Retention Policies）：底层物理文件的清理规则

1. 为什么需要保留策略

这是文档中重点强调的核心逻辑： DELETE事务仅删除数据集视图中的文件引用，底层文件系统中的物理文件不会被删除；同时，ABORTED的事务、历史版本的事务对应的物理文件，都会一直保留在存储中，持续占用存储成本。

保留策略的核心作用，就是真正清理底层文件系统中不再需要的物理文件，实现两个核心目标：

• 降低存储成本，清理无效、过期的文件；
• 满足数据合规要求，实现过期数据的彻底清理。

2. 界面截图对应讲解（与文档完全匹配）

你提供的截图，就是文档中提到的数据集保留策略查看页面，对应文档中「查看数据集的保留策略 [Beta]」章节，界面元素的完整解读如下：

1. 页面入口：数据集预览应用 → 顶部Details标签页 → 左侧菜单栏Retention policies，和文档描述完全一致；
2. 系统默认策略：截图中DELETE_ABORTED_TRANSACTIONS是Foundry自带的系统级策略，作用是自动清理所有ABORTED状态事务对应的底层物理文件（中止的事务不会出现在数据集视图中，无业务价值，系统默认自动清理）；
3. 分支过滤开关：Only show policies relevant to this branch开关，开启后仅显示当前数据集分支生效的保留策略，关闭后会显示全部分支的策略；
4. 功能状态：文档明确标注该功能为Beta版，可能在部分Foundry实例中未开放，需联系Palantir代表开通。

四、分支（Branches）：数据集的多人协作能力

1. 核心定位

分支是Foundry为数据集提供的并行版本管理与多人协作能力，完全类比Git的分支机制。 事务仅解决了数据集的单链路版本追溯问题，而分支解决了「多个用户同时对数据集做修改、实验，互不影响，不破坏主版本稳定性」的协作需求。

2. 核心规则

• 每个数据集默认有一个主分支（通常为master），是生产环境的稳定版本；
• 用户可基于任意分支的当前视图，创建新的分支，新分支会完整继承原分支的事务历史；
• 用户在新分支上的所有修改、事务提交，仅对当前分支生效，不会影响原分支；
• 分支上的修改验证通过后，可通过合并操作，同步到主分支中。

五、数据集视图（Dataset View）：用户看到的数据集的本质

1. 核心定义

数据集视图，是某个时间点、某个分支下，数据集的有效文件集合。 我们在界面上打开数据集看到的行和列，本质就是该数据集当前分支、最新时间点的视图。历史视图，就是数据集的历史版本。

2. 视图的标准计算逻辑（文档官方定义）

视图不是固定存储的，而是基于事务历史动态计算出来的，计算步骤完全固定：

1. 从一个空的文件集合开始；
2. 找到目标时间点之前，该分支上最新的SNAPSHOT事务；如果没有SNAPSHOT事务，则取数据集的最早事务；
3. 从这个起始事务开始，按时间顺序应用目标时间点之前的每一个后续事务，更新文件集合：
   • SNAPSHOT/APPEND：将事务中的所有文件添加到集合中；
   • UPDATE：将事务中的文件添加到集合中，已存在的同名文件直接替换；
   • DELETE：从集合中删除事务中指定的所有文件；
4. 最终得到的文件集合，就是该时间点、该分支的数据集视图。

3. 关键补充规则

• 只有SNAPSHOT事务会重置视图的计算起点，因此增量管道（无新SNAPSHOT，仅用APPEND/UPDATE/DELETE）的视图，始终基于最开始的SNAPSHOT累加计算；
• 视图可以跨分支继承事务，比如从master分支创建的子分支，会完整继承master分支的事务历史，作为视图计算的起点。

六、模式（Schema）：数据的解析规则

1. 核心定义

Schema是绑定在数据集视图上的元数据，核心作用是定义如何解析视图内的底层文件，包括两部分核心内容：

• 文件的解析规则：比如文件格式、CSV的分隔符、编码等；
• 结构化数据的字段定义：列名、字段类型、字段约束等。

【重点提醒】Schema是绑定在视图上的，不是绑定在底层文件上的，因此无法保证底层文件一定符合指定的Schema。比如给CSV文件绑定了Parquet格式的Schema，读取数据集时会直接报错，这是开发中常见的踩坑点。

同时，Schema可以随时间变化，和数据集视图绑定，适配数据集的结构性变更（比如新增列、修改字段类型）。

2. 官方支持的字段类型

Foundry数据集兼容Spark的全量数据类型，官方列出的核心支持类型如下：

• 基础类型：BOOLEAN、BYTE、SHORT、INTEGER、LONG、FLOAT、DOUBLE、STRING、BINARY、DATE、TIMESTAMP
• 高精度数值类型：DECIMAL，必须配置precision（精度，最大支持38）和scale（小数位数），官方推荐默认值为precision: 38、scale: 18
• 复杂类型：
  • MAP：需配置键类型mapKeyType和值类型mapValueType
  • ARRAY：需配置数组元素类型arraySubType
  • STRUCT：需配置嵌套字段的子Schema列表subSchemas

3. 配套配置规则

• 文件格式支持：Schema中会定义底层文件的存储格式，最常用的三种为Parquet、Avro、文本格式（CSV、JSON等）；
• 自定义解析配置：可在Schema的options块中配置CSV文件的解析规则（分隔符、编码、首行是否为表头等）；例子：（就像sql中的表结构 id INT, name STRING, address STRUCT<city STRING, zip INT>, create_time TIMESTAMP ）
• 半结构化数据处理建议：对于JSON、XML等非表格格式，官方不建议直接绑定Schema，推荐存储为无模式的非结构化数据集，在下游数据变换中做Schema推断，提升性能与灵活性。

shcema推断：

第一步：上游原始数据集，只存文件，不绑定 Schema

你把同步过来的 JSON/XML 文件，存成一个无模式的非结构化数据集。这个数据集不配置任何 Schema，Foundry 只把这些 JSON 当成普通文件管理，不做任何提前解析、不做任何格式校验。上游同步新文件的时候，只是把文件存进来，没有任何额外开销，速度极快，也不会因为文件结构变化而同步失败。

第二步：在下游数据加工环节，做 Schema 推断 + 解析

当你需要用这个数据的时候，在 Pipeline Builder（或 Code Repositories）里，把这个无模式的原始数据集作为输入源，然后在下游的变换步骤里完成 Schema 推断：

1. 用 Foundry 内置的「Parse JSON」算子（或 SQL 的from_json函数、Python 的 json 解析函数），让系统自动扫描 JSON 文件的内容，识别出里面的字段、嵌套结构、数据类型，自动生成对应的 Schema（这个自动识别生成 Schema 的过程，就是Schema 推断）；
2. 系统基于推断出来的 Schema，把所有 JSON 文件解析成结构化的二维表格，每一行对应一条业务数据，供你后续做清洗、关联、聚合等加工；
3. 你可以基于自动推断的结果，手动微调 Schema（比如把字符串类型的时间改成 TIMESTAMP、展开嵌套结构），固化成稳定的结构，存成下游的结构化数据集。

七、底层支持文件系统

文档中明确了Foundry的存储架构核心规则： 数据集跟踪的文件，并不存储在Foundry平台本身。Foundry仅维护「文件在Foundry中的逻辑路径」与「文件在底层支持文件系统中的物理路径」之间的映射关系。

底层支持文件系统必须兼容Hadoop FileSystem（HDFS）接口，常见的部署方式为：

• 私有化部署：自托管的HDFS集群；
• 云原生部署：公有云对象存储（Amazon S3、Azure Blob Storage、Google Cloud Storage等）。

所有数据集的底层物理文件，都存储在该支持文件系统的基础目录下的文件夹层级中，Foundry本身不做物理文件存储，实现了存算分离的架构。

其他数据库处理：不能直接作为底层文件导入

通过「数据连接」同步 SQL 数据到 Foundry

这是官方推荐的、也是唯一的 SQL 数据库数据接入方式，完全对应你之前学的「数据连接」应用。整个过程分为 3 步，和之前的概念完全打通：

第一步：用「数据连接」连接 SQL 数据库

在 Foundry 的「数据连接」应用里，配置 SQL 数据库的连接信息：

• 数据库类型：MySQL、PostgreSQL、SQL Server、Oracle 等（Foundry 原生支持绝大多数主流 SQL 数据库）
• 连接地址：主机名、端口
• 访问凭证：用户名、密码（凭证会被安全加密管理，不会泄露）
• 初始配置完成后，你可以在「数据连接」里可视化探索数据库里的表、视图、字段。

第二步：同步 SQL 数据，生成 Foundry 数据集

在「数据连接」里配置同步任务，把 SQL 数据库里的表 / 视图数据，同步到 Foundry 中：

• 同步方式：支持全量同步（第一次同步全表数据）、增量同步（后续只同步新增 / 变更的数据，效率更高）
• 底层存储：同步过来的数据，会自动转换成 Foundry 推荐的Parquet 列式存储格式，存储在 Foundry 的底层文件系统（S3/HDFS）里
• 自动绑定 Schema：同步过程中，Foundry 会自动把 SQL 数据库的表结构（字段名、字段类型、主键等）映射成 Foundry 数据集的 Schema，无需手动配置，直接生成绑定固定 Schema 的结构化数据集

举个例子：你同步 MySQL 里的user表到 Foundry，会自动生成一个名为raw_user的结构化数据集，底层是 Parquet 文件，Schema 自动映射为id INT、name STRING、create_time TIMESTAMP（和 MySQL 表结构完全对应）。

第三步：下游加工使用

同步生成的结构化数据集，就可以直接用了：

• 在 Pipeline Builder 里做清洗、关联、聚合
• 在 Code Repositories 里用 SQL/Python 做深度加工
• 在 Contour 里做分析、在 BI 工具里做报表
• 用「数据沿袭」查看上下游依赖，用「数据健康」监控同步状态

除了从 SQL 数据库同步数据到 Foundry，你也可以通过「数据连接」，把 Foundry 里加工好的数据集，写回到 SQL 数据库中，供业务系统调用。

• 写回方式：支持全量覆盖写入、增量追加写入
• 适用场景：把 Foundry 里计算好的业务指标、标签、报表结果，写回业务数据库，支撑前台应用

八、界面全元素与核心概念的串联

你提供的数据集预览界面，完整覆盖了文档中的所有核心概念，界面元素的对应关系如下：

九、整体逻辑闭环总结

文档中定义的所有核心概念，共同构成了Foundry企业级数据管理的完整底层体系，和之前讲解的上层应用形成了完美的闭环：

1. 数据接入：「数据连接」应用将外部数据同步到Foundry，通过SNAPSHOT/APPEND事务生成初始数据集；
2. 数据开发：「Pipeline Builder」/「Code Repositories」应用开发数据流水线，通过4种事务类型，对数据集进行变换、更新，生成下游数据集；
3. 数据探查：「数据集预览」应用查看数据集的视图、Schema、事务历史、保留策略，验证数据结果；
4. 数据治理：「数据沿袭」应用追踪数据集的上下游依赖与事务流转，「数据健康」应用监控数据集的Schema变更、更新状态与数据质量；
5. 运维调优：「构建应用」执行流水线构建，生成数据集事务，监控事务的执行状态，排查构建故障；
6. 存储管理：通过保留策略，清理底层无效的物理文件，控制存储成本，满足合规要求。