数据平台卷完引擎，开始卷应用

数据平台的边界，正在被悄悄重画。

Databricks 宣布 Databricks Apps 正式 GA，并随之开放了一个此前只有少数客户内测时才触碰的能力：基于 on-behalf-of-user（代表用户执行）的权限感知授权。翻译成人话——应用不再是『应用自己的身份』去碰数据，而是『以当前使用者的身份』去碰数据，权限体系自动继承。

听起来是个技术细节。但在数据行业干了十几年平台的人都知道，这种『细节』往往是战略转向的路标：数据平台不满足于做引擎和存储了，它要把应用层也收进自己的版图。

📦 应用直接长在平台上，意味着什么

先还原一个真实场景。一家中型零售公司的数据团队，业务方要一个『门店库存健康度看板』：不是静态报表，而是能下钻到 SKU、能标注异常、能触发补货提醒的工具。传统路径是什么？数据团队在平台上跑数，把结果导出到某个 BI 工具或者另起一个 Web 服务，再想办法把权限、调度、监控拼起来。

痛点不在写代码，而在『平台之外的那一段』：部署在哪、鉴权怎么做、数据出不出平台边界、运维谁兜底。据多位从业者私下交流，这段『最后一公里』消耗的工程量，常常超过分析逻辑本身。

Databricks Apps 给出的答案是：开发者直接在 Databricks 平台上构建和部署数据与 AI 应用，不再把数据搬出去、不再另起炉灶搭一套运行时。数据留在原地，应用跑在数据旁边。

这不是简单的托管部署。往深一层看，它改写的是数据平台的产品定义——过去的数据平台是『供数方』，通过 SQL 接口、JDBC、BI 连接器把数据喂给外面的应用；现在的数据平台开始自己『长出』应用，把供数方和用数方的角色合并到同一个平台里。

产业逻辑其实很直白：数据和计算之间存在天然引力，谁离数据近、谁的权限体系能贯穿到底，谁在应用层就有成本和体验优势。引擎层的竞争已经卷到边际收益递减，应用层是下一个增量战场。

🔐 on-behalf-of-user：权限感知不是锦上添花

很多人会把 Apps 的 GA 理解为『平台多了个应用托管功能』，这个理解漏掉了本次发布真正的重心——on-behalf-of-user 授权。

拆开看。过去平台上的应用典型有两条权限路线：要么应用用一个高权限服务账号替所有用户查数，要么在应用里自建一套用户到数据的映射。前者是安全事故的温床——任何一个用户都可能看到本不该看的数据；后者是维护地狱——平台侧权限和数据应用侧权限两套体系，永远对不齐。

OBOU 授权把这两条路都堵死了：应用以最终用户的身份执行，用户在平台上能看到什么数据，通过应用就只能看到什么数据。权限感知内建于应用层，而不是外挂在应用周边。

这张图的关键在中间那一环：应用不再持有独立的『数据身份』。对做了多年数据安全的人来说，这是架构级的减负——审计时不用再回答『这个应用账号能看到哪些表』这种问题，因为答案就是『看它当前代表谁』。

对承担合规责任的企业，尤其是金融、医疗、政企客户，『行级权限能不能贯穿到应用界面』长期是数据应用落地的第一道门槛。这个 GA 把门槛从『应用团队自证安全』变成了『平台默认保证』，性质完全不同。

🗺️ 从 Dashboard 到 Data App，中间隔着什么

要看懂这个动作，得把它放回更大的时间线里。

• 2019 年前后：Streamlit、Gradio 等轻量应用框架兴起，『数据科学家顺手写个交互应用』成为流行叙事
• 2022 年：Snowflake 收购 Streamlit，把数据应用框架直接装进云数仓，开启『平台内长应用』的路线之争
• 2024 年：Databricks 在自家年度大会上推出 Databricks Apps，进入公测
• 现在：Apps 正式 GA，on-behalf-of-user 授权落地，权限感知成为默认能力

两家头部平台的动作高度一致，说明这不是谁的奇招，而是行业共识：数据消费的形态正在从『看报表』升级为『用应用』。

需求侧的变化推着平台走。AI 应用的爆发让『用数』变得五花八门：一个 RAG 问答机器人、一个特征查询工具、一个标注工作台，都很难塞进传统 BI 的模具。业务要的不是更漂亮的数据可视化，而是长在数据上的操作界面。

谁能承接这种需求，谁就占据了数据价值链的出海口。报表工具的市值故事大家都看过，应用层的想象空间只会更大——这是平台方下场最直接的商业动机。

🧱 平台边界的重划与生态张力

把镜头拉远，这一步棋重划的是数据栈的分层。

平台内应用和外部工具，从并列关系变成了有亲疏之别的两条路径。跑在平台内的应用，权限、治理、审计天然打通；外部工具则要走连接器、要做额外的身份映射。这条『亲疏差』本身就是竞争壁垒——数据不出平台、权限不出平台，粘性随之而来。

张力也随之而来。数据集成、BI、应用开发这一带的 ISV 生态，会重新评估自己与平台的竞合关系：你是平台能力的补充，还是平台要亲手吃掉的那一层？历史上每一代平台向上扩展时，这个问题都会重演一遍。

对自建数据平台的企业，同样有一个必须回答的问题：当应用层与平台耦合加深，迁移成本会同步上升。便利和锁定，从来是同一枚硬币。务实的选择不是拒绝，而是在架构上明确边界——业务逻辑尽量留在应用代码里，数据依赖尽量走标准接口，给未来留一扇门。

⚠️ GA 之后，工程现实还有几道坎

作为搭过实时管道和湖仓的人，我必须泼一点冷水：GA 不等于生产就绪的终局，落地上还有几件事要看清楚。

第一，OBOU 授权把权限下推到每一个用户身份，意味着高频应用场景下的权限判定次数会显著上升，权限引擎的性能与缓存策略，直接决定应用响应延迟。这在 demo 里看不出来，在日均百万次调用的生产环境里会暴露无遗。

第二，权限收紧后，应用可用的数据范围变窄了。过去靠服务账号『暗中』取到的聚合数据、跨域数据，现在都可能因为用户无权限而拿不到。据一线团队反馈， migrating 到权限感知模式后，很多历史应用的取数逻辑需要重写——这不是技术问题，是权限治理的历史欠账集中清算。

第三，成本模型变了。应用常驻运行，计算资源从『批处理按需拉起』变成『在线服务持续付费』，FinOps 的账要重新算。数据团队第一次要像业务研发团队一样关心 QPS 和可用性，组织能力也得跟上。

这些不是否定，恰恰说明这次发布是真的走向生产——真正生产化的能力，才会带来这些真实的痛。概念产品不需要操心成本和可靠性。

小结

Databricks Apps 的 GA 与 OBOU 授权，表面是一次产品发布，实质是数据平台对应用层的正式宣示：数据不出平台、权限贯穿到底、应用长在数据旁边。权限感知能力从可选项变成默认项，会倒逼整个行业重估『数据应用该怎么建、权限该怎么管』。

接下来值得盯两件事：一是 Snowflake 阵营如何回应，两家在应用层的竞争会快速拉齐水位；二是 ISV 生态的站队与分化。数据平台的上半场卷的是存储和引擎，下半场的胜负手，大概率落在谁能成为企业数据应用的默认落脚点。