Databricks Backstage 让 FinOps 一条查询搞定，但难点转移到了上游

Databricks 已完成由三部分组成的 Backstage 实验，并得出一个引人注目的结果：一条查询即可将基础设施归属与每日 Lakebase 消耗关联起来。databricks backstage 设计消除了通常将平台工程与 FinOps 分隔开的集成边界。不过，它也暴露出对准确服务元数据更棘手的依赖。

该演示将 Backstage 的实时软件目录与 Databricks 计费记录直接连接，无需先将两个数据集迁移至独立的报表系统。FinOps 分析师可以通过一条 SQL 语句识别 Lakebase 资源、找到其负责人并查看其使用情况。

这比又一个仪表盘集成更具影响力。Backstage 通常保存运营归属数据，而数据仓库存储成本记录。团队通过 ETL 作业、导出、工单和人工维护的映射将这些系统连接起来。

这一新方法以联邦查询替代了其中大量的数据迁移；联邦查询通过共享 SQL 层跨系统查询数据。然而，它并未消除成本分摊背后的组织工作，而是将其转移到目录注解、资源标识符、访问控制和计费语义中。

Databricks Backstage 实验实现了其 FinOps 价值

第三个实验将 Backstage 的归属关系图谱转化为云成本分析的直接入口。

在整个系列中，Databricks 与 Thoughtworks 使用了 Backstage——Spotify 的开源内部开发者门户——作为运营应用。Backstage 维护的软件目录包含服务、组件、负责人、依赖关系和基础设施引用。

团队将门户的 PostgreSQL 状态迁移至 Lakebase，即 Databricks 的托管 Postgres 服务。Lakebase 将存储与计算分离，并将事务数据与更广泛的 Databricks 环境集成。

第一部分聚焦数据库分支。作者称，Lakebase 大约可在一秒内创建一个数据库分支。这使得团队能够在修改生产数据库之前，针对隔离副本测试 Backstage 迁移。

第二部分将运营数据库纳入 Unity Catalog，即 Databricks 面向数据和 AI 资产的治理层。这一步让 Backstage 数据库能够通过与分析数据相同的控制平面被访问。

第三部分将此前的改造应用于 FinOps。其核心查询将 Backstage 记录与 Databricks 的系统计费表结合起来。

Backstage 一侧使用 final_entities，这是一张包含目录已处理实体记录的表。每个相关实体均包含 databricks/project-id 注解，用于标识其 Lakebase 项目。

计费一侧使用 system.billing.usage，该表记录可计费的 Databricks 消耗。查询将目录注解与 usage_metadata.project_id 匹配，然后筛选 Lakebase 使用情况。

已发布的示例按 Backstage 资源名称、Lakebase 项目 ID 和日期对消耗进行分组。其示例输出将 2026 年 4 月 8 日的 39.8667 DBU 和 4 月 7 日的 43.6231 DBU 归属到相应资源。

DBU，即 Databricks Unit，是用于表示平台处理消耗的标准化计量单位。该查询报告的是 DBU，而不是最终的货币费用。

这一差异很重要。该演示证明，使用量可以归属到目录中登记的资源。但它并未建立一个涵盖各类折扣、承诺、调整或共享费用的完整核算模型。

即便如此，它仍缩短了常见的 FinOps 调查流程。分析师不再需要在将服务归属导出结果与仓库计费数据比较之前，先申请服务归属数据导出。

这一结果还将成本信息连接到开发者本已用于发现服务的位置。这为按系统、团队或产品而非仅按云资源名称组织成本视图创造了路径。

因此，这一系列的终点与起点有所不同。数据库分支改善了工程工作流。统一治理随后使运营状态可被查询。最后一步则将这些技术变化转化为一种组织报表机制。

为什么一条查询改变了平台团队的角色

关键变化不在于 SQL 更短，而在于消除了平台、数据和财务团队之间反复进行的协调。

典型的内部开发者门户会回答诸如谁负责某项服务、哪个代码仓库包含它，以及哪些基础设施支持它等问题。计费系统则回答某个资源产生了多少计量消耗。

这些答案往往使用不兼容的标识符。开发者认识名为 checkout-api 的服务，而云账单呈现的却是账户、项目、集群或不透明的资源 ID。

FinOps 团队通过标签、分配规则、报表模型和人工审查来处理这种不匹配。FinOps Framework 将分配视为核心能力，因为未分配的成本会削弱问责机制和预测能力。

Backstage 为这一过程提供了潜在的归属层。其目录已将软件实体与团队及基础设施关联起来。挑战在于，如何可靠地将这些关联与计费记录连接起来。

Databricks 的实验将这种连接置于数据平台之内。Lakehouse Federation 是一项无需传统数据摄取即可查询外部或运营数据源的能力，它让实时 Backstage 目录与系统计费数据并列呈现。

