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

　　去年劳动节，我在机房盯备份恢复——就那台老ES集群，IDC搬迁前最后一次全量拉取，磁盘阵列灯闪得跟心跳似的。柜顶积灰厚到能写字，我拿指甲刮了下，掉渣。

　　运维小张蹲在机柜缝里喊：“李工，索引重建卡在2014年那个index_daily_log_v3了。”我探头看了眼屏幕：状态red，shard未分配，报错是“mapping mismatch on field ‘user_action’”。我原以为又是字段类型冲突，结果翻了下mapping快照，发现2014年这个索引根本没存过‘user_action’字段——它连字段名都没有，只有‘action_code’和‘sub_id’。

　　可奇怪的是，下游BI报表那边，昨天刚跑出一份“十年用户路径聚类图”，用的正是这批数据。他们连表都没换，就是改了下查询DSL里的聚合桶数——把8改成16，再加了个terms嵌套filter。就这么一动，沉了十年的冷数据，突然开始吐特征向量了。我盯着Kibana里那个陡升的“_search”延迟曲线，像看一个刚睁眼的人。

文章配图，仅供参考

　　优胜劣汰站得住的地方就在这儿：不是所有冷数据都等被唤醒，是有的冷数据压根没死透，它只是没被问对问题。2014年那次上线，业务方说“日志只做归档”，所以没建analyzed字段，没开doc_values，甚至关了_source——可他们忘了，当年用Logstash写入时，默认给所有字符串加了keyword子字段。那些被藏在keyword下的原始值，一直静静躺在倒排索引底层，连GC都懒得碰它。

　　（刚才小张递来一杯咖啡，杯底印着“运维部团建2019”，杯子裂了条细缝，我拿纸巾擦了三遍也没擦净水痕）

　　真正触发决策链的，是上周五甲方突然发来一条需求：要“不依赖用户注册信息，仅凭设备指纹与点击序列反推高潜人群”。开发组连夜重写了特征提取器——结果发现旧索引里，2014年的device_id字段虽然没开fielddata，但它在keyword子字段上启用了doc_values。只要聚合粒度足够粗，那个十年没动过的doc_values区，居然比新索引的aggs缓存还快半拍。我查了下节点日志，第一次命中缓存是在凌晨两点零七分，第十三次查询时，cache_hit_ratio直接跳到97%——但没人知道为什么跳得这么猛，连ES源码里那行注释都说“this is not guaranteed”。反正就那样跳了。

　　小张说：“李工，是不是我们之前配错了？比如refresh_interval设成30s其实是对的？”我摇摇头。我也不知道。但那天下午三点，BI组长发来截图：他们用同一份2014年原始日志，跑出了四十七种用户分群——其中二十三种，完全绕过了当时已弃用的user_status字段。靠的是把click_time转成hour_of_day，再跟session_id拼接哈希。我看着那个哈希值，长得跟2023年的新规则几乎一模一样，除了最后一位字母是小写的t，而不是T。

　　后来我调出2014年五月一日当天的segment文件，用Lucene的CheckIndex工具扫了一遍，发现有三个seg里，.doc文件体积比.fdt大整整六倍——而正常应该反过来。这种结构，通常意味着字段内容高度重复、压缩率极高……可那年五一，我们根本没有用户行为埋点。所有点击都走的是静态资源URL带参上报。所以那个巨大的.doc，存的其实全是形如“/click?pos=header_nav&bid=10042&v=1.2”的固定模板串。它们被当作文档塞进了倒排索引，却没人去读正文。直到十年后，有人用正则从url参数里批量extract了bid字段，再扔进terms aggregation。

　　（柜顶那只老鼠夹子还在，弹簧锈死了，旁边散着几粒没拆封的奶酪块，生产日期是2015年3月）

　　所以“一招激活”根本不是哪行代码或者哪个配置，就是某个人在某个时刻，决定不再按字段语义去读数据，而是按字节模式去啃。你问我怎么判断它站得住？就一点：2014年那批日志，在激活前后，物理存储一字没变；变的，只是Query DSL里那个“size: 1000”——从前它拦住了99.3%的结果，这次被删了。于是十年没刷出来的那页，终于露了出来。有谁碰到过这个吗？

（编辑：航空爱好网）

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