广电大数据可视化：机顶盒回传、收视指标与ECharts大屏

大屏上的点播曲线在晚上八点整毫无征兆地掉了下去，业务群里的消息一条接一条弹出来："是不是系统挂了？""昨天这个时候还是峰值。"我打开后台，先看数据链路，再看前端——数据可视化这东西，最怕的不是画不出来，而是画出来了、还挺好看，但它是错的。广电这一行的数据可视化尤其如此：数据源分散在机顶盒、EPG、点播系统、宽带认证、客服工单里，口径各说各话，样本还不是全量。把广电大数据做成一块能被人信任的看板，难点从来不在配色和动效，而在链路和口径。

这篇内容主要围绕广电行业的大数据可视化落地来讲，包括机顶盒回传数据的真实形态、收视指标的清洗建模、四类典型看板的需求拆解、ECharts 大屏的工程化处理，以及上线之后才会暴露的坑。适合正在做广电、运营商、IPTV 或者大屏可视化项目的同学参考，也适合刚接手数据看板、被业务方追着问"这个数字怎么来的"的开发者。下面这些都是我在实际项目里踩出来的东西，不是文档里抄的。

1. 广电的数据底子：机顶盒回传链路到底长什么样

1.1 一条换台日志走过的四段路

很多人以为广电的数据是"实时"的，其实绝大多数机顶盒的回传是准实时，甚至是准准实时。用户按下遥控器换台那一刻，事件先在机顶盒本地落盘，攒够一批（或者等到心跳周期）再通过回传通道上行，进入采集网关，落到消息队列，然后才进数仓。这四段路里，每一段都会引入延迟。

第一段是本地缓存。机顶盒的 CPU 和内存都很紧张，很多型号是"攒够 N 条或者隔 M 分钟上报一次"，M 通常是 5 到 30 分钟。也就是说，你在晚上八点看到的一条换台记录，事件真实发生时间可能是七点四十。

第二段是回传通道。老一些的机顶盒走的是数据广播通道或者私有协议，新一些的走 HTTP 上报。通道拥塞的时候会出现批量补传，同一批日志的时间戳跨度很大。

第三段是采集网关。网关做协议解析、字段映射、基础过滤，慢查询、超时重试、重复投递都发生在这里。这地方如果没做幂等，重复数据会直接污染上层。

第四段是入仓。消息队列到数仓一般是 Flink 或者 Spark Streaming 消费，分钟级微批。真正的看板刷新周期，取决于客户能接受多长的延迟，以及链路能不能扛住。

我一般会在设计阶段就把这条链路画清楚，明确每个环节的延迟量级，然后告诉业务方："这块看板是 T+1 的，那块是 5 分钟延迟的。"说清楚比事后解释强一万倍。

1.2 机顶盒数据最会骗人的三个地方

第一是时间戳。机顶盒的本地时钟漂移是常态，尤其是那些长时间不断电、也没有做过 NTP 校时的老盒子，一天偏几分钟很正常，极端情况偏几十分钟。如果你直接拿事件里的时间戳做分钟级聚合，收视曲线会出现莫名的错位和毛刺。我的做法是同时保留"事件时间"和"服务端接收时间"，分钟级指标优先用服务端接收时间做兜底校准，事件时间只用于会话和顺序判断。

第二是重复上报。断网重连之后，机顶盒会把缓存里的历史记录重新吐一遍。如果不做去重，某天某个片区的数据量会莫名其妙翻倍。去重的键一般是设备 ID + 事件类型 + 事件时间 + 内容 ID 的组合哈希，配合布隆过滤器或者数仓侧的 row_number 去重。

第三是样本偏差。回传的机顶盒不是全量机顶盒，断网用户、老旧型号、关机用户都不回传。更麻烦的是，不同片区的回传率差异很大，有的片区能到 80%，有的只有 40%。如果直接拿回传数据当全量算渗透率，结果会系统性偏低。

1.3 机顶盒之外，还有哪些数据源值得接进看板

只盯机顶盒是做不出好看板的。下面这张表是我在项目里常见的几类数据源和它们的用途：

