做可视化大屏这几年我最大的感受是真正让项目翻车的从来不是图表不好看而是数据对不上。我见过太多团队在立项时把大屏当作前端展示工程来做设计师调了三轮配色前端换了三版动效结果到了联调阶段业务方一句这个数和昨天晨会报表对不上就能让整个项目停滞两周。后来我慢慢想明白一个道理大屏看得见的这部分其实是最简单的那部分真正决定项目生死的全在看不见的地方——数据治理尤其是数据互通。这篇文章想跟正在做大屏或准备做大屏的朋友聊透这件事。不管你是前端、数据工程师、项目经理还是业务方只要你跟大屏沾边这篇文章里说的坑你大概率会踩到而且越早看到越好。1. 先泼盆冷水把大屏做成皮肤工程翻车只是时间问题1.1 为什么说数据呈现是最简单的一环先别急着反驳。我承认做一个视觉效果惊艳的大屏并不容易但这里的容易是相对的——相对数据治理而言。数据呈现这一层说白了就是把数据画出来。它的边界非常清晰输入是结构化的数据输出是图表、地图、指标卡、轮播表格。这个过程里所有的变量都是可控的颜色、布局、动画、交互都有现成的最佳实践和组件库可以参考。工具链也已经卷到不能再卷了。前端有ECharts、AntV G2、Highcharts可视化大屏编辑器类产品也一大堆拖拖拽拽就能搭出一块屏幕。别误会我不是说这些工具不好用恰恰相反正因为它们太好用了所以把大屏做出来这件事的门槛被拉到了极低。任何一个有点前端基础的人花两周时间都能拼出一个看起来像模像样的demo。我见过一个最夸张的例子某个供应商拿着一个纯前端写的大屏demo去投标数据全是写死的假数据动画倒是做得很炫酷。客户一看很满意当场就定了。结果真正对接数据的时候发现业务系统里根本没有他们承诺的那些数据字段就算有质量也惨不忍睹。这就是问题的核心大屏的视觉呈现是确定性工作而数据治理是不确定性工作。做视觉你面对的是像素和坐标做数据治理你面对的是一个个活生生的业务系统、一堆说不清的口径、一屋子各执一词的业务方。1.2 大屏的本质是决策工具不是装饰品很多团队在做大屏的时候把精力全扑在好看上这其实是本末倒置。大屏的核心价值是辅助决策——让管理层在30秒内掌握全局状态发现问题、定位风险、指导行动。它本质上是一个信息压缩和呈现系统而不是一个室内装修项目。想明白这一点你就会意识到数据错了大屏上的数字再大再漂亮也只是把错误放大了给领导看。你没看错是放大。一块3x6米的LED大屏一个错误的数字在上面挂一天全公司路过的人都看得见。那个画面光是想想就够让人失眠的。所以我一直跟团队强调一句话大屏项目里数据是1视觉是后面的0。没有前面那个1后面加越多0越尴尬。这也是我这篇文章为什么一直念叨数据治理的原因。不是视觉不重要而是顺序要搞对先把数据这件事整明白了再谈怎么把它画得好看。2. 数据质量的账源头脏了大屏再好看也是白搭2.1 大屏上最常见的四类数据质量问题我做了十几个大屏项目涵盖制造业、园区、政务、环保这些领域发现数据质量问题来来去去就那么几类真的很典型。你要是做大屏至少会遇到其中两三个。第一类是数据缺失。这在大屏上最常见表现形式就是图表上突然出现一个大空洞或者指标卡上显示--。啥叫缺失就是该有的数据没采集到。比如某个传感器断连了一天或者某个业务系统当机了半小时。这种情况在实时性要求高的大屏上尤其致命——领导正在看大屏你指标卡上一个大0挂在那边场面非常难看。第二类是数据重复。同一条数据被算了两次导致总计数虚高。这通常是因为数据从多个源头汇入时没有做去重。比如一个订单既在ERP里有一份又在数据仓库里被同步了一份你求和的时候如果没去重数字直接翻倍。第三类是口径不一致。这是最要命的。同样一个销售额财务部认为是已开票的金额运营部认为是下单但未退款的全部金额两个数差了十万八千里。大屏上到底该放哪个如果你不去管口径这件事前端拿到什么就放什么那就是在给自己埋雷。第四类是数据滞后或时间错乱。业务系统的数据是T1更新的大屏却按小时刷新出来的数字自然对不上。又或者不同系统用的时区不一样同一条订单A系统记录的是北京时间B系统记录的是UTC时间放一起比较的时候你会发现数据莫名其妙地穿越了。大多数时候大屏项目的数据治理工作就是在跟这四类问题做持久战。别指望上线前花两周清洗一遍就一劳永逸没那回事。数据是每天在新增的脏数据也是每天在产生的只不过有时候多有时候少而已。2.2 数据治理不是一次打扫卫生而是车轮战我之前看到过一张数据治理车轮图觉得特别形象。它把治理过程画成一个不断循环的轮子数据盘点 → 问题发现 → 标准制定 → 执行清洗 → 效果评估 → 回到盘点一轮完了接着下一轮永无止境。这个图放在大屏项目里一点不夸张。你上线第一天把数据整得干干净净第三天可能又脏了。业务系统改了字段、运维调整了表结构、业务方手工导了一版Excel覆盖了数据随便哪件事都能让你的大屏数据重新变得不可信。所以我对大屏项目的定位一直是它不是一次性交付而是一个持续运营的系统。数据治理不是上线前的准备工作而是大屏上线后长期存在的一项日常工作。你需要在项目启动的时候就考虑好谁来盯着数据质量数据出问题了怎么发现发现了找谁修这些问题不提前想清楚大屏上线就是噩梦的开始。2.3 用治理流程把脏数据挡在图表之前我自己在项目里走的流程大概是这样的分享出来给大家参考第一步是元数据摸底。把大屏需要用到的每一个数据字段列出来搞清楚它来自哪个系统、哪个表、哪个字段、谁在维护、更新频率是多少。这步看着枯燥但它是一切治理的基础。没有这份清单后面出了问题只能瞎摸。第二步是标准定义。明确每个指标的定义、单位、聚合方式。比如销售额到底含不含税在线设备数包含备用设备吗今日投诉量是按提交时间算还是按处理时间算把这些写清楚形成一份指标字典各环节都按这个字典来。第三步是质量规则配置。针对每个关键字段设定质量门槛空值率不能超过多少、数值波动不能超过多少、延迟不能超过多少。一旦超出阈值就触发告警。第四步是持续性监控。每天自动跑一批数据校验任务有问题立即通知相关责任人。这步在运维阶段的价值怎么强调都不过分。这套流程不是每个项目都要全部做一遍但它给了你一个框架——你至少要知道当前大屏的数据处在哪个阶段还缺哪一步。3. 数据互通比数据有更难的是数据能对在一起3.1 三个真实的互通断点如果说数据质量是大屏项目里绕不开的坎那数据互通就是坎中坎。我见过太多项目单看每一个数据源都还行但一旦要把两个系统的数据放同一块大屏上对比就各种对不上。断点一不同系统的ID对不上。A系统里管这个客户叫客户编号10086B系统里同一个客户的ID是SEQ-2023-001C系统更狠直接用的手机号。你把三个系统的数据拉出来往大屏上一摆业务方想看到的是一件事在不同环节的状态结果你给他呈现的是三列互不相认的数据他只能拿Excel自己去匹配这大屏的意义就没了。断点二不同系统的统计时间基准不一样。举一个我们做制造业大屏时遇到的例子——工厂产量。MES系统制造执行系统按班次统计产量一个班8小时今天可能有三个班次的数据。ERP系统呢按自然日统计。财务想看的报表呢又按工作中心来汇总。三个系统都合理但它们的时间切片方式不同数字就永远无法对齐。你问他今天产量多少他得先反问你是按哪个口径哪个时段算的。断点三系统之间根本没有自动化的数据通道。大屏要的数据在ERP里但ERP没开放接口。怎么办人工导出Excel跑到内网的另一台电脑上再通过上传工具导到数据中间库。这个过程每天都要做而且经常忘了做。你大屏上的数据永远滞后一天不说还时不时断供。我见过最极端的情况是因为负责导数的同事休年假了大屏数据整整停更了一周。这三个断点每一个都是做数据互通时必然要面对的具体问题。它们不讲任何情面不会因为你的大屏做得好看就自动消失。3.2 垂直场景里的互通难题从森林防火到污水处理我平时关注了不少垂直场景的大屏案例像森林防火可视化大屏、污水处理可视化大屏这些项目的数据互通难度比通用的大屏还要高一个层级。森林防火大屏看着是地图上一堆热力图和摄像头图标但背后涉及的数据源极其分散气象部门的风向风力数据、卫星热点监测数据、地面摄像头识别数据、消防队伍的车辆和人员定位、防火物资库存数据。这些数据来自完全不同的机构和系统有的在省级平台有的在市级有的是部队系统有的还是Excel。要把它们汇聚到一块大屏上还要保证同一时刻显示的气象、火点和救援力量在空间上自洽这个数据互通工程量远超前端的展示工作量。污水处理大屏更典型。一个污水厂的大屏要同时展示进水水质、出水水质、流量、设备运行状态、能耗、药耗。进水数据来自在线监测仪表出水数据可能来自化验室的人工录入能耗数据在电力监控系统里设备状态又在PLC系统里。这些系统的数据格式、刷新频率、校准周期完全不同你大屏上显示的COD值到底是仪表实时读数还是实验室国标检测结果两者能差出一倍。不把源理清楚大屏就是让领导看一个矛盾的现场。这些场景告诉我们一个残酷的事实数据互通的复杂度和业务系统数量成正比和行业信息化水平成反比。信息化搞得越久、系统越多的单位数据互通越困难因为历史包袱太重了。3.3 互通这件事底层就三件事被各种互通问题折磨了几年之后我总结出数据互通的本质就三个词标识统一、语义统一、时间统一。标识统一就是同一件事物在系统A和系统B里有相同的ID或者可以通过映射规则互相转换。这需要建立主数据管理把客户、产品、设备、人员的编码统一起来。语义统一就是同一个指标在系统A和系统B里含义一致。这需要指标字典和口径说明再由技术手段做转换。时间统一就是不同系统的数据能在同一个时间坐标系里对齐。要么统一用UTC要么统一换算到北京时间要么对齐统计时段要么做增量校正。这三个统一没一个靠前端能解决。它们需要业务方拍板、数据工程师执行、系统厂商配合是一个从上到下的协作过程。所以每次有人问我做个大屏要多久我第一句不是回答周期而是反问他们数据从哪来、能不能直接对接、口径有没有争议。这三个问题问清楚了大屏的工期基本上就能估个八九不离十了。4. 我落地大屏数据治理的一条完整路线前面说了那么多问题和原理下面来点实操的东西。我把自己做过的项目里觉得跑得通、也愿意推荐给别人的一条路线写出来你可以把它当作一份参考清单不一定每一步都照搬但核心顺序别打乱。4.1 先盘家底把数据资产摸清楚不管大屏的视觉设计先做了多少版本我的建议永远是第一步先做数据资产盘点不做完不许碰视觉效果。盘什么盘清楚以下五件事大屏需要展示哪些指标跟业务方把需求里的指标一个一个对齐每个指标对应的原始数据存在哪个系统ERP、MES、Excel、手工填报列清楚即可数据通过什么方式获取接口调用、数据库直连、文件导入不同方式的技术成本和时效性完全不同数据质量目前什么情况抽样看一下空值率、重复率、异常值比例数据的责任人和维护频率是谁没有责任人的数据源迟早会出问题这个盘点过程产出两份文档一份是《数据源清单》另一份是《指标口径字典》。这两份文档建议直接跟UI稿一样作为交付物写进合同里。没有它们后期扯皮的概率极高。4.2 建指标体系用口径文档消除各说各话数据源盘完之后必须做的一步就是把指标口径坐实。具体做法是把大屏上每一个要展示的指标做成一张卡片卡片上写清楚指标名称、指标定义、计算公式、数据来源、更新频率、单位、责任人、备注。然后拿着这套卡片逐条去跟业务方确认一条一条过直到他们签字确认。这个过程很痛苦因为业务方内部都未必统一口径。但恰恰是这种痛苦才有价值——你在上线前把矛盾暴露出来总好过上线后被领导当众质疑。我记得做某园区大屏时入驻企业数这个指标就扯了两天。招商部门说按工商注册地址算运营部门说按实际办公人数算两边数字差了30%。最后怎么解决的大屏上放了两个指标卡入驻企业注册口径和入驻企业实际办公口径下面用小字标清楚来源。领导想看的都有谁也不得罪。4.3 搭同步链路批处理还是API取决于时效要求口径定了之后就要解决数据怎么从源系统到大屏的问题。这里有一个关键决策数据的时效要求是什么是实时、一小时刷新一次还是每天同步一次如果只要求T1展示比如昨天的产量、前天的库存那就走批处理每天晚上从源库抽数到中间库白天大屏直接查中间库即可。好处是稳定对业务系统零侵入缺点是时效差。如果要求秒级或分钟级比如设备状态、实时报警就得走API或消息队列但这样做会占源系统的资源也可能遇上接口被调爆的情况。我的习惯是优先考虑中间库方案业务数据先同步到一个独立的数据库中大屏只跟中间库打交道。这样就算大屏的SQL写得不怎么样或者刷新频率太高也不会把业务系统拖垮。对源系统是个保护对后期运维也省心。4.4 上校验与告警让脏数据现出原形数据链路搭通之后我强烈建议别急着接大屏先做一件事数据校验与告警。具体做法是在数据同步完成后自动执行一批校验逻辑今天同步的行数和昨天比是否合理比如突然少了90%大概率是抽取失败关键指标的数值波动是否超限比如某指标突然涨了10倍可能是源系统改口径了数据的时间戳是否是最新时间比如过了凌晨1点数据还停在昨天白天说明同步链路挂了一旦校验不过立即通知相关人员发企业微信、钉钉、短信都行。关键是让数据异常在业务方看到大屏之前就被拦截下来。我知道有些项目觉得这是在浪费工时但如果你经历过大屏在领导面前显示了个大零蛋的社死现场你会回来感谢这条建议的。4.5 大屏只消费治理后的数据最后一步才是前端接入。到了这一步大屏的技术含量反而变得普通了——查中间库、渲染图表、做动效。这里有一个原则要把握好大屏的前端代码里永远不要写复杂的取数逻辑和聚合逻辑。所有计算、清洗、合并都在数据层完成大屏只负责查出来、画出来。我见过有些项目把一堆sum、group by、join写在前端代码里当时看着没事后面数据量一上来页面直接卡死而且没人敢动那坨代码因为一改就崩。记住数据层干数据的活展示层干展示的活。职责清晰项目才扛得住后续迭代。5. 做过十几个大屏后我踩过的那些数据坑下面这段算是我压箱底的内容了都是真金白银换来的教训。每一个坑都是在一个个不眠之夜之后才爬出来的。5.1 口径之争财务和运营谁说了算有一次做集团经营大屏财务给大屏的接口叫营业收入运营也给了一个接口叫营业收入两个数字在测试环境上差了1200万。查了半天才明白财务的营业收入是剔除退货、含税金额运营的营业收入是含预收定金、不含税金额。两边都觉得自己是标准口径谁都不让谁。最后怎么解的层层上报到集团分管副总让他拍板大屏上放财务口径为主数字运营口径作为辅助指标显示并特别标注口径差异请参考指标字典。在架子上挂了两天终于不吵了。这个坑的教训是口径之争本质上是权力之争技术解决不了只有业务一把手能拍板。你作为项目方别试图当裁判你只负责把分歧摆在桌面上把决策权交给该交的人。5.2 昨日到底是哪一天时区和统计时段的问题做全国性业务的大屏如果你以为今天就是北京时间今天那大概率要出事。我们做过一个大屏数据源分布在两个机房一个在东八区一个在UTC时区。当时所有日期字段都从源系统直接取出没做转换结果每天凌晨0点到8点之间大屏上的今日销售额会出现一段锐减。排查了整整两天最后发现是UTC时区的那个数据源它的今天比北京时间晚了8小时——北京时间凌晨1点UTC那边还是昨天。再有一个坑是统计日切问题。有些业务系统每天的日切点设在凌晨2点有些设在晚上12点有些设在早上6点。你大屏上显示今日数据的时候到底从哪一刻开始算今日不同系统的日切点不一致数字就对不齐。现在我的做法是在指标字典里强制规定两个字段——时区基准和日切时间。所有跨系统的指标都按统一的时区和日切规则来做时间对齐不允许各算各的。5.3 刷新风暴大屏上的数字把数据库打爆了大屏上线后业务方提了一个合理需求我们要实时刷新5秒一次。前端痛快地接了给大屏配置了一个5秒轮询的定时器前端从接口数据一条接一条地拉。结果不到半天后端数据库CPU直接飙到100%源系统的IT打电话过来骂人。这个坑的本质在于大屏的数字一晃而过没人盯着看但数据库的负担是实实在在的。后来我们把方案改成了主动推送前端被动接收后端每10秒推一次增量数据前端拿到就更新拿不到就继续展示旧数据。数据库的压力几乎归零而大屏的实时性观感并没有下降——反正人的眼睛根本分不清5秒和10秒的差别。如果你还在用前端轮询接口的老办法做实时大屏赶紧改。5.4 缓存里的旧数据你看到的是昨天不是现在还有一个特别隐蔽的坑发生在数据中台架构下。大屏接了一个数据服务API这个API本身是有缓存的TTL设了30分钟。也就是说大屏上看到的数据其实是30分钟之前的数据。你盯着大屏怎么看都觉得实时其实它根本没实时过。这个本身并不可怕可怕的是没人知道有这层缓存存在。有次业务方拿大屏上的数字跟实际业务系统核对发现对不上立即群邮件投诉大屏数据不准。查了半天罪魁祸首就是中间那层静默的缓存。教训是数据链路中每一个环节都要把数据更新机制写清楚。同样一张大屏上的数字谁是秒级、谁是分钟级、谁是T1必须在数据字典里标注明白否则没人知道这个数字背后经历了什么。6. 最后几句大实话写到这里该讲的原理和实操都差不多了再分享几个我个人的心得体会算是一些不为钱赚的建议吧。第一做一个大屏宁可花70%的精力在数据上也别花70%精力在视觉上。视觉是锦上添花数据是雪中送炭。数据不好视觉再好也没用数据好了视觉朴素一点领导照样愿意开。第二数据治理这事越早启动越好。别等大屏开发到一半才去盘点数据源更别等上线后再补数据质量。项目一开始就把数据治理的工建起来后面才不会被动。第三如果团队只能招一个人招数据工程师别招另一个视觉设计师。大屏的视觉在一手可数的几个大屏可视化编辑器加持下已经是标准的工程活管理多源数据互通的水平才是决定项目生死的天花板。最后分享一句我常跟客户说的话大屏系统里任何一个数字你往上能追到它的出处往下能追到它的计算过程这个系统才敢叫可信。不能追根溯源的大屏好看也只是一块高级显示屏而不是决策工具。希望正在读这篇文章的你能在大屏这条路上少踩几个坑多省几根头发。