赞
踩
今天向大家介绍一个帮助往届学生完成的毕业设计项目,基于hadoop大数据的音乐推荐系统。
1.4 Hadoop优势(4高)
1.5 Hadoop 组成(面试重点)
1.5.1 HDFS 架构概述
Hadoop Distributed File System
,简称
HDFS
,是一个分布式文件系统(1
)
NameNode
(
nn
):存储文件的
元数据
,如
文件名,文件目录结构,文件属性
(生成时间、副本数、文件权限),以及每个文件的
块列表
和
块所在的
DataNode
等。(2
)
DataNode(dn)
:在本地文件系统
存储文件块数据
,以及
块数据的校验和
。(3
)
Secondary NameNode(2nn)
:
每隔一段时间对
NameNode
元数据备份
。简单的说就是NameNode就相当于一个目录,一个索引,负责标记每一个DataNode的存放位置 而DataNode才是真正存放数据的, Secondary NameNode(2nn) :相当与老板的一个秘书,他会备份 一部分 数据,不会备份全部数据。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
1.5.2 YARN 架构概述
Yet Another Resource Negotiator
简称
YARN
,另一种资源协调者,是
Hadoop
的资源管理器。1.5.3 MapReduce 架构概述
MapReduce
将计算过程分为两个阶段:
Map
和
Reduce(1
)
Map
阶段并行处理输入数据(2
)
Reduce
阶段对
Map
结果进行汇总1.5.4 HDFS**、YARN、**MapReduce 三者关系
YARN
用户提交任务,任务给到ResourceManager,ResourceManager 会找一个节点**NodeManager,**开启一个Container ,把任务(App Mstr)放在Container App Mstr会向
ResourceManager申请说自己需要多少资源 ResourceManager 看哪一个DataNode有资源,给他分配资源 之后 App Mstr 会在被分配的资源节点上开启计算任务(MapTask ),这个其实就是MapReduce 的map阶段,之后会返回一个Reduce到各自对应的节点,这就是他们三者之间的关系
推荐系统广泛存在于各类网站中,作为一个应用为用户提供个性化的推荐。它需要一些用户的历史数据,一般由三个部分组成:基础数据、推荐算法系统、前台展示**。基础数据包括很多维度,包括用户的访问、浏览、下单、收藏,用户的历史订单信息,评价信息等很多信息;推荐算法系统主要是根据不同的推荐诉求由多个算法组成的推荐模型;前台展示主要是对客户端系统进行响应,返回相关的推荐信息以供展示。**
基础数据主要包括:
其实这些用户的偏好信息可以分为两类:
显式的用户反馈能准确的反应用户对物品的真实喜好,但需要用户付出额外的代价,而隐式的用户行为,通过一些分析和处理,也能反映用户的喜好,只是数 据不是很精确,有些行为的分析存在较大的噪音。但只要选择正确的行为特征,隐式的用户反馈也能得到很好的效果,只是行为特征的选择可能在不同的应用中有很 大的不同,例如在电子商务的网站上,购买行为其实就是一个能很好表现用户喜好的隐式反馈。
推荐引擎的分类可以根据很多指标进行区分:
这是一个最基本的推荐引擎分类,其实大部分人们讨论的推荐引擎都是将个性化的推荐引擎,因为从根本上说,只有个性化的推荐引擎才是更加智能的信息发现过程。
其实在现在的推荐系统中,很少有只使用了一个推荐策略的推荐引擎,一般都是在不同的场景下使用不同的推荐策略从而达到最好的推荐效果,例如 Amazon 的推荐,它将基于用户本身历史购买数据的推荐,和基于用户当前浏览的物品的推荐,以及基于大众喜好的当下比较流行的物品都在不同的区域推荐给用户,让用户 可以从全方位的推荐中找到自己真正感兴趣的物品。
迄今为止,在个性化推荐系统中,协同过滤技术是应用最成功的技术。目前国内外有许多大型网站应用这项技术为用户更加智能的推荐内容。
第一代协同过滤技术是基于用户的协同过滤算法,基于用户的协同过滤算法在推荐系统中获得了极大的成功,但它有自身的局限性。因为基于用户的协同过滤算法先计算的是用户与用户的相似度(兴趣相投,人以群分物以类聚),然后将相似度比较接近的用户A购买的物品推荐给用户B,专业的说法是该算法用最近邻居(nearest-neighbor)算法找出一个用户的邻居集合,该集合的用户和该用户有相似的喜好,算法根据邻居的偏好对该用户进行预测。
基于用户的推荐逻辑有两个问题:冷启动与计算量巨大。基于用户的算法只有已经被用户选择(购买)的物品才有机会推荐给其他用户。在大型电商网站上来讲,商品的数量实在是太多了,没有被相当数量的用户购买的物品实在是太多了,直接导致没有机会推荐给用户了,这个问题被称之为协同过滤的“冷启动”。另外,因为计算用户的相似度是通过目标用户的历史行为记录与其他每一个用户的记录相比较的出来的,对于一个拥有千万级活跃用户的电商网站来说,每计算一个用户都涉及到了上亿级别的计算,虽然我们可以先通过聚类算法经用户先分群,但是计算量也是足够的大。
第二代协同过滤技术是基于物品的协同过滤算法,基于物品的协同过滤算法与基于用户的协同过滤算法基本类似。他使用所有用户对物品或者信息的偏好,发现物品和物品之间的相似度,然后根据用户的历史偏好信息,将类似的物品推荐给用户。这听起来比较拗口,简单的说就是几件商品同时被人购买了,就可以认为这几件商品是相似的,可能这几件商品的商品名称风马牛不相及,产品属性有天壤之别,但通过模型算出来之后就是认为他们是相似的。什么?你觉得不可思议,无法理解。是的,就是这么神奇!
举个例子:假设用户 A 喜欢物品 A 和物品 C,用户 B 喜欢物品 A,物品 B 和物品 C,用户 C 喜欢物品 A,从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的,喜欢物品 A 的人都喜欢物品 C,基于这个数据可以推断用户 C 很有可能也喜欢物品 C,所以系统会将物品 C 推荐给用户 C。
其实基于项目的协同过滤推荐机制是 Amazon 在基于用户的机制上改良的一种策略,因为在大部分的 Web 站点中,物品的个数是远远小于用户的数量的,而且物品的个数和相似度相对比较稳定,同时基于项目的机制比基于用户的实时性更好一些。但也不是所有的场景都 是这样的情况,可以设想一下在一些新闻推荐系统中,也许物品,也就是新闻的个数可能大于用户的个数,而且新闻的更新程度也有很快,所以它的形似度依然不稳 定。所以,其实可以看出,推荐策略的选择其实和具体的应用场景有很大的关系。
本系统基于java技术,使用UML建模,采用springboot框架组合进行设计,Mysql数据库存储数据。
本系统的功能主要包括本系统的功能主要包括:
使用springboot,vue,mysql, mybaties, typescript, html ,css, js 等进行开发
开发工具主要有:idea、jdk1.8、maven、mysql5.7、Navicat等。
@RequestMapping("/strategy") @RestController @Scope("prototype") public class StrategyController { @Autowired private StrategyService strategyService; @Value("${web.upload-path}") private String path; @RequestMapping("/findPage") public ObjDat<Strategy> findPage(Strategy strategy, @RequestParam(value="page", defaultValue="1") int page, @RequestParam(value="limit", defaultValue="10") int limit){ return strategyService.findPage(strategy,page-1,limit); } @RequestMapping("/edit") public JsonResult edit(HttpServletRequest request, Strategy strategy) throws IOException { User user=(User)request.getSession().getAttribute("user"); if(user==null){ return JsonResult.error("请登录"); } String str=strategyService.edit(request,strategy); if(str.equals("成功")){ return JsonResult.success("操作成功"); }else{ return JsonResult.error("操作失败"); } }
项目功能演示
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。