企业官网建设流程全解析

简介：这是一份基于SpringBoot+HiveJDBC+ECharts的数据大屏可视化与大数据分析完整源码，面向计算机专业毕设学生、大数据可视化及Java实战学习者，可直接用于课程设计、期末大作业等场景。项目在Centos7搭建Hadoop和Hive环境，通过SpringBoot整合HiveJDBC远程连接HiveServer2，对6万条美妆销售数据进行处理分析，后端输出JSON、前端ECharts实现大屏展示，生成每日订单量走势、前十销售品牌、地域偏好等有价值结论。压缩包共70个文件，其中14个Java源码负责后端逻辑与数据访问，8个JavaScript和5个CSS构成可视化前端，另有19个PNG图片及字体文件等界面资源，整体仅1.86MB，内含项目使用说明，目录清晰便于查阅。目前已有1938人学习下载，适合需要快速落地大数据分析实战、复用可视化模板或参考毕设架构的读者。

1. 为什么 SpringBoot 项目里用 HiveJDBC 而不是 MyBatis

拿到一份六万条美妆销售数据，要做出数据大屏可视化时，很多人会本能地想到“SpringBoot 连 MySQL，用 MyBatis 查，再拿 echarts 画屏”。但这套项目的数据链路明显不同：销售订单表和商品信息表放在 Hadoop 上，由 Hive 3.1 做离线分析，SpringBoot 通过 HiveJDBC 远程访问 HiveServer2，Java 提交 HiveSQL，结果转 JSON，前端再交给 echarts 渲染。选 HiveJDBC 而不是 MyBatis，核心原因是聚合分析不应该压给业务数据库，六万条数据的 group by 和 join 放到 Hive 上，走 YARN 分布式计算，SpringBoot 只承担轻量查询和接口下发。对正在做大数据方向毕设、课程设计，以及想完整跑通 Hadoop + Hive + SpringBoot + ECharts 全链路的 Java 学习者来说，这套组合是成本最低、最能讲清楚“数据从 HDFS 到前端图表”的落地方式。

2. HiveServer2 连接原理与 SpringBoot 配置

2.1 HiveServer2：HiveJDBC 背后的门面

HiveJDBC 不是一个独立数据库驱动，它连的其实是 HiveServer2 暴露出来的 JDBC 协议入口。HiveServer2 启动后监听 10000 端口，接收来自 Java、Beeline、Python 客户端的 SQL 请求，再转成执行计划提交到 Hadoop 集群。默认传输模式是 binary，基于 Thrift；如果跨网络部署，也可以开 HTTP 模式走 10001 端口，但大屏场景直接用 binary 少一层 HTTP 转发，查询延迟更低。

在 SpringBoot 里集成时，照搬 MySQL 的配置思路是很常见的错误。HiveJDBC 驱动从建立连接开始就比 MySQL 重：要做认证协商，要和 HiveServer2 交换客户端信息，所以连接不能频繁创建，必须靠连接池复用。这个项目用的是 Spring JDBC 的JdbcTemplate，没有引入 MyBatis 的实体映射，原因也简单：HiveSQL 结果集的列名和类型不稳定，直接映射成 Java 对象容易报类型转换错，用Map接收再手动转字段更可控。

2.2 pom.xml 与 application.yml 配置

先处理hive-jdbc依赖的冲突。Hive 3.1 的 JDBC 包会连带引入 Jetty、Tomcat、Calcite 等一大堆依赖，直接塞进 SpringBoot 会覆盖内嵌 Tomcat。常见的做法是把 Jetty 相关依赖排除掉：

<dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-jdbc</artifactId> <version>3.1.2</version> <exclusions> <exclusion> <groupId>org.eclipse.jetty.aggregate</groupId> <artifactId>jetty-all</artifactId> </exclusion> <exclusion> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-server</artifactId> </exclusion> </exclusions> </dependency>

这段配置保留了hive-jdbc和它自动带上的 Hadoop 客户端 API，排除掉 Jetty 容器组件，避免 SpringBoot 启动时端口被抢占。如果项目里还有 Guava 版本冲突，再单独加一个guava排除即可。

连接配置放在application.yml：

hive: url: jdbc:hive2://hadoop-centos:10000/sales_dw driver-class-name: org.apache.hive.jdbc.HiveDriver username: root password: hadoop pool: max-total: 8 max-wait-millis: 10000

