今日头条user profile系统架构实践_丁海峰


今⽇头条 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
还剩24页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

樂鲁伊

贡献于2017-08-28

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf