简述

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

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

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

客户登录及发帖及看帖

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

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

用户特性 - 用户画像

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

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

推荐及Feeds流

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

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

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

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

帖子新闻查询

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

基于位置的推荐人

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