企业官网建设流程全解析

一个奶茶品牌的门店数量超过二十家之后，每天的订单数据就会从几千条涨到几万条，一个月下来就是上百万条的流水。这种量级的数据，靠数据库单表聚合已经不太舒服了。我做这个奶茶销售数据分析平台，就是把订单流水先落到 HDFS 上，用 MapReduce 按品类、门店、时段、支付方式这些维度做离线聚合，再通过 Spring Boot 提供查询接口，最后在 Vue 大屏上把销售报表、排行榜、趋势曲线展示出来。整套链路覆盖了 Hadoop 生态里最典型的批处理场景，适合想实战 MapReduce 的开发者，也适合正在准备大数据方向项目或课程设计的同学参考，更关键的是它的模块边界非常清晰，拿到源码之后可以按自己的需求替换业务逻辑。

1. 项目定位与技术选型解析

1.1 核心需求拆解

奶茶销售数据分析，拆开看其实是三个问题：第一，数据从哪来；第二，数据怎么算；第三，结果怎么展示。数据源是门店每天产生的订单流水，字段一般包括订单号、门店编号、奶茶品类、单价、数量、下单时间、支付方式这些基础信息。计算层要回答的就是“今天卖了多少、哪款卖得好、哪家店更赚钱、什么时段单量最多、用户喜欢用微信还是支付宝”，这几个问题分别对应总销售额、品类销售榜、门店对比、时段趋势、支付方式占比这几类统计指标。

原始订单数据本身是明细流水，一天几万行，一个月几十万到上百万行。如果直接在 MySQL 里反复做 GROUP BY 和 SUM，字段少、数据量在一两百万行时勉强能撑住，但一旦表数据过千万，或者要按十几个维度同时统计，SQL 的聚合效率就会明显下降。这个项目把“明细数据存储”和“预计算聚合”分开，明细放 Hadoop，聚合结果回落到 MySQL，前端只查结果表，这是整套设计最核心的思路。

1.2 技术栈选择的背后逻辑

技术选型上，有人会问：现在 Spark 那么火，为什么还用 MapReduce？我的答案很直接——这个场景是典型的离线批量统计，数据量在百万级别，MapReduce 完全够用，而且它的运行模型足够简单，把 Mapper 和 Reducer 两个阶段的逻辑搞清楚，整个项目的主干就通了。用 Spark 当然也可以，但如果你是从零学习 Hadoop 生态，MapReduce 是绕不开的基础，把这个吃透后再去看 Spark 的 RDD 算子会顺畅很多。

Spring Boot 负责把计算好的结果数据暴露成 REST API。后端不需要做复杂计算，只是把 MySQL 里的统计结果查出来，按前端需要的格式返回。选 Spring Boot 是因为它对 MyBatis、Redis、定时任务这些组件接入成本低，本地起一个服务调试也快。Vue 这边配合 ECharts，做数据可视化大屏的成本极低，社区里图表案例多，直接抄作业都能搭出不错的效果。三层结构梳理下来，源码的工程目录也清晰：mapreduce 模块写统计作业，backend 模块写接口，frontend 模块做页面展示。

2. MapReduce 核心业务逻辑设计与实现

2.1 数据模型与 HDFS 存储设计

在写 Mapper 之前，先把输入数据的结构定好。我用的是一份 CSV 格式的模拟订单流水，字段顺序约定为：

order_id, store_id, category, price, quantity, order_time, pay_type 1001, 店001, 珍珠奶茶, 15.0, 2, 2025-06-01 08:12:33, 微信

这里故意把品类名称直接放在明细里，省去了关联字典表的步骤。真实业务里品类可能会有单独的维度表，但在这个项目里，维度表的引入会让 MapReduce 的 join 逻辑变复杂，初学阶段没必要。order_time 统一存成“年-月-日 时:分:秒”的字符串，日期和小时可以在 Mapper 里直接截取，不用额外解析成 Date 对象。

数据准备好后，上传到 HDFS 指定目录：

hdfs dfs -mkdir -p /data/orders hdfs dfs -put orders.csv /data/orders/

这里注意一点，HDFS 上放的是明细数据，不是结果数据。明细数据的特点是量大、不需要修改，非常适合放在分布式文件系统上。MapReduce 作业的输入目录和输出目录建议分开管理，输出目录每次跑之前先删除旧的，避免目录已存在导致的作业失败。