这里的hadoop-centos是 HiveServer2 所在节点的集群主机名，建议优先用/etc/hosts里的名称，不要直接写 IP，因为 Hadoop 返回给客户端的数据节点地址可能和外部 IP 不一致。如果集群没开 Kerberos，URL 末尾要加;auth=noSasl，否则会报认证相关错误。常用参数整理如下：

2.3 用 HiveJdbcTemplate 封装查询

把 Hive 查询收敛到一个模板类里，后续所有大屏接口都复用，便于打日志和统一超时控制：

@Component public class HiveJdbcTemplate { private final JdbcTemplate jdbcTemplate; @Autowired public HiveJdbcTemplate(@Qualifier("hiveJdbcTemplate") JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } public List<Map<String, Object>> queryForList(String sql) { return jdbcTemplate.queryForList(sql); } }

@Qualifier("hiveJdbcTemplate")是为了和项目里其他数据源区分，避免 SpringBoot 自动注入到 MySQL 的 JdbcTemplate。queryForList返回的每一行是Map，列名就是 HiveSQL 里的别名；没有做实体映射，因此不管 Hive 返回的字段是大写还是带特殊字符，都不会在 ORM 层报错。数据源配置用的是 HikariCP，maxPoolSize设成 5 到 8 即可，大屏轮询不会产生太高的并发。

如果某个查询超过 60 秒，页面同步等待不现实。六万条数据做走势统计通常几十秒内能出，但如果 Hive 默认引擎是 MapReduce 而不是 Tez，速度会明显变慢，这一点在排错章节再展开。

3. 六万条美妆销售数据的 HiveSQL 分析与 JSON 输出

3.1 原始表结构与 Hive 建表

资源包里提供的是销售订单表和商品信息表两个文本文件。按最常见的 CSV 格式设计，订单表字段为order_id, user_id, product_id, order_date, order_amount, city，商品表字段为product_id, brand, category。先建库再建表：

