数据可视化从零实战：Gemini 3.5 Flash搭建运营大屏系统
一、项目背景与选型考量
运营团队每周一上午需手动拉取数据、制作图表并整理为Excel报表，整个过程耗时两三个小时。上个月终于无法容忍，决定建设一套实时数据大屏，部署在办公室电视墙，支持自动刷新与交互式钻取。
横向对比多款大模型后，最终选定 Gemini 3.5 Flash 作为主力开发工具。核心考量两点：284 token/s 的生成速率在批量生成图表配置和SQL查询时几乎秒级响应，低于 GPT-5.5 一半的单价使频繁迭代调试无预算压力。以下为完整技术实现。
二、架构设计：四层分离
大屏架构采用四层分离设计，各层独立伸缩、互不干扰：
| 层级 | 职责 | 技术选型 |
|---|---|---|
| 数据层 | 原始数据存储与查询 | MySQL + Redis 缓存 |
| 服务层 | 数据聚合运算与接口封装 | FastAPI + SQLAlchemy 2.0 |
| 接口层 | 实时推送与轮询降级 | WebSocket + RESTful |
| 展示层 | 图表渲染与交互 | ECharts + React |
核心设计决策为读写分离加预聚合。原始订单表每日新增数十万行数据，直接查询会导致大屏加载延迟。Gemini 3.5 Flash 建议使用 Redis 缓存预聚合结果，每分钟刷新一次，同时保留最近一天内的分钟级明细数据用于实时趋势图。
三、SQL 与图表配置的双线加速
大屏开发中最耗时的两个环节：编写多表联查的聚合 SQL，以及调试 ECharts 的数十个配置项。Gemini 3.5 Flash 在这两方面的效率提升最为显著。
将完整的数据库 Schema 描述清晰后，它能直接生成带窗口函数和 GROUP BY 的复杂查询，标注索引建议，并生成完整的前后端对接代码：
@app.get("/api/realtime-sales")
async def realtime_sales(minutes: int = 60):
cache_key = f"sales:{minutes}"
cached = await redis.get(cache_key)
if cached: return json.loads(cached)
result = await db.fetch_all("""
SELECT category, SUM(amount) AS total,
COUNT(DISTINCT user_id) AS buyers
FROM orders WHERE created_at >= NOW() - INTERVAL :mins MINUTE
GROUP BY category ORDER BY total DESC
""", {"mins": minutes})
data = [dict(r) for r in result]
await redis.set(cache_key, json.dumps(data), ex=60)
return data图表配置方面，描述清楚数据结构和展示需求后，几分钟即可获得完整的 ECharts 配置——双 Y 轴叠加销售额与订单量、异常值自动标红、深色背景适配大屏展示。过去手动对照文档调整这些配置至少需要半小时。
四、实时推送与性能优化
实时推送采用 WebSocket，核心逻辑为服务端定时查询缓存推送最新数据，前端监听 message 事件动态更新图表。需处理两个关键问题：心跳检测防止长连接断开，以及动态调整推送频率降低服务端压力。
性能优化方面，Gemini 3.5 Flash 主动执行了几项操作：自动为高频查询字段建立复合索引，标注需要缓存处理的接口，以及给 WebSocket 推送添加防抖机制——数据无变化时自动延长推送间隔。
五、关键踩坑记录
1. WebSocket 连接泄漏。大屏长时间运行后连接数只增不减，排查发现心跳检测后未关闭过期连接。Gemini 3.5 Flash 建议采用心跳超时一定时长主动断开、重连走新通道的方案修复。
2. 大屏分辨率适配。办公室电视墙分辨率与开发机完全不同，导致图表渲染变形。自动添加 ECharts 的 resize 监听，配合 CSS 的 rem 单位实现自适应。
3. 缓存策略分层设计。高频指标缓存时间短，中频指标缓存时间中等，低频指标走异步任务。Gemini 3.5 Flash 建议按数据刷新频率分层设计缓存，避免内存浪费。
六、总结
Gemini 3.5 Flash 在本项目中承担了大部分体力工作——SQL 编写、图表配置、WebSocket 对接。其速度优势在批量生成和频繁迭代中发挥最充分。但核心架构设计、缓存策略的最终决策、上线前的全量压测仍需人工把关。
AI 负责“写出来”，人负责“写对了”。这一分工在数据可视化开发中同样适用。省下的时间，可以投入真正需要判断力的领域——数据洞察与交互设计，而非反复调试 ECharts 参数。