2.2 Mapper 阶段：数据清洗与维度拆分

Mapper 阶段做的三件事：解析字段、过滤脏数据、输出中间键值对。以“按奶茶品类统计销售额、订单量、销量”这个作业为例，输入 key 是行偏移量，value 是整行文本。解析后把品类名作为输出的 key，把金额、数量、订单数封装成一个自定义 Writable 对象作为 value。

public class SalesMapper extends Mapper<LongWritable, Text, Text, SalesWritable> { private Text outKey = new Text(); private SalesWritable outValue = new SalesWritable(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { // 跳过CSV表头 if (key.get() == 0L) { return; } String line = value.toString(); String[] fields = line.split(","); // 约定字段：order_id, store_id, category, price, quantity, order_time, pay_type if (fields.length < 7) { context.getCounter("OrderStats", "INVALID_FIELDS").increment(1); return; } String category = fields[2].trim(); double price; int quantity; try { price = Double.parseDouble(fields[3].trim()); quantity = Integer.parseInt(fields[4].trim()); } catch (NumberFormatException e) { context.getCounter("OrderStats", "INVALID_NUMBER").increment(1); return; } // 脏数据过滤：价格或数量不能为负数 if (price <= 0 || quantity <= 0) { context.getCounter("OrderStats", "NEGATIVE_VALUE").increment(1); return; } double amount = price * quantity; outKey.set(category); outValue.set(amount, quantity, 1L); context.write(outKey, outValue); } }

这里有两个容易被忽视的细节。第一个是表头跳过逻辑——如果 CSV 有表头，第一行解析出来的字段类型会转成数字报错，虽然异常被捕获了，但还是会白白算一条无效记录，最好在逻辑上直接跳过。第二个是脏数据记录——用 Hadoop Counter 统计无效数据量，在作业跑完后从控制台或者 YARN 日志里能看到，这是一张免费的“数据质量体检报告”。

2.3 Reducer 阶段：聚合统计与指标计算

Mapper 输出的是同一个品类对应的多个“金额 + 数量 + 订单数”的 Writable 对象，Reducer 要做的是把这些对象累加起来，算出该品类的总销售额、总销量、总订单数、客单价。

public class SalesReducer extends Reducer<Text, SalesWritable, Text, Text> { @Override protected void reduce(Text key, Iterable<SalesWritable> values, Context context) throws IOException, InterruptedException { double totalAmount = 0.0; int totalQuantity = 0; long totalOrders = 0L; for (SalesWritable value : values) { totalAmount += value.getAmount(); totalQuantity += value.getQuantity(); totalOrders += value.getOrderCount(); } double avgAmount = totalOrders == 0 ? 0.0 : totalAmount / totalOrders; String result = String.format("%.2f,%d,%d,%.2f", totalAmount, totalQuantity, totalOrders, avgAmount); context.write(key, new Text(result)); } }

自定义 Writable 的目的是减少序列化开销。Java 自带的对象序列化会把整个对象图一起序列化，而 Hadoop 的 Writable 接口只按你定义的方向写具体字段，序列化结果更紧凑，网络传输时更省带宽。定义方式如下：

public class SalesWritable implements Writable { private double amount; private int quantity; private long orderCount; // 必须提供无参构造，Hadoop反序列化时会调用 public SalesWritable() { } public SalesWritable(double amount, int quantity, long orderCount) { this.amount = amount; this.quantity = quantity; this.orderCount = orderCount; } @Override public void write(DataOutput out) throws IOException { out.writeDouble(amount); out.writeInt(quantity); out.writeLong(orderCount); } @Override public void readFields(DataInput in) throws IOException { this.amount = in.readDouble(); this.quantity = in.readInt(); this.orderCount = in.readLong(); } // getter... }

主类里还需要显式设置 Mapper、Reducer 以及输出类型。这里有个容易踩的坑：如果 Mapper 输出的 value 类型和 Reducer 输出的 value 类型不一致，必须分别设置 map output 类型和 job output 类型，否则作业会在运行时报类型转换错误。

public class SalesAnalysisJob { public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "sales-category-analysis"); job.setJarByClass(SalesAnalysisJob.class); job.setMapperClass(SalesMapper.class); job.setReducerClass(SalesReducer.class); job.setMapOutputKeyClass(Text.class); job.setMapOutputValueClass(SalesWritable.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(Text.class); // 结果只有几十行，设置3个Reducer便于观察分区效果 job.setNumReduceTasks(3); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }

2.4 多个统计维度的工程化组织方式

一个品类统计只能算完成一项指标，完整的平台还需要“按门店统计”“按小时统计”“按支付方式统计”。这些作业的 Mapper / Reducer 逻辑高度相似，只是“分组维度”和“输出结果字段”不同，没必要复制出多份重复代码。

我的做法是把公共逻辑抽成一个基类或者静态工具方法。比如用一个枚举来标识不同维度：

public enum DimType { CATEGORY, STORE, HOUR, PAY_TYPE }

Mapper 里根据 dimType 决定从哪一列取分组 key，Reducer 输出结果时在结果前面拼上维度名称。这样一套代码可以通过参数跑出四个统计维度。如果觉得枚举方式偏复杂，也可以直接复制四个作业类，日常练习项目里直观比抽象更重要，这一点可以根据自己的代码风格来定。

2.5 Combiner 的合理使用场景

Combiner 是在 Mapper 输出之后、网络传输之前做一次本地预聚合。在品类统计这个场景里，同一台机器上同一个品类可能出现了很多次，如果不加 Combiner，这些记录会原样传到 Reducer。加了 Combiner 之后，本地先把同品类的金额、数量、订单数求个和，传输量就能降到原来的一半甚至更低。

但要注意，Combiner 不能乱用。在这个作业里，计算的是求和、计数，Combiner 用 Reducer 的逻辑完全没问题。如果换成计算平均值的场景，比如统计“各品类的平均售价”，Combiner 就不能直接用 Reducer 的逻辑，原因是多个本地平均值再求平均不等于全局平均值。遇到这种场景，要么不用 Combiner，要么在 Writable 里同时携带总和与条数，Reducer 再根据这两个值算最终平均。

3. Spring Boot 数据服务层搭建

3.1 计算结果回灌 MySQL 的方案对比

MapReduce 作业跑完后，结果以 part-r-xxxxx 文件的形式存放在 HDFS 上。这些文件可以看作“中间结果”，前端接口不能直接读 HDFS，原因有两点：一是 HDFS 读数据的延迟比 MySQL 高很多；二是在线查询要支持排序、分页、多条件筛选，用文件系统实现这些功能非常别扭。所以需要一个环节把结果从 HDFS 搬到 MySQL。

方案一：在 MapReduce 作业里直接写 MySQL。Hadoop 提供了 DBOutputFormat，可以把 Reducer 的输出直接写入数据库表。这个方案看起来省事，但存在一个实际问题——数据库连接是在每个 Reducer task 里建立的，如果 Reduce task 数量多，会对数据库造成比较大的压力，而且最近版本的 Hadoop 对 DBOutputFormat 的支持也谈不上多好，学习成本反而高。

方案二：先把结果文件导出到本地，再用脚本或工具批量导入 MySQL。推荐这个方式，操作透明，出了问题也好排查。命令如下：

hdfs dfs -cat /result/category/part-r-* > /data/sync/category_stats.csv

这样拿到一个 CSV 文件，再用 JDBC 写一个批量导入方法，或者用 MySQL 的 LOAD DATA 命令快速导入。CSV 文件一般只有几十行到几百行，导入耗时可忽略不计。

3.2 分析结果表结构设计

结果表的结构要能同时支持报表展示和维度筛选。以品类统计表为例：

CREATE TABLE category_stats ( id INT AUTO_INCREMENT PRIMARY KEY, category VARCHAR(50) NOT NULL, total_amount DECIMAL(12,2) NOT NULL, total_quantity INT NOT NULL, total_orders INT NOT NULL, avg_order_amount DECIMAL(10,2) NOT NULL, stat_date DATE NOT NULL, UNIQUE KEY uk_category_date (category, stat_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

stat_date 字段用来区分不同统计周期的数据，本期跑的数据和上期跑的数据可以共存，方便做环比对比。其他人日常排查看这张表的经验是：唯一索引尽量加上，这样重复导入数据时可以用 ON DUPLICATE KEY UPDATE 做幂等，避免跑了两遍定时任务后数据翻倍。

表字段按照“维度字段 + 指标字段 + 日期字段”的模式来设计，后续新增统计指标，只需要加列，改起来成本很低。

3.3 后端接口设计与代码组织

后端整体分层为 Controller、Service、Mapper。Controller 只做参数接收和结果包装，不写业务逻辑；Service 层处理缓存、排序、异常等；Mapper 层用 MyBatis 做 SQL 映射。

@RestController @RequestMapping("/api/dashboard") public class DashboardController { @Autowired private CategoryStatsService categoryStatsService; @GetMapping("/category/top") public Result<List<CategoryStatsVO>> categoryTop( @RequestParam(defaultValue = "10") Integer limit) { return Result.success(categoryStatsService.getTop(limit)); } }

接口统一返回 Result 对象，结构包含 code、message、data 三个字段，前端判断 code 是否为 200 再取 data。接口路径按资源命名，/api/dashboard/overview 返回汇总卡片数据，/api/dashboard/category/top 返回品类排行榜，/api/dashboard/store/compare 返回门店对比，/api/dashboard/hourly/trend 返回时段趋势，/api/dashboard/payment/ratio 返回支付占比。

统计结果表的数据量不大，最多几百行，查询本来就不慢。但为了给后续增加数据量留出余地，Service 层加了简单的本地缓存，缓存有效期设成 60 秒，配合前端大屏 30 秒轮询的节奏，既能看到数据变化，又不会频繁打到数据库。

@Service public class CategoryStatsServiceImpl implements CategoryStatsService { @Autowired private CategoryStatsMapper categoryStatsMapper; private final Cache<String, List<CategoryStatsVO>> localCache = Caffeine.newBuilder().expireAfterWrite(60, TimeUnit.SECONDS).build(); @Override public List<CategoryStatsVO> getTop(int limit) { try { return localCache.get("top_" + limit, key -> categoryStatsMapper.selectCategoryTop(limit)); } catch (Exception e) { // 缓存加载失败时直接查库，避免缓存异常影响主流程 return categoryStatsMapper.selectCategoryTop(limit); } } }

我在实际写这个模块时，把 MyBatis 的 SQL 都写得非常“死”——比如查询 Top10 就直接写 ORDER BY total_amount DESC LIMIT 10，而不是搞一套动态查询条件。统计报表页面的查询模式是固定的，动态化带来的灵活性在增删改查系统里才有价值，在报表场景里反而增加维护成本。

4. Vue 前端可视化展示实现

4.1 前端工程结构与依赖项

前端使用 Vue 3 + Vite + Element Plus + ECharts。Vite 的启动速度比 Webpack 快很多，开发调试体验好。工程目录按页面和组件拆分：

frontend/ ├── src/ │ ├── api/ │ │ ├── request.js │ │ └── dashboard.js │ ├── components/ │ │ ├── StatCard.vue │ │ ├── CategoryBarChart.vue │ │ ├── StoreBarChart.vue │ │ ├── HourlyLineChart.vue │ │ └── PaymentPieChart.vue │ ├── views/ │ │ ├── Dashboard.vue │ │ └── DataBoard.vue │ ├── router/ │ │ └── index.js │ ├── App.vue │ └── main.js

dashboard.js 里按接口封装请求函数，每个函数返回一个 Promise，组件里通过 async/await 拿到数据交给 ECharts 渲染。

4.2 大屏布局思路

大屏设计不是简单的图表堆叠，而是围绕“核心指标 + 趋势变化 + 排名对比”的阅读顺序来布局。我的默认方案是：

• 顶部通栏：系统标题 + 当前日期 + 核心数据（总销售额、总订单数）
• 左侧区域：门店销售对比柱状图、支付方式占比饼图
• 中间区域：核心指标卡片 + 销售趋势折线图
• 右侧区域：品类销售 Top10 柱状图、时段订单量折线图

中间核心指标卡片的数据来自 /api/dashboard/overview，其他图表的数据来自对应的子接口。整体页面用 CSS Grid 划分成两行三列，栅格比例左侧 20%，中间 60%，右侧 20%，页面宽度固定为 1920px，通过 transform: scale() 做整体缩放，保证在小屏电脑上也能全屏展示。

4.3 图表组件对接与数据刷新

品类销售 Top10 柱状图是最典型的一个例子。组件挂载后先请求数据，再用 ECharts 的 setOption 渲染：

import * as echarts from 'echarts'; import { getCategoryTop } from '../api/dashboard'; import { onMounted, onUnmounted, ref } from 'vue'; export default { name: 'CategoryBarChart', setup() { const chartRef = ref(null); let chart = null; async function loadData() { const { data } = await getCategoryTop(); if (!chart) { chart = echarts.init(chartRef.value); } chart.setOption({ tooltip: { trigger: 'axis' }, xAxis: { data: data.map(item => item.category), axisLabel: { color: '#ccc' } }, yAxis: { type: 'value', axisLabel: { color: '#ccc' } }, grid: { left: 50, right: 30, top: 30 }, series: [{ type: 'bar', data: data.map(item => item.totalAmount), itemStyle: { gradient: '#3ec1d3' }, barWidth: 18 }] }); } onMounted(() => { loadData(); window.addEventListener('resize', handleResize); }); function handleResize() { chart && chart.resize(); } const timer = setInterval(loadData, 30000); onUnmounted(() => { window.removeEventListener('resize', handleResize); clearInterval(timer); chart && chart.dispose(); }); return { chartRef, loadData }; }, template: `<div ref="chartRef" style="width:100%;height:300px;"></div>` };

数据刷新我这里叫“实时刷新”，用的其实是 30 秒轮询。为什么不用 WebSocket？因为后端数据本身是 T+1 的离线统计结果，基本不会在秒级变化，30 秒轮询的成本低、实现简单、也不会给后端造成压力。如果整个平台后续接入了实时流计算，再考虑替换成 WebSocket 推送也不迟。路由配置用 createWebHashHistory，避免部署到静态服务器时刷新页面出现 404。

5. 环境搭建与源码部署

5.1 环境版本与匹配关系

先列一张版本匹配表，这是整个项目里最容易被忽略的部分。很多同学在环境上反复折腾，多数是因为版本不一致：

如果你本机同时装了其他版本的 JDK，建议单独设置 Hadoop 和 Spring Boot 的 JAVA_HOME，不要共用一个环境变量。我在跑项目时遇到过 Hadoop 在 JDK 11 下报模块访问警告的情况，虽然不影响整体运行，但额外输出会掩盖真正的报错信息，排查问题时很干扰。

5.2 Hadoop 关键配置与启动

伪分布式模式下需要改动三个配置文件。

core-site.xml：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/home/hadoop/data/tmp</value> </property> </configuration>

hdfs-site.xml：

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/home/hadoop/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/home/hadoop/data/datanode</value> </property> </configuration>

mapred-site.xml：

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>mapreduce.map.memory.mb</name> <value>1024</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>1024</value> </property> </configuration>

dfs.replication 设成 1 是因为本地单节点跑多副本没有任何意义，纯增写磁盘空间。mapreduce.map.memory.mb 和 reduce.memory.mb 设成 1024 是考虑开发机内存一般只有 8G 或 16G，YARN 如果给每个任务分配太多物理内存，多个任务并发跑时会直接触发 OOM，即便是伪分布式模式，这种行为也很常见。

启动命令：

start-dfs.sh start-yarn.sh

启动后可以用 jps 看 NameNode、DataNode、ResourceManager、NodeManager 这四个进程是否都在。少任何一个都说明某一步没起来，优先去对应日志目录里看报错信息。

5.3 全链路操作步骤与验证顺序

整个平台从零跑通的步骤，按顺序整理如下：

1. 生成模拟订单数据（用 Python 脚本生成 orders.csv）
2. 上传原始数据到 HDFS：hdfs dfs -mkdir -p /data/orders && hdfs dfs -put orders.csv /data/orders/
3. 提交 MapReduce 作业：hadoop jar sales-analysis.jar 入口类 /data/orders /result/category
4. 查看输出文件：hdfs dfs -cat /result/category/part-r-*，确认结果无异常
5. 导出结果到本地 CSV，再导入 MySQL 结果表
6. 启动 Spring Boot：mvn spring-boot:run，测试 /api/dashboard/overview
7. 启动前端：npm run dev，用浏览器打开本地地址查看大屏

流程跑通之后，建议把第 3 到第 5 步封装成一个 shell 脚本，每次更新数据后一键执行，避免手动敲命令太多次。

5.4 模拟订单数据生成脚本

写一个简单的 Python 脚本，生成 2 万行订单，门店、品类、金额、时间都在合理范围里随机：

import csv import random import datetime stores = ['店001', '店002', '店003', '店004', '店005', '店006'] categories = ['珍珠奶茶', '波霸奶茶', '芋圆奶茶', '抹茶奶盖', '杨枝甘露', '柠檬茶'] pay_types = ['微信', '支付宝', '现金'] start_date = datetime.datetime(2025, 6, 1) end_date = datetime.datetime(2025, 6, 8) time_span = end_date - start_date with open('/data/orders.csv', 'w', newline='', encoding='utf-8') as f: writer = csv.writer(f) writer.writerow(['order_id', 'store_id', 'category', 'price', 'quantity', 'order_time', 'pay_type']) for i in range(1, 20001): store_id = random.choice(stores) category = random.choice(categories) price = round(random.uniform(10.0, 32.0), 1) quantity = random.randint(1, 3) order_time = start_date + random.random() * time_span pay_type = random.choice(pay_types) writer.writerow([ i, store_id, category, price, quantity, order_time.strftime('%Y-%m-%d %H:%M:%S'), pay_type ])

这里下单时间的生成逻辑是“在 6 月 1 日到 6 月 8 日之间随机取一个时间点”，符合真实场景里订单的随机分布。如果你后续想做“工作日 vs 周末”的对比分析，可以把 start_date 和 end_date 拉长到半个月以上，生成更多天数数据，在 Mapper 里根据 weekday 做分组判断。

6. 实操避坑与问题排查实录

6.1 高频问题速查表

以下是我在这个项目里真实踩过的问题，整理成了速查表：

最后这个时区问题非常典型。MySQL 8.x 驱动对时区要求很严格，不配置时区会直接报错，出现类似 The server time zone value 的错误，处理方法就是在 JDBC URL 后面显式加上时区参数。

6.2 数据倾斜的处理思路

虽然这个项目的最终结果数据量不大，但 MapReduce 作业在中间计算阶段同样会遇到数据倾斜的可能。比如“珍珠奶茶”是爆款，品类的数据行数可能是其他品类的三到四倍，Reducer 收到的数据就会不均衡，导致某个 Reducer 要跑很久，其他 Reducer 已经结束在空等。

处理数据倾斜的常用方法有两种。第一种是“加盐”，在 Mapper 输出的 key 前面拼接一个随机数，把同一个品类的数据随机打散到多个 Reducer，第一轮作业只做部分聚合，再把结果按真实 key 做第二轮聚合；这种方法适合数据量大且 key 种类少的场景。第二种是“两阶段聚合”，先在 Map 端做 Combine，再在 Reduce 端合并；但注意先确认你的聚合算子是否能在本地做预聚合。在我的项目里，因为最终统计结果就几十行，数据倾斜对作业整体耗时影响很小，所以没有在实际代码里加入这些优化，但在日志里看到过某个品类的 Counter 记录明显偏多，这个现象本身值得记录下来。

6.3 日志排查的三个习惯

跑 Hadoop 作业最怕的就是只看报错里的前几行，后面真正的堆栈信息被刷过去了。我的经验是养成三个习惯：第一，在代码里加 Counter 统计无效数据，跑完作业先看 Counter 变化；第二，遇到失败任务优先去 YARN 的日志页面看对应 task 的 stderr 输出，而不是在提交作业的终端里猛翻；第三，把每个 MR 作业的输出目录独立命名，避免多个作业写同一个路径导致结果互相覆盖。

6.4 项目后续可以怎么扩展

这个平台的骨架搭好后，扩展方向其实很自然。第一，离线统计升级为定时调度，用 Crontab 或者调度平台每天凌晨自动跑前一天的统计任务，业务方每天早上一进办公室就能看到昨天的销售分析；第二，从 T+1 升级到实时，把 MapReduce 替换成 Flink、Spark Streaming，实现分钟级刷新；第三，增加更多统计维度，比如会员复购率、门店坪效、品类关联购买分析；第四，给后端加一套简单的权限控制，不同的角色只能看到自己权限范围内的数据。

我个人在实际操作中的体会是，这个项目最值得学习的不在于某一段代码有多高级，而在于把“离线计算、结果存储、接口服务、数据可视化”这条链路完整打通的过程。很多人单独学过 Hadoop、单独写过接口、单独画过报表，但把它们串联成一个面向业务的系统，需要想清楚每一层之间的数据契约是什么。先把结果表结构定义好，再回推 Mapper 和 Reducer 的输出格式，最后定前端接口，整条链路就非常顺滑。最后再分享一个小技巧——遇到各种奇怪的乱码、时区、权限问题，不要先怀疑框架，先把配置项逐行对照一遍，大多数问题都在配置文件里。