MapReduce+SpringBoot+Vue构建地铁大数据分析系统实战

想直接复现一套完整的地铁大数据分析系统（MapReduce+SpringBoot+Vue），同时又不想只停留在“跑通Demo”层面，那这篇内容正好对你有用。我会把整套项目的核心模块拆开，从数据怎么造、离线计算怎么做、后端接口怎么设计，到前端大屏怎么调，一步一步还原我当时做这个项目的决策过程和实现细节。适合正在做大数据课设、毕设，或者想入门Hadoop生态与Java全栈开发的读者参考，也适合准备面试前拿真实项目练手的朋友。

1. 整体设计思路：为什么要用MapReduce + SpringBoot + Vue这套组合

1.1 技术选型背后的四个考量

很多人在选型时容易陷入“哪个火就上哪个”的误区，但实际做项目，尤其是教学型或毕设型的大数据项目，技术选型得考虑四个维度：数据规模、计算类型、团队能力、部署成本。

我先说结论：这套系统用MapReduce做离线批处理，用SpringBoot提供查询接口，用Vue做数据可视化，对应的是经典的大数据离线分析链路。为什么不选Spark或Flink？原因很简单——MapReduce能更清晰地暴露“分而治之”的完整过程，方便理解Hadoop的核心机制；而Spark的DAG优化、内存计算等概念会干扰初学者对数据流转过程的感知。如果你的目标是学习，MapReduce是必须跨过的门槛；如果你是给企业做生产系统，那另说，但项目本身的教学价值会大打折扣。

SpringBoot负责服务层也是同理。Hadoop计算完的结果文件躺在HDFS上，不能让前端直接去读文件，中间必须有个业务网关。SpringBoot的优势是生态成熟、配置简单、写REST接口高效，尤其适合把MapReduce产出的一堆part-r-00000文件导入MySQL后做条件查询。

前端选Vue，核心原因是组件化和数据绑定。数据大屏类页面有大量重复的图表卡片，用Vue的组件机制可以很清晰地把“线图卡片”“柱图卡片”“排行卡片”抽象成独立组件，一个组件传不同参数就能复用到多个位置。另外Vue对ECharts的适配非常好，各种社区方案很成熟，踩坑成本低。

1.2 整个系统的数据流闭环

地铁数据的分析流程其实可以类比成一个“加工流水线”：

• 原始数据层：模拟产生的地铁刷卡/AFC数据，存到HDFS的指定目录下，按日期分区存放。
• 离线计算层：运行多个MapReduce任务，分别统计进站量、出站量、客流高峰时段、线路客流分布、OD（起点-终点）区间流量等指标。
• 结果落地层：MapReduce把统计结果写入HDFS，再用Sqoop或自写Java API把结果导入MySQL，按天或按小时分表。
• 服务接口层：SpringBoot读取MySQL数据，封装成统一的JSON结构，提供RESTful接口给前端。
• 可视化展示层：Vue + ECharts按接口返回的数据渲染大屏。

这套链路最大的好处是每一层都独立，可以单独替换。比如之后想把MapReduce换成Spark或者Flink，只需要把“离线计算层”的输出格式保持一致，其他层完全不用动。我当时把MapReduce结果导出MySQL时写了一个通用的导入工具，后来做扩展时省了很多事。

1.3 没有真实数据时，数据模拟策略怎么定

做这种系统最常遇到的尴尬是：没有官方开放的AFC数据。网上能找到的公开数据集要么格式老旧，要么字段对不上需求，所以绝大多数项目最终都是自己写程序模拟数据。

模拟数据不是乱造几个数字，而是要尽量贴合地铁客流的真实规律。我当时整理了几条核心规则：

• 早晚高峰效应：早高峰7:00-9:00，晚高峰17:00-19:00，客流量是平峰的5到8倍。
• 站点热度差异：换乘站、商业中心站（比如城市CBD附近）、交通枢纽站的客流量远大于普通居民区站。
• 方向不平衡：早高峰时住宅区进站量大、CBD出站量大，晚高峰相反，所以统计进站量和出站量时要反映这种潮汐现象。
• 周末与工作日差异：周末没有明显早晚高峰，整体客流偏低，但下午到傍晚会出现一个小高峰。
• 线路差异：穿越市中心的地铁线（通常是一号线、二号线这类老线）客流量显著高于新开的郊区线。

