从第一次把业务指标压进内存里跑到后来撑起几个核心链路的实时报表这几年我在内存计算这条路上没少踩坑。很多人一听“大数据内存计算”下意识觉得就是堆内存、上大集群、把数据全塞进内存就行——真不是这么回事。我先说个最直白的感受内存计算强不强看的不是你给了多少内存而是你让哪些数据留在内存里、留多久、怎么保证重启之后还能恢复一致性。这三个问题没想清楚配置再高也白搭。这篇文章我打算完整拆一遍我实际搭建过的实时数据处理平台把架构选型、内存模型、资源测算、参数调优、故障排查这些环节全部摊开讲。适合三类人看一是刚接触实时计算、想搞清楚 Spark Streaming / Flink / StarRocks 这些技术到底怎么选的人二是已经在跑实时任务、但经常被 OOM、背压、数据延迟折腾得够呛的开发三是技术负责人想判断平台该往内存计算方向投多少资源。我把项目中最关键的设计决策和踩坑记录都放在后面每一条都是真金白银换来的。1. 内存计算到底解决什么问题延迟瓶颈不在计算在数据搬移先澄清一个最容易被误解的点。内存计算并不是说 CPU 算得慢恰恰相反CPU 在一毫秒里能执行的指令数量远超你从磁盘里读同一批数据的耗时。传统大数据框架慢的核心瓶颈是数据从磁盘搬到内存、再从内存搬到 CPU 缓存这一整套 IO 路径。我以前做过一个粗略的压测同样一次聚合计算数据全在内存里跑耗时 800 毫秒同样的量从磁盘读入再算要 6.7 秒差了快 8 倍。这个差距在离线场景还能忍但在实时风控、实时大屏、秒级监控这些场景里8 倍就是能不能用的分界线。内存计算的核心思路就是尽量把热数据驻留在内存里把计算引擎调度到数据所在的位置消除“数据搬移”的重复开销。注意这里有两个关键词一个是驻留一个是调度到数据所在位置。不是把全量数据一次性读进内存而是按访问频率和时效性把数据分级——高频访问的维度表、最近窗口内的明细数据、需要做关联的状态数据这些留在内存冷历史数据继续放对象存储或 HDFS只在需要的时候临时加载。在这个思路下实时数据处理的典型链路会变成这样数据源通过 Kafka 接入流处理引擎比如 Flink在内存里维护状态做实时聚合聚合结果写进一个支持内存计算的 OLAP 引擎比如 StarRocks对外提供亚秒级查询。这条链路每一步都有内存计算参与但每一步的内存策略完全不同。接着往下我会逐个环节拆。2. 平台架构怎么设计一条实时链路里每个环节该干什么我搭建的平台整体分四层每一层都解决一个明确的问题。数据接入层负责把业务库 binlog、埋点日志、IoT 设备消息全部统一收拢到 Kafka做流量削峰和消息缓存实时计算层用 Flink 做流式 ETL、状态聚合、窗口计算它是内存计算的主力OLAP 存储层用 StarRocks 存放聚合结果和明细提供极速查询最上层是统一查询服务对外封装 SQL 接口供报表、API、大屏使用。2.1 为什么接入层必须用 Kafka 而不是直接打到计算引擎很多人做实时项目时有个误区觉得数据量不大直接从业务库拉数据丢给 Flink 算就行。我第一个实时项目就是这么干的结果是业务库一忙Flink 消费端直接背压数据延迟从秒级恶化到分钟级最后还把业务库连接数打满了。后来老老实实引入 Kafka 做缓冲层问题全部消失。Kafka 的价值不只是削峰填谷。它天然做了生产者和消费者的解耦上游业务系统不需要关心下游实时任务的重启、扩容、故障恢复只管往 Kafka 丢消息下游 Flink 任务可以按自己的节奏消费遇到反压就暂停消费消息在 Kafka 里堆积但不会丢也不会乱序。Kafka 的 Topic 分区设计还解决了并行消费的扩展性问题一个 Topic 分成 12 个分区下游就最多能起 12 个并行度去消费这个是后劲。2.2 计算引擎的两种模式为什么我最终选了 Flink在计算引擎选型上我做了充分的对比验证。Spark Streaming 是微批模式本质是把流切成一批批的小微批来处理吞吐量高但单条数据延迟在秒级且无法做到精准的逐条处理Flink 是纯流式模式数据一条条来一条条处理延迟能做到毫秒级而且 Flink 的精确一次语义在金融、交易这类场景里几乎是刚需。我当时的项目需要做实时风控用户每笔交易要在几百毫秒内判断有没有风险明显只能选纯流引擎。测试时做了个对比同样处理 10 万条交易消息Spark Streaming 的端到端延迟在 2 秒到 5 秒之间波动Flink 稳定在 300 到 500 毫秒。最终定了 Flink这个决策后来被证明是对的——它的状态管理机制、事件时间处理和两阶段提交在后续实现精确一次语义时帮了大忙。我在 5.1 节会把 Flink 的几个关键机制详细展开这里先不铺开。2.3 OLAP 存储层为什么不用 ClickHouse 而是 StarRocks存储层选型是我和团队争论最久的一个环节。当时候选有 ClickHouse 和 StarRocks。ClickHouse 的优点是单表查询极快在宽表聚合场景下性能很猛但它的短板是集群运维复杂度高、数据更新能力弱、Join 支持不友好。我们的实时场景偏偏需要频繁更新聚合结果比如订单状态从“待支付”变“已支付”指标就要跟着变。ClickHouse 对这种更新场景的解决方案是异步合并延迟不可控查出来的结果可能和实际情况不一致。StarRocks 的 Unique Key 模型天然支持实时更新主键表做的是 Merge 操作更新后的数据能立刻在查询中生效。它还支持标准 SQL、物化视图、弹性扩缩容生态友好很多。我拿真实业务数据跑过对比测试在百万级明细聚合查询场景下ClickHouse 单表查询确实快一点但在多表 Join 和频繁更新场景下StarRocks 的稳定性和易用性全面胜出。最终存储层定了 StarRocks这个选择让后续的报表开发和指标更新省了非常多事。2.4 架构图之外的三个关键连通件架构除了硬件和引擎选型还有一些容易被忽略的连接件。第一个是消息格式的统一。不同来源的数据格式五花八门有 JSON、有 Avro、有纯文本必须统一在接入层做 schema 归一化否则 Flink 侧需要解析各个杂乱的格式会很难维护。我统一用 JSON Schema 定义消息结构Kafka 消息 key 存业务主键value 存业务数据消息头里放时间戳和数据源标识这套约定后来成了整个团队开发实时任务的默认规范。第二个是水位线与数据延迟问题。实时任务处理的是持续不断的数据流但数据会因为网络抖动、上游系统延迟而迟到。Flink 的水位线机制就是为了处理这种乱序数据设计的——它把数据的时间字段和到达顺序分开允许数据在一定时间范围内乱序超过水位线就当过期数据处理。我在设计时给每个任务设置了 10 秒的乱序容忍度这样既能保证大部分迟到数据都能被处理又不会过度延迟窗口计算结果。第三个是监控链路。实时平台任何一个环节出问题都会直接表现为数据延迟增大或结果异常所以必须对各个环节都建立监控。Kafka 侧看堆积量和消费 lagFlink 侧看反压和 checkpoint 耗时StarRocks 侧看查询耗时和导入延迟三套监控配套一套告警规则才能保证出了事第一
