摘要

  • BigQuery 对受行级安全保护的表进行预演时，始终返回零字节；Google 明确说，这种结果不能用来估算查询成本。
  • 查询后的部分计费统计也会被隐藏。企业若把空白填成零，得到的是一张更整齐、却更不可信的内部成本表。

财务最喜欢的数字，有时恰好是财务最不该相信的数字。

在 BigQuery 中，对受行级安全保护的表做一次查询预演，返回的处理量是零字节。这个零很漂亮：容易展示，方便汇总，还能让预算看起来相当克制。Google 给它安排的工作却是保密。为了防止有人从查询所需处理量反推受保护数据，系统把这扇窗关上了。

这里有两件事同时成立。预演本身免费，也不占用查询计算槽位；随后真正执行的查询，仍须按所采用的计费模式处理。Google 的查询说明直说，行级安全场景下不能依赖预演估算成本。一个被设计成不透露信息的零，到了预算表里，不能突然变成报价。

隐私关上窗，成本还在屋里

行级安全解决的是一张表中谁能看哪些行的问题。同一份数据，可以让不同业务人员只看到各自获准访问的部分。麻烦在于，查询结果之外还有线索：处理了多少数据、花了多长时间、报了什么错，都可能透露被遮住的内容。

因此，BigQuery 隐藏的并不只有预演数字。行级安全最佳实践列出的受限统计，包括处理的字节数与分区数、计费字节数以及查询计划阶段。查询已经跑完，也不等于分析人员就能拿到完整的成本证据。

这会直接碰上企业常做的一件事：按团队、用户或项目分摊云费用。官方的 INFORMATION_SCHEMA.JOBS 说明指出，查询读取带有行访问策略的表时，total_bytes_billed 和 total_bytes_processed 两个字段的值为空。它们不是记录了零消耗，而是没有向这条查询统计路径交出相应数字。

官方成本估算示例也把边界写得很实在：可以数出可能受行级安全影响的作业，却拿不到这些作业的计费用量。知道有多少张遮住的收据，算不出收据上的总额。

设想一家公司把空值统一补成零，再按用户排出“最节省查询成本”的榜单。这个例子里的名次会偏爱统计缺失的工作负载。奖状可以打印，节省却没有被证明。错误发生在公司自己的报表转换里，保密机制甚至可能从头到尾都在正常工作。

给财务开门，也会给数据开门

通常，报表缺数据，组织的第一反应是找权限更高的人。这里不能把权限当万能钥匙。

Google 说明，项目所有者能在相关审计日志中看到处理字节数，但作业详情里的这类计费元数据仍不显示，也没有某个专门权限或角色能把它们直接解锁。与此同时，Cloud Billing Viewer 可以查看账单信息。两者是不同的信息入口，不能混成“管理员什么都能看”。

更尖锐的是，Google 建议不要给本来只应看到过滤后数据的用户授予这类账单可见权限。费用本身可能成为敏感信息的出口。企业想让每个业务经理对成本负责，却又不能把所有成本线索发给每个业务经理，这个矛盾需要有人真正负责。

所谓“透明管理”，到了这里必须说清楚透明给谁。获准核对整体账单的人、需要理解自身预算的人、只能访问部分业务数据的人，未必应当是同一群人。把三个身份塞进一个权限组，省下的是审批步骤，交出去的可能是数据边界。

看见的行少，未必读得便宜

行级权限还有一个容易被商业直觉误读的细节：眼前的数据少，不代表背后处理量按相同比例减少。

Google 明确说明，行访问策略中的过滤条件不参与分区表或聚簇表的裁剪。即使策略引用了分区列，也不会因此获得对应的分区裁剪收益。查询自身的过滤条件与访问策略承担不同工作；把“这个人只能看一个区域”写进权限，并没有顺手替他买下一张同等比例的折扣券。

BigQuery 定价规则又把成本责任放在实际发起查询的项目上：查询共享数据时，查询费用记在查询项目关联的结算账户，而不是因为数据归别人所有，就自动由数据所有者付款。能看到多少、处理多少、谁来付钱，是三条需要分别核对的线。

按需模式按处理字节计费，容量模式按计算容量及使用时间计价。拿一个零字节预演去证明两种模式都没成本，等于让一个沉默的仪表替整间机房报销。

Google 的成本控制说明提供按需查询的日配额和单次最大计费字节设置。这些是实际控制项，遮蔽后的预演数字不是控制项。所查文件没有交代最大计费字节设置与该零字节估计之间的全部执行细节；具体工作负载需要经过授权的验证，不能靠这个零推定限额一定放行或一定兜底。

文章所依据的是产品规则，没有某家客户的真实账单和内部核算记录。要把预算错配算成金额，需要这些记录。机制已经足够清楚：保密让部分成本证据暂时离开了使用者的视线，组织仍然得付钱、分账，并解释钱去了哪里。

把空白留为空白，是最便宜的一步。接下来才是管理真正值钱的部分：指定有权核账的人，给无法精确归属的费用安排明确责任，向业务团队提供适合其权限的预算反馈。隐私可以藏住仪表，不能顺手藏掉负责仪表的人。