数据可视化平台源码解析：数据库设计、动态数据源与大屏实现

简介这是一份数据可视化分析平台源码与配套数据库主要面向Java技术栈的软件开发、数据分析及BI平台二次开发者。平台覆盖数据源管理、项目管理、数据集管理、图表管理与看板管理全流程支持接入MySQL、NoSQL等常见数据源并可自定义图表与拖拽式看板实时展示关键业务指标。资源包共1160个文件约27.19MB其中682个Java文件构成后端主体119个FTL模板、95个JS及CSS文件负责前端渲染9个SQL脚本用于初始化数据库JSON、XML等配置则便于调整数据源和权限策略。借助完整源码读者可理解从数据接入、清洗转换到可视化展示的工程实现修改图表类型、看板布局与权限控制也能借鉴其数据源管理、ETL处理和看板交互设计适合作为企业级数据平台的二次开发底稿或数据可视化课程实战案例。目前已有389人学习下载对希望从源码层面掌握可视化平台搭建的开发者具有较高参考价值。1. 数据可视化分析平台的源码构成与数据库定位数据可视化分析平台从来不是一套前端图表模板就能撑起来的。它由三块互相咬合的东西组成数据接入层从 MySQL、Oracle、达梦或 ClickHouse 里取数分析引擎做聚合计算可视化层把结果映射成大屏、折线图和透视表。标题里的源码加数据库指的是业务代码和配套库表一起交付因为可视化配置、数据源信息、用户权限这些元数据本身要存进数据库。所以拿到一份源码包光编译跑通不算完还得把元数据库建对、把数据源接上、把图表配置灌进去。这篇文章按实际落地路径展开建库、改配置、把服务跑起来再到二次开发和性能排查。适合准备接手一套可视化平台源码的 Java 或前端工程师也适合做数据库课程设计时参考库表设计思路。2. 数据库表结构设计与数据源接入配置标题里数据库三个字在可视化分析平台里要分两层理解。一是平台自身的元数据库存用户、数据源连接串、图表配置、大屏布局二是被分析的业务数据库也就是图表背后真正的数据来源。拿到源码包时一般会看到sql/目录下的初始化脚本常见结构是init.sql建库建表、seed.sql写入默认管理员和示例数据源。不要急着双击导入先逐行读建表语句确认字符集、引擎和字段注释再决定要不要执行。2.1 平台元数据库的核心表与建表细节可视化分析平台的元数据库设计不同项目表名有差异职责基本固定。我一般会先找这五张表数据源注册表、图表配置表、大屏布局表、用户表、角色权限表。以数据源注册表为例标准建表语句长这样CREATE TABLE ds_source ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(64) NOT NULL COMMENT 数据源名称, type varchar(16) NOT NULL COMMENT mysql/oracle/clickhouse, host varchar(128) NOT NULL, port int(11) NOT NULL, dbname varchar(64) NOT NULL, username varchar(64) NOT NULL, password varchar(256) NOT NULL COMMENT 加密存储, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT数据源注册表;这段语句有三个细节值得停下来看。type字段用字符串而非数字枚举扩展 Oracle、达梦这类新数据源类型时不需要改表结构代价是查询时多一次字符串比较对元数据表来说完全可以忽略。password留 256 长度是因为要对密文做 AES 加密或 base64 处理后再入库明文存储是这类源码项目最常见的低级坑接手后第一件事就是把密码字段改成加密存储。create_time用CURRENT_TIMESTAMP默认值插入记录时不传这个字段也能拿到准确时间省掉应用层手动塞时间的代码。图表配置表是另一张核心表它把可视化方案本身存进数据库真正实现配置驱动开发。CREATE TABLE chart_config ( id int(11) NOT NULL AUTO_INCREMENT, title varchar(128) NOT NULL, chart_type varchar(32) NOT NULL COMMENT line/bar/pie/map, source_id int(11) NOT NULL COMMENT 关联ds_source.id, query_sql text NOT NULL COMMENT 取数SQL, option_json text COMMENT ECharts option的JSON片段, refresh_interval int(11) DEFAULT 0 COMMENT 自动刷新秒数0为不刷新, PRIMARY KEY (id), KEY idx_source_id (source_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT图表配置表;这个设计的精妙之处在于新增图表不需要改代码往表里插一条记录就行。query_sql用 text 类型是因为聚合查询带 GROUP BY 和子查询时可能很长option_json存 ECharts 配置片段前端拿到后与基础配置做深合并。idx_source_id索引在建表时就加上避免后面数据量大了再补。图表数量上千后按数据源批量查询配置的场景非常常见。这两张表配合一个简单的配置界面就是一个简化版的企业级数据可视化平台雏形业务人员配图表开发只维护框架。2.2 多数据库驱动并存的数据源适配策略平台要连的往往不止 MySQL。实际交付场景里业务库经常是 Oracle、达梦统计分析场景还会碰到 ClickHouse。源码项目处理多数据源常见做法有两种一是基于 Spring 的 AbstractRoutingDataSource 做动态路由二是直接在 MyBatis 配置里写死多个环境。前者更适合可视化平台因为数据源是用户在界面上动态添加的不可能每次新增都重新发布应用。动态路由的核心是三个类路由类本身很简洁public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DataSourceContextHolder.getDataSourceKey(); } }DataSourceContextHolder用 ThreadLocal 保存当前请求绑定的数据源 key查询前由拦截器根据请求参数里的 source_id 设置 key查询完在 finally 里清理防止线程池复用导致拿错连接。这种做法有两个容易翻车的点连接池必须给每个数据源独立配置HikariCP 的 maximumPoolSize 不能大家共用一个计数跨数据源的事务要慎用一旦涉及两个库的写操作就需要分布式事务绝大多数可视化大屏是纯查询场景不需要这个复杂度。不同数据库的方言差异是另一个高频坑。同样一个取数 SQLMySQL 的LIMIT在 Oracle 里要改OFFSET FETCH日期函数写法也完全不同。拿到源码先看查询引擎有没有做方言适配层参考对照如下| 数据库 | 分页写法 | 日期格式化 | JDBC 驱动 | | Oracle | OFFSET ? ROWS FETCH NEXT ? ROWS ONLY | TO_CHAR(date,YYYY-MM-DD) | ojdbc8 | | MySQL | LIMIT ?, ? | DATE_FORMAT(date,%Y-%m-%d) | mysql-connector-j | | ClickHouse | LIMIT ?, ? | formatDateTime(date,%Y-%m-%d) | clickhouse-jdbc | | 达梦 | LIMIT ?, ? | TO_CHAR(date,YYYY-MM-DD) | DmJdbcDriver |驱动 jar 也要逐一核对。企业环境里最常见的报错是No suitable driver found原因无非两个驱动没打进部署包或者 JDBC URL 前缀写错。Oracle 的 URL 前缀是jdbc:oracle:thin:达梦是jdbc:dm://ClickHouse 是jdbc:clickhouse://。这三条记清楚能省半天排查时间。另外Oracle 11g 和 12c 的驱动类名相同但 jar 不兼容混用会出现奇怪的字符集异常一个应用里只保留一份 ojdbc 版本。3. 后端源码核心模块与查询 API 的实现可视化分析平台的后端说白了就两个职责把数据库里的数据查出来把图表配置吐给前端。源码结构上常见分层是 controller 层处理 HTTP 请求service 层做业务编排mapper 层用 MyBatis 执行 SQL。下面按这个结构走一遍取数链路的每个环节。3.1 动态数据源切换下的取数链路当用户打开大屏时前端会带一组 chart_id 请求数据。后端要做的第一件事是查出每个图表对应哪个数据源然后切换到那个数据源执行配置好的 SQL。服务层的核心代码Service public class ChartServiceImpl implements ChartService { Override public ChartDataResult queryChartData(ChartDataRequest request) { ChartConfig config chartConfigMapper.selectById(request.getChartId()); DataSourceContextHolder.setDataSourceKey(config.getSourceId()); try { ListMapString, Object rows chartMapper.executeQuery(config.getQuerySql()); return transform(rows, config); } finally { DataSourceContextHolder.clear(); } } }四个关键点依次说明。selectById拿到图表的配置对象包含数据源 id、取数 SQL、图表类型。setDataSourceKey把当前线程要用的数据源 id 写进 ThreadLocal下一次从连接池拿连接时DynamicDataSource 会根据这个 key 路由到正确的库。executeQuery执行的是配置表里存的原始 SQL返回 List 包 Map 的行结构。finally里的clear()是必须的漏掉的话线程池复用线程时会串数据源最常见的就是图表数据突然变成另一张表的。Controller 层只做参数接收和响应包装RestController RequestMapping(/api/chart) public class ChartController { private final ChartService chartService; PostMapping(/data) public Result getChartData(RequestBody ChartDataRequest request) { return Result.success(chartService.queryChartData(request)); } }这里的校验逻辑必须前置。request 里的 chartId 不能是负数和超出表范围的任意数字source_id 必须存在于 ds_source 表否则会被恶意遍历出所有图表配置。很多开源的免费数据可视化大屏项目在这一层是裸奔的直接把请求参数透传给 SQL安全设计要从 controller 入口就接上。3.2 动态 SQL 的安全边界参数白名单与语句拦截可视化平台和普通 CRUD 系统最大的区别在于 SQL 是动态的、存在数据库里的、由业务人员在配置界面写的。这个特性决定了它不能走 MyBatis 的#{}预编译因为 SQL 本身是数据不是代码里的常量。安全问题因此更加敏感chart_config.query_sql一旦被写入恶意语句比如拼接了删表语句执行引擎就成了一件危险工具。实际项目里我一般做三层防护。第一层是配置界面层面的语法校验SQL 只允许 SELECT 开头不允许分号后追加语句不允许注释符--和/*。第二层是关键字黑名单拦截 INSERT、UPDATE、DELETE、DROP、TRUNCATE、ALTER以及系统函数load_file()、version。第三层是结果集限制所有查询包一层分页防止内存被打爆。private void validateQuerySql(String sql) { String trimmed sql.trim().toLowerCase(); if (!trimmed.startsWith(select)) { throw new BizException(仅允许SELECT语句); } ListString forbidden Arrays.asList( insert , delete , update , drop , truncate , alter , load_file, version ); for (String keyword : forbidden) { if (trimmed.contains(keyword)) { throw new BizException(包含非法关键字: keyword); } } }这套校验放在 service 层入口执行 SQL 前统一调用。注意黑名单匹配的是带空格的语句关键字updated_at这种字段名不会误伤。结果集限制也一样重要MyBatis 的StreamingResultHandler配合游标可以撑住百万行级别但免费数据可视化大屏通常几百条就够渲染了直接LIMIT 0, 5000更稳妥。3.3 结果集统一封装与图表数据整形数据库返回的行结构是ListMapString, Object键是字段名值是数据库原生类型直接抛给前端会导致序列化字段大小写不稳定、Date 类型被转成时间戳。后端应该在返回前统一整形private ChartDataResult transform(ListMapString, Object rows, ChartConfig config) { ChartDataResult result new ChartDataResult(); result.setChartType(config.getChartType()); result.setColumns(new ArrayList()); result.setRows(new ArrayList()); if (rows.isEmpty()) return result; // 取第一行的key作为列定义 result.setColumns(rows.get(0).keySet().stream().toList()); // 值全部转成字符串空值统一填0或空串 for (MapString, Object row : rows) { ListObject line new ArrayList(); for (String col : result.getColumns()) { Object val row.get(col); line.add(val null ? : val.toString()); } result.getRows().add(line); } return result; }columns和rows分离是专门为 ECharts 设计的前端拿到 columns 做维度字段下拉选择拿到 rows 做数据绑定。空值处理按场景区分数值型字段填 0 还是空串会影响图表显示折线图遇到 null 会断开填 0 会画出一条误导性的掉底曲线这里按图表类型传参line 图传 nullbar 图传 0。后端封装的 columns 决定前端能拿到哪些维度按图表类型做约束| 图表类型 | columns 约定 | rows 约定 | 特殊处理 | | line | 第一列是时间或维度 | 后续列是数值 | 数值转 Number空值保留 null | | bar | 第一列是分类 | 数值列 | 空值填 0 | | pie | 第一列名称第二列数值 | 两列定死 | 其他列忽略 | | map | 第一列区域名第二列数值 | 两列定死 | 区域名要跟地图 JSON 对齐 |这张表建议直接写进接口文档。前端拿到数据时不需要猜列的含义按约定取数渲染新增图表类型只需要扩展这个约定不用改整套返回结构。数据库增删改查在元数据管理界面里是标准操作但真正决定平台上限的是这套数据整形约定严谨的约定能省掉前端和后端反复联调的时间。4. 前端可视化源码与 ECharts 大屏集成前端做可视化大多数项目直接用 ECharts。源码包里前端常见两种组织方式Vue 单页应用或传统多页面加 jQuery。不管哪种核心问题都是同一个——后端返回的 columns 和 rows 数据怎么快速变成图表的 option。4.1 后端数据到 ECharts option 的映射函数拿到后端封装好的 columns 和 rows 数组后前端要做一个通用的映射函数把行数据变成 ECharts 能识别的 seriesfunction buildEchartsOption(columns, rows, chartType, dimension, metrics) { // 根据列定义找到维度列和指标列的下标 const dimIndex columns.indexOf(dimension); const metricIndexes metrics.map(col columns.indexOf(col)); const categories rows.map(row row[dimIndex]); const series metricIndexes.map((mIdx, i) ({ name: metrics[i], type: chartType pie ? pie : line, emphasis: { focus: series }, data: rows.map(row { const val Number(row[mIdx]); return isNaN(val) ? null : val; }) })); return { tooltip: { trigger: axis }, legend: { data: metrics }, xAxis: { type: category, data: categories }, yAxis: { type: value }, series }; }dimension和metrics是用户在配置界面选的字段对应 chart_config 表里的 option_json。函数先通过indexOf拿到列下标再用map抽出值。数值转换的细节在最后三行空值字符串转成 Number 会得到 NaN这里统一转成 null避免 ECharts 把无效点画成 0。实际开发中这个函数会被封装进一个图表工厂类所有图表统一走它遇到地图或仪表盘再单独扩展。这个函数直接决定了后端返回到前端渲染的效率也是二次开发改得最频繁的地方。4.2 大屏自适应布局与定时刷新免费数据可视化大屏和普通报表页最大的区别在于屏幕分辨率。大屏通常跑在拼接屏或宽屏显示器上分辨率从 1920x1080 到 7680x2160 都有。纯用百分比适配是不可靠的我一般用容器尺寸来计算function resizeChart(chartInstance) { const container chartInstance.getDom().parentElement; const rect container.getBoundingClientRect(); chartInstance.resize({ width: rect.width, height: rect.height }); }getBoundingClientRect拿的是元素实际渲染尺寸比 window.innerWidth 可靠。容器宽度变化时大屏布局重新计算每个图表模块的宽高再调用chart.resize()。注意 resize 要在 DOM 渲染完成后调用否则拿到的是 0。拼接屏场景还要处理缩放比例常见做法是设计稿按 1920 宽绘制运行时计算实际宽度和设计稿的比值图表和字体都乘上这个比例。定时刷新要跟 chart_config 里的 refresh_interval 字段联动const timers new Map(); function startAutoRefresh(chartId, chartInstance, loadData) { const config chartConfigMap.get(chartId); if (!config || !config.refresh_interval || config.refresh_interval 0) return; const timer setInterval(async () { const data await loadData(chartId); chartInstance.setOption(data, true); }, config.refresh_interval * 1000); timers.set(chartId, timer); } function stopAutoRefresh(chartId) { const timer timers.get(chartId); if (timer) { clearInterval(timer); timers.delete(chartId); } }setOption第二个参数传 true是让 ECharts 用新配置完全替换旧配置而不是合并否则切换图表类型时旧 series 会残留。定时器必须用 Map 管理页面切换或销毁组件时统一清理否则切几个页面后浏览器会挂着一堆无效的 setInterval。提示refresh_interval 太短会拖垮数据库连接池。推荐生产环境最小间隔 10 秒且大屏并发高时建议用 WebSocket 或 SSE 推送替代轮询前端只负责渲染数据由后端主动推过来。4.3 地图与热力图的 GeoJSON 加载地图在可视化大屏里是另一个高频需求。ECharts 的 map 类型需要注册 GeoJSON 数据import chinaJson from ./geo/china.json; echarts.registerMap(china, chinaJson); const option { series: [{ type: map, map: china, roam: true, data: rows.map(row ({ name: row[0], value: Number(row[1]) })) }] };地图数据的维度约定是第一列区域名称第二列数值。区域名称必须跟 GeoJSON 里的properties.name完全一致内蒙古写成内蒙古自治区就匹配不上。源码包里如果没有 geo 目录可以找精简版或官方地图数据源下载后放进前端静态目录。内网大屏环境经常没有外网访问权限把 JSON 文件打到前端包里更省心。缩放和平移用roam: true开启但大屏默认不开启防止用户误拖导致布局错位。地图注册后如果切换主题或销毁组件记得调用echarts.dispose()释放实例否则地图对象会一直占内存。5. 大屏部署验证与性能调优要点拿到源码后从建库到跑通再到优化按下面三个环节走能避开大多数发行包里的暗坑。5.1 建库初始化与启动验证清单# 1. 导入元数据库脚本 mysql -uroot -p sql/init.sql # 2. 确认表已创建 mysql -uroot -p -e USE dashboard; SHOW TABLES; # 3. 检查字符集必须为utf8mb4 mysql -uroot -p -e SELECT table_name, table_collation FROM information_schema.tables WHERE table_schemadashboard; # 4. 启动后端 java -jar dashboard-server.jar --spring.profiles.activeprod # 5. 前端构建 npm install npm run build启动后先访问健康检查接口确认后端连上了元数据库。再打开一个大屏页面看 Network 面板里图表数据接口是否 200。如果接口报 500优先翻后端的异常日志最常见的两类错误数据源连接超时、SQL 方言不兼容。连接超时检查数据库防火墙和账号权限方言不兼容按前面表格里的对照改查询 SQL 函数。5.2 慢查询定位与索引优化技巧大屏卡顿十有八九不是前端渲染慢是查询慢。开启 MySQL 慢查询日志定位SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 2;慢查询日志里记录的每一条 SQL都用EXPLAIN看执行计划EXPLAIN SELECT province, SUM(amount) FROM sales WHERE create_time 2024-01-01 GROUP BY province;聚合大屏的常见问题有三个查询没有走索引、临时表过大、返回了多余的列。优化手法按收益从高到低排列给 WHERE 和 GROUP BY 字段建联合索引把重复子查询改成 JOINSELECT 只取需要的字段。如果表数据量到了百万级还可以考虑把统计结果落到独立的汇总表大屏直接查汇总结果牺牲一点实时性换流畅交互。5.3 二次开发扩展新增图表类型的边界处理在源码基础上新增一种图表类型不是改前端就完事。后端 option_json 要能承载新类型的全部配置数据库表结构可能需要加字段。实践中常见做法是扩展 chart_type 枚举然后在前端图表工厂里加一个分支。地图、仪表盘、桑基图都属于配置密集型的图表字段级校验要放在后端防止前端被塞入非法的 option。扩展边界要守住通用能力进框架特殊需求进配置不要为单一大屏把框架改死。最后说一个绝大多数发行版都踩过的坑时区。MySQL 默认时区跟应用服务器不一致时日期字段会差 8 个小时柱状图的日期轴会出现错位。在建会话时显式执行SET time_zone 08:00或者在 JDBC URL 上加serverTimezoneAsia/Shanghai一行参数解决别在代码里手工给时间加小时数。本文还有配套的精品资源点击获取