社交类型网站建设怎样解决会员实时抽取系统框架的规划？大型社交网站建设对于实时抽取系统来说，每台服务器可以承载大约1亿用户的用户兴趣挖掘。当用户发布社交网站后，此信息实时进入原始Feed流队列中，语义处理单元针对每条社交网站快速进行语义计算，语义处理单元采取多任务结构，依次对社交网站进行分词、焦点词抽取以及社交网站分类计算。焦点词抽取与传统的关键词抽取有很大差异，因为社交网站比较短小，如果采取传统的TF.IDF框架抽取关键词效果并不好，所以我们提出了焦点词抽取的概念，不仅融合传统的TF.IDF等计算机制，也考虑了单词在句中的出现位置、词性、是否是命名实体、是否是标题等十几种特征来精确抽取社交网站所涉及的主体内容，避免噪声词的出现。社交网站分类则通过统计分类机制将社交网站分到内部定义的多级分类体系中。
当社交网站经过语义处理单元处理后，已经由原始的自然语言方式转换为由焦点词和分类构成的语义表示。每条社交网站有两个关键的Key：社交网站ID和用户ID，经过语义处理后，系统实时将社交网站插入“Feed语义表示Redis数据库”中，每条记录以社交网站ID为key，value则包含对应的UID以及焦点词向量和分类向量。考虑到每天每个用户可能会发布多条社交网站，为了能够有效控制“Feed语义表示Redis数据库”数据规模在一定范围，系统会监控“Feed语义表示Redis数据库”大小，当大小超出一定范围时，即将社交网站数据根据用户ID进行合并进入“User语义表示Redis数据库”。单机实时抽取系统架构如下图所示。
在用户不活跃时段，系统会将“User语义表示Redis数据库”的内容和保存在MySQL中的用户历史兴趣信息进行合并，在合并时会考虑时间衰减因素，将当日社交网站用户新发表的内容和历史内容进行融合。为了提高系统效率，会设立一个历史信息缓存Redis数据库，首先将部分用户的历史数据读入内存，在内存完成合并后写入MySQL进行数据更新。
大型社交网站建设怎样解决离线挖掘
系统出于精准定位用户兴趣的目的，在实时抽取系统已经通过“焦点词抽取”以及历史合并时采取一些特殊合并策略来优化算法，但是通过实际数据分析发现，有些用户的兴趣词向量还包含不少噪声。主要原因在于：社交网站用户在发布社交网站或者转发社交网站时有很大的随意性，并非每条用户发布的社交网站都能够表示用户的兴趣，比如用户转发一条“有奖转发”的社交网站，目的在于希望能够通过转发中奖，所以其社交网站内容并不能反映用户兴趣所在。为了能够更加精准地从用户发布内容定位用户兴趣词，我们通过对实时系统累积的用户历史兴趣进行离线挖掘来进一步优化系统效果。
大型社交网站建设离线挖掘的基本逻辑是：
社交网站用户发布的社交网站有些能够代表个人兴趣，有些不能代表个人兴趣。离线挖掘的基本目标是对实时系统累积的个人兴趣词进行判别，过滤掉不能代表个人兴趣的内容，只保留能够代表个人兴趣的兴趣词。我们假设如果用户具有某个兴趣点，那么他不会只发布一条与此相关的社交网站，一般会发布多条语义相近的社交网站，通过是否经常发布这个兴趣类别的社交网站可以作为过滤依据。比如假设某个用户是苹果产品的忠实用户，那么他可能会经常发布与苹果产品相关内容。但是问题在于，如何知道两条社交网站是否语义相近？更具体而言，通过实时抽取系统累积的用户兴趣已经以若干兴趣词的表示方式存在，那么问题就转换成：如何知道两个单词是否语义相近？如何将语义相近的兴趣词进行聚类？如何判别聚类后的兴趣词？哪些可以保留哪些需要过滤？我们通过图挖掘算法来解决上述问题，将某个用户历史累计的兴趣词构建成一个语义相似图，任意两个单词之间的语义相似性通过计算单词之间的上下文相似性来获得，如果两个单词上下文相似性高于一定值则在图中建立一条边。然后在这个图上运行Pagerank算法来不断迭代给单词节点打分，当迭代结束后，将得分较高的单词保留作为能够表达用户兴趣的兴趣词，而将其他单词作为噪声进行过滤。下图是兴趣词语义相似图的一个具体示例，通过这张图可以看出，如果用户某个兴趣比较突出，则很容易形成一个连接密集的子图。通过在语义相似图上运行Pagerank算法，语义相近的兴趣词会形成得分互相促进加强的作用，密集子图越大，其相互增强作用越明显，最后得分也会越高，所以通过这种方法可以有效识别噪声和真正的用户兴趣。
当社交网站经过语义处理单元处理后，已经由原始的自然语言方式转换为由焦点词和分类构成的语义表示。每条社交网站有两个关键的Key：社交网站ID和用户ID，经过语义处理后，系统实时将社交网站插入“Feed语义表示Redis数据库”中，每条记录以社交网站ID为key，value则包含对应的UID以及焦点词向量和分类向量。考虑到每天每个用户可能会发布多条社交网站，为了能够有效控制“Feed语义表示Redis数据库”数据规模在一定范围，系统会监控“Feed语义表示Redis数据库”大小，当大小超出一定范围时，即将社交网站数据根据用户ID进行合并进入“User语义表示Redis数据库”。单机实时抽取系统架构如下图所示。
在用户不活跃时段，系统会将“User语义表示Redis数据库”的内容和保存在MySQL中的用户历史兴趣信息进行合并，在合并时会考虑时间衰减因素，将当日社交网站用户新发表的内容和历史内容进行融合。为了提高系统效率，会设立一个历史信息缓存Redis数据库，首先将部分用户的历史数据读入内存，在内存完成合并后写入MySQL进行数据更新。
大型社交网站建设怎样解决离线挖掘
系统出于精准定位用户兴趣的目的，在实时抽取系统已经通过“焦点词抽取”以及历史合并时采取一些特殊合并策略来优化算法，但是通过实际数据分析发现，有些用户的兴趣词向量还包含不少噪声。主要原因在于：社交网站用户在发布社交网站或者转发社交网站时有很大的随意性，并非每条用户发布的社交网站都能够表示用户的兴趣，比如用户转发一条“有奖转发”的社交网站，目的在于希望能够通过转发中奖，所以其社交网站内容并不能反映用户兴趣所在。为了能够更加精准地从用户发布内容定位用户兴趣词，我们通过对实时系统累积的用户历史兴趣进行离线挖掘来进一步优化系统效果。
大型社交网站建设离线挖掘的基本逻辑是：
社交网站用户发布的社交网站有些能够代表个人兴趣，有些不能代表个人兴趣。离线挖掘的基本目标是对实时系统累积的个人兴趣词进行判别，过滤掉不能代表个人兴趣的内容，只保留能够代表个人兴趣的兴趣词。我们假设如果用户具有某个兴趣点，那么他不会只发布一条与此相关的社交网站，一般会发布多条语义相近的社交网站，通过是否经常发布这个兴趣类别的社交网站可以作为过滤依据。比如假设某个用户是苹果产品的忠实用户，那么他可能会经常发布与苹果产品相关内容。但是问题在于，如何知道两条社交网站是否语义相近？更具体而言，通过实时抽取系统累积的用户兴趣已经以若干兴趣词的表示方式存在，那么问题就转换成：如何知道两个单词是否语义相近？如何将语义相近的兴趣词进行聚类？如何判别聚类后的兴趣词？哪些可以保留哪些需要过滤？我们通过图挖掘算法来解决上述问题，将某个用户历史累计的兴趣词构建成一个语义相似图，任意两个单词之间的语义相似性通过计算单词之间的上下文相似性来获得，如果两个单词上下文相似性高于一定值则在图中建立一条边。然后在这个图上运行Pagerank算法来不断迭代给单词节点打分，当迭代结束后，将得分较高的单词保留作为能够表达用户兴趣的兴趣词，而将其他单词作为噪声进行过滤。下图是兴趣词语义相似图的一个具体示例，通过这张图可以看出，如果用户某个兴趣比较突出，则很容易形成一个连接密集的子图。通过在语义相似图上运行Pagerank算法，语义相近的兴趣词会形成得分互相促进加强的作用，密集子图越大，其相互增强作用越明显，最后得分也会越高，所以通过这种方法可以有效识别噪声和真正的用户兴趣。
在具体实现时，因为每次运算都是在单个用户基础上，记录之间无耦合性，所以非常适合在Hadoop平台下使用MapReduce来分布计算，加快运算效率。深圳网站建设公司总结用户兴趣建模在社交网站环境下有着非常重要的作用，一个好的用户兴趣建模系统可以有效支持个性化推荐、搜索以及个性化广告推送系统。博纳网络本文主要从体系结构角度，简单介绍了社交网站用户兴趣建模分布式体系结构，并介绍了其中比较关键的数据挖掘算法。好了，本文关于“社交类型网站建设怎样解决会员实时抽取系统框架的规划？”的框架解决方案就分享到这里，谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/solution/14427.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。