内容智能生态——数据、算法、应用在线视频

前面两讲

我们分别介绍了

爱奇艺在个性化内容推荐

用户行为大数据分析方面的

一些研究和应用的成果

今天我们非常高兴

能请到阳任科

他是2007年

从华北电力大学

计算机系硕士毕业

曾经先后在中国互联网信息中心

竞技世界 从事大数据

数据挖掘的相关工作

多年在数据建设和风控

用户行为挖掘 内容分析等领域

做技术一线的深耕

他2017年加入爱奇艺

现在是爱奇艺的研究员

也是商业数据智能组的负责人

今天他会来跟我们一起分享

大数据上的内容分析

下面我们用热烈掌声来欢迎

阳任科研究员跟我们（进行）座谈会

大家下午好

今天非常高兴有机会

能够在这里跟大家做交流

我是来自于爱奇艺商业智能部

数据智能组的阳任科

今天我的题目叫做

大数据之上的内容分析

之前演讲的题目叫做

AI与大数据之上的内容分析

感觉大数据系列课上大数据

我把AI两个字去掉了

感到好像更加契合

这个名字可能写得

稍微有一点抽象

大家看这个标题

不知道我要讲的是什么

我们之前的课程应该有一个介绍

大家猛一看不知道在讲什么

毕竟我们的场景离大家有点远

可能大家得仔细看一下

可能还是不知道在讲什么

分析可以分成两个部分

一个在用户侧

用户侧主要是分析用户行为

基于对用户行为的分析

给用户提供更好的服务

另外一方面在内容侧

内容侧分为两个部分

一个是对内容本身的分析

另外一个是

用户在内容上发生行为的分析

它的目的也是为了更好地服务用户

大数据是个比较大的话题

也可以说数据本身

从数据本身来说

大数据并不是数据多就叫大数据

至少要包括三个特点

首先 可用

我们的数据

是可以被我们所使用的

我们能够采集到 获取到的

第二是好用

如果只是一个数据堆积

在这里是没任何意义的

我们的数据能够被我们加工

生产成数据资产

能够为我们的生产

或者是为我们的应用

能提供更好的价值

这样才是好用的

这样才是有意义的

另一方面叫做易用

易用是数据资产已经有了

但是你使用起来非常困难

你要通过特别大的代价

才能对它进行使用

甚至有一些不懂技术的人

甚至都不能使用

这样也是没有太多意义的

只有符合这三个特点

大数据才能真正叫做大数据

不然只能叫做数字信息的堆积

除了大数据本身以外

还有一块儿是我们大数据的技术

大数据技术这几年发展还是比较快的

在几年以前

做一个简单的分数的TOP-N排序

可能要做到分钟级都比较困难

我们需要通过一些算法

做一些近似的处理

现在通过一种实时的计算引擎

做一个算子可能就搞定了

甚至用像Kylin

这样的一些预计算引擎

可能在秒级都能返回结果

在以前是不可想象的

以前大家都在搞神经网络

以前做一个比较浅层的神经网络

数据量一大 机器基本上就歇菜了

现在可以看到

各种深度的模型都在满天飞

大家可能赶上一个好的时代

以前一些土豪才能玩的东西

现在我们的在校学生也能搞一搞

真的是旧时王谢堂前燕

飞入寻常百姓家

我今天想跟大家分享一下

我们在基于整个大数据之上的

内容方面做一些工作

可能分成两个部分

一方面稍微系统地介绍

大概的内容

另一方面分享落地的东西

可能会挑一两个应用

再深入地讲一下其中的技术点

我们的内容分析

一个是智能生态

首先我们可以看到分成三个部分

数据部分 算法部分 应用场景

数据部分首先是我们的数据建设

数据建设是所有工作的基础

我们会把所有的内部外部的数据

包括结构化的 非结构化的数据

我们都会采集过来

我们会对它进行加工 转化

先是我们的数据仓库

包括我们基于各种主题的知识库

我们会建设用户画像系统等等

这些都是我们的数据资产

在此之上我们有一个数据中台

我们会通过数据中台

统一对外提供一些数据能力

在我们数据之上

是我们的算法模型部分

它包括直接对业务

提供支持的一些比较基础的分析

比如说我们的运营分析

剧集分析 我们的绿镜

同时

也包括了对内容进行深入理解

一些NLP 语音和图象识别

