4. 成本度量与分摊体系

在OLAP平台中，成本优化如果没有度量与分摊体系，就只能停留在“感觉贵”的层面。成本度量与分摊要解决三个问题：钱花在哪里、谁该为这笔钱负责、单位产出是否在改善。本节围绕成本中心划分、标签体系、分摊规则、单位成本计算和成本看板搭建展开，形成一套可落地的成本治理闭环。

一、成本中心划分：把账单拆成可归因的单元

成本中心是成本归集的最小管理单元。OLAP平台的成本通常由计算、存储、网络和调度四类资源构成，因此成本中心划分应同时覆盖资源维度与组织维度。常见的划分方式如下：

• 按资源类型：计算成本（CPU/内存/弹性节点）、存储成本（热/冷/归档）、网络成本（跨区传输、外网出口）、调度成本（元数据、任务编排）。
• 按组织归属：业务线、租户、项目组、环境（生产/测试/开发）。
• 按服务形态：常驻集群、弹性伸缩组、Serverless查询、物化视图刷新任务。

划分时要注意“可归因”原则：如果一个成本中心无法对应到明确的资源消耗或责任人，就应继续拆分或合并。例如，共享元数据服务可以按查询次数比例分摊到各租户，而不是简单计入平台公共成本。

二、标签体系：让每一笔资源消耗都带上下文

标签是成本分摊的“身份证”。没有标签，账单只能看到集群总费用；有了标签，才能下钻到业务、租户、查询甚至单条SQL。建议的标签体系分为四层：

• 组织标签：业务线、部门、负责人、成本中心编码。
• 租户标签：租户ID、租户等级（金牌/银牌/普通）、SLA等级。
• 资源标签：集群名、资源组、节点规格、存储类型。
• 查询标签：查询来源（BI/ETL/Adhoc）、查询指纹、用户、项目、优先级。

标签必须在资源创建和查询提交时自动注入，而不是事后人工补录。例如，在查询入口层强制要求携带tenant_id和business_line，缺失时拒绝提交或标记为“未归属”，并纳入治理清单。

三、按业务/租户/查询分摊成本

分摊的核心是找到合理的“动因”。不同资源类型对应不同动因：

分摊到查询级别时，可以采用“查询指纹”聚合：将相同SQL模板的查询归为一组，计算该组的资源消耗，再按执行次数或数据扫描量分摊到具体业务。这样既能避免逐条SQL的噪声，又能保留可优化的热点。

四、单位成本计算：每TB扫描成本与每查询成本

单位成本是衡量效率的核心指标。最常用的两个指标是：

• 每TB扫描成本 = 计算资源总成本 ÷ 总扫描数据量（TB）。它反映“读得贵不贵”，适合评估分区裁剪、列裁剪和存储格式优化的效果。
• 每查询成本 = 计算资源总成本 ÷ 查询总数。它反映“单次查询的平均开销”，适合评估查询并发、缓存命中率和资源调度效率。

假设某租户月度计算成本为 12,000 元，当月总扫描量为 600 TB，查询总数为 240,000 次。则：

每TB扫描成本 = 12000 / 600 = 20 元/TB
每查询成本   = 12000 / 240000 = 0.05 元/查询

这两个指标需要结合看：如果每TB扫描成本下降但每查询成本上升，可能是查询变多但单查询扫描量变小，属于正常优化；如果两者同时上升，则要检查是否有大查询或资源浪费。

五、成本看板搭建

成本看板的目标是让成本“可见、可下钻、可对比、可预警”。建议看板包含以下区域：

• 总览区：月度总成本、环比/同比、预算执行率。
• 趋势区：按天/周的成本曲线，叠加扫描量和查询量。
• 下钻区：按业务线、租户、资源组、查询指纹逐层下钻。
• 单位成本区：每TB扫描成本、每查询成本、每租户成本。
• 异常区：成本突增、未归属资源、高消耗低产出查询。

看板数据应来自统一的成本明细表，字段包括：日期、成本中心、租户、业务线、资源类型、用量、单价、金额、查询指纹、扫描量。这样既能支撑财务结算，也能支撑技术优化。

六、从度量到行动：成本治理的闭环

成本看板不是终点，而是行动的起点。当看板发现某租户每TB扫描成本连续三周上升时，应触发下钻：检查该租户的查询指纹，定位是否存在全表扫描、分区裁剪失效或小文件过多。若发现某业务线未归属成本占比超过5%，应推动标签补全和入口校验。若某查询指纹的每查询成本是均值的10倍，应评估是否增加物化视图或调整资源组。

建议每月做一次成本复盘，输出三张清单：高成本租户清单、未归属资源清单、高消耗低产出查询清单。每张清单都要有责任人、优化动作和预期收益。这样，成本度量与分摊体系才能真正驱动容量与成本优化，而不是停留在报表层面。