央视网的融媒体数据中台实践

本文涉及的产品
智能数据建设与治理Dataphin,200数据处理单元
可视分析地图(DataV-Atlas),3 个项目,100M 存储空间
简介: 作为中央电视台新媒体平台,央视网在不断升级建设“一网(中央重点新闻网站)+一端(移动客户端)+新媒体集成播控平台(IPTV、手机电视、互联网电视)+市场端口连接”的全新传播格局,打造“无处不在”新入口的同时也深刻认识到,需要让大数据成为驱动整个企业发展的核心动能。

作为中央电视台新媒体平台,央视网在不断升级建设“一网(中央重点新闻网站)+一端(移动客户端)+新媒体集成播控平台(IPTV、手机电视、互联网电视)+市场端口连接”的全新传播格局,打造“无处不在”新入口的同时也深刻认识到,需要让大数据成为驱动整个企业发展的核心动能。

央视网的多终端系统技术平台经过多年建设和发展,各终端都建成了一套适合于自己业务发展和管理规范的相对独立的技术平台,虽然实现了对各自业务的支撑,但也形成了很多数据孤岛,不仅数据独立,数据口径也因对业务的不同理解而千差万别,不同平台和业务线都自成体系,央视网庞大的数据库无法形成产业合力。

事实上,不仅是央视网,许多互联网大型企业都遭遇了同样的问题。借鉴阿里巴巴的中台战略思想,将业务共同的工具和技术沉淀打造“大中台、小前台”的技术布局,将业务发展的全流程进行数据化采集并整合,以数据链打通生产和传播,整合生产数据和多终端用户数据需求,从而进行更高效更精准的定向传播。

央视网大数据平台于2018年底正式建成,是主流媒体中目前计算能力最强、数据量最大的大数据平台。目前每天采集10~20亿条用户数据,系统具备每天处理100亿条数据的能力,采集分析处理央视网PC网站、央视影音客户端、IPTV、手机电视、互联网电视和总台全部微博、微信公众号的用户访问数据。在构建数据中台的过程中也沉淀出一套方法论和服务体系。

一、融媒体数据中台管理体系

通过建设数据中台,驱动“一切业务数据化”,提升数据资产价值。数据中台是实现媒体数据沉淀的重要组成部分,每家媒体都拥有自己的独特数据模型、算法服务和数据管理规则,这些都与业务强关联,是每家媒体独有且能复用的核心资源。统一的模型维护不仅可以降低烟囱似的协作成本,减少重复建设,更可以在相关业务领域形成数据汇聚,解决数据互通的诉求,实现数据1+1>2。于是央视网构建了OneData、OneID和OneService的数据管理体系,以“承技术启业务”的模式促进媒体融合发展(图1)。
2.jpg

1.数据采集与清洗

数据采集是数据挖掘、分析的基础,数据的大小、类型以及数据质量直接决定数据分析与挖掘的成果。在实际应用中通常是需要多个维度、多个方面的数据汇集交融。因此在数据采集时,就要考虑多源数据的立体采集,收集尽可能多的数据,同时保证数据质量。

数据采集汇总完成后,需要投入大量的精力和时间对数据进行整理校准,统一口径,规范关联规则,也就是数据清洗。在数据清洗过程中,需要建设完整性、准确性、一致性三个基本准则,最后使数据标准、高质量、可应用。

2.OneData体系

传统单个业务独立运行并自行管理数据的过程中,我们经常会发现一份原始数据被多个业务存储和计算,产生多个备份,定义出多种口径,命名相同,定义口径却不一样,混乱的标准和规则指向不明,界定模糊,给技术统一管理和业务应用带来极大难度。大数据建设过程就是从无序到有序的逻辑重建过程,由数据接入、规范定义、计算加工、数据验证、数据稳定性等多个部分合并构成了整体数据研发流程。OneData体系致力于建立跨终端数据公共层,保障数据口径的规范性和唯一性。从终端数据源头标准化数据,对每个元数据进行指标定义,使每一条数据都保持唯一性,以确保数据模型建立时,数据的标准性和存储资源开销也是稳定可靠的。

3.OneID体系

以媒体业务为例,数据主要分为用户数据、媒资数据、业务流程数据、运营数据几类,不同业务模式、产品线、终端、平台都有自己关注的数据指标和参数,业务之间相对独立又整体关联,建立统一的数据管理规则才能从中挖掘更多数据价值。One ID体系致力于建立跨终端的用户ID体系和内容ID体系,深入挖掘用户真实感受和内容价值。

4.OneService体系

