从原始数据接入到 Ontology 语义建模的全链路数据治理体系，基于 "Data as Code" 理念实现数据资产的版本化管理和零拷贝协同。
Palantir 的数据集成哲学与传统做法截然不同：
"所有数据先落地，再治理"——不在入口做过滤，保留原始数据的完整性和真实性。
| 维度 | 传统做法 | Palantir 做法 |
|---|---|---|
| 数据接入 | 先设计目标模型 → 清洗数据 → 只导入"干净"数据 | 全部原始数据落地 → 在平台内逐步清洗转换 |
| 原始数据 | 过滤后丢弃原始数据 | 原始数据不可篡改保留，完整血缘 |
| 模型变更 | 需要重新从源头获取数据 | 回溯到原始数据重新处理 |
| 审计合规 | 入口过滤后无法追溯原始状态 | 审计和合规有据可查 |
这一哲学的价值在于：原始数据不可篡改地保留了"发生了什么"，如果下游模型变化，可以回溯到原始数据重新处理而无需重新对接源系统。
数据在 Foundry 中经历三个递进的存储和处理层次：
源系统 (ERP / MES / WMS / CRM / IoT)
│ 连接器同步 (Magritte 框架)
▼
Raw Dataset
├── 格式: Parquet / Delta 列存
├── 版本: 每个同步批次有独立版本号
├── 血缘: 记录来源系统、同步时间、数据量
└── 不可变: 原始数据落地后不可修改
原则: 这不是缓存，是持久化存储，
带完整版本和血缘管理。Raw Dataset
│ Transform (Python/Spark/SQL)
│ 清理、去重、标准化、关联
▼
Transformed Dataset
├── 每个转换步骤可追溯
├── 支持分支 (Branch) 和版本 (Version)
└── 多 Dataset 可串联成 DAG 流水线Transformed Dataset
│ 映射关系 (Mapping)
▼
Ontology Object Layer
├── 不单独存储数据
├── "对象定义 + 指向 Dataset 的映射"
└── 查询对象属性时底层读的还是 Dataset
关键结论: Ontology 是语义层而非独立存储层。
数据存储三重: 原始 → 加工 → Ontology映射Pipeline Builder 是 Foundry 中数据工程师的核心工具，提供可视化拖拽式 DAG 编排能力。
| 调度模式 | 触发方式 | 适用场景 |
|---|---|---|
| 增量更新 | 定时 (如每6小时) | 追加型数据（销售记录、日志） |
| 全量刷新 | 定时 (如每日凌晨) | 维度表、小数据集 |
| 事件触发 | 上游 Dataset 完成 → 触发下游 | 依赖链自动传播 |
| 手动触发 | 用户手动执行 | 临时分析、数据修复 |
💡 DAG 自动编排：平台自动计算依赖关系，按拓扑顺序执行。上游失败则下游不触发，保证数据一致性。
这是 Palantir 数据架构中最具创新性的能力之一——像管理代码一样管理数据：
| 概念 | Git 类比 | Foundry 实现 |
|---|---|---|
| Repository | Git 仓库 | Dataset |
| Branch | 分支 | Dataset Branch |
| Commit | 提交 | Dataset Version |
| Clone | 克隆 | Zero-copy Clone |
| Merge | 合并 | Branch Merge |
基于 Apache Spark + AtlasDB 事务性文件系统：克隆时不复制数据，仅创建元数据指针；写时复制 (Copy-on-Write) 确保只有修改的数据块才产生新存储。PB 级数据克隆可在秒级完成。
"每一个数据资产（Dataset、Transform、Pipeline）都像代码一样管理——版本控制、分支开发、Code Review、合并策略。数据的生命周期等于代码的生命周期。"
端到端的数据血缘追踪是数据治理的核心能力。Palantir 实现了从原始数据源到最终消费的完整链路记录：
前向追踪：从源数据向下追踪到所有消费方，了解数据被谁使用。
后向追溯：从最终指标向上追溯到原始来源，回答"这个数从哪里来"。
影响分析：修改上游 Dataset 后，自动列出所有受影响的下游。
变更通知：上游变更时自动通知下游维护者。
示例血缘链路：
Palantir 的权限管控是三维独立检查，任一维度不通过即拒绝访问。这不是"或"的关系，而是"且"的关系：
用户所属的角色
PlantManager / Analyst / Viewer / Admin
示例：产线经理才有权创建生产订单
对象/字段的安全等级
Public / Internal / Confidential / Secret
示例：工资字段定级 Confidential，仅 HR 可读
访问的业务目的
日常运营 / 审计 / 数据科学
示例：数据科学家可读脱敏数据但不能看 PII
🔒 细粒度权限到字段级：支持 Dataset 级、ObjectType 级、Property (字段) 级、LinkType 级、ActionType 级，甚至行级（Row-Level Security）权限控制。所有写入操作强制记录审计日志，与数据写入在同一事务内完成——"不存在改了但没留痕的中间态"。
将业务知识转化为 Ontology 平台可执行的语义层，分为三个明确的步骤：
列出 50 个核心指标 → 跨部门对齐口径 → 白纸黑字文档化。这一步解决的是"同样一个词，不同部门理解不一致"的问题。
示例："毛利" = 销售收入 - 成本；"华东区" = region_id IN (101, 102, 105)
将清洗后的指标定义翻译为 Function 或 Transform 代码。每个指标都有明确的计算逻辑，可验证、可复现。
示例：Function marginRate = (sales - cost) / sales
将逻辑存入 Ontology 平台，成为 Agent 的"字典"。Agent 查询时不是猜测，而是查字典——这正是零幻觉的根基。
结果：所有应用和 Agent 共享同一套语义定义，确保"看到的一致、操作的一致"。
| 传统方式 | Palantir 方式 |
|---|---|
| "我们要做数据治理" | AIP Agent 上线 |
| 业务部门不理 | 老板直接问数，Agent 报错 |
| 推不动 | 业务部门紧张，主动配合治理 |
| 数据质量持续恶化 | 数据质量在"使用"中提升 |
"用 AI 应用驱动数据治理，用业务结果反向要求数据质量。"
这是一个被反复验证的策略：当数据治理是 IT 部门单方面推动时，业务部门没有动力配合；但当 AI Agent 的准确率直接影响业务结果时，数据质量就变成了业务部门的切身利益。这便是"以用促治"——不是先治理好再用，而是在使用中倒逼治理。