七种武器打造云视频平台【学习笔记】

听完讲座应总结,本次讲座是宋永柱(腾讯在线视频部\技术研发中心高级总监、P4专家)所分享的云视频平台的7个关键系统:长生剑:CDN全局实时调度系统;孔雀翎:海量视频的分发与存储;碧玉刀:视频的编解码系统;多情环:媒资库及管理系统(CMS);离别钩:视频的搜索/推荐系统;霸王枪:数据挖掘系统;拳头:高并发请求处理能力。而主讲人主要挑了长生剑、孔雀翎和霸王枪来讲。

先抓定义,宋永柱对云视频平台的定义如下:

基于云计算的视频平台,包括从视频的批量上传、存储备份、多码率转码、多CDN分发网络加速、视频内容制作、视频内容管理、自定义播放器、数据挖掘、高清视频播放等综合视频应用服务管理应用,通过云端服务器来实现。

随时,随地,个性化,多终端是其特征。

谈谈CDN全局实时调度系统

像腾讯面临的挑战是,全国的IDC结点总数多,但每个IDC的带宽和容量都不同,视频文件也不一样。这就好比一个蚁巢有很多大小不一的蚂蚁,发现食物时,蚁后不知要派哪只蚂蚁,多少蚂蚁合适?

腾讯的应对方法是:实时收集每个节点的带宽,动态调度每个播放请求,实时计算,不缓存,将数据,计算和策略分开。这个应对方法对于蚁后是难以实现的,但鉴于食物本身没有那个迫切要进入蚁巢的意识,所以蚁后的策略是自己不管,让蚂蚁们自己量力而行,中央不动,分布管理。

而实现中要将数据横向备份为分区,共享内存多实例,丢弃数据库,废弃缓存。

系统结构如下:

qjtd

由于一台机器比较合适的带宽输出是1.5G,对于码流是500K的视频,只能满足3000个同时在线,因此热播剧需要分步在多台服务器上才能正常服务→调度和同步需要实时交互。

其云视频业务请求服务的流程可以简单概括如下:

用户访问(页面中有视频)→(Media CMS)向用户发送302重定向报文,使用户转向CDN访问相应媒体文件→(CDN)查询资源并定位与用户最近的区域→(CDN)就近为用户提供视频文件

对于标准HTTP请求,只要将用户的HTTP请求重定向到云视频CDN,即可完成媒体资源的分发并提供相应的用户服务。

谈谈海量视频的分发与存储

腾讯视频所面对的挑战是,文件数量大,而文件播放频率呈现长尾效应,视频访问五次以下的占视频播放总量的30%以下,而热点视频的份数和节点也要保持一定的数量来满足用户访问。

与此同时,各个节点的带宽和存储容量也不统一,包括合作节点。

这里腾讯视频采用的是中心控制的方法:

1、设置一个知道所有文件位置,知道所有机房,服务器硬盘状态的中心服务器,来实现文件同步和删除。

2、自行开发Web服务器,优化IO

3、支持多协议,合并同步下载器和Web服务器

4、以分布式文件系统CDN来分发视频,文件分布在所有的CDN节点上

5、视频CDN同步采用PUSH模式,同步中央服务器完全控制同步文件和删除文件,并从调度处实时获取用户访问行为。

谈谈视频的编解码系统

由于用户上传和访问对应视频的码率和分辨率的不同需求,云视频平台也要具有转码中心的功能,实现多码率适配。

关于云视频平台的多码率适配,这里提供了常用的开源转码工具:

Handbrake:handbrake.fr/

Mencoder : www.mplayerhq.hu/design7/news.html

X264 : www.videolan.org/developers/x264.html

FFMPEG : ffmpeg.org

谈谈媒资库及管理系统(CMS)

先谈定义:

媒资库系统是一种多接口,数字化,网格化的海量媒体内容存储和管理平台,能满足视频存储检索,节目制作发布和内容版权管理的需求。

MTK

谈谈视频的搜索/推荐系统

关于视频推荐系统,目前视频网站主要分为两种,一种以用户产生内容为主(UGC网站);另一种是专业视频内容为主。这两种视频网站的内容和用户行为不一样,从而会导致相应的推荐系统的设计也会有一定差别。

