musical-ly 杜鹏 - musical-ly基于社交关系的Smart Feed架构

衷昊伟

2017/12/18 发布于 技术 分类

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会,参会者中超过50%拥有8年以上的工作经验。 ArchSummit秉承“实践第一、案例为主”的原则,展示新技术在行业应用中的最新实践,技术在企业转型中的加速作用,帮助企业技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

文字内容
1. musical.ly 基于社交关系 的Smart Feed架构 杜鹏 musical.ly ⾼高级Java架构师
5. 杜鹏 Cooper Du musical.ly ⾼高级Java架构师 2016年年初加⼊入musical.ly,在musical.ly担任⾼高级Java架构师,负责musical.ly的业 务架构和基础架构⼯工作。
6. • 业务背景介绍 • 产品技术背景介绍 • Smart Feed设计思路路和技术架构 • 实践中的重难点 • 总结
7. 关于 • musical.ly是⼀一个短视频社交应⽤用,视频的⽣生 产和消费是驱动社区发展的主⼲干功能 • ⽤用户的主要内容消费场景之⼀一是关注栏⽬目 • musical.ly的关注栏⽬目是基于时间线的feed流
8. 业务背景介绍 2017年年2⽉月 1.5亿⽤用户 1500万 DAU ⽤用户基数和内容⽣生产数量量已经达到⼀一定规模 提⾼高内容消费即分发效率成为公司的核⼼心⽬目标之⼀一 每⽇日 1200万短视频
9. • 业务背景介绍 • 产品技术背景介绍 • Smart Feed设计思路路和技术架构 • 实践中的重难点 • 总结
10. Feed流简介 内容来源 产品形态 musical.ly 关注栏⽬目 社交关系 时间线 兴趣 瀑布流 其他 其他
11. 时间线产品的常⻅见架构 ⼗十万级 百万级 千万级 读扩散(纯拉) 写扩散(纯推) 推拉结合 注:纯推的⽅方案还是推拉结合,另外⼀一个重要的因素是社交关系结构--即⼤大V的粉丝数量量。
12. 最简单的推拉结合模型
13. 推拉结合改进:Vip发件箱数据存取 • 问题:拉取时需要循环访问Vip的发件箱 • 解决⽅方案:把Vip⽤用户的发件箱独⽴立出来,把循环逻辑向底层推。 • 效果:平均每个Vip⽤用户的发件箱访问耗时从之前的约2ms,降低到 0.2ms
14. 推拉结合改进:异步拉取Vip数据 • 问题:少量量⽤用户关注了了数百个Vip⽤用户,导致拉取Feed时出现超时 • 解决⽅方案:拉取Feed时,限制同步拉取Vip Feed的数量量,新增异步拉取 的流程 • 效果:线上接⼝口访问超时减少90% • 劣势:部分Vip的Feed是异步完成分发的,⽤用户可能会错过⼀一些精彩内容
15. 推拉结合改进:推-拉-推结合 • 问题:异步拉取Vip数据导致的Vip Feed内容丢失 • 解决⽅方案:把 “推拉结合” 的⽅方案进⼀一步改进为 “推-拉-推结合”。 • 定义关注超过500个Vip的⽤用户为 “Vip Zealot” • Vip发布内容后,向所有的“Vip Zealot”进⾏行行分发 • “Vip Zealot”拉取Feed时,不不再拉取Vip的Outbox • 效果:解决Vip Feed内容丢失问题,同时不不降低在线接⼝口访问性能
16. Vip⽤用户的社交关系数据的演进 • 接⼝口需求:对于给定⽤用户,返回其关注的所有Vip User • 实现:⼀一开始,我们使⽤用“⼤大表分区、⼩小表复制”的⽅方式实现 • 新的问题:随着流量量增加、数据量量增⼤大,上述实现逐渐成为系统瓶颈。 最后在实现“Vip Zealot”时,对这部分数据做了了冗余 • 效果:99线从超过50ms,下降到约12ms
17. 纯时间线产品的不不⾜足 • 错过精彩内容:⽤用户消费信息的顺序是固定的。存在错过精彩内容、感 兴趣的内容、强社交关系内容的情况。 • 抑制消费兴趣:部分低质量量的内容抑制了了⽤用户继续消费的兴趣。 • 个性化单⼀一:⽤用户通过“关注好友”或者“订阅”和信息来源建⽴立关系,满⾜足 ⽤用户的个性化定制需求,但这种⽅方式是⼀一元的个性化。
18. • 业务背景介绍 • 产品技术背景介绍 • Smart Feed设计思路路和架构 • 实践中的重难点 • 总结
19. 时间线产品进⾏行行Smart Feed优化 上次访问时间 当前时间 上次已读 优化空间 时间线
20. 时间线产品进⾏行行Smart Feed优化 上次访问时间 上次已读 优化空间 当前时间 本次 已读 时间线
21. 时间线产品进⾏行行Smart Feed优化 更更早已读 优化空间 上次访问时间 当前时间 上次 已读 优化空间 时间线
22. Smart Feed的系统组成 推 拉
23. Smart Feed分发流程
24. Smart Feed系统和Feed系统分发流程上的区别 • 事件源需要增加延迟,留留出时间对视频进⾏行行内容理理解 • 根据社交⽹网络的特点,增加了了⽤用户间的亲密度数据源 • 对同⼀一个⽤用户存在多个Inbox,在分发阶段进⾏行行打分,根据打分结果将数 据分发到不不同的Inbox中(Inbox、Priority Inbox) • 分发过程增加Feed ID,由ID Generator⽣生成。保证顺序性、唯⼀一性、稀 疏性。
25. Smart Feed拉取流程
26. Smart Feed系统和Feed系统拉取流程上的区别 • 需要从当前⽤用户的多个Inbox拉取数据 • 数据合并后根据是否已被固化分成多个Segment • 从Vip Outbox中拉取Feed需要根据Segment的结果进⾏行行 • 在精排后,向⽤用户展示的内容需要在Inbox中进⾏行行固化,固化时需要重写 Feed ID
27. Smart Feed存储数据结构 User ID Item Type Item ID Feed ID Bottom Item Features Feed ✓ ✓ 排序列列 - - Smart Feed ✓ ✓ ✓ 排序列列,固化时会批量量重设 固化Segment信息 分发时冗余的Feed特征,包括视频tag、cv label、 作者国家地区等信息
28. Feed ID⽣生成逻辑 • 使⽤用Redis Lua Script实现,每个⽤用户⽤用Hash数据结构维护状态 • ⽬目的是为了了使⽣生成的Feed ID是稀疏的,后期可以在任意两个ID之间插⼊入内容 Timestamp Timestamp_Ms << 17 Status (3 bits) Feed状态,初始值为0,固化后为1,其余值⽤用作⼀一些特殊情况 Sequence (10 bits) 固化顺序,分发时统⼀一填充为0,固化时根据Ranking II的结果依次填充排序值 VIP (1 bit) Preserved_Sequence (3 bits) 预留留,初始值为0,⽤用于特殊情况下,在已经完成固化后继续插⼊入内容
29. • 回顾推拉结合模式下的Feed流架构 • Smart Feed的主要需求和挑战 • Smart Feed的设计思路路和架构 • 实践中的重难点 • 总结
30. 好友亲密度数据的挑战 • 数据量量⼤大:百亿级,每条记录需要保存10~20个浮点数,数据规模约1TB 左右 • 变化频繁:在离散化(牺牲精度)之后,每⽇日仍有超过⼀一半数据需要更更 新 • 更更新慢:⼀一次全量量更更新需要超过2周时间,只能保证⽇日活⽤用户先更更新 • 扩容困难:MySQL增加Slave之后 “追不不上”
31. 好友亲密度数据的挑战:RocksDB实现数据回流 • builder-mgr: 拆分和管理理构建任务 • worker: 解析数据⽂文件构建索引 • server: 提供在线查询 • smart-client: 实现sharding、新旧 集群切换
32. 使⽤用RocksDB的优势 • 数据构建过程⾮非常快,瓶颈基本只存在于数据解析 • ⽀支持全量量和增量量数据更更新 • 研发成本⾮非常低,只需要开发4个功能⾮非常单⼀一的组件 • 数据更更新过程对在线系统完全没有影响,节省了了使⽤用两个集群切换的成本 • 容易易Scale:增加分⽚片、增加实例例 • Schema Free • ⼀一开始可以复⽤用现有基础设施;后期仍有改进空间:直接使⽤用SstWriter、重新实现服务端
33. 使⽤用RocksDB的优势 写⼊入速度 全量量更更新周期 扩容速度 上线前 <1万 ⼤大于2周 ⼤大于1周 上线后 平均每个节点>5万 每⽇日 次⽇日
34. 数据固化的实现 Feed ID是排序列列。利利⽤用Feed ID⽣生成的稀疏性,通过重新⽣生成Feed ID,把固化的 Feed放在剩余数据的前⾯面。 本次拉取 优 排 化 空 重排 序 结 固化 间 果 重新⽣生成ID 保持ID不不变
35. Vip Feed和普通Feed的合并 • 和普通Feed的推拉结合⽅方案类似,Vip的数据会在拉取后异步的合并回⽤用户的 Inbox中。 • 主要有两⽅方⾯面的原因: • Vip发件箱的访问相对耗时较多,回写之后下次访问时不不需要重复拉取。 • 业务上需要保证Vip的内容顺序稳定 • Vip数据回写Inbox之后,需要在逻辑上保证不不要重复拉取Vip的内容
36. Vip Feed和普通Feed的合并 从Inbox拉取数据后,对数 据按是否固化,进⾏行行分段。 已固化的数据段对应的Vip Feed已经合并回Inbox。 未固化段需要根据相邻区 间的边界,从Vip Outbox 中拉取Vip Feed。 未读 场景1: 所有 数据都未读 已读 未读 场景2: 部分数 据已读 已读 未读 已读 场景3: 更更复杂 的情况
37. Vip Outbox的实现优化 • 使⽤用Redis ZSET实现,以Feed ID作为Score • 使⽤用ZRANGEBYSCORE指令进⾏行行查询,使⽤用Redis Script减少⽹网络交互 • 为每个Vip准备多个副本,让压⼒力力更更均匀的分担在每个分⽚片上 • 拉取Vip Feed内容耗时下降到:平均 6ms,99线 9ms;未读数量量查询耗 时从4ms下降到2.36ms
38. • 业务背景介绍 • 产品技术背景介绍 • 设计思路路和技术架构 • 实践中的重难点 • 总结
39. Smart Feed优化效果 +4.9% UV +21% 消费时⻓长
40. Smart Feed技术指标 拉取数量量 平均响应时间 feed 20 79 ms smart feed 200 118 ms
41. 总结 • 时间线产品常⻅见的推拉结合的架构及数据量量增⻓长之后的优化 • 时间线产品进⾏行行Smart Feed改进的产品需求 • musical.ly在Smart Feed上的技术探索,其系统架构和主要流程 • RocksDB,⼀一种低实现成本的海海量量数据回流的⽅方案
42. 杜鹏 Cooper Du musical.ly ⾼高级Java架构师 2016年年初加⼊入musical.ly,在 musical.ly担任⾼高级Java架构 师,负责musical.ly的业务架构 和基础架构⼯工作。 微信:Cooper_Du