中国IDC圈9月2日报道,无数据不未来。数据是源头和动力,不同行业对于数据的管理,需要的服务的需求一定是不尽相同的。8月29日-30日D-Future数据时代峰会上芒果TV 平台部大数据团队负责人吴红和大家分享了怎么样解决数据采购的、介绍了芒果TV大数据平台架构与基础组件优化。

吴红

吴红

以下是吴红演讲内容(根据速记内容整理):

大家下午好,我是芒果TM的数据负责人,我主要是负责数据平台,今天主要是和大家分享一下是怎么样解决数据采购的。首先我介绍一下我们这个团队,我们这个团队是从去年开始筹建的,经过了8个月的发展,目前是10个人,现在差不多是有150多个结点,提供了一个150多台结点,通过1.5PB左右的数据,有三个业务系统,一个是一个是数据魔方,主要是一些指标的统计。第二个是推荐系统,今天上午爱奇艺的也说过了,我们如何把一些流量转化出来,可能需要一些引导性的东西,推荐系统是不错的选择,最后是视频内部的分析系统,很多互联网的数据可以转化成传统的媒体需要的数据,我们会把一些用户的记录,可以提供给导演选择一些精采的片子和剧情的发展。

我们现在数据的部门,支撑了70%-80%左右的数据业务。然后今天主要是说的分了三块,一块是基础篇,一块是整合篇,最后是数据管理篇。基础建设主要是分了采集,为什么要单独的说一下采集,在做大数据的过程中,数据的准确性是非常的重要的,采集是数据的生产方,决定了数据是否可用,这一块会单独的说一下,第二块是搜集,我们会关注的一个带宽的成本,我们做视频的公司的会非常的敏感,视频公司主要是版权和带宽的成本。

如果搜集这一块的带宽很高的话,会带来很大的支出,然后我们的整体架构是这样子的,前面的话,我们自己开发了一个SDK,把数据采集到了以后,会发送到我们自己定义的系统上,会进行一个汇聚,然后进行分类,一块发到FDS,一个是发到我们的队列系统,最终会转化成数据,形成数据仓库。

实时计算这一块的话,主要是会计算一些播放过程中质量的监控,还有一块,我们会到ES里面去,主要是做一些即时的查询。首先看一下采集这一块,可能大家看到了这个会比较熟悉,比如是上面列一个元素,然后吊一个方法,把所有的参数传送给服务商,但是会有一个弊端,随着采集点的增多,代码需要维护,第二个是没有一个系统性。实际上我们对这一块做了一些工作,主要是做了一个抽象,采集的过程中,我们会分为三大块,一大块是模板,我们采集的数据是可以进行一个分类的。比如说我们的页面数据和播放数据,以及错误数据。

还有就是事件,事件是因为什么触发。最后一块是配置,我们多了一个类似阿里的一个东西,这一块的话,主要是通过后端的配置,把一个元素的名称和一个事件整合起来,在页面加载的时候,会把这一块的配置加载到后端,后端会根据这些加载的配置来决定什么数据是需要上报的,什么是不需要上报的。

如果是我们需要一个很长的开发周期,使用这个模式的话,我们只要在后台进行一个配置,数据马上就会上来了。搜集这一块,一般我们采用的是放一个像素的图片,把一些参数带到这个图片的后面,这个过程会造成带款的成本非常的大。光是搜集带宽会占到600兆左右。我们可以把服务器的资源降到极值,可以改为PT进行篡数,我们做了一个对比,可以看到不同的数量级下面,保持了一个比较平均的一个比例,我们使用PB的话,可以减少原有的三分之一的数量,为我们节省了差不多三分之二的带宽的成本。

