基于IPTV业务的数据分析系统设计与应用

陈惠兰

（福建省广播影视集团 福建省福州市 350000）

1 引言

近年来，IPTV 作为媒体融合的典型业务发展迅猛，IPTV 用户实现了规模化发展，与此同时也产生了海量的视频、文本、行为数据。如何充分利用这些数据服务IPTV 业务的发展，如何汇聚和计算解析这些数据，从中提炼出有价值的信息，以此了解用户行为，为IPTV 平台未来业务的发展，起到更为针对性的指导作用，是新媒体所要面临的新的难题和挑战。

系统基于IPTV 平台的用户行为数据，采用海量数据分级存储、分布式异构数据的处理等关键技术，结合传统媒体平台与新媒体平台的用户样本数据分析，为新媒体平台的策略制定提供详细的数据支撑，包括用户个性化信息推送服务，平台内容安全监控等。

2 业务需求分析

在实际的运营中，发现一些问题：目前用户数已超600 万，但沉默用户占比高，而增值用户占比低。IPTV 业务数据各为孤岛，且数据停留在统计分析层面，加工利用难，对业务支撑较弱。因此，深入挖掘平台海量数据，以此更精准定位用户的消费喜好、消费层次等行为特征，做到有的放矢，最大化的激活潜在沉默用户，提升增值用户订购率。

为解决以上IPTV 业务运营中存在的问题，设计符合业务需求的数据分析平台，借助数据图文和报表的方式帮助运营人员收集用户需求和喜好，从而实现激活沉默用户和提高增值用户比例。鉴于此，我们构建了数据分析系统。实现运营人员适用的数据分析平台，可广泛应用于IPTV、手机电视、融媒体平台等多种业务平台，实现可视化报表方式展现，可根据业务场景进行定制开发和模型重构。

3 数据分析系统方案

3.1 系统总体架构

数据分析系统架构侧重于解决传统BI 数据分析的三个瓶颈问题：

图1

图2

图3

（1）分布式计算，设计思想是实现多节点并行计算，优势是数据本地化，尽量减少数据之间的传输[5]。

（2）分布式存储，则是将一个较大的文件分解为多个小文件分别存储到不同的服务器，通过分片式技术对分解后的小文件进行管理。

（3）基于IPTV 业务数据，数据分析面临着在多种异构数据类型的海量数据中进行检索。

为了解决以上三个瓶颈的问题，系统采用分层设计、分级处理的系统架构。主要由数据采集层、数据存储层、数据分析计算层、数据展示层4 个分层架构组成，系统架构如图1所示。

系统部署需要解决以下四个问题：

（1）日常EPG 及专区系统探针数据、C2（媒资数据接口）、C3（运营数据接口）的源数据体量庞大，虽然硬盘的存储容量不断增加，但还有一个明显的缺陷就是硬盘的寻址能力有限，寻址效率低，当数据规模较大时，数据的读取效率会很缓慢，这是硬件本身的局限性，单从软件方面突破有一定难度。

（2）鉴于硬件的局限性，我们参考另外一种成熟的数据访问方式—基于数据流，数据采集首先是获取数据的输入流，通过该流来获取所有数据，以此做数据的检索和分析，充分节省数据寻址的时间，数据读取效率大大提高[1]。

（3）基于流的访问方式虽然可以提高数据读取效率，但是同时又发现了一个问题：基于流的方式消耗会很多的计算机资源（比如CPU，内存等），对于这些缺陷，我们能想到的最直接的处理方式便是将汇聚的源数据进行分割，分散到多台设备上进行并行的读取[1]，这样不但加快了数据的读取效率，也缓解了单台设备性能不足的问题。

（4）但是，经过分散部署这种方式处理之后，又会带来新的难题：首先，源数据分散部署之后，会大大增加数据遗失的风险。其次，对分散数据的片段需要重新汇聚。

为了解决以上所述海量数据的存储和分析计算存在的问题，系统设计选择基于Hadoop 作为基础框架部署数据平台。

Hadoop 擅长日志分析，对大数据进行分布式处理；它的处理能力是可扩充的且成本低，可以通过普通机器组成的服务器群来分发以及处理数据，集群中的每台机器都会参与存储和计算。利用分布式存储进行大数据的处理过程中，可以非常好地解决耗时数据传输问题。更关键的一点是，数据冗余机制能够让Hadoop 从单点失效中逐渐恢复[4]。

Hadoop 框架的核心思想为存储和计算。存储逻辑用到的是HDFS（分布式文件系统）子框架，计算逻辑用到的是MapReduce（布式运算）子框架，每个子框架分别解决了上述难点[4]。本文数据分析系统的集群规模2+13+1（2 个名称节点+13 个数据节点+1 个接口机），数据存储规模为45TB。

3.2 数据采集

数据分析系统涉及的用户行为数据如表1。

3.2.1 EPG 探针数据采集

EPG 数据采集探针是我们为了获取用户的操作行为和播放信息等，通过在EPG 页面嵌入代码，实现EPG 页面向采集服务器的消息传递，为EPG 实时报表提供准确数据的功能。EPG 探针采集流程如图2所示。

