微信视频号的实时推荐技术架构

1. 微信视频号的实时推荐技术架构林枫 flashlin@tencent.com 腾讯微信高级工程师

2.

3. • 实时推荐系统的意义和挑战 • 视频号流批一体的特征服务 • 视频号大模型的毫秒级上线

4. 推荐系统越来越多

5. 算法很重要，但实时性也不能忽视 facebook 论文让好内容更快被发现

6. 实时性的挑战数据仓库毫秒级离线特征（批量计算）秒级在线特征 (流式计算) 行为收集秒级秒级小时级毫秒级特征服务推荐逻辑毫秒级训练样本生成秒级模型训练小时级小时级推理服务向量检索毫秒级排序/召回

7. • 实时推荐系统的意义和挑战 • 视频号流批一体的特征服务 • 视频号大模型的毫秒级上线

8. 特征服务的痛点与现状业务痛点： 1. 2. 3. 4. 5. 6. 可以高吞吐导入大批量的数据；流批一体，既能在线写，也能高吞吐离线导入；使用 UDF 实现特征计算逻辑；支持大 Batch 扩散读，且性能好；可以扫描数据；支持 List 、 Hash 、 HyperLogLog 等数据结构；组件持久化读吞吐扩散读扫描能力在线写离线导入存储模型扩展性运营成本 UDF Redis 1 1 0 0 2 0 2 1 1 2 HBase 2 0 0 2 1 0 1 2 2 0 PaxosStore 2 2 1 1 2 0 1 2 2 2 HBase + 2 2 1 1 2 0 1 2 1 0 Redis

9. 高吞吐导入的挑战高吞吐导入会影响在线服务的可用性  服务的 CPU，磁盘IO，网络带宽资源有限，突发流量会影响在线服务；  Compaction；  需要业务自行控速，不同任务可能同时导入；  数据量大，十亿乃至千亿，导入耗时长；业务需求：业务A：想时在 5 小时内导入 40 亿条数据业务B：想在 1 小时内导入 1TB 数据 … 在线存储：请求量 CPU 使用率有状态的存储服务扩展成本高  机型成本高；  数据需要腾挪；  横向扩容后读扩散严重；磁盘带宽网络带宽

10. 读写分离的数据导入

11. 读写分离的数据导入 • 10TB 的数据只要 4 小时，导入速度是 730MB/s ; • 1000 亿 key 只要 8 小时，导入速度是 340 万 key /s ; • 加机器可以近线性提速； • 读写分离，导入时不会影响在线的特征服务；

12. 流批一体的背景在线特征： • 用户行为统计； • Flink 流式计算；数据仓库离线特征： • 用户画像； • Embeding；毫秒级离线特征（批量计算）秒级两套存储 HBase + Redis ？ • 存储成本 • 开发成本 • 运营成本在线特征 (流式计算) 小时级特征服务秒级行为收集

13. 分布式 LSM 引擎

14. 流批一体的特征服务

15. 灵活扩展 • RPC 数量越多，越容易出现长尾请求； • 而一次特征查询的耗时由长尾 RPC 耗时决定；

16. 多种数据结构支持 • 有序的 KV 存储引擎可以表示高级数据结构 HSET • Hash HMSET • 宽表存储, {key}{filed} => value HGET HMGET • 磁盘中连续存储，一次 IO 可以读出一行 LPUSH List • RPUSH • 队列存储，{metakey} ，{key}{index} => value LPOP • 磁盘中连续存储，一次 IO 可以读出连续一段 RPOP

17. 高性能 UDF • User Define Function ; • 基于 WASM 实现，支持 C++ / Rust / Javascript 等语言； • 类似于 Redis 中的 Lua 脚本，但拥有更好的性能（~100x），接近原生 C++ ; • 和主进程严格隔离，可控制运行时间； • 支持链接第三方库，比如 ProtoBuf， TensorFlow， MKL 等； • 用途：高性能计数器、特征选择、特征拼接 C++ ProtoBuffer 多 filed 求和测试：方法微秒原生代码 6206 微信KV UDF 5814 类Redis（lua解释器，性能关键部分使用C库） 77724 类Redis（lua解释器） 367559

18. 视频号特征服务的总结与展望现已解决了的痛点 • • 未来工作 • 可以高吞吐导入 • 数据湖，实时数仓 • 流批一体 • 特征工程 • 读性能高 • 在线图数据库 • 可以使用高层次的存储模型（Hash/List），可以使用 UDF 组件持久化读吞吐扩散读扫描能力在线写离线导入存储模型扩展性运营成本 UDF FeatureKV 2 2 2 2 2 2 2 2 2 2 Online

19. • 实时推荐系统的意义和挑战 • 视频号流批一体的特征服务 • 视频号大模型的毫秒级上线

20. 模型上线的现状与问题推荐系统一般会采用双塔模型，把 User 和 Item 向量化表示。对于视频号来说，是一个大规模稀疏特征的推荐场景，采用参数服务器架构是比较合适的。方案迭代速度 WXG FeatureKV 小增量 15 秒，全量 100GB/20min， QQ看点无量 GB级 20 分钟, TB级低峰期上线，阿里RTP算分服务分钟级

21. 在线参数服务器 WePS • 训练和推理共用同一个参数服务器 • 从根源上解决以下问题： • • 大模型的毫秒级上线 • 训练和推理的模型对齐，保证算法效果包含训练和推理组件的参数服务器框架

22. 多副本数据同步 • 在线服务需要高可用，所以需要多副本存储； • 已有的副本同步方案开销高：

23. 多副本数据同步同步日志 • 参数服务器场景的业务特点： • 接受最终一致 • 接受低概率的数据丢失同步状态 • • 存在热点数据采用同步状态会比同步日志更合适；

24. 多副本数据同步 • • 现网效果：同步性能优化： • • • 使用多层版本号(key粒度，桶粒度等)来降低比较开销；使用二级索引来快速定位最近的新修改；推拉结合；直播推荐短视频推荐模型总大小 5TB+ 10TB+ 模型数量 100+ 100+ 峰值流量 300GB+/min 4TB+/min 峰值QPS 2千万/s 1亿/s 同步耗时低于 600ms 低于 1s

25. Adam 优化器的实现

26. Adam 优化器的实现

27. Item 向量的实时检索 • 推荐系统的召回流程中，需要用推理服务生成的查询向量，召回 topk 条最相似的向量，进入下一步的排序环节； • ANN( Approximate Nearest Neighbor ) 近邻检索再学术界已被研究多年，有 Faiss、HNSWLib 等成熟的库； • 但实时的向量检索仍是难点；

28. Item 向量的实时检索

29. Item 向量的实时检索

30. WePS 的总结与展望通过训练和推理共用同一个参数服务器，实现了大模型毫秒级上线，解决了训练和推理的模型差异问题； • 解决了里面的一些技术难点： • • 未来工作： • • 大模型的分布式异构训练 • 参数服务器中的异构存储（RAM+PMEM+DISK） • 大召回集的高性能、实时向量检索；高可用 • 优化器实现 • 高性能且低成本

31.

32.