这些数据源在设备标识、时间基准、区域编码上基本都不一致，能不能打通，决定了你的看板是"数据陈列"还是"业务工具"。我通常会在项目早期先做一版主数据对齐，把区域编码、频道编码、时间基准三件事统一，后面所有指标都建立在这上面。

2. 可视化之前先统一口径：收视指标的清洗与建模实操

2.1 我常用的 ODS 到 ADS 四层结构

分层不是为了好看，是为了让口径可追溯。业务方问"这个收视率怎么来的"，你能一层一层往下指。我的习惯是四层：

• ODS 层：原始回传日志，几乎不做加工，只做去重和分区。保留原始字段，方便事后回溯。
• DWD 层：清洗后的行为明细。补全设备维表、频道维表、区域维表，过滤测试设备和异常数据。
• DWS 层：主题汇总。会话表、分钟级频道收视表、内容消费表、网络质量表。
• ADS 层：面向看板的指标宽表，一行就是一个看板卡片需要的数据。

这套结构的好处是，当某个指标口径要改，你只需要动 DWS 或 ADS 的生成逻辑，ODS 和 DWD 不用重建。广电的行为数据量很大，一个中等规模的城市，一天的机顶盒事件量在千万到亿级，重建一次 DWD 的成本不低。

流式部分我一般用 Flink 做分钟级窗口。核心逻辑是把换台事件按设备分组，做会话切割，再按分钟切片落到频道上。这里有个细节：跨分钟的会话要按时间比例分摊到各个分钟，否则分钟级 UV 会忽高忽低。

2.2 会话切割与停留时长：最容易被忽略的口径细节

收视时长怎么算？最粗暴的做法是用"下一次换台时间减这一次换台时间"，听起来合理，实际上问题很多。用户切台切得快，几十秒就换走，这些碎片时长全算进去，最后的结果会虚高，而且不同频道的对比会失真。

我的做法是设一个最小有效停留阈值，通常是 30 秒。停留时长不足 30 秒的切片不计入收视时长，但会记录在行为明细里，用于分析"随手换台"这个行为本身。这个阈值不是拍脑袋定的，可以拿实际数据跑分布，看停留时长的分位数，找到那个明显区分"真的在看"和"只是路过"的分界点。

会话切割的规则也要定清楚。常用的是"30 分钟无事件则切会话"。用 Hive 或者 Spark SQL 实现，核心是窗口函数：

