推荐系统总结

Flume分布式数据采集，用户行为数据

数据采集

sqoop全量数据导入

定时任务

sqoop增量数据导入

数据迁移

数据融合模块

一切能够刻画这个物品的数据都属于物品画像

TF 词频

IDF 逆文档词频，可以有效的抑制语气词

Hive：Keyword_idf表

Hive：Keyword_tf_idf表

1.TF-IDF指标

节目描述信息提取关键词

创作时间

上映时间

节目时长

。。。。。。

节目基本属性

物品画像

Hive：item_profile表

一切能够刻画这个用户的数据都属于用户画像

历史浏览的节目的关键词

衰减系统1/(log(n)+1)

浏览时间

喜好分值

浏览时长

分值

用户行为数据

省份

城市

分类算法

离散值（如：职业）

回归算法

连续值（如：薪资）

信息补全方式

用户基本属性

用户画像

rowkey：userId

itemID

kw|score

label

province

city

info

列簇

Hbase：user_profile表

构建画像模块

TF-IDF

Word2Vec

节目向量化

Hive:tmp_keyword_weightHbase:tmp_keyword_weight

KMeans算法

LSH局部敏感Hash算法

计算节目的相似性

rowkey：itemid

itemid（另一个节目的id）

score（相似度）

similar

列族

Hbase：program_similar

计算节目的相似度

基于用户历史浏览的节目召回相似的节目

内容召回策略

Hbase：recall：content、History_recall

基于用户对节目的评分矩阵，采用LFM隐语义模型算法构建两个隐语义矩阵，优化算法：ALS

行为召回策略

Hbase：recall：als、History_recall

1.基于用户浏览时长计算出观看百分比

2.Redis hot+1zincrby

流式计算框架去实时统计节目的热度

redis：Sorted Set 类型

热门召回策略

实时计算

内容召回

实时召回策略

Hbase：recall：online、History_recall

防止出现冷启动问题

增加推荐列表的新颖性

信息茧房问题：看了军事的内容，之后推荐的都是军事的内容，导致视野变小

防止信息茧房问题

多路召回

召回策略模块

有效的解决冷启动问题

基于所有用户的行为数据构建 

特点：明确得知用户对物品的喜好程度，如：评价系统

显式

特点：无法准确的得知用户对物品的喜好程度

隐式

反馈数据类型

redis：投建用户画像部分的特征索引

0：不喜欢

1：喜欢

label标签

构建训练集

算法：分类算法 SparkMLib  LogisticRegress

保存模型参数

TP

TN

FP

FN

混淆矩阵

acc=（TP+TN)/(P+N)

正确率

pre=TP/(TP_FP)

准确率

recall=TP/P

召回率

2/(1/pre+1/recall)

F-measure

模型评估指标

排序模型模块 ctr预估

Hbase：ctr_feature

key：index

value：weight

Redis：model

特征索引

基于用户的召回结果构建测试样本

测试样本+model = 预测score

生产者

HashMap集合 排序 TopN

消费者

微服务模块

基线桶

实验桶

AB test

基线桶1

基线桶2

AAB test

A/B Test模块

1.避免创建重复的RDD

2.尽可能复用同一个RDD

cache

Memory_only

memory_only_ser

memory_and_disk

DISK相关的持久化策略以及带有_2的 不要用

persist

unpersist

3.频繁使用的RDD进行持久化

每个Executor一份

4.尽可能多的使用广播变量

mapPartition

foreachPartition

reduceBykey

AggregateBykey

combinBykey

mapPartitionWithIndex

5.尽可能多的使用高性能算子

map都存在combine

代码调优

1.提前预聚合

1、改变HDFS Block个数 （不建议，复杂）

2.初始化RDD的时候，设置分区数

3.使用shuffle类算子的时候，设置并行度 reduceByKey、join

conf.set（“spark.default.parallelism”，10）

spark-submit --conf spark.default.parallelism =10（推荐）

全局：spark-default.conf

4.spark.default.parallelism

coalesce（numPartitions，isShuffle）

5.repartition、coalesce算子 增加RDD的分区数

2.提高并行度

sample采样、wc计算、filter过滤

3.过滤掉导致数据倾斜的key

1.随机加前缀

2.第一次聚合

3.去掉前缀

4.第二次聚合

4.双重reduce聚合

1.筛选导致数据倾斜的key

2.分拆RDD

3.一个RDD添加N以内随机前缀

4.另一个RDD扩容N倍

5.聚合

6.union

5.join添加随机前缀+分拆RDD

全局加随机前缀，全局扩容N倍

6.join导致数据倾斜的key过多

数据倾斜的解决方案

PROCESS_LOCAL

task计算的数据在本节点的磁盘上

task计算的数据在本节点的其他的进程内存中

NODE_LOCAL

NO_PREF

RACK_LOCAL

ANY

本地化级别

spark.locality.wait=3S//等待节点本地化时间spark.locality.wait.node = spark.locality.wait//等待进程本地化时间spark.locality.wait.process = spark.locality.wait//等待机架本地化时间spark.locality.wait.rack = spark.locality.wait通过spark.locality.wait 来调优默认是3S 可以提高等待时间增加本地化的级别但是调优要有度！！！时间太高，会影响整体执行时间反而过长。

调优

1.PROCESS_LOCAL如果等待时间超过3s，Driver重新在此往Executor1中发送，5次后还不能执行判定Executor资源满了。降低一级数据本地化级别变为 NODE_LOCAL

2.NODE_LOCAL如果等待3s，重试5次 不能执行；再次降一级

3.RACK_LOCAL依次类推

任务的流程

数据本地化

资源调优是计算框架调优的根本

注意点：核心支持超线程，一个core分配两个thread24个cores  Spark_worker_cores 48不要忘记预留出25%给系统自己用，剩下的75%来分配

如果需要10台机器的集群，需要采购11台，有一台作为client用1、安全 2.、性能差异

1.加大集群管理的资源Yarn standalone

--executor-cores

--executor-memory

--total-executor-cores

2.增加Executor使用的资源

3.调高任务的并行度

资源调优

Spark调优模块

推荐系统