模拟程序可以用Java写，也可以直接用Python脚本生成CSV，再传到HDFS。我的做法是用Java写一个数据生成器，因为这样整个项目只用一套技术栈，后续如果要和SpringBoot整合比较方便。生成器里定义好站点列表、线路拓扑、各站点权重系数，再按时间戳生成一条条刷卡记录。

2. 数据生成与HDFS准备：细节决定后续计算是否顺畅

2.1 模拟数据字段与格式设计

我设计的原始记录采用CSV格式，一行代表一次地铁行程记录，字段如下：

text复制record_id, card_id, station_id, station_name, line_id, line_name, action_type, action_time, amount

• record_id：全局唯一记录ID，用UUID或者自增数字。
• card_id：刷卡卡号，模拟城市一卡通的逻辑卡号（16位数字）。
• station_id / station_name：进出站的站点ID和名称，站名设计为广州地铁真实站点命名的风格。
• line_id / line_name：线路编号与名称。
• action_type：0001代表进站，0002代表出站，方便区分。
• action_time：刷卡时间，格式为yyyy-MM-dd HH:mm:ss。
• amount：扣费金额，按里程来算，这里简化成按站点数区间收费（2元、3元、4元、5元四档）。

这里有一个容易踩坑的地方：不要把字段设计得太花哨，重要的是分析时用不用得上。我当时添加过“闸机编号”“车厢编号”这类字段，后来发现MapReduce任务里根本用不到，反而增加文件体积和模拟复杂度。字段够用就好，后期要扩展再加。

2.2 模拟算法：让数据“看起来像真的”

客流模拟的关键是实现“泊松分布效果”，也就是数据量在时间段上要符合统计规律。我先定义一天24小时每个小时的基础客流权重：

java复制// 每小时客流权重（占比），25个元素对应0-24点
double[] hourWeights = {
    0.3, 0.2, 0.2, 0.2, 0.3, 0.8,   // 0-5点
    2.5, 6.0, 8.5, 4.5, 3.0, 3.5,   // 6-11点
    4.0, 3.5, 3.5, 4.0, 4.5, 7.5,   // 12-17点
    8.5, 5.5, 3.0, 2.0, 1.0, 0.5    // 18-23点
};

然后根据当天是否是工作日做缩放，周末就折叠早晚高峰，比如周六把早上8点的峰值放到10点，峰值系数设到0.6左右。站点热度通过权重表控制：每个站点有一个基础热度因子，生成线路时按比例决定该站被选中的频率。

生成动作时，进站和出站要成对出现。最简单的做法是：先随机生成若干个进站事件，然后对每个进站事件设定一个随机时长（比如15到90分钟），再生成对应的出站事件。这样保证了OD数据是有效的，不会出现只有进没有出。

我还会往数据里注入小比例（约1%）的异常记录，比如站名乱码、时间为空、金额为负，用于测试后续清洗环节。自己造数据时加入脏数据，是训练数据清洗能力的一个好方法。

2.3 上传HDFS：目录规划与文件大小控制

HDFS目录规划我建议按日期分一层，再按数据类型分一层，比如：

text复制/metro/raw/20240501/records.csv
/metro/raw/20240502/records.csv

如果每天的数据拆成多个文件，那就放在同一天目录下：

text复制/metro/raw/20240501/part1.csv
/metro/raw/20240501/part2.csv

上传命令很简单：

bash复制hdfs dfs -mkdir -p /metro/raw/20240501
hdfs dfs -put ./data/20240501_*.csv /metro/raw/20240501/

文件大小控制上，有一点要提醒：MapReduce处理大文件比处理大量小文件高效得多。如果模拟程序把一天的记录拆成了几百个小文件，每个只有几十KB，MapReduce启动的任务数量会暴增，整个作业的性能会非常难看。建议把一天的数据合并成1到4个文件，每个文件控制在几十MB以上。可以用数据生成器直接批量写，也可以上传后用 hdfs dfs -merge 合并文件。