数据定义清晰、规则统一之后,数据最终是要通过可视化的方式给管理人员、业务人员提供服务。在数据中台初始化的过程中,数据团队从管理视角、服务视角、业务视角打造多张数据报表对数据实时监控从而实现业务应用。随着业务应用越来越多,业务关系越来越复杂,需要构建标准化统一服务模型来减少系统对于研发力量的核销和服务计算压力的开销。

要建立OneData、OneID、OneService的数据管理体系,在技术上需要具备很强大的数据计算能力、平台化的数据模型能力以及智能化的数据算法能力,在业务上同样需要媒体行业经验指导,建立合适的业务场景,通过场景应用使数据业务化,从而体现数据的价值,赋能产品线。
3.jpg

二、融媒体数据中台实施

1.数据分层次
传统数仓平台通常会使用ETL(Extract-Transform-Load)将业务系统的数据经过抽取、清洗转换之后加载到数据仓库,目的是将业务线中的分散、零乱、标准不统一的数据整合到一起。随着业务线增多,需求变化加快,通过一个个单一的ETL代码匹配一连串业务场景,显得捉襟见肘,无法符合数据中台建模规范,必须重新定义。

依照OneData体系原则,数据中台数据仓库建模规范,将表数据模型主要分为三个层次,分别是ODS(Operational Data Store)操作数据层、CDM(Common Dimensions Model)公共维度模型层、ADS(Application Data Store)应用数据层,其中公共维度模型层包括明细数据层(DWD)和汇总数据层(DWS)。三个层次自下而上,逐级递进,各层次之间高内聚低耦合,公共层承上启下,业务逻辑下沉,避免了应用层存在过多繁琐的业务逻辑实现。

ODS层:将来源于各终端各个系统最原始的数据,结构化后存放在数据仓库。ODS层属于表模型的最底层,直接对接各终端各业务系统产生的结构化数据、非结构化数据、历史留存数据等。数据接入主要使用同步任务和代码任务方式,对于结构化数据(数据库)采用全量或增量方式同步到数据计算平台,而非结构化数据(日志、埋点采集)需要先进行结构化处理后存储到数据计算平台,对于历史留存数据可根据数据结构特点采用相应方式接入数据计算平台。在这一层实时和离线在源头上是统一的,口径也是基本一致的,在后续数据校验时,可以很容易进行实时和离线间数据的对比。

CDM层:CDM层是数据加工逻辑的核心层,也是数据建模业务数据化的体现点,主要存放明细事实数据、维表数据及公共指标汇总数据。在这层采取维度模型方法基础,更多采用一些维度退化手法,减少事实表和维度表的关联,容易维度到事实表强化明细事实表的易用性;在汇总数据层,加强指标的维度退化,采取更多宽表化的手段构建公共指标数据层,提升公共指标的复用性,减少重复加工。

ADS层:主要存放各终端独立业务产品统计指标数据,主要来源于CDM层加工生成,这一层计算只有业务本身才会关注的维度和指标,与其他终端业务线一般没有交集,都是独立存在,常用于新的业务需求或基于各个应用场景的数据组装。比如:用户留存漏斗模型、视频播放趋势分析都可以按照不同需求从CDM层加工而成(图3)。

4.jpg
2.定义扣指标

数据分层规划完成后,下面需要规范定义。这里“规范定义”是指以维度建模作为理论基础,构建总线矩阵,划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、衍生指标等。一般指标组成体系可以划分为:原子指标、衍生指标、修饰类型、修饰词、时间周期。在跨终端多业务指标体系建立过程中,应始终遵循OneData原则,避免因为个性化业务需求,创建重复或赘余的指标。

3.维度建模型

维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法,以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,重点解决用户如何更快速完成分析需求,同时还具有较好的大规模复杂查询的响应性能。

数据建模首先需要做好业务需求调研。在业务梳理过程中,逐步抽象出数据域。数据域将业务过程和维度进行抽象地集合,在媒体行业中常用会抽象出会员域(注册、登录等)、日志域(曝光、浏览、播放)、互动域(评论、回帖)等,每个数据域会包含不可拆分的行为事件,这需要对业务高度提炼且根据需求持续更新迭代。确定了数据域就需要明确数据域下业务过程与哪些维度有关联,这里就会涉及维度表的创建。

接下来最重要的一项是创建事实表。事实表作为数据仓库维度建模的核心,紧紧围绕业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的指标,在事实表中应该尽量包含所有与业务过程相关的事实。

