电商转化率低？90%用户行为数据沉睡在数据库中

　　跟开发吵了一架。就去年十二月份，凌晨三点半，告警响的那一刻，我正盯着三台机器的慢查询日志发呆，屏幕上还开着个没关的 pg_stat_statements 窗口，旁边是半桶泡面——葱花都浮在汤上，没动过。

　　他推门进来，头发竖着，手里攥着张纸，说：“转化率跌了百分之二十七，运营要模型，数据得今天下午前导出。”我指了指他身后那个连着三根网线、风扇嘶吼像拖拉机的老家伙，“你看看这台，连索引都建不全，建到一半卡住，查 pg_locks 查到想辞职。”他笑了一下，特别轻的那种，“哎哟，又不是要你建索引，就是跑个行为路径分析，滑动窗口加 funnel 漏斗，SQL 不就一行？”我原以为他真写了 SQL，结果打开他钉钉发来的附件——Excel 表格里贴着四条语句，其中两条用了 SELECT FROM user_behavior WHERE event_time > '2023-12-01'，没分区剪枝，没字段过滤，连 LIMIT 都没写。

　　我直接把屏幕转过去给他看：那条语句在 pg_stat_activity 里挂着跑了四十三分钟，锁住了两个事务，其中一个正在等 WAL 写满，另一个在等 vacuum。他“啧”一声，说：“那加个 limit 呀。”我点头，加了。然后它又跑了三十七分钟——因为数据按天分区，但表名是 user_behavior_20231201 到 user_behavior_20231231，三十一个物理表；他写的 WHERE event_time > '2023-12-01' 根本没法触发分区裁剪，PG 自己都懒得跳过二十九个表。我们盯了七分钟，谁也没说话。窗外天快亮了，蓝得发青。

　　其实那天白天我就知道会炸。早上八点运维群弹出一条消息：“主库连接数突破阈值”，我没回。倒不是不想管，是刚被叫去帮机房的人查证书续期——去年十月份签的 Let's Encrypt 泛域名证书，过期提示邮件进了垃圾箱，他们翻监控时才看见 Nginx 返回了 502，整整六小时，连管理后台都打不开。我说你早干啥去了？他说值班表排错了，他那周不该值夜班，该值的是老张。老张昨儿晚饭吃了俩肉夹馍，喝了一瓶冰啤酒，躺下就睡死，手机静音，没听见告警音。这事跟转化率没关系，可我一想到自己上周也忘了给归档目录配磁盘配额，就觉得没什么好骂的——骂谁？骂自己？

　　电商转化率低？90%用户行为数据沉睡在数据库中。这话站得住的地方，不是什么技术债积累，是优胜劣汰——真有人用数据，他的 SQL 早进缓存、进物化视图、进实时管道了；没人用，它就堆在几十TB的冷表区，连 ANALYZE 都懒得跑。去年十一月我们试过一次行为数据提纯：把点击、加购、下单三个动作抽成宽表，预聚合每日路径，开发提需求三天，DBA 建模两天，上线后第二天，运营反馈“漏了用户从APP切微信分享再回来的路径”。我查日志，发现他们埋点SDK没打渠道参数；我问前端，前端说“文档没写强制传”，我说那你至少别传空字符串啊，他们回：“空字符串也是字符串呀。”我麻了。反正我后来没再碰那张宽表，让它自生自灭去了。

　　最荒唐的是那个叫“漏斗分析”的报表系统，它每天零点定时执行一个脚本，扫所有分区，合并所有 event_type='view'、event_type='cart_add'、event_type='order_submit' 的记录，再用窗口函数算路径完整度。跑一遍要十六小时，中间崩两次，每次重跑前得先 truncate 清表。清表前没人 check 备份策略是否启用——我们压根没给这张表开逻辑备份，只靠 xlog + basebackup 归档。我说过，去年十月我忘了配 pg_basebackup 的 retention 脚本，导致归档目录塞爆过两次，第二次直接把主库 wal_write_delay 给拉到了 800ms。所以我根本没敢在凌晨三点手动 truncate，只让同事把调度器停了。他停的时候手抖，误删了调度配置文件里的 notify_on_failure 字段，搞得后来崩了三天都没人收到钉钉提醒。

　　你问我为什么不清表？因为上个月有次 truncate 后 restore 慢了两小时，我临时改了个折中方案：ALTER TABLE user_behavior_archive RENAME TO user_behavior_archive_202311；然后 CREATE TABLE … AS SELECT ，建完 rename 回去。命令只写了一行，可前后花了四十五分钟写权限检查、测空间预留、核对分区数量，还得等一个开发来确认“这次真不用跑下游 ETL”。其实我不确定要不要跑——他们上游埋点逻辑改过三次，但没人同步更新过血缘文档。我问过两次，最后一次是当面问，开发嚼着口香糖说：“我们哪记得？反正你们 DBA 看 SQL 就知道了。”我看了，SQL 是 view 层嵌 view 层嵌 view 层，最底下那个 base_view 依赖的三张物理表，有一张上周被开发手动 DROP 过——理由是“名字起错了”，然后连夜重建，字段顺序全乱，数据类型也从 int 改成了 bigint，却没通知我调 dependency。我原以为只是小变更，结果下周做月结时发现佣金汇总差了五万七，追查才发现是某个 count() 的结果因为隐式转换变成了 null，最后 sum() 没加进去。这事到现在也没个复盘，因为当天下午总监来巡检，表扬了“快速恢复能力”。

　　前几天整理旧工单，翻到去年七月的一条，写着：“申请开通 prod_user_behavior 表 select 权限，用于 A/B 测试平台。”申请人是另一个组的测试负责人。我没批，因为表没统计信息，没采样，没注释，甚至字段说明都混着中英文：“user_id（int64）、event_time（UTC+8 时间戳）”。我写回复：“请提供最小字段集、查询频次、预期 QPS，否则按高风险权限流程走二级审批。”他没回。现在那张表还躺在那里，连 vacuum 都没跑过完整一轮——自动 vacuum 因为 dead_tuple 太多早就放弃了，last_vacuum 时间停在去年五月二十号。我上个月清理 pg_class 时顺手查了下，它占空间排第三，前面两个是归档日志和审计日志。

　　所以转化率低这事……其实我认了。不是服气，是认命。你知道最绝的是什么吗？上周五财务部要年度复盘PPT，让我导一份“2023全年各渠道首访—成交漏斗”，我把表名抄给他，附言：“建议优先使用 BI 系统已缓存视图，原始表需走数据服务层，T+1延迟。”他两分钟后回：“好的谢谢！”然后自己写了个 Python 脚本，用 psycopg2 直连生产库，FETCH BATCH SIZE 设成十万，连跑九次——第七次断开重连时把 connection pool 塞满了，导致订单库的 insert 全堵在 queue 里，那会儿我正在厨房煎蛋，手机震个不停，一看是值班群里@我，蛋黄流出来了，没擦。

文章配图，仅供参考

（编辑：站长网）

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