企业官网建设流程全解析

简介：面向实时计算与数据平台从业者，这份文档完整呈现美团配送实时特征平台从零到一的建设路径，覆盖平台目标、整体架构、数据流处理、计算层设计、实时特征服务、稳定性建设及规模化演进等核心模块。内容紧密结合实际业务场景，详解了SQL加UDF开发模式、拼图式数据流处理、端到端精确一次语义、四层监控体系、多机房容灾与性能优化等关键实践，并梳理了系统化、规模化、平台化三阶段演进思路，适合数据架构师、算法工程师及平台研发人员参考借鉴。资源为单个PDF文档，大小56.23MB，以演讲幻灯片形式呈现，图文结合便于快速理解分钟级实时特征平台的整体技术方案，也可作为团队技术分享与讨论资料。目前已有195人学习浏览，对希望了解实时特征平台建设、特征服务治理与性能优化思路的读者具有直接参考价值。

1. 实时特征平台是什么：配送场景为什么不能等批处理跑完

做配送ETA预估、定价补贴、调度派单的同学，大概率都经历过这种痛：模型离线训练时AUC涨得挺好看，一上线的实时请求就“变傻”。原因十有八九不在模型，在特征。离线训练用的特征是T+1的全量统计，在线服务拿到的是截止到当前秒的实时状态——两边的分布根本对不上。美团配送这个体量下，骑手位置、商家出餐、天气路况每秒都在变，等离线数仓凌晨跑完当天数据，预估结果早就没意义了。

实时特征平台就是把这层“特征时效差”填平的基础设施。它把实时计算链路和在线特征服务串起来，让模型请求时能拿到秒级新鲜度的特征，同时保证在线特征和离线训练特征的口径一致。适合谁？适合已经在用机器学习做定价、调度、营销，特征还停留在“离线批量算好、在线查表”阶段的团队。这篇笔记按我自己的落地经验，把平台拆成链路、计算、存储、服务四层来讲，每层都给能直接抄的参数和踩坑记录。

2. 从离线数仓到实时特征：链路选型为什么是 Flink + 在线存储双层结构

2.1 Lambda 架构在特征场景的变体：实时链路不替代离线，而是互补

先别急着把离线特征全部搬到流上。美团配送这类业务，离线特征承担的是“长时间窗口统计”和“复杂业务逻辑加工”，实时特征负责“短窗口聚合”和“状态类特征”。两者不是替代关系，而是同源双写。常见做法是：同一份事实数据，离线数仓跑T+1全量加工，实时链路用Flink跑秒级窗口加工，最终在特征服务层合并输出。

我一般会把这套结构叫“Lambda架构的特征版”。好处很直接：离线链路做口径校准和全量回填，实时链路保证新鲜度，两边用同一个特征版本号管理。特征版本号是这里最容易忽略的细节——离线特征和实时特征必须带同一个版本标识，否则在线请求查不到对应版本的特征时，降级逻辑都不知道该往哪退。

实时链路的源头，美团配送场景里通常是三类：骑手GPS上报的轨迹流、订单状态变更流、商家/用户端行为事件流。这三类流的峰值QPS差异很大，GPS轨迹流最猛，订单状态流有突刺，行为事件流相对平缓。链路设计上建议把三类流分开接入，不要合成一个大Topic再统一处理，否则一个流反压会拖垮全部特征计算。

2.2 流表与维表：实时特征计算的两个核心抽象

Flink做实时特征，核心就是两件事：流表上的窗口聚合，以及流表Join维表补齐静态属性。窗口聚合解决“过去5分钟这个商圈的单量、骑手密度”这类统计特征；维表Join解决“这个商家的品类、评分、人均价”这类变化慢的属性。

维表在这里有一个关键选择：用Flink的维表Join还是预加载到本地内存。Flink原生维表Join走Async I/O，适合维表数据量大、需要实时感知变化的场景；但如果维表就几千行，干脆启动时加载到内存，用RichFlatMap自己维护，省掉每一条流消息都查一次外部存储的开销。配送场景的商家属性维表就是典型的小维表，几十万商家，字段十几个，本地内存完全放得下。

窗口聚合这块，注意别把所有特征都做成滑动窗口。滑动窗口每个事件都要触发计算，状态开销线性增长。我一般的做法是：秒级特征用滚动窗口，分钟级特征用滑动窗口，小时级以上特征直接走离线。窗口粒度不是越细越好，实时特征服务端还有一层缓存，窗口太细会导致缓存命中率下降，服务端压力反而变大。

2.3 最小可用链路：从消息队列到特征存储的完整管道

