吴红：芒果TV大数据平台架构与基础组件优化

互联网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这些核心的指标，但是如果是我们计算的指标的方式和爱奇艺的不一样，这个数据在行业内是没有一个可对比性的，所以会从几个方面去定义，一个是它的概念，运用的常理是怎么样的，是怎么样上报的，会导致数据统计出来的结果，可能会千差万别。

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

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

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