案例分享｜Alluxio在媒体融合领域的应用

分享嘉宾

桂静，就读于中国传媒大学计算机与网络空间安全学院，媒体融合与传播国家重点实验室，导师为王永滨教授。已发表论文三篇。其中 SCI 论文1篇。参与多项国家级以及省部级子课题项目。致力于媒体融合领域数据存储与处理关键技术研究。

分享大纲媒体融合介绍；
中国传媒大学在 Alluxio 上的应用场景；
探索 Alluxio 在媒体融合领域潜在的应用场景；

观看完整分享

媒体融合介绍

媒体融合的概念

融媒体的特征包含内容多模态、采集/发布多渠道、组织多主体。融媒体是媒体融合的产物，可以从融媒体的角度理解媒体融合的模式。

多模态

从数据的角度切入看内容多模态，又可以分为数据类型多、数据格式多、数据多源，其中数据类型主要包含文本、图片、视频、音频以及时序数据：

• Text (新闻稿、日志、评论)
• Images（新闻图片、视频帧）
• Audio（电视节目、短视频）
• Video（广播节目、音乐、配音）
• Time-Series Data（广播信号)

数据格式是比较常见的三大类：

• 结构化
• 半结构化
• 非结构化

数据多源的问题在数字媒体领域是最直观的，因为在制作新闻和节目的时候，第一步并非数据采集，而是策划，策划完成之后会再对策划的内容进行数据采集，数据多源的“源”可以映射到全世界。

多主体
多主体包含：传统媒体机构、新媒体机构、自媒体机构、政务媒体、企业媒体、商务主体、生活主体、娱乐主体、教育主体

多渠道

多渠道包含：纸媒、广播、电视、网络广播、IPTV、微博、微信、小红书、快手、抖音、网络电视、手机电视、视频网站、互联网直播

渠道主要是媒体内容的发布渠道，而在发布的选择上肯定会首选流量大的渠道，比如小红书等主流媒体平台。

媒体融合发展历程

下面我们再来了解一下媒体融合的发展历程，媒体融合的概念其实是一个舶来品，最初是媒介融合的概念，大概在 2005 年引入中国，经过多学派学者思想的碰撞，衍生出了媒体融合的概念，2013 年习总书记在全国宣传思想工作会议上提出要加快传统媒体和新媒体的融合发展，至此媒体融合发展就上升到了国家战略层面，各种媒体融合的产物也如雨后春笋一般涌现在大众眼前，听得比较多的就是两微一端：微信、微博和客户端。

2015 年还有一个比较火的就是“中央厨房”的模式，最开始是人民日报和新华社在节目制作的流程上以及整体的组织架构上进行了一系列创新，这种方式加快了新闻的传播、增强了时效性和影响力，一直到 2016 年，全国范围的市、县级融媒体开始出现，这些融媒体中心的出现主要是为之前的县级电视台、广播、报社等单位提供融媒体服务。

融媒体平台更多还是在省级单位建立 ，主要是由于市、县级单位在技术、数据管理等方面还存在落后情况，如果建立了融媒体平台，市、县级融媒体中心就可以接入到融媒体平台，依托于媒体平台的技术、资源发展自己的媒体服务，到2023年开始出现一轮新的趋势，就是融媒联合体，最开始出现在四川，四川政府建立了一个以四家省级媒体和 21 家市、县级媒体，以及 185 家其他媒体机构为主体的媒体“航母”，它的媒体能力肯定是要比融媒体平台、融媒体中心更加全面。

下面详细介绍一下几个媒体融合平台的建设现状，上图列举的是一些比较经典的融媒体平台，比如湖北省的长江云，江苏省的荔枝云，西藏的珠峰云以及吉林的天池云等，需要重点关注的是现在这些融媒体平台采用了混合云的架构。电视台之前采用的传统架构一般都是物理机+文件系统（可能是 lustre ），再后面是 SAN、NAS ，最后是存算一体的超融合架构。现在各个平台陆续开始上云，采用了公有云平台和私有云平台。公有云平台主要负责整个媒体机构的数据采集，大数据的挖掘、数据分析、新媒体的生产分发等任务，私有云平台主要是应对传统的电视、广播节目的制作，因为传统的广播、电视节目需要一定的时效性和安全性，所以大家更多会采用传统的架构模式，保证数据的稳定性，更高的性能、更高的响应速度、更高的安全性。这时候就会产生一个问题，在公有云和私有云平台之间会出现一些数据孤岛，以及一些数据如何流转的问题。