这种方法减少了专用管道的需求，无需再将归属记录复制到数据仓库中。它也避免了在解决成本问题前，还要等待该管道下一次计划运行。

计算分离是该方案的核心。Lakebase 可以处理 Backstage 的事务请求，同时由另一项计算资源对相关数据执行分析查询。

Databricks 将 Lakebase Postgres 描述为支持自动扩缩容、按需缩容至零、分支、只读副本和即时恢复，同时还可与 Unity Catalog 和 Databricks Apps 集成。

该架构旨在保护门户不受分析师工作负载影响。大型聚合不应仅因两者引用相同的底层状态，就直接与 Backstage 的交互式请求竞争。

这种分离改变了平台团队能够提供的能力。他们可以将归属和消耗视为同一资源图谱的两个视图，而不是经过多次交接后才连接起来的两个数据集。

FinOps 分析师获得了从成本直达责任人的路径。平台工程师获得了关于哪些内部服务消耗 Lakebase 容量的证据。工程负责人则获得了团队级报表的潜在基础。

开发者也将面对更清晰的责任。当目录条目中的标识符决定基础设施消耗被归属到哪里时，它便不再只是文档。

这一转变促使平台团队提升目录质量。他们必须决定哪些注解是必填项、如何验证标识符，以及资源在负责人之间转移时应如何处理。

数据团队也面临相关变化。他们仍负责受治理的访问和计费语义，但不再需要负责连接运营元数据与分析记录的每一条集成管道。

FinOps 团队同样需要适应。更快的访问并不会消除他们定义分配政策的需求，而是让他们能够在更贴近当前运营模型的位置应用这些政策。

因此，回报在于劳动分工的改变：平台工程维护可信的归属图谱，数据平台提供受治理的联接能力，FinOps 定义如何将消耗转化为问责。

这一安排具有吸引力，因为它消除了等待；但它也要求更高，因为归属图谱中的错误如今会直接流入财务报表。

其机制是联邦查询，而非新的成本数据库

Databricks 将联邦查询定位为一种替代方案，用于取代将运营目录数据复制到另一个成本报表存储中的做法。

核心查询从 Backstage 的已处理实体表开始。Backstage 在从 YAML 文件、插件或外部系统等来源摄取并规范化目录定义后，会创建这一表示。

软件目录 将实体视为描述组件、系统、API、资源、群组和用户的元数据记录。关系将这些实体连接为归属与依赖关系图谱。

在该实验中，Backstage 资源在注解中包含 Lakebase 项目标识符。SQL 查询从实体的 JSON 文档中提取该标识符。

随后，它将该标识符与计费表中的项目元数据联接。按资源、项目和日期分组后，便可产生人们能够理解的归属结果。

这一机制具有三个重要特性。

首先，运营记录仍保持为运营记录。Backstage 继续使用 PostgreSQL 进行正常的目录活动，而无需等待分析副本接受更新。

其次，计费记录仍保留在 Databricks 系统表中。该演示不要求分析师在使用之前执行自定义导出。

第三，联接在受治理的查询环境中发生。Unity Catalog 可以控制参与对象的发现与访问。

Databricks 将其称为零数据移动。更准确地说，用户无需在运行分析前构建独立管道来物化另一份联接后的数据集。

查询执行仍会在相关接口之间传输请求和结果。联邦查询也依赖连接器、凭证、元数据和性能控制。

这一细微差别并不会抹去其优势。它只是阐明了 ETL 管道消失后，复杂性会转移到哪里。

传统管道通过转换代码表达映射关系。联邦设计则通过置于 Backstage 实体上的注解来表达关键映射。

这种映射更容易被看到，但也更容易被忽略。如果注解缺失或不正确，查询便会失去资源与负责人之间的连接。

成熟的实现方式会在目录摄取期间验证该注解。它可以拒绝格式错误的项目标识符，或标记引用不存在 Lakebase 项目的实体。

团队还需要制定生命周期规则。被删除的服务、已转移的应用或更名的项目，都可能带来仅凭当前目录快照无法回答的历史归属问题。

对于成本分摊而言，时点归属尤为重要。当前负责人不应自动承担服务转移前产生的消耗。

该演示按日分组提供了一个起点，但历史分配需要持久化的归属历史。团队可以保留目录变更、计费快照或按生效日期维护的映射表。

访问控制则带来另一项设计决策。工程师可能需要查看自己负责的服务，但无需获得对全企业计费记录的不受限访问。

Unity Catalog 可以帮助定义权限，但每个组织都必须确定适当的粒度。相比授予对底层系统表的广泛访问权限，团队范围的视图可能更为安全。

性能同样值得关注。示例查询很简洁，但生产环境中的 Backstage 目录可能包含大量实体和庞大的 JSON 记录。

