先交代背景我上一个项目是做用户行为实时分析团队早期一直把 MaxCompute 当成“T1 离线仓库”用所有统计结果都是隔天出。但业务方不停追问“今天的实时指标能不能提前到今天下午”后来被逼着把这个问题做实才真正摸索出一套以 MaxCompute 为数据底座的实时数据处理方案。这篇文章就基于这个项目的实际经历聊聊我是怎么搭链路、选方案、定参数以及踩了哪些坑。这套实践整体做的事情很简单把埋点日志从 Kafka 接入流计算引擎实时算完聚合指标后写回 MaxCompute 的明细表和汇总表再统一用 MaxCompute 的查询能力做报表和接口数据。整体延迟控制在 1~5 分钟既保住了实时性又保住了团队熟悉的数仓技术栈。如果你是刚接触实时数据处理、或者正在纠结 MaxCompute 能不能扛实时业务的人这篇文章应该能省掉你不少弯路。1. 实时数据处理的关键概念为什么“实时”不能只靠 MaxCompute 本身1.1 “实时”在不同业务场景下是完全不同的指标做实时数据处理第一个要澄清的问题不是“用什么技术”而是“你说的实时是多快”。同一个词在业务方嘴里可能指三件事秒级实时用于大屏、风控拦截、分钟级准实时用于运营看板、指标预警、小时级近实时用于日常报表加速。我项目里最开始的需求是“运营看板能实时看到今天的数据”这本质上属于分钟级准实时。业务方说“实时”实际上能接受 3~5 分钟延迟。这个定位非常重要因为它直接决定了技术选型的复杂度——如果追求秒级那对下游存储和查询引擎的要求会截然不同如果只是分钟级那用“流处理 批量写回”的方式就完全够用还能大幅降低链路成本。1.2 MaxCompute 的定位离线计算引擎但能承载实时数据的终点很多人把 MaxCompute 下意识等同于“离线和慢”这其实是个误解。MaxCompute 本质上是一个分布式大数据计算服务擅长的是海量数据存储和批量计算它的强项是数据管理、权限体系、生命周期策略以及和大量数据工具的无缝集成。它不擅长的是“事件流式处理”也就是说MaxCompute 本身没有一个常驻运行、逐条处理的流计算引擎不能像 Flink 那样 continuously 接收事件、维护窗口状态。所以要实现标题里“基于 MaxCompute 的实时数据处理”正确的姿势不是试图让 MaxCompute 自己处理实时流而是把它放在实时链路的下游作为存储和计算终点。流数据在外面用专门的流处理引擎加工最后落到 MaxCompute 表里。这样既享受了 MaxCompute 的数据仓库能力又不强迫一个离线引擎去做它不擅长的事。1.3 项目里的核心矛盾流计算的“热数据”和数仓的“冷数据”如何衔接实时数据处理落到 MaxCompute 时最核心的矛盾就是两种数据处理模型的差异。流计算是一条永不停歇的事件流数据按时间陆续到达每个时刻都在变化而 MaxCompute 这类数仓长期习惯是“批量导入一个分区然后对这个静态分区反复查询”。把流式数据接入批式存储中间必须要做几个关键转化。第一个转化是时间窗口化流式数据需要先在 Flink 里按窗口例如 1 分钟滚动窗口聚合聚合成一个有限的数据集才能方便地写入 MaxCompute 的分区表。第二个转化是分区策略流数据写入 MaxCompute 时必须要有明确的分区组织方式最常见的是按小时或按天分区这样后续批量查询、生命周期管理都比较自然。第三个转化是幂等与去重流计算可能因为重启和重试导致重复写入所以要在写入端或表设计上保证幂等避免同一批数据落两遍。理解这三个矛盾之后再去搭具体链路就有方向了。所谓“基于 MaxCompute 的实时数据处理”其实就是把流式计算和批量数仓组装成一条通畅的流水线让热数据能以分钟级延迟流进数仓再按数仓的方式被消费。2. 架构选型思考从“离线数仓”升级为“批流一体”的完整链路2.1 候选人方案对比为什么最终敲定“Kafka 流处理引擎 MaxCompute”在真正动手之前我拉了一张表格比较了三种常见方案这个取舍过程非常值得拿出来说说。方案 A纯离线。数据先进日志服务或 Kafka然后每小时调度一次批量任务把近一个小时的增量数据同步到 MaxCompute 并跑汇总。这个方案实现成本最低但延迟是 1 小时起步而且每个小时跑一次全量同步会频繁扫源表压力很大。方案 B完全实时另起一套实时数仓。把流数据全部计算完放到独立的实时查询引擎里抛弃 MaxCompute。这个方案延迟最低但代价是数据体系分裂离线和实时两套存储口径很难保持一致且额外引入一套系统的运维成本。方案 C核心用流计算完成实时加工结果实时或准实时落入 MaxCompute。既要实时性也保留 MaxCompute 作为统一数仓存储查询、权限和后续离线加工都复用数仓能力。这套方案的延迟在分钟级只引入一个流处理引擎链路还算清晰。三套方案对比后非常明显方案 C 的性价比最高既不用推翻团队现有的数仓体系又能把数据延迟从“隔天”降到“几分钟”。我实际项目里也用的这个思路Kafka 作为消息缓冲层Flink流计算引擎承担实时计算MaxCompute 负责最终存储和查询。这套架构到今天运行了半年多整体稳定。2.2 链路中的每个环节都在解决什么问题把这个链路一步步拆开看能更清楚地知道哪些环节是必须的。上游数据源通常是各种埋点日志、业务库变更消息这些数据的第一站往往是 Kafka。Kafka 在这里的角色不只是“队列”更重要的是削峰填谷和数据缓冲。比如做活动大促时流量峰值可能是平时的十倍如果没有 Kafka 缓冲流计算任务容易被瞬时流量打爆而有了 Kafka 就可以让 Flink 按自身处理能力去消费天然实现背压缓冲。Flink 或者类似流引擎承担的计算任务包括解析 JSON、过滤无效数据、按事件时间开窗、做维度关联、计算 PV/UV 类指标。流计算引擎最核心的价值是能维护状态比如按用户去重必须记住哪些用户已经出现过了这是离线批量 SQL 做不到的持续状态管理。最后写回 MaxCompute 的环节则负责把流计算结果落到分区表。这里可以选择经过一个小型数据管道组件定期把一段时间的增量文件合并上传到 MaxCompute也可以直接调用 MaxCompute 的写入 SDK 实时写入。我在实际项目里用的是定期刷写的方式例如每 2 分钟刷一次最近窗口数据避免频繁小文件写入。2.3 数据口径统一实时和离线必须从源头对齐架构确定后第一个要踩平的坑就是数据口径。实时侧用 Flink 算 PV/UV离线侧如果用 Hive 或 MaxCompute 跑 SQL 重新算一遍很容易出现两套 SQL 写法、两套口径最终结果可能差一小截。我的做法是在实时链路上游先做一次“数据标准化”把埋点字段、事件名、时间字段、去重主键全部约定好实时和离线共用同一份“事件明细表”。后续离线任务直接从 MaxCompute 的实时落表明细重新聚合也能反查实时结果的准确性。这个设计让实时和离线变成了同一份数据在不同时效下的两种加工方式口径自然对齐。3. 核心实现细节从埋点日志到 MaxCompute 全链路拆解3.1 数据接入Kafka Topic 设计与埋点协议规范数据接入是整个链路的第一道关但我发现很多人只关注 Flink 怎么算完全忽略上游数据格式。上游数据混乱下游流计算作业写的尽是兼容逻辑成本极高。我项目里的埋点日志格式统一为 JSON并且约定必须包含三类字段事件公共字段如 user_id、device_id、event_type、source、业务业务字段如 item_id、page_id、duration、时间相关字段event_time 表示客户端事件发生时间report_time 表示服务端收到时间。例如{ user_id: u123456, device_id: d7f9, event_type: item_click, source: app, item_id: sku_888, event_time: 2024-06-12 14:30:05.123, report_time: 2024-06-12 14:30:06.456 }Kafka Topic 按业务域拆分不要所有日志塞进一个 Topic。我们当时建了三个 Topicapp_event_log、web_event_log、order_event_log。每个 Topic 根据 user_id 的 hash 分 16 个分区这样同一个用户的事件能保证有序到达消费者又保证了一定的并行度。分区数定 16 是因为 Flink 的 Source 并行度是 4每个并行度消费 4 个分区分布比较均匀。这里要特别注意分区数量在创建 Topic 后尽量不要随意减少改分区数会导致 key 分布重新打散影响局部顺序性。我在另一个项目里踩过这个坑中途为扩容把分区翻倍结果同一用户的点击和下单事件落到了不同分区去重逻辑当场失效。3.2 Flink SQL 作业开发窗口、水印和状态的正确用法整个流计算环节我强烈推荐用 Flink SQL 来写不需要一开始就搞 DataStream API。Flink SQL 对窗口、聚合、维表 Join 都有原生支持代码量少很多而且非常容易对照数仓 SQL 口径。关键要理解三个核心概念事件时间、Watermark、窗口。事件时间就是用户实际操作的时间也就是日志里的event_time而不是 Flink 处理到这条数据的时间。之所以要区分是因为网络传输和处理延迟会导致数据乱序到达如果按处理时间去聚合实时指标就会波动、不准。Watermark 用来告诉 Flink “事件时间小于某个水位的数据已经到得差不多了可以触发窗口计算了”。实际项目里我会在事件时间基础上加 5 秒延迟允许最多 5 秒的乱序数据。核心计算 SQL 片段大概是这样的CREATE TABLE kafka_source ( user_id STRING, device_id STRING, event_type STRING, page_id STRING, item_id STRING, event_time TIMESTAMP(3), report_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 5 SECOND ) WITH ( connector kafka, topic app_event_log, properties.bootstrap.servers kafka-cluster:9092, properties.group.id flink-app-event, format json, scan.startup.mode latest-offset ); CREATE TABLE kafka_processed ( window_start TIMESTAMP(3), window_end TIMESTAMP(3), user_id STRING, event_type STRING, page_id STRING, cnt BIGINT, PRIMARY KEY (window_start, window_end, user_id, event_type, page_id) NOT ENFORCED ) WITH ( connector kafka, topic app_event_processed, properties.bootstrap.servers kafka-cluster:9092, format json ); INSERT INTO kafka_processed SELECT TUMBLE_START(event_time, INTERVAL 1 MINUTE) AS window_start, TUMBLE_END(event_time, INTERVAL 1 MINUTE) AS window_end, user_id, event_type, page_id, COUNT(*) AS cnt FROM kafka_source GROUP BY TUMBLE(event_time, INTERVAL 1 MINUTE), user_id, event_type, page_id;这段 SQL 最值得注意的点是不要去重逻辑直接放在第一步聚合里。先按用户、事件、页面做一分钟粒度计数这是一个细粒度预聚合。后续不管是按小时聚合还是按天聚合都能复用这个中间结果不用再扫描原始明细。3.3 写回 MaxCompute分区设计、写入方式和生命周期管理实时数据最终要落进 MaxCompute我强烈建议直接落到一张独立的“实时明细分层表”而不是跟离线表混用。原因很简单实时表的写入频率高、单次数据量小跟离线批量导入的特征完全不同。表结构上我通常这样设计CREATE TABLE dim_user_event_detail_di ( event_time STRING COMMENT 事件时间, event_hour STRING COMMENT 事件发生小时本地时区, user_id BIGINT, device_id STRING, event_type STRING, page_id STRING, item_id STRING, attributes STRING COMMENT 业务扩展字段JSON, report_time STRING COMMENT 服务端接收时间 ) PARTITIONED BY ( dt STRING COMMENT 天分区, hh STRING COMMENT 小时分区 );里面有两个关键的细节设计。第一用dt和hh双分区。这样当天的数据初始落在dt20240612 / hh14晚上跑离线任务的时候可以只扫描当天的分区省去巨大的 IO如果需要重刷某一天的数据也可以直接删除对应分区重跑。第二我在明细表里保留了event_time字符串格式因为流里面主键去重、乱序判断都需要精确到毫秒的时间。如果用 MaxCompute 的 DATETIME 类型精度可能不够而且转来转去反而容易丢信息。写入方式我选择“批式刷写”不是每条事件独立写。Flink 作业每处理完一个滚动窗口把结果攒到内存每隔固定时间例如 3 分钟批量提交一次写任务。这样做的原因是为了避免频繁产生几百字节的小文件。MaxCompute 本质上对大文件更友好大量小文件不仅影响写入性能还会拖垮后续查询。3.4 参数计算与资源评估一个具体案例完整走一遍先交代我当时的实际数据量每天日志量峰值约 5000 万条日常每秒约 5000 条大促峰值每秒约 5 万条单条日志平均大小约 0.8KB。Flink 作业资源怎么评估我按一个并行度能平稳处理每秒 2000~5000 条简单解析和聚合估算日常需要 4 个并行度峰值需要 16 个并行度。最终设置 Flink 任务并行度为 16每个并行度分配 2GB 内存。这个估算不是拍脑袋每条日志解析和窗口聚合的 CPU 开销很小瓶颈主要在反序列化和下游写入16 并行度配合 Kafka 16 分区正好一一对应。写入 MaxCompute 的并发我设置为 4 个写算子每 3 分钟写一批。一批数据量大约在 90 万条体积约 700MB这个粒度对 MaxCompute 的批量写入接口比较友好既不会因为太频繁产生大量小文件也不会因为积压太多造成延迟过大。最后总延迟分成三段Kafka 停留延迟约几十毫秒Flink 窗口触发延迟约 1 分钟写回 MaxCompute 批量刷写约 3 分钟整体端到端延迟在 5 分钟内。这完全满足运营看板的分钟级需求。4. 实操实录一个用户行为实时看板项目从 0 到 1 搭建全过程4.1 需求拆解实时看板到底要看什么指标如何定义项目开始的时候业务方给的需求描述是“在运营后台看到用户实时行为”。这是典型的一线需求什么细节都没说。我跟业务方一起拆解后明确了第一版的核心指标只有三个实时 PV当前小时累计页面浏览次数实时 UV当前小时去重后的独立用户数实时热门页面 Top10当前小时内被访问最多的前十个页面。有了这三个明确指标后续所有实时链路都围绕它们展开。指标不要贪多尤其第一版。每增加一个指标就可能增加一种去重口径、一个维度组合、一条新的 Flink 作业复杂度是乘法不是加法。4.2 从 Kafka 到 MaxCompute 的建表与关键 SQL第一步在 MaxCompute 建两张表实时明细表和实时指标汇总表。明细表用于存储所有经过标准化的实时事件供排查问题和离线回溯使用汇总表按分钟粒度存储 PV/UV 结果供看板查询。实时指标汇总表结构如下CREATE TABLE dws_user_event_minute_di ( dt STRING COMMENT 天分区, hh STRING COMMENT 小时分区, minute STRING COMMENT 分钟, page_id STRING, pv_cnt BIGINT, uv_cnt BIGINT ) PARTITIONED BY (dt STRING, hh STRING); CREATE TABLE dws_user_event_hour_di ( dt STRING COMMENT 天分区, page_id STRING, pv_cnt BIGINT, uv_cnt BIGINT ) PARTITIONED BY (dt STRING);这里为什么要明细表、分钟分区的汇总表、小时汇总表各一张是因为实时看板需要分钟级粒度而运营同事只看小时粒度就够了。分钟表数据量大小时表数据量相对小查询快很多。两张表通过 MaxCompute 的周期任务每 15 分钟由分钟表聚合成小时表。这样实时查询看分钟表汇总分析看小时表各司其职。4.3 任务调优与上线前压测确保稳定性的关键操作上线前我做了两轮压测第一轮是“暴力灌数据”用脚本往 Kafka 里直接灌了 10 倍于日常流量的数据看资源占用和背压情况。结果发现一个并行度的处理能力明显比其他并行度慢定位后发现是因为某个user_id特别多的事件比如爬虫集中在一个 key导致单分区分发不均衡。解决办法是在 Flink 聚合前加一个随机前缀键把热点 key 打散再在下游按真实 user_id 去重。第二轮压测是“延迟探测”按 20 秒、1 分钟、5 分钟三个粒度分别验证从事件进 Kafka 到查询到 MaxCompute 的时间差。这轮验证发现一个意料之外的问题Flink 作业默认的 checkpoint 间隔是 5 分钟一旦重启恢复从 Kafka 最早位点重新消费的数据和当前正在消费的数据混在一起导致部分延迟出现尖峰。我后来把 checkpoint 间隔调成 2 分钟同时把 Consumer 的启动模式从latest-offset调整为group-offsets让作业重启后尽量从上次提交的位点继续消费而不是从头开始。4.4 上线后的延迟表现和资源使用结果到底稳不稳系统上线后我追踪了大约一周做了几个简单统计端到端 p99 延迟稳定在 4 分钟以内p50 延迟在 2 分钟左右MaxCompute 小时汇总任务跑一次耗时约 3 分钟Flink 作业 24 小时内存稳定在 28GB~32GB没有明显增长状态没有膨胀。最意外的一点是查询性能比我预想的好。因为数据是按小时分区落盘的运营看板查“当前小时热门页面”只需要扫一个dt hh分区MaxCompute 在这类分区裁剪查询下的性能表现非常稳定基本能做到秒级返回结果。这也再次证明了“流计算 MaxCompute 分区分层”这条链路在分钟级实时场景里完全够用。5. 常见故障与排查心得写在运行半年之后的避坑指南5.1 数据延迟越来越大先查背压不要急着加资源实时链路最常见的现象是先开始延迟正常运行几天后延迟越来越大。很多人第一反应是给 Flink 加并行度实际上往往治标不治本。我自己的排查顺序是第一看 Flink Web UI 的 Backpressure 监控如果某个算子出现背压说明下游处理速度小于上游输入速度这个时候要看这个算子是不是单点瓶颈。第二检查 Kafka 消费位点的 lag如果 lag 长期升高说明消费端整体跟不上再考虑加并行度。第三检查写入 MaxCompute 的耗时批量刷写是不是因为小文件太多或者网络抖动变慢了。我实际项目里遇到过一次写入 MaxCompute 延迟飙升排查后根本不是 Flink 问题而是下游 MaxCompute 项目空间配额不足出现了大量写入等待。这时候加 Flink 并行度完全没用去提配额才是解法。5.2 实时结果和离线结果对不上大概率是迟到的数据和窗口乱序晚上离线任务跑出来的 PV 和实时看板显示的 PV 有出入这是很多团队会遇到的困扰。要区分两种情况如果是差几百条以内通常是因为 Flink 窗口允许 5 秒乱序晚到 5 秒之后的数据被放进下一个窗口导致实时窗口结果略小于离线 SQL 的结果这是可以接受的误差。如果差值很大就要查另一种情况Flink 作业发生重启时从 Kafka 某个位点重新消费而下游 MaxCompute 因为没有幂等写入导致同一批数据写入两次。遇到这种情况我的经验是在落 MaxCompute 之前先用 Flink 对事件主键做一个去重也就是在明细表里加一个“幂等键”写入时设置主键忽略策略。另外每晚的离线校验任务也要对比实时明细表与日志原始量的总量能第一时间发现问题。5.3 写入性能查查小文件刷写间隔和合并策略的平衡点MaxCompute 写实时数据最容易忽视的性能杀手就是“小文件”。如果 Flink 每 30 秒刷一次一次只有几百KB一天下来产生几千个小文件查询扫描文件的开销会变得非常大。我在实践里通常把刷写间隔定为 3~5 分钟或者攒够一定行数再刷优先保证每批不小于 64MB。但这里要平衡一个点刷写间隔越长延迟越高。运营看板能接受 5 分钟延迟所以我选了 3 分钟间隔如果业务要求 1 分钟延迟那要么接受更多小文件后期跑合并任务要么选择 MaxCompute 的更实时写入方式但这是另外一套代价。不要把所有维度都调到最优没有免费的午餐。5.4 排查速查表一张表直接定位实时链路问题现象可能原因排查动作解决建议数据整体延迟升高Kafka lag 持续增长看 Flink Metrics 消费位点和背压先检查瓶颈算子必要时增加并行度某几个页面数据缺失实时解析写入异常查 Flink 作业异常日志和 MaxCompute 失败任务看解析器是否兼容新字段统一字段规范实时与离线结果差很多Flink 重启导致重复消费对比消费位点与 MaxCompute 写入量保证幂等写入设置主键去重查询越来越慢小文件过多或分区过多查看表分区数和文件数调大刷写间隔定期合并小分区Flink 内存持续增长状态后端存储膨胀查看 RocksDB 状态大小设定 State TTL控制状态生命周期6. 后续如果是新团队我还会怎么优化这套链路真实运行半年后如果再给我一次机会做这套实时数据处理链路我会在第一版就加两个东西。第一个是“实时数据质量监控任务”。现在链路稳定后质量更多靠离线对账发现如果能从第一天就配置实时数据健康分数据量波动、多指标波动、延迟达标率除种异常能早点预警避免业务方先发现问题再来问我们。第二个是“指标字典与口径管理”。实时结果和离线结果的口径目前靠人肉对齐每次新增指标都要重新协调。如果一开始就建一套在线字典把每个指标的计算逻辑、维度、更新频率统一存起来后续实时和离线加工都从字典读取定义就不会出现越来越多的口径分叉。MaxCompute 作为数据底座最大的价值其实不是“快”而是“省心”权限、生命周期、多租户资源隔离都是现成的团队可以专注解决业务问题而不是维护一堆基础组件。把实时链路建在它上面是我在这半年里觉得最正确的决策——既拿到了实时性又守住了统一的数据管理底线。如果你也在为“实时数仓怎么落”发愁不妨先想清楚自己的延迟目标再用类似这套“流计算 数仓存储”的组合去落地复杂度可控扩展路线也很清晰。