1. 画像系统概述：什么是用户画像与物品画像，流式更新的价值与挑战
1.1 用户画像：不只是标签堆砌
用户画像是什么？说白了，就是给用户打标签。
但别想得太简单。我见过不少团队，上来就搞几百个标签，结果线上效果一塌糊涂。为什么？因为画像的核心不是「多」，而是「准」和「用」。
用户画像，是对真实用户的数字化抽象。它把用户的行为、属性、偏好，变成机器能理解的结构化数据。举个例子：
- 基础属性：年龄、性别、地域、设备型号
- 行为偏好：点击品类、浏览时长、购买频次
- 兴趣标签：游戏爱好者、美妆达人、数码极客
- 价值分层：高活跃用户、潜在付费用户、流失预警用户
我在项目中遇到过一件事：某电商平台给用户打了「母婴」标签，结果给一位单身男青年狂推婴儿车。查了半天才发现，他只是在帮姐姐买过一次奶粉。嗯，这里要注意——画像的时效性和场景性，比标签本身更重要。
画像的核心三要素：
- 可计算：每个标签必须有明确的量化逻辑
- 可解释：推荐系统用得上，业务人员看得懂
- 可更新：用户变了，画像必须跟着变
1.2 物品画像：让机器「认识」商品
物品画像和用户画像是对称的。用户画像描述「谁来了」，物品画像描述「有什么」。
我习惯把物品画像分成三层：
| 层级 | 内容 | 示例 |
|---|---|---|
| 基础层 | 静态属性 | 商品名称、类目、品牌、价格、上架时间 |
| 行为层 | 统计特征 | 近7天曝光量、点击率、转化率、好评率 |
| 语义层 | 内容理解 | 标题关键词、图片风格、视频标签、文本主题 |
举个例子。一件「白色纯棉T恤」，基础层是类目=男装、品牌=某牌、价格=99元。行为层是近3天曝光10万次、点击率2.3%。语义层是「纯棉」「夏季」「百搭」这些关键词向量。
你想想看，如果只靠基础层做推荐，那跟直接查数据库有什么区别？画像的价值，恰恰在于行为层和语义层——它们让物品「活」了起来。
我的经验：物品画像的更新频率，通常比用户画像低。但一旦遇到大促、换季、爆款突然断货，静态画像就会出大问题。所以流式更新对物品画像同样重要。
1.3 流式更新的价值：从「天级」到「秒级」
传统做法是每天凌晨跑批处理，把昨天的数据算一遍，更新画像。这叫离线更新。
但用户不会等你。他刚点了一个「游戏手机」的链接，下一秒你就该知道他感兴趣。等明天？他可能已经下单了别家。
流式更新的核心价值，就三个字：快、准、活。
- 快：事件发生后毫秒级响应，用户行为实时反映到画像
- 准：避免离线更新带来的「数据滞后」和「状态不一致」
- 活：画像不再是静态快照，而是持续演化的动态模型
我曾经在一个短视频推荐项目里踩过坑。离线画像每天凌晨4点更新，结果用户晚上8点刷到某个新品类，系统要等到第二天才能识别他的新兴趣。那段时间留存率掉了2个百分点。后来改成流式更新，问题立刻解决。
注意：流式更新不是万能药。如果业务场景对实时性要求不高（比如月度用户分层），强行上流式只会增加系统复杂度和运维成本。选型之前，先问自己：这个画像真的需要秒级更新吗？
1.4 流式更新的挑战：没那么简单
流式更新听起来很美好，但落地的时候，坑一个接一个。
我总结了几大挑战：
- 数据乱序：用户的行为事件可能延迟到达。比如用户先点了A，后点了B，但B的事件先到。如果按到达顺序更新，画像就错了。
- 状态一致性：流式系统里，同一个用户的画像可能被多个节点同时更新。怎么保证不丢数据、不重复计算？
- 计算开销：每个事件都触发一次画像更新，CPU和内存扛得住吗？尤其是大促期间，流量暴涨10倍，系统会不会雪崩？
- 存储压力：画像数据要支持高频读写，传统MySQL扛不住。选Redis还是HBase？选错了就是灾难。
- 特征漂移：用户的兴趣会变，物品的热度会变。流式更新如果只加不减，画像会越来越「胖」，越来越不准。
嗯，这里要注意——挑战不是用来吓唬人的，而是用来指导设计的。后面的章节，我会一个一个拆解这些问题的解法。
1.5 核心知识体系：一张图看懂
下面这张图，是我梳理的本章知识体系。它把用户画像、物品画像、流式更新的价值与挑战串在了一起。
1.6 本章小结
这一章，我们聊了三件事：
- 用户画像：对用户的数字化抽象，核心是可计算、可解释、可更新
- 物品画像：对物品的结构化描述，分基础层、行为层、语义层
- 流式更新：让画像从「天级」进化到「秒级」，但面临乱序、一致性、性能等挑战
我个人觉得，画像系统是整个推荐系统的「地基」。地基不稳，上面盖的模型再漂亮也没用。后面的课程，我们会一步步把这个地基打扎实。