Hadoop+Spark+Hive+Django农作物产量趋势分析链路

农作物产量趋势可视化分析是数据类专业毕业设计里出现频率很高的一类题目，但真正把它做成一条能跑通的链路，并不是把一份 CSV 丢进数据库、再用框架画个折线图那么简单。真正决定这个项目能不能演示、能不能答辩、能不能在答辩后继续维护的，是数据从原始文件到页面图表之间那几层转换是否清晰：原始数据存在哪里、清洗规则写在哪里、指标口径由谁定义、后端只负责取数还是也负责计算、图表接口怎么保证响应速度。这条链路一旦层次混乱，后面每加一个图表都要改一遍后端逻辑，数据量一大就彻底跑不动。

这篇文章面向正在做大数据方向毕业设计、或者需要快速搭一个离线统计分析原型的开发者，把 Hadoop、Spark、Hive 与 Django 拼成一条职责明确的分析链路：HDFS 存原始文件，Hive 做分层建模和 SQL 口径沉淀，Spark 负责跨年趋势和同比这类需要窗口计算的重活，Django 只做结果查询和 API 输出，前端用图表库消费接口。读完之后，你应该能从零跑通一个可复现的农作物产量趋势分析小系统，知道每一步该验证什么，遇到读不到数据、字段全是 NULL、Spark 写库报驱动缺失、接口返回空数组时该从哪一层开始查。

1. 先把链路职责划清：HDFS 存文件、Hive 定口径、Spark 算趋势、Django 出接口

很多毕业设计项目失败，不是因为某个组件不会用，而是因为一开始就没想清楚"谁该做什么"。常见写法是 Django 直接读取一个 Excel，用 pandas 算完再塞进模板渲染，前期确实跑得通，但只要数据量涨到几十万行、指标增加到同比环比、还要支持按省份和作物下钻，这种方式就会暴露出两个问题：计算逻辑和 Web 请求生命周期绑死，一次页面刷新触发一次全量计算；口径散落在视图函数里，换个图表对不上数。把职责拆开，是让这个项目从"能看"变成"能讲清楚"的第一步。

1.1 为什么不让 Django 直接读原始数据做统计

Django 的强项是路由、ORM、鉴权、模板和接口序列化，它的进程模型是同步请求-响应，一个请求占一个 worker。如果在视图里做全表扫描加分组聚合，请求耗时随数据量线性增长，前端会一直转圈，用户连续点几个筛选条件就可能把 worker 打满。更麻烦的是，趋势类指标需要跨年份对比，SQL 里要写窗口函数，而多数项目用的 MySQL 版本对窗口函数支持有限，硬写自连接会让语句难以维护。

把统计下沉到离线层之后，Web 层只做一件事：按查询条件从结果表里取几十到几百行已经算好的数据。这样接口响应时间基本稳定在毫秒级，页面交互也会顺畅得多。这个拆分还有一个隐性好处：离线任务的运行日志和 Web 请求日志是分开的，出问题时能立刻判断是"数据没算出来"还是"接口没查对"，排错范围直接减半。

1.2 四个组件各自解决什么问题

把每个组件的定位写清楚，后面写代码时就不会来回摇摆。下面这张表是我在实际项目里常用的职责划分，可以直接作为模块设计的依据。

这里要强调 Hive 和 Spark 的分工。Hive 适合表达"数据长什么样、口径是什么"，比如单产等于产量除以播种面积、只统计播种面积大于零的记录；Spark 适合表达"怎么高效算出来"，比如按省份和作物分组后取上一年的值做同比。两者叠加，既能让人读懂口径，又能保证计算效率。

1.3 一条完整的数据流应该长什么样

把数据流画成文字版的链路，便于对照检查每一层是否落地：

text复制原始 CSV
  -> 上传 HDFS /data/crop/ods/crop_yield/dt=YYYY/
  -> Hive 外部表 ods_crop_yield（TextFile，映射 HDFS 目录）
  -> Hive 明细表 dwd_crop_yield（Parquet，按 stat_year 分区，做类型转换与去重）
  -> Spark 读取 dwd，计算单产、同比、区域排名
  -> 结果写入 MySQL 的 t_crop_yearly_trend / t_crop_region_top
  -> Django 读取 MySQL，输出 JSON
  -> 前端图表渲染

