简介基于Hadoop大数据生态与Spring Boot框架实现的电力生产数据分析系统面向计算机相关专业学生、毕设开发者及大数据入门者。系统覆盖HDFS存储、Yarn任务调度、pyspark数据预处理与分析配合Vue交互页面可支撑电力数据从采集入库到可视化分析的全流程演练。资源共369个文件约9.6MB含54个Java源码、24个Vue页面、13个Python脚本、96个XML配置以及SQL建表脚本、CSV样例数据、项目截图与搭建说明文档。代码已经测试运行成功并配有运行配置说明可作为课程设计、毕业设计或项目初期演示的完整参考也便于在此基础上二次扩展。当前已有166人学习下载适合需要将大数据分析与Web开发结合的读者参考学习。1. 电力生产数据分析到底在做什么这个项目值得你上手吗电表数据一多第一反应是加索引、加缓存但当地市级的采集点超过十万个、每15分钟上报一次电压、电流、功率时再快的数据库也只是把慢查询变成不那么慢的慢查询。这套基于Hadoop大数据springboot实现的电力生产数据分析系统思路是反过来的明细数据全部下沉到HDFS由MapReduce在夜间批量算成各类指标Spring Boot只负责把结果变成REST接口和可视化页面。它解决的是海量明细存储、周期性统计分析、报表展示这一整条链路适合做毕业设计、课程设计也适合想见识Hadoop与Spring Boot如何协作的初级开发。标题里写明的源码、文档说明、项目截图和项目搭建四件套构成一套能演示、能答辩、能二次开发的高分交付物。2. 架构与选型为什么电力数据分析要把Hadoop和Spring Boot组合在一起2.1 电力生产数据的三个数据特征直接决定存储选型电力生产数据与普通业务数据最大的区别在于时序性、海量性和多源异构性。一台电能表每15分钟产生一条采集记录一个中等规模的地市往往有数万到数十万台设备一天下来就是几百万行一年轻松破亿。再加上电压、电流、有功、无功、电度、温度、气压这些维度混在一起传统关系型数据库在单表亿级行数下做聚合查询索引基本失效慢查询能把接口拖到十几秒。HDFS恰好踩中了这个场景。它的设计目标是顺序读大文件而不是随机点查单行。电力数据是典型的追加写入、批量读取落盘时按时间分区折叠成文件计算时按台区、按日期扫整个文件这种访问模式与HDFS的块存储特性完全吻合。伪分布式环境下看起来只有一个节点但文件的block切分、副本机制、流式读取流程都一样拿到集群上只需要改配置就能扩。2.2 Spring Boot在架构里的真实角色结果服务化而不是计算很多人拿到这类项目以为Spring Boot里要算负荷、算线损这是最常见的误解。计算放到Spring Boot里做有一个硬伤数据在HDFS上Spark或MapReduce能带着计算逻辑直接跑在数据所在节点上而Spring Boot必须先把数据拉回内存再在JVM堆里做聚合数据一多直接OOM。这套系统里Spring Boot做的是结果服务化。MapReduce任务跑完后输出指标文件到HDFS再由一个同步任务把这些结果写入MySQLSpring Boot从MySQL读取并封装成REST接口给前端大屏和报表用。即使不接MySQLSpring Boot也可以直接通过FileSystem API读取HDFS上的结果文件按行解析返回JSON只是查询能力弱一些适合做演示。模块职责技术载体数据接入采集文件收集、CSV解析、落盘定时脚本或Flume数据存储明细文件、中间结果、最终指标HDFS批计算负荷聚合、电量统计、异常时段识别MapReduce Job服务层指标查询、报表接口、参数校验Spring Boot REST API展示层趋势图、台区排名、异常告警表ECharts页面或模板渲染2.3 选型边界什么场景下这套组合反而是过度设计这套方案并不是万金油。如果数据量只有几百万行、查询要求秒级响应Hadoop的序列化和任务调度开销反而会让系统更慢这时候MySQL加合理的索引设计就是最佳解。如果计算时效要求到分钟级甚至秒级比如用电异常实时告警那要引入的是Kafka、Flink这类的流处理架构批处理架构再硬套也答不了这个诉求。这块恰恰是答辩时最容易把你问住的问题。准备两个数据点放在心里数据量在千万级以内单机MySQL加上汇总表完全够用真正让Hadoop发挥价值的是明细数据上亿行、且分析任务是周期性T1批处理的场景。把这两句话讲清楚评审老师就知道你不是只会跑通Demo而是真的想过架构边界。大数据治理和集群部署的话题也在这里展开伪分布式只是教学形态生产上至少要三节点起步这也是从课程设计走向工程实践的必经一步。3. 从采集到出指标HDFS存储、MapReduce计算与Spring Boot接口的全链路实现3.1 模拟数据生成没有生产数据时怎么把链路跑起来真实电力生产数据拿不到这是所有做课设的人都会遇到的第一道坎。常见的做法是写脚本模拟采集数据字段参照电采系统的标准格式采集时间、台区编号、电压、电流、有功功率、无功功率、电度。我用Python生成CSV一是因为随机数生成方便二是可以和Hadoop的hadoop fs -put命令无缝衔接。import csv import random from datetime import datetime, timedelta start datetime(2025, 6, 1, 0, 0, 0) with open(power_daily.csv, w, newline) as f: writer csv.writer(f) writer.writerow([ts, area_id, voltage, current, active_power, reactive_power, energy]) for i in range(200000): t start timedelta(minutes15 * i) area fTA{random.randint(1, 100):04d} v round(random.uniform(215, 235), 1) c round(random.uniform(5, 60), 2) p round(v * c * random.uniform(0.85, 0.98), 2) writer.writerow([t.strftime(%Y-%m-%d %H:%M:%S), area, v, c, p, round(p * 0.3, 2), round(p * 0.25, 2)])这个脚本按15分钟一条的频率生成约200天、20万行数据文件不大但足够把整个链路跑通。timedelta(minutes15 * i)保证了时间序列连续递增台区编号用TA加四位数字模拟100个台区电压值保持在215到235伏的合理区间有功功率由电压乘电流再乘功率因数得到这样生成的数据在物理上说得通。做这个步骤时把area_id范围的随机种子固定下来这样每次生成的数据分布一致后续验证平均值、峰值这些指标时能对比得起来。我见过有人每次启动都重新生成数据导致前后两次分析结果对不上最后排查半天发现是数据源变了这种坑没必要踩。3.2 数据落地Spring Boot工程里用FileSystem API写入HDFSCSV生成在本地之后需要上传到HDFS指定目录。项目里通常会提供一个数据接入模块用Hadoop的Java API完成文件上传。注意这段代码必须放在Linux服务器或能连通HDFS集群的环境中运行本机Windows开发环境跑会有一堆native库的坑后面避坑章节会展开。String hdfsUri hdfs://node01:9000; String localFile /tmp/power_daily.csv; String targetDir /power/prod/2025/06; System.setProperty(HADOOP_USER_NAME, hadoop); Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfsUri); FileSystem fs FileSystem.get(conf); Path target new Path(targetDir /power_daily.csv); fs.copyFromLocalFile(false, true, new Path(localFile), target); fs.close();HADOOP_USER_NAME这个属性必须放在FileSystem.get之前它决定了以哪个用户身份访问HDFS。伪分布式下HDFS文件归属是启动Hadoop的那个系统用户Spring Boot进程默认用当前登录用户去访问两者不一致就会遇到Permission denied。copyFromLocalFile的第一个参数表示是否删除源文件第二个参数表示是否覆盖目标路径这里选不删源、允许覆盖方便反复调试。落盘之后用hadoop fs -ls /power/prod/2025/06确认文件存在再hadoop fs -text抽查几行数据确认字段没有错位。HDFS是二进制块存储用-text查看能自动解压并转换文本格式比-cat更稳。3.3 指标计算台区日均负荷的MapReduce实现与参数调优这是整个系统的核心计算环节。用MapReduce对HDFS上的明细文件做聚合统计每个台区每一天的平均有功功率。计算逻辑分两个阶段Mapper按行读取CSV把台区加日期拼成Key有功功率作为ValueReducer对同一个Key的所有功率值求和、计数输出平均值。public class AvgLoadMR { public static class AvgMapper extends MapperLongWritable, Text, Text, LongWritable { private Text outKey new Text(); private LongWritable outVal new LongWritable(); Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String line value.toString(); if (line.startsWith(ts)) { return; } String[] fields line.split(,); String area fields[1]; String date fields[0].substring(0, 10); long power (long) Double.parseDouble(fields[4]); outKey.set(area _ date); outVal.set(power); context.write(outKey, outVal); } } public static class AvgReducer extends ReducerText, LongWritable, Text, DoubleWritable { private DoubleWritable result new DoubleWritable(); Override protected void reduce(Text key, IterableLongWritable values, Context context) throws IOException, InterruptedException { long sum 0; long count 0; for (LongWritable v : values) { sum v.get(); count; } result.set((double) sum / count); context.write(key, result); } } public static void main(String[] args) throws Exception { Configuration conf new Configuration(); Job job Job.getInstance(conf, area avg load); job.setJarByClass(AvgLoadMR.class); job.setMapperClass(AvgMapper.class); job.setReducerClass(AvgReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(DoubleWritable.class); job.setMapOutputValueClass(LongWritable.class); job.setNumReduceTasks(3); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }两个参数最容易配错。setOutputValueClass必须与Reducer实际输出的类型一致这里Reducer输出的是DoubleWritable因为平均值是浮点数而Mapper输出的Value是LongWritable所以要单独设置setMapOutputValueClass否则运行时会抛序列化异常。setNumReduceTasks(3)控制分区数量伪分布式单节点上2到3个合适Reducer数量超过CPU核数反而增加调度开销。MapReduce的输入输出路径通过args[0]和args[1]传入打成jar后用hadoop jar命令提交。打成jar时注意不要用Spring Boot的fat jar直接提交Hadoop对嵌套jar的类加载支持不好通常做法是用maven打包出瘦jar并把依赖置入Hadoop classpath。3.4 服务出口Spring Boot把计算结果变成REST接口MapReduce跑完的结果落在HDFS的/power/out/part-r-00000文件里每行是一个台区加日期和平均功率。Spring Boot这里选择一个稳妥的方案用FileSystem直接读取结果文件解析成JSON返回给前端。这样省掉同步MySQL的环节链路最短适合演示环境。RestController RequestMapping(/api/power) public class AnalysisController { private final AnalysisService analysisService; public AnalysisController(AnalysisService analysisService) { this.analysisService analysisService; } GetMapping(/area/avg) public ResultListMapString, Object areaAvg( RequestParam String startDate, RequestParam String endDate) { ListMapString, Object data analysisService.readAvgResult(startDate, endDate); return Result.success(data); } }public ListMapString, Object readAvgResult(String startDate, String endDate) { ListMapString, Object result new ArrayList(); String path hdfs://node01:9000/power/out/part-r-00000; Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://node01:9000); try (FileSystem fs FileSystem.get(conf); BufferedReader reader new BufferedReader(new InputStreamReader(fs.open(new Path(path))))) { String line; while ((line reader.readLine()) ! null) { String[] parts line.split(\\t); String[] areaDate parts[0].split(_); String area areaDate[0]; String date areaDate[1]; if (date.compareTo(startDate) 0 date.compareTo(endDate) 0) { MapString, Object item new HashMap(); item.put(areaId, area); item.put(date, date); item.put(avgPower, Double.parseDouble(parts[1])); result.add(item); } } } catch (IOException e) { throw new RuntimeException(读取HDFS结果文件失败, e); } return result; }这样实现有几个值得注意的细节。FileSystem要放到try-with-resources里用完整URI而不是路径字符串否则会走默认文件系统配置。日期过滤用字符串compareTo做比较因为日期格式是定长的yyyy-MM-dd字典序就是时间序省去了SimpleDateFormat的解析开销。接口返回的Result是统一响应体包含code、message、data三个字段前端拿到后按code200判断成功。把HDFS读文件这段逻辑抽成独立的AnalysisService后续如果想替换成MySQL数据源只需改Service实现而不用动Controller。4. 从零开始搭伪分布式Hadoop安装配置与Spring Boot接入的完整步骤4.1 版本搭配与SSH免密先定好这三件事再动手Hadoop伪分布式搭建是整套系统里最耗时的部分但绝大多数坑都源于版本搭配问题。我的建议是第一件事先定版本不要凭感觉用最新版。组件版本建议核心理由JDK1.8Hadoop 3.x与Spring Boot 2.x均兼容二进制兼容性最稳Hadoop3.3.x稳定版本网上资料和踩坑记录最全Web UI端口为9870Spring Boot2.7.x使用javax命名空间与hadoop-client依赖无冲突MySQL5.7或8.0存结果表和系统配置两个版本都可用Spring Boot 3.x不建议在这个项目里用它切换到了jakarta命名空间而Hadoop的hadoop-client依赖还停留在javax体系混用会出现各种ClassNotFoundException。这种问题排查起来非常费时间属于典型的没必要踩的坑。装完JDK后先做SSH免密登录。Hadoop的启动脚本通过SSH远程控制本机的NameNode和DataNode进程不做免密的话每次启动都要输密码脚本直接卡住。ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost-P 表示空密码-f指定生成路径这两条必须一起写否则会交互式询问。最后一条ssh localhost如果直接进入终端而没有提示输入密码说明免密成功可以exit退出。伪分布式下NameNode和DataNode都在本机所以只需要配置localhost免密不需要配置到其他机器。4.2 core-site.xml与hdfs-site.xml必须写对的核心参数Hadoop解压后有两个关键配置文件core-site.xml定义文件系统入口hdfs-site.xml定义NameNode和DataNode的数据目录与副本策略。这两个文件一旦配错大概率启动时或上传文件时报各种奇怪的错。!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://node01:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///data/hadoop/name/value /property property namedfs.datanode.data.dir/name valuefile:///data/hadoop/data/value /property property namedfs.namenode.http-address/name valuenode01:9870/value /property /configurationhadoop.tmp.dir是元数据的基础目录默认指向/tmp/hadoop-${user}系统重启清空tmp后NameNode会丢失元数据这是新手最常踩的坑。把它固定到/data/hadoop/tmp同时把name和data目录也移到非tmp路径这样数据落地后不会因为系统清理而丢失。dfs.replication设为1伪分布式只有一个DataNode副本数设为3会导致文件一直处于副本不足状态。node01这个主机名要和/etc/hosts里的映射一致或者直接改成localhost。很多人配置了hdfs://node01:9000但hosts文件没配node01导致客户端解析不到地址报UnknownHostException。检查方式是ping node01能通就说明hosts没问题。4.3 格式化、启动与验证jps之外还要看什么配置完成后需要先格式化NameNode再启动HDFS和YARN。格式化只做一次重复格式化会留下clusterID不一致的问题这个在避坑章节详细说。hdfs namenode -format start-dfs.sh start-yarn.sh jpsjps输出里看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这五个进程说明启动成功。这时候打开浏览器访问http://localhost:9870能看到NameNode的Web UI才算稳妥。Hadoop 2.x的用户注意端口是50070不是9870。有个细节容易忽略Hadoop的bin目录下有个hadoop-env.sh脚本里面默认JAVA_HOME是空的或者指向不存在的路径。即使系统环境变量里配置了JAVA_HOMEHadoop的daemon脚本也不一定读取得到建议在hadoop-env.sh里显式写一行export JAVA_HOME/usr/local/jdk1.8.0_xxx路径换成你实际的JDK安装目录。这一行能省掉启动时JAVA_HOME is not set的报错。启动完成后在HDFS上创建项目目录hadoop fs -mkdir -p /power/prod hadoop fs -mkdir -p /power/out hadoop fs -ls /4.4 Spring Boot连接HDFS依赖、配置与最小验证代码伪分布式跑起来后Spring Boot侧需要引入hadoop-client依赖并配置连接参数。pom里加依赖时注意作用域设为compilehadoop-client会把一堆依赖带进来和Spring Boot的依赖管理有过冲突的可能但不是必现保持2.7.x和3.3.x组合一般没问题。dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-client/artifactId version3.3.6/version /dependencyapplication.yml里把HDFS的连接信息、用户身份和目录配置成外部变量避免硬编码hadoop: hdfs-uri: hdfs://node01:9000 user: hadoop input-dir: /power/prod/2025/06 output-dir: /power/out server: port: 8080Spring Boot里用ConfigurationProperties绑定这批配置参数再写一个HdfsClient配置类把这个类交给Spring管理Component public class HdfsConfig { Value(${hadoop.hdfs-uri}) private String hdfsUri; Value(${hadoop.user}) private String user; public FileSystem getFileSystem() throws IOException { System.setProperty(HADOOP_USER_NAME, user); Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfsUri); return FileSystem.get(conf); } }这样每次调用getFileSystem拿到的都是连接hdfs://node01:9000、以hadoop用户身份访问的FileSystem实例。验证连接是否成功最直接的办法是写一个CommandLineRunner启动项目时列出HDFS根目录Component public class HdfsStartupCheck implements CommandLineRunner { private final HdfsConfig hdfsConfig; public HdfsStartupCheck(HdfsConfig hdfsConfig) { this.hdfsConfig hdfsConfig; } Override public void run(String... args) throws Exception { try (FileSystem fs hdfsConfig.getFileSystem()) { FileStatus[] statuses fs.listStatus(new Path(/)); System.out.println(HDFS连接成功根目录文件数: statuses.length); } } }Spring Boot启动日志里出现“HDFS连接成功”字样说明整条链路已经通了。到这里Hadoop伪分布式集群、数据上传、MapReduce计算、Spring Boot接口四层全部就位接下来才是真正有意思的部分把系统跑给评审看并应付各种突发问题。5. 高频避坑记录从数据采集到图表展示的5个翻车点5.1 反复格式化NameNode后DataNode启动即退出现象第一次格式化启动一切正常之后因为某些原因删掉name目录重新format再启动时DataNode进程起来几秒就自动退出NameNode的Web UI里看不到任何节点。日志里出现clusterID不匹配的异常。原因格式化只会重置NameNode元数据DataNode的data目录里还保留着旧的clusterID。NameNode新生成的clusterID和DataNode持有的不一致导致DataNode认为自己不属于这个集群拒绝注册。解决stop-all.sh停掉所有进程把dfs.namenode.name.dir和dfs.datanode.data.dir对应目录全部删干净确保name和data两边都是全新状态再重新hdfs namenode -format并启动。格式化前先想清楚是不是必须做伪分布式环境里元数据损坏的概率极低大多数反复格式化都是自己吓自己。5.2 Spring Boot访问HDFS报Permission denied现象命令行用hadoop fs操作文件一切正常Spring Boot代码里一调FileSystem.get就抛AccessControlException: Permission denied。原因命令行工具默认以启动Hadoop的Linux用户身份操作而Spring Boot进程是以当前系统用户启动的。如果Spring Boot用root启动HDFS上的文件owner是hadoop这个普通用户root在HDFS的权限模型里并不特殊照样被拒。解决在FileSystem.get之前设置System.setProperty(HADOOP_USER_NAME, hadoop)让Java进程伪装成hadoop用户访问。这个设置必须在获取FileSystem之前否则不生效。如果想彻底省事也可以hadoop fs -chmod -R 777 /power把目录权限放开但这是偷懒做法答辩时被问到权限模型会露怯还是建议用系统属性方式。5.3 Windows本机开发连不上Linux伪分布式集群现象Windows上用IDE启动Spring Boot访问HDFS时报Failed to set permissions of path或Could not locate executable null\bin\winutils.exe。原因Hadoop的本地库是Linux平台编译的Windows上缺winutils.exe和hadoop.dllJava进程无法完成文件权限设置。再加一句大实话Windows上跑Hadoop客户端代码类似的问题层出不穷不只是缺这两个文件的问题。解决我的经验是最省心的方案是让Spring Boot跑在Linux服务器上Windows只做代码编辑和数据库连接把部署目标环境直接定为Linux。如果一定要在Windows调试可以下载对应Hadoop版本的winutils.exe放到本地HADOOP_HOME的bin目录再配置HADOOP_HOME环境变量但即使这样也可能遇到版本不匹配的玄学问题。把时间花在正事上不要在Windows上死磕Hadoop native库。5.4 Reduce卡在99%不动数据倾斜还是参数问题现象MapReduce任务跑起来Map阶段很快完成Reduce进度停在99%超过十几分钟任务最终超时失败或者勉强成功但耗时长到离谱。原因最典型的是数据倾斜。模拟数据里台区编号是随机生成的但某些台区恰好被分配到大量数据对应的Reducer要处理几倍于其他Reducer的数据量。另外setNumReduceTasks设置过少也会让单个Reducer承担全量数据。解决先看任务日志里每个Reducer的输入字节数如果某个Reducer明显比其他大就是倾斜。模拟数据场景下最简单的处理是生成数据时控制台区数据量的均匀性或者对Key加盐中间Key改成area _ date _ (随机数 % N)让数据分散到N个临时分区再在下一轮job按真实Key聚合。伪分布式单节点上Reduce数量调到2到3就够调成10个只会增加文件碎片不会变快。5.5 接口返回空数组但日志没有任何报错现象前端图表一片空白Spring Boot接口返回HTTP 200和空数组控制台没有任何异常。数据库表也是空的但系统看起来一切正常。原因数据链路断了而且断得悄无声息。最常见的是定时同步任务没跑起来MapReduce结果已经在HDFS上但MySQL结果表没有数据Spring Boot查空表自然返回空数组。这类问题隐蔽在链路中间日志无感知。解决逐段验证不要从上到下猜。第一站在HDFS上查中间结果是否存在hadoop fs -cat /power/out/part-r-00000 | head -20看文件内容是否正常。第二站查MySQL结果表行数select count(*) from area_avg_result。第三站看Spring Boot连的库是不是你查的那个库很多时候是测试环境和开发环境配置串了。直接在HdfsConfig里加一个调试接口把HDFS结果文件的内容原样返回这样在前端页面就能看到是哪一段出了问题排查效率高一截。6. 从跑通到高分演示前必做的三个验证和一个进阶改造项目跑起来只是起点演示时的关键操作才是拿分的地方。第一个验证是展示MapReduce的计算结果确实落在HDFS上用hadoop fs -ls /power/out列出输出目录再用hadoop fs -cat /power/out/part-r-00000 | head -20抽查几行证明计算不是Mock出来的。第二个验证是接口数据与批处理结果对得上。手工选取一个台区一天的数据用Excel汇总平均功率再调用curl http://localhost:8080/api/power/area/avg?startDate2025-06-01endDate2025-06-07两手结果一致这比口头说十句“系统正常”都有说服力。第三个验证是HDFS的持久性。演示现场把NameNode进程杀掉再重启然后hadoop fs -ls /power/prod确认数据还在顺便点出HDFS副本机制的原理。这个演示点很能体现你对系统的理解程度讲师和评委通常会多看你一眼。进阶改造上如果时间允许把MapReduce换成Spark用同样的输入路径跑一遍对比两者耗时这在大数据面试里是很加分的实践经历。再往前一步用crontab -e配一个每天凌晨两点执行Mapper任务的定时器构建出T1报表的完整节奏这就从一个一次性演示系统变成了一个有生产雏形的分析平台。我当年第一次搭这套环境反复格式化NameNode就折腾了一整个下午最后发现只是DataNode的clusterID没清干净。后来带人做类似的项目我把这些验证步骤固定成了模板环境搭好先验证HDFS写读再跑一个最小MapReduce最后才接Spring Boot每一步都有明确的检查点。只要按这个顺序走这类系统极少跑不起来。希望帮到你。本文还有配套的精品资源点击获取