甚至上面会有数学建模的东西

在此之上是我们能够落地的领域

我们在投资 创作 制作 运营

营销 风控等各个领域都可以应用

我们主要包括两大部分

第一 大数据部分

第二 算法模块

首先讲大数据部分

要说大数据绕不开的

话题是数据仓库

在校的学生或者中小企业

感触不是很深

大家做数据分析

可能是拿张框表

在上面跑一些东西

可以用Python做一些处理

做算法是做一些特征工程

需要什么就做什么

有什么日志 从哪里生产

大家可以想一下

如果是一个人两个人可以这样做

但是如果到五个人 十个人

大家用同一份数据

你的做法可能就会有一定的干扰

如果数据量再大一点

以前的数据量是几十G

我们现在到几十T 上百T

甚至到几十P

有上千人一起在用这个数据

如果再用这种方式来做

可能就做不了了

我们的代价是非常非常大的

如果不搞数据仓库

可能会出现三个问题

这就是量变到质变

一旦发生质变可能会有三个问题

一个是数据定义的不统一

比如说我们对一些数据指标

定义 命名都不一样

可能实际上是同一个东西

这样我们的计算逻辑

可能也不一样

已经大大提高了数据使用的成本

数据可能会重复建设

张三和李四都在做一个项目

大家从头到尾对整个数据流

进行这样的处理

这样会发现

大量数据实际上被重复建设

因为大家计算逻辑比较相似

一个非常简单的访问时长

用户登录次数等

大家可能都会用

每个人可能都会从头计算一遍

不但增加我们存储的成本

以及我们计算的成本

同时也增加变化成本

在互联网行业

我们的变化 迭代非常快

有很多人都用同一份数据

一旦数据发生变化

所有人整个流程都要再做一次

变化对应速度是非常慢的

代价会非常大

也会造成其它数据不一致的

综合性的问题

第三个问题是研发成本高

因为每个工程师 分析师

或者是做研究的研究员

他做自己的事情

每个人都在做自己的那套工作

做完了他的成果很难跟别人共享

大家都是在自己的相对封闭的

一个数据集里进行工作

对生产是非常大的浪费

对于企业来说需要考虑两个因素

第一 成本

第二 效率

这是两个必须要考虑的问题

从这两个方面来说

我们数据仓库的建设

是非常有必要的

看大数据的同学觉得

数据仓库就是一个Hive

或者是在Hive里建一张表

现实中跟这个差别还是比较大的

我们要怎么建数据仓库

在行业里面

有两个比较著名的大牛级人物

一个叫Evm 一个叫Kob

他们提出两种不同的思路

像Evm 他之前提出的理论是

基于传统的关系数据库时代

他讲的是自上而下进行建设

先做好充分的分析和调研

定义好一个非常完备的

方案和规则

然后我们再来建设数据仓库

再往下到各个数据集市

我们可以看到

它的优点是很明显的

首先 他的数据会非常非常的规范

他的数据会很一致

数据质量会非常高

会满足各方面的需求

因为调研得很充分

但是它的缺点也很明显

首先 建设周期很长

其次 对需求的响应速度很慢

在传统的企业行业是非常合适的

因为一些传统行业

业务变化非常非常慢

需要的是稳定 规范

他能忍受这样的代价

但是在我们互联网时代

这个方式就不太能忍

因为互联网时代讲究的是变化

我们的变化速度会非常非常快

这样不太满足大家的需求

像Kob提出的

是另外一种截然相反的思路

讲究的是由下而上进行建设

他是讲究对需求快速响应

接到一个需求后

我们要做的事情是

对外分析建模的方式

首先 对需求进行响应

建设我们的数据集市

再往上集成到数据仓库

这种方式的优点很明显

响应速度非常快

能够快速对应业务

但是同时它的缺点也很明显

过分地讲究速度

忽略了体系建设的事情

可能当时我们解决了问题

但是过了一段时间后

会发现存在数据不一致

或者各种其它的问题

我们又要对之前的工作进行重构

这个代价也是非常非常大的

特别是企业到一定的规模

我们的数据量到一定规模

这个代价也是特别大的

如果企业数量到一定规模以后

一般用这两种方式相互结合来做

我们首先快速地对应我们的需求

用Kob的思想 但是

到了一定阶段

我们会往上进行迭代

