企业官网建设流程全解析

1. 项目选题与整体方案设计

1.1 这个项目到底在解决什么问题

拿Spark做数据处理与分析，是很多计算机、大数据相关专业学生在课程设计、毕业设计里绕不开的一道坎。但说实话，真正能把整个项目从头到尾跑通、并且讲清楚原理的人并不多。多数人的状态是：装了个Spark环境，跑了官方自带的一个WordCount示例，写报告的时候发现没什么可写的，答辩的时候被老师一问“为什么用Spark不用MapReduce”就卡壳。

我做的这个项目，目标很直接：围绕电商交易数据分析这个经典场景，从零搭建一套基于Spark的离线数据处理与分析链路。数据用模拟生成的用户行为日志和订单数据，经过清洗、转换、聚合，最终产出用户消费画像、商品热度排行、时段销量趋势等核心指标，并且把结果落地到MySQL和可视化图表里。项目包含了完整的设计源文件、一份万字左右的详细报告、以及配套的讲解说明，整体是可以直接作为课设、毕设参考方案的。

选择电商场景，不是因为创新，恰恰是因为它成熟、稳妥、好讲。面试官和答辩老师对电商分析的业务逻辑都很熟悉，不需要你花大量篇幅去解释业务背景，精力可以集中在Spark本身的算子使用、任务调度、性能调优这些真正有含金量的地方。还有一个现实考虑：电商数据集在网上很容易找到开源版本，即便自己模拟生成，也不会有数据合规的隐患。

1.2 为什么选Spark而不是其他计算框架

这是报告里必须写清楚、答辩时大概率会被问到的问题。Spark胜在三点：内存计算、丰富的算子、统一的编程模型。

MapReduce是Hadoop生态里的老大哥，但它有个硬伤——每个Map和Reduce阶段都要落盘，迭代计算的时候磁盘IO开销非常大。Spark的思路是尽可能把中间结果放在内存里，只有内存不够或者需要Shuffle时才落到磁盘。这个差异在数据量小的时候感觉不出来，一旦数据量上了GB级别，Spark的运算速度可以比MapReduce快几倍甚至十几倍，Spark官方给的性能对比数据是快10到100倍，虽然有点营销味，但量级上的优势是真实的。

Flink又是一个常被拿来对比的框架。Flink的强项是流式处理，毫秒级延迟，适合实时风控、实时推荐这类场景。而我们的项目是离线分析，数据是批量落盘的，没有太高实时性要求，用Flink反而杀鸡用牛刀，而且Flink的批处理API（DataSet）已经进入维护模式，官方推荐用Table API/SQL做批处理，学习成本和项目复杂度都会上升。

所以最终选型是Spark Core + Spark SQL的组合。既能在代码里体现RDD、DataFrame这些核心抽象的使用，又能在业务逻辑层用Spark SQL简化开发，两种风格都覆盖到，报告里可以写的技术点也更丰富。

1.3 项目模块划分与技术架构

整个项目拆成五个模块，各自职责清晰，也方便报告按章节展开。

数据接入层负责把原始日志从本地文件系统或HDFS读取进来，做初步的格式校验和字段抽取。数据清洗层处理缺失值、去重、格式统一这些脏活，比如时间戳统一成时间格式、金额字段去掉非法字符、IP地址解析成省份。数据分析层是核心，包含用户维度、商品维度、时间维度三条分析主线，用的算子包括groupBy、join、window、sortBy等等。结果输出层把分析结果写入MySQL，同时生成CSV供可视化工具读取。配置监控层负责提交参数管理、日志记录、任务执行时间统计。

技术栈上，Spark版本选的3.2.x，Scala版本2.12，运行模式支持local和yarn两种。存储方面，源数据放HDFS，结果放MySQL，可视化用的ECharts和Tableau各做了一版，方便报告里截图对比。调度工具没有引入Azkaban、Airflow这些，因为单项目的场景下，用crontab定期触发spark-submit就够了，引入调度框架反而增加部署复杂度和报告篇幅压力。

2. 环境搭建与Spark集群部署实操

2.1 本地开发环境和集群规划

很多人在环境搭建这一步就劝退了，其实没那么玄乎。我自己用的是三台机器组成的集群，一台Master节点，两台Worker节点，操作系统是CentOS 7.9。JDK用1.8，因为Spark 3.2对JDK版本的兼容性最稳，换JDK 11虽然也能跑，但某些老版本的Hadoop组件可能会有兼容提示，没必要给自己找麻烦。