3. MapReduce离线计算：从写Mapper到跑通到底要过几道坎

3.1 核心指标拆解与MapReduce任务设计

整套系统的核心计算任务有四个，对应我最终的四个MapReduce作业：

• 任务一：各站点日进出站客流统计。输入原始CSV，输出每个站点的进站总量、出站总量。按 station_id 分组。
• 任务二：各站点分时段客流分析。输入原始CSV，输出“站点 + 小时”维度的客流热力数据，用来支撑前端热力图和24小时曲线图。
• 任务三：各线路客流分布统计。按 line_id 分组，统计全天各线路的总客流与各站点客流占比。
• 任务四：OD区间流量分析。把同一个 card_id 的进站记录和出站记录配对，统计“站点A到站点B”的OD流量，用于前端桑基图或OD矩阵图。

这四项指标对应了大屏上最核心的几个模块。你也可以根据自己的业务场景换成“温度分析”“用户画像”等，但整体设计思想是一样的——把原始数据按维度聚合成可读的统计结果。

3.2 自定义Writable与MapReduce代码实现要点

任务一的代码比较典型，我贴一段核心逻辑说明用法。首先，MapReduce的Reduce输出需要自定义一个可序列化对象，用来同时携带进站量和出站量：

java复制import org.apache.hadoop.io.Writable;
import java.io.DataInput;
import java.io.DataOutput;
import java.io.IOException;

public class StationFlowWritable implements Writable {
    private long inCount;
    private long outCount;

    public StationFlowWritable() {}

    public StationFlowWritable(long inCount, long outCount) {
        this.inCount = inCount;
        this.outCount = outCount;
    }

    @Override
    public void write(DataOutput out) throws IOException {
        out.writeLong(inCount);
        out.writeLong(outCount);
    }

    @Override
    public void readFields(DataInput in) throws IOException {
        this.inCount = in.readLong();
        this.outCount = in.readLong();
    }
    // getter/setter 省略
}

这里有一个非常关键的注意事项：write 和 readFields 中的字段读写顺序必须完全一致，否则反序列化时会错位。我当时第一次调试时把 inCount 和 outCount 的顺序写反了，导致所有结果都反了，排错过程极其痛苦。建议养成“先写long就先读long，字段顺序和类中声明顺序保持一致”的编码习惯。

接下来是Mapper类：

java复制import org.apache.hadoop.io.LongWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Mapper;
import java.io.IOException;

public class StationFlowMapper extends Mapper<LongWritable, Text, Text, StationFlowWritable> {

    private Text stationKey = new Text();

    @Override
    protected void map(LongWritable key, Text value, Context context)
            throws IOException, InterruptedException {
        String line = value.toString();
        // 简单跳过CSV表头
        if (line.startsWith("record_id")) {
            return;
        }
        String[] fields = line.split(",");
        if (fields.length < 8) {
            return;
        }
        String stationId = fields[2];
        String actionType = fields[6];
        stationKey.set(stationId);
        if ("0001".equals(actionType)) {
            context.write(stationKey, new StationFlowWritable(1, 0));
        } else if ("0002".equals(actionType)) {
            context.write(stationKey, new StationFlowWritable(0, 1));
        }
    }
}

Reducer就是对同一站点的进站量和出站量累加：

java复制import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Reducer;
import java.io.IOException;

public class StationFlowReducer extends Reducer<Text, StationFlowWritable, Text, Text> {

    @Override
    protected void reduce(Text key, Iterable<StationFlowWritable> values, Context context)
            throws IOException, InterruptedException {
        long totalIn = 0;
        long totalOut = 0;
        for (StationFlowWritable val : values) {
            totalIn += val.getInCount();
            totalOut += val.getOutCount();
        }
        String result = totalIn + "\t" + totalOut;
        context.write(key, new Text(result));
    }
}

Driver类里需要设置Job的关键参数，这里有一点要特别提醒：如果输入路径指向的是HDFS目录，不要写本地文件路径。我见过很多新手把输入路径写成本地路径，跑起来一直报文件找不到。提交时务必用 hdfs:// 前缀或者先 cd 到Hadoop环境下用相对路径。

