1. 成本核算概述：流批一体架构简介、为什么需要成本核算、成本核算的核心指标
大家好，我是这次课程的主讲。做了这么多年大数据架构，我见过太多团队在流批一体上栽跟头——不是技术选型不对，而是成本算不清楚。今天咱们就从最基础的说起，把成本核算这件事掰开揉碎了讲清楚。
1.1 流批一体架构简介
流批一体，说白了就是一套代码、一套引擎，同时搞定实时流处理和离线批处理。以前我们做数据，Lambda 架构是主流：实时走 Storm/Flink，离线走 MapReduce/Spark，两套代码两套运维，维护成本高得吓人。
我个人习惯把流批一体分成两个流派：
- Flink 流派：以 Flink 为核心，批看作有界流。我最早接触这个思路时也觉得别扭，但后来发现它的状态管理和 Exactly-Once 语义确实扎实。
- Spark 流派：以 Structured Streaming 为主，流看作微批。适合对延迟要求不那么苛刻的场景。
你想想看，如果能把实时和离线统一起来，运维团队只需要维护一套集群，开发人员只需要写一套 SQL，这得省多少事？但问题来了——省事不代表省钱。我见过不少团队，上了流批一体后资源消耗反而翻倍了。
核心观点：流批一体的价值在于「统一」，但统一带来的资源复用和调度复杂度，恰恰是成本核算的难点所在。
1.2 为什么需要成本核算
这个问题我问过很多团队，答案五花八门。有人说为了给老板看报表，有人说为了分摊费用。但我觉得，最根本的原因就一个：你不知道钱花在哪，就没办法优化。
我在项目中遇到过这样一个案例：某电商团队上线了流批一体平台，三个月后集群资源使用率飙升到 85%。老板问为什么，没人能说清楚。后来我一查，发现某个实时任务因为数据倾斜，单个 TaskManager 吃掉了 40% 的内存，而离线任务又在同一时段抢资源。如果当时有成本核算，这个问题早就能发现。
具体来说，成本核算能帮我们解决三个核心问题：
- 资源归属：每个任务、每个部门到底用了多少资源？
- 成本趋势：资源消耗是涨了还是降了？哪个环节在恶化？
- 优化依据：该不该扩容？该不该调整并行度？该不该换存储？
我的建议：成本核算不是财务部门的事，而是技术团队的「体检报告」。没有这份报告，你做的优化都是拍脑袋。
1.3 成本核算的核心指标
聊到指标，很多人的第一反应就是「看 CPU 和内存」。嗯，这没错，但太粗了。我习惯把成本指标拆成四个维度：CPU、内存、存储、网络。每个维度都有它的坑。
1.3.1 CPU
CPU 是计算成本的大头。在流批一体场景下，CPU 的消耗主要来自：
- 算子计算：比如 Join、Aggregate、Window 操作
- 序列化/反序列化：数据在算子间传递时的开销
- 状态管理：Flink 的 State 读写、RocksDB 的 compaction
我曾经踩过一个坑：某个实时任务 CPU 使用率一直很高，但并行度已经调到 64 了。后来发现是 KeyBy 的 key 分布不均匀，导致某些 subtask 的 CPU 跑满，其他 subtask 在空转。这就是典型的「CPU 利用率高但效率低」。
| 指标 | 说明 | 常见问题 |
|---|---|---|
| CPU 利用率 | 任务占用的 CPU 百分比 | 数据倾斜导致局部热点 |
| CPU 时间 | 任务实际消耗的 CPU 时长 | 序列化开销被忽略 |
| CPU 核时 | 核数 × 运行时间，用于计费 | 空闲任务也在消耗核时 |
1.3.2 内存
内存是流批一体中最容易失控的指标。Flink 的 Managed Memory、RocksDB 的 Block Cache、Spark 的 Shuffle 缓冲区，哪个没配好都会出问题。
我记得有一次帮客户排查 OOM，发现他的 Flink 任务给 Managed Memory 配了 70%，结果 State 根本用不了那么多，反而把堆内内存挤爆了。后来我建议他把 Managed Memory 降到 40%，问题就解决了。
避坑指南：我曾经因为没算清楚内存开销，导致一个实时任务在高峰期频繁 GC。后来养成了习惯——每个任务上线前，先估算状态大小，再反推内存配置。
内存核算的关键指标：
- 堆内内存：算子计算、缓存数据
- 堆外内存：网络缓冲区、RocksDB
- Managed Memory：排序、Hash Join 等操作
1.3.3 存储
存储成本往往被低估。很多人只盯着计算资源，却忘了数据是要存下来的。在流批一体架构中，存储分为三层：
- 状态存储：Flink 的 State Backend（RocksDB 或 Heap）
- 中间存储：Shuffle 数据、Checkpoint 文件
- 结果存储：写入 HDFS、OSS、Kafka 等
我见过最夸张的一个案例：某个团队把 Flink 的 Checkpoint 间隔设成了 1 秒，结果一天产生了 2TB 的 Checkpoint 文件，存储成本比计算成本还高。后来改成 30 秒一次，成本直接降了 90%。
| 存储类型 | 计费方式 | 优化方向 |
|---|---|---|
| 状态存储 | 按内存/磁盘容量 | 控制状态大小、合理设置 TTL |
| 中间存储 | 按临时文件大小 | 调整 Checkpoint 间隔、清理策略 |
| 结果存储 | 按数据量 + 存储时长 | 数据压缩、生命周期管理 |
1.3.4 网络
网络成本是最容易被忽视的。你想想看，流批一体任务中，数据要在 TaskManager 之间 shuffle，要写 Checkpoint 到远端存储，要读取外部数据源——这些都要走网络。
网络成本的核心指标：
- 网络吞吐：每秒传输的数据量（MB/s 或 GB/s）
- 网络延迟：数据从源到目标的耗时
- 跨机房流量：如果集群跨机房，流量费用可能翻倍
我有个朋友，他们的流批一体集群部署在两个机房，每天跨机房流量高达 10TB。后来我建议他把数据源和计算集群放在同一个机房，网络成本直接砍掉一半。
1.4 成本核算的整体框架
说了这么多，咱们来画个图，把整个成本核算的框架串起来。
这个框架图其实就说明了成本核算的核心逻辑：从流批一体任务出发，拆解到四个资源维度，每个维度再细化到具体指标，最后汇总到成本模型，输出报表和优化建议。