Hadoop版本选的3.2.4，只用了HDFS和YARN两个组件。这里给个建议：如果只是做Spark项目的课设，HDFS可以只做单节点伪分布，YARN也是单节点，然后Spark以local模式跑。但如果你想在简历上和报告里写“具备Spark集群部署和YARN调度的经验”，那还是老老实实搭一个真正的多节点集群。多节点带来一个问题：网络配置、SSH免密、防火墙规则，每一个环节出错都会卡半天。

集群规划我建议这样分配：Master节点跑NameNode、ResourceManager、Spark的Master进程，两个Worker节点跑DataNode和NodeManager。Spark自身有两种集群模式：Standalone和YARN。虽然Spark自带Standalone模式部署更简单，但企业里绝大多数是跑在YARN上的，因为能跟Hadoop生态统一资源调度。所以我的方案里两种模式都装了，默认用YARN提交，Standalone作为备选方案在报告里做对比。

2.2 Spark安装与关键配置项说明

安装Spark本身不复杂，复杂的是理解参数含义。这里把最关键的几个配置项列出来，报告里也会逐个解释。

spark-env.sh里面配置JAVA_HOME、HADOOP_CONF_DIR、SPARK_MASTER_HOST。这里有个容易踩的坑：如果不配HADOOP_CONF_DIR，Spark往HDFS上写文件的时候会报找不到FileSystem的错。

spark-defaults.conf是另一份重要配置，里面可以统一设置executor内存、核数、序列化方式。我习惯把spark.serializer设成org.apache.spark.serializer.KryoSerializer，Kryo序列化比默认的Java序列化更高效，尤其是数据量大或自定义对象多的时候，能明显减少网络传输和存储开销。代价是需要对自定义类做registerKryoClasses注册，但很多项目里直接用基础类型和元组，不注册也能跑。

spark-submit提交命令的参数优先级，是所有Spark初学者必须搞清楚的。优先级从低到高是：配置文件里的默认值，spark-submit命令行参数，代码里SparkConf的set方法。也就是说，代码里set的参数会覆盖命令行参数，这个特性用好了很灵活，用不好会让人困惑。比如你在代码里把executor内存写死成2g，命令行传--executor-memory 4g是不生效的，因为优先级不够。

2.3 集群资源分配与CPU核心数的经典坑

这个话题要重点展开写。很多人在使用spark on yarn提交任务时，发现executor在yarn上运行时，每个container只分配了一个vcore，哪怕你在参数里把spark.executor.cores设成了2或者更大，最后看YARN的ResourceManager界面，发现每个executor还是只有一个vcore。我在项目初期也被这个问题坑了一天。

这个问题的根源在于YARN的调度配置。YARN默认用的容量调度器（Capacity Scheduler）里，有一个参数叫yarn.scheduler.maximum-allocation-vcores，默认值是1。只要你没改这个参数，无论Spark申请多少个核，YARN每次最多就给你1个vcore。解决办法是在yarn-site.xml里把这个参数调大，比如设成4或者8。同理还有一个yarn.scheduler.maximum-allocation-mb控制最大内存分配，默认是8192MB，如果你的executor内存申请超过8g，也会被限制。

这个坑非常典型，因为问题不在Spark，而在YARN。排查思路也很简单：先看Spark UI里的executor资源，再看YARN的调度器配置，确认是不是被yarn.scheduler.maximum-allocation-vcores卡住了。我在报告里专门用一页写了这个问题的根因分析和解决步骤，答辩的时候如果老师问“你怎么做性能调优的”，这就是一个现成的实战案例。

2.4 Spark on YARN提交任务的最小客户端方案

另一个高频问题：spark on yarn提交任务时，是不是只需要一个spark客户端就行了？答案是：看情况，但大多数情况下可以。

先说最简单的场景。如果你提交的是local模式，那本地机器必须要完整的Spark环境处理逻辑。但如果是yarn模式，任务的核心计算是交给YARN集群的NodeManager去启动Executor容器执行的，客户端只负责提交Application Master的启动指令和上传依赖包。所以理论上，客户端机器只需要装了Spark（用于提交作业的spark-submit脚本依赖）和Hadoop的客户端配置（用于连接HDFS和YARN），就能完成提交。这也是为什么我在部署文档里特别说明：提交机器不需要跟集群节点做相同的完整配置。