传输这一块,刚才超哥已经介绍过了。这一块的话,使用插片式的方式开发,可以很好的实现自己的利益。在使用的过程中,我们会踩到一些坑,最重要的是占用的资源是非常大的。实际上我们对每一块进行一个具体的分析,也不难解决这一块的问题,在数据量大的时候,会存在一些数据的情况。一个主要的特点每隔一段时间会建一个文件夹,实际上我们在前面做文件的时候,远远的会超于这个时间,所以我们会把这一块进行一个调整。另外的话,使用了一个单线层的方式。最后一块是做了一个很不错的优化,到了1.5,1.6以后,会直接导致系统的内存这一块的资源膨胀的比较厉害,所以我们对这一块有二种的解决方式,一种是会加一条配置的参数,第二条可以直接把位置去进行改掉。

一般是在类型和文件之间选择,主要是一个效率高的问题,这个之前,网上也有人提出了比较有效的解决方案,把这二者综合,在数据量高的情况下,使用文件。最后一块比如是在写FTX的时候,会导致文件关闭的状态,会导致我们的错误会失败,我们需要对这一块进行一些监控。另外一块的话,可能会产生很多的小的文件,会造成比较大的压力,所以根据自己的业务来调整,选择合适的文件的大小,这样子可以减少很多小的文件。最后一块的话,因为大数据,数据量肯定是很大的,在网络的传输过程中,我们也需要进行压缩,实际上我们使用的压缩的方式,这一块差不多可以压缩80%的数据量。

队列传输这一块,我们主要是用的Kafka。我们总结的经验是这样子的,并不是所有的分区越多越好。其实我们的分区越多的话,客户端和服务端所使用的限制内存也就越多,一个分区会产生二个文件,这二个文件会导致具体的数会增加,最后一块是因为Kafka的机制所导致的,如果是分区数过多的话,Kafka里面有一个页的分区,会产生投票的过程,分区数越多的话,使用的时间越漫长,也会影响使用。

我们会选择一台机器,只创建一个分区,然后测生产和消费这二边分别是怎么样的,我们最关心的是吞吐量,所以TP和TC的大值可以做我们的分区数。

然后是存储这一块往往我们说的存储会比较笼统,我们采用的方案是多级存储的方式。那就会有一个问题,当数据量增加的时候,会有很多的冷数据在那里,工作的压力会比较大,我去计算的时候,这样子会造成一些不必要的浪费,所以我们会分成三级,主要的特点是CPU和内存会比较丰富一点,第二个是少复本,这样子的话,我们可能只需要二个复本,最后一块是冷数据,这样子的话,实际成本会比我们之前的集群多很多。最终会把一些冷数据丢到云存储上面去。

那存储这一块,另外关心的问题就是压缩的问题,存储这一块空间是一个很重要的问题,我们在做的过程中,我们也发现了这个问题,往往我们前期没有规划好的时候,我们会发现存储的空间已经不够用了,我们可能需要对存储进行一些压缩,这一块的话,我们需要根据自己的业务去选择。使用日志归档对小文件进整理。

计算这一块的话,因为都是比较成熟的。象离线计算这一块的话,有二个比较需要关注的点,一个是资源分配这一块,最多的一块是队列这一块,需要特别的做一些信心的工作,这一块的话,有二块,一个是二分之一CPU,摸索的是按照1核来使用的,很多的业务我们并不需要CPU这么的值,我们可以选择二分之一的CPU,可以满足使用内存量比较大的业务。

另外是实时计算这一块,我们是采用的Starm的方式,我们要做一个数据平台的话,主要是控制和资源管理,Starm是不显示这一块的工作的,通过这一块可以进行一些管理的操作,包括一些日志的图表的显示,根据图表来分析我们Starm上的运行的情况。

即时查询这一块,主要是和我们的技术人员比较相关一点,因为我们经常在开发的过程中,经常会报错,实际上我们是需要一个比较好的产品平台的。这块的话,我们使用的是我们自己开发的Dek,可以做一个索引的程序。在索引的过程中,我们尽量的把复复本和falsh关掉。接下来从它的的索引的协议上做一些工作,大部分的选择索引的过程中,如果是在我们网络允许,或者是在比较好的情况下,可以尝试一下TCP。

如果我们单从文本上做归类的话,会导致内存缺失的情况,所以我们会形成一些数字型的工作,最后是要做一个比较相对开放的平台,这一块是必须要做的。否则的话,别人就会干掉另外一块的索引。我们现在每天的索引是30TB的数据。

