文档

社交行业

更新时间:

在社交领域之中,有很多数据的存储,使用数据的形态也多种多态。目前主流的社交都带推荐模块会把新闻/消息/短文推动给适合的用户。本文简述社交类的基本架构。

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

社交基本架构

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

客户登录后发帖和看帖

  • 客户登录后,系统会记录位置信息,位置信息通过GeoHash处理后,可以存在HBase之中。

  • 客户发帖子时可以将帖子写到HBase之中,发完之后,也可以立即写到推荐之中,可以看到自己发的帖子。

  • 客户浏览帖子,系统记录客户浏览过的帖子的信息,把浏览记录写到HBase之中,以备后续分析反馈给用户特性-用户画像模块。

用户特性-用户画像

  • 用户注册后,会选择感兴趣的特征,此块数据会形成最初的用户特性。

  • 用户浏览信息后,会有浏览的历史记录,会写到HBase之中。

  • 晚上会启动spark或者用户写的code分析用户的历史记录,修正用户的标签画像。

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

推荐及Feeds流

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

  • 当帖子或者文章产生后,会写一份到HBase存储上。

  • 再同时会计算,帖子的属性,分析帖子的归类,提取特征值。

  • 根据帖子的特征值与用户特性-用户画像,把匹配的用户写入到推送的表之中。此块根据不同的业务,可能涉及的逻辑比较复杂,比如加入位置的因素、权重、好友关注的列表、把不活跃的客户剔除。

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

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

帖子新闻查询

  • 用户打开APP,可以查询最近推荐的信息。

    • 对于大V或者运营推送的信息,可以单独链路查询。

    • 查询帖子推荐表,查询出所属的帖子ID后,再查询实际的帖子信息,这部分一般在Redis或者CDN之中有缓存,没有命中,可以查询到业务库HBase之中。

基于位置的推荐人

  • 可以基于存的客户位置的信息,推荐兴趣相投的人。

    • 基于地理信息,查询边上所有的客户,再查询画像表,找到兴趣相投的人,再推荐。

  • 本页导读 (1)
文档反馈