Palantir × Databricks：让数据与计算各归其位的双向集成

摘要

Palantir 架构师 Chad Walquist 与 Databricks 架构师 Ben Abood 共同介绍了两家公司的产品级伙伴关系。核心理念是「Databricks 与 Palantir 合在一起更好」（better together）：更快获得价值，意味着减少数据搬运、安全共享数据、与 Unity Catalog 深度集成、让你在跨平台时自由选择计算与存储运行时。这是一场由客户驱动的集成——两家公司有大量联合客户，2024 年 11 月高管们会面时，客户们反复提出的诉求是：「Palantir 和 Databricks 都在我的生态里扮演关键角色，但并排部署时有摩擦——我想减少数据移动、在平台间保留一份数据、安全共享、灵活选择用哪个平台的哪个工具。」

伙伴关系围绕四根产品集成支柱：数据联邦（data federation）、治理集成、计算下推/计算联邦，以及 AI 与工作流集成。技术底座是 Palantir 的「多模态数据平面」（MMDP）：任何存储、任何计算、任何位置。双向集成意味着可以把 Palantir 的 Iceberg REST 目录直接注册进 Databricks，也可以把 Databricks 的数据通过虚拟表（virtual table）注册进 Foundry——两者都不需要物理搬运数据。治理侧用服务主体（service principal）与工作负载身份联邦（workload identity federation）免密钥认证，Unity Catalog 向底层云存储直接发放读写凭据，性能显著提升。目前已有 100 多家联合客户在使用该集成，多数使用虚拟表/数据联邦能力。

现场演示展示了「在 Foundry 中编写、在 Databricks 中运行」：在 Pipeline Builder 里对联邦表做过滤转换，预览实时回查 Databricks，计算跑在 Databricks serverless 上，输出直接写回 Unity Catalog——全程零数据移动，而日志、构建报告都是 Foundry 中的一等公民。Ben 强调：「这不是事后加装的补丁，也不是普通的 JDBC 连接——这是 Palantir 与 Databricks 的一等集成。」

正文

一、伙伴关系的四根支柱：数据联邦、治理、计算下推与 AI 工作流

Chad 开场点明合作的最终目标：消除两个平台之间的摩擦，让客户更快获得价值——减少移动数据的次数、安全地共享数据、真正把 Unity Catalog 与 Palantir 集成起来、在平台间自由选择计算与存储运行时。他特别强调，这是一场「客户驱动的集成」：两家公司有大量联合客户。大约去年（2024）11 月，几位高管聚在一起聊到：联合客户一直在问「Palantir 和 Databricks 怎么更好地协同」——两家都在他们的生态中扮演关键角色，但并排部署时有摩擦。客户的具体诉求包括：减少数据移动、在两个平台间只保留一份数据、安全共享、以及在「何时用哪个平台的哪个工具」上拥有更多灵活性。

于是双方决定建立伙伴关系，构建一流的（first-class）产品集成，通过改善平台互操作性帮助客户更快实现价值。合作围绕四根支柱：数据联邦、治理集成、计算下推（compute pushdown，又称计算联邦）、以及 AI 与工作流集成。双方于 3 月（3 月 13 日）正式宣布合作，产品集成工作在此之前就已启动。

Chad 强调「双向」（bi-directional）是这次合作的关键词：不是单向「连过来拉数据」，而是同步的双向集成——数据在 Databricks 中可以注册进 Palantir，在 Palantir 中创建的数据也可以注册进 Databricks，来回无缝移动，全部处于统一目录与治理之下。人们真正想要的是减少搬运、复制与创建管道的次数——那些都在拖慢你。最终目标是消除摩擦，更快实现为企业增值的用例。

二、多模态数据平面：任意存储、任意计算、任意位置

Ben 解释了「多模态数据平面」（MMDP，Multimodal Data Plane）：Palantir 网站上近期大量提及的概念，含义是「任何存储、任何计算、任何位置」。在伙伴关系语境下，它就是 Palantir Foundry 与 AIP 加上 Databricks 开放数据智能平台（open data intelligence platform）。

由于是双向集成：一部分数据会驻留在 Foundry（工作流数据，或 Palantir 对某些数据源有很好的连接器）。如果你想在 Databricks 中访问这些数据——最近开始，你可以把 Palantir 的 Iceberg REST 目录直接注册进 Databricks，无需移动数据即可访问。反方向：你正在用 Databricks 的开放湖仓，摄入了一批数据源、建好了 medallion 架构，但想在 Foundry 中把这些数据用于工作流或本体论应用——你可以通过虚拟表把数据注册进 Foundry，同样不需要在网络上物理搬移数据。

价值差异化在哪里？Chad 指出：如果数据集成与管道工作已经在 Databricks 中完成，那么下一步自然是构建运营应用（operational applications）——把不只是数据、还有逻辑与行动建模进本体论，驱动跨业务的集成工作流。这带来了两个世界的精华：前端是 Palantir 构建运营应用的能力，后端由 Databricks 提供企业级计算与存储。更酷的是，你甚至可以在 Palantir 中（包括平台内的低代码工具里）编写管道，却让存储与计算跑在 Databricks——「编写在 Palantir，运行时选择 Databricks」。组织中可能有 Palantir Foundry 专家在 Pipeline Builder 与代码仓库中继续编写管道，但计算可以运行在数据所在之处：「联邦了数据，也联邦了计算」——回到最小数据移动的核心概念。

