简介这是一份基于SpringBootHiveJDBCECharts的数据大屏可视化与大数据分析完整源码面向计算机专业毕设学生、大数据可视化及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 远程访问 HiveServer2Java 提交 HiveSQL结果转 JSON前端再交给 echarts 渲染。选 HiveJDBC 而不是 MyBatis核心原因是聚合分析不应该压给业务数据库六万条数据的 group by 和 join 放到 Hive 上走 YARN 分布式计算SpringBoot 只承担轻量查询和接口下发。对正在做大数据方向毕设、课程设计以及想完整跑通 Hadoop Hive SpringBoot ECharts 全链路的 Java 学习者来说这套组合是成本最低、最能讲清楚“数据从 HDFS 到前端图表”的落地方式。2. HiveServer2 连接原理与 SpringBoot 配置2.1 HiveServer2HiveJDBC 背后的门面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 groupIdorg.apache.hive/groupId artifactIdhive-jdbc/artifactId version3.1.2/version exclusions exclusion groupIdorg.eclipse.jetty.aggregate/groupId artifactIdjetty-all/artifactId /exclusion exclusion groupIdorg.eclipse.jetty/groupId artifactIdjetty-server/artifactId /exclusion /exclusions /dependency这段配置保留了hive-jdbc和它自动带上的 Hadoop 客户端 API排除掉 Jetty 容器组件避免 SpringBoot 启动时端口被抢占。如果项目里还有 Guava 版本冲突再单独加一个guava排除即可。连接配置放在application.ymlhive: 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 不一致。如果集群没开 KerberosURL 末尾要加;authnoSasl否则会报认证相关错误。常用参数整理如下配置示例值说明transport modebinary / httpbinary 默认局域网推荐authnoSasl / kerberos / ldap无认证集群用 noSaslsocketTimeout600000长 SQL 执行时防止客户端先超时hive.server2.thrift.bind.host0.0.0.0HiveServer2 监听地址在 hive-site.xml 配置maxTotal8Hive 连接池上限大屏接口并发不高8 足够2.3 用 HiveJdbcTemplate 封装查询把 Hive 查询收敛到一个模板类里后续所有大屏接口都复用便于打日志和统一超时控制Component public class HiveJdbcTemplate { private final JdbcTemplate jdbcTemplate; Autowired public HiveJdbcTemplate(Qualifier(hiveJdbcTemplate) JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public ListMapString, Object queryForList(String sql) { return jdbcTemplate.queryForList(sql); } }Qualifier(hiveJdbcTemplate)是为了和项目里其他数据源区分避免 SpringBoot 自动注入到 MySQL 的 JdbcTemplate。queryForList返回的每一行是Map列名就是 HiveSQL 里的别名没有做实体映射因此不管 Hive 返回的字段是大写还是带特殊字符都不会在 ORM 层报错。数据源配置用的是 HikariCPmaxPoolSize设成 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 对应关系如下大屏模块SQL 关键点输出规模订单走势GROUP BY order_date几十行品牌 Top10JOIN LIMIT 1010 行地域热度GROUP BY city LIMIT 2020 行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 MapString, Object overview() { return Result.success(new HashMapString, Object() {{ put(orderTrend, analysisService.orderTrend()); put(brandTop10, analysisService.brandTop10()); put(cityRank, analysisService.cityRank()); }}); } }一个overview接口聚合三个分析结果前端只请求一次就能拿全图表数据。不要拆成三个接口让页面并发请求Hive 连接池不大三个连接同时占用会拖慢其他查询。在 service 层做字段转换public ListMapString, Object orderTrend() { String sql SELECT order_date, COUNT(*) AS cnt FROM sales_orders GROUP BY order_date ORDER BY order_date; ListMapString, Object raw hiveJdbcTemplate.queryForList(sql); return raw.stream().map(row - { MapString, 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放大屏 CSSimages/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离线演示时地图才不会白屏。三种图表的配置对照图表类型核心配置常见坑折线图xAxis.category series.line日期顺序要服务端排好饼图radius 环形 legend.scroll品牌名重复或空值中国地图geo.map series.mapname 要和地图 json 一致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 stateCLOSED。Hive 连接被服务端断开常见原因是空闲超时或连接数耗尽。用 HikariCP 时把max-lifetime调得比服务端空闲超时短一些并配置connection-test-query定期探测。项目同时连 MySQL 和 Hive 时两个 JdbcTemplate 必须用不同的 Bean 名称注入避免大屏接口串到业务库。第三坑SQL 执行很慢。六万条数据不至于跑三分钟如果发生进 Beeline 执行set hive.execution.enginetez;。Hive 3.1 默认 Tez集群没配置 TEZ_HOME 时退回 MapReduce速度差距很大。大屏场景还可以把sales_orders按order_date分区让走势查询只扫目标分区。第四坑中文乱码。连接 URL 加useUnicodetruecharacterEncodingUTF-8并确保原始 txt 文件是 UTF-8。用 LOAD DATA LOCAL 加载 GBK 文件后中文标签全会变成问号靠 SQL 层cast救不回来。5.2 参数化查询让全量大屏变成可筛选大屏如果大屏要支持按日期范围筛选不能把用户输入直接拼进 SQL。比较好的做法是先用正则做白名单校验再拼接字符串。HiveJDBC 在 Hive 3.1 上的 prepared statement 对日期参数支持不如 MySQL 稳定所以用“校验 拼接”的方式更可控public ListMapString, 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?startDate2023-03-01endDate2023-04-30后端再把参数分流到三个分析方法即可。当数据量真的上到千万行再把sales_orders改成按order_date分区查询带上分区字段同时调整连接池的maxTotal和 YARN 队列资源否则大屏刷新会卡在 HiveServer2 的等待队列里。本文还有配套的精品资源点击获取