下图PPT简单比较了两种网站的一些差别和推荐系统常用的算法(来自腾讯大讲堂微博内容):

2000

PS:YouTube公布说首页60%的点击来自于推荐,并且经过比较个性化推荐和最热门视频的点击率,结果前者的点击率是后者的2倍多。而Netflix则完全围绕推荐来进行。这里分享了推荐系统影响的权重,分别是产品(UI/UE)占40%,内容/数据占30%,知识库/运营占20%,算法只占10%。不知这个权重的数据是否也是从YouTube来的,用算法还是难以琢磨用户的心理,腾讯可以通过跨平台来整合用户行为来进行数据挖掘,这样将很有效地提高推荐成功率。

谈谈数据挖掘系统

先看看数据系统框架,如下:

 

wj

再看看宽表如下:这里我们可以分为解释变量(用户基本信息)、行为变量(交互行为)、价值变量(商业行为),腾讯挖掘出来的变量分别是21个、542个、72个,总共635个,而最后选用178个变量来分群,64个价值变量,114个行为变量。

kbsj

这里要谈到分群的定义:将客户划分到具有相同行为,价值和社会属性等不同组别的分享工具。

以下是分群模型:

fenqu

模型选择的标准:

1、分群之间互斥

每个客户只能落有一个客户分群中。

2、不同细分市场应当具备差别化的特征(效度)

· 同一细分市场的组成成分具有很多共同特征

· 不同的细分市场之间具有实实在在的区别

3、可操作性-可以针对不同的细分市场采取不同的行为策略

· 细分市场应特征明显,容易寻找和认同

· 能够识别细分市场的成员并针对性采取行为(如产品的研发、品牌定位、宣传、销售人员的选择和培训)

分群是否易于管理

· 分群个数不要太多,一般经验是7±2个群

前述客户分群分析是基于过去一段时间的历史记录进行的,并综合考虑了大量的行为和价值变量,建立的模型的机制保证了一定时间段内的客户分群稳定性。

这里分群示例见原PPT,这里提供一个例子:

√最高的平均搜索次数

√100%有搜索行为

√中等水平的观看次数

√100%有观看行为

√搜索技巧最为纯熟,懂得组合搜索,排行榜搜索等

√喜欢通过视频名称搜素

注意的是要将一些程度副词给量化,比如技巧到达要达到怎么样的行为标准才算纯熟等。

也可以用波士顿四象限图来表示:

用发展潜力为纵轴,ARPU为横轴,来分群自己的瘦狗,问题,明星,金牛用户。

谈谈高并发请求处理能力

单机服务能力是有限的,根据腾讯视频的经验,如下:

1、lighttpd并发超过600个请求,性能会明显下降

2、满足300万用户同时在线,至少需要54台单机服务器

如何提高单台机器的服务能力-IO:

tips:

—使用read/send来读磁盘和发送数据

—增加单词read读取大小

—自己实现对读磁盘操作的调度

· 针对硬盘做调度优化

· 针对网络层buffer中的不同链接数据量的差异做调度优化

效果:

单台服务器达到2500个链接,跑满2张网卡(1G*2)

运营优化经验:

不做raid,最大化每块硬盘IO(可以减少raid所消耗额外的磁盘空间,同时也减少了磁盘(无论是旋转式机械磁盘还是固态磁盘)在将数据写入RAID集时候必须进行的工作量,鉴于国内网速普遍不高,因此有必要来牺牲下吞吐速度)

√使用ext4文件系统,实测IO wait下降15%√使用deadline io scheduler,IO能力提高5%

修改硬盘的IO 调度算法:假设我们要对sdb进行操作,如下所示:

cat/sys/block/sdb/queue/scheduler

echo “cfq” > /sys/block/sdb/queue/scheduler

OR

echo “deadline” > /sys/block/sdb/queue/scheduler

最后用一张图片来结束这篇笔记:

 

kat_Full

By Ted on 2012 年 09 月 27 日 · Posted in My Exploration, My Prediction

Be the first to post a comment.