大屏做得越炫越好？错！数据实时性和展示性能，才是真正决定项目成败的关键
作者：Echo_Wish
很多公司第一次做数据大屏，都有一个共同的梦想。
领导一句话：
"我要一个像电影《钢铁侠》一样的大屏！"
于是研发开始疯狂堆特效。
各种地图飞线、粒子动画、数字翻牌、实时滚动、炫酷图表……
结果上线第一天。
CPU 100%。
浏览器直接卡成 PPT。
数据刷新越来越慢，领导站在大屏前看了半天，突然问了一句：
"为什么仓库都发货了，大屏还是十分钟前的数据？"
这一句话，比任何 Bug 都扎心。
其实，大屏项目真正难的，从来不是画图，而是数据实时性和展示性能之间的平衡。
今天，我就结合这些年做 MES、BI、大数据平台项目的一些经验，聊聊这个话题。
一、为什么大屏越实时，反而越容易崩？
很多人认为：
实时 = 每秒刷新。
其实这是一个非常大的误区。
举个例子。
假设一个工厂有：
- 500 台设备
- 每秒上传一次数据
- 每条数据 2KB
那么一分钟的数据量就是：
500 × 60 × 2KB
≈60MB
一天就是：
60MB × 60 × 24
≈84GB
如果你的大屏：
每秒查询一次数据库。
后台：
100 个大屏
×
每秒一次 SQL
=
100QPS
如果每个 SQL 都要统计当天数据……
数据库基本可以准备报警了。
所以。
很多所谓"实时"，其实只是：
不断重复查询数据库。
数据库根本不是这样设计的。
二、真正的实时，不等于每秒查数据库
很多成熟的大数据平台，都遵循一个原则：
数据库负责存储。缓存负责查询。
而不是：
浏览器
│
▼
MySQL
正确架构应该是：
浏览器
│
WebSocket
│
实时缓存(Redis)
│
Kafka
│
实时计算
│
数据库
什么意思？
数据库的数据负责落盘。
Redis 保存最新一分钟的数据。
Kafka 负责消息。
真正的大屏，看到的是：
Redis。
不是 MySQL。
三、千万不要让浏览器自己轮询
很多新人都会这样写。
setInterval(() => {
fetch("/api/dashboard");
},1000);
一秒请求一次。
如果：
100 个客户端。
就是：
100 × 1 次/s
=
100QPS
如果：
1000 个客户端。
就是：
1000QPS。
而实际上：
很多时候数据一分钟都没变化。
却一直在查。
这是非常浪费资源的。
四、WebSocket，才是真正适合大屏的方案
如果数据发生变化。
服务器主动推送。
没有变化。
什么都不用发。
例如：
const ws = new WebSocket("ws://server/dashboard");
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
updateChart(data);
};
后台：
while True:
latest = redis.get("dashboard")
websocket.send(latest)
time.sleep(1)
很多人看到这里会说：
"这不还是一秒一次吗？"
不是。
真正成熟的系统通常会这样：
Kafka 收到消息
↓
更新 Redis
↓
通知 WebSocket
↓
推送浏览器
没有消息。
就没有推送。
真正做到：
按需更新。
五、不是所有数据都需要实时
这是很多项目最大的误区。
例如：
生产数量。
确实需要实时。
但是：
人员信息。
昨天的数据。
本月统计。
去年同比。
真的需要每秒刷新吗？
完全没必要。
我一般会这样分类。
| 数据类型 | 建议刷新频率 |
|---|---|
| 设备状态 | 1 秒 |
| 告警信息 | 实时推送 |
| 今日产量 | 5 秒 |
| 小时统计 | 1 分钟 |
| 日报统计 | 10 分钟 |
| 月报分析 | 手动刷新 |
很多项目。
就是所有接口：
setInterval(1000)
结果：
数据库天天加班。
CPU 天天报警。
六、图表性能，比数据库还容易被忽略
很多人优化数据库。
优化 SQL。
却忘了一件事。
真正卡顿的。
很多时候是浏览器。
举个例子。
折线图。
如果一次画：
100000
个点。
无论是：
- ECharts
- AntV
- HighCharts
都会开始掉帧。
因为浏览器要：
计算坐标
↓
布局
↓
绘制 Canvas
↓
动画
↓
重绘
点越多。
浏览器越吃力。
七、大屏展示，不需要所有数据
举个例子。
数据库：
一分钟采集：
60000
条数据。
领导真正需要看什么？
其实只是：
一分钟平均值。
例如：
原始数据：
21
22
21
20
21
22
...
展示：
一分钟平均：
21.2℃
或者：
最大值
最小值
平均值
而不是：
把六万条数据全部画出来。
八、前端也需要做"数据减肥"
很多团队认为：
后台已经很快。
前端随便画。
其实并不是。
例如：
后台返回：
[
{
"device":"A001",
"temperature":25.1,
"pressure":1.2,
"humidity":60,
"createTime":"..."
}
]
如果：
10000 条。
JSON 就非常大。
其实：
大屏真正需要：
{
"temperature":25.1
}
网络传输立即减少很多。
另外，如果确实需要大量数据，可以结合分页、增量更新或者二进制协议（如 Protocol Buffers）来进一步降低带宽占用，而不是每次都把完整数据重新发送。
九、真正优秀的大屏，都遵循"增量更新"
很多人更新图表。
都是：
chart.setOption(option, true);
每秒：
重新渲染。
实际上。
很多图表只新增一个点。
完全可以：
const option = chart.getOption();
option.series[0].data.push(newPoint);
// 删除最早的数据，保持固定窗口
if (option.series[0].data.length > 60) {
option.series[0].data.shift();
}
chart.setOption(option, false);
这样。
浏览器不用：
重新布局。
重新计算。
性能能提升很多。
很多实时监控系统，就是采用这种"滑动窗口"模式，只保留最近 1 分钟、5 分钟或者 1 小时的数据，既保证实时性，又避免图表无限增长。
十、真正的大屏优化，其实是在做"取舍"
做了这么多年数据平台，我越来越觉得：
大屏开发，本质上不是技术炫技，而是资源管理。
很多团队喜欢追求：
- 数据越实时越好；
- 图表越多越好；
- 动画越炫越好；
- 页面越复杂越好。
但现实却是：
- 每提高一点实时性，后台资源都会增加；
- 每增加一个动态图表，浏览器渲染压力都会上升；
- 每增加一次全量刷新，网络带宽和数据库压力都会被放大。
真正成熟的大屏，不会追求"所有数据都实时"，而是根据业务价值划分刷新策略；不会把所有细节都展示出来，而是让关键指标第一眼就能被发现；也不会让数据库承担所有查询，而是充分利用缓存、消息队列和增量更新，把压力分散到系统各层。
好的大屏，不是刷新得最快，而是让用户觉得"数据一直都是新的"；不是图表最多，而是关键指标最容易看懂；不是性能跑满服务器，而是用最少的资源创造最大的业务价值。
很多时候，领导真正关心的并不是页面有多炫，而是站在大屏前的那几秒钟，能不能快速发现异常、做出决策。
所以，下次再接到一个大屏项目时，不妨先问自己三个问题：
这份数据真的需要实时吗？这张图真的需要展示全部数据吗？这一次刷新，真的值得消耗这么多资源吗？
当你开始思考这些问题时，你设计的大屏，就已经从"好看"迈向了"好用"，也真正具备了企业级数据可视化系统应有的价值。
