十年沉睡数据，一招激活智能决策引擎

　　去年六月份被拉去救火那项目，现在想起来还牙根发酸。运营总监拍着桌子说"这十年数据要是用不上，我今年KPI直接归零"，可那堆数据当时躺在Hadoop里，格式比老式磁带还乱——有些字段是GBK编码，有些直接存了二进制图片流，最离谱的是有个表的主键居然用MD5(用户手机号+注册时间)，我原以为这种设计早该进博物馆了，结果翻文档发现是2013年某位"架构师"的手笔，现在那人都升CTO了。

　　真正动手那天下了暴雨，机房空调嗡嗡响得像拖拉机。我和后端老张蹲在工位上啃煎饼果子，他突然说"要不咱们直接上Flink？"我差点把榨菜喷出来——那堆数据连基本清洗都没做，直接喂实时计算引擎？这就像给拖拉机装火箭发动机，点火瞬间就能散架。最后还是选了最笨的办法：先写Spark脚本把所有表JOIN成宽表，光这一步就跑了十八个小时，期间运维小哥接了三个电话，每次回来都盯着监控屏幕叹气。

　　最要命的是字段映射。有个叫"user_behavior"的字段，在2015年的表里存的是JSON字符串，2017年改成KV对，2019年又变成Protobuf二进制。我原以为写个解析器就能搞定，结果发现不同年份的JSON键名还不一样——2015年用"action_type"，2016年改成"behavior_code"，2017年又变回"action_type"但值类型从字符串变成数字。老张叼着烟说"这他妈是故意搞我们吧？"，我盯着屏幕上的报错日志，突然闻到他身上有股酒味——这货昨晚肯定又去撸串了。

　　数据清洗完已经七月中旬，这时候运营又提新需求：要能按"用户最近一次购买品类"做分层。我翻遍所有表，发现"品类"字段在2018年之前根本不存在，2018年到2020年用的是三级分类ID，2021年才改成可读的文字描述。最后没办法，只能把2018年之前的数据全标成"未知"，结果运营看了直摇头："这数据质量怎么跟路边摊似的？"我差点把键盘摔了——你倒是早说啊，现在才挑刺？

　　但真正让我服气的，是最后那个智能决策引擎的上线效果。我们原以为这种历史数据训练出来的模型，准确率能有60%就不错了，结果第一版测试直接冲到82%。后来复盘才发现，那些"沉睡"十年的数据里，藏着大量现在算法根本抓不到的长期行为模式——比如2013年注册的用户，如果前三年没买过电子产品，后面五年几乎也不会买；而2018年之后注册的用户，这个规律完全不适用。这种跨时间维度的特征，靠最近三年的数据根本挖不出来。

　　现在回头看，"优胜劣汰"这话真没错。那些当年被吐槽"设计烂"的字段，比如用MD5当主键、不同年份用不同编码，反而成了区分数据质量的天然标签——能活过十年还没被删除的记录，基本都是真实有效的用户行为。反倒是后来那些"规范"设计的表，因为业务频繁变更，字段含义早就面目全非。上周和老张喝酒，他举着啤酒杯说："要我说，数据治理就跟养孩子似的，小时候管得太死，长大反而没出息。"我笑了笑没接话，心里想的却是：这项目要是早两年做，估计早被那些"规范"折腾死了。

文章配图，仅供参考

　　现在这引擎已经跑了三个月，准确率稳定在85%左右。昨天运维小哥跟我说，最近监控显示模型推理时间从120ms降到了98ms，我问他怎么优化的，他挠挠头说："就是把那些十年前的老数据从缓存里踢出去了——反正现在用不上。"我愣了两秒，突然笑出声——这算不算另一种形式的"优胜劣汰"？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!