这条链路的关键在于"每一层都有可独立验证的产物"。ODS 层验证的是"文件有没有被 Hive 正确读到"，DWD 层验证的是"字段类型和空值处理对不对"，DWS 层验证的是"指标数值是否符合业务预期"，结果表验证的是"MySQL 里的行数和抽样值是否合理"。任何一层跳过验证，后面出问题都只能靠猜。

注意：不要等整条链路全写完再一起调试。每完成一层就先跑一条 SELECT * LIMIT 10 或 df.show(10)，确认数据形态正确再往下走，这是节省时间最多的习惯。

2. 环境准备：先在单机模式跑通，再考虑分布式部署

毕业设计最常见的环境问题是"版本互相不认"。Hadoop、Hive、Spark 三者对 JDK 和 Scala 版本都有要求，Django 侧又依赖 Python 版本和数据库驱动。比较稳妥的策略是：先在一台机器上用伪分布式或本地模式把整条链路跑通，确认数据能走完全程，再去考虑多节点部署。因为对这类数据量在百万行以内的分析场景，单机伪分布式的性能完全够用，答辩演示也不会因为集群启不来而卡住。

2.1 版本组合与依赖对齐

下面的组合是常见可用的方向，具体小版本号要以你实际下载的发行包为准，落地前先确认各组件的兼容说明，不要直接把网上看到的版本号抄进配置文件。

版本对齐之后，先做一次"能否互相看见"的自检，比直接写业务代码更有效。

bash复制java -version
hadoop version
hive --version
spark-submit --version
python -c "import django, pymysql; print(django.get_version())"

四条命令都能正常输出版本号，说明基础环境没问题。如果 spark-submit --version 报 Java 相关错误，优先检查 JAVA_HOME 是否指向了正确的 JDK，而不是去改 Spark 配置。

2.2 目录结构与配置外置

项目目录建议按"离线任务"和"Web 服务"两个子工程分开，避免 Python 依赖互相污染。下面是一个可以直接照搬的结构，包名和路径按自己的项目调整。

text复制crop-analysis/
├── offline/                      # 离线计算部分
│   ├── conf/
│   │   └── app.properties        # 数据库连接、路径等配置
│   ├── sql/
│   │   ├── 01_ods.sql
│   │   ├── 02_dwd.sql
│   │   └── 03_dws.sql
│   ├── jobs/
│   │   └── crop_trend_job.py     # Spark 任务入口
│   └── data/
│       └── crop_yield_sample.csv
├── web/                          # Django 服务部分
│   ├── manage.py
│   ├── config/
│   │   ├── settings.py
│   │   └── urls.py
│   └── report/
│       ├── models.py
│       ├── views.py
│       └── urls.py
└── requirements.txt

配置外置这件事在小项目里常被忽略，但它直接影响可复现性。数据库地址、用户名、密码、HDFS 路径这些内容写死在代码里，换一台机器就要全局搜索替换，非常容易漏改。推荐用一份 app.properties 统一管理，Spark 任务启动时读取，Django 侧则通过环境变量或 settings.py 读取。

properties复制# offline/conf/app.properties
mysql.report.url=jdbc:mysql://127.0.0.1:3306/crop_report?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
mysql.report.user=crop_user
mysql.report.password=change_me
hive.database=crop_dw
hdfs.ods.path=/data/crop/ods/crop_yield

这段配置里有两个点值得说明。第一，useUnicode=true&characterEncoding=utf8 必须带上，否则写入中文省份名时可能出现问号。第二，serverTimezone=Asia/Shanghai 不能省，JDBC 驱动在 MySQL 8 上如果不指定时区，连接阶段就会直接抛异常，这是新手最常遇到的第一个硬错误。

2.3 启动顺序与连通性自检