但实际项目里有个细节容易忽略：如果你的代码里要读取的依赖包、自定义jar包比较多，Spark会把提交机上的相关jar包通过SparkContext上传到HDFS临时目录，如果这个临时目录权限不对，提交的时候会报PermissionDenied。所以提交机器上要确认HDFS的/tmp目录有写入权限，或者提前在spark-defaults.conf里改掉spark.yarn.jars这个路径。

我在实际项目里采用的方案是：集群里三台节点都装全量的Spark和Hadoop，但日常开发是在自己电脑上写好代码、打jar包，再把jar包丢到提交节点的固定目录，用统一的spark-submit脚本提交。这样既保留了clinet模式改代码调试的便利性，又不影响yarn集群模式的正常运行。

3. 核心功能模块设计与代码实现

3.1 数据源设计与模拟数据的生成逻辑

这个项目没有直接采用公开数据集，而是写了一个Scala脚本，模拟生成一份用户订单数据。原因有两点：第一，公开数据集普遍比较规范，缺字段、脏数据的情况少，做数据清洗的部分就没什么可写了；第二，自定义模拟器可以精确控制数据量和数据分布，方便验证不同参数下的Spark性能表现。

模拟数据的字段设计如下：订单ID、用户ID、商品ID、商品名称、商品类目、商品单价、购买数量、订单金额、下单时间、支付时间、用户所在省份、用户设备类型。一共12个字段，覆盖了用户、商品、时间、地域、终端五个维度，足够支撑后续所有分析主题。

数据生成逻辑里我模拟了几种脏数据情况：一是随机生成约2%的订单ID为空记录，二是约1%的订单金额字段是“N/A”这种非数字字符，三是约3%的下单时间缺失。这样在清洗环节就有真实可操作的场景，而不是为了清洗而清洗。数据总量控制在50万条订单，文件大小大约120MB，分成20个分区存储，既能体现分布式处理的效果，又不至于在课设环境里跑太久。

需要注意的一点是，模拟器在生成时间字段的时候，我用的是Unix时间戳格式，跨了整整30天的范围。这样后续做时间窗口分析时，可以按天分组，也可以按小时做更细粒度的分析。如果时间跨度太短，画趋势图的时候曲线太平滑，报告里看不出什么规律。

3.2 数据清洗流程的算子设计与实现

清洗是整个项目里最容易被低估的环节。很多人觉得数据清洗就是filter一下空值，其实里面藏着不少可写的技术点。我的清洗流程分四步，每一步都用不同的方式处理，报告里可以逐个展开。

第一步是去重。订单ID理论上应该唯一，但模拟数据里有重复。这里我用dropDuplicates("order_id")，而不是先groupBy再filter count，因为dropDuplicates底层用了更高效的去重策略，在大数据量下性能差异明显。第二步是过滤空值，用filter条件把order_id为null或空串的记录剔掉。注意不能用!= null这种写法，在Scala里要用Option或者isNotNull的显式判断。第三步是格式标准化。金额字段如果是“N/A”，我直接把这一整条记录标记为异常并输出到另一个error表里，而不是直接丢弃。这样做的好处是，报告里可以量化清洗比例：总记录50万，有效记录48.7万，异常记录1.3万，清洗通过率97.4%，这个数据比笼统说一句“完成了数据清洗”有说服力得多。

第四步是时间字段的处理，把Unix时间戳格式化成业务可读的"yyyy-MM-dd HH:mm:ss"格式，并且抽取year、month、day、hour四个字段单独存成新列。这一步为后面做时间维度聚合铺路，省得每个分析任务里都要做一次时间转换。

代码实现用的是DataFrame API，配合Spark SQL的注册临时表。整体逻辑大概50多行，个人经验是：清洗逻辑尽量不要用RDD的低级算子去写，因为RDD的map操作里做字符串拼接和类型转换，代码可读性差，一旦要改逻辑就要从头排查。DataFrame API配合case class做schema映射，写起来和阅读起来都舒服得多。

3.3 指标体系设计与分析任务的执行逻辑

指标设计这部分，是我在报告里花篇幅最多的内容。不是因为它难，而是因为好的指标设计能体现你对业务的理解，这在答辩加分上很有用。

我把指标分成三个维度。用户维度算四个指标：总用户数、活跃用户数（有购买行为的用户）、人均消费金额、用户复购率。商品维度算三个指标：销量Top10商品、销售额Top10商品、商品类目销售占比。时间维度算两个指标：每日销售额趋势、每小时下单量分布。另外加一个地域维度：各省份销售额排行。

