@      数据人看Feed流-架构实践

当前位置: 亚博体育里的钱怎么提现 > 新闻中心 > 数据人看Feed流-架构实践

数据人看Feed流-架构实践

消费者收信箱hbase表设计如下,其中序列号要保证递增,一般用时间戳即可,特别高频情况下可以用一个RDS来制造序列号

图9 起步架构

我们常见的Feed流场景有:

图8 基于推荐的Feed流架构

4 头条,用户获取系统推荐的新闻、评论、八卦

本人水平有限,根据自身的经验向大家推荐一种迭代路径以供参考,如有不同意见欢迎交流

Feed信息流是互联网场景中非常普遍的场景,遍布于电商、社交、新媒体等APP,因此研究Feed流是非常有价值的一件事情。本文总结了Feed流的业务场景和主流架构,分析了不同场景、体量下技术的难点与瓶颈。对Dispatcher、Inbox、Outout几个组件进行了详细的演进介绍,提供了基于云环境的落地方案。本人水平有限,希望可以抛砖引玉,欢迎大家一起探讨。Feed流的架构演进还在持续,不同业务场景下还有哪些缺陷和痛点?数据产品如何从功能和性能上演进来支撑Feed流的持续发展?在这些问题的驱动下,云HBase未来将会大力投入到Feed流场景的持续优化和赋能!

希望吸引更多的生产者和消费者(PV、UV),用户更长的停留时间,广告、商品更高的转化率

起步架构如图9,使用云Kafka 云HBase。如果对Inbox有检索需求,建议使用HBase的scan filter即可。

数据量逐渐增大后,对推模式进一步迭代,主要需求是

原文链接:https://yq.aliyun.com/articles/707097?utm_content=g_1000064837

希望信息支持格式丰富(文字、图片、视频),发布流畅(生产信息的可用性),订阅者及时收到消息(时效性),订阅者不漏消息(传递的可靠性)

新浪微博为例,作为移动社交时代的重量级社交分享平台,2017年初日活跃用户1.6亿,月活跃用户近3.3亿,每天新增数亿条数据,总数据量达千亿级,核心单个业务的后端数据访问QPS高达百万级

图6 基于关系传递的纯推模式

[5] feed流个性化推荐架构和算法分享 https://blog.csdn.net/baymax_007/article/details/89853030

Feed流:可以理解为信息流,解决的是信息生产者与信息消费者之间的信息传递问题。

[4] 新浪微博架构和FEED架构分析 http://blog.sina.com.cn/s/blog_53b95aec0100ujim.html

业务迅猛发展,消息和用户增长迅速,僵尸账号、非活跃账号较多,信息过载严重

图5 消息传递的推模式和拉模式

Rowkey消息元数据列状态列其它列MD5(用户ID) 用户ID 序列号消息ID、作者、发布时间、关键字等已读、未读

原标题:数据人看Feed流-架构实践

1 手淘,微淘提供给消费者的首页商品信息,用户关注店铺的新消息等

图11 基于推荐的推拉混合架构