用一个最小链路说明整体结构。假设做一个实时特征：商家近15分钟已完成订单量。完整管道是：订单状态流 -> Kafka -> Flink 消费 -> 15秒滚动窗口聚合 -> 写入特征存储 -> 特征服务API读取。

Flink SQL 建聚合任务（对应订单完成事件流）：

CREATE TABLE order_done ( order_id STRING, merchant_id STRING, status STRING, done_time TIMESTAMP(3), WATERMARK FOR done_time AS done_time - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'ods_order_status_changed', 'properties.bootstrap.servers' = 'kafka-1:9092,kafka-2:9092', 'properties.group.id' = 'rt-feature-merchant-order-done', 'format' = 'json', 'scan.startup.mode' = 'group-offsets' ); CREATE TABLE merchant_done_cnt_15min ( merchant_id STRING, done_cnt_15min BIGINT, window_start TIMESTAMP(3), PRIMARY KEY (merchant_id, window_start) NOT ENFORCED ) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://feature-store:3306/rt_feature', 'table-name' = 'merchant_done_cnt_15min', 'sink.buffer-flush.max-rows' = '500', 'sink.buffer-flush.interval' = '5s' ); INSERT INTO merchant_done_cnt_15min SELECT merchant_id, COUNT(order_id) AS done_cnt_15min, window_start FROM TABLE( TUMBLE(TABLE order_done, DESCRIPTOR(done_time), INTERVAL '15' MINUTE) ) GROUP BY merchant_id, window_start;

这段SQL的逻辑：订单完成事件按15分钟滚动窗口聚合，每5秒批量写入MySQL特征表。WATERMARK设5秒是为了容忍GPS和状态流乱序。两个参数值得注意：sink.buffer-flush.max-rows设为500、sink.buffer-flush.interval设为5秒，这个组合是实践里比较稳的——写太频繁MySQL扛不住，太稀疏特征新鲜度又不够。如果你用Redis做特征存储，Sink端可以换成Redis connector，写入延迟能压到毫秒级，但要注意Redis集群的管道批量写配置。

3. 特征存储选型与在线服务：查询延迟和一致性如何兼得

3.1 Redis 还是 OLTP 数据库：看特征量的量级和更新频率

特征存储选型是平台建设里最容易撕起来的事。Redis派说延迟必须毫秒级，MySQL派说事务和一致性重要。实际落地看两个指标：特征总量和单特征更新频率。特征总量在千万级以下、更新频率秒级，Redis够用；特征总量上亿、特征间有复杂关联更新，就要考虑HBase或分布式KV。

美团配送场景的实时特征，量大的是骑手维度和网格维度特征，这两个维度动辄千万级key。但大部分特征的更新频率是分钟级，不是秒级。我见过不少团队把Redis当万能存储，结果key过期策略、内存淘汰策略没配好，大key阻塞导致在线服务抖动。经验值：单key value超过10KB的特征不要放Redis，Redis的value越大，序列化和网络传输成本越高，超时概率越大。

另外要区分“特征原始值”和“特征版本快照”。在线服务查询时，最好查的是版本快照——某个特征版本下全量特征的统一视图，而不是散落的单个key。实现上常见做法是：特征值写入Redis的hash结构，版本号作为hash的field；查询时按版本号批量hgetall。这样避免特征更新一半时被在线请求读到中间态。

3.2 特征服务的API设计：批量查询是性能生命线

特征服务是承接在线请求的入口，这里最大的性能杀手就是“循环单查”。模型一次请求需要几十个特征，如果客户端代码一个特征一个特征地查，一次推理的RT里大半耗在网络往返上。特征服务API必须设计成批量查询，一次请求带上所有特征ID，服务端并行查存储、合并返回。

一个参考接口定义：

POST /feature/batch/query { "feature_version": "20240612_001", "entities": [ {"entity_type": "merchant", "entity_id": "M100023"}, {"entity_type": "rider", "entity_id": "R450012"}, {"entity_type": "grid", "entity_id": "G88201"} ], "feature_names": ["done_cnt_15min", "rider_online_cnt", "grid_order_density"] }

响应就是每个实体对应的特征KV。设计上注意三点：第一，feature_version必传，服务端拿不到版本号时直接拒绝降级到离线特征，避免线上线下混用；第二，实体类型和ID分开传，因为不同实体的特征存储可能在不同的Redis集群；第三，响应里特征不存在时返回null而不是报错，让模型侧做缺失值填充，而不是服务端抛异常。

3.3 特征更新链路：双写一致性怎么做

特征存储里的数据从哪来？两条链路：实时链路Flink写进来，离线链路Spark/Hive每天回刷全量快照。两条链路写同一张特征表，就会遇到覆盖顺序问题——离线回刷跑得慢，实时增量先写了新值，离线跑完把旧值覆盖回去，这在线上一眼就能查出来。