中国传媒大学在 Alluxio 上的应用场景

多语言新闻监测分析平台

第二部分详细介绍一下中国传媒大学实验室在 Alluxio 上的应用场景，主要是在一个多语言新闻监测分析平台上使用。最初做这个平台是为了对境外的一些媒体数据进行采集，供实验室舆情分析使用，为舆情分析提供数据支撑。采集对象包含了 40 多个国家，32 个语种，400 多个境外媒体，当时的总监测量达到 300 万篇，目前这些数据也在逐渐增加。

以下是中国传媒大学新闻监测平台的架构：

这个平台一共分为两层，上层是业务层，下层是资源层。业务层提供了一些新闻服务，包括新闻聚类、相似性计算以及新闻摘要的生成。这些内容为上层应用提供了定制化的服务，比如国家发改委的系统、国家汉办的系统以及外交部的系统。

底层的资源层又分为计算层和存储层。计算层分为数据清洗、数据去重、数据标注和模型训练；底层的存储层主要包含本体库、新闻素材库以及平行语料库。新闻素材库是平台采集到的原始数据存储的地方，平行语料库存储处理后的数据。其中平行语料库存储的内容是对于每一个事件，在各个国家、各个语言的新闻对这个事件的描述关键词。

计算框架主要是 Spark、Tensorflow、Pytorch。Alluxio 在这个中间提供数据缓存功能，对接的底层存储系统是 HDFS 和 Ceph。在实验室的应用场景中，把数据缓存在 Alluxio，省去了一些数据传输的开销，比如上层计算到底层存储拉取数据的时候，将数据缓存在 Alluxio 中，这样就可以直接通过 Alluxio 读取数据，而不用再去底层存储一遍一遍的访问，另外在 Alluxio 上缓存了多语言模型，供多个上层应用取用，这个数据加速的功能在实验室的环境上是有一定程度的加速的，但并不像真正的云环境和本地环境之间的效果那么明显，因为实验室的环境是一个局域网环境，所以在任务加速方面是有一点的，但这更多是受环境因素的限制。

新闻文本存储问题 - 问题分析

前面提到，这个系统的数据量其实是相对比较小，因此使用 Alluxio 承载它的任务是完全够用的，但是存储空间有限，想在有限的空间上提高存储利用率，同时考虑到未来新闻的数据量会越来越大，还要面对横向扩展或者纵向扩展的问题，所以团队就产生了研究动机，要在 Alluxio 上对新闻文本的存储进行优化，下图表示的是 Alluxio 读取数据的流程：

图中可以看到在 Alluxio 2.x 的版本上，是 Alluxio+HDFS 架构，所有的数据访问都需要通过 Alluxio Master 节点访问文件元数据，所有的读和写都需要通过 Master 访问文件元数据。这种情况下如果是同数据量的小文件和同数据量的大文件相比，可能需要访问上千次的 Master 获取同数据量的小文件，但是只需要访问一次就可以访问到大文件，这个对Master节点的IO产生了性能瓶颈。

第二个是在元数据服务内，文件元数据大概在 1 至 2kb，2亿文件大概在 200 至 400GB，如果继续一个单节点 Master，2亿小文件打满的状态下，需要 200-400GB 的存储容量，但可能没有一个 200 至 400GB 内存的机器，也就由此产生了研究动机，需要优化这个点。如今很多企业对小文件的读优化是将数据和元数据缓存在客户端，其实在小文件的优化上也是这种方式，下图是对 Alluxio 的 IO 性能进行的测试：

存储使用的是 HDFS，写类型是 MUST_CACHE，读类型是 NO_CACHE，将同数据量的一个文件进行读写，然后文件的大小最小是 2k，最大到 4G，这个表就可以看出来，Alluxio 的小文件吞吐量和大文件的吞吐量存在指数级的差别。

