★ FEATURED ARTICLE 简介这是一份面向金融科技、大数据风控领域工程师与架构师的技术分享PDF内容来自58同城资深数据开发工程师的实践演讲系统梳理智能风控在线特征系统的设计思路与落地路径。资料从2017年网络黑产背景切入讲解特征系统与规则、模型策略的协作关系并围绕时间窗口特征、维度特征、滑动窗口计算等核心难点展开对比Storm、Kafka Stream、Spark Streaming与自研TC框架的优劣给出延迟队列、顺序队列的具体解法。包体为单个PDF文件大小1.69MB便于按章节精读与检索。文中还展示了数据中心、计算中心的流批一体架构及数据字典设计适合希望提升实时特征计算能力、优化风控模型效率的读者参考。已有143人学习下载内容兼具背景认知与工程实践细节对理解在线特征生产链路和实时计算选型有直接帮助。1. 智能风控在线特征系统为什么特征上线比模型上线更让团队睡不着风控系统的效果翻车十次里有七次不是模型不行而是特征没送到位。我见过一个信贷团队模型离线 AUC 提升了 0.03上线之后逾期率反向涨了五个点最后定位到根因线上实时算出的“近 7 天申请次数”和离线训练表里的口径差了 12 小时的数据。这份《2-558智能风控在线特征系统设计与实践》的内部代码号就是用来解决这类问题的把离线批量算好的特征变成在线实时可查、口径一致、延迟可控的服务。本文按该系统最常见的落地路径展开覆盖架构选型、特征在线化改造、发布验证和踩坑适合风控算法、后台开发和数据平台三类读者照着搭一套最小可用版本。2. 在线特征系统的架构选型三级计算与存储分层的取舍2.1 特征从离线到在线要跨的三道坎风控特征有一个天然矛盾离线训练时你用尽全量历史数据特征越全越好线上推断时你只有几十毫秒不可能现场扫一遍 Hive 表。在线特征系统要做的就是把“能离线算的先算好不能离线算的想办法实时算”并且保证两边口径一致。第一道坎是延迟。离线特征 T1 生成完全没问题线上风控要求特征读取加计算整体在 50 到 100 毫秒内返回。第二道坎是口径。离线用 Hive SQL 算出的 COUNT、SUM、AVG到了实时计算要用 Flink 或 Spark Streaming 重写一遍稍不注意窗口边界、时间字段单位、空值处理就会产生偏差模型拿到的特征和训练时对不上。第三道坎是数据量。把所有特征一股脑塞进 Redis 不现实全量用户特征可能上亿 key成本高且命中率低必须按特征的使用频率和更新频率分级存储。2.2 离线/近线/在线三级计算的分工我在实际项目里习惯把特征按更新时效分成三级对应三条计算链路。离线级T1处理变化慢的强变量比如用户注册时长、历史逾期次数、设备首次出现日期、多头借贷历史。这类特征用 Hive 或 Spark 批处理每天凌晨算好写入特征表再同步到在线存储。近线级分钟到小时级处理中频变量比如近 1 小时申请次数、IP 段聚集度、同设备关联账号数用 Flink 或 Spark Streaming 做微批延迟目标设在 1 到 5 分钟。在线级毫秒级处理只跟本次请求相关的变量比如当前请求 IP 是否命中黑名单、设备指纹是否异常、本次输入的手机号段、实时埋点行为这类必须请求进来现算。三个级别缺一不可全部放线上一是算不过来二是很多特征比如历史逾期次数在线根本拿不到全量数据全部放离线又满足不了实时拦截的需求。我的经验是一个特征从“离线能算”升级为“在线能算”前先看它的变化频率和风控价值只有两个都达标才值得迁移。计算级别更新时效典型特征存储介质失败影响离线T1历史逾期次数、注册时长、多头借贷Hive - Redis特征陈旧可用兜底值近线分钟~小时近1小时申请次数、同设备关联数Flink - Redis短时不准影响评分在线毫秒当前IP黑名单、设备指纹、实时行为本地缓存 Redis直接拦截失败需降级2.3 在线特征服务的存储选型与 Key 设计在线特征服务的存储层我见过三套方案纯 Redis、Redis 加本地缓存、HBase 加 Redis。风控特征大部分是“一个实体 ID 对应一组特征值”读多写少、单个 value 不大Redis 的 Hash 结构最合适。HBase 适合特征维度极多、需要按列族批量扫描的场景但运维成本高在线延迟也不如 Redis 稳定。本地缓存适合高频热点特征比如黑名单 IP、设备风险等级命中率极高且允许分钟级更新延迟。一个常被忽略的细节是 Key 设计。风控特征最少需要三个维度特征名、实体 ID、特征版本。我常用的格式是featureName#entityId#version比如apply_cnt_7d#U1000234#v20240501。版本号必须进 Key否则特征口径调整后旧缓存数据未过期线上会读到新旧混杂的脏数据。TTL 根据特征更新频率定T1 特征设 24 到 48 小时近线特征设 2 到 4 小时在线特征通常不设 TTL靠本地缓存淘汰。public class FeatureFetcher { private LoadingCacheString, FeatureValue localCache; // L1 本地缓存 private RedisTemplateString, String redis; // L2 Redis public FeatureValue getFeature(String featureName, String entityId, String version) { String key featureName # entityId # version; FeatureValue v localCache.getIfPresent(key); if (v ! null) { return v; } String raw redis.opsForValue().get(key); if (raw null) { return null; // 上层走特征缺失兜底逻辑 } FeatureValue parsed parse(raw); localCache.put(key, parsed); // 回填本地缓存 return parsed; } }这段代码没什么高深之处但三个参数必须说明version不传默认值的后果我之前已经说了localCache我建议配置 maximumSize 在 10 万到 50 万之间过大导致 GC 压力过小命中率上不去raw为空时不要当场计算而是返回 null 让上层走兜底否则每个请求都在线算一遍等于把保护层拆了。另外Redis 操作务必设置超时我一般设 10 到 20 毫秒超时直接返回 null不能因为特征系统拖垮主流程。3. 核心特征在线化改造时间窗、序列特征与外部数据的实时计算3.1 把 Hive SQL 的时间窗聚合改写成 Flink 实时任务时间窗聚合是风控特征里最常用也最容易出问题的一类。离线口径是“近 7 天申请次数”Hive 里一句count(*) group by uid就完事到线上实时计算你要决定两件事窗口是滚动还是滑动事件时间还是处理时间。我先给一个离线版 SQL 做参照-- 离线特征表每天跑一次dt 是分区字段 SELECT uid, COUNT(*) AS apply_cnt_7d, AVG(amount) AS apply_avg_amount_7d FROM apply_record WHERE dt date_sub(${today}, 7) AND dt ${today} GROUP BY uid;这段 SQL 看着简单但有一个隐藏坑dt是申请日期不是业务发生时间。如果一笔申请跨天落库dt按入库日期算离线口径会对不上线上实时的事件时间。这也是为什么很多人离线特征和在线特征天然不一致的原因之一。改写为 Flink SQL 近线任务常见做法是开一个 7 天滚动窗口按事件时间聚合INSERT INTO online_feature_sink SELECT uid, COUNT(*) AS apply_cnt_7d, AVG(amount) AS apply_avg_amount_7d FROM apply_record_stream GROUP BY TUMBLE(event_time, INTERVAL 7 DAY), uid;这里最关键的参数是 Flink 的状态过期时间。滚动窗口本身会在窗口结束时清理状态但如果你用的是 OVER 窗口或者需要保留中间结果状态会无限增长。我一般会给算子设置state.ttl例如table.exec.state.ttl配置为 2 天防止 7 天窗口的中间状态把堆内存撑爆。另一个参数是水位线事件时间模式下乱序数据会导致窗口提前关闭建议允许 1 分钟内迟到数据再晚的直接丢弃并记录指标用于监控数据质量。3.2 IP 与设备风险特征的在线打标IP 黑名单、设备风险等级、手机号段风险这些特征不适合批量算完再存因为请求进来之前你根本不知道下一个 IP 是谁。常见做法是分两层第一层用布隆过滤器做粗筛判断“这个 IP 是否在历史风险集合里”如果命中再走一次精确查询拿到详细标签。布隆过滤器有一个误判率参数要设定fppfalse positive probability设 0.01 时容量 1000 万的集合只需要约 1200 MB 内存设 0.001 时约 1700 MB。风控场景误判会导致正常用户被标记为风险所以我建议 fpp 设 0.001 而不是 0.01代价是多几百 MB 内存换取更低的误伤。同时布隆过滤器不支持删除黑名单 IP 到期移除时要重建过滤器否则过期风险 IP 永远占着内存。我之前踩过这个坑后来改成每天凌晨从离线风险库重建一次布隆过滤器运行期只添加不删除。3.3 特征配置化把特征上线从发版变成改配置在线特征系统如果每个特征都要改代码发版运营成本会随特征数量线性增长。更常见的做法是做一套特征配置中心把特征的定义、计算逻辑、存储位置、TTL、兜底值都放在配置里由配置中心下发到特征服务动态加载。一个最小配置结构长这样{ featureName: apply_cnt_7d, version: v20240501, level: neartime, computeType: flink_sql, computeLogic: SELECT uid, COUNT(*) FROM apply_record_stream GROUP BY TUMBLE(event_time, INTERVAL 7 DAY), uid, storeKeyTemplate: apply_cnt_7d#{uid}#{version}, ttlSeconds: 14400, fallbackValue: 0 }这里的fallbackValue最容易被人忽视。风控特征查询失败时不能直接让请求报错必须给一个默认值。默认值怎么定是门学问apply_cnt_7d这种“次数越高风险越高”的特征兜底设 0 意味着“更信任这个用户”如果缓存故障发生在高风险时段反而会放行更稳妥的做法是设成历史分布的 P50 或 P90 值宁可误杀不放过。我把这个思想叫“特征兜底偏向风控”不是所有特征都适合给 0 或 null。4. 特征发布与一致性校验从离线表到在线缓存怎么不出错4.1 离线特征表同步到 Redis 的链路每天凌晨批处理产出特征快照后需要同步到在线存储。这里推荐用分片同步而不是单线程全量灌数据。假设离线特征表有 1 亿行按 uid 哈希分成 64 个分片每个分片一个同步任务整体同步时间能从 1 小时压到 15 分钟以内。一个典型的数据同步任务骨架#!/bin/bash # 从 Hive 导出当日特征快照按 uid 哈希分片 hive -e SET hive.exec.dynamic.partitiontrue; INSERT OVERWRITE TABLE feature_snapshot_daily PARTITION(dt${TODAY}) SELECT uid, feature_name, feature_value FROM feature_offline WHERE dt${TODAY} DISTRIBUTE BY HASH(uid, 64); # 逐分片同步到 Redis for shard in $(seq 0 63); do hadoop fs -cat /warehouse/feature_snapshot_daily/dt${TODAY}/shard${shard}/* | redis-cli --pipe -h ${REDIS_HOST} -p ${REDIS_PORT} done wait这个脚本有两个参数值得说明DISTRIBUTE BY HASH(uid, 64)是保证同一个 uid 的所有特征落在同一个分片这样 Redis 写入时天然避免跨分片事务问题redis-cli --pipe是批量导入模式比逐条SET快一个数量级但要注意一次管道的数据量建议每 10 万条一批避免 Redis 响应缓冲区积压导致连接超时。4.2 影子验证离线回放与在线比对特征同步上线最怕的不是慢而是“悄悄不一致”。我见过一个特征在离线表里用了unix_timestamp存时间在线实时计算里用了字符串时间两边没 diff 出来模型上线后逾期率涨了三个点才定位到。所以特征发布前必须做影子验证用真实历史流量回放比对离线值和在线值。回放比对的逻辑很简单取最近 7 天的线上请求日志逐条根据请求里的 uid、ip、device_id 去查在线特征服务再把结果和当天离线特征表里对应记录做差。一致率低于 99.5% 就禁止该特征放量。注意 99.5% 是整体容忍度单条特征的差异要按错误类型分类小数值浮点差、窗口边界差、空值差分别设独立的容忍度。# 离线值 vs 在线值比对脚本 import json confident_count 0 total_count 0 diff_examples [] with open(replay_result.jsonl) as f: for line in f: record json.loads(line) total_count 1 offline_val record[offline_value] online_val record[online_value] if abs(offline_val - online_val) 0.001: confident_count 1 else: diff_examples.append(record) if len(diff_examples) 10: break print(f一致率: {confident_count / total_count:.4f}) print(f差异样例: {json.dumps(diff_examples, indent2)})这段脚本里我刻意把0.001作为浮点容忍度这是血泪教训特征值经常是概率、比率离线用 Decimal 在线用 Double正常计算产生的浮点误差在 1e-6 量级如果差到 0.001 以上基本可以断定是口径问题而不是精度问题。跑完脚本后还要人工看差异样例光看一致率数字不够我遇到过一致率 99.9% 的情况下差异的那 0.1% 恰恰是风险最高的头部用户。4.3 灰度发布与特征开关特征系统改动不能一把梭全量切换必须灰度。常见的做法是在特征服务里嵌入“特征开关”逻辑请求进来先读配置中心判断当前请求的 uid 是否命中灰度分桶。分桶规则用hash(uid) % 100灰度比例从 1% 开始逐步调到 5%、 20%、 50%、 100%。灰度期间实时对比灰度和非灰度的特征命中率、平均耗时、兜底触发率任何一项异常立即把开关调回 0%。特征开关的配置项要包含三个字段特征名、生效比例、生效版本。比如apply_cnt_7d当前线上是v20240501要发布v20240601配置中心先下发{featureName: apply_cnt_7d, version: v20240601, ratio: 5}特征服务收到后只对 5% 的请求用新版本其余 95% 仍走旧版本。这个机制的好处是回滚不需要改代码只需要把 ratio 调成 0天然给团队留了后悔药。我在实际项目中特征灰度发布通常比模型灰度多观察一个完整业务周期比如 7 天因为很多欺诈特征在日维度上才有区分度。5. 在线特征系统常见问题与排查五个线上坑的血泪经验5.1 缓存穿透风控大促瞬间打到下游数据库现象大促期间风控 QPS 冲到平时的 20 倍特征服务 Redis 命中率从 90% 掉到 40%数据库连接数被打满特征查询平均延迟从 20ms 飙到 2 秒。原因活动期间大量新用户涌入这些用户没有历史特征离线表里自然查不到请求全部穿透 Redis 打到数据库。数据库没有这么高的读能力连接池耗尽后所有查询排队。解决为每个特征加一个“空值占位符”。查询 Redis 时如果 key 不存在写一个 TTL 为 30 到 60 秒的空值占位后续相同请求直接命中占位符不再穿透。同时限制单 IP 每秒最大特征查询数超限直接拒绝并返回兜底值。这个坑的特征在于你很难从监控里发现“穿透”本身只能看到延迟突增排查时要先看 Redis 命中率曲线。5.2 特征值延迟到达上游数据没到下游算了半截现象某个近线特征在每天凌晨 2 点会有 10 分钟的值断层期间返回的全是兜底值白天偶尔也会出现某分钟窗口特征值为 0。原因上游日志数据因为 Kafka 消费 lag 或 HDFS 小文件问题延迟入库Flink 窗口已经触发计算但数据还没到达导致窗口聚合结果偏小甚至为 0。离线表第二天修正后在线特征已经用错误值参与了一天的风控决策。解决给 Flink 任务设置“允许迟到数据”的时长我常用的是窗口结束后再等 1 分钟迟到数据触发一次增量更新。同时特征服务端增加“特征新鲜度”监控对于近线特征如果当前时间减去特征最后更新时间超过阈值直接标记该特征不可用返回兜底值而不是返回旧的正常数值。5.3 数据倾斜与热点 Key某个头部用户的特征被反复查询现象Redis 某个节点的 CPU 使用率比其他节点高 5 倍特征服务整体延迟正常但错误率上升。原因头部欺诈分子可能同时发起大量申请同一个 uid 的特征被高频查询Redis 单分片热 key 出现。更隐晦的是特征表里某个 IP 段覆盖了大批量用户导致按 IP 聚类的特征在同一时间段内被密集访问。解决热 key 加本地缓存我前面说的 L1 本地缓存对这种情况特别有效命中一次就在本地缓存中保留后续请求不再打 Redis。热 key 本身需要在写入时做散列拆分比如把ip_risk#1.2.3.0/24拆成ip_risk#1.2.3#shard0到ip_risk#1.2.3#shard15共 16 个分片查询时随机选一个分片读取。拆分数量不宜过多否则维护成本大于收益。5.4 模型用的特征和线上算的特征不是同一套现象新模型上线后效果低于离线评估排查了半天发现线上特征服务里apply_amount_avg_7d还在用旧口径只算成功申请而新模型训练时用的新口径包含拒绝申请。原因特征更新了但模型版本和特征版本没有绑定。特征服务的配置信息里没有记录“这个特征属于哪个模型版本”导致新模型上线时用了旧特征。解决在做特征服务时就把“模型-特征版本映射表”建好每次模型上线前自动校验模型依赖的特征版本是否全部在线可用。校验不通过直接拒绝发布。这个映射表可以是一个简单的配置文件发布系统读取后自动比对不允许人工跳过。5.5 监控盲区只看接口成功率不看特征覆盖率现象特征服务接口成功率 99.99%但风控模型的效果在缓慢下降每周逾期率都在涨但没人察觉。原因特征覆盖率即请求能拿到非兜底特征值的比例从 95% 慢慢掉到了 85%兜底值使用比例升高模型实际输入和质量变差。接口成功率只反映“请求有没有返回”不反映“返回的值可不可信”。解决必须为每个特征单独埋“值来源”指标区分三类命中缓存、空值占位、兜底值。按特征、按接口维度统计兜底比例超过阈值就告警。我在这个坑上吃过亏后来把“兜底率”列为线上 dashboard 的前三个指标之一和成功率并列。“接口正常但效果变差”这类慢故障大多数情况下是特征覆盖率和新鲜度出了问题。6. 最后一道关用一份检查清单验收你的在线特征系统在线特征系统跑起来只是开始验收才是决定团队能不能睡得着觉的环节。我每接手一个风控特征系统都会按固定清单过一遍不发版也要每月自查。这份清单的核心是五个数字特征覆盖率、特征新鲜度、查询成功率、P99 延迟、离线在线一致率它们分别对应“特征有没有、数据新不新、服务稳不稳、延迟够不够、口径对不对”。一个正常的系统至少满足覆盖率大于 99%新鲜度延迟低于 5 分钟成功率大于 99.99%P99 延迟小于 100ms一致率大于 99.5%。如果某一项不达标对应的排查方向分别是数据同步链路、Flink 窗口延迟、缓存穿透与热 key、特征序列化和网络开销、离线在线口径差异。这里给你一个可以直接用的验收表格模板我每次系统改造完就照着逐项打勾曾在两周内发现 6 个潜在隐患验收项通过标准失败排查方向特征覆盖率 99%离线特征表是否有大量 key 未同步特征新鲜度近线 5min离线 24hFlink 消费 lag同步任务失败告警查询成功率 99.99%Redis 连接池、本地缓存淘汰策略P99 延迟 100ms特征序列化格式、Redis 慢查询离线在线一致率 99.5%时间口径、空值处理、浮点容差最后一个技巧和序列化有关在线特征值我建议统一使用二进制格式如 protobuf 或 MessagePack不要直接存 JSON 字符串。JSON 的好处是调试方便但序列化和反序列化开销在 P99 延迟上至少多消耗 5 到 10ms。批量特征读取时用 pipeline 或 mget 而不是循环单条查询Redis 往返次数从 N 次降到 1 次P99 延迟往往能直接砍掉 30%。我自己的习惯是每次台风控特征上线前把这份清单贴在发布群里没人敢免检。干这行越久越相信一件事模型和算法只决定上限特征系统才是底限宁可模型笨一点也不能让特征停下来。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