组建的整合,这个和我们公司的业务会比较相关,在业务的过程中,这个数字会非常的难看,而且会产生商务上的一些纠纷。我们需要把这些配置进行一个统一的管理。接下来就是一些权限的管理。

其实配置这一块的话,我们主要是把配置整合起来,进行推送的工作,主要是机遇RPC的控制模型,对所有的组建进行全员的控制。我们的数据服务平台需要支持公司很多的业务线,他们只需要一个帐号就可以进行我们的采集服务机数据传输服务,实时计算服务,我们也可以提供资源流量监控的服务,包括提供资源使用的菜单。

接下来的话,主要是说一下如何管理平台上的一些数据。主要是几块,一个是日志种类抽象,这个其实是和公司的业务会息息相关,我们这一块的话,分了播放类的日志,广告类的日志,为什么需要指标定义单独的拿出来说一下,有一个特别有意思的地方,在芒果TV,更关心的是VV,TV,PV这些核心的指标,但是如果是我们计算的指标的方式和爱奇艺的不一样,这个数据在行业内是没有一个可对比性的,所以会从几个方面去定义,一个是它的概念,运用的常理是怎么样的,是怎么样上报的,会导致数据统计出来的结果,可能会千差万别。

最后是上报内容和计算公式。数据到了平台以后,最重要的是对数据进行管理,为什么会要做一些管理,其实为了把这些数据进行一些分门别类,我们所产生的就是主题式的管理,某一个点为核心,你必须关注哪一些方面,我们会分为几类,这个和我们的日志抽象会非常的相同。数据仓库只是一个数据结合的地方,但是数据仓库的价值需要上层利用做一些工作。

这一块的话,主要是数据的管理,数据仓库建立以后,别人要使用你仓库的数据,需要一个明细,我们需要做一个数据的数据,这个原数据分了二类,一类是技术性的原数据,主要是给我们的技术开发人员使用的,包括了一些仓库的结构,就是我们是怎么从原始性抽取的一些规则,这个是需要从公司出来的,不然的话,数据没有质量可言。

最后为什么要做数据集市,在这个过程中,每一个公司会有多个业务部门,每一个业务部门的话,所面临的是不一样的,比如是从统计的角度,会更关注数据,分析的话,有分析的角度,但是这样子的话,数据仓库没有办法稳定,需要数据集市进行隔离,在这个过程中,我们可以把一些数据抽出来进行一些队列,放到我们的关系成本里面,这些集市之间的结果是可以进行分享和交换的,有利于数据的共享,更重要的是在于事实表和维表的管理和维护,这样子有利于数字队列的操作,谢谢我就说这些。

关注中国IDC圈官方微信:idc-quan 我们将定期推送IDC产业最新资讯

查看心情排行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党
2015-09-02 10:19:00
大数据资讯 美图网杨尚刚:数据库运维和性能优化之路
8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵,数据库优化是一个很大的问题,迄今为止一直困扰着所有的数据库管理员和程序员 <详情>
2015-09-02 10:13:56
大数据资讯 携程数据架构建设和平台服务化的实践
8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵,会上携程网的架构专家杨晓青,给我们带来携程数据架构建设和平台服务化的实践 <详情>
2015-09-02 09:51:00
大数据资讯 一号店陈敏敏:电商场景下的千人千面和实时意图实践
8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵,会上一号店精准化部门架构负责人陈敏敏以《电商场景下的千人千面和实时意图实 <详情>
2015-09-02 09:38:00
大数据资讯 贝贝网:特卖场景下的大数据平台和机器学习实践
8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵,如何快速的建设技术体系,发挥技术的价值。会上贝贝网大数据负责人周黄玲以《 <详情>
2015-09-02 09:32:35
大数据资讯 乌云章华鹏:成长型互联网的数据安全
8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵,会上乌云章华鹏以《成长型互联网的数据安全》为题给大家带来了精彩的演讲。 <详情>