4、成本分摊模型：四种分摊方式与混合设计

成本归因做到一半，最头疼的问题来了——算出来的总成本，怎么分给各个业务方？

分少了，平台亏钱。分多了，业务方喊冤。我见过不少团队，在这个环节吵得不可开交。其实说白了，分摊模型没有银弹，关键是要找到适合你场景的组合拳。

这一章，我把常见的分摊模型拆成四种：按资源用量、按任务时间、按数据量、以及混合模型。每种我都会讲清楚原理、适用场景，还有我踩过的坑。

4.1 按资源使用量分摊

这是最直观的方式。用了多少CPU、内存、磁盘，就摊多少成本。听起来公平，对吧？

但实际操作起来，有个大坑——资源怎么计量。

我早期在做一个实时计算平台时，直接拿YARN的container申请量来算。结果发现，有些任务申请了16核，实际只用2核。按申请量分摊，那些优化做得好的团队反而吃亏了。

具体实现上，我建议这样分：

• CPU：按实际CPU使用率（秒级采样）
• 内存：按实际内存占用（GB·h）
• 存储：按实际数据存储量（TB·天）
• 网络：按实际流量（GB）

举个例子，假设集群总成本是100万，三个团队的资源使用情况如下：

4.2 按任务执行时间分摊

有些场景下，资源用量不好精确计量。比如Spark任务，资源动态调整，很难说清楚到底用了多少。这时候，按任务执行时间分摊就派上用场了。

核心逻辑很简单：任务跑得越久，分摊越多。

但这里有个隐含假设——所有任务的资源规格是一样的。如果不一样，就得加权。我记得有一次，一个团队跑了个大任务，用了200个executor跑了2小时，另一个团队用20个executor跑了1小时。按原始时间算，前者只比后者多一倍，但实际资源消耗差了10倍。

具体公式：

分摊成本 = (任务执行时间 × 资源规格系数) / Σ(所有任务执行时间 × 资源规格系数) × 总成本

举个例子：

4.3 按数据量大小分摊

数据平台嘛，核心就是数据。按数据量分摊，对存储和传输成本特别合适。

具体分两种：

• 存储分摊：按数据在HDFS/对象存储上的实际占用空间
• 传输分摊：按数据在上下游之间的流转量

我见过一个案例：某公司按原始数据量分摊存储成本，结果业务方疯狂压缩数据格式，从Parquet换成Avro再换成CSV，最后存储成本是降了，但查询性能一塌糊涂。

还有一个细节——冷热数据。冷数据访问少，但占空间大。如果按数据量均摊，对只存冷数据的团队不公平。我习惯把冷热数据分开定价，热数据单价高，冷数据单价低。

4.4 混合分摊模型设计

单一模型总有局限。你想想看，计算成本按资源量摊，存储成本按数据量摊，网络成本按流量摊——这不就是混合分摊吗？

我个人习惯把成本拆成三块：

1. 计算成本：按资源使用量 + 任务执行时间加权
2. 存储成本：按数据量大小 + 冷热分层
3. 网络成本：按实际流量

然后给每块一个权重。比如：

总分摊成本 = 计算成本 × 60% + 存储成本 × 30% + 网络成本 × 10%

权重怎么定？看你的平台成本结构。如果计算占大头，就提高计算权重。我一般用过去3个月的成本占比来定初始权重，然后每季度调整一次。

下面这张图，是我常用的混合分摊流程：

4.5 混合模型的设计要点

设计混合模型时，有几个要点我特别想强调：

1. 权重要动态调整：平台成本结构会变，权重不能一成不变。我每季度做一次复盘，看看实际成本占比和权重是否匹配。
2. 分摊粒度要统一：所有成本最终都要落到同一个维度上，比如团队、项目、或者数据域。不然汇总时会乱套。
3. 要有兜底机制：有些成本实在分不清楚，比如集群管理开销、公共组件成本。我习惯设一个「公共成本池」，按人头或者按团队规模均摊。

嗯，说到这，我想起一个具体的案例。有个团队的数据量特别大，但计算量很小。如果按资源量分摊，他们很划算。但如果按数据量分摊，他们就亏了。最后我们用了混合模型，计算成本按资源量，存储成本按数据量，两边都照顾到了。

这就是混合分摊的魅力——没有完美的模型，只有最适合的组合。