回到我们的数据仓库

在这之中涉及到的问题也比较多

比如说

怎样对元数据进行管理

怎么样对数据进行治理

数据安全怎么保证

指标要怎么进行统一控制

统一进行定义管理等等

涉及的问题也比较到

左图是爱奇艺数据仓库的架构图

我们会把各种各样的外部数据

经过采集 经过ETL进行加工处理

存到的数据集市里面

首先建设数据集市

然后周期性地

迭代到我们的数据仓库

数据集市是我们右边的架构

是一个经典的四层架构模型

底层是ODS层

第二层是DWD层

然后到MID层 到AL层

ODS层是外部采集的

各种各样的数据

我们会把各种数据

原封不动地进行保留

我们在DWD层会对数据进行处理层会对数据进行处理

但是得到是一些很明细的数据

在这个地方

我们会对业务规则进行屏蔽

得到是一些很规范的数据模型

再往上到聚合层

用户经过聚合统计的数据

再往上就是应用层

一般的分析师

或者其它的非数据仓人士

使用的应用层这一块儿

对于一个算法工程师来说

如果有人已经帮你把特征工程做完了

或者你能简单通过几个数据抽取

从几张表集合拖成一张大框表

我觉得每个算法工程师和分析师

都是非常高兴的

因为你已经不用担心

数据使用性问题

这张表是不是过时了

这个指标定义计算口径

是不是有问题

统统你都不用考虑

你要做的是从聚合层

把各种数据抽取出来

拉出一张框表

输入到我们的算法模型

或者拿来做分析

大概是这样的过程

我这样给大家讲的原因是

这一块儿东西

离学校的同学稍微远一些

大家可能不是特别关心

所以我单独拿出来给大家讲一下

当然大家可能会疑问

概念挺好的

但是怎么样去落地

肯定不仅仅是一个规范的问题

不是仅仅要求在哪一层

建表 我的表名怎么样

我们把整个过程抽象成三个

一个建模阶段

比如说 要建数据仓库

我们首先要有业务建模

然后有数据建模

有物理建模

在业务建模里面把用户的需求

翻译成业务语言

我们的数据建模里面

把我们的业务语言

翻译成数据语言

数据语言会用数据模型进行落地

在物理建模这块把之前设计的

数据模型落到数据仓库各个层

我们在建模这一块儿

可能会涉及比较多

这一块儿用得比较多就是

服务于分析师做分析

或者算法工程师用来做算法

我们更多用的用对外分析建模

比如说三范式建模

Data Vault建模 Anchor建模等等

这一块儿理论还是很多的

我给大家在这儿做一些分享

每一个单独的理论

我们都可以专门做一个演讲

内容挺多的

先给大家这样泛泛做介绍

后续大家如果感兴趣

可以再深入交流

讲完数据集这一块儿

我们可以看一下算法体系

算法可以分为几层

基础模型层 业务模型层 应用模型层

在基础模型层可以分为

内容侧和用户侧

在用户侧包括回归 分类 聚类

比较通用的常规的机器学习的模型

还包括跟搜索相关的一些LTR模型

或者推荐相关的

甚至还有一些数学建模

在内容侧有大量的NLP的工作

包括我们从字到词到句

再到段落 到整个文本

我们都做了一些工作

基于我们的一些基础模型

或者是业务模型

我们的业务模型针对的是某一个

具体的业务点进行建模

解决一些具体的问题

比如说我们的一些对事件抽取

对广告进行识别

对热点进行发现等等

对用户标签进行建设

建一个用户画像

包括我们对内容会打一些标签

类似于内容画像性的等等的

包括我们会做一些开播前预测

或者是开播后预测

流量预测等等

我们会对一些内容进行评分

对它的质量进行评分

我们会对它进行排序等等

像SCORE和RANK

在业务模型之上是应用模型

是我们具体落地的应用服务

或者是我们的应用产品

我们有剧本分析

对小说进行分析

所谓的分析是对内容进行分析

会对弹幕评论进行分析

可能跟舆情比较相关

我们对用户进行分析

对视频的质量进行评估

我们需要知道

视频中哪一段比较精彩

哪一段是高潮

哪一段是一个尿点 可以直接跳过

我们会对流量进行预测等等

讲得比较宽泛

前面这一部分讲的是大的框架

给大家概括性讲一下

我们包括什么东西