11.1 黑马头条推荐业务架构介绍
1.1.1业务
在头条APP海量用户与海量文章之上,使用lambda大数据实时和离线计算整体架构,利用黑马头条用户在APP上的点击行为、浏览行为、收藏行为等建立用户与文章之间的画像关系,通过机器学习推荐算法进行智能推荐
1.1.2 架构与业务流
- 1、用户的行为收集,业务数据收集
- 2、批量计算(离线计算):用户文章画像
- 3、用户的召回结果、排序精选过程
- 4、grpc的实时推荐业务流的搭建
- 缓存
1.3 开发环境介绍
1.3.1 虚拟机设备
1.3.3 python环境
- 分布式环境:Hbase会遇到三台时间同步的问题
- python环境:三台也都必须安装
2.2 数据库迁移
2.2.1 数据库迁移需求
- 业务数据:133,134,135, 136
- web
- 推荐系统:137,138,139
- 导入过来,增量更新
- hadoop的hive数据仓库
- 同步一份数据在集群中方便进行数据分析操作
- 用户资料信息呢两张表:user_profile,user_basic
- 文章内容基本信息、频道三张表:news_article_basic,news_article_content,news_channel
2.2.2.2 Sqoop 迁移
业务数据导入问题
- 新增的用户、文章
- 修改的用户信息、文章信息
两种导入形式,我们选择增量,定期导入新数据
- sqoop全量导入
- 不需要创建HIVE表
- sqoop增量导入
- append
- incremental
- 直接sqoop导入到hive(–incremental lastmodified模式不支持导入Hive )
- sqoop导入到hdfs,然后建立hive表关联
2.2.2.3 Sqoop 迁移案例
sqoop 导出的 hdfs 分片数据,都是使用逗号 ,
分割
于 hive 默认的分隔符是 /u0001
(Ctrl A)
Mysql导入对应hive类型:
代码语言:javascript复制MySQL(bigint) --> Hive(bigint)
MySQL(tinyint) --> Hive(boolean)
MySQL(int) --> Hive(int)
MySQL(double) --> Hive(double)
MySQL(bit) --> Hive(boolean)
MySQL(varchar) --> Hive(string)
MySQL(decimal) --> Hive(double)
MySQL(date/timestamp) --> Hive(string)
注意:1、连接JDBC的IP 地址 或者主机名是否错误 2、确认mysql数据库打开并且能够sqoop测试成功
- 并且mysql表中存在tinyibt,必须在connet中加入: ?tinyInt1isBit=false
- 防止默认到HIVE中,字段默认会被转化为boolean数据类型
4、news_channel与用户两张表一起导入
5、news_article_content
- 全量导入(表只是看结构,不需要在HIVE中创建,因为是直接导入HIVE,会自动创建news_article_content)
2.2.3 crontab-shell脚本定时运行
- 创建一个定时运行的脚本
- crontab -e
- 写入定时执行的命令:
- */30 * * * * /root/toutiao_project/scripts/import_incremental.sh
- 启动服务
- service crond start/stop
2.2.3 总结
- sqoop导入业务数据到hadoop操作
- append, lastmodifield
- 增量导入形式
2.3 用户行为收集到HIVE
2.3.1 为什么要收集用户点击行为日志
- 便于了解分析用户的行为、喜好变化
- 为用户建立画像提供依据
2.3.2 用户日志如何收集
2.3.2.1 埋点开发测试流程
- 埋点参数:
- 就是在应用中特定的流程收集一些信息,用来跟踪应用使用的状况,后续用来进一步优化产品或是提供运营的数据支撑
- 1、PM(项目经理)、算法推荐工程师一起指定埋点需求文档
- 2、后端、客户端 APP集成
- 3、推荐人员基于文档埋点测试与梳理
2.3.2.2 黑马头条文章推荐埋点需求整理
- 埋点事件号:
- 停留时间
-
- read
- 点击事件
-
- click
- 曝光事件(相当于刷新一次请求推荐新文章)
-
- exposure
- 收藏事件
-
- collect
- 分享事件
-
- share
- 埋点参数文件结构
- 曝光的参数:下拉刷新,推荐新的若干篇文章
- 我们将埋点参数设计成一个固定格式的json字符串
2.3.3 离线部分-用户日志收集
通过flume将业务数据服务器A的日志收集到hadoop服务器hdfs的hive中
2.3.3 Supervisor进程管理
很方便的监听、启动、停止、重启一个或多个进程
- 使用
- 1、配置 supervisor开启配置文件在哪里
- /etc/supervisor/
- 2、配置.conf ,reco.conf
- 3、写入配置格式
- 4、开启supervisor, 启动 supervisord -c /etc/supervisord.conf
- 5、supervisorctl管理进程
- 1、配置 supervisor开启配置文件在哪里
2.3.4 supervisor 启动监听flume收集日志程序
2.3.6 总结
- 用户行为日志收集的相关工作流程
- flume收集到hive配置
- supervisor进程管理工具使用
2.1 离线画像业务介绍
文章内容标签化:内容标签化,根据内容定性的制定一系列标签,这些标签可以是描述性标签。针对于文章就是文章相关的内容词语。
- 文章:频道ID内容,关键词、主题词
用户画像:研究用户对内容的喜好程度
2.4 离线文章画像计算
离线文章画像组成需求
- 文章画像,就是给每篇文章定义一些词。
- 关键词:文章中一些词的权重(TFIDF与texrank)高的。
- 主题词:是进行规范化处理的,文章中出现的同义词,计算结果出现次数高的词。
- 共性的词
1、原始文章表数据合并得到文章所有的词语句信息
- 文章标题 文章频道名称 文章内容组成文章完整内容
2.4.1 原始文章数据的合并
- 初始化spark信息配置,定义一个积基类
2.4.1.1 创建Spark初始化相关配置
- 合并三张表内容,到一张表当中,写入到HIVE中
- article数据库:存放文章计算结果
- article_data
- 建议初始化spark , SparkSessionBase
jupyter notebook先把代码写好,测试好
2.4.1.2 进行合并计算
3、新建merge_data.ipynb文件
- 初始化spark信息
- 读取文章进行处理合并
- DF 进行注册一个表,temp合并文章频道名称
2.4.2 Tfidf计算
article_data
2.4.2.1 目的
2、所有历史文章Tfidf计算
2.4.2.2TFIDF模型的训练步骤
- 读取N篇文章数据
- 文章数据进行分词处理,得到分词结果
- 分词用的词库,三台都需要上传
- 先计算分词之后的每篇文章的词频,得到CV模型
- 然后根据词频计算IDF以及词,得到IDF模型
- 训练idf模型,保存
- cv * log(C1出现文章次数/总文章数量)
- 不同词列表,所有的词的IDF的值
- 利用模型计算N篇文章数据的TFIDF值
- tfidf_keywords_values:结果结果
- 用到idf_keywords_values这个表: 词以索引的对应关系
- 对于每篇文章的每个词的权重做排序筛选
- tfidf_keywords_values:结果结果
3、所有历史文章TextRank计算
- 定义:通过词之间的相邻关系构建网络,然后用PageRank迭代计算每个节点的rank值,排序rank值即可得到关键词
- 词之间的相邻关系构建网络
- PageRank迭代计算每个节点的rank值(每个词,网页
- 利用图模型来提取文章中的关键词
举例:10篇文章
- 关键词评分:权重
2.4.3.1 文章的TextRank计算
- jieba.analyse.TextRank
- textrank_model
- textrank_model = TextRank(window=5, word_min_len=2)
- textrank_model
textrank_keywords_values
tfidf_keywords_values