每个指标都不是简单地count和sum，而是结合了join和window操作。举一个例子：用户复购率。先按照用户ID分组，统计每个用户的购买次数，然后统计购买次数大于1的用户数占总用户数的比例。这个统计逻辑在关系型数据库里要写嵌套子查询，在Spark里用agg + filter + count组合，代码非常紧凑。

地城省份分析那里用到了UDF。原始数据里只有IP地址字段，我写了一个UDF函数，把IP地址的前三段映射到省份。严格来说这个映射很粗糙，但对于教学演示完全够用，而且UDF的写法在报告里是一个明确的技术亮点——体现了Spark对自定义函数扩展的支持。要注意的是，UDF的序列化性能比内置函数差，所以在数据量大的时候要谨慎，我在这个项目里是在已经清洗完小数据集上才调UDF的。

3.4 分析结果的落地与可视化衔接

分析算完之后，结果不能留在内存里就算完事，必须落到存储里才能说明白。我把结果分成两类：一类是明细结果，比如清洗后的订单明细，我落在HDFS的parquet文件里，列式存储加压缩，后续如果要再跑其他分析任务，直接load parquet比重新读原始文本快很多；另一类是统计结果，比如Top10榜单、每日趋势，这些量比较小，直接写入MySQL的对应表里。

写MySQL用的是JDBC方式，通过DataFrame.write.jdbc实现。这一环节有两个坑。第一个是驱动包问题，Spark默认不带MySQL的JDBC驱动，要把mysql-connector-java.jar放到Spark的jars目录下，或者提交任务时用--jars参数显式带上，不然ClassNotFound异常报的你怀疑人生。第二个是写入模式选择，我用的是SaveMode.Append，因为分析任务是按天跑的，每次跑完追加当天结果就行。如果你要覆盖历史结果，用Overwrite模式，但要小心这个模式会把整个目标表清空重建，如果表里有别的数据，会一起没掉。

可视化这块，我做了两版。一版是直接把MySQL里的统计数据导出到CSV，在Tableau里拖几个工作表，生成销售额趋势图和商品排行榜，这个比较适合放进报告做静态截图。另一版是用ECharts写了一个简单的Web页面，通过后端接口读MySQL数据，在页面上动态展示，这个适合现场演示，视觉冲击力更强。

4. 项目报告撰写与配套资料制作

4.1 万字报告的整体结构与写作逻辑

这个项目配套的万字报告，不是随便灌水凑字数，每一章都有明确的目的。我的报告结构分七章，加起来大概一万二千字左右。

第一章是绪论，写项目背景和研究意义。网络购物数据分析对大数据的依赖，引出Spark在大数据生态中的地位，这部分大概1500字。第二章是相关技术介绍，写Spark核心架构、RDD与DataFrame的区别、Spark SQL执行流程、YARN资源调度原理。这个章节尽量用图说话，我在源文件里画了好几张架构图和数据流转图。第三章是系统需求分析，写功能性需求和非功能需求，数据量级、响应时间、可扩展性这些指标都量化了。第四章是系统设计，包括架构设计、模块划分、数据库表设计。第五章是系统实现，按数据清洗、用户分析、商品分析、时间分析四个小节展开，每小节都贴核心代码、运行截图和结果分析。第六章是系统测试与性能分析，讨论不同数据规模下的任务运行时间、不同executor配置下的性能差异。第七章是总结与展望，把项目成果做个梳理，再简单说未来怎么从离线转实时。

这里要给个建议：写报告的时候千万不要把代码全贴进去。很多学生贴了上百行代码，老师根本不看，反而显得凑字数。我的做法是：每个小节只贴最关键的核心代码片段，控制在20行以内，然后在代码块下面用文字详细解释这段代码做了什么、为什么这么写、有没有其他替代方案。

4.2 设计源文件的整理规范和交付标准

设计源文件这部分，很多人不重视，觉得就是随便放几个文件夹。但作为完整交付的项目，源文件整理是否规范，直接影响使用方（可能是你的指导老师，也可能是下载你项目的人）的第一印象。

我的源文件目录结构是这样组织的：

• docs：存放万字报告、答辩PPT、需求说明书
• code：存放完整的Spark工程代码，包括scala源码、pom.xml依赖文件、resources配置文件
• sql：存放建表语句、初始化数据和查询脚本
• data：存放模拟数据生成器、源数据、清洗后的数据样例
• images：存放架构图、流程图、运行截图、可视化图表

code目录里我特别注意了工程化的结构，用了标准的Maven布局，src/main/scala下面按com.project.spark的包路径组织，分成clean、analysis、output、utils四个子包。每个类都写了类注释，关键方法都有行内注释。这样不仅代码可读性好，也方便后续二次开发。