5.jpg
事实表中一条记录所表达的业务细节程度被称为粒度。粒度的声明是事实表设计中不可忽视的重要一步。粒度用于确定事实表中一行所表示业务的细节层次,决定了维度模型的扩展性,在选择维度和事实之前必须先声明粒度且每个维度和事实必须与所定义的粒度保持一致。

遵循OneData体系数据建模实施过程是一个高度迭代和动态的过程,采用螺旋式实施方法。在总体架构设计完成之后,开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中,都会引入评审机制,以确保模型实施过程的正确性。

4.平台理资产

业务以数据化形态展现出来的同时,也无形中变成了最宝贵的资产。数据模型建立不仅需要设计上的合理,更需要平台化的支撑。数据平台资产管理的能力主要表现为:支持基础信息管理的能力,即存放在平台内的表信息、表名、字段、分区、存储空间及数据预览功能;任务血缘关系管理能力,数据平台上管理的代码任务、同步任务应自动或手动建立血缘关系,实现数据链路可查询、可追踪、可溯源能力;数据存放生命周期能力,即存放在平台内的表具有生命周期,在建立表结构的同时指定留存时长,提高平台存储利用率;类目标签体系管理能力,即能对存放在平台的表分门别类,一方面便于业务管理,另一方面便于快速查询;操作记录管理能力,即能够记录对于表结构新增、变更、删除等操作,操作痕迹有据可查,保证平台具备数据审计能力,事故可追根溯源;用户权限管理能力,即表级、行级权限授权,包含权限审批流程,保障数据安全性;脏数据管理能力,即对于平台任务产生的脏数据,能统一查看和处理。数据资产管理平台化是数据中台基础核心功能,也是数据管理体系建设中技术平台化体现(图5)。
6.jpg
5.规则保质量

在实际数据中台实施建设过程中,数据计算任务没有告警,但不代表数据就是正确的,比如源数据异常、代码逻辑修改等原因都会造成结果数据错误。数据质量就是保障数据正确性的工具,主要运用以下几条规则保证数据质量:数据准确性校验规则针对核心的表及字段进行校验规则,比如表的数据量是不是波动很大、字段是否存在异常值或突增突降现象;双表校验规则,在处理历史数据迁移、重要业务逻辑变更时,需要保证数据的一致性,在保持原表的同时创建新逻辑表,待两张表验证结果后再执行变更上线;统计校验规则,按固定周期根据表、字段或业务线核心指标,输出数据校验报表,辅助定位数据质量的问题根源会定期自动执行校验规则,输出校验报告(图6)。
7.jpg

三、数据中台建设的经验与启示

数据中台建设是推进企业发展的重要驱动力。对于已经有较大规模业务的企业来说,历史数据整合比新建数据体系困难更大。传统媒体的技术人才劣势是驱动媒体融合发展中无法回避的弊端,与先进的技术能力提供商联合可以减少弯路加速技术升级进程。

推进中台建设的过程中将会面临着技术挑战、业务挑战、财务挑战以及所有相关利益团队的挑战。既需要企业管理层支持,自上而下地统一思想,更需要在推进过程中脚踏实地、胆大心细。如果说平台搭建可以依赖外部的技术力量,企业数据治理和数据规范则需要在内部团结一切可以团结的力量,让越来越多的业务线共同参与,以同样的理念做好同一件事,从而达成共赢。

数据是辩证的、是客观的,是未经过加工的信息表达载体。在面对这既美妙又枯燥的表达方式时,我们可能碰到的是由每一个功能上线呈现出精彩图表应用带来的喜悦,也可能经历的是由于规则错误导致从头再来的沮丧。“不积跬步,无以至千里”,在漫长的数据中台建设过程中,必将经历各种磨难。痛并快乐着!

PS:内容转载至央视科技

