全部产品

社交行业

更新时间:2018-08-13 21:05:09

简述

在社交领域之中,有很多数据的存储,使用数据的形态也多种多态。目前主流的社交都会带推荐模块的,也就是会把新闻/消息/短文 推动给合适的人,也会考虑地理位置的信息。本文简述社交类的基本架构,考虑的一些因素。细节点会在不同的社交类场景之中,有一定的优化,但是大同小异,基本架构如下:

社交领域的基本架构及流程流

社交基本架构

上图是社交领域的基本架构,分为以下基本部分

客户登录及发帖及看帖

  • 客户登录后,系统会记录位置信息,位置信息 GeoHash处理后,可以存在 云HBase 之中
  • 客户可以 发帖子,此块帖子可以写到 云HBase 之中,发完之后,也可以立即写到推荐之中,自己可以看到自己发的帖子
  • 客户浏览帖子,系统记录 客户看过的帖子的信息,把浏览记录 写到 云HBase 之中,以备后续 分析 反馈给 用户特性 - 用户画像 模块

会有 帖子/新闻 的表,量也比较大,一般在1T-1P左右。

用户特性 - 用户画像

  • 用户注册后,会选择感兴趣的特征,此块数据会形成最初的用户特性
  • 用户浏览信息后,会有浏览的历史记录,会写到 云HBase之中
  • 晚上会启动 spark 或者 用户写的code 分析用户的历史记录,修正用户的标签画像

最终会形成一张 用户特性 - 用户画像表

推荐及Feeds流

一般有两个模型,分表为 推模型拉模型 ,最主要是以帖子为维度还是以 查询的 人为维度推模型 是 写放大的,拉模型是读放大的。 HBase基于LSM,比较适合推模型

  • 当帖子或者文章产生后,会写一份到 云HBase 存储上
  • 再同时会计算,帖子的属性,分析帖子的归类,提取 特征值
  • 根据 帖子的特征值用户特性 - 用户画像,把匹配的用户写入 到 推送的表之中。此块 根据不同的业务,可能涉及的逻辑比较复杂,比如加入 位置的因素 、 权重 、好友关注的列表 、把不活跃的客户剔除。

会形成一张 帖子推荐表,数据量比较大,大约1T到100T左右。会有过期时间,一般在3天-4天左右。

对于大V或者写运营普发的信息,可以采取拉模式,可以显著减少写放大。一般实际的业务是 推模型拉模型 混合使用

帖子新闻查询

  • 用户打开APP,可以查询最近推荐的信息
    • 对于 大V 或者 运营推送的信息,可以单独链路查询
    • 查询 帖子推荐表,查询出所属的帖子ID后,再查询实际的帖子信息,这部分一般在 redis 或者 CDN之中有缓存,没有命中,可以查询到 业务库 云HBase 之中

基于位置的推荐人

  • 可以基于存的客户位置的信息,推荐边上 兴趣相投的人
    • 基于地理信息,查询边上所有的客户,再查询画像表,找个兴趣相投的人,再推荐