java复制import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;

public class StationFlowDriver {
    public static void main(String[] args) throws Exception {
        Configuration conf = new Configuration();
        Job job = Job.getInstance(conf, "station flow");
        job.setJarByClass(StationFlowDriver.class);

        job.setMapperClass(StationFlowMapper.class);
        job.setCombinerClass(StationFlowReducer.class); // 注意这里
        job.setReducerClass(StationFlowReducer.class);

        job.setMapOutputKeyClass(Text.class);
        job.setMapOutputValueClass(StationFlowWritable.class);
        job.setOutputKeyClass(Text.class);
        job.setOutputValueClass(Text.class);

        FileInputFormat.addInputPath(job, new Path(args[0]));
        FileOutputFormat.setOutputPath(job, new Path(args[1]));

        System.exit(job.waitForCompletion(true) ? 0 : 1);
    }
}

Combiner的使用是一个亮点，值得多说一句。Combiner是在Map端做的本地聚合，可以减少shuffle阶段的数据传输量。对于求和类的Reducer，Combiner可以直接复用Reducer逻辑。但这个项目里任务二的Reducer逻辑不是单纯求和，而是按小时分组累加，所以Combiner不能直接复用Reducer，得单独写一个。很多人习惯无脑复用，碰上逻辑复杂的Reducer就会出问题。

3.3 任务二、三、四的区别与实现差异

任务二需要同时知道“站点”和“小时”两个维度，Map端的Key就要设计成组合Key。最简单的办法是把 stationId + "#" + hour 拼成字符串。

小时可以从 action_time 字段中截取：action_time.substring(11, 13)。然后统计进站量时，先判断actionType，再截取小时，拼出Key，Value依然用自定义的Writable。

任务三相对简单，把Key换成 lineId，统计每条线路的总流量。如果还要统计“线路-站点”级别，就按 lineId + "#" + stationId 做Key。

任务四稍微复杂，因为需要配对“同一张卡号的进站和出站记录”。我用的方案是：Map阶段输出Key为 card_id，Value里带上“进站/出站标记、站点ID、时间”这些信息。Reduce阶段把同一个卡号的所有记录收集起来，按时间排序，然后两两配对成OD记录。

OD任务的Reduce阶段需要注意内存，如果单卡记录非常多（正常情况下不会，但设计上要有防御），建议在Map端就过滤掉只有一个动作的卡号，或者在Reduce端做好裁剪。我当时给同一个卡的记录数设了一个上限，超过阈值就跳过该卡号，因为正常情况下一个用户一天最多也就五六条记录。

MapReduce作业跑完后，输出目录里会出现 part-r-00000 这样的文件。这是最标准的产出。我看到很多人拿到结果文件后直接拷贝到本地，再用Excel打开，其实这不是推荐的链路。正确的做法是把结果导入MySQL，再用后端接口去查询。特别是项目要交报告或答辩演示时，把结果固化到数据库里，避免了每次演示都要重新跑一遍MapReduce的尴尬。

3.4 从HDFS结果导出到MySQL：两条路线对比

结果落地MySQL我试过两种方式，各有适用场景。

方式一：Sqoop导入

Sqoop是专门做HDFS和关系型数据库之间数据迁移的工具。命令大致如下：

bash复制sqoop export \
  --connect jdbc:mysql://localhost:3306/metro_db \
  --username root --password 123456 \
  --table station_daily_flow \
  --export-dir /metro/output/station_flow \
  --input-fields-terminated-by '\t' \
  --columns station_id,in_count,out_count

Sqoop的优势是命令简单，适合字段完全对齐的导出场景。但要注意：目标MySQL表必须在导出前建好，且表结构和HDFS里的字段顺序要完全对应。另外Sqoop版本与Hadoop版本兼容性也是个坑，Sqoop1.4.7对Hadoop2.x支持很好，对Hadoop3.x就需要额外处理，我当时在Hadoop3.1.3环境里折腾了很久。

方式二：自写Java导入工具

