今⽇头条 User Profile 系统架构实践 丁海峰 推荐系统是怎样⼯作的 • ⾼质量的⽤户特征是做好推荐的关键之⼀ 什么是好的推荐效果 • 点击率，但不仅是点击率 • 内容⾼质量，丰富多样，有惊喜感，能够帮助⽤ 户探索兴趣，快速反馈⼜不能过度灵敏， etc. • ⻓期⺫标 • ⽤户：有兴趣，有收获，愿意⻓期使⽤ • ⽣态：⿎励良币，驱逐劣币 需要怎样的⽤户特征 • ⼈⼝学：性别、年龄、地域， etc. • 内容特征： category, topic, keyword, entity, etc. • 喜欢 & 不喜欢 • 短期 & ⻓期 • 协同特征：相似⽤户 • 其它： e.g. 逼格 My Profile 算法 • 点击加权 & 未点击惩罚 • 热⻔点击降权 • 时间衰减 • 噪声过滤： spam，标题党等 • 其它精细的调优 System Overview Our Challenges • 存量⽤户量⼤， ⽤户⾏为数据量巨⼤ • 期望快速反馈 • Online serving storage: 读写吞吐⾼，时延低且可 预期 ⼀些数字 • ⽤户⾏为数据 • 历史存量： 500TB+ （压缩后） • 每⽇新增： 1TB+ （压缩后） • ⾼峰时段： 400K msg/s （ Overall） • Profile Server • feature 数量： 200+ • 容量：单副本 12TB • 请求次数： 1.2M qps Batch Approach • Batch 计算， MySQL 存储 • Daily Mapreduce Workflow • 对每⽇活跃⽤户，抽取该⽤户过去两个⽉的展 ⽰和动作，从 0开始重建该⽤户的 user profile 问题 • CPU 密集，⼤量重复计算 • ⾼写⼊吞吐， MySQL 瓶颈 • 更新不及时，⽤户动作反馈到 user profile 可能会 ⻓达两天 Streaming Approach • A Storm Topology • mini-batch processing • 固定 10 min 时间窗⼝ • 获取⽤户上⼀次 profile 状态作为 base • 做时间衰减 • 使⽤新增的展⽰和动作更新 profile Pros. • ⽤户动作反馈周期⼤⼤缩短： 2天 -> 10分钟 • 减少重复计算，节省⼤量 计算资源 Cons. • 统计类特征 会有延迟，即时值 不等于 最终值 • 点击延迟：⽤户可能在展⽰之后⼀段时间才会点击 • 热点⽂章点击降权：热点⽂章，在⽂章发布初期点击的⽤户被 错误的认为点击了冷⻔⽂章 • ⽂本特征延迟： spam 标题党等特征判定会有延迟 • 算法上线可能会有异常，需要回滚 user profile • batch 更容易，覆盖新数据即可 • streaming 计算需要 replay ⻓时间的历史数据，开销反⽽更⼤ Hybrid Approach • 在 Streaming 更新的基础上，引⼊周级的 Batch 校准 • 以上⼀次 Batch 计算产出的 user profile 快照作为 base， replay 其 后产⽣的⽤户展⽰、动作并更新 user profile Data pipeline 算法接⼝抽象 • Storm & Mapreduce 计算模型有差异，但核⼼算 法⼀致 • 抽象核⼼算法接⼝，算法实现保持⼀致，避免 维 护两份不同的 Code • update_profile(base_profile, impressions, actions) => new_profile • Re-thinking: Spark & Spark Streaming UserActionStore • 基于 HBase 实现的，实时、可随机读写、可扩展 的⽤户⾏为存储 • 以 (hash, user_id, timestamp) 为 RowKey • 访问接⼝ • UAStore.get_impressions(uid, start_time, end_time) • UAStore.get_actions(uid, start_time, end_time) ProfileStore • 需求 • 读请求稳定低延迟： serve 在线访问请求 • ⾼写⼊吞吐： batch/流式更新 • 数据多副本 • 数据量巨⼤，需要可⽔平扩展 Springdb • twemproxy + rocksdb • 主从同步 双副本 • twemproxy reload 配置实现主从切换 • 重写 compaction 策略，降低写放⼤系数 • latency ⻓尾调优，减少超时 LSM-Tree Compaction http://www.benstopford.com/2015/02/14/log-structured-merge-trees/ Fight with Write-Amp • rocksdb: LSM-Tree, compaction, 写放⼤ 10x~, SSD 寿命 • Our Solution: • 限制只使⽤ L0~L1，减少 compaction 层次 • Customized Level Style Compaction • L0 ⼩⽂件 compaction => L0 • L0 ⼤⽂件 full compaction => L1 • 写放⼤ 10x~ => 2~3x，读放⼤、空间放⼤可接受 • https://github.com/facebook/rocksdb/issues/210 Performance • 数据量：压缩后 12TB 数据 x 2副本 • QPS： read 140K， write 55K (cache 后 ) • 时延： avg 500us, pct99 5ms • 机器： 16台机器， SSD，存储瓶颈 Lessons we learned • Batch + Streaming 是⼀种常⽤的模式 • 合适的基础设施和业务抽象，减少重复 • 深⼊理解 workload，选择合适的存储系统 • Rocksdb on SSD rocks! Thanks for listening. Joint work with many others. Q&A Time