另外建议把运行脚本单独放一个bin目录，里面放submit.sh、data_gen.sh、mysql_init.sh。这样即使对Spark不太熟的人，也能按脚本的提示一步步把项目跑起来。脚本里把环境变量、jar包路径、提交参数都做成变量，改了头部配置就能适配自己的环境。

4.3 讲解说明与演示答辩的准备技巧

讲解部分是这个项目配套服务里最有价值的东西。不是念PPT，而是要能把项目从头到尾串成一个有逻辑的故事。

我的讲解主线是：场景痛点（原始日志数据量大、格式混乱，传统工具处理不了或太慢）→ 方案选型（为什么选Spark）→ 架构设计（整个链路怎么搭）→ 核心实现（挑两到三个最有技术含量的点展开）→ 成果展示（看数据指标和可视化图表）→ 总结沉淀（踩过哪些坑，学会了什么）。

每个环节都要准备一些可以随时引用的数据，比如“清洗前50万条数据，清洗后剩下48.7万条，清洗率97.4%”、“跑完整个分析流程只需要40秒，如果单机用MySQL查这几张表，光一个join就要几十秒”。这些具体数字比“性能很好”这种空话有说服力得多。

演示环节最容易翻车的是环境问题。我见过太多人在答辩现场跑不起来程序，原因五花八门：MySQL没启动、HDFS没起来、内存不够、端口被占用。我的建议是：提前一天做一次完整的冷启动演练，从开机、启动HDFS、启动YARN、启动MySQL、提交任务到出结果，全程走一遍，确保每个环节都顺畅。现场演示时，宁可用一份之前跑好的结果截图兜底，也不要冒险现场重新跑。

4.4 资料定制与后续扩展的思路

因为这个项目用的是模拟数据，所以整套代码和报告是可以直接复用到其他场景的。如果你手头有真实数据或者换一个业务领域，需要做的改动并不大，主要是调整字段名和指标定义。

如果你想把电商场景换成其他业务，比如金融交易分析、日志监控分析，核心流程是不变的，变的只是数据模型和指标定义。比如金融场景，把用户ID换成账户ID，订单金额换成交易金额，时间维度的粒度从小时细化到分钟，再增加一个风险等级的字段。整套Spark处理链路完全一致，只要改数据解析的schema和UDF逻辑，就能复用。

我在讲解说明里也专门录了一段内容，讲怎么基于这套代码去定制自己的指标和分析逻辑，包括怎么新增UDF、怎么调整Spark SQL的查询语句、怎么把结果输出到新的MySQL表。这部分对于需要定制项目的同学来说，是非常实用的参考。

5. 实战过程中的高频问题与排查方法

5.1 Executor只分配一个Vcore的排查思路

这个问题在前文已经提到根因是YARN调度器的maximum-allocation-vcores参数。但这里想补充一个完整的排查思路，方便你真正遇到的时候按步骤处理。

第一步，看Spark UI。提交任务后，打开Spark UI的Executors页面，如果每个Executor的Cores列都是1，说明资源申请确实被限制了。第二步，去YARN的ResourceManager界面，看这个Application实际申请到的资源描述。第三步，看YARN调度器配置，到yarn-site.xml里检查yarn.scheduler.maximum-allocation-vcores的值。如果确实是1，改成4或更大的值，然后重启ResourceManager和NodeManager。第四步，重新提交任务，看Spark UI里Cores列是否变化。

另外一个不容易想到的点是：如果用了spark-submit的--num-executors参数，它有可能会影响vcore的分配。如果你指定了executor数量但没指定每个executor的核数，Spark默认给每个executor分配1个核。所以提交命令，最好的做法是四个参数都显式指定：--num-executors、--executor-memory、--executor-cores、--driver-memory。不要依赖默认值，默认值在性能调优里是灾难。

5.2 Spark内存模型相关的经典坑

Spark内存模型是面试和答辩里的高频题，也是实际调优时绕不开的部分。简单说一下我的理解：在Spark 3.0之后，executor的堆内存被分成三块，reserved memory是固定300MB，用来存储Spark内部对象；user memory用来存储用户自定义的数据结构和RDD对象；剩下的就是spark.memory.fraction默认0.6的部分，这一块再细分为storage memory和execution memory，两部分可以互相借用。