这个方式更灵活，也更能体现对完整链路的掌控。我在SpringBoot工程里写了一个Jar包工具，通过HDFS Java API读取MapReduce的结果文件，逐行解析后批量插入MySQL。核心代码思路：

java复制FileSystem fs = FileSystem.get(new URI("hdfs://localhost:9000"), new Configuration(), "hadoop");
RemoteIterator<LocatedFileStatus> files = fs.listFiles(new Path("/metro/output/station_flow"), false);
while (files.hasNext()) {
    LocatedFileStatus fileStatus = files.next();
    if (fileStatus.getPath().getName().startsWith("part-")) {
        FSDataInputStream in = fs.open(fileStatus.getPath());
        BufferedReader reader = new BufferedReader(new InputStreamReader(in));
        String line;
        while ((line = reader.readLine()) != null) {
            String[] fields = line.split("\t");
            // 拼接SQL或使用PreparedStatement批量插入
        }
        reader.close();
    }
}

这个方案唯一的麻烦点是要处理HDFS的Java API版本兼容，但一旦跑通，后续导入任何结果都能用，而且可以在导入过程中做二次加工，比如把字符串形式的日期转成Date、把String数字转成Long等。

4. SpringBoot后端接口层：让数据在合适的时间出现在合适的地方

4.1 表结构设计与MyBatis-Plus使用

MapReduce的结果导入MySQL后，对应的表结构需要提前设计好。我建的四张核心表：

sql复制CREATE TABLE station_daily_flow (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    stat_date VARCHAR(10),
    station_id VARCHAR(20),
    station_name VARCHAR(50),
    in_count BIGINT,
    out_count BIGINT,
    total_count BIGINT
);

CREATE TABLE station_hour_flow (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    stat_date VARCHAR(10),
    station_id VARCHAR(20),
    hour INT,
    in_count BIGINT,
    out_count BIGINT
);

CREATE TABLE line_flow (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    stat_date VARCHAR(10),
    line_id VARCHAR(10),
    line_name VARCHAR(20),
    total_count BIGINT
);

CREATE TABLE od_flow (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    stat_date VARCHAR(10),
    start_station VARCHAR(50),
    end_station VARCHAR(50),
    od_count BIGINT
);

这里有个设计细节：存 station_id 是为了关联计算，存 station_name 是为了前端直接展示，省去前端再调一次基础信息接口的开销。total_count 存储的是进站和出站的总和，前端排序时直接用这一个字段，避免后端实时计算。

SpringBoot层我搭配了MyBatis-Plus，主要是为了减少重复的CRUD代码。写一个实体类、一个Mapper接口，继承 BaseMapper，就能直接调用 selectList、selectPage 等方法。

4.2 REST接口设计与统一返回结构

接口设计遵循“按查询条件返回对应维度数据”的原则。比如前端要展示“2024-05-01当天各站点客流排行”，对应的接口就是：

bash复制GET /api/station/daily?date=2024-05-01&limit=20

返回的JSON结构统一为：

json复制{
    "code": 0,
    "message": "success",
    "data": [
        {
            "stationName": "珠江新城",
            "totalCount": 52340,
            "inCount": 26012,
            "outCount": 26328
        }
    ]
}

统一返回结构的好处是前端可以写一个通用的axios拦截器，只用看 code 是否为0，不用每个接口单独处理异常。我在Controller里加了 @CrossOrigin 注解解决跨域问题。

4.3 接口性能优化与缓存思路

数据量大时，接口查询频繁。每天的分时数据维度是“站点 x 小时”，一天下来就是上千条记录，前端大屏通常每5秒轮询一次，频繁查库对MySQL压力不小。我当时用SpringBoot内置的 @EnableCaching + Caffeine 做了一层本地缓存，对“24小时内不变化的数据”缓存1小时，对实时性要求不高的接口缓存5分钟。

实现方式很简单，在Service方法上加注解：

java复制@Cacheable(value = "stationDaily", key = "#date")
public List<StationDailyFlowVO> getDailyFlow(String date) {
    return stationDailyFlowMapper.selectDailyFlow(date);
}