小文件存储优化方法

基于这个动机，团队研究了一些小文件的读取优化方法。前面提到的把元数据缓存在客户端也是一种方式，除了这种还有一种就是像 Facebook Haystack 和淘宝的 TFS，他们定制了小文件或者小对象数据的存储系统，这两个都是为图片的存储而定制的，HDFS 本身存在四个小文件存储系统的优化方法，其余不同的场景可以选择不同的存储方式。

研究现状中关于 Alluxio 的一篇论文值得我们关注，这篇论文是由卡内基梅隆大学的范斌博士发表的，内容讲述的是在Alluxio 上实现了一个小文件的打包与索引，出发点非常有意思，发现如果在云服务商上传或者缓存同数据量的小文件比大文件要贵很多。所以把 Alluxio 作为一个打包的客户端，Alluxio 所有挂载点上文件系统里的数据都可以进行打包，而且是基于不同的打包策略，然后再把打包后的数据上传到云端，这个过程大概实现了两万五千倍的成本压缩。它的打包方式就是把很多小文件合并成大文件，形成一个 blob 文件，然后将海量小文件的元数据放在这个 blob 的页脚，这样在访问这个小文件的时候，需要从 blob 文件一直读到页脚，这是一项高成本的任务。于是，它就把每个 blob 页脚的文件元数据给拿出来进行映射并存储在blob描述符表( BDT )中，相当于维护一个冗余的全局索引文件。这样可以达到性能上的提升，访问小文件可以更快。

HDFS中的小文件存储优化方法

通过调研我们发现，Alluxio 和 HDFS 的架构非常像。Alluxio 的小文件存储优化其实可以参考的资料非常少，所以就对HDFS 上的小文件优化做了调研，2022年的时候有这样一篇文章（ HPF ），它是基于文件合并以及元数据索引做小文件的优化，在内存空间占用、生成大文件的成本还有读性能方面都达到非常优秀的效果，基于这个内容实验室对新闻存储进行了一系列优化，在看到这篇论文的时候对于在 Alluxio 上做小文件的存储优化也有了一些新的想法。

基于Alluxio 的新闻文本存储优化

Step 1：基于目录聚合的新闻文本合并策略

这个部分做的就是基于目录的新闻文本合并，先把一个新闻目录里的文件合并成一个大文件，对于新文本的元数据重新设定，不再使用本身的文件元数据，制定四个字段的文件元数据，包括文件名、小文件在大文件里的文件位置、文件数据量和文件大小，基于这个文件元数据就可以在大文件中还原出来小文件。

Step2: 基于完美哈希算法的新闻文本元数据索引构建

第二个方式是小文件合并成大文件之后就不可避免的需要做两次查找，这样的情况下，文件访问性能就有损失，所以在第二部分对文本元数据的索引进行了构建，使用的是最小完美哈希算法。

这个方法的功能是：有一个索引表，以前没有最小完美哈希可能需要从头读到尾，这种情况做的查询是比较慢的。如果使用了最小完美哈希算法，把文件名放到哈希函数就可以定位到这个文件存在哪，直接通过位置映射就可以从哈希表中找到小文件位置，然后读取它的元数据，从元数据定位到小文件的合并文件并且读取就可以了。

基于 Alluxio 的新闻文本存储优化

接下来这个是实验室做的存储优化在 Alluxio 上的三个模块。第一个是合并模块，对不同大小的文件进行过滤，如果特别小的文件，比如小于 2KB，把它的元数据进行合并；如果是大于 2KB，小于 2MB，就把它当成是小文件进行合并；第二个是元数据管理模块，其实就是前面的完美哈希表，把它放到 Alluxio Master 里边；第三个是合并文件的存储模块，负责合并后文件的读取。

下图是实验结果，使用了三种最小完美哈希算法，包括CHD、GOV、BBHash，对这三个的构建时间、查询时间、空间占用情况对比发现，GOV 的效果最好；然后用自建的数据集对合并前和合并后在 Alluxio 上内容空间占用情况进行了比较，也是一个指数级别的减少，还有一个就是文件读取时间，与 Alluxio 原来的数据比较，也是 GOV 的表现最好。

