四层架构设计

Palantir Foundry 采用技术架构、应用架构、数据架构、业务架构四层分层模型,通过 Ontology 语义层实现跨层统一协同,构建企业级数据操作系统。

架构哲学:数据操作系统

Palantir 的定位不是传统"数据平台",而是企业数据操作系统。这一架构的核心哲学是:"终点从来不是一份静态的报表或仪表板,而是触发一次有效的行动。"

与传统 BI 将"数据到洞察"作为终点不同,Palantir 将系统设计延伸至"数据→洞察→决策→行动→回流"的完整闭环。这决定了其四层架构必须是一个有机整体——技术层提供算力与存储、数据层保障质量与血缘、应用层支撑交互与可视化、业务层驱动决策与执行。

五层架构模型

Layer 5: 决策编排层
AIP Agent / Scenario Modeling / Workflow Automation
AI 驱动的智能决策与自动化闭环
Layer 4: 分析应用层
Workshop / Slate / Object Views / OSDK
低代码 + 专业开发双轨应用构建
Layer 3: 本体层 (Ontology)
ObjectType / LinkType / ActionType / Function / Audit
连接上下四层的核心语义枢纽
Layer 2: 模型层
Pipeline Builder / Code Repository / Dataset / Spark Jobs
数据处理、转换与版本管理
Layer 1: 数据层
Data Lake / Connectors / Magritte Framework / Streaming
多源异构数据的统一接入与持久化

💡 关键理解:Ontology(第三层)是承上启下的核心枢纽。向下对接数据层和模型层,将原始数据抽象为业务对象;向上支撑应用层和决策编排层,让应用和 Agent 基于统一的语义模型进行交互。这就是 Palantir 区别于传统数据平台的真正壁垒所在。

四层架构全景

1

技术架构

基础设施与平台运行底座

🔧 Apollo 部署平台

  • 多环境统一部署:公有云 (AWS/Azure/GCP) + 私有云 + 裸金属 + 隔离网络
  • 数百微服务生命周期管理、自动扩缩容、负载均衡
  • 基础设施即代码 (IaC),配置声明式管理、版本控制
  • 持续集成/持续交付 (CI/CD),平台更新零停机

⚡ 分布式计算引擎

  • Apache Spark 分布式数据处理,支持 Python/PySpark、SQL、Java、R
  • Build Service 任务编排与调度,解析 JobSpec 分配计算资源
  • 按团队/项目隔离计算资源,成本归因精细到单个 Job

💾 存储层技术

  • Apache Iceberg / Delta Lake / Parquet 列式存储
  • AtlasDB 自研事务性文件系统,提供 ACID + 不可变写入
  • 零拷贝克隆:克隆秒级完成,修改时写时复制 (COW)
  • 压缩比 5-10x,TTL 自动归档/删除
2

应用架构

用户交互界面与消费层

🏗️ Workshop — 低代码应用构建器

  • 面向业务分析师,拖拽式拖入 Widget 搭建应用
  • Widget 直接绑定 Ontology ObjectType,实时读写
  • 预置组件:对象表格、表单、图谱、地图、时间线、仪表盘
  • Action 按钮绑定 ActionType,点击即触发业务操作

🎨 Slate — 高级定制构建器

  • 面向前端/全栈开发者,JavaScript/TypeScript 完全控制
  • 自定义布局、复杂交互、条件渲染、动画
  • 完整 OSDK 访问权限,可嵌入外部组件

🔄 OSDK 多语言开发套件

  • TypeScript / Python / Java 三语言 SDK,原生 Ontology 访问
  • ObjectSet 可组合查询抽象:filter→orderBy→paginate→linkTo→aggregate
  • Function 和 Action 的程序化调用

🤖 AIP Agent — 自然语言交互界面

  • Agent 工具集 = Ontology 全部 ActionType + Function
  • 自然语言→语义理解→Ontology 查询→Action 执行
  • 安全边界:Agent 只能做 Ontology 定义的事,权限在建模时就锁死
3

数据架构

数据全生命周期管理

📥 数据集成层 — Magritte 框架

  • Push 模式:源系统主动推送 → Foundry 接收端点
  • Pull 模式:定时拉取 → 源系统 API/JDBC/REST
  • 支持 20+ 数据源类型:Oracle、SAP、Snowflake、Kafka、IoT

🔀 Pipeline Builder — 可视化管道

  • 拖拽式 DAG 编排:Connector→Transform→Dataset→Scheduler
  • 三种构建方式:Pipeline Builder (拖拽)、Code Repository (代码)、Contour (交互式)
  • 增量更新 / 全量刷新 / 事件触发三种调度模式
  • DAG 依赖自动解析,上游失败下游不触发

📋 Dataset — Git 式版本管理

  • 每个 Dataset 具备:数据文件 + Schema + 版本链 + 分支 + 血缘 + 权限
  • branch / commit / merge / tag / diff 操作完整支持
  • 开发分支从生产零拷贝克隆 → 修改 → 合并回主干

🌊 数据流模式

  • 批处理 ETL:定时同步,适合维度数据和日报
  • 流处理:Kafka → Streaming Connector → 近实时 (<60s 延迟)
  • 联邦查询:不落地数据,按需查询外部系统
4

业务架构

行业方案与决策闭环

🏭 六大行业解决方案

  • 国防与情报:Gotham 多源情报融合、目标识别、战场态势感知
  • 制造业:Airbus A350 全机队 10万+ 零件供应链秒级追溯
  • 能源:BP 全球数百油田到加油站的端到端数字化
  • 医疗健康:NHS 全国医疗资源调度、疫情响应
  • 金融服务:AML 反洗钱网络分析、欺诈检测
  • 供应链:端到端可视化、中断自动响应、库存优化

🔄 决策四步闭环

Sense (感知) → Understand (理解) → Decide (决策) → Act (行动)

👷 FDE 嵌入式实施

  • Forward Deployed Engineer 常驻客户现场数月至数年
  • 从 3-5 个核心数据源、50 个业务对象起步
  • 典型周期:Discovery (4周) → Data Onboarding (8周) → App Build (4周) → Go-Live & Iteration

🤖 决策自动化分级

  • L0 人工 → L1 辅助 → L2 建议 → L3 半自动 → L4 全自动
  • 低风险场景全自动闭环 (如库存自动补货),高风险保留人工审批

架构间的协作关系

四层架构并非孤立存在,而是通过 Ontology 本体层 实现深度协作:

技术架构提供运行环境 (Apollo 部署、Spark 计算) → 数据架构管理数据全生命周期 (接入→清洗→建模) → Ontology 将数据抽象为业务对象 → 应用架构为不同角色提供交互界面 → 业务架构驱动决策与行动闭环。

这一设计确保了:数据工程师在 Pipeline Builder 中定义的 Dataset 变更会将血缘自动更新到 Ontology;Ontology 建模师新增的 ObjectType 会被 Workshop Widget 和 AIP Agent 即时识别;所有应用的权限校验统一在 Ontology 层执行,不依赖各应用各自实现。

关键设计约束

🔒

LLM 不能直接操作外部系统

AIP Agent 只能通过 Ontology ActionType 执行操作,所有外部交互都经过定义好的契约边界。

🛡️

权限在建模时就锁死

三维权限模型 (Role × Classification × Purpose) 在 Ontology 定义时即绑定,不依赖上层的应用代码。

📝

所有操作可追溯

不可变审计日志与数据写入在同一事务内完成,不存在"改了但没留痕"的中间态。

← 数字孪生体系 下一篇: 数据治理与建模 →