-- 用窗口函数做 30 分钟无事件切会话（Hive / Spark SQL） WITH ev AS ( SELECT device_id, event_time, LAG(event_time) OVER (PARTITION BY device_id ORDER BY event_time) AS prev_time FROM ods_box_event WHERE dt = '2026-03-11' AND event_type = 'switch_channel' ), flag AS ( SELECT device_id, event_time, CASE WHEN prev_time IS NULL OR UNIX_TIMESTAMP(event_time) - UNIX_TIMESTAMP(prev_time) > 1800 THEN 1 ELSE 0 END AS is_new_session FROM ev ), sess AS ( SELECT device_id, event_time, SUM(is_new_session) OVER ( PARTITION BY device_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS session_seq FROM flag ) SELECT device_id, session_seq, MIN(event_time) AS session_start, MAX(event_time) AS session_end, COUNT(1) AS event_cnt FROM sess GROUP BY device_id, session_seq;

跑完之后你会发现，广电用户的一天通常是几个大会话：早间、午间、晚间，晚上八点到十点是绝对高峰。这个分布本身就是一个很重要的业务信息，可以拿来做开机率的分时段基线。

2.3 回传覆盖率校准：样本不等于全网

前面说过，回传率在不同片区差异很大。如果你要算"全网收视率"，就必须做校准。思路不复杂：用已知的全网在网用户数，除以回传用户数，得到每个片区的放大系数，再用这个系数对回传样本加权。

举个例子，A 片区在网 10 万户，回传覆盖 6 万户，放大系数是 1.67；B 片区在网 4 万户，回传覆盖 3.6 万户，放大系数是 1.11。同样是一个回传用户在某个频道看了一分钟，A 片区的这个样本"代表"了 1.67 个用户，B 片区只代表 1.11 个。加权之后，全网口径才站得住。

校准系数的更新频率也有讲究。我一般按天更新，并且监控系数的波动。如果某个片区某天的系数突然从 1.67 跳到 2.5，那大概率不是用户真的流失了，而是回传链路出了问题。这类异常值得单独做一张监控图。

提示：校准系数不要做成"实时"的。回传覆盖率本身是统计量，日内波动没有业务意义，反而会引入新的噪声。

2.4 频道、节目单、终端型号三张维表的维护节奏

频道维表是广电的老大难。同一个频道，在不同分公司、不同前端机房里，ServiceID 可能都不一样；频道改版、换名字、上星下星，映射关系一直在变。我一般会建三层映射：物理标识（频率 + ServiceID）到逻辑频道 ID，逻辑频道 ID 到标准频道名，标准频道名到内容分类。

节目单维表来自 EPG，是把时间片挂到节目上的关键：

-- 把分钟级收视挂到具体的节目单上 SELECT s.stat_minute, s.channel_id, e.program_name, e.program_type, s.uv, s.duration_sec FROM dws_channel_minute s LEFT JOIN dim_epg_program e ON s.channel_id = e.channel_id AND s.stat_minute >= e.start_time AND s.stat_minute < e.end_time;

这张表帮我解决过很多"为什么跨零点节目数据对不上"的问题。跨零点的节目，日期归属要用节目开始日期，不是分钟所在的日期。这个规则要写进文档，不然每隔一段时间就会有人来问一遍。

终端型号维表看起来最没技术含量，其实最有价值。它让你能做"不同机顶盒型号的卡顿率对比"，直接给采购和运维提供依据。广电在网机顶盒型号少则几十种、多则上百种，把型号和固件版本维护好，排查问题时能少走一大截弯路。

3. 大屏上真正要回答什么：四类广电看板的需求拆解

3.1 收视与节目编排看板：给内容采购和排播用

这类看板的核心用户是内容采购和排播团队。他们不关心你的技术架构，只关心三件事：哪个节目在涨、哪个时段还有空档、买这部剧值不值。

我的经验是，这类看板最有效的三个视图是：分频道分钟级收视趋势（看竞争格局和时段表现）、节目排行榜（按收视时长而不是按播放次数排序）、以及新上线节目的首周衰减曲线。第三条特别有用，一部剧如果首周衰减特别快，说明口碑一般，后续排播就得调整。

指标上重点看人均收视时长和到达率，而不是单纯的 PV。PV 高但人均时长低的节目，往往是靠预告和片头拉起来的流量，商业价值有限。

3.2 用户运营看板：把沉默用户和潜在流失捞出来

这类看板的用户是运营，他们要的是名单，不是曲线。看板的价值在于把"沉默用户""潜在流失用户"的定义固化下来，并且每天产出可落地的名单。

我给的定义通常是三档：日活、周活、沉默。连续 7 天无开机行为算沉默，连续 14 天算深度沉默。潜在流失的判定要结合行为退化：不只是有没有开机，还要看开机时长是否下降、点播频次是否下降、是否从活跃频道转向了免费频道。这几个信号叠加起来，命中率会明显高于单纯用"多少天没开机"。

名单要能导出、能对接营销系统，否则运营看完还得手工整理，用两次就没人用了。这是我踩过的坑：第一版看板只做了统计，没做名单导出，结果运营还是回去用 Excel。

3.3 网络与终端质量看板：让运维先看到问题

广电是"内容 + 网络"双业务，网络体验直接影响收视体验。这块看板要覆盖：宽带认证成功率、掉线率、点播首帧时长、播放卡顿率、以及分区域、分型号的质量对比。

这类看板的关键是"先看到问题"。我的做法是给每个指标配一个动态基线，用过去 14 天的同期均值加减标准差做上下限，超出就标红。静态阈值在广电这种有强周期性（周末、寒暑假、重大赛事）的业务里基本没用，一到周末全屏飘红。

3.4 广告与商业合作看板：对外的口径要更保守

这类看板是要给外部合作方看的，口径必须保守、可解释、可复核。同一个曝光量，内部用宽口径（只要开机即算触达），对外就得用严格口径（有效停留超过阈值才算触达），两个数字差一倍都很正常。

我的建议是把两套口径都算出来，内部看板展示宽口径，对外承诺只用严格口径，中间留出余量。合作方最怕的不是数字小，是数字前后不一致。

4. ECharts 大屏工程化：实时看板的性能与适配处理

4.1 把全量重绘改成增量更新

刚开始做大屏的人，最常见的写法是每次推送数据都重新构造整个 option，然后 setOption 一把梭。数据量小的时候看不出来，等大屏上挂十几个图表、每个数据源按分钟推送，浏览器就开始卡了。

正确的做法是只更新变化的部分。ECharts 的 setOption 默认是合并模式，series 按索引合并，你可以只传需要变的字段：

// 只推变化的部分，避免整块 option 重建 function pushTrendData(newData) { chart.setOption({ series: [ { data: newData } // 第 0 个 series 是收视趋势 ] }, { lazyUpdate: true }); } // 如果 series 数量会变化，才需要 replaceMerge chart.setOption( { series: rebuiltSeries }, { replaceMerge: ['series'] } );

这里有两个必须注意的点。一是 series 的索引顺序要固定，如果你在某次更新里插了一个 series，后面的全错位。二是lazyUpdate: true会让更新延迟到下一次渲染帧，连续多次推送时能合并成一次重绘，大屏上效果很明显。

4.2 万级数据点的渲染取舍

广电的分钟级收视趋势，一天是 1440 个点，如果要看多条频道对比，很容易上万个点。ECharts 处理这个量级有几种办法，我一般会组合使用：

我的默认配置是：趋势线开 lttb 采样，动画全局关闭，坐标轴刻度固定不浮动。动画在大屏上是负担，不是加分项——一块挂了十几个图的屏幕，每个图都在做入场动画，看起来乱，也吃性能。

4.3 分辨率与投屏适配的三种做法

大屏适配有坑。设计稿通常是 1920×1080，但实际投屏可能是 3840×2160，也可能是拼接屏的 5760×1620 这种奇怪比例。我试过三种做法：

第一种是固定基准加整体缩放，用 CSS transform 把 1920×1080 的容器等比放大。优点是布局完全可控，缺点是超宽屏两侧会留大量黑边。

第二种是 rem 或者 vw 自适应，所有尺寸按视口比例计算。优点是填满屏幕，缺点是超宽屏上元素会被拉得很难看，字间距会失控。

第三种是分区域弹性布局，顶部指标卡用 flex 自动伸展，中间主图固定宽高比，两侧列表用自适应宽度。这是我现在最常用的方案，工作量稍大，但在各种屏幕比例下都不会崩。

还有个小细节：数字字体。大屏上的核心指标一般用 LED 风格的数字字体，但这套字体通常不含中文。字体回退没配好，"开户数"三个字会变成默认宋体，跟数字风格完全撕裂。font-family 里一定要把中文字体显式写在后面。

4.4 WebSocket 推送与断线重连的细节

轮询在大屏上很浪费，尤其是十几个图表同时刷新的时候。我一般用 WebSocket 推送，但推送这一步要克制：不是每次数据变化就推，而是后端做一层节流，比如每 5 秒合并推一次。

重连必须做指数退避，不能一直高频重试：

let retry = 0; function connect(url) { const ws = new WebSocket(url); ws.onopen = () => { retry = 0; }; ws.onclose = () => { const delay = Math.min(30000, 1000 * Math.pow(2, retry++)); setTimeout(() => connect(url), delay); }; ws.onmessage = (e) => handleMessage(JSON.parse(e.data)); }

大屏通常是 7×24 挂着的，网络抖动、后端重启都很常见。除了重连，还要加一个"数据新鲜度"标识，就是在大屏角落显示最后更新时间。一旦超过阈值就变黄或者变红，让人一眼看出这块屏的数据是不是还在更新。这个小小的设计，能省掉大量"大屏是不是卡住了"的沟通。

5. 一次点播量暴跌 40% 的排查链路：上线后才暴露的坑

5.1 第一步：确认是真跌还是假跌

回到开头那个晚上。业务方说点播量暴跌，我做的第一件事不是去查代码，而是先确认这个数字本身可不可信。

判断方法很简单：横向对比。同一天的开机量、换台量有没有同步下跌？如果所有指标一起跌，那可能是链路问题；如果只有点播跌，换台正常，那更可能是点播系统本身或者统计逻辑的问题。当时的情况是：开机量正常，换台量正常，只有点播量跌了 40%。这基本排除了"用户集体不看电视"这种可能。

5.2 逐层回推：从 ADS 倒查到 ODS

确认是"假跌"之后，就开始逐层回推。我习惯按 ADS、DWS、DWD、ODS 的顺序，看每一层的数据量变化：

ODS 数据量没变，DWD 少了将近四成，说明清洗逻辑出了问题。这个结论一下就把范围从"整个链路"缩小到"清洗脚本"。

5.3 根因落在机顶盒固件升级上

接着对比 DWD 的清洗规则变更记录，发现前一天下午确实上线了一版脚本，调整了点播事件的字段映射。但当时在预发环境验证过，逻辑没问题。

继续往下挖，把被过滤掉的记录抽样出来看，发现这些记录的duration字段全是空的。而这些记录集中在某一个机顶盒型号上。查了一下这个型号的固件升级时间，正好是前一天凌晨开始分批推送。

真相是：厂商在新固件里把view_duration改成了duration，同时老字段置空。清洗脚本优先读老字段，读到空就按无效记录过滤掉了。所以数据不是没上报，是被我们主动扔掉了。

修复方式很直接：字段读取做优先级兼容，老字段为空时回落读新字段，两个都为空才判无效。同时加了字段级监控，统计每个字段的空值率，超过阈值就告警。

5.4 把这次事故固化成告警规则

修完不算结束，得让这类问题下次能自己冒出来。我加了三条规则：

第一条是回传量波动告警。每个数据源按小时统计记录数，同比波动超过 15% 就告警，不用等业务方发现。

第二条是清洗损失率告警。DWD 占 ODS 的比例，正常区间是 55% 到 75%，偏离就告警。这次事故里这个比例直接掉到 59%，触发得会非常早。

第三条是字段空值率告警。关键字段的空值率突然上升，往往意味着上游协议变了，比等数据出问题要提前得多。

提示：这三条规则的阈值都是拿历史数据跑分位数定的，不要直接抄别人的数字。不同规模、不同数据源的广电网络，正常区间差得很远。

6. 终端标识脱敏与小样本抑制：看板不能踩的展示边界

6.1 设备标识的哈希处理

广电数据里最容易出问题的字段就是设备标识，因为它能直接对应到一个具体家庭。我在这类项目里的固定做法是：原始标识只在采集层落地，进入清洗层之前统一做加盐哈希，后续所有环节只使用哈希值。加盐值单独托管，不写在代码里，也不进配置中心。

这样做带来一个小麻烦：排查单个设备的问题时不能直接按原始 ID 查。所以我会额外建一张受限的映射表，只有特定角色能访问，查一次留一次记录。听起来重，但这是必须付的成本。

6.2 小样本聚合抑制

看板上有一类隐性风险：某个小区只有 5 户用户，你直接把"该小区收视率 100%"展示出来，等于变相暴露了这几户的行为。我的做法是做小样本抑制，聚合维度下的用户数小于阈值（我一般设 30）时，不展示具体数值，统一显示成占位符或者合并到上一级区域。

这张表我在每个项目里都会拿出来跟业务方对一遍，因为抑制规则会直接影响数字，提前说清楚比上线后被质疑"数据不准"要好得多。

6.3 权限分级与导出控制

看板的权限我一般分三级：只读（看聚合结果）、分析（可下钻到片区）、管理（可导出明细）。导出是风险最高的一环，因为一旦导成 Excel，所有脱敏规则就都失效了。所以导出必须做三件事：字段白名单、行数上限、操作留痕。

还有个小技巧：把导出按钮做得不那么显眼。这话听起来不专业，但实际效果很好——很多随手导出的行为，只是因为按钮太顺手了。

最后分享一个我在多个广电项目里反复验证过的小经验。看板上线后的第一周，别急着加功能，先盯着看有多少人用、看哪几个卡片被反复打开、看哪些卡片从来没人点。通常的结果是，你精心设计的十几个图表里，真正被使用的就那么三四个，而业务方嘴上要的"实时数据"，实际看的时候都是切到 T+1 的历史对比。把没人看的那几块砍掉，把有人看的做强，比再加十张图有价值得多。