反复从 JSON 中提取数据，在规模扩大后可能效率不足。团队可以通过精选视图公开特定注释，同时保持源目录不受影响。

这种优化仍能保留更广泛的模型。区别在于，受治理的语义层将位于实时运营数据之上，而不是采用相互脱节的导出管道。

因此，databricks backstage 架构并未取消数据工程，而是将工程工作集中在元数据契约、访问策略和查询接口上。

只要组织愿意接受更严格的目录治理纪律，这就是更具战略价值的工作位置。

真正的对手是 ETL 交接环节

该实验挑战的是以管道为先的集成模式，而不是 PostgreSQL 竞品或其他开发者门户。

团队传统上会将在线事务处理与在线分析处理分离。事务系统优先支持高频、低延迟写入，而分析系统则会扫描和聚合规模大得多的数据集。

这种分离形成了两个运营领域。应用团队维护 PostgreSQL 等数据库，而数据团队则将选定记录复制到数据仓库或湖仓中。

这种架构是合理的，因为这些系统具有不同的存储布局、扩展模型和故障考量。直接进行分析查询可能会威胁应用性能。

现代云平台正日益将存储、计算和治理解耦。这让部分数据能够通过多条面向不同工作负载的计算路径访问。

Lakebase 正处于这一趋势之中。Databricks 将其定位为面向事务型应用的托管 PostgreSQL，同时可与湖仓数据保持近距离连接。

这项 Backstage 实验利用这种近距离连接，避免了专门的所有权导出。其主要替代方案并非另一家 Postgres 供应商，而是熟悉的流程：提取目录记录、转换标识符，再将其加载到报表模型中。

ETL 仍保有重要优势。物化数据集可以提供可预测的性能、持久化快照、质量检查，以及与源模式变更的隔离。

它也能够对来自多个门户或云提供商的数据进行标准化。针对单个 Backstage 数据库的联邦查询，未必能够覆盖拥有多个目录和计费环境的企业。

ETL 的成本体现在延迟和所有权上。必须有人安排管道运行、监控失败、更新模式、核对映射，并在用户不信任其输出时作出响应。

这些职责往往落在团队之间的空白地带。平台工程了解服务目录，数据工程拥有数据仓库，FinOps 则理解分摊模型。

联邦优先的方法减少了一些副本和调度任务。它使实时源数据可用，但也增加了对其可用性、模式、元数据质量和查询行为的依赖。

这正是核心权衡。ETL 与源系统保持距离，并吸收源端的不稳定性。联邦查询提供更高的新鲜度和更少的数据副本，但也让使用者更贴近运营变更。

正确选择取决于要支持的决策。交互式调查受益于最新的所有权数据；经审计的月度成本分摊则需要稳定的历史记录和可复现的规则。

对于大型组织，混合模式很可能成为常态。分析师可以通过联邦查询调查近期使用情况，再将获批的分摊结果发布到持久化报表层。

该模式并不会否定这一演示。它利用联邦查询降低探索性分析的摩擦，同时为正式财务流程保留物化记录。

其他托管 PostgreSQL 平台同样可以参与联邦架构。AWS、Google Cloud、Microsoft 和独立数据库提供商都提供了具备分析集成能力的事务系统。

Backstage 本身仍保持数据库中立。其对 PostgreSQL 的支持让组织能够根据运营、监管和商业需求选择基础设施。

Databricks 在该实验中的优势来自平台近距离集成。Lakebase、系统计费表、联邦查询和 Unity Catalog 均存在于同一受治理环境中。

这种便利也可能带来集中化风险。采用完整模式的团队会更依赖 Databricks 标识符、计费模式、权限和查询服务。

因此，文章带来的竞争压力主要落在碎片化的内部技术栈上。供应商和平台团队必须解释：当受治理的查询可以直达源系统时，为何仍有必要复制所有权元数据。

然而，Databricks 必须证明这张更简单的架构图经得起运营现实的考验，包括目录规模、模式演进、访问边界和月末报表需求。

单查询结果尚未解决的问题

一个成功的概念验证并不能保证企业成本分摊值得信赖，因为查询的正确性取决于计费系统之外的组织元数据。

示例结果表明，Backstage 资源能够与 Lakebase 使用情况匹配。它并未说明大型组织中有多少基础设施能够以这种方式分摊。

覆盖率是第一个未解问题。团队需要知道，相关 Lakebase 项目中有多少比例具备有效的 Backstage 实体和项目注释。

结果在技术上可以正确，却仍可能在财务上不完整。除非分析师另行识别，否则未纳入目录的项目会直接从以所有权为中心的查询中消失。

准确性是第二个问题。有效的项目 ID 仍可能指向错误的服务、过期的负责人，或支撑多个产品的共享资源。