常见解法是带时间戳的最终写入机制：每条特征写入时带一个update_time，写入前先对比已存在值的更新时间，只有新数据才覆盖。实现上可以在Redis里用hash的field存值、field名带时间戳后缀，或者用Lua脚本做原子比较更新。离线回刷链路我一般安排在凌晨低峰期，并且只回刷T-1的快照，不回刷当天——当天数据以实时链路为准，避免双写冲突。

4. 实时特征计算的三个必调参数：状态TTL、并行度、反压阈值

4.1 状态TTL：不设就是给自己埋定时炸弹

Flink流计算里最容易炸的就是状态无限增长。做实时特征聚合，如果按商家ID做key，状态里存着所有窗口的累加值，关键词不在的垃圾数据永远不清，状态后端越来越大，最终整个Job的Checkpoint超时。

状态TTL是每个实时特征任务必须显式设置的。

# Flink DataStream API 设置状态 TTL 的示例（Java/Scala 同理） from pyflink.datastream import StreamExecutionEnvironment from pyflink.datastream.state import StateTtlConfig, TimeCharacteristic env = StreamExecutionEnvironment.get_execution_environment() ttl_config = StateTtlConfig \ .new_builder(Time.hours(24)) \ .set_update_type(StateTtlConfig.UpdateType.OnCreateAndWrite) \ .set_state_visibility(StateTtlConfig.StateVisibility.NeverReturnExpired) \ .build()

参数逻辑：TTL设为24小时，意味着24小时没有更新的key自动过期。OnCreateAndWrite表示每次写入都刷新TTL计时，适合订单类持续活跃的key。NeverReturnExpired保证查询时永远拿不到过期数据，避免模型读到过期特征。

TTL设多大需要按特征窗口长度反推。如果特征最长窗口是6小时，TTL至少是窗口长度的4倍，要给乱序数据留足余地。美团配送这类业务有典型的高峰低峰周期，建议TTL覆盖至少一个完整业务周期，否则低峰期不活跃的商家key会被清掉，高峰期一来特征冷启动，模型预估质量明显下降。

4.2 并行度设置：不是越大越好，看Kafka分区数

实时特征Job的并行度，常见误区是“集群资源够就多设并行度”。实际上并行度超过Kafka分区数后，多余的subtask根本分不到数据，白白占用slot。更隐蔽的问题是KeyBy之后的聚合，并行度不是关键，数据倾斜才是关键。

配送场景的特征聚合，热点商家和普通商家的单量差两个数量级很正常。热点商家的key在一个subtask上处理，其他subtask空闲，整个Job背压全打在一个subtask上。经验做法是： KeyBy之后先加一层随机前缀打散，聚合完再合并前缀。比如商家ID加一个0-9的随机后缀，先按打散key聚合一次，再按原始商家ID聚合一次。代价是多一次聚合的CPU开销，换来的是热点key不再拖垮整个链路。

并行度设置参考：Kafka分区数64，Flink并行度设32到64之间，source端并行度和分区数保持一致，聚合算子并行度可以比source低一半。这个配比不是绝对的，按集群可用slot数微调。核心原则是：source并行度跟随分区数，聚合并行度跟随key分布，不要一刀切。

4.3 反压和Checkpoint：实时特征任务的两个健康指标

反压是实时链路要时刻盯着的指标。特征计算任务出现反压，最直接的后果就是特征新鲜度下降——Kafka里的消息处理不过来，Lag越来越大，模型拿到的特征越来越旧。监控反压，盯两个数值：Kafka消费Lag和Flink任务的反压百分比。

我一般用Prometheus + Grafana搭监控看板。指标的告警阈值经验值：Kafka Lag超过5000条触发告警、持续10分钟以上进入OnCall；Flink反压百分比超过80%就要查原因。常见根因三类：热点key倾斜、维表Join查存储超时、Sink端写入瓶颈。

Checkpoint这里有一个容易翻车的点：实时特征任务写入外部存储，Checkpoint的语义和普通ETL不一样。特征数据允许重复写入，但绝不能丢。也就是说，Checkpoint策略上开Exactly-Once意义不大，关键是开启Checkpoint并设置合理的超时时间。常见配置：Checkpoint间隔60秒，超时10分钟，同时开启Checkpoint失败不阻断Job——别让Checkpoint失败把整个特征链路搞挂。

5. 避坑：实时特征平台建设的四个高频翻车现场

5.1 在线特征和离线特征对不上：分布偏移是模型效果差的元凶