在实际部署中，这种缓存策略能把接口平均响应时间从80ms降到5ms以内。大屏演示时尤其爽，页面切换几乎无感。

5. Vue可视化大屏：让数据从表格变成一眼能看懂的图

5.1 前端工程结构与布局方案

可视化大屏我用的技术栈是Vue2 + ECharts + Axios + Vue Router。为什么没用Vue3？因为我当时团队的Node版本和项目模板工具链对Vue3的支持还不完善，用Vue2能稳定少踩很多坑。如果你的环境是新的，可以上Vue3 + Vite，但对于大屏这种强依赖ECharts渲染的场景，Vue2已经很成熟了。

大屏布局采用经典的16:9设计稿。全屏容器用 autofit 方案实现自适应缩放，保证在不同分辨率屏幕上都能完整显示。整体框架是上中下三行，左右两列是各种图表卡片，中间一行是核心数据（总客流、总进站、总出站、实时客流），下面区域放地图或OD大图。

各卡片组件统一用一套结构：

vue复制<template>
  <div class="chart-card">
    <div class="card-title">{{ title }}</div>
    <div ref="chartRef" class="chart-container"></div>
  </div>
</template>

<script>
import * as echarts from 'echarts';

export default {
  name: 'BaseChartCard',
  props: {
    title: String,
    option: Object
  },
  data() {
    return {
      chart: null
    };
  },
  mounted() {
    this.chart = echarts.init(this.$refs.chartRef);
    this.chart.setOption(this.option);
  },
  watch: {
    option(newVal) {
      this.chart.setOption(newVal);
    }
  },
  beforeDestroy() {
    if (this.chart) {
      this.chart.dispose();
    }
  }
};
</script>

这里有一个Vue + ECharts的高频坑：mounted 里初始化图表时，容器可能还没有真正的宽度和高度，尤其是放在flex布局里时。解决方案是初始化前检查 this.$refs.chartRef.clientWidth，如果是0，就用 window.onresize 或 requestAnimationFrame 延迟初始化。我通常用一个定时器配合 clientWidth > 0 的判断来处理。

5.2 核心图表与对应数据接口

大屏上我用了六种图表：

折线图的数据组装是典型的前端数据处理场景。后端返回的数据是“站点-小时-进站量-出站量”，前端需要先聚合出全局小时趋势。我当时写了一个通用函数，按小时累加所有站点数据：

javascript复制function buildHourlyTrend(list) {
  const hours = Array.from({ length: 24 }, (_, i) => i + ':00');
  const inData = new Array(24).fill(0);
  const outData = new Array(24).fill(0);
  list.forEach(item => {
    inData[item.hour] += item.inCount;
    outData[item.hour] += item.outCount;
  });
  return {
    hours,
    inData,
    outData
  };
}

5.3 前端轮询优化与细节处理

大屏的数据更新我用了两种策略：

• 对日级数据（全天总量、线路占比），启动时请求一次，每隔5分钟刷新。
• 对小时级数据（24小时曲线、实时热度），每隔30秒轮询一次。

Axios封装好基本请求方法后，在组件里用 setInterval 定时获取数据，并更新ECharts的option。有一个很小的细节要提醒：ECharts的 setOption 默认是“合并模式”，如果新旧数据里少了一个系列，图表里还会残留旧系列的图。需要在更新时传入第二个参数 true，表示“不合并，直接替换”：

javascript复制this.chart.setOption(newOption, true);

这个坑我踩过一次，调试了很久才发现是旧数据没清掉。

6. 环境搭建、部署与踩坑实录

6.1 集群环境与版本搭配

如果你的目标是把整个项目从零跑通，环境搭建议如下：

• 操作系统：Ubuntu 18.04/20.04 或 CentOS 7（如果只是本地学习，也可以用Windows + WSL）。
• JDK版本：JDK 1.8（Hadoop 3.x和SpringBoot 2.x都支持，兼容性最好）。
• Hadoop版本：Hadoop 3.1.3或3.2.x，稳定且资料多。
• MySQL版本：MySQL 5.7或8.0。
• SpringBoot版本：2.5.x - 2.7.x，配合JDK1.8很稳。
• Vue版本：Vue 2.6.x + @vue/cli 4.x/5.x。
• Node版本：14.x或16.x。

