架构哲学:数据操作系统
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 区别于传统数据平台的真正壁垒所在。
四层架构全景
🔧 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 自动归档/删除
🏗️ 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 定义的事,权限在建模时就锁死
📥 数据集成层 — 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 延迟)
- 联邦查询:不落地数据,按需查询外部系统
🏭 六大行业解决方案
- 国防与情报: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 定义时即绑定,不依赖上层的应用代码。
📝
所有操作可追溯
不可变审计日志与数据写入在同一事务内完成,不存在"改了但没留痕"的中间态。