用Spark分析Amazon的8000万商品评价(内含数据集、代码、论文)

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 尽管数据科学家经常通过分布式云计算来处理数据,但是即使在一般的笔记本电脑上,只要给出足够的内存,Spark也可以工作正常(在这篇文章中,我使用2016年MacBook Pro / 16GB内存,分配给Spark 8GB内存)。

更多精彩内容参见云栖社区大数据频道https://yq.aliyun.com/big-data;此外,通过Maxcompute及其配套产品,低廉的大数据分析仅需几步,详情访问https://www.aliyun.com/product/odps

6587d33eea29d553992c9df21c14eb0249fce4bc

亚马逊的商品评论和评分是一个非常重要的业务。 亚马逊上的客户经常基于这些评论做出购买决定,并且单个不良评论可以导致潜在购买者重新考虑。 几年前,我写了一篇非常受欢迎的博客文章,题为“120万亚马逊评论统计分析“。

a6a7680cd62d34ec327e3e1bb83db3c01d8839d9

当时,我只限于1200万评论,因为尝试处理更多的数据会导致内存不足,以至于我的R语言代码需要运行几个小时。

Apache Spark是一个高效的开源大数据计算框架,在过去几年中已经非常流行(对于使用Spark和Python的好教程,我推荐免费的eDX课程)。尽管数据科学家经常通过分布式云计算来处理数据,但是即使在一般的笔记本电脑上,只要给出足够的内存,Spark也可以工作正常(在这篇文章中,我使用2016年MacBook Pro / 16GB内存,分配给Spark 8GB内存)。

我写了一个简单的Python脚本,用来合并Julian McAuley、Rahul Pandey和Jure Leskovecucehua在2015年发布“Inferring Networks of Substitutable and Complementary Products”论文时准备的亚马逊产品评论数据集中每个类别的评级数据 。成果是一个4.53 GB的CSV,肯定不能在Microsoft Excel中打开。选取和整合的数据集包括:留下评论的用户的用户名,指明是哪一个接收评论亚马逊产品的id,从1到5的用户给出的评级,以及评论写入的时间(精确到天)。 我们还可以从数据子集的名称推断已评价产品的类别。

然后,使用面对R语言的新的升级包,我可以使用一个spark_connect()命令轻松启动本地Spark集群,并使用单个spark_read_csv()命令很快将整个CSV加载到集群中。

e717df7f6a826ceccf03dfc1e22b2b7f1e2d4542

在数据集中总共有8074万条记录,即8.074e + 07条。如果使用传统工具(如dplyr或甚至Python pandas)高级查询,这样的数据集将需要相当长的时间来执行。

使用sparklyr,操作实际很大的数据就像对只有少数记录的数据集执行分析一样简单(并且比上面提到的eDX类中教授的Python方法简单一个数量级)。

试探性分析

(您可以查看用于Spark处理数据的R代码,并在此R Notebook中生成可视化数据)有20,368,412个有效id的用户在此数据集中提供评论。 其中51.9%的用户只写了一篇评论。

df8586a6e15da634ddedbd7330dd6014f364f6df


相应地,此数据集中有8,210,439个单独的产品,其中43.3%只有一个评论。

179e3b292051694adc49e3c5ef97122f4ee199fb

删除几个重复的评分后,我为每个评分添加了几个函数,这可能有助于说明审核行为随时间的变化:一个能表示给定该评论的作者的#评论排名值(作者的第一次评论,第二次评论等),一个指示给定接到该评论的产品已经接收到的#评论(产品的第一评论,产品的第二评论等)的评级值以及进行评论的月份和年份。

前两个添加的函数需要非常大的处理能力,这突出Spark的性能事实上,Spark使用默认情况下所有的CPU核心,而典型的R / Python方法是单线程的!)

这些更改被缓存到Spark DataFrame df_t中。 如果我想确定哪个亚马逊产品类别获得最佳平均评论评分,我可以按类别整合数据,计算每个类别的平均评分,然后排序。多亏Spark的强大功能,这个数百万记录的数据处理需要几秒钟。

df_agg <- df_t %>%
            group_by(category) %>%
            summarize(count = n(), avg_rating = mean(rating)) %>%
            arrange(desc(avg_rating)) %>%
            collect()
be11eea2a75d22d37529bb9c8270947b4741fa2c

也可以使用ggplot2以图表形式显示:

c2043ff4f10eb1da5299eeb08421bf9e9681263f

数字音乐/ CD产品平均获得最高评价,而视频游戏和手机得到最低平均评价,评分范围为0.77。 这确实说明了一些直观的联系; 购买数字音乐和CD这类产品时,你知道你会得到什么,没有产生随机缺陷机会,而手机和配件根据背后的第三方卖家的会有不同的质量(电子游戏尤其容易由于微小的不合理而产生评论的“爆炸”)。

我们可以将每个条细分分成从1-5的每个评级的百分比,更利于该可视化。 也可以将饼图图表划分成不同类别,但像这样码成条形图再缩放到100%能看起来更清爽。

48114e75423874d08121188a2ba466ac031c34a2

新的图表确实有助于支持上述理论; 顶部的类别的4/5星评级的百分比显著高于底部类别,并且1/2/3星级评分的比例低得多,底部类别与之相反。那么这些故障如何随时间而改变? 还有其他因素在发挥吗?