现象：模型上线后评估指标不如离线实验，特征重要度排序里排名靠前的特征在线分布和离线完全两样。

原因：离线特征从数据仓库全量计算，实时特征从Kafka消息流计算，两边对“订单完成时间”的定义不一致。离线用它进数仓的加工时间，实时用它的事件时间，两个时间差在业务高峰能到分钟级，导致同一个特征ID两边的值口径不同。

解决：统一事件时间口径。离线和实时都取业务发生时间（订单状态变更的服务器时间），不要用到达数仓或Kafka的时间。另外建立周期性离线-实时特征对比任务，每天抽样对比两类特征值的偏差率，偏差率超过5%的报警。

5.2 特征延迟的连锁反应：模型预估的雪崩效应

现象：某个核心特征的P99延迟从50ms涨到500ms，随后模型推理超时率上升，业务方开始投诉。

原因：特征服务依赖的下游Redis集群出现大key，单个热点商家的特征hash特别大，一次hgetall拉取几MB数据，拖垮了那个分片的所有请求，进而反压到特征服务。

解决：Redis侧的key拆分。一个商家的全量特征拆成多个hash，按特征类别分片（统计类一个hash、画像类一个hash）。同时特征服务侧加本地缓存，热点特征的TTL设短一点（比如5秒），非热点特征的TTL设长一些（30秒）。这个组合能兜住大多数Redis抖动场景。

5.3 新商家和新骑手没有特征：冷启动如何处理

现象：新商家上线第一小时，所有统计类特征都是空的，模型打出的ETA完全不靠谱，配送时间预估严重失真。

原因：实时特征链路只处理在线产生的数据，新实体没有历史积累，离线特征也没有T-1数据可回刷。

解决：特征平台内置冷启动规则。实体首次出现在特征服务查询时，自动填充同商圈同品类的均值特征，并打一个is_cold_start标记位。模型侧对这部分的预估结果单独校准，或者直接退回规则策略。冷启动标记位很重要，模型需要知道这个特征值是“填充的”而不是“真实统计的”，否则会把填充值当成真实值学出偏差。

5.4 线上发现特征值异常，要回看历史却拿不到数据

现象：业务方反馈某个特征输出全是0，排查时发现特征存储只保留最近几天的数据，想回看历史特征值对比，什么都查不到。

原因：特征存储设计时只考虑了在线查询性能，没有考虑数据回溯需求。Redis的过期策略把历史数据清了，HBase的保留版本数也没配。

解决：特征平台建设第一天就要规划特征数据回流。实时特征值写入在线存储的同时异步写入数据仓库的特征明细表，保留至少30天。这样排查问题时能直接对比“当时线上实际拿到的特征值”和“期望的特征值”，而不是靠业务方回忆。这个成本不高，Kafka topic加一个消费者把数据落数仓就行，但能省掉后面无数次排障的沟通成本。

6. 进阶：特征质量监控体系和优雅降级的最后一道防线

实时的特征质量监控，核心不是监控平台本身，而是定义清楚“什么样的特征值算异常”。我常用的方法是分层设防。第一层是时效性监控：特征更新时间距今超过阈值（比如5分钟）就降级，因为特征太旧了，宁可不给。第二层是分布漂移监控：特征实时分布和最近7天同时段的分布对比，KL散度超过阈值就触发报警。第三层是业务闭环反馈：ETA预估偏差率上涨时，自动回溯这批请求的特征快照，反查特征是哪个环节出了问题。

这三层里，时效性降级最值得做细。特征服务查询时要带出每个特征的更新时间，模型侧可以根据更新时间给特征衰减权重——特征越旧，权重越低。这样就不存在“硬降级”的边界，而是平滑衰减。

特征版本快照的保存策略是另一个容易被忽略的细节。线上模型推理时特征值是什么，这个问题必须在事后能回答。所以特征服务每次查询都会把特征版本号和查询结果异步写入审计日志，保留7天。之前排查过两次疑难问题，都是靠审计日志还原当时的真实特征输入，才定位到是上游特征计算逻辑变更导致的口径偏移，而不是模型本身的问题。

最后分享一个教训：实时特征平台上线半年后，我们曾经因为追求极致的性能，把特征服务端加了多级缓存，结果特征更新的延迟被缓存掩盖，业务方看到特征没变化以为计算挂了，来回排查了很久。后来在缓存更新上强制加了“版本号递增检测”——特征版本号没变就不允许命中缓存，变更后的第一次查询必须穿透到存储。这个约束保障了特征平台的正确性，正确性永远排在性能前面。希望这篇笔记能帮你在建设实时特征平台的路上少踩几个坑。

本文还有配套的精品资源，点击获取