1. 分层混合存储架构
Palantir 的存储不是单一数据库，而是按职责分层的混合架构。Ontology 的"图"是逻辑层概念，物理层是列存 + 关系索引的组合。
| 层级 | 技术 | 角色 | 为什么选它 |
|---|---|---|---|
| 元数据 | PostgreSQL | OMS 类型定义存储 | 强一致性、Schema 演化、成熟稳定 |
| 全文搜索 | Elasticsearch | 对象属性搜索索引 | 分布式全文检索、聚合分析 |
| 图遍历 | 自研图索引引擎 | Link 关系加速遍历 | 预计算邻接表 > 运行时BFS（快10-100x） |
| 对象存储 | Iceberg / Delta Lake | OSv2 列存物理层 | 分区快照隔离、时间旅行、Parquet 列存 |
| 事务引擎 | AtlasDB（自研） | 不可变文件系统 | ACID + Append-Only + COW |
| 缓存 | Redis / Caffeine | 热查询结果缓存 | 减少 OSv2 压力，毫秒级响应 |
| 消息队列 | Kafka / Pulsar | 流式数据管道 | Pipe 增量同步、事件总线、Action 事件分发 |
为什么不直接用 Neo4j？ 图数据库在处理 PB 级企业数据时性能不足；大多数查询是"列表过滤"而非"图遍历"，列存（Parquet）对此更优。关系索引（预计算邻接表）在绝大多数场景下比运行时图遍历快 10-100 倍。
2. 图门控机制
"图做门控"是指 Ontology 的 LinkType 关系图本身充当访问控制和查询路由的门控机制。不是先查数据再过滤，而是在查询路径上层层把关。
三层门控
| 门控层 | 检查内容 | 失败后果 |
|---|---|---|
| LinkType 门控 | 从 A 类型到 B 类型是否存在关系路径？ | 查询无法执行，返回空 |
| Classification 门控 | 路径上每个对象/字段对当前用户可见？ | 不可见节点从结果中透明过滤 |
| Action 门控 | 沿图路径的操作是否符合 ActionType 权限契约？ | Action 调用被拒绝 |
执行原理
关系索引采用预计算邻接表（列存格式）而非运行时 BFS。权限掩码作为位图过滤器在索引查找时注入，返回的是"用户视角的子图"，不是完整图。单个查询的图遍历深度有上限，防止深度递归拖垮性能。
3. 端到端数据路径
场景一：供应链库存告警 → 自动补单
阶段1 (流式接入): WMS → Kafka → Raw Dataset (Parquet) → Incremental Transform (5min)
阶段2 (语义映射): Clean Dataset → Ontology 映射 → Object Data Funnel → OSv2/OSS
阶段3 (规则检测): Function(turnoverRate) 每小时计算 → 结果 < 阈值 → Subscription 触发
阶段4 (Agent 推演): AIP Agent 读取上下文 → 推理 → 准备 Action: updateSafetyStock
阶段5 (Action 执行): 参数校验 → 三维权限检查 → OSv2 原子写入 → 同事务审计 → SAP Webhook场景二：情报分析 → 关系图谱调查 (Gotham)
数据融合: 卫星图(目标检测) + 通信记录(实体解析) + 文本报告(NLP/NER)
→ Nexus Peering 实体解析引擎 → Ontology 对象图谱
交互调查: 分析师从 Person A → 沿 LinkType 扩展 → 图门控自动过滤涉密节点
→ 添加假设标注 → 导出情报报告场景三：制造产线数字孪生 → 预测性维护
IoT传感器 (1000条/s) → MQTT → Kafka → Spark Structured Streaming
→ ML模型异常检测 → AIP Agent 激活 → Ontology 上下文查询
→ What-if 对比 (停工/降速/坚持) → 推荐方案 → Action: scheduleMaintenance → MES工单4. 本体融合过程
面向结构化数据系统
连接器注册 → Schema自动发现 → Raw落盘 (Iceberg/Parquet) →
人工语义映射 (table→ObjectType, column→Property, enum值映射) →
Spark Object灌注 → 人工确认关系 (FK→LinkType) → 质量校验关键点：映射逻辑由数据工程师 + 业务专家共同定义，不是自动推断。Palantir 不做"魔法式自动关系发现"——它提供工具，领域知识必须由人输入。
面向文本/非结构化数据
文档摄入 (PDF → Apache Tika → 纯文本, 扫描件 → Tesseract OCR)
→ NLP Pipeline:
1. NER 实体识别 (预训练模型 + 领域词典)
2. RE 关系抽取 (依存句法 + 规则)
3. Event 事件抽取 (触发词 + 论元角色)
4. Nexus Peering 实体解析 (模糊匹配 + 上下文消歧)
→ 人工审核界面: 确认/拒绝/修正抽取结果
→ 关联已有 Ontology 对象 → 创建新关系 → 同步图谱5. 人工介入模式
| 层次 | 角色 | 活动 | 是否可自动化 |
|---|---|---|---|
| L1: 建模层 | Ontology 建模师 + FDE | 定义 ObjectType/LinkType/ActionType，语义映射 | ❌ 不可自动化 |
| L2: 运营层 | 业务分析师 + 数据工程师 | 创建管道、配置监控、编写 Function | ⚠️ 部分可模板化 |
| L3: 决策层 | 业务决策者 | 审核 AI 建议，确认/修改/拒绝 Action | ❌ Human-in-the-Loop 设计如此 |
典型人工介入场景
场景1: Ontology 建模 (空客案例)
Palantir FDE 嵌入客户现场数周，与业务专家逐条讨论"飞机如何定义""零件如何关联""维护流程是什么"。每次数小时到数天的领域知识提取，迭代建模，试错调整。这不是"配置"，而是将业务隐性知识转化为显性语义模型的过程。
场景2: 情报实体解析审核
NLP Pipeline 输出 "Ahmad Al-Rashid" (confidence 0.78)，人工审核界面展示 3 个可能匹配的历史人物档案。分析师根据上下文判断选择 P-3391 "Ahmed Al-Rashid" (85%匹配)。点击确认 → 同步创建 Audit 记录。
场景3: AIP Agent 风险分层审批
低风险 (< 1万元影响): 自动执行，事后通知
中风险 (< 10万元影响): ActionType.requireApproval = "single"
高风险 (> 10万元影响): ActionType.requireApproval = "dual"
紧急决策: 自动执行但必须事后有人确认场景4: 数据口径对齐会议
财务的"毛利率" ≠ 中台的"毛利率" → 2小时跨部门会议 → 逐条核对50个核心指标口径 → 白纸黑字"语义口径手册" → FDE 修改 Function 代码 → 双方签字确认。这是最繁琐但最不能省略的人工介入。
核心结论：Palantir 不是即插即用的 SaaS，它是高度依赖人工服务的平台。Ontology 的价值在于将人工知识一次性结构化沉淀，让后续查询和决策可以自动化，但初始的知识注入和建模必须有大量人工参与。FDE（Forward Deployed Engineer）嵌入式服务是 Palantir 商业模式的核心。