组件之间有依赖关系，启动顺序错了会出现"明明配置对却连不上"的假象。推荐顺序是：HDFS → MySQL（元数据库与结果库）→ Hive Metastore → HiveServer2 → Spark 任务 → Django。

每一层启动后都要单独验证，不要指望一次性全绿。

bash复制# 1. HDFS 可用性
hdfs dfs -ls /

# 2. Hive 元数据可用性
beeline -u jdbc:hive2://127.0.0.1:10000 -e "show databases;"

# 3. MySQL 结果库连通性
mysql -h127.0.0.1 -ucrop_user -p -e "show databases;" crop_report

# 4. Spark 能否读到 Hive 表
spark-sql -e "select count(1) from crop_dw.dwd_crop_yield;"

四个检查点全部通过，再开始写业务 SQL 和 Spark 任务。这里有一个经验判断：如果 beeline 能连上但 spark-sql 报找不到表，问题通常出在 hive-site.xml 没有被 Spark 读到，而不是 Hive 本身有问题，检查 SPARK_HOME/conf 下是否放置了同一份元数据配置即可。

3. 数据准备与 Hive 分层建模：把口径写在表结构里

农作物产量分析的核心字段其实不多：地区、作物、年份、播种面积、产量。但恰恰是这几个字段，最容易在建模阶段埋下隐患。比如面积单位有的数据源是"千公顷"、有的是"亩"，产量有的是"万吨"、有的是"吨"，如果不统一，算出来的单产会差好几个数量级，图表上看着就是一条离谱的曲线。所以建模这一步不只是建表，更是把单位、空值、去重规则固定下来。

3.1 字段设计与样例数据

先约定一套最小字段集，覆盖后续所有指标计算需要。下面是一份样例 CSV，字段含义在表后统一说明。

csv复制province,city,crop_name,stat_year,plant_area,yield_amount
河南省,周口市,小麦,2021,810.5,620.3
河南省,周口市,小麦,2022,815.2,635.8
河南省,周口市,玉米,2021,420.0,310.5
山东省,潍坊市,小麦,2021,500.2,398.7
山东省,潍坊市,小麦,2022,505.6,410.2

单位统一这件事要在 DWD 层一次性做完，不要留到 Spark 里再转换。因为在 Hive 里写一次转换，所有下游任务都能受益；而在 Spark 里转换，每个任务都要重复一遍，迟早会漏。

3.2 ODS 到 DWD 的建表脚本

ODS 层用外部表直接映射 HDFS 目录，好处是删表不删数据，出问题可以重建。注意 CSV 首行是表头，需要通过表属性跳过。

sql复制CREATE DATABASE IF NOT EXISTS crop_dw;
USE crop_dw;