数据分析系统为保障系统实时性报表的准确性及系统承载压力，参考最高并发用户100 万计算，系统投入5 台负载均衡服务器，最终确定了机顶盒上报频率时间间隔为5 秒。计算公式如下：

服务器承载量：（（1000000 用户÷ 60000 次/秒（服务器承载能力））÷ 5 秒））÷70%（冗余30%系统能力）=5 台服务器。

3.2.2 C3 数据采集

C3 数据每日由运营商收集话单按规范生成C3 压缩数据同步至数据分析系统，数据分析系统定时扫描离线文件并自主解压，解压后系统自动导入文本数据至数据仓库。

3.2.3 媒资管理系统采集

媒资管理系统数据利用标准C2 规范实现数据准实时同步至数据分析系统数据仓库。

3.3 数据存储与计算

表1

3.3.1 数据分级存储

系统采用数据分级存储技术来实现多元异构数据存储的高可靠性。

在本项目中，引入分级存储技术的优点有：

降低总体存储成本：对于访问频次高的数据存储在高性能存储设备中，而对于低频访问的数据则存储在低成本存储设备中，可充分发挥高性能存储设备的性能优势和低价格存储设备的成本优势[2]；

优化性能：访问频次高的数据和有访问响应时长要求的数据则存入内存存储设备中，可显著提高数据访问和计算的效率。

3.3.2 数据计算

数据系统采用Hadoop + Spark 并行分布式存储和流式计算的框架，计算分为离线计算和实时计算两部分。该架构的优势具备：

（1）Hadoop 分布式文件系统的高效数据交互，将大数据处理引擎MapReduce 尽可能靠近存储HDFS 以实现Local Data 处理的模式，将采集到的数据进行快速分析处理并走向存储；

（2）Spark 充分利用Linux 的多线程及高性能的检索技术，优势是在数据流还没写入硬盘时就能够在存储器中进行合理地分析和运算，做到实时分析处理，保证快速的响应时间[4]；

（3）分布式文件系统HDFS 的备份恢复机制，生成原始数据备份文件保存在服务器，保证了分布式处理的可靠性，从而保障数据的安全。

3.3.2.1 离线计算

系统基于HDFS + MapReduce 的计算框架，实现分布式并行计算模型MapReduce,适用于大规模离线数据集的并行运算场景。MapReduce 采用分节点处理的方式，首先把任务分发到集群的多个节点上，并行计算，然后再把计算结果合并，从而得到最终计算结果，达到单条信息秒级的处理性能。

3.3.2.2 实时计算

系统采用Spark Streaming 实时流式大数据采集处理方案，Spark 是基于内存计算的分布式集群并行计算系统，能有效应对实时数据的高并发，实现大容量高并发消息数据实时计算处理，保证任务能够秒级完成，处理性能得到大幅提升。

4 数据报表生成

系统基于采集的EPG、专区系统的实时用户行为数据、IPTV C3 离线日志数据及C2 播控媒资数据，根据IPTV 业务发展和运营实际需求建模和统计分析，提供多个维度和层级的各类业务运营分析报表，包括实时分析报表、历史分析报表，运营人员可全方位监控IPTV 业务运营情况数据。

各维度分析报表如下：

（1）区域维度：按省、地市统计；

根据福建全省地图，实时呈现全省九地市的在线用户数及在线用户占比，全网在线用户数，开机率进行按地区实时监控对比、排序；如图3所示。

（2）用户维度：用户发展、用户活跃、用户价值等；

根据用户维度，实时把握用户发展情况，适时调整用户发展营销策略；

（3）业务维度：直播、点播、回看、时移收视，EPG 页面浏览等；

对全网用户频道收视人数对比分析，实时监控频道、栏目收视人数、收视时长、收视次数、占比及排行；

对EPG 页面各推荐入口点击数、停留时长等维度进行实时分析、对比。以此报表作为日常运营及节目推荐的参考依据。

（4）内容运营维度：支持按运营分析需求，从栏目、媒资分类（电影、电视剧、少儿等）、基础标签（亲子、搞笑、冒险等）、运营标签（根据运营需要自行定义标签，动漫电影等）、内容属性（提供商、导演、演员、年代等），再到具体媒资内容收视统计分析数据，满足内容运营分析的各项需求。

（5）产品维度：支持单点、包月、包年订购统计，及时掌握各种类型产品订购汇总指标对比及趋势分析，满足运营对于总体营收的把控和具体营销产品的跟踪分析需求；

5 结束语

数据是反映产品和用户状态最真实的一种方式，相比传统的收视统计手段，大数据分析平台具有更客观、更准确、更及时、更精细等特点。福建IPTV 大数据分析平台自上线以来，得益于丰富客观的数据源，实现了IPTV 业务数据整合，在以此基础上分析出的多维度收视指标，做到知己知彼知用户，实现了以数据指导运营决策，有效地提升转化率，驱动福建IPTV 业务增长。