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

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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.

Home - Wiki
Copyright © 2011-2024 iteam. Current version is 2.139.0. UTC+08:00, 2024-12-24 00:02
浙ICP备14020137号-1 $Map of visitor$