CREATE EXTERNAL TABLE IF NOT EXISTS ods_crop_yield (
  province      STRING,
  city          STRING,
  crop_name     STRING,
  stat_year     INT,
  plant_area    DOUBLE,
  yield_amount  DOUBLE
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE
LOCATION '/data/crop/ods/crop_yield'
TBLPROPERTIES ('skip.header.line.count' = '1');

建完之后先做一次最小验证，确认字段没有被整体错位。如果省份列里出现的是年份，说明分隔符或表头处理有问题。

sql复制SELECT province, city, crop_name, stat_year, plant_area, yield_amount
FROM ods_crop_yield
LIMIT 10;

DWD 层用 Parquet 存储并按年份分区，原因是 Parquet 列式存储压缩比高、扫描快，分区则让"只看某几年"的查询自动裁剪文件。清洗逻辑放在 INSERT ... SELECT 里，包括去掉首尾空格、过滤非法年份、过滤面积非正数。

sql复制CREATE TABLE IF NOT EXISTS dwd_crop_yield (
  province      STRING,
  city          STRING,
  crop_name     STRING,
  plant_area    DOUBLE,
  yield_amount  DOUBLE
)
PARTITIONED BY (stat_year INT)
STORED AS PARQUET;

INSERT OVERWRITE TABLE dwd_crop_yield PARTITION (stat_year)
SELECT
  trim(province)  AS province,
  trim(city)      AS city,
  trim(crop_name) AS crop_name,
  plant_area,
  yield_amount,
  stat_year
FROM ods_crop_yield
WHERE stat_year BETWEEN 2000 AND 2100
  AND plant_area > 0
  AND yield_amount IS NOT NULL
  AND province IS NOT NULL
  AND province <> '';

这段 SQL 有两个设计取舍值得说明。第一，plant_area > 0 直接把面积为零或负数的记录挡在明细层之外，因为单产计算的分母必须有效，与其在 Spark 里到处判断，不如在这里一次性过滤。第二，允许 yield_amount 为空但在 ODS 层就过滤掉，是因为趋势分析关注的是有完整观测的年份，缺失值参与同比计算会让结果失真。如果业务上确实需要保留空值，应该改成保留并在下游用 coalesce 处理，而不是直接丢弃。

分区字段 stat_year 必须放在 SELECT 列表最后，这是 Hive 动态分区写入的语法要求。如果顺序写错，运行时会报列数不匹配。

3.3 DWS 汇总层：把指标口径固定下来

DWS 层的作用是把"省级 + 作物 + 年份"这个粒度的指标算好，供 Spark 和后续查询复用。单产是这里最核心的派生指标。

sql复制CREATE TABLE IF NOT EXISTS dws_crop_yearly (
  province      STRING,
  crop_name     STRING,
  stat_year     INT,
  plant_area    DOUBLE,
  yield_amount  DOUBLE,
  unit_yield    DOUBLE
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET;

INSERT OVERWRITE TABLE dws_crop_yearly PARTITION (dt = '2024')
SELECT
  province,
  crop_name,
  stat_year,
  sum(plant_area)   AS plant_area,
  sum(yield_amount) AS yield_amount,
  round(sum(yield_amount) / sum(plant_area), 4) AS unit_yield
FROM dwd_crop_yield
GROUP BY province, crop_name, stat_year;

这里用 sum 而不是 avg，是因为原始数据粒度是"地市"，省级指标应当由地市数据加总得到。如果直接对单产取平均，会得到"各地市单产的算术平均"，与"总产量除以总面积"在数值上并不相等，这是一个非常典型的统计口径错误，答辩时很容易被问到。

注意：任何比率型指标都要想清楚分子分母的聚合顺序。先聚合再相除，和先相除再平均，结果不一样，而且后者在样本量差异大时会严重偏离真实值。

4. Spark 计算趋势：同比、环比与区域排名

Hive 能做的事情，Spark 也能做，那为什么还要单独写 Spark 任务？原因在于趋势分析需要窗口函数和跨行取值，比如"取该省份该作物上一年的产量"，虽然部分 Hive 版本支持窗口函数，但把这类逻辑放在 Spark 里更灵活，也便于后续扩展到更复杂的计算，比如移动平均、连续增长年份统计。另外，Spark 读取 Hive 表、计算结果、写入 MySQL 这条完整链路，本身就是大数据项目里很有代表性的一段工程实现，写进论文或答辩材料里也更有说服力。

4.1 构建带 Hive 支持的 SparkSession

第一步是把 Spark 和 Hive 元数据打通。如果这一步没做对，后面所有 spark.sql("select ... from crop_dw.xxx") 都会报表不存在。

python复制from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("crop-yield-trend")
    .enableHiveSupport()
    .config("spark.sql.session.timeZone", "Asia/Shanghai")
    .config("spark.sql.shuffle.partitions", "16")
    .getOrCreate()
)

spark.sql("USE crop_dw")
df = spark.sql("SELECT * FROM dws_crop_yearly WHERE dt = '2024'")
df.printSchema()
df.show(5, truncate=False)

三个配置点需要解释。enableHiveSupport() 是必须的，没有它 Spark 用的是内置的内存目录，看不到 Hive 库表。spark.sql.session.timeZone 统一时区，避免日期函数在不同机器上算出不同结果。spark.sql.shuffle.partitions 默认是 200，对于几十万行的小数据集来说会产生大量空任务，调到 16 左右能明显减少任务调度开销，这个值要按数据量调整，不是固定最优。

4.2 用窗口函数计算同比与连续增长

同比的算法是：按省份和作物分组，按年份排序，取上一年的产量，然后用今年减去年再除以去年。Spark 的 lag 函数正好对应这个需求。

python复制from pyspark.sql import functions as F
from pyspark.sql.window import Window

w = Window.partitionBy("province", "crop_name").orderBy("stat_year")

trend = (
    df.withColumn("prev_yield", F.lag("yield_amount", 1).over(w))
      .withColumn(
          "yoy_rate",
          F.when(
              (F.col("prev_yield").isNotNull()) & (F.col("prev_yield") > 0),
              F.round((F.col("yield_amount") - F.col("prev_yield")) / F.col("prev_yield"), 4)
          ).otherwise(F.lit(None))
      )
      .withColumn("unit_yield", F.round(F.col("yield_amount") / F.col("plant_area"), 4))
      .select(
          "province", "crop_name", "stat_year",
          "plant_area", "yield_amount", "unit_yield",
          "prev_yield", "yoy_rate"
      )
)

trend.orderBy("province", "crop_name", "stat_year").show(20, truncate=False)

这段代码里最容易出问题的是除零和空值。prev_yield > 0 这个条件是必须的，否则上一年产量为 0 时会产生 Infinity 或 null，写进数据库后图表会直接断线或者显示异常值。用 when(...).otherwise(None) 而不是直接相除，是让异常情况变成明确的空值，前端可以据此显示"无对比数据"，而不是画一个错误的比例。

另一个细节是 unit_yield 在这里重新算了一遍。虽然 DWS 层已经算过，但 yield_amount 在 Spark 里可能经过过滤或合并，重算一次能保证口径与当前数据集一致。代价是多一次除法，对这个数据量来说可以忽略。

4.3 写入 MySQL 结果表

结果写入前，先在 MySQL 侧把目标表建好。字段类型要和 Spark DataFrame 的 schema 对得上，尤其是 DECIMAL 与 DOUBLE 的映射，类型不匹配会导致写入时报类型转换异常。

sql复制CREATE TABLE IF NOT EXISTS t_crop_yearly_trend (
  id           BIGINT AUTO_INCREMENT PRIMARY KEY,
  province     VARCHAR(64)  NOT NULL,
  crop_name    VARCHAR(64)  NOT NULL,
  stat_year    INT          NOT NULL,
  plant_area   DECIMAL(18,2),
  yield_amount DECIMAL(18,2),
  unit_yield   DECIMAL(18,4),
  prev_yield   DECIMAL(18,2),
  yoy_rate     DECIMAL(18,4),
  created_at   DATETIME DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY uk_province_crop_year (province, crop_name, stat_year)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

唯一索引 uk_province_crop_year 是幂等写入的关键。离线任务重跑很常见，如果没有唯一约束，每次重跑都会追加一批重复数据，图表上会出现同一年份两条记录。有了唯一索引，配合 mode("overwrite") 或者在写入前先按条件删除，就能保证结果表始终是"最新一次计算"的状态。

python复制mysql_url = "jdbc:mysql://127.0.0.1:3306/crop_report?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai"

(
    trend.write
    .format("jdbc")
    .option("url", mysql_url)
    .option("dbtable", "t_crop_yearly_trend")
    .option("user", "crop_user")
    .option("password", "change_me")
    .option("driver", "com.mysql.cj.jdbc.Driver")
    .option("batchsize", 1000)
    .option("truncate", "true")
    .mode("overwrite")
    .save()
)

truncate=true 配合 mode("overwrite") 会先清空目标表再写入，适合全量重算的场景。如果数据量大到不能整表清空，就应该改成按年份分区删除再插入。batchsize 控制每次提交的行数，默认值偏小，设为 1000 左右在本地环境下效率更好，但不要设得过大，否则单次事务过大容易超时。

注意：JDBC 驱动 jar 必须能被 Spark 找到。如果报 ClassNotFoundException: com.mysql.cj.jdbc.Driver，说明驱动没进 classpath，用 --jars 指定路径即可，不要试图在代码里 pip install 解决。

提交任务的命令如下，--jars 和 --master 按实际环境调整。

bash复制spark-submit \
  --master local[4] \
  --jars /opt/spark/jars/mysql-connector-j-8.0.33.jar \
  --conf spark.sql.shuffle.partitions=16 \
  offline/jobs/crop_trend_job.py

5. Django 侧只做取数和组装，不重复计算

离线结果写好之后，Web 层的实现就变得很轻。这里的核心原则是：Django 不做任何聚合计算，只按筛选条件读取结果表，把行数据组装成前端图表需要的结构。这样接口的响应时间与数据总量无关，只与单次返回的行数有关，分页和限制条数就能控制住性能。

5.1 模型定义与数据库路由

用 Django ORM 映射结果表时，字段类型要和 MySQL 保持一致，DecimalField 的 max_digits 与 decimal_places 必须和 DDL 对齐，否则取数时会出现精度截断。

python复制from django.db import models

class CropYearlyTrend(models.Model):
    province = models.CharField(max_length=64)
    crop_name = models.CharField(max_length=64)
    stat_year = models.IntegerField()
    plant_area = models.DecimalField(max_digits=18, decimal_places=2, null=True)
    yield_amount = models.DecimalField(max_digits=18, decimal_places=2, null=True)
    unit_yield = models.DecimalField(max_digits=18, decimal_places=4, null=True)
    prev_yield = models.DecimalField(max_digits=18, decimal_places=2, null=True)
    yoy_rate = models.DecimalField(max_digits=18, decimal_places=4, null=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        db_table = "t_crop_yearly_trend"
        unique_together = ("province", "crop_name", "stat_year")

db_table 必须显式指定，否则 Django 会按 app_label_modelname 的规则生成表名，和离线任务写入的表对不上，接口就会一直返回空数组。这是新手排查"数据库里明明有数据但接口没结果"时最常见的原因。

数据库配置建议把敏感信息放到环境变量里，至少不要硬编码在版本库中。

python复制import os

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": os.environ.get("REPORT_DB_NAME", "crop_report"),
        "USER": os.environ.get("REPORT_DB_USER", "crop_user"),
        "PASSWORD": os.environ.get("REPORT_DB_PASSWORD", ""),
        "HOST": os.environ.get("REPORT_DB_HOST", "127.0.0.1"),
        "PORT": os.environ.get("REPORT_DB_PORT", "3306"),
        "OPTIONS": {"charset": "utf8mb4"},
    }
}

5.2 接口设计：一个趋势接口覆盖大部分图表

前端图表需要的结构通常是"一个维度数组 + 若干数值数组"，比如年份作为 x 轴，产量和单产作为两个系列。后端直接按这个结构返回，前端就不需要再做二次转换。

python复制from rest_framework.decorators import api_view
from rest_framework.response import Response
from .models import CropYearlyTrend
from django.db.models import F

@api_view(["GET"])
def yield_trend(request):
    province = request.GET.get("province")
    crop_name = request.GET.get("crop_name")
    start_year = request.GET.get("start_year")
    end_year = request.GET.get("end_year")

    qs = CropYearlyTrend.objects.all()
    if province:
        qs = qs.filter(province=province)
    if crop_name:
        qs = qs.filter(crop_name=crop_name)
    if start_year:
        qs = qs.filter(stat_year__gte=int(start_year))
    if end_year:
        qs = qs.filter(stat_year__lte=int(end_year))

    rows = list(
        qs.order_by("stat_year")
          .values("stat_year", "yield_amount", "unit_yield", "yoy_rate")[:200]
    )

    return Response({
        "years": [r["stat_year"] for r in rows],
        "yield_amount": [float(r["yield_amount"]) if r["yield_amount"] is not None else None for r in rows],
        "unit_yield": [float(r["unit_yield"]) if r["unit_yield"] is not None else None for r in rows],
        "yoy_rate": [float(r["yoy_rate"]) if r["yoy_rate"] is not None else None for r in rows],
    })

这段代码有几个刻意为之的设计。第一，限制返回 200 行，虽然年份维度本身不会超过这个数，但加上省份和作物的多维度组合后行数会增加，限制条数是一种兜底。第二，Decimal 显式转 float，因为 DRF 默认序列化 Decimal 会变成字符串，前端图表拿到字符串后做数值运算会出错。第三，空值保留为 None 而不是填 0，这样图表可以正确断开，不会把缺失年份画成"产量为零"。

路由配置保持简单：

python复制from django.urls import path
from . import views

urlpatterns = [
    path("api/yield/trend/", views.yield_trend, name="yield-trend"),
]

5.3 前端图表对接与空数据处理

前端拿到接口数据后，直接构造图表配置。这里的重点是空值处理，如果某一年的同比为空，null 在折线图上会表现为断点，需要确认这是预期行为。

javascript复制async function renderTrend(province, cropName) {
  const params = new URLSearchParams({ province, crop_name: cropName });
  const resp = await fetch(`/api/yield/trend/?${params.toString()}`);
  const data = await resp.json();

  if (!data.years || data.years.length === 0) {
    document.getElementById("trend").innerText = "当前筛选条件下暂无数据";
    return;
  }

  const chart = echarts.init(document.getElementById("trend"));
  chart.setOption({
    tooltip: { trigger: "axis" },
    legend: { data: ["产量", "单产"] },
    xAxis: { type: "category", data: data.years },
    yAxis: [
      { type: "value", name: "产量" },
      { type: "value", name: "单产" }
    ],
    series: [
      { name: "产量", type: "line", data: data.yield_amount, smooth: true },
      { name: "单产", type: "line", yAxisIndex: 1, data: data.unit_yield, smooth: true }
    ]
  });
}

双 y 轴的设计是为了解决量纲问题。产量和单产的数值范围差距可能很大，共用一根轴会让单产曲线压成一条直线，看不出趋势。把单产放到次轴上，两条曲线的形态都能保留。如果还要展示同比，建议单独用一个柱状图，因为同比有正有负，和产量放在同一张图上会干扰阅读。

6. 端到端验证与排查路径

一条链路能不能用，不取决于代码写得多漂亮，而取决于你能不能快速判断问题出在哪一层。下面这套验证顺序是我在实际项目里反复用到的，从数据源头往下逐层检查，基本能覆盖绝大多数故障。

6.1 分层验证清单

这张表的价值在于把"没数据"这个模糊现象拆成了六个可判断的具体状态。接口返回空数组时，先看 MySQL 有没有数据；MySQL 有数据再看接口的过滤条件是不是写错了省份名；MySQL 也没数据，就往上追到 Spark 任务是否成功、DWS 是否有结果。

6.2 典型报错与处理方式

下面这些错误在搭建过程中出现频率很高，建议对照日志关键字快速定位。

注意：排查时优先怀疑"输入不对"，而不是"代码有 bug"。绝大多数数据类故障，最终原因都是文件格式、字段顺序或路径配错，而不是算法写错。

6.3 三个必须提前避开的坑

第一个坑是把缺失值当零处理。原始数据里某一年产量缺失，如果清洗时用 coalesce(yield_amount, 0) 填充，趋势图上就会出现一个"产量归零"的深谷，同比也会算成负百分之百。正确做法是保留空值，在计算同比时判断基数是否有效，图表上用断点或空值表达。

第二个坑是单位没有统一就直接聚合。面积字段如果一部分是"千公顷"、一部分是"亩"，加总之后的单产会失真几个数量级，而且这种错误在图上通常表现为"某省份单产异常高"，很容易被误判为数据源有问题。统一单位必须在 DWD 层完成，并在建表注释里写清楚。

第三个坑是离线任务与接口表共用同一张表。有些项目为了省事，让 Spark 直接往业务表里写，接口同时读这张表，结果就是任务重跑期间接口返回空数据或重复数据。推荐的隔离方式是：离线任务写入中间表或带批次标记的表，写入完成后再做一次原子切换，接口始终只读"当前有效"的那一份。数据量不大时，用 truncate + insert 在同一事务里完成也能达到类似效果。

7. 从能跑通到能讲清楚：生产化差异与毕设写作建议

毕业设计和生产系统之间最大的差别不是技术栈，而是对异常、重跑、监控和权限的处理深度。学习环境里跑通一次就算成功，生产环境里要考虑任务失败怎么重试、数据延迟怎么发现、结果错了怎么回滚、谁能改口径。把这些差异想清楚，论文里的"系统设计"章节才不会写成流水账。

7.1 学习环境与生产环境的关键差异

这张表可以直接用在论文的"系统优化"或"不足与展望"部分，比空泛地写"未来将提升系统稳定性"要有说服力得多。

7.2 性能与资源上几个实用的调整点

对这类数据量不大的分析场景，性能瓶颈往往不在计算，而在小文件和数据倾斜。HDFS 上如果每天上传一个 CSV，几年下来就是上千个小文件，Hive 查询时每个文件都要开一个任务，调度开销远大于实际计算。解决办法是定期做一次合并，或者在上传阶段就按年归档成一个文件。

Spark 侧则要注意分区数设置。默认的 200 个 shuffle 分区对几十万行数据来说太多，大部分任务只处理几行就结束，日志里会看到大量耗时极短的 task。把 spark.sql.shuffle.partitions 调到 16 到 32 之间，任务耗时会明显下降。但如果数据量真的涨到千万级，又要相应调大，所以这个参数应该写在配置里而不是硬编码。

另一个容易忽略的点是查询侧的索引。Django 接口里的筛选条件通常是 province、crop_name、stat_year，如果结果表只有主键索引，每次查询都会全表扫描。给这三个字段建联合索引，或者在 MySQL 里按 (province, crop_name, stat_year) 建唯一键，查询就能走索引。数据量小时感觉不明显，但当表增长到几十万行、页面又要频繁切换筛选条件时，差异就会显现出来。

7.3 一份可直接使用的上线前检查清单

在演示或提交之前，按下面的顺序过一遍，能挡掉大部分低级问题：

• 原始 CSV 的编码是 UTF-8，首行表头与 Hive 表字段顺序完全一致。
• HDFS 上的 ODS 目录结构与 LOCATION 配置一致，且文件大小非 0。
• ODS 表查询结果中省份、作物字段不是 NULL，年份是四位数字。
• DWD 表分区存在，且 plant_area > 0、yield_amount 非空的记录占绝大多数。
• DWS 表单产数值在业务合理区间，没有出现几千或零点零几这种量级异常。
• MySQL 结果表有唯一约束，重复执行 Spark 任务不会产生重复行。
• Spark 任务退出码为 0，日志中没有 ERROR 级别的写库异常。
• Django 的 db_table 与 MySQL 实际表名一致，字段类型映射正确。
• 接口在无筛选、单条件、多条件三种情况下都能返回结构正确的 JSON。
• 图表在数据为空、只有一条记录、同比为 null 三种边界情况下不会报错。
• 敏感配置（数据库密码）没有提交到代码仓库。
• 有一份从零开始的部署说明，换一台机器能照着跑通。

这份清单看起来琐碎，但每一条都对应过一次真实的排查经历。尤其是最后一条，很多人自己机器上跑得好好的，换环境就各种报错，原因往往是环境变量、驱动 jar、字符集这些没有写进文档的隐性依赖。

如果把这条链路继续往下做，比较自然的扩展方向有三个：一是引入调度工具，把 Spark 任务做成按天自动运行；二是把结果表换成更适合多维分析的存储，支持更灵活的下钻和切片；三是在 Web 侧加上导出的能力，让分析结果能落到 Excel 或 PDF。这三个方向的共同前提，都是当前的层次划分已经足够清晰——只有每一层的输入输出稳定，扩展才不会牵一发动全身。对正在做毕业设计的人来说，把这条最小链路真正跑通、每一层都能解释清楚为什么这么设计，比堆更多图表更有价值。