随时间变化的评级

也许出现在二十世纪二十年代社会媒体中的二元评级“喜欢/不喜欢”已经转化为五星级评论系统的行为。 以下是从2000年1月至2014年7月每月撰写的评论的评分细目:

6de1f0eff21affe33be360448bb1238c4fd386f9

投票行为在一段时间内非常轻微地振荡,没有清晰的尖峰或拐点,这与该理论冲突。

平均值分布

我们应该看看亚马逊的产品分数的全球平均值(即客户在购买产品时看到的),以及给出分级的用户。在我们期望中两者分布匹配,所以任何偏差都会很有趣。关注至少评级5的产品时,有4.16平均总评级:

6587d33eea29d553992c9df21c14eb0249fce4bc

当查看反应用户给出的总体评分类似的图表时(5个评级最低),平均评级略高于4.20。

0471ea17e3509e2595c902c7fe7e8515fa4a996f

这两种分配的主要区别是亚马逊客户只有5星评价的比例明显更高。归纳和总结两个图表可以清楚突出了差异。

9fef21c007712221b37f0eca46255dbbc54d4db9

特别的评论

几个帖子前,我讨论了Reddit帖子的第一个评论为何比以后的评论有更大的影响。 在做出越来越多的评论后,用户评分行为是否会改变? 同一件产品的第一次评价,与典型的评级行为是否不同?这里是某个用户给出的几个亚马逊评论的评分细目:

8f9150fd9ad3609511ca3be0da4795c248f45873

第一个用户评论的评分比之后的评价稍高。其他情况下,评级行为大部分是相同的,虽然用户给4星而不是5星评价的比例增加,由于这样更舒适。相比之下,这里是某亚马逊产品收到的几个评论的评分细目:

a4c98f9c3174c4497645c19823044c21354bd5f9


第一个产品评论是5星评价的可能略高于随后的评论。 然而,在第10次审查之后,评级分布没有变化,这意味着特殊评级行为独立于该阈值之后的当前评分。

总结

的确,这篇博文中使用数据多于分析它。 在未来技术发布中,可能更有趣的是特定条件下的行为,例如根据该产品/该用户以前的评价,预测评论的评级。 然而,这篇文章表明,虽然“大数据”可能现在仍是一个令人费解的流行语,但即使你不必为一家财富500强公司工作,也能够理解它。 即使数据集由5个简单的函数组成,您也可以归纳大量的结论。

而这篇文章甚至不需要查看亚马逊的产品评论的文本或与产品相关的元数据! 只要有想法,就能完成。

您可以在R Notebook中查看所有用于可视化Amazon数据的R和ggplot2代码。您还可以在此GitHub存储库中查看用于此帖子的镜像/数据

原文链接:Playing with 80 Million Amazon Product Review Ratings Using Apache Spark(作者/Max Woolf)

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
相关文章
|
5月前
|
机器学习/深度学习 分布式计算 算法
Spark快速大数据分析PDF下载读书分享推荐
《Spark快速大数据分析》适合初学者,聚焦Spark实用技巧,同时深入核心概念。作者团队来自Databricks,书中详述Spark 3.0新特性,结合机器学习展示大数据分析。Spark是大数据分析的首选工具,本书助你驾驭这一利器。[PDF下载链接][1]。 ![Spark Book Cover][2] [1]: https://zhangfeidezhu.com/?p=345 [2]: https://i-blog.csdnimg.cn/direct/6b851489ad1944548602766ea9d62136.png#pic_center
189 1
Spark快速大数据分析PDF下载读书分享推荐
|
1月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
2月前
|
SQL 分布式计算 Serverless
EMR Serverless Spark:一站式全托管湖仓分析利器
本文根据2024云栖大会阿里云 EMR 团队负责人李钰(绝顶) 演讲实录整理而成
182 2
|
2月前
|
存储 缓存 分布式计算
大数据-89 Spark 集群 RDD 编程-高阶 编写代码、RDD依赖关系、RDD持久化/缓存
大数据-89 Spark 集群 RDD 编程-高阶 编写代码、RDD依赖关系、RDD持久化/缓存
49 4
|
2月前
|
设计模式 数据采集 分布式计算
企业spark案例 —出租车轨迹分析
企业spark案例 —出租车轨迹分析
111 0
|
2月前
|
消息中间件 分布式计算 Kafka
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
61 0
|
5月前
|
弹性计算 分布式计算 Serverless
全托管一站式大规模数据处理和分析Serverless平台 | EMR Serverless Spark 评测
【7月更文挑战第6天】全托管一站式大规模数据处理和分析Serverless平台 | EMR Serverless Spark 评测
23729 42
|
6月前
|
机器学习/深度学习 数据采集 分布式计算
基于spark的大数据分析预测地震受灾情况的系统设计
基于spark的大数据分析预测地震受灾情况的系统设计
174 1
|
6月前
|
分布式计算 定位技术 Scala
使用spark基于出租车GPS数据实现车辆数量统计以及北京每个城区的车辆位置点数分析
使用spark基于出租车GPS数据实现车辆数量统计以及北京每个城区的车辆位置点数分析
129 0