实际项目中，最常见的OOM问题出在哪呢？我遇到两次。第一次是把大表load到内存做join，但executor内存只给了2g。解决方法是把同一个executor的内存调大到4g，同时调整spark.memory.fraction为0.7，给execution memory更多配额。第二次是collect操作，把全量数据拉到driver端。result集太大直接把driver内存撑爆了。这个问题的标准解决方案是：尽量不要用collect，改用saveAsTextFile或者写入数据库的方式，把结果写出去而不是拉回来。

顺带说一个排查内存问题的通用工具：在spark-submit里加--conf spark.eventLog.enabled=true和--conf spark.eventLog.dir=hdfs://.../eventlog，开启事件日志之后，可以在History Server里看到完整的任务时间线、Shuffle读取量、垃圾回收耗时。如果GC时间占了任务总时间的15%以上，那基本可以断定内存配小了。这类细节写进报告里，是很加分的实操经验。

5.3 Spark on YARN客户端依赖和日志问题

提交任务时看到log4j相关的提示，比如“Using Spark's default log4j profile: org/apache/spark/log4j-defaults.properties”，这其实不是报错，只是说明Spark没有找到自定义的log4j配置，在用一个默认配置。很多人第一次看到这行日志会慌，实际上不需要管它。如果想让日志输出更可控，在conf目录下放一个log4j.properties文件，自定义日志级别和输出格式就行。我在项目里把log4j.rootCategory设成了WARN，这样最终提交时，控制台只打印必要信息和警告，不会被INFO级别的冗余日志刷屏。

还有一个常见的客户端问题：提交任务的时候发现找不到HDFS文件。这时候要检查两处：一是HADOOP_CONF_DIR环境变量有没有指向Hadoop的配置目录，二是core-site.xml里的fs.defaultFS配置对不对。如果本机没装Hadoop，只装了Spark，那提交yarn模式任务时，Spark会找不到YARN的ResourceManager地址，报Connection refused。解决办法是：在Spark客户端的hadoop配置目录，放一份集群的core-site.xml和yarn-site.xml。这样客户端机器不需要装完整的Hadoop，只需要配置文件的连接信息就能提交任务。

5.4 常见问题速查表

其实大多数Spark问题，网上都能搜到解决方案，难点在于定位问题的思路。我个人的习惯是：遇到问题先看日志，先看YARN的日志，再看Spark的任务日志，最后才看代码逻辑。80%的问题在日志里就有直接线索，只是很多人不愿意一行一行去翻。

6. 项目交付与帮你避开的那些坑

整个项目从环境搭建到报告写完，我前后花了大约两周的业余时间。回头复盘，有几个地方是最浪费时间、也最值得提前避开的。

第一，环境版本务必提前锁定。Hadoop 3.2.4、Spark 3.2.1、Scala 2.12、JDK 1.8，这四个版本组合是我实测最稳定的搭配。如果你用其他版本，尤其是Spark升级到3.4或4.0，部分API可能会有变更，网上搜到的资料和你的代码可能对不上。版本问题在课设项目里非常致命，因为老师不会帮你踩环境坑，你自己卡一天都是有可能的。

第二，代码要尽早开始写，不要等环境完全稳定再动工。很多人在环境上花了一周，代码没写几行。我的建议是先在本机把local模式的代码跑通，把核心业务逻辑写出来，之后再把同样的代码包提交到yarn模式。local模式调试方便，报错信息也直观，等逻辑对了再切换运行模式，遇到的坑就少很多。

第三，报告和演示素材最好同步准备。跑每个分析任务的时候，顺便把运行截图、结果截图、执行时间统计都用表格记下来。等代码写完，报告素材也在手边了，不用回头重新跑一遍补截图。

这个项目运行下来，单次全流程的任务时间大约40秒，这个数字看起来不大，但你要想，这里面包含了50万条数据的清洗、聚合、Join、UDF计算、多张结果表的写入。如果回到MySQL单机环境，用SQL去模拟同样的分析逻辑，可能要等好几分钟。而Spark的优势，在数据量再翻10倍、100倍的情况下会越来越明显。这也是我在报告最后写下的观点：单机工具解决不了的问题，才是大数据框架真正发力的主场。

如果你在做类似的项目，希望这篇内容能帮你少走一些弯路。核心功能够用、报告逻辑清晰、演示稳妥不出错，课设或毕设基本就稳了。最后再分享一个小技巧：所有跑过的命令，包括spark-submit提交命令、MySQL建表语句，操作完了要养成一个习惯，顺手把输出截图保存下来，命名按照环境+日期+用途来区分。等你写报告的时候，你会发现这些零碎的记录比任何模板都管用。