版本搭配是最大的隐形坑。我见过很多人一上来装最新版Hadoop 3.3.x配JDK11，结果一连串兼容性问题。建议锁死版本，不要追求最新。

6.2 大数据组件安装与启动顺序

以Ubuntu为例，创建一个专门用户（比如用户名为hadoop），然后安装SSH免密登录，这是Hadoop伪分布式和集群部署的第一步。然后按顺序安装配置：

bash复制# 解压Hadoop到指定目录
tar -zxvf hadoop-3.1.3.tar.gz -C /usr/local/
cd /usr/local/hadoop-3.1.3

# 配置环境变量 /etc/profile
export HADOOP_HOME=/usr/local/hadoop-3.1.3
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

# 修改核心配置文件 core-site.xml

核心配置文件里，fs.defaultFS 设置为 hdfs://localhost:9000，hadoop.tmp.dir 指定一个真实存在的目录（不要用默认的 /tmp/hadoop-${user.name}，容易被系统清理）。

配置完成后，启动顺序是：先格式化NameNode：

bash复制hdfs namenode -format

然后启动：

bash复制start-dfs.sh

通过 jps 查看进程，看到NameNode、DataNode、SecondaryNameNode都在，就说明HDFS起来了。

6.3 高并发提交MapReduce任务的内存调优

在伪分布式模式下跑MapReduce，最容易遇到的就是内存不足导致任务被杀。Hadoop默认分配的YARN容器内存和本机实际内存可能不匹配。我遇到过两次 Container killed by the ApplicationMaster，最后靠调整以下参数解决：

在 yarn-site.xml 里配置：

xml复制<property>
  <name>yarn.nodemanager.resource.memory-mb</name>
  <value>8192</value>
</property>
<property>
  <name>yarn.scheduler.maximum-allocation-mb</name>
  <value>4096</value>
</property>
<property>
  <name>yarn.scheduler.minimum-allocation-mb</name>
  <value>512</value>
</property>

在 mapred-site.xml 里配置：

xml复制<property>
  <name>mapreduce.map.memory.mb</name>
  <value>1024</value>
</property>
<property>
  <name>mapreduce.reduce.memory.mb</name>
  <value>2048</value>
</property>
<property>
  <name>mapreduce.map.java.opts</name>
  <value>-Xmx819m</value>
</property>
<property>
  <name>mapreduce.reduce.java.opts</name>
  <value>-Xmx1638m</value>
</property>

如果本机内存只有8G，建议YARN容器总量不要超过6G，否则整个机器会卡死。

6.4 SpringBoot + Vue打包部署到服务器

后端打包：

bash复制mvn clean package -DskipTests
java -jar metro-server.jar --spring.profiles.active=prod

前端构建：

bash复制npm run build

构建产物在 dist 目录下，用Nginx托管：

