简介一套基于Apache Spark的外卖大数据分析系统项目包面向大数据技术学习者、毕设学生以及需要快速搭建分析原型的开发者。项目围绕外卖业务的多维数据覆盖实时数据接入、仓库清洗、指标统计与机器学习挖掘等环节涉及Spark Streaming、Spark SQL、MLlib及Hadoop集群部署思维适合从案例中掌握大数据分析系统的落地方式。文件压缩包共38个包含14个scala源文件作为核心业务实现配合HQL/SQL脚本用于表结构与管理查询py与sh脚本辅助数据处理和启动运行另附md说明文档、csv/tsv样例数据和jpg结果图便于对照调试与成果展示。资源体积仅646KB轻量易读虽规模不大但结构完整。已有740人下载学习可用作课程设计、毕业设计或大数据实训的参考模板尤其适合希望在Spark实战中快速入门并扩展功能的读者。 做这个项目之前我其实已经学了一段时间的大数据。理论啃了不少Spark资料也翻烂了但每次面试被问到“做过什么实际项目”的时候还是会忍不住心虚。后来我下了个决心不再刷零散的Demo了干脆从0到1做一个能把完整链路跑通、能现场演示的项目。于是就有了这个基于Spark的外卖大数据平台分析系统。这个系统解决的核心问题很直白外卖平台每天产生上千万条订单数据散落在日志和业务库里如果不做处理它们就是一堆睡着的数字。我用Spark把订单数据接进来完成清洗、转换、聚合分析把结果写进MySQL最后用ECharts展示成运营人员能直接看懂的图表。整条链路涵盖了模拟数据生成、ETL、离线数仓分层、Spark SQL分析、结果落库、可视化展示麻雀虽小五脏俱全。适合谁参考呢如果你是正在准备大数据岗位面试的开发者或正在做毕业设计相关选题的学生又或者是学了Spark基础但一直卡在“不知道怎么把知识串成项目”这个阶段的人这个项目的思路和踩坑记录应该都能帮到你。1. 项目要解决什么问题为什么技术栈选了Spark1.1 外卖场景的数据分析到底分析什么很多人拿到“外卖分析”这样的需求会很茫然觉得不知道从哪下手。我在动手之前先把外卖平台的业务拆了一遍。一单外卖从用户下单到配送完成至少会留下十几条关键信息用户ID、商家ID、菜品品类、下单时间、订单金额、配送距离、配送时长、平台评分、优惠券信息、城市区域。这些字段就是整个分析系统的数据底座。基于这些字段我把核心分析拆成了五个方向订单量趋势按天/按小时看订单波动、商家分析热门商家TopN、商家订单量分布、品类分析不同菜品类目的销售额占比、配送分析平均配送时长、超时率、用户分析复购率、消费区间分布。为什么选这五块因为它们对应了外卖平台运营最关心的几个问题——什么时候单多、哪些商家在撑流量、什么品类好卖、配送有没有拖后腿、用户粘性够不够。这五个方向恰好也把Spark里最高频的几个操作都覆盖了分组聚合、窗口函数、多表JOIN、TopN排序、条件分支。做完整个项目你会发现这些知识点不是孤立的而是被一条业务线串起来了这也是这个项目比起单纯刷题最有价值的地方。1.2 选Spark而不是MapReduce的三个理由技术选型阶段我犹豫过最开始想用MapReduce写后来果断否了。原因是这个分析系统里大量操作是交互式查询和多轮聚合比如先聚合再关联再排序MapReduce每个Job都要把中间结果落到HDFS来回读写磁盘跑一轮完整分析得多花两三倍时间。Spark基于内存计算DAG调度器会把多个Stage串起来同一份数据尽量在内存里完成多轮计算性能优势非常明显。第二个理由是编码效率。MapReduce写一条聚合逻辑要自己处理Mapper、Reducer、Partitioner、Combiner这些底层细节代码量特别大。Spark用DataFrame和Spark SQL几条语句就能表达同样的逻辑而且内置Catalyst查询优化器会自动做谓词下推、列裁剪这类优化不需要我手动调整执行计划。第三个理由是从实战角度考虑。现在做离线分析的公司基本已经把Spark当成标配面试聊项目的时候你说“我用Spark做过一个完整的数据分析平台”和说“我用MapReduce跑过WordCount”完全是两个重量级。这个项目做完面试官问Spark SQL优化、Shuffle原理、资源调优你都有真实案例可以讲而不是只能背书。1.3 整体架构与数据分层思路系统的技术栈是这样定的HDFS负责分布式存储Spark SQL作为核心计算引擎Hive管理数据仓库的元数据MySQL保存聚合后的结果ECharts负责可视化展示后端用SpringBoot提供查询接口。数据流转上原始数据先进HDFS在Hive里建ODS贴源层原始数据原样存放然后用Spark SQL把ODS层的数据清洗、转换落成DWD明细层干净的订单事实表和商家维度表接着按业务需求聚合到DWS汇总层比如每天的订单量、每个商家的累计单量最终把DWS层的结果通过Spark JDBC写入MySQL。这里多说一句数据分层不是摆架子。我见过很多同学的课程设计上来就直接对着原始CSV算指标代码确实能跑但一旦业务逻辑复杂了SQL就会变成几百行的嵌套地狱。ODS、DWD、DWS这套数仓分层本质是把“对数据的加工过程”拆成几个可独立维护的阶段每一层出了问题都能单独回溯和修复这也是目前工业界的通用做法属于你简历上可以写的能力点。2. 数据从哪来模拟数据生成与ETL清洗全流程2.1 500万条模拟订单是怎么生成的真实外卖订单数据是不可能跑到自己集群上的所以我用Python脚本自己造了一份模拟数据。这里的关键不是“随机”两个字而是要让数据的分布符合真实业务否则后续分析出来的结论没有任何参考价值。我的生成逻辑是这样的用户ID分布在1到5万商家ID分布在1到5000保证每个商家平均能承接10个用户的订单下单时间覆盖最近90天并且刻意埋入外卖行业的峰谷曲线——中午11点到13点和晚上17点到20点的订单量占全天的四成以上菜品品类按常识给权重快餐简餐占30%奶茶甜品占20%正餐占25%其他占25%配送时长用正态分布近似集中在15到45分钟之间再随机加一小部分超过60分钟的超时单。总数据量我控制在500万条左右文件切成多个CSV放上HDFS。这里提醒一下做大数据项目数据量最好不要少于100万条否则Spark处理完可能几十秒就结束了你既体会不到分布式计算的价值面试时也禁不起深挖。文件存储统一编码UTF-8时间字段固定为yyyy-MM-dd HH:mm:ss空字符串表示空值避免后续解析时出现编码或格式的坑。2.2 清洗过程中最容易被忽视的三个细节ETL清洗这个环节做好了没人看见做错了全盘崩。我处理模拟数据的时候故意埋了几类脏数据进去清洗逻辑对应着几个典型的线上问题。第一是无效数据过滤。我往订单表里插了下单时间在未来、金额为负、商家ID不存在的记录清洗阶段必须全部拦截。判断条件看着不复杂但每个字段都得覆盖到比如时间字段要能被to_timestamp成功解析金额必须大于0商家ID必须能在维度表里关联上。第二是空值策略。配送时长为空和评分为空不能一把梭地删除或置0。配送时长为空我选择保留代表订单可能还没完成配送评分为空则用该商家已有评分的均值去填充。如果简单把评分空值填成0后面算商家平均分时这个商家的数据会被严重拉低分析结论直接失真。第三是订单去重。线上日志因为重试机制同一订单可能出现多次我按订单ID做row_number()去重保留最新一条。这里用窗口函数的效率要远高于group by再取max而且代码意图更清晰。提示ETL是整套系统的地基。如果你发现后面分析结果怎么都对不上先别急着怀疑Spark大概率是清洗阶段某类脏数据漏掉了。2.3 Spark作业初始化与集群提交的正确姿势分析作业我用Spark SQL为主开发环境是Spark 3.2.0集群部署模式走YARN。开发的时候很多人习惯在IDEA里直接跑main方法但我建议从一开始就养成用spark-submit提交作业的习惯把工程打成jar包发到集群上运行。这样做的好处是集群模式的资源调度、Shuffle行为、日志机制都跟本地跑完全不一样你越早适应当前真实的工作方式后面越不吃亏。提交命令大致长这样spark-submit \ --class com.demo.OfflineAnalysis \ --master yarn \ --deploy-mode cluster \ --driver-memory 2g \ --executor-memory 4g \ --executor-cores 2 \ --num-executors 4 \ --jars mysql-connector-java-8.0.30.jar \ order-analysis.jar注意这里的--jars参数Spark在YARN集群模式下客户端本地的MySQL驱动不会自动分发到所有executor必须用--jars显式带上否则写MySQL那一步会在运行时报ClassNotFoundException。这个坑我踩过一次后来每次提交都习惯性地在参数里先加上依赖jar。3. 核心分析模块落地订单、商家、配送与可视化3.1 订单量和营业额趋势分析订单量趋势是整套系统的底座也是入门第一个分析任务。我用Spark SQL对DWD明细表做时间维度聚合先看按天的口径SELECT date_format(create_time, yyyy-MM-dd) AS order_date, COUNT(DISTINCT order_id) AS order_cnt, SUM(total_amount) AS order_amount FROM dwd_order_detail GROUP BY date_format(create_time, yyyy-MM-dd) ORDER BY order_date这段SQL虽然短但有两个细节值得注意。第一COUNT(DISTINCT order_id)而不是COUNT(*)为的是排除同一订单在明细表里出现多行的情况保证订单量是真实单量第二GROUP BY和ORDER BY使用同一个格式化表达式避免出现聚合口径和排序口径不一致导致的结果错乱。按小时粒度分析时我用hour(create_time)做分组然后就能清晰看到订单量的日内波动。我这份模拟数据跑出来的结果很贴近真实情况午高峰从11点启动、13点回落晚高峰是17点到20点凌晨2点到5点几乎没单。看到图表的那一刻你会觉得这批模拟数据是真的值了因为分析模型能匹配业务常识说明整个清洗和计算链路没有跑偏。3.2 热门商家TopN与品类占比的窗口函数写法热门商家排行榜是运营视角里最直观的指标。我一开始直接用GROUP BY算订单量然后ORDER BY LIMIT 10但这里有一个明显的坑如果两个商家的订单量并列第10名LIMIT 10会把其中一个截掉导致榜单显示不完整。改用窗口函数之后可以稳定地取到完整的并列名次。我的实现是这样写的SELECT merchant_id, merchant_name, order_cnt, rank_no FROM ( SELECT m.merchant_id, m.merchant_name, COUNT(o.order_id) AS order_cnt, DENSE_RANK() OVER (ORDER BY COUNT(o.order_id) DESC) AS rank_no FROM dwd_order_detail o JOIN dim_merchant m ON o.merchant_id m.merchant_id GROUP BY m.merchant_id, m.merchant_name ) t WHERE rank_no 10这里我用的是DENSE_RANK而不是RANK因为RANK遇到并列第一名后第三名的序号会直接从3开始而DENSE_RANK会从2开始能保证取出来的TopN数量永远是真实的N个。品类销售额占比的分析里我用了一个很实用的写法——窗口函数直接算全量总和SELECT category_name, SUM(total_amount) AS amount_sum, ROUND(SUM(total_amount) / SUM(SUM(total_amount)) OVER(), 4) AS amount_ratio FROM dwd_order_detail GROUP BY category_name ORDER BY amount_sum DESCSUM(SUM(total_amount)) OVER()这行的意思是把聚合后的金额再按全表窗口求和一步就得到占比比先聚合一次再单独Join一个总数表高效很多代码也简洁。如果你追求极致性能在数据量非常大的情况下TopN还可以换成repartition配合mapPartitions在每个分区内先取局部TopN再汇总到Driver端做全局排序能显著减少Shuffle的数据量。面试时主动说出这个优化点通常能让面试官眼前一亮。3.3 配送时效分析的DataFrame实现配送时效直接关系到用户对平台的第一印象也是外卖数据分析里很有业务特色的一个模块。我定义超时标准为配送时长超过30分钟然后按城市维度统计平均配送时长和超时率。PySpark的DataFrame写法如下from pyspark.sql import functions as F df spark.table(dwd_order_detail) df.withColumn( is_overtime, F.when(F.col(delivery_minutes) 30, 1).otherwise(0) ).groupBy(city_name).agg( F.round(F.avg(delivery_minutes), 1).alias(avg_delivery_minutes), F.round(F.avg(is_overtime) * 100, 2).alias(overtime_rate) ).orderBy(F.desc(overtime_rate))这一段把DataFrame API的核心操作全都带上了withColumn新增条件列、when/otherwise分支、groupBy分组、agg多指标聚合、alias重命名、orderBy排序。配送数据跑出来的结果也让我挺意外郊区城市的平均配送时长会比市中心高出七八分钟超时率跟配送距离呈明显正相关这些都是可以做业务延伸的观察点。如果你的分析系统后续要接入Spark Streaming这个配送时效模块是最适合做实时化的场景可以改成每5分钟刷新一次超时率看板用于监控运力是否充足。算是一个很有价值的扩展方向也是我在项目过程中最想继续完善的部分。3.4 分析结果写入MySQL与ECharts展示离线分析的结果全部通过Spark JDBC写回MySQL。这里有一个必须养成的习惯在MySQL里先把目标表的字段类型定义好再让Spark往里面写而不是直接使用df.write.jdbc自动建表因为自动建表出来的字段类型经常跟你的业务需求对不上后期查数据时会遇到类型转换问题。写入参数上我结合实际情况做了调整批量写入大小batchsize设置在1000到5000之间太小写库太慢太大则容易把executor的内存撑爆写入模式统一用overwrite因为分析结果每次都是全量重算不需要保留历史。可视化端我选了ECharts通过SpringBoot提供一个查询接口把MySQL里的聚合结果返回给前端图表组件。这样做的好处是整个系统的数据处理、后端、前端三层职责清晰答辩演示的时候也能分别讲清楚。我没有选择用Jupyter Notebook做展示虽然技术上更快但工程感和说服力会弱很多。如果想在简历里表达“我有完整项目经验”前后端分离、数据落库这些环节一个都不能少。4. 实战中踩过的坑数据倾斜、资源配置、时区问题4.1 商家数据倾斜导致任务卡死怎么定位和解决跑商家订单量分析时我第一次遇到了Spark里最经典的数据倾斜问题。某个头部商家的订单量是一般商家的上百倍按商家ID做JOIN和分组聚合时承载这个热点商家的executor要处理的数据量远超其他executor结果就是其他任务早就跑完了还有一两个任务卡在那里像死了一样。定位方法其实不复杂。先在Spark UI里看Task级别的耗时分布如果绝大多数Task在几秒内完成却有个别Task耗时是它们的几十倍基本就锁定倾斜了。然后再用SQL快速验证SELECT merchant_id, COUNT(*) AS cnt FROM dwd_order_detail GROUP BY merchant_id ORDER BY cnt DESC LIMIT 20如果发现前几个商家的数据量极度不合理就实锤了。解决思路用的是最常见的“加盐打散”给热点商家ID拼接一个随机前缀让它被分不到多个分区里去计算完成聚合后再去掉前缀做最终汇总。这个方案对绝大多数倾斜场景都有用代价是代码逻辑稍微复杂一些但面试时讲出这个方案绝对是个加分项。4.2 Executor内存和core到底怎么调资源参数是我一开始完全凭感觉配的一上来就给每个executor分配8GB内存、4个core结果集群并行度上不去任务排队特别严重整体跑得反而更慢。后来查阅大量经验帖才明白集群资源分配的核心约束单个executor的内存不要超过物理机可用内存的三分之一单个executor的core数控制在2到4个之间executor总数则由集群总资源除以单个executor的资源来反推。我调整后采用的配置是这样的配置项推荐值说明spark.executor.memory4g单executor内存别超过物理机1/3spark.executor.cores2单executor核数2-4之间优先取2spark.executor.instances4executor数量按并行度和资源反推spark.sql.shuffle.partitions100shuffle分区数数据量小就调低spark.default.parallelism100默认并行度和shuffle分区保持一致还有一个容易被忽略的点spark.sql.shuffle.partitions的默认值是200如果数据量不大200个分区会导致大量小文件和碎片化任务反而拖慢速度。在我的500万条数据场景下调整到100左右效果更好。这个参数不能死记硬背要根据数据量和集群规模做实验跑一版对比一下时间就清楚了。4.3 时区把晚高峰算成了凌晨这个坑必须讲时间字段的处理真的是一个极度隐蔽的坑。我最初生成模拟数据时顺手把时间写成了带时区的ISO格式比如2024-06-18T12:30:00Z。Spark读取后如果不做处理直接按日期分组得到的结果跟业务时间正好错开了——于是图表上显示的“晚高峰”出现在凌晨两三点。解决思路特别简单但不说出来你可能要排查好几天ETL阶段统一把时间字符串解析为yyyy-MM-dd HH:mm:ss格式并存储为TimestampType清洗之后的所有分析都基于这个已经归一化的字段不再保留原始时区信息。这样从根上杜绝了交叉转换带来的歧义。数据平台的项目里各种时间字段乱七八糟是最常见的数据质量问题宁可前期多花一点时间统一规范也不要后期反复返工。4.4 本地能跑、集群报错怎么办这个场景几乎每个人都遇见过。本地IDEA里跑得行云流水打成jar包丢到YARN上就报各种ClassNotFound或者连接超时。我归纳了一下大部分问题出在三处。第一依赖包缺失MySQL驱动、第三方组件没有通过--jars或--py-files打包进去解决办法就是在提交命令里把依赖显式带上第二Hive表在集群上没有创建或有权限问题提交前先到Hive CLI里手工验证一下目标表有没有数据第三日志遮住了真正的原因默认INFO日志刷几万行根本看不出问题建议提交时加上--conf spark.log.levelWARN然后重点去看YARN Container那一层的日志。如果上面这些都没解决还有一个终极大招先在同一份数据上把代码里可能出错的环节拆出来一个函数一个函数单独跑用排除法缩小范围。这样做看起来慢实际上比瞎猜日志快得多。5. 写在项目之后的一点体会整个项目从零到能跑、能演示前后花了我三周。中间被数据倾斜折磨过被时区坑过也经历过本地正常、集群必挂的经典窘境。但回过头去看那些当时觉得特别难搞的坑恰恰是我现在面试时最有底气的素材。如果你也想复刻这个项目我的建议是别急着追求技术栈有多新、指标有多复杂。先把数据分层和ETL做扎实再一个模块一个模块地实现分析任务最后再补上可视化和前后端打通。每一步都走稳了出来的项目自然会经得起别人追问。离线链路跑通之后你完全可以继续往Spark Streaming方向扩展。把订单量、销售额这些指标改成分钟级实时刷新项目就从一个离线分析系统升级成准实时数据平台了。到那时候你手里拿的不只是一个“课程设计”而是一段足够拿到任何大数据岗位面试里去讲的完整故事。本文还有配套的精品资源点击获取