参考链接：https://github.com/datawhalechina/fun-rec/blob/master/docs/
一、物料侧画像的构建
1.1 新物料来源
物料是通过每天在新闻网站上爬取获取的，爬取新闻详细的内容请参照
[2.2.1.4 Scrapy基础及新闻爬取实战](https://github.com/datawhalechina/fun-rec/blob/master/docs/第二章 推荐系统实战/2.2新闻推荐系统实战/docs/2.2.1.4 scrapy基础及新闻爬取实战.md)。新闻爬取是每天凌晨的时候爬取前一天的新闻，这么做的原因是可以爬到更多的物料，缺点就是物料的时效性会延迟一天，新爬取的物料存储在MongoDB中。
1.2 物料画像的更新
主要从以下2方面考虑：
-
1.新物料画像添加到物料库中
新物料添加到物料库发生在新闻爬取之后，先对新物料进行简单的画像处理，目前定义的画像字段如下（处理后的画像存储在Mongodb）：
image.png
具体的逻辑就是遍历今天爬取的所有文章，然后通过文章的title来判断这篇文章是否已经在物料库中(新闻网站有可能有些相同的文章会出现在多天)来去重。然后再根据定义的一些字段，给画像相应的字段初始化，最后就是存入画像物料池中。
-
2.旧物料画像，通过用户的交互记录进行更新
关于旧物料画像的更新，需要先了解旧物料哪些字段会被用户的行为更新。下面是新闻列表展示页，我们会发现前端会展示新闻的阅读、喜欢及收藏次数。而用户的交互（阅读、点赞和收藏）会改变这些值。
image.png
为了能够实时的在前端显示新闻的这些动态行为信息，我们提前将新闻的动态信息存储到了redis中，线上获取的时候是直接从redis中获取新闻的数据，并且如果用户对新闻产生了交互，那么这些动态信息就会被更新，我们也是直接更新redis中的值，这样做主要是为了能够让前端可以实时的获取的新闻最新的动态画像信息。
通过上面的内容我们了解到，新闻的动态画像的更新是在redis中进行的，而redis又是一个内存数据库，资源是非常宝贵的，我们不能一直将新闻的信息存储在里面，而是每天进行一次更新，只更新那些今天可能会被用来展示的新闻（有些新闻可能从发表到现在太久了，由于新闻的时效性就没有必要再展示了）。所以为了能够保存新闻历史的动态信息，系统还需要每天将redis中的动态新闻信息更新到mongodb存储的新闻画像库中，这里的逻辑也是每天会定时触发，这里的逻辑会放在更新完新物料的画像之后，当然这里两个的先后顺序并没有什么影响，只需要注意更新物料动态画像的时候一定得再redis数据清空之前。
其实这里还有个逻辑需要说明一下，新闻的画像库其实是有两个的，一个被称为是特征库FeatureProtrail, 它存储了物料的所有字段。还有一个是存储前端展示内容的画像库RedisProtrail, 这个画像库中的物料是一样的多，只不过每个物料存储的内容不一样，这个特征库的内容每天都会被更新，作为存储再redis中的新闻内容的备份内容。所以在完成了新、旧物料画像的更新之后，我们需要将最新的物料库中的新闻信息往RedisProtrail物料库中写一份，并去掉一些前端展示不需要的字段内容。
更新完的物料如何添加到redis数据库中。关于新闻内容在redis中的存储，我们将新闻的信息拆成了两部分，一部分是新闻不会发生变化的属性（例如，创建时间、标题、新闻内容等），还有一部分是物料的动态属性，在redis中存储的key的标识分别为：static_news_detail:news_id和dynamic_news_detail:news_id 下面是redis中存储的真实内容
image.png
image.png
这么做的目的是为了线上实时更改物料动态信息的时候更加高效一点。当需要获取某篇新闻的详细信息的时候需要查这两份数据并将数据这两部分数据拼起来最终才发送给前端展示。
二、用户侧画像的构建
主要包括以下两方面：
- 新注册用户画像的更新
- 老用户画像的更新
由于系统中将所有注册过的用户都放到了一个表里面（新、老用户），所以每次更新画像的话只需要遍历一遍注册表中的所有用户。
在具体的画像构建逻辑之前，得先了解一下用户画像中包含哪些字段，下面是直接从mongo中查出来的。
从上面可以看出，主要是用户的基本信息和用户历史信息相关的一些标签。对于用户的基本属性特征这个可以直接从注册表中获取，那么对于跟用户历史阅读相关的信息，需要统计用户历史的所有阅读、喜欢和收藏的新闻详细信息。为了得到跟用户历史兴趣相关的信息，我们需要对用户的历史阅读、喜欢和收藏这几个历史记录给存起来，其实这些信息都可以从日志信息中获取得到，但是这里有个工程上的事情得先说明一下，先看下面这个图，对于每个用户点进一篇新闻的详情页
最底部有个喜欢和收藏，这个前端展示的结果是从后端获取的数据，那就意味着后端需要维护一个用户历史点击及收藏过的文章列表。
此外前面也提到了我们可以使用用户历史阅读的文章做用户画像，为了更好处理和理解，我们也维护了一份用户历史阅读过的所有文章的mysql表（维护表的核心逻辑就是每天跑一边用户日志，更新一下用户历史阅读的记录），那么此时我们其实已经有了用户的阅读、点赞和收藏三个用户行为表了。
三、画像自动化构建
上面分别对用户侧和物料侧的画像构建进行了介绍，接下来就是要将上面所有的过程都自动化运行，并且设置好定时任务，其实最核心的一点就是一定要在清除redis数据之前，完成用户和物料画像的构建，。
大致的执行逻辑就是：
- 先爬取新闻数据，这里需要注意的是，虽然是今天零点爬数据，但是实际上爬的是前一天的新闻；
- 数据爬完之后，离线更新用户画像，物料画像及线上要存储再redis中的画像；
- 最后其实是离线推荐的流程，离线将用户的排序列表存到redis中，线上直接取就行了。
四、总结
本章节很难，需要理清物料和用户的逻辑关系，还要将它们自动联系起来，代码非常多，很容易出现细节问题，所以需要有扎实的基础和强大的内心来运行代码。