nginx复制server {
    listen 80;
    server_name your_server_ip;
    root /usr/share/nginx/html/dist;
    index index.html;

    location /api/ {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Nginx的 /api/ 反向代理要特别注意 proxy_pass 后面是否带斜杠，带斜杠和不带斜杠的效果不一样。我写的是 http://localhost:8080;（不带路径），这样会保留原始的 /api 前缀。如果写成 http://localhost:8080/;，就会被替换掉，和前端接口路径对不上。

7. 高频报错与排查技巧实录

7.1 MapReduce任务卡在Running状态且进度不变

这个我遇到的情况是：Map任务进度一直是0%，但Reduce任务进度显示100%。后来发现是输入文件太大、Map任务数量太多，集群同一时间只调度了少量任务，其他任务在排队。解决办法是看看 yarn-site.xml 里是否限制了调度器线程数，或者干脆加大 yarn.nodemanager.resource.memory-mb，让单个节点能同时跑更多容器。

另一个可能原因：输入路径下的文件数量太多且每个文件很小，Map任务被拆成几百个，但集群资源不够，导致长时间排队。这时候优化文件合并即可。

7.2 Reduce阶段一直拉取数据，最后报OOM

报错信息类似 java.lang.OutOfMemoryError: Java heap space。排查思路是优先检查是否需要使用Combiner，或者是否存在某个Key的数据量特别大（数据倾斜）。对于数据倾斜，我用的方案是加盐，把同一个Key打散成多个子Key，最后再汇总一次。比如OD分析里某个热门站点对的数据特别多，就在Key后面拼接一个随机数再分桶，Reduce后再做一次普通聚合。

7.3 SpringBoot接口返回中文乱码

中文乱码的根源往往是HDFS上的数据文件编码和读取时的解码不一致。Hadoop默认读取文件是按UTF-8，但模拟生成数据时如果用Windows记事本保存成了GBK，就会出现乱码。解决办法是模拟生成器统一指定UTF-8编码，导出结果时也统一用UTF-8。如果文件已经在HDFS上了，可以在导入工具里手动指定编码转换。

7.4 ECharts图表在Vue大屏中显示空白

多数原因是图表容器高度为0。ECharts需要一个有明确宽高的容器才能渲染。大屏页面里卡片容器如果高度没设置，图表就会空白。解决方法是给卡片容器设置固定高度，比如 height: 320px，或者在初始化前用 window.getComputedStyle 检查宽高。

7.5 前后端联调时跨域问题

本地开发时，Vue运行在8081端口，SpringBoot在8080端口，必须解决跨域。我在后端加了全局CORS配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*");
    }
}

注意 allowedOrigins("*") 上线前要收紧，改成自己的域名，否则有安全风险。

8. 高阶优化建议：从“能跑”到“跑得好”

8.1 数据压缩与文件格式优化

MapReduce默认输出是文本文件，后续导入MySQL时解析文本没问题，但如果数据量增加到几亿条，文本文件的IO开销会很显著。可以考虑把输出格式改成SequenceFile或Parquet，或者开启压缩。

在Hadoop的 mapred-site.xml 里配置：

xml复制<property>
  <name>mapreduce.map.output.compress</name>
  <value>true</value>
</property>
<property>
  <name>mapreduce.map.output.compress.codec</name>
  <value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>

Snappy压缩算法速度快、压缩率不低，适合MapReduce中间的shuffle数据。如果想进一步优化，可以把摄入数据格式从CSV换成Parquet，配合Hive做SQL查询，效率会高很多，算是把项目升级成“工业级”方向。

8.2 引入定时调度与自动化

开发或演示阶段，MapReduce任务都是手动提交的。但真实场景中，每天凌晨都要对前一天的数据做离线计算，靠人肉提交肯定不行。后期可以引入Oozie或Apache DolphinScheduler做定时调度，让整套系统每天自动完成“数据生成->上传HDFS->MapReduce计算->导出MySQL->更新缓存”的流程。

如果只是本地用，也可以用Crontab定时执行脚本：

bash复制# 每天凌晨1点执行计算任务
0 1 * * * /home/hadoop/metro-scheduler/daily_run.sh

脚本内容大致是：调用数据生成器 → hdfs dfs -put → 依次执行4个MapReduce任务的Jar包 → 调用SpringBoot的数据导入接口。

8.3 前后端分离部署与容器化

进阶玩法是把整个项目容器化，写Docker Compose编排文件，把MySQL、Hadoop、SpringBoot、Nginx分别做成容器。这样别人拿到你的项目源码后，一条 docker-compose up 就能拉起整套环境。我当时就是因为部署环境太复杂，特意写了一套Docker方案，对于交作业或演示的场景极其好用。

回顾这个从零到一构建地铁大数据分析系统的过程，我最大的收获其实是“把每一层的职责边界划清楚”——数据生成归数据生成，计算归计算，存储归存储，展示归展示。每一层都只做自己的事，通过标准化的数据格式对接，整个系统才能稳定跑起来。如果你正准备复现或扩展这个项目，建议先按“单机伪分布式”把链路跑通，再加数据量、加调度、加容器化，逐步升级。中途遇到问题不要急着换框架，先回到数据流上的每一步检查，大多数Bug其实都出在数据格式和版本兼容上。