社交行业
简述
在社交领域之中,有很多数据的存储,使用数据的形态也多种多态。目前主流的社交都会带推荐模块的,也就是会把新闻/消息/短文 推动给合适的人,也会考虑地理位置的信息。本文简述社交类的基本架构,考虑的一些因素。细节点会在不同的社交类场景之中,有一定的优化,但是大同小异,基本架构如下:
社交领域的基本架构及流程流
上图是社交领域的基本架构,分为以下基本部分
客户登录及发帖及看帖
- 客户登录后,系统会记录位置信息,位置信息 GeoHash处理后,可以存在
云HBase
之中 - 客户可以 发帖子,此块帖子可以写到
云HBase
之中,发完之后,也可以立即写到推荐之中,自己可以看到自己发的帖子 - 客户浏览帖子,系统记录 客户看过的帖子的信息,把浏览记录 写到
云HBase
之中,以备后续 分析 反馈给用户特性 - 用户画像
模块
会有 帖子/新闻
的表,量也比较大,一般在1T-1P左右。
用户特性 - 用户画像
- 用户注册后,会选择感兴趣的特征,此块数据会形成最初的
用户特性
- 用户浏览信息后,会有浏览的历史记录,会写到
云HBase
之中 - 晚上会启动
spark
或者用户写的code
分析用户的历史记录,修正用户的标签画像
最终会形成一张 用户特性 - 用户画像表
推荐及Feeds流
一般有两个模型,分表为 推模型
,拉模型
,最主要是以帖子为维度
还是以 查询的 人为维度
。推模型
是 写放大的,拉模型
是读放大的。 HBase基于LSM,比较适合推模型
- 当帖子或者文章产生后,会写一份到
云HBase
存储上 - 再同时会计算,帖子的属性,分析帖子的归类,提取
特征值
- 根据 帖子的
特征值
与用户特性 - 用户画像
,把匹配的用户写入 到 推送的表之中。此块 根据不同的业务,可能涉及的逻辑比较复杂,比如加入 位置的因素 、 权重 、好友关注的列表 、把不活跃的客户剔除。
会形成一张 帖子推荐表
,数据量比较大,大约1T到100T左右。会有过期时间,一般在3天-4天左右。
对于大V或者写运营普发的信息,可以采取拉模式,可以显著减少写放大。一般实际的业务是 推模型
与 拉模型
混合使用
帖子新闻查询
- 用户打开APP,可以查询最近推荐的信息
- 对于 大V 或者 运营推送的信息,可以单独链路查询
- 查询
帖子推荐表
,查询出所属的帖子ID后,再查询实际的帖子信息,这部分一般在 redis 或者 CDN之中有缓存,没有命中,可以查询到 业务库云HBase
之中
基于位置的推荐人
- 可以基于存的客户位置的信息,推荐边上 兴趣相投的人
- 基于地理信息,查询边上所有的客户,再查询画像表,找个兴趣相投的人,再推荐
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
评论