相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
相关文章
|
7月前
|
SQL 运维 关系型数据库
基于AnalyticDB PostgreSQL的实时物化视图研发实践
AnalyticDB PostgreSQL企业数据智能平台是构建数据智能的全流程平台,提供可视化实时任务开发 + 实时数据洞察,让您轻松平移离线任务,使用SQL和简单配置即可完成整个实时数仓的搭建。
645 1
|
4天前
|
数据采集 供应链 搜索推荐
商业案例 I AllData数据中台商业版落地实践
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
|
1月前
|
JSON 数据可视化 NoSQL
基于LLM Graph Transformer的知识图谱构建技术研究:LangChain框架下转换机制实践
本文介绍了LangChain的LLM Graph Transformer框架,探讨了文本到图谱转换的双模式实现机制。基于工具的模式利用结构化输出和函数调用,简化了提示工程并支持属性提取;基于提示的模式则为不支持工具调用的模型提供了备选方案。通过精确定义图谱模式(包括节点类型、关系类型及其约束),显著提升了提取结果的一致性和可靠性。LLM Graph Transformer为非结构化数据的结构化表示提供了可靠的技术方案,支持RAG应用和复杂查询处理。
131 2
基于LLM Graph Transformer的知识图谱构建技术研究:LangChain框架下转换机制实践
|
4月前
|
机器学习/深度学习 自然语言处理 搜索推荐
LangChain在个性化内容生成中的实践
【8月更文第3天】随着人工智能技术的发展,个性化内容生成已经成为许多应用的核心竞争力。LangChain 是一种开源框架,旨在简化语言模型的应用开发,尤其是针对自然语言处理任务。本文将探讨 LangChain 如何帮助开发者根据用户的偏好生成定制化的内容,从挑战到实践策略,再到具体的案例分析和技术实现。
282 1
|
7月前
|
机器学习/深度学习 人工智能
【LangChain系列】第九篇:LLM 应用评估简介及实践
【5月更文挑战第23天】本文探讨了如何评估复杂且精密的语言模型(LLMs)应用。通过创建QA应用程序,如使用GPT-3.5-Turbo模型,然后构建测试数据,包括手动创建和使用LLM生成示例。接着,通过手动评估、调试及LLM辅助评估来衡量性能。手动评估借助langchain.debug工具提供执行细节,而QAEvalChain则利用LLM的语义理解能力进行评分。这些方法有助于优化和提升LLM应用程序的准确性和效率。
589 8
|
7月前
|
存储 机器学习/深度学习 人工智能
【LangChain系列】第八篇:文档问答简介及实践
【5月更文挑战第22天】本文探讨了如何使用大型语言模型(LLM)进行文档问答,通过结合LLM与外部数据源提高灵活性。 LangChain库被介绍为简化这一过程的工具,它涵盖了嵌入、向量存储和不同类型的检索问答链,如Stuff、Map-reduce、Refine和Map-rerank。文章通过示例展示了如何使用LLM从CSV文件中提取信息并以Markdown格式展示
326 2
|
7月前
|
机器学习/深度学习 自然语言处理 数据挖掘
【LangChain系列】第七篇:工作流(链)简介及实践
【5月更文挑战第21天】LangChain是一个框架,利用“链”的概念将复杂的任务分解为可管理的部分,便于构建智能应用。数据科学家可以通过组合不同组件来处理和分析非结构化数据。示例中展示了如何使用LLMChain结合OpenAI的GPT-3.5-turbo模型,创建提示模板以生成公司名称和描述。顺序链(SimpleSequentialChain和SequentialChain)则允许按顺序执行多个步骤,处理多个输入和输出
1035 1
|
7月前
|
存储 人工智能 搜索推荐
【LangChain系列】第六篇:内存管理简介及实践
【5月更文挑战第20天】【LangChain系列】第六篇:内存管理简介及实践
209 0
【LangChain系列】第六篇:内存管理简介及实践
|
7月前
|
存储 机器学习/深度学习 人工智能
【LangChain系列】第一篇:文档加载简介及实践
【5月更文挑战第14天】 LangChain提供80多种文档加载器,简化了从PDF、网站、YouTube视频和Notion等多来源加载与标准化数据的过程。这些加载器将不同格式的数据转化为标准文档对象,便于机器学习工作流程中的数据处理。文中介绍了非结构化、专有和结构化数据的加载示例,包括PDF、YouTube视频、网站和Notion数据库的加载方法。通过LangChain,用户能轻松集成和交互各类数据源,加速智能应用的开发。
389 1
|
7月前
|
人工智能 测试技术 API
【AIGC】LangChain Agent(代理)技术分析与实践
【5月更文挑战第12天】 LangChain代理是利用大语言模型和推理引擎执行一系列操作以完成任务的工具,适用于从简单响应到复杂交互的各种场景。它能整合多种服务,如Google搜索、Wikipedia和LLM。代理通过选择合适的工具按顺序执行任务,不同于链的固定路径。代理的优势在于可以根据上下文动态选择工具和执行策略。适用场景包括网络搜索、嵌入式搜索和API集成。代理由工具组成,每个工具负责单一任务,如Web搜索或数据库查询。工具包则包含预定义的工具集合。创建代理需要定义工具、初始化执行器和设置提示词。LangChain提供了一个从简单到复杂的AI解决方案框架。
735 3