CREATE DATABASE IF NOT EXISTS sales_dw; USE sales_dw; CREATE TABLE IF NOT EXISTS sales_orders ( order_id STRING, user_id STRING, product_id STRING, order_date STRING, order_amount DOUBLE, city STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE;

order_date用 STRING 而不是 TIMESTAMP，是故意为之。原始文本里的日期可能是2023-04-12，也可能是2023/4/12，用 STRING 存下来后可以在 SQL 里用regexp_replace统一格式，比让 Hive 自己解析时间类型更可控。金额字段必须用 DOUBLE，后续SUM才能算销售额。

建表后导入数据：

LOAD DATA LOCAL INPATH '/opt/data/sales_orders.txt' INTO TABLE sales_orders; LOAD DATA LOCAL INPATH '/opt/data/product_info.txt' INTO TABLE product_info;

LOCAL表示文件在 HiveServer2 所在节点的本地磁盘上。LOAD 执行后文件会被移动到 HDFS，原路径不会保留，因此导入之前记得留一份备份。

3.2 三个分析 SQL：走势、品牌、地域

大屏核心模块对应三条 SQL。先看每日订单量走势：

SELECT order_date, COUNT(*) AS order_cnt FROM sales_orders GROUP BY order_date ORDER BY order_date;

这条 SQL 在六万条数据上通常十秒内能返回。如果一张订单在明细表里产生多行，必须用COUNT(DISTINCT order_id)而不是COUNT(*)，否则每日订单量会被放大，走势曲线虚高。

Top10 销售品牌需要 join 商品信息表：

SELECT p.brand, COUNT(DISTINCT o.order_id) AS brand_orders, SUM(o.order_amount) AS brand_amount FROM sales_orders o JOIN product_info p ON o.product_id = p.product_id GROUP BY p.brand ORDER BY brand_amount DESC LIMIT 10;

这里同时统计订单数和销售额。排序时优先用brand_amount，因为“销售品牌”在大屏场景里通常指卖得最多的品牌，GMV 比订单数更能反映业务价值。商品表是小表，Hive 会自动转为 MapJoin，不需要手动加 hint。

地域偏好统计：

SELECT city, SUM(order_amount) AS total_amount, COUNT(*) AS order_cnt FROM sales_orders GROUP BY city ORDER BY total_amount DESC LIMIT 20;

如果city字段是“广东省,深圳市”这种格式，先用split(city, ',')[1]取城市名再 group by。后端返回给前端时，建议再按省份聚合一次，方便 echarts 中国地图做区域着色。三个模块与 SQL 对应关系如下：

3.3 后端接口与 JSON 结构

不要直接把 HiveJDBC 返回的原始 Map 序列化给前端。Hive 的列名可能是_c0、_c1，数字类型可能变成 Long 或 BigInteger，前端用起来很难受。统一在 service 层转换，接口设计如下：

@RestController @RequestMapping("/api/bigscreen") public class BigScreenController { @Resource private HiveAnalysisService analysisService; @GetMapping("/overview") public Map<String, Object> overview() { return Result.success(new HashMap<String, Object>() {{ put("orderTrend", analysisService.orderTrend()); put("brandTop10", analysisService.brandTop10()); put("cityRank", analysisService.cityRank()); }}); } }

一个overview接口聚合三个分析结果，前端只请求一次就能拿全图表数据。不要拆成三个接口让页面并发请求，Hive 连接池不大，三个连接同时占用会拖慢其他查询。

在 service 层做字段转换：

public List<Map<String, Object>> orderTrend() { String sql = "SELECT order_date, COUNT(*) AS cnt FROM sales_orders " + "GROUP BY order_date ORDER BY order_date"; List<Map<String, Object>> raw = hiveJdbcTemplate.queryForList(sql); return raw.stream().map(row -> { Map<String, Object> m = new HashMap<>(); m.put("date", String.valueOf(row.get("order_date"))); m.put("count", Long.parseLong(String.valueOf(row.get("cnt")))); return m; }).collect(Collectors.toList()); }

Long.parseLong(String.valueOf(...))是一个很实用的兼容写法：Hive 的 BigInt 在 JDBC 里可能被识别成 Long、BigInteger 或 String，统一转成字符串再解析，能避开绝大多数类型强转异常。date字段保留字符串，折线图 category 轴直接可用。

最终 JSON 结构：

{ "code": 0, "data": { "orderTrend": [{ "date": "2023-04-01", "count": 2100 }], "brandTop10": [{ "brand": "YSL", "amount": 1200000 }], "cityRank": [{ "city": "上海", "total": 890000 }] } }

字段名和图表维度一一对应，前端拿到后不需要二次聚合。

4. ECharts 数据大屏渲染与刷新策略

4.1 大屏前端目录与数据流

项目前端资源放在 SpringBoot 的resources/static下：views放 index 页面，scripts放 echarts.min.js 和自写的图表渲染方法，styles放大屏 CSS，images/fonts放背景和图标。页面启动后调用后端/api/bigscreen/overview，拿到统一 JSON 后分别交给renderTrend、renderBrand、renderCity三个函数。

数据流很清晰：后端已经完成统计，前端只做渲染。不要在浏览器里对 Hive 聚合结果再做reduce或sort，尤其是地图数据，前端聚合逻辑一旦出错，排查难度比后端高得多。

4.2 折线图、饼图、中国地图的配置细节

折线图展示每日订单量走势：

const trendChart = echarts.init(document.getElementById('trendChart')); trendChart.setOption({ tooltip: { trigger: 'axis' }, xAxis: { type: 'category', data: dates, axisLabel: { rotate: 30, color: '#aaa' } }, yAxis: { type: 'value', name: '订单数', splitLine: { lineStyle: { color: '#1e2b3a' } } }, series: [{ type: 'line', smooth: true, symbol: 'circle', symbolSize: 6, data: counts, lineStyle: { width: 3, color: '#37d2ed' }, areaStyle: { opacity: 0.2 } }] });

xAxis.data对应后端date数组；axisLabel.rotate: 30避免 30 天日期重叠。smooth: true让曲线更平滑，但会掩盖数据突变，如果大屏用于经营监测，建议改成false。深色背景下亮青色线条比默认蓝色更醒目。

品牌占比用环形饼图：

const pieChart = echarts.init(document.getElementById('brandChart')); pieChart.setOption({ legend: { type: 'scroll', bottom: 5, textStyle: { color: '#fff' }, pageIconColor: '#37d2ed' }, series: [{ type: 'pie', radius: ['35%', '65%'], center: ['50%', '45%'], label: { formatter: '{b}: {d}%', color: '#eee' }, data: brandData }] });

radius: ['35%', '65%']形成环形饼图，比实心饼更适合展示 Top10 品牌的份额。legend.type: 'scroll'防止十个品牌在窄侧栏里溢出。大屏饼图最重要的是把百分比显示在扇区旁边，否则看板信息密度不够。如果觉得普通饼图不够立体，可以引入echarts-gl做pie3D，但要先确认echarts-gl和当前 echarts 版本兼容，否则地图和饼图都会白屏。

中国地图展示地域热度：

const mapChart = echarts.init(document.getElementById('mapChart')); mapChart.setOption({ geo: { map: 'china', roam: false, itemStyle: { areaColor: '#1c2b3a', borderColor: '#37d2ed' } }, series: [{ type: 'map', map: 'china', geoIndex: 0, data: cityRank }] });

cityRank的每一项必须是{ name: '广东', value: 120000 }，name必须和china.js注册的地区名完全一致。echarts 5 之后不再内置中国地图，需要在页面里手动引入china.min.js，或者使用 npm 包里的 GeoJSON。大屏项目建议把地图文件放到本地的scripts目录，不要依赖 CDN，离线演示时地图才不会白屏。

三种图表的配置对照：

4.3 大屏布局与定时刷新

大屏页面通常按网格分三块：左侧放品牌饼图和订单量趋势，中间放中国地图，右侧放地域榜单。每个图表容器用百分比尺寸，才能兼容 1920x1080 和更小分辨率。resize 监听和定时刷新写在一起：

window.addEventListener('resize', () => { trendChart.resize(); pieChart.resize(); mapChart.resize(); }); function loadOverview() { fetch('/api/bigscreen/overview') .then(res => res.json()) .then(data => { renderTrend(data.data.orderTrend); renderBrand(data.data.brandTop10); renderCity(data.data.cityRank); }) .catch(err => console.error('大屏数据加载失败', err)); } loadOverview(); setInterval(loadOverview, 300000);

刷新间隔建议 5 分钟以上，Hive 查询本身较慢，太频繁会压满连接池。每次刷新时先chart.setOption(currentOption, true)再更新 data，避免图表闪烁。注册resize后，浏览器缩放不会导致图表裁切。

5. HiveJDBC 大屏项目的排错与参数化进阶

5.1 上线必查的 4 个坑

第一坑：Could not open client transport with JDBC Uri。八成是 HiveServer2 没起来或端口不通。先jps看有没有 RunJar，再telnet 127.0.0.1 10000测本机端口；跨服务器访问时检查hive-site.xml里hive.server2.thrift.bind.host是否为0.0.0.0。

第二坑：Current state=CLOSED。Hive 连接被服务端断开，常见原因是空闲超时或连接数耗尽。用 HikariCP 时把max-lifetime调得比服务端空闲超时短一些，并配置connection-test-query定期探测。项目同时连 MySQL 和 Hive 时，两个 JdbcTemplate 必须用不同的 Bean 名称注入，避免大屏接口串到业务库。

第三坑：SQL 执行很慢。六万条数据不至于跑三分钟，如果发生，进 Beeline 执行set hive.execution.engine=tez;。Hive 3.1 默认 Tez，集群没配置 TEZ_HOME 时退回 MapReduce，速度差距很大。大屏场景还可以把sales_orders按order_date分区，让走势查询只扫目标分区。

第四坑：中文乱码。连接 URL 加useUnicode=true&characterEncoding=UTF-8，并确保原始 txt 文件是 UTF-8。用 LOAD DATA LOCAL 加载 GBK 文件后，中文标签全会变成问号，靠 SQL 层cast救不回来。

5.2 参数化查询：让全量大屏变成可筛选大屏

如果大屏要支持按日期范围筛选，不能把用户输入直接拼进 SQL。比较好的做法是先用正则做白名单校验，再拼接字符串。HiveJDBC 在 Hive 3.1 上的 prepared statement 对日期参数支持不如 MySQL 稳定，所以用“校验 + 拼接”的方式更可控：

public List<Map<String, Object>> orderTrend(String startDate, String endDate) { String sql = "SELECT order_date, COUNT(*) AS cnt FROM sales_orders " + "WHERE order_date >= '" + startDate + "' AND order_date <= '" + endDate + "' " + "GROUP BY order_date ORDER BY order_date"; return hiveJdbcTemplate.queryForList(sql); }

startDate和endDate必须通过Pattern.matches("\\d{4}-\\d{2}-\\d{2}", date)校验，否则 SQL 注入会直接打到 HiveServer2。大屏页面增加时间选择器后，请求/api/bigscreen/overview?startDate=2023-03-01&endDate=2023-04-30，后端再把参数分流到三个分析方法即可。

当数据量真的上到千万行，再把sales_orders改成按order_date分区，查询带上分区字段；同时调整连接池的maxTotal和 YARN 队列资源，否则大屏刷新会卡在 HiveServer2 的等待队列里。

本文还有配套的精品资源，点击获取