实时决策架构设计：让数据从“事后复盘”到“下一秒决策”

搞实时决策架构之前我一直有个观点做大数据架构的人如果只看报表和离线数仓永远是在给业务“事后复盘”真正能体现架构价值的是把数据从“昨天发生了什么”变成“下一秒该怎么办”。大数据领域的实时决策架构设计其实就是在解决这个问题——让数据在产生后的几百毫秒内就能变成一条可执行的业务动作比如拦截一笔欺诈交易、调整一个推荐策略、下发一条故障告警。这篇文章我从实际落地角度出发把这类架构的设计思路、核心链路、选型取舍和上线后的各种坑都摊开聊一遍适合正在搭实时数仓或做风控、推荐、运维智能化方向的工程师参考。先说一个很多团队的共性困惑实时决策明明是典型的大数据场景为什么用传统离线数仓的思路做延迟始终降不下来原因很简单——离线数仓从一开始就不是给“决策”用的它是给“分析”用的。分析允许你跑十几分钟甚至几小时但决策不行。决策系统里每一项数据都要有明确的价值导向要么是规则引擎触发的策略要么是模型推理后的输出链路里每一个环节都不能成为瓶颈。所以实时决策架构在设计上往往会刻意和传统数仓分层拉开距离单独立一套轻量、闭环、能快速反馈的体系。有人可能会问那这和网上常说的“实时数仓”“流式架构”有什么区别实时数仓偏重的是数据加工和指标服务目标是让分析师能查到分钟级甚至秒级的数据实时决策偏重的则是“决策动作”要求计算结果直接进入业务流程并且决策的准确性和时效性都能被评估。两者的底层技术有重叠但构建逻辑、数据模型、链路组织差异不小。如果你们团队什么都没搭过直接照搬一套实时数仓来做决策大概率会发现指标是准了动作却发不出去因为决策链路上的回传、容错、上下文字段根本没设计。回到架构本身。做好一套实时决策架构我的经验是先判断你们到底属于哪种决策场景。业界大致能分成三类一类是规则触发型比如风控里“同一设备号短时间登录次数超过阈值就拦截”逻辑简单对实时性极其敏感另一类是模型推理型比如推荐系统用实时特征拼装模型输入靠推理结果决定给用户推什么第三类是混合型规则负责初筛模型负责精排现实中多数系统都属于这种。三类场景对架构的延迟要求不同规则型可能只需要秒级模型推理型会要求到200毫秒甚至更低架构设计如果不去先分清这些约束后面怎么调都别扭。1. 实时决策架构到底在解决什么问题1.1 决策和报表的本质差异做报表核心追求的是“口径一致”所有团队看的数字得对得上做决策核心追求的是“在正确的时间点做正确的动作”。这两个目标经常冲突。报表看重的是数据完整性漏掉几条可以等补数决策不行决策错过了一个时间窗口这条数据就永远失效了。比如用户已经发起一笔支付需要在100毫秒内判断是否可疑这时候你不可能等两分钟后数据补齐再算必须拿当下已有的信息快速给出一个带概率的判断。这个差异带来的架构影响非常深远。离线链路里你可以依赖全量join、精确去重、回溯重算这些重型手段实时决策链路里全部得换思路。窗口不再是随便跑一天而是几秒或几分钟的滑动窗口数据join不能靠大表关联要靠预构建的维表缓存去重逻辑也不是跑一个distinct就能完事而是要维护bitmap或者布隆过滤器这类有状态结构。做实时决策架构设计时最先要回答的问题不是用什么组件而是你愿意为一份决策结果付出多少准确性来换取及时性。1.2 实时决策的三种典型应用场景结合业务形态实时决策场景大致分散在三个方向上。第一是风控反欺诈这是最成熟也最讲究低延迟的领域。支付、登录、营销反作弊都需要在请求链路里同步拦截一般延迟预算只有几十毫秒到几百毫秒架构上通常采用本地规则加远端特征计算相结合的方式。因为规则判断本身不复杂核心瓶颈在特征计算上你需要维护用户历史行为画像、设备指纹、聚集性检测等实时特征。第二是智能推荐与用户增长。推荐决策存在两种模式一种是列表型推荐可以接受秒级延迟从用户触发到拿到推荐结果有几百毫秒窗口做实时重排另一种是推送型触达用户刚完成某个动作后系统要立刻判断是否该发一张优惠券或推送一篇内容这类决策更接近风控的同步调用模式。第三是运维与业务监控比如支付成功率突然下降、服务器负载突增需要自动触发扩容或者熔断。这类场景延迟容忍度相对高一些几秒到几十秒都可以但对规则的准确率和误报率特别敏感。做架构前先分类场景能帮你避开后续很多无谓的性能调优。1.3 实时决策、实时数仓、传统离线架构的边界把三套架构放在一起对比会发现它们的核心矛盾完全不同。离线架构的核心矛盾是数据量与计算成本实时数仓的核心矛盾是口径一致性与时效性实时决策的核心矛盾是延迟预算与决策质量。这决定了每一层组件怎么选、数据模型长什么样。离线数仓可以放心用Hive或Spark做批处理靠定期调度产出结果实时数仓一般用Flink做流式加工把结果写到OLAP引擎里供查询典型链路是Kafka加Flink加Doris或ClickHouse。实时决策则在实时数仓的基础上又往下走了一层它不只是产出指标还要把指标和动作连接起来。所以链路里必须多出两块一块是决策引擎承载规则与模型推理另一块是动作下发通道把决策结果送回业务系统。很多团队搭实时数仓很顺利一到做决策就卡住原因是他们一直盯着“如何把数据算出来”而没仔细想过“算完之后怎么让业务拿到结果”——决策系统的架构设计后半段比前半段更重要。2. 架构选型先定大局再抠细节2.1 从业务延迟目标反推技术选型选型这件事网上有大量对比文章但真正起决定性作用的不是哪个框架排名靠前而是你们的延迟目标到底是多少。延迟目标一旦定了整个技术选型就变成了一个排除法。如果业务决策能接受秒级以上延迟那技术选型的余地非常大Kafka加Flink加Redis做特征规则引擎做判断完全够用而且实现和维护成本低。期货、股市这种毫秒级交易场景大数据架构基本插不上手主流是用C或Java做内存计算所有数据常驻内存甚至要追求堆外内存和零拷贝。真正让很多团队纠结的是百毫秒到一秒这个区间因为这是典型的大数据流处理框架和在线服务之间的真空地带。Flink本身的处理延迟一般在几十毫秒到几百毫秒之间看起来够用但前提是你不能让Flink承担所有事情比如特征存储就不能放到外部数据库做远程访问否则一次网络开销就要几毫秒到几十毫秒叠加起来就超预算了。我的经验是凡是要支撑百毫秒级决策的特征全部要本地化能放进程内缓存就放进程内缓存放不下的用Redis但必须做好批量拉取和缓存预热。2.2 各层组件的职责划分与落地建议把实时决策架构打开看通常有五个层次接入层负责统一接收业务事件缓冲层负责削峰填谷和消息回溯计算层负责做实时加工与窗口聚合存储层负责特征、规则、模型等数据的读写决策层则负责把计算产出的结果最终变成业务动作。接入层用什么端口协议取决于业务方现有架构但消息标准化一定要在接入源头做好。这块用Apache Kafka非常普遍但也有人用Pulsar看你们对多租户和地域容灾的需求。计算层的主流选择毫无疑问是Apache Flink它能做精确一次语义的流式计算有状态、有窗口、有容错生态也比较全。可能有人会提Spark Streaming但在实时决策这个方向Spark Streaming的微批模式天然有秒级延迟如果你们已经能接受秒级就还凑合如果要做到毫秒级基本就不用考虑了。存储层这个环节最灵活需要按数据类型拆高吞吐的明细数据放消息队列或实时数仓维度数据放MySQL或Redis特征向量放下面的时序存储或内存规则定义可以放配置中心本身就是一套组合拳。决策层的形态差异很大。规则型系统常见做法是配一个规则引擎把条件配置化模型型系统则需要在线推理服务比如基于TensorFlow Serving或者ONNX Runtime对模型做加载和服务化。决策层看起来代码量不大却是整个系统里最需要精细设计的因为它要同时保证毫秒级响应、高并发吞吐以及可灰度可回滚。这层的架构直接决定实时决策系统的类型——逻辑是否清晰、扩展是否方便、多版本规则是否容易切换。2.3 我对选型中“技术栈崇拜”的几个提醒选型阶段最容易犯的错是盲目追求新和重。我见过有团队一开始就上Flink加Hudi加Iceberg想把数据湖也引进来结果整个链路变得极其复杂一套简单的实时特征计算却要维护好几个分布式组件最后瓶颈全出在组件协调上。特别对于刚起步的团队我的建议是重计算、轻存储核心资源放在计算层和决策层支撑系统能少则少。数据湖、数据仓库这些不是不能用而是它们更适合用在对数据回溯、全量分析要求高的场景。实时决策线路上的常用数据往往生命周期很短保留几小时到几天就够了如果硬要落到数据湖不光成本高还容易把简单的链路搞得很难排查。另一种常见误区是逢特征必入Flink状态状态后端越堆越大最终导致检查点超时更合理的做法是明确区分窗口状态和长期特征窗口内临时聚合用状态长期用户画像用外部存储。3. 一步一步搭出实时决策核心链路3.1 标准端到端链路的数据流设计我平时给团队讲实时决策架构时通常先用一条标准链路把概念串起来业务系统里产生一条行为事件SDK或消息客户端把它发送到接入层接入层完成协议解析和格式标准化后写入KafkaFlink消费Kafka一边做实时计算一边更新外部存储里的用户画像与特征决策服务拿到请求后从本地缓存或Redis读取实时特征再从配置中心拉取最新的规则或从推理服务拿到模型打分最终由决策引擎综合这些信息输出决策动作并把动作结果写回Kafka形成反馈闭环。这条链路看起来不复杂难点在于每一段的衔接。比如从Kafka到Flink这段消费位点怎么管理Flink算出的结果怎么同步到Redis如果做异步更新如何避免覆盖旧值决策服务读特征的时候如果Redis刚好没有缓存回源逻辑要怎么做。任何一个衔接细节没设计好做到后面都会变成不断打补丁的脏代码。我经验是先绘制一张详细的数据流图把每条数据的字段、生命周期、生产者消费者标注清楚再进行编码。3.2 Kafka主题规划与消息格式设计细节做实时决策架构Kafka主题规划往往是第一件落地的事情。这件事规划得好不好直接影响后续所有环节的复杂度。我的习惯是主题按数据域而不是按业务系统划分比如订单、支付、用户行为、风控结果、推荐曝光各自建主题而不是一个系统一个主题。否则业务系统一多消费者需要订阅的主题数量爆炸数据血缘也理不清楚。消息格式方面强烈建议使用统一的Schema比如Avro或Protobuf配套Schema Registry做版本管理消息格式变更时消费者才不会灭顶之灾。分区键的设计同样重要因为它决定了消息到达消费者的顺序性。在实时决策场景里大量逻辑依赖事件顺序比如用户先加购后下单如果这两条消息被发送到不同分区被不同并发度处理就可能导致决策状态错乱。针对这类场景分区键必须带上用户ID、设备ID这类能标识业务实体的字段让同一个实体的消息永远进入同一个分区进而交给同一个Flink算子处理。关于消息体设计要额外提醒一点实时决策通道应该走轻量事件而不是全量数据。很多业务方图省事直接把MySQL的binlog或者完整业务对象塞进Kafka导致Flink要解析大量用不到的字段。实时决策链路不需要知道业务表每一个字段的每一个中间态变化它只关心判定决策所需的最小事件集合。我把这个原则叫“贴源瘦身”在接入层就完成字段裁剪只保留决策会用到的核心字段。3.3 实时特征计算与状态管理的关键方法接下来是整个链路里技术含量最高的一段实时特征计算。特征分为两类一是事务性特征比如用户最近5分钟内下单次数二是累积性特征比如用户累计消费金额、30天活跃天数。事务性特征很适合用Flink的窗口计算来实现比如滑动窗口、会话窗口累积性特征则适合以状态或外部存储的方式维护每次新事件到达时对旧值做增量更新。对于Flink的状态管理我建议把状态划分为算子状态和键控状态尽量用键控状态而不是算子状态这样能充分利用Flink的分区机制。比如统计“用户最近N分钟访问次数”最自然的做法是按用户ID做keyBy然后用keyed state存储计数。这里有个大坑如果用户量大每个key都长期保留状态状态后端会迅速膨胀。需要设置合理的TTL比如状态空闲超过10分钟就自动清理既能满足实时特征的计算窗口又不至于让状态堆积成定时炸弹。另一类特征计算要依赖存量维表数据比如用户等级、会员城市等。Flink里做维表关联有几种常见方案——最粗暴的每来一条数据都查一次外部数据库完全不推荐性能太差。实际工程里一般用异步IO加缓存先用本地缓存扛命中率缓存未命中时异步回源查询再把结果缓存一段时间。缓存的过期时间要结合维表更新频率来设置如果维表一天才更新一次缓存设十分钟没问题如果维表可能有秒级更新缓存就要设得很短甚至绕开缓存。3.4 决策服务与动作下发回流的实现思路当实时特征准备就绪决策服务就是最后一道关卡。决策服务本身是一个高并发在线服务它接收业务请求提取请求上下文并组合实时特征和画像特征把这个特征向量传进决策引擎。规则型场景配置中心会下发一组规则表达式系统逐条做条件判断匹配到命中规则就直接返回决策结果。模型型场景特征向量需要组拼成模型输入通过RPC调用模型推理服务拿到打分结果后与阈值比对再返回。动作下发与回流是整个闭环最容易丢信息的一段。我建议所有决策结果无论命中与否都写回Kafka字段里至少要包含请求ID、决策时间、命中的规则或模型、特征快照、动作结果以及一个trace ID串联整个数据链路。这样做有三个好处第一可以复盘决策质量比如规则误杀率是不是变高了第二可以构建样本数据用于后续训练更准确的模型第三出现线上问题时可以定位是哪个环节导致的。关于决策上下文快照这个字段特别容易被忽略所以我说一下它是干嘛用的。系统事后发现某条规则下线了一批错误订单想分析原因但如果当时执行规则所依赖的输入特征没有保存你连“为什么当时会做这个判断”都无从查起。把快照字段设计成嵌套JSON或Protobuf结构业务Debug时候能把关键输入复现出来省去大量“猜原因”的时间。4. 性能、一致性与高可用这三关过不去就白搭4.1 端到端延迟指标拆解与调优顺序做实时决策系统有一句话我反复和团队讲没有度量就没有优化。上游说“差不多几十毫秒”Flink说“差不多几百毫秒”到底端到端多少必须有真实的数据可观测。要拆解延迟得先定指标口径从事件在业务端发生到决策结果返回给业务端的端到端延迟。中间又可以细分成传输延迟、排队延迟、计算延迟、决策延迟四个子段。分别埋好监控点哪个环节慢了才能一目了然。调优顺序上我建议先定位大块慢点再做细活。比如先看是不是业务端SDK发送逻辑阻塞了再看Kafka是否因为分区数不足导致消费侧堆积再者是Flink任务里频繁做外部IO导致反压。如果以上都没问题再去看JVM GC是不是出现了长时间的stop-the-world。顺序反了容易白费力气一上来就调GC参数结果发现瓶颈根本不在计算层。延迟优化是“先通路再提速”的过程通路没打通细节上的优化都是事倍功半。4.2 数据一致性语义的真正难点大数据架构里一致性往往会被理解成“Spark和Flink有精确一次语义数据就不会丢”但实际落地没这么美好。Flink的精确一次语义解决的是计算层的问题它不代表端到端的不重不漏。数据从业务系统发到Kafka这个过程如果业务端先更新数据库再发消息这个操作天然存在双写一致性问题不能保证不丢消息决策结果写入下游业务的时候也可能因为网络超时而产生重复调用比如订单已经打标风控结果了但下游重复收到同一条结果补发通知。所以做实时决策架构从一开始就要接受一个现实端到端精确一次几乎做不到需要让系统设计成“能容忍重复或能检测重复”。典型做法是防重表、幂等键、唯一索引。在决策动作下发的场景里所有下游都要支持幂等写入业务侧需要有requestId去重机制。计算层即使用了Flink exact-once也不能完全依赖它因为你不知道上游某个环节会不会因为日志采集的自动重推而发生数据重复。4.3 实时链路的容错与故障恢复策略高可用这件事实时链路比离线链路更让人头疼因为离线任务挂了可以等人发现实时链路挂了每一秒都在丢决策机会。所以系统要在设计层面就预留好降级路径。第一级是部分降级比如特征存储的Redis集群有一台挂了不应该让整个决策服务不可用可以让请求走本地缓存加简化特征路径。第二级是功能降级当实时特征不可用可以降级成纯规则匹配牺牲准确性来保住可用性。第三级是兜底策略如果全部不可用必须给业务方一个默认策略宁可放行也不可把用户请求卡死。流任务的容错靠的是检查点。常规的建议是把检查点间隔设置成中等长度比如30到60秒太短会造成频繁的分布式快照影响吞吐太长则故障恢复时回放的日志量偏大。状态后端选RocksDB因为增量checkpoint能有效降低快照开销。这里面还有个容易踩的坑不要等任务故障了才去看检查点是否成功日常就要监控checkpoint的历史完成时间和失败次数如果频繁失败多半是状态太大或者下游恢复速度慢需要提前处理。4.4 压测方法和容量预估的实操经验上线前压测很多团队也做但经常是开着压测工具看CPU打满了就完事缺少对延迟分布的判断。实时决策系统看平均延迟没意义P99延迟才是决策质量的真实反映。如果P99和P50差了一个数量级说明系统存在长尾可能来自GC暂停、Redis连接池饥饿也可能是某个热点用户把单分区流量打满了。这种长尾对决策的影响非常不稳定用户平时感觉挺快遇到大促流量爆一下就可能连锁故障。容量预估建议按业务峰值而不是平均值来设计。比如业务往常峰值是每秒2万条事件大促预估会到每秒6万条集群规模就要按峰值乘一个1.5倍到2倍的缓冲系数来规划。Kafka的Partition数量也要提前规划它是吞吐量和并行度的上限。后续如果分区数不够再扩容对keyed状态和顺序性的影响非常大尽量一次设置在合理范围内。Flink算子的并行度同样不要随意改特别是在使用keyed state的情况下修改并行度会触发状态重分布可能带来较大的恢复时间。5. 真实上线中最容易踩的坑和排查方法5.1 时间窗口乱序带来的误判实时决策里事件乱序是个特别容易忽略又特别致命的问题。比如用户先下了订单但由于网络原因订单事件的日志比之前的点击事件日志更早到达了Flink如果在窗口聚合时不做处理计算出的“用户点击后多久下单”就可能是负数或者完全错误。Flink对此提供了两种手段水位线和允许延迟。我通常是设置5到10秒的乱序容忍度配合窗口触发后延迟关闭的机制在保证实时性的同时消化大部分乱序事件。但这里有个取舍乱序容忍度设得越大窗口关闭越晚下游决策的时效性就越差。需要结合业务对延迟和准确性的容忍度去调参。风控场景我一般会把容忍度设得保守一些因为少判一次风险可能造成实质损失而推荐场景可以把容忍度放宽一点因为晚几十毫秒推荐用户几乎无感。每次调完参数都要用线上历史数据做一遍回放测试看看窗口结果的变化是否在可接受范围内。5.2 热度倾斜导致的效果问题实时决策场景里热点用户和热点商品会造成严重的数据倾斜。头部用户的请求量可能是普通用户的上百倍如果按用户做keyBy一个流处理算子会被某个超级用户的洪流打满其他普通用户的数据只能排队等着。表现到决策侧就是大多数用户没问题但某些热点场景下延迟骤增。这种问题离线数据处理中可以通过加盐打散把热点key拆成多个子key再合并实时计算里也能用类似思路。不过无脑加盐需要格外谨慎。如果你直接把这个用户的事件分散到多个子任务去处理那这个用户的有状态窗口计算就乱了比如5分钟内下单次数会被拆成好几份合不回来。一个相对成熟的做法是热点用户单独走专用通道或者把热key与高频维度比如商品、活动拆开统计这样既保证并行度又不破坏单用户的窗口聚合语义。遇到这类问题先用数据探查看看Key分布别靠猜。5.3 特征数据漂移与冷启动失败实时特征是基于一段时间窗口的数据统计出来的一旦用户行为模式发生变化旧特征对新决策的解释力就会下降。比如大促期间用户的购买频率会突然翻好几倍如果模型还是按平时训练数据的特征分布去判断很容易把所有大促用户都识别成异常。针对特征漂移架构层面要留好特征监控和版本管理的口袋团队需要定期评估线上特征分布与训练集特征分布是否一致必要时触发特征版本回退或重新训练。冷启动是另一个老生常谈但每次都能绊倒团队的问题。用户第一次进系统没有历史行为实时画像全空特征值全是缺省值这时候规则或者模型很容易给出一个偏差极大的判断。处理冷启动我比较推荐用场景化默认画像来填充缺失特征比如新用户统一按同城市、同设备类型用户的平均水平来估计。特征存储要设计好默认值规范别把“空值”传给模型模型学到的东西会直接被污染。5.4 排查问题速查表从现象到根因故障现象可能原因第一步排查方向端到端延迟突然升高Kafka消费堆积或下游外部调用慢查看消费组Lag、Flink反压指标、Redis慢日志决策结果频繁偏离预期特征值漂移或规则配置变更核对特征快照、检查规则配置中心发布记录部分用户决策实时性差分区键设计不合理导致倾斜查看各分区的消息量分布和算子繁忙度流任务频繁重启失败状态过大导致检查点超时检查状态大小、TTL设置、RocksDB的block cache数据重复导致决策被重复执行下游缺少幂等检查业务去重表、requestId字段是否有唯一约束排查实时链路有一个心法数据要能看到全链路追踪信息。从业务端发出事件开始每经过一个组件就打一个追踪点记录requestId和时间戳。线上问题只需捞一条失败链路就能看它到底卡在哪个环节不用靠猜。这里的习惯是宁可在源头多维护一个requestId也不要在事后拿着时间戳到处找日志填坑。6. 复盘一次风控场景的实时决策架构落地具体到业务案例上拿一个典型的电商风控实时决策来说也许更容易理解全链路长什么样。业务诉求是用户在领取优惠券和支付环节做实时风控判断目标是拦截批量注册、薅羊毛和盗刷行为响应时间要求是300毫秒内返回结果。最初期团队曾考虑把所有逻辑写在业务服务的拦截器里但后来发现每次活动上线要改的规则太多太频繁业务代码被风控逻辑搅得无法维护于是才开始设计独立的实时决策链路。配置上事件接入层用统一SDK上报用户行为日志和支付订单事件写入Kafka的order_risk_topic。Flink实时订阅这个topic分别做两类算子一类对用户近5分钟的支付频次、设备聚集度做计数统计结果写入Redis另一类维护用户30天画像标签结果存到HBase。决策服务接收风控请求时先从Redis拼接规则所要的全部实时特征再从规则引擎服务拉取当前生效规则列表并且同时用一套XGBoost模型对高风险行为进行打分。规则引擎命中A类规则或模型得分超过阈值的时候决策服务就直接向风控中台发起拦截指令放行业务方继续流程整个过程做异步标记与离线分析。这套架构上线不久后真正让团队头疼的问题落在了Redis特征的可复用性上。开始设计时特征与规则之间的耦合太深规则写死了某几个特征名当规则微调想要引入新特征时特征计算程序也要跟着改通常两个迭代才能发一次版本。后来团队对特征做了服务化抽象成立统一的特征平台业务方在平台上配置特征加工逻辑Flink和决策服务都从特征平台上读取特征定义规则的调整就不再依赖计算程序的修改了。风控场景对延迟的敏感性会逼迫你反复审视链路的每一环。有些团队习惯把所有规则都做成跨服务远程调用一条请求串行调三四个服务延迟预算一下就被吃光了。这次实践给团队的启发是把最常用的决策规则和核心特征直接加载到决策服务本地做成嵌入式规则评估引擎远程调用只留给一些低频的边缘判断。延迟一下子就能砍掉一大截。所以经验就是靠近业务判断的关键数据一定要离决策点尽量近凡是高频读的能本地就本地化。做实时决策架构设计本质是在“及时性”和“确定性”之间做一连串细腻的权衡没有银弹也没有一套可以照抄的方案。如果有人问我这个项目最终收获了什么我觉得最重要的不是把Flink和Kafka用得有多花哨而是整个团队建立起了一套数据驱动的决策思维——从业务上看我们不再是事后补救而是在现场实时做判断。最后分享一个选型上的小建议如果团队资源和运维能力有限就不要同时上太多分布式组件先让一条核心链路稳定跑起来其他优化以后再说。这比什么架构都可靠。