共享基础设施使归属变得复杂，因为一个项目可能服务多个团队。单个 Backstage 注释无法表达每一项按比例分摊规则。

计费语义构成第三项限制。DBU 代表消耗量，但完整的成本视图可能还需要云基础设施费用、抵扣、承诺、税费和组织调整。

FinOps 团队必须决定该查询是用于成本展示、成本分摊、异常调查还是容量规划。这些用途需要不同级别的精确度。

历史所有权也是一个尚未解决的问题。实时目录天然更适合描述当前状态，而非过去的责任归属。

4 月 15 日发生的服务移交，不应必然改写 4 月 7 日消耗量的归属方。可靠的历史报表需要具备时间维度的所有权记录。

模式稳定性同样重要。该查询深入访问 JSON 实体，并依赖特定注释名称。团队必须将这个字段作为受支持的契约来管理。

Backstage 插件、目录处理器和组织惯例都可能改变实体结构。随着 Lakebase 发展，Databricks 也可能演进计费元数据。

生产用户应自动测试这些契约。验证作业可以识别缺失的注释、未知项目、重复分配，以及没有负责人的使用情况。

安全性带来了另一种压力。Backstage 元数据可能暴露内部系统和团队结构，计费数据则可能揭示敏感的消耗模式。

将两类数据集结合，会让单次查询可获得的信息增加。这有利于分析，但也会放大权限过宽的影响。

组织需要与其运营模式相匹配的行级或视图级边界。服务负责人可能只需要查看一个团队的使用情况，而中央 FinOps 则需要覆盖全企业。

运营依赖同样存在。联邦分析依赖于源数据库、查询服务、身份配置和治理层均保持可用。

Databricks 表示 Lakebase 为不同工作负载隔离计算资源。对于延迟、并发、故障恢复和可预测的分析性能，独立的生产证据仍然至关重要。

原始系列文章也遇到了身份验证问题。Lakebase 需要具有特定作用域的 OAuth 凭证，而不是传统的 Databricks 个人访问令牌。

在概念验证中，团队通过脚本刷新短期凭证。生产部署需要受支持的轮换流程，避免将刷新后的令牌存储在不安全的位置。

当团队附加 Lakebase resource 时，Databricks Apps 可以为应用服务主体创建 PostgreSQL 角色。这种托管路径比临时拼凑的本地刷新循环更合适。

更广泛的教训并非联邦查询消除了治理工作，而是它让治理在用户提出业务问题的那一刻变得可见。

只有当目录完整性成为运营指标时，databricks backstage 模式才能成功。缺乏这种纪律时，单查询 FinOps 可能给出快速却不完整的答案。

三项信号将验证该模式是否成立

下一阶段必须衡量采用情况、分摊覆盖率和生产可靠性，而不是庆祝一条简洁的 SQL 语句。

第一项信号是 Databricks、Thoughtworks 或 Backstage 社区是否提供可复用的实现。团队应关注是否出现得到维护的目录处理器、验证规则、仪表板或支持该模式的模板。

受支持的软件包将强化这样一种判断：该架构能够超越定制化演示。它应定义注释模式、凭证处理、权限和部署实践。

缺乏可复用组件将削弱这一主张。每个采用者都需要独立重建最容易出错的映射和控制措施。

第二项信号是真实目录中的分摊覆盖率。实用指标是：有多少比例的 Lakebase 使用量关联到当前有效、经过验证的 Backstage 实体和负责人。

在不断变化的生产环境中实现高覆盖率，将支持联邦查询作为实用的 FinOps 输入。持续存在的未分摊使用量则表明，元数据维护仍是关键约束。

覆盖率应与新鲜度和异常数量结合衡量。团队需要知道新项目出现得有多快，以及映射验证失败的频率。

第三项信号是混合工作负载下的生产行为。组织应衡量分析师针对大型目录运行联邦计费查询时的 Backstage 延迟。

稳定的门户性能将强化 Databricks 的计算隔离论点。查询中断、凭证故障或治理瓶颈，则会让关键工作流程更倾向于采用物化报表层。

one-query case study 提出了一个清晰假设：共享治理和隔离计算可以重新连接运营所有权与分析成本数据。

如今，团队需要证据来说明这一假设在多个账户、共享资源、服务移交和正式财务控制下将如何表现。

对开发者而言，眼下的行动很简单：将目录注释视为生产数据，验证基础设施标识符，并明确界定所有权变更。

对平台负责人而言，应当追问现有成本管道是出于当前需求，还是旧有架构约束。即便官方报表仍保持物化，联邦查询也可能缩短调查时间。

对 FinOps 团队而言，应在扩大使用范围前，先以已知分摊结果测试 databricks backstage 查询。重要的问题不在于一条查询能否运行，而在于当组织发生变化时，其答案能否始终保持完整、可解释且可复现。