Alluxio 的潜在应用场景

应用挑战

该部分主要分享 Alluxio 在媒体融合领域潜在的应用场景，刚才提到的那种混合云的架构模式其实是存在问题的：

• 多主体媒体接入融合平台时，缺少统一的数据接口。其实每一个媒体都有自己的媒体内容库，他们的存储系统也是不一样的，就算是 HDFS 可能也会存在不同的版本，那么在业务中遇到这么多存储系统、这么多存储系统的版本，想要做到高效的兼容，这个场景 Alluxio 就可以发挥很好的价值。
• 传播渠道和业务类别有差异，比如对传统的广播媒体和互联网短视频进行数据分析时，这两个部分的内容可能是存在于不同的部门，他们之间存在数据孤岛，这两个部门没有进行对接也不知道怎么进行对接的情况下，就可以在混合云平台上搭建一个Alluxio 的缓存平台进行数据共享。
• 本地私有云与外部公有云服务共存，导致数据引流、倒流、迁移、确权、管理难度增大。
• 数据资产增值率并不高，流量变现能力弱，而数据运维和管理成本又居高不下，需要重点关注的就是如何在降低成本的同时，提高数据资产的变现。数据资产的变现措施有待进一步探究，但是降低成本的措施是有迹可循的。可以看如何在数据管理方面降低成本，比如减少数据副本，在租赁云服务器时所需要的空间就会减少。

媒体融合服务模式

这个部分是实验室提出的“多方主体协作共享融媒体服务模式”，在多媒体主体合作的场景下提出了这样的合作模式。因为媒体融合的发展问题也非常多，基于对100+家媒体的调研形成了一个协作共享的模式，这个模式是广电主体、互联网的主体都接入融合平台，使用融合平台的技术实现业务发展，同时多主体又对融合主体提供数据，以数据驱动融合平台的融合业务和协同管理，底层的数据支撑就依赖大数据、人工智能以及区块链技术。这个架构只能看到三方主体，第四方主体并没有在架构中体现，第四方主体其实是公共服务主体，这个融合主体也可以为政务系统提供一些融合服务。

Alluxio 潜在应用场景（一）

这个系统细化来讲可以如图所示：

整个架构图很像一个“螃蟹图”，这只“螃蟹”最丰富的是中间“蟹黄”的位置，就是融合平台。它的架构其实也是基于云平台架构，包含基础设施层、平台服务层与软件服务层，这些可以为媒体服务进行赋能。除了中间的位置外，“蟹脚”是多主体，包括电视、广播、报业主体、互联网用户，它们拥有自己的媒体资源库。这些主体在接入主平台的时候需要“关节”，所谓的“关节”就是接入节点，接入节点主要负责节点的加入和退出，还有核心应用层所包含的媒体资源管理等。在这个场景下 Alluxio 可以做什么呢？

主体有自己的媒体资源库，平台又是云平台架构，这个时候如果要做多主体媒体数据资源共享和交换的时候，就可以用Alluxio 做中间层。因为自己的私有云和公有云中间要做数据共享，会有很长的网络带宽，这时就可以在平台的两端搭建 Alluxio，平台需要各个主体数据时，就可以直接通过 Alluxio 做缓存。但有些数据存在安全要求和版权要求，并不是所有的数据都可以直接由各个主体发送给平台端使用，这个时候就需要平台将计算任务分发给各个主体，主体在本地做任务，这个阶段 Alluxio 除了可以缓存数据外，还可以通过统一命名空间的能力统一多个主体的数据接口。

Alluxio 潜在应用场景（二）

第二部分就是因为现在很多主流媒体都在做自己垂类大模型的训练，比如人民网有自己的“写易”大模型，央视网有自己的“智策”大模型，他们是基于通义千问做的，中央广播电视总台在做自己的“央视听媒体大模型”、芒果TV在做自己的“芒果大模型”。期待后续Alluxio可以在各个大模型的训练和推理、部署场景发挥自己的优势。