三、治理集成：服务主体、工作负载身份与 Unity Catalog 凭据发放

治理集成目前围绕「连接级」展开：在 Palantir Foundry 中建立到 Databricks 的连接时，选择要连接的 Databricks 工作区、目录、schema 与表，并在 Foundry 侧为该连接配置访问 Databricks 的凭据。推荐方案是服务主体（service principal）加工作负载身份联邦（workload identity federation）：在 Databricks 侧创建服务主体，授予其「希望联邦给 Palantir 的数据资产」的访问权，再把它挂到 Foundry 内的 Databricks 源上。当 Foundry 与 Databricks 认证时，会以该服务主体身份、使用工作负载身份联邦——无需任何密钥即可访问 Databricks API；来自 Foundry 侧的所有数据访问都按该服务主体的权限执行。

数据联邦的实际机制是：Unity Catalog 可以向底层数据资产「发放凭据」（vend credentials）。比如数据资产存放在 S3 某处：Foundry 用服务主体向 Unity Catalog 认证并请求「我想联邦某个目录/schema/表名的数据资产」，Unity Catalog 先检查权限、确认可联邦，然后向该云存储位置发放直接读写凭据——Foundry 于是直接读写 Delta、Iceberg 或 Parquet 文件实际所在的 S3 桶。这带来巨大的性能提升：不再需要穿过多个层，Unity 统一发放凭据、直接访问联邦数据。Ben 补充，目前使用该集成的联合客户已超过 100 家，多数在使用虚拟表或数据联邦能力。

另一个关键能力：本体论对象可以直接由 Databricks 中的表支撑，并且支持写回（write back）。构建运营应用时常需要捕获工作流中的反馈：过去要落在 Foundry、再建一条管道搬回 Databricks；现在可以直接写回 Databricks——如果后续要在 Databricks 上做报表或其他工作流，「数据就在那里」。这种集成消除了层层管道：「不用建管道把数据带进来构建本体对象，再建一条移回 Databricks」——更少环节意味着更少可坏的东西、更快的价值实现。AI 与工作流支柱还包括模型：数据科学团队在 Databricks 训练的模型可以直接注册进 Foundry、作为工作流的一部分使用；既可以让模型托管在 Databricks、在 Foundry 中使用，也可以把模型带入 Foundry 托管——整个架构都有可选性。

四、现场演示：在 Foundry 中编写、在 Databricks 中运行

演示从 Foundry 的数据连接设置开始：已配置好 Databricks 连接。传统方式「批同步」（batch syncs）是把数据从环境拉进 Palantir；「虚拟表」则是新能力——把 Databricks Unity Catalog 中的数据直接注册进 Palantir 使用。点击创建虚拟表，系统读取 Databricks 的 schema 信息，搜索「DBX customer clone」数据集并预览数据，添加并创建虚拟表。打开这张表，它看起来就是普通的 Foundry 数据集，但有几处关键不同：来源标注为 Databricks；表详情显示这是 JDBC 连接——通过 warehouse 到 blob store，即 Databricks 正在向 Foundry 提供数据；而如果是「外部访问」（external access）类型，则表示由 Unity Catalog 发放凭据并给出 S3 位置。Foundry 里甚至有「在 Databricks 中打开」按钮，直接跳转到 Databricks 环境中的同一张表。

接下来在 Foundry 中对该表做点事：探索数据、创建新管道（DBX demo）。当选择「外部」（external）运行时，这就是一条批处理管道，将运行在 Databricks 环境中——存储与计算都位于 Databricks。选好源、做基本转换：过滤行、选州列、等于「CA」（加利福尼亚）、应用。构建过程的亮点：预览也是真实回查 Databricks——使用转换、取回结果集，沿管道给出实时预览。然后创建新表，选择它要驻留在 Databricks 的位置：可以是托管 Delta（managed delta）、托管 Iceberg 或外部表——你有这种可选性。保存、部署（第一次部署报了个小错误，修复后重试成功），作业执行并创建名为 dbxdemo 的表；在 Foundry 里可以像往常一样查看构建报告与部署历史——但这次实际执行发生在 Databricks 中。

回到 Databricks 更新目录，找到那张只有加州数据的表。Ben 总结整个闭环：Chad 展示了 Databricks 连接器，那张表在 Databricks；把数据资产联邦到 Foundry（选择 customer clone 数据集，没有摄入数据，只是虚拟化/联邦化）；Chad 用大家熟悉的 Foundry 工作流（Pipeline Builder）执行转换；计算跑在 Databricks serverless 上；输出数据集直接写回 Unity Catalog——全程零数据移动：从 Databricks 读数据、在数据所在处用 Databricks 计算、输出直接回写 Unity Catalog。而日志与构建在平台内实时可见，「是 Foundry 中的一等公民」。管道里本可以 join 多张表，但核心思想已经展示：在 Foundry 编写，整体下推给 Databricks 承担计算与存储。这不是临时补丁或事后想法，不是「到另一个数据源的 JDBC 连接」——这是 Palantir 与 Databricks 的一等集成。