一一中文网

手机浏览器扫描二维码访问

第98章 系统设计面（第2页）

需要采集用户静态属性、商品属性，以及最重要的用户动态行为数据——浏览、点击、加购、下单、评价。

数据采集端需要埋点规范，保证数据质量和一致性。

存储方面，用户和商品属性这类更新不频繁的数据适合用mySqL或postgreSqL；行为流水数据量巨大且需要实时分析，我会用Kafka做消息队列缓冲，然后落地到hdFS或数据湖做离线分析，同时也会同步一份到clickhouse这类oLAp数据库供实时查询”

。

他语速平稳，每个技术选型都带着简要理由。

王毅听得认真，偶尔插问。

“为什么选clickhouse而不是druid或Kylin”

？

“综合考虑查询性能、社区生态和运维成本”

。

林晨回答，“clickhouse在单表聚合查询上性能极佳，适合推荐系统里常见的‘用户最近30天行为统计’这类查询，而且部署相对简单。

新团队初期资源有限，需要平衡性能和运维负担”

。

“合理”

。

王毅示意他继续。

“第二层，特征工程层”

。

林晨切换到下一张图，“这是推荐系统的‘燃料加工厂’。

原始数据不能直接喂给模型，需要提取特征。

我会分为离线特征和实时特征两条流水线。

离线特征主要利用夜间计算资源，处理历史数据，生成用户长期兴趣向量、商品热度统计、协同过滤矩阵等；实时特征则处理最近几分钟甚至几秒内的用户行为，捕捉即时兴趣变化，比如用户当前会话中点击了哪些类目”

。

他详细描述了特征存储方案——离线特征存入Redis集群供白天服务读取，实时特征则通过Flink流处理实时更新到在线缓存。

“这里的关键是特征版本的统一管理和回滚机制，防止特征不一致导致线上推荐效果抖动”

。

王毅频频点头，手中的笔在纸上沙沙作响。

“第三层，模型层”

。

林晨进入了最核心的部分，“对于新App，冷启动是个大问题。

我建议采用多模型混合的策略。

初期数据少，可以用基于规则的策略（比如热门商品、新品推荐）和简单的协同过滤模型撑场面，快速上线。

同时并行训练更复杂的模型，比如深度学习排序模型——我会先用wide&deep模型结构，兼顾记忆性和泛化性。

等用户行为数据积累到一定量，再引入强化学习来优化长期用户满意度”

。

他顿了顿，补充道：“模型训练方面，离线训练用tensorFlow或pytorch分布式训练框架，部署在公司的Kubernetes集群上，按需调度GpU资源。

这里要设计好实验管理平台，方便算法工程师做Ab测试和模型迭代”

。

“线上服务呢”

？王毅追问，“模型怎么部署？延迟要求多少”