(来自 今日头条推荐系统架构设计实践https://yq.aliyun.com/go/articleRenderRedirect?spm=a2c4e.11153940.0.0.73fe1781Ewxvic&url=https://yq.aliyun.com/download/602)

本文作者:daniel.meng

[2] Feed系统架构与Feed缓存模型 https://mp.weixin.qq.com/s/RmDLqQmXQAmtQrajoanNuA?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com

---------------------------------------

上面还是两大巨头的历史指标,假设一条消息1KB那么千亿消息约93TB的数据量,日增量在几百GB规模且QPS高达百万,因此需要一个具备高读写吞吐,扩展性良好的分布式存储系统。用户浏览新消息期望百毫秒响应,希望新消息在秒级或者至少1分钟左右可见,对系统的实时性要求很高,这里需要多级的缓存架构。系统必须具备高可用,良好的容错性。最后这个系统最好不要太贵。

因此我们需要一个高吞吐、易扩展、低延迟、高可用、低成本的Feed流架构

[1] Feed架构-我们做错了什么 https://timyang.net/architecture/feed-data-arch-cons/

综上,个人推荐使用HBase存储

(来自 Feed系统架构与Feed缓存模型https://yq.aliyun.com/go/articleRenderRedirect?url=https://mp.weixin.qq.com/s/RmDLqQmXQAmtQrajoanNuA?spm=a2c4e.11153940.0.0.73fe1781Ewxvic&utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com)

图6是纯推模式的架构,该架构有3个关键的部分

Feed流参与者的价值

图3 使用HBase存储Feed流消息

对于关系服务,其写入操作是建立关系和删除关系,读取操作是获取关系列表,逻辑上仅需要一个KV系统。如果数据量较少可以使用RDS,如果数据量较大推荐使用HBase。如果对关系的QPS压力大可以考虑用Redis做缓存。

在业务发展的初期,用户量和资源都没有那么多,团队的人力投入也是有限的,不可能一上来就搞一个特别复杂的架构,“够用”就行了,重要的是

1 Feed流当前的主流架构以及落地方案

本文为云栖社区原创内容,未经允许不得转载。

展开全文

关于Feed流的架构设计,包括以上场景中的很多业内专家给出了相应的思考、设计和实践。本人是大数据方向出身的技术人,所在的团队参与了阿里手淘、微淘Feed流的存储层相关服务,我们的HBase/Lindorm数据存储产品在公有云上也支持着Soul、趣头条、惠头条等一些受欢迎的新媒体、社交类产品。我们在数据存储产品的功能、性能、可用性上的一些理解,希望对真实落地一个Feed流架构可以有一些帮助,以及一起探讨Feed流的未来以及数据产品如何帮助Feed流进一步迭代。

3 微博,粉丝获取关注明星、大V的信息

随着业务的增长,推模式资源浪费会越发严重。原因在于两点:第一存在着大量的僵尸账号,以及大比例的非活跃用户几天或者半个月才登陆一次;第二信息过载,信息太多,重复信息太多,垃圾信息太多,用户感觉有用的信息少,消息的阅读比例低。这种情况下推模式相当一部分在做无用功,白白浪费系统资源。

希望及时收到关注的消息(时效性),希望不错过朋友、偶像的消息(传递的可靠性),希望获得有价值的消息(解决信息过载)

进一步的迭代架构如图10

Feed流的技术难点

2 一个初创公司如何选择Feed流的架构演进路径

截止2016年12月底,头条日活跃用户7800W,月活跃用户1.75亿,单用户平均使用时长76分钟,用户行为峰值150w msg/s,每天训练数据300T (压缩后),机器规模万级别

图4 用户关系存储

消息本身应该算是一种半结构化数据(包含文字,图片,短视频,音频,元数据等)。其读写吞吐量要求高,读写比例需要看具体场景。总的存储空间大,需要很好的扩展性来支撑业务增长。消息可能会有多次更新,比如内容修改,浏览数,点赞数,转发数(成熟的系统会独立一个counter模块来服务这些元数据)以及标记删除。消息一般不会永久保存,可能要在1年或者3年后删除。

使用云Kafka 云HBase 云Redis

是推?是拉?还是混合?没有最好的架构,只有适合的场景~

图7 基于关系传递的推拉混合模式

2 微信朋友圈,及时获取朋友分享的信息

图10 纯推模式的演进

讲到Feed流一定会有关于推模式和拉模式的讨论,推模式是把消息复制N次发送到N个用户的收信箱,用户想看消息时从自己的收信箱直接获取。拉模式相反,生产者的消息写入自己的发信箱,用户想看消息时从关注的M个发信箱中收集消息。

推模式实现相对简单,时效性也比较好。拉模式要想获得好的性能需要多级的缓存架构。推模式重写,拉模式重读,Feed流场景下写的聚合效果要优于读,写可以大批量聚合。N越大,写入造成的数据冗余就越大。M越大,读消耗的资源越大。

[3] 今日头条推荐系统架构设计实践 https://yq.aliyun.com/download/602

图2 Feed流消息、关系的存储

图1 Feed流简单抽象

图1是对Feed流的最简单抽象,完成一个从生产者向消费者传递消息的过程。

首先,用户在APP侧获得的是一个Feed ID列表,这个列表不一定包含了所有的新消息,用户也不一定每一个都打开浏览,如果传递整个消息非常浪费资源,因此产生出来的消息首先生成主体和索引两个部分,其中索引包含了消息ID和元数据。其次一个应用总是存在关系,基于关系的传递是必不可少的,也因此一定有一个关系的存储和查询服务。

图8是基于推荐的模型,可以看出它是在推拉结合的模式上融合了推荐系统。

一种是基于关系的消息传递,关系通过加好友、关注、订阅等方式建立,可能是双向的也可能是单向的。一种是基于推荐算法的,系统根据用户画像、消息画像利用标签分类或者协同过滤等算法向用户推送消息。微信和微博偏向于基于关系,头条、抖音偏向于基于推荐。

初创公司的迭代路径

图7是推拉结合的模式

本文希望可以提供两点价值:

互联网场景总是需要一定规模才能体现出技术的瓶颈,下面我们先看两组公开数据: