弹幕处理方法及系统

技术领域

本申请涉及数据处理技术领域，尤其涉及一种弹幕处理方法、系统、电子装置及计算机可读存储介质。

背景技术

随着计算机技术的普及与发展，视频网站的用户越来越多。而在观看视频时发送弹幕进行互动，也逐渐成为视频网站用户的习惯。弹幕，指的是在网络上观看视频时弹出的评论性字幕，可以给观众一种“实时互动”的错觉。弹幕工程建设发展到现在，需要在高并发、热点场景下，保证弹幕服务的稳定和高可用，并且以优化视频消费体验为目标，筛选优质弹幕内容上屏展示，建设千人千面的弹幕推荐能力。

发明内容

本申请的主要目的在于提出一种弹幕处理方法、系统、电子装置及计算机可读存储介质，旨在解决如何在高并发、低延迟、高可用性、高稳定性保障的场景下，进行弹幕内容个性化推荐的问题。

为实现上述目的，本申请实施例提供了一种弹幕处理方法，所述方法包括：

将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池；

根据客户端用户观看的视频标识和时间段，从所述弹幕召回池中获取相应弹幕信息，根据特征算法进行筛选后，展示至客户端。

可选地，所述弹幕召回池包括物料池和索引池，所述物料池用于保存弹幕物料，为弹幕的基础数据；所述索引池用于保存弹幕索引，为与所述物料池对应的每条弹幕的模型评估结果。

可选地，所述方法还包括：

在无需更新粗排模型的情形下，通过索引回刷仅更新所述弹幕召回池中的弹幕索引，以实现模型策略迭代。

可选地，所述方法还包括：

在需要更新所述粗排模型的情形下，通过物料回刷同时更新所述弹幕召回池中的弹幕物料和索引，以实现模型策略迭代。

可选地，所述弹幕召回池为键值数据库，将一个视频第一预设时段内经过召回的弹幕保存在一个键对应的值中。

可选地，所述物料池和所述索引池在所述弹幕召回池中以不同的键分开存储，数据一致性通过Redis分片锁保证。

可选地，所述将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池包括：

从所述弹幕数据库中获取弹幕物料，通过粗排模型对每条弹幕进行评估；

聚合第二预设时段内的所有弹幕物料，根据评估结果对所述第二预设时段的所有弹幕进行排序和淘汰；

针对未淘汰的弹幕通过全部模型进行评估，根据评估结果得到弹幕索引；

将未淘汰的弹幕物料列表和索引列表分别存入所述物料池和所述索引池。

可选地，所述时间段依照用户当前观看的视频播放时间点和服务端根据应用场景动态下发的分片大小进行确定。

可选地，所述根据特征算法进行筛选包括：

基于预设的特征算法，包括用户特征和视频特征，建立个性化推荐的精排逻辑，对相应弹幕通过全部模型进行评估，然后根据所述评估结果进行排序和截取，返回推荐结果。

可选地，所述索引回刷包括：

获取高热视频列表和实时增量视频列表；

将所述高热视频列表和所述实时增量视频列表对应的弹幕通过全部模型进行评估；

根据评估结果得到新的索引，将所述新的索引更新至所述弹幕召回池。

可选地，所述物料回刷包括：

获取全量弹幕和实时增量弹幕；

通过粗排模型对所述全量弹幕和所述实时增量弹幕进行评估；

根据评估结果排序和淘汰弹幕后，对未淘汰弹幕通过全部模型进行评估，得到新的索引；

将所述未淘汰弹幕的物料和新的索引更新至所述弹幕召回池。

此外，为实现上述目的，本申请实施例还提供一种弹幕处理系统，所述系统包括：

召回模块，用于将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池；

展示模块，用于根据客户端用户观看的视频标识和时间段，从所述弹幕召回池中获取相应弹幕信息，根据特征算法进行筛选后，展示至客户端。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的弹幕处理程序，所述弹幕处理程序被所述处理器执行时实现如上述的弹幕处理方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有弹幕处理程序，所述弹幕处理程序被处理器执行时实现如上述的弹幕处理方法。

本申请实施例提出的弹幕处理方法、系统、电子装置及计算机可读存储介质，能够提供一种工程系统和算法系统深度结合的方案，在百亿数据量级、高并发、低延迟场景下，进行弹幕个性化推荐，提升数据一致性、稳定性，并优化了上屏弹幕的质量，提升了用户互动体验。

附图说明

图1为实现本申请各个实施例的一种应用环境架构图；

图2为本申请实施例中维护的两套系统的示意图；

图3为本申请第一实施例提出的一种弹幕处理方法的流程图；

图4为本申请第一实施例中弹幕发送链路的示意图；

图5为本申请第一实施例中弹幕展示链路的示意图；

图6为本申请第二实施例提出的一种弹幕处理方法的流程图；

图7为本申请第二实施例中索引回刷的示意图；

图8为本申请第二实施例中物料回刷的示意图；

图9为本申请第二实施例中模型版本控制的示意图；

图10为本申请第三实施例提出的一种电子装置的硬件架构示意图；

图11为本申请第四实施例提出的一种弹幕处理系统的模块示意图；

图12为本申请第五实施例提出的一种弹幕处理系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

请参阅图1，图1为实现本申请各个实施例的一种应用环境架构图。本申请可应用于包括，但不仅限于客户端2、服务器4、数据库6的应用环境中。

其中，所述客户端2用于向用户显示当前应用的界面，例如视频网站界面，接收用户发送的弹幕及在播放视频时向用户展示相应弹幕等。所述客户端2可以为PC(PersonalComputer，个人电脑)、手机、平板电脑、便携计算机、可穿戴设备等终端设备。

所述服务端4用于为所述客户端2提供数据和技术支持，例如根据数据库6中的弹幕信息进行模型评估和粗排、淘汰后，保存至物料池和索引池，根据用户观看的视频标识(ID)和时间段，从所述物料池、索引池中获取相应弹幕信息，进行精排、截断后，展示至客户端2。所述服务端4可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。

所述数据库6包括用于存储全量弹幕信息的关系型数据库和存储弹幕召回池的键值(Key-Value，KV)数据库，其中所述弹幕召回池中包括弹幕物料和弹幕索引。所述关系型数据库可以是TiDB数据库或其他任意可行的关系型数据库，在后文中以TiDB数据库为例进行说明。TiDB数据库是一种分布式关系型数据库，同时支持在线事务处理与在线分析处理(Hybrid Transactional and Analytical Processing，HTAP)，适合高可用、强一致要求较高、数据规模较大等各种应用场景。KV数据库是一种以键值对存储数据的一种数据库，每个键都会对应一个唯一的值。KV数据库查询速度快、存放数据量大、支持高并发，非常适合通过主键进行查询，但不能进行复杂的条件查询。

所述服务端4和一个或多个所述客户端2、所述数据库6之间通过无线或有线网络通信连接，以进行数据传输和交互。所述网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，GSM)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等。

在现有的弹幕推荐方案中，当用户发送弹幕时，工程系统通过数据库Binlog同步给算法系统。所述Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志。在展示侧，由算法系统负责计算对应视频要展示的弹幕ID列表，工程系统获取弹幕内容最终返回。这样就实现了一个具备基础能力的弹幕推荐方案。但是，这种方案依赖一个弹幕池的设计，基于视频的长度确定一个视频内可展示弹幕数的上限。当弹幕池满了，会按照时间倒序淘汰，留下最新的N条弹幕。例如，一个15分钟长度的视频，弹幕池上限是6000条。

这个设计会带来以下的问题：由于弹幕池上限比较小并且分布不均匀，经常出现弹幕填不满屏幕的情况。另外很多长视频的大量弹幕集中出现在开屏打卡，这部分重复内容会挤占整个视频的弹幕池，导致后面大段内容出现弹幕空屏。因为弹幕池整体较小，候选集有限，选出优质内容的空间较小，同时因为时间序淘汰，很多优质历史弹幕无法召回，非常影响弹幕质量。

本申请实施例提出了一种新的弹幕处理方法及系统，以工程系统和算法系统结合的整体视角来进行设计优化，从视频分片、召回池大小、索引回刷、计算量、退场逻辑、实验能力等各个方面提升了个性化弹幕推荐方案的处理效果，数据一致性、稳定性都获得了大幅提升，并可以给用户带来更优质的弹幕消费体验。

弹幕处理的两个核心场景是，用户发送弹幕时以弹幕维度的唯一ID作为主键存入数据库，同时关联视频ID；在需要展示弹幕时，以视频+分片维度一次性读取数据库中的弹幕信息，例如一个视频6分钟分片的全部弹幕。在本申请各个实施例中，一共需要维护两套弹幕系统。线上维持两套系统的常见问题是职责边界和关系不清晰，导致在迭代中逐渐走向混乱。因此，本申请实施例对两套系统做了明确的职责划分和关系定义。如图2所示，为本申请实施例中所述两套系统的示意图。其中一套是现有的弹幕系统(图中的原弹幕系统)，主要用于负责整体的弹幕业务逻辑，以TiDB数据库存储全量弹幕信息。另一套是新的弹幕处理系统(图中的个性化推荐弹幕系统)，主要用于进行个性化弹幕推荐服务。新系统以KV数据库作为个性化推荐的召回池，是TiDB数据库的子集。同时，在弹幕消费这一主要场景下，原系统以线上热备的形式维护。在新系统出现故障时，可以自动降级至原系统，使用户侧无感。

作为视频网站的核心功能，弹幕的读写场景都要随时应对高并发流量以及突发的热点场景。所述原弹幕系统主要用了一套三级缓存的结构：

第一级缓存的键(Key)为视频ID+分片，值(Value)为具体的弹幕内容，为接口级缓存，直接承接客户端2的读流量。第二级缓存的Key为视频ID+分片，Value为弹幕ID，用于维护弹幕池内的弹幕ID列表，创建时间倒序淘汰。第三级缓存的Key为视频ID，Field为弹幕ID，Value为弹幕内容，数据结构和数据库一致，减轻回源压力。在第一级缓存发生缺失(Miss，即要访问的数据在缓存中未命中)之后，先通过第二级缓存获取当前视频分片的弹幕ID列表，然后从第三级缓存获取具体的弹幕内容。在第二级缓存到第三级缓存之间存在弹幕数量的读放大，若当前视频的6分钟分片有1000条弹幕，就会产生1000倍的读放大。若第三级缓存发生缺失，则会回源到底层存储TiDB数据库。

由于所述原弹幕系统的上述存储架构相对复杂，在容量扩展上，很难支持个性化推荐的业务诉求。同时视频维度时间序列淘汰这一固定逻辑也很难变更。因此，本申请实施例重新搭建一套新的所述个性化推荐弹幕系统。新系统在展示侧的核心链路不变，仍然是通过人工智能(Artificial Intelligence，AI)算法的精排接口获取弹幕ID，在内部存储中读取弹幕内容，渲染并返回。新系统的核心目标是最大限度扩大召回池容量，同时选用基于模型的召回策略并支持回刷，因此需要简化存储并提升计算能力。

新系统的职责边界是只满足读弹幕的个性化推荐这一个最核心场景，因而在存储上不需要存全量弹幕，也不需要支持复杂的业务逻辑和查询能力。基于这样的场景特点，可以放弃关系查询支持，因此选择了KV数据库进行数据存储，将一个视频第一预设时段(例如一分钟)内经过召回的弹幕存在一个Key中。同时，单条弹幕也以弹幕ID作为Key进行存储，用于处理弹幕状态或其他元数据的更新。因为KV数据库不支持事务，可以通过远程字典服务(Remote Dictionary Server，Redis)分布式锁保证并发场景下的数据一致性。受益于KV数据库强大的读写并发能力，在场景有读放大的情况下，仍然可以选择不加缓存直连数据库的最简单存储结构。经过实验证明，这种存储结构完全可以承受百万级的并发访问量。

并且，在所述个性化推荐弹幕系统中，多处使用到了分片的概念，用来聚合单位视频长度下的弹幕内容，具体包括：

在展示接口层，如果一次下发的分片过长会造成带宽浪费，例如下发10分钟的弹幕，用户看1分钟就退出了。但如果分片过小，又会因为请求轮询导致服务端每秒查询率(Queries-per-second，QPS)变大。在本申请实施例中，服务端可以根据应用场景动态下发分片大小，从而节约带宽。

同样，在存储上主要的平衡点是读数据时的请求放大和数据更新时的颗粒度。在所述原弹幕系统中，如果弹幕池存满是基于时间序列倒序淘汰。新系统选择视频第二预设时段(例如每10秒钟)的弹幕作为最小的策略单元进行弹幕淘汰，可支持10秒1000条弹幕的召回空间，按照AI策略提供的粗排模型打分进行淘汰，从而满足策略目标，让弹幕足量且均匀。

这套架构通过召回池存储容量的整体扩充，以及弹幕淘汰的策略颗粒度提升，使弹幕召回池扩充至原来的10倍左右。假设视频是15分钟，召回池的弹幕上限就从整个视频6000条升级到每10秒1000条，曝光上涨30％，大大提升了消费体验。

所述个性化推荐弹幕系统将工程系统和算法系统深度结合，工程系统用于物料、索引的存储以及淘汰，算法系统用于粗排、精排的模型打分和策略。各个部分的具体功能在后续各个实施例中将会详细介绍，在此不再赘述。

实施例一

如图3所示，为本申请第一实施例提出的一种弹幕处理方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述服务端作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池。

所述弹幕数据库是指所述原弹幕系统保存全量弹幕信息的TiDB数据库。当客户端用户发送弹幕时，弹幕信息通过弹幕网关层传输至所述原弹幕系统，保存至所述弹幕数据库中。所述弹幕数据库中的弹幕信息通过数据库binlog同步至所述个性化推荐弹幕系统。

所述弹幕召回池是指所述个性化推荐弹幕系统保存召回的弹幕信息的KV数据库。所述弹幕召回池将一个视频第一预设时段(例如一分钟)内经过召回的弹幕存在一个Key中。在本实施例中，将物料池和索引池合并在所述弹幕召回池中，以解决物料池、索引池各自进行淘汰导致的数据不对齐问题。也就是说，所述弹幕召回池包括但不限于物料池、索引池及弹幕物料库。其中，弹幕物料指弹幕的基础数据，包括内容、状态、点赞、举报、属性标记等。弹幕索引指弹幕的全部模型评估结果(打分)，所述全部模型包含基线模型(即粗排模型)、点赞模型、举报模型、内容相关模型等，主要用于精排计算。例如，每条弹幕有15-20组模型评估结果。所述物料池指一个视频分片(例如一分钟)内所有弹幕物料的列表集合，Key为视频ID+分片(分钟)。所述索引池和所述物料池类似，指一个视频分片内所有弹幕索引的列表集合，Key也为视频ID+分片(分钟)。所述弹幕物料库将每一条弹幕信息序列化存储，以弹幕ID作为Key，用于处理弹幕状态或其他元数据的更新。

由于所述索引池和所述物料池的读写场景一致，因此可以选择和所述物料池同样的KV数据库实现，在一个视频ID+分片(分钟)作为Key的单位下，对应物料池的粗排评估结果排序淘汰进行存储。值得注意的是，所述物料池和所述索引池用不同的Key来存储，没有使用在所述物料池的基础上扩展字段来实现，核心原因是：物料和所述TiDB数据库、各业务场景下的弹幕模型保持一致，将索引池和物料池用不同的Key存储，可以避免排序索引和业务功能的耦合；可实现索引、物料独立更新，降低索引回刷成本；分梯度降级保证可用性，一旦出现事故索引失效，可以随机打分降级保证用户无感。

同时，所述物料池和所述索引池的一致性通过Redis分片锁保证，所述Redis分片锁的颗粒度也是视频ID+分片(分钟)，和所述物料池、索引池的Key的颗粒度相同，从而在业务存在高并发，且线上增量数据和物料、索引回刷同时进行的情况下实现视频每分钟的弹幕原子性写入。在优先级上以所述物料池为主，写入索引前先验证物料存在，反之则不做强校验。

如图4所示，为本实施例中弹幕发送链路的示意图。当从所述弹幕数据库中获取到弹幕物料后，首先通过粗排模型对每条弹幕进行评估(打分)，然后聚合第二预设时段(例如每10秒钟)内的所有弹幕物料，根据该评估结果对第二预设时段的所有弹幕进行排序，然后根据将排在后面的弹幕淘汰，再针对未淘汰的弹幕进行全部模型评估，得到弹幕索引，最后将物料列表和索引列表分别存入所述物料池和所述索引池，相应的单条弹幕信息存入所述弹幕物料库。当有增量数据更新时，通过消息队列聚合的方式可以减轻数据库的写入压力。

在所述个性化推荐弹幕系统中，模型推理的计算成本也是一项重要考量，如果能节省掉冗余的推理次数，可以提升整个系统的效率，同时降低运维成本。如果计算一条弹幕的模型评估结果的方式是并发进行所有模型的推理，假设这条弹幕最终因粗排分过低而淘汰，则会造成计算冗余。因此，在本实施例中，先进行粗排模型评估的推理，完成排序淘汰之后再进行全部的模型推理，从而优化计算量。

另外，本实施例将退场逻辑收敛到粗排阶段，精排时不再需要进行数据缓存，只需读取经过粗排淘汰后的物料和缓存即可。这样，在精排阶段需要排序的数据量大大减少，从而优化了响应时间。

S202，根据客户端用户观看的视频ID和时间段，从所述弹幕召回池中获取相应弹幕信息，根据特征算法进行筛选后，展示至客户端。

如图5所示，为本实施例中弹幕展示链路的示意图。当客户端用户在视频播放界面打开弹幕功能时，则需要在播放视频的同时展示相应的弹幕信息。视频ID和用户当前观看的时间段等信息通过弹幕网关层传输至所述个性化推荐弹幕系统，个性化推荐网关(工程系统)根据所述视频ID和时间段从所述弹幕召回池中读取相应的弹幕物料和索引。其中，所述时间段可以依照用户当前观看的视频播放时间点和服务端根据应用场景动态下发的分片大小进行确定，例如6分钟，以免浪费网络带宽。工程系统根据所述视频ID和所述时间段对应的各个视频分片，可以从所述弹幕召回池中找到相应的弹幕物料和索引，然后向算法系统发出精排请求。算法系统基于预设的特征算法，包括用户特征和稿件(视频)特征，建立个性化推荐的精排逻辑，对相应弹幕进行全部模型评估，然后根据该评估结果进行排序、截断(截取排序靠前的弹幕)，返回推荐结果，也就是需要展示的弹幕信息。所述个性化推荐网关将这些弹幕通过弹幕网关层展示至客户端的显示界面中。

并且，所述个性化推荐网关还可以进行降级检测，即当所述个性化推荐弹幕系统出现故障时，可以自动降级至原弹幕系统，根据所述原弹幕系统的返回结果进行弹幕展示，使客户端的用户侧无感。

本实施例提出的弹幕处理方法，可以提供一种工程系统和算法系统深度结合的方案，工程系统负责物料、索引的存储以及淘汰，算法系统负责粗排、精排的模型打分和策略，在百亿数据量级、高并发、低延迟场景下，进行互动内容(弹幕)个性化推荐，数据一致性、稳定性都获得了大幅提升。精排降级率显著下降，在策略不变的情况下弹幕曝光也有大幅增长，再通过扩大召回池容量优化了上屏弹幕的质量，提升了用户互动体验。另外，本实施例还采用了多种分片设置，保障数据更新和淘汰时的合适颗粒度，节约带宽，并通过维护两套弹幕系统进行线上热备，在新系统出现故障时可以自动降级，使用户侧无感。

实施例二

如图6所示，为本申请第二实施例提出的一种弹幕处理方法的流程图。在第二实施例中，所述弹幕处理方法在上述第一实施例的基础上，还包括步骤S304-S306。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S300，将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池。

所述弹幕召回池是指所述个性化推荐弹幕系统保存召回的弹幕信息的KV数据库。所述弹幕召回池将一个视频第一预设时段(例如一分钟)内经过召回的弹幕存在一个Key中。在本实施例中，所述弹幕召回池包括但不限于物料池、索引池及弹幕物料库。

当从所述弹幕数据库中获取到弹幕物料后，首先通过粗排模型对每条弹幕进行评估，然后聚合第二预设时段(例如每10秒钟)内的所有弹幕物料，根据该评估结果对第二预设时段的所有弹幕进行排序，然后根据将排在后面的弹幕淘汰，再针对未淘汰的弹幕进行全部模型评估，得到弹幕索引，最后将物料列表和索引列表分别存入所述物料池和所述索引池，相应的单条弹幕信息存入所述弹幕物料库。

S302，根据客户端用户观看的视频ID和时间段，从所述弹幕召回池中获取相应弹幕信息，根据特征算法进行筛选后，展示至客户端。

当客户端用户在视频播放界面打开弹幕功能时，则需要在播放视频的同时展示相应的弹幕信息。视频ID和用户当前观看的时间点/时间段等信息通过弹幕网关层传输至所述个性化推荐弹幕系统，个性化推荐网关(工程系统)根据所述视频ID和时间段从所述弹幕召回池中读取相应的弹幕物料和索引。其中，所述时间段可以依照用户当前观看的视频播放时间点和服务端根据应用场景动态下发的分片大小进行确定，例如6分钟，以免浪费网络带宽。工程系统根据所述视频ID和所述时间段对应的各个视频分片，可以从所述弹幕召回池中找到相应的弹幕物料和索引，然后向算法系统发出精排请求。算法系统基于预设的特征算法，包括用户特征和稿件(视频)特征，建立个性化推荐的精排逻辑，对相应弹幕进行全部模型评估，然后根据该评估结果进行排序、截断，返回推荐结果，也就是需要展示的弹幕信息。所述个性化推荐网关将这些弹幕通过弹幕网关层展示至客户端的显示界面中。

并且，所述个性化推荐网关还可以进行降级检测，即当所述个性化推荐弹幕系统出现故障时，可以自动降级至原弹幕系统，根据所述原弹幕系统的返回结果进行弹幕展示，使客户端的用户侧无感。

S304，在无需更新粗排模型的情形下，通过索引回刷仅更新所述弹幕召回池中的弹幕索引，以实现模型策略迭代。

本实施例的回刷链路包括索引回刷和物料回刷。其中索引回刷应用于在召回、粗排策略不变的情况下刷新一组(或多组)模型评估结果，物料回刷应用于粗排模型更新时通过全量弹幕重新计算召回和粗排淘汰。业务上出现的主要场景是，如何快速支持粗排模型外的一组模型分数更新。如果对全部的存量数据进行回刷，耗时会非常久。针对这一特点，本实施例拆分了索引回刷和物料回刷，区别是是否需要更新粗排模型，重新进行召回和淘汰。这样通过索引回刷即可满足大部分策略迭代需求，减轻了整体的流程。结合前面物料池、索引池分离的存储设计，可以减少一半的数据写入量。

如图7所示，为本实施例中索引回刷的示意图。弹幕消费/展示应用场景的一个特点是流量集中在头部稿件(视频)，因此需要通过尽量小的数据回刷来覆盖尽量多的访问次数(Visit View，VV)百分比。在本实施例中，通过ETL(Extract-Transform-Load，抽取-转换-加载，一种数据仓库技术)任务计算得到小时更新的高热稿件(视频)表，再通过Clickhouse(列式存储数据库)存储当天的实时增量数据，这样两者结合即可得到完整的高热视频列表和实时增量视频列表，在需要更新索引时只需要更新这部分视频对应的弹幕即可。工程系统进行高热索引回刷和增量索引回刷，并对这两部分索引进行聚合更新，算法系统对聚合的索引对应的弹幕进行全部模型评估，根据该评估结果得到新的索引，工程系统将新的索引更新至所述弹幕召回池。注意此处只更新索引至索引池，不用更新物料。通过上述冷热数据分离的方式，通过15％计算量可以覆盖90％的VV，大幅提升了实验效率。

此外，部分策略迭代并不需要刷新全部视频下的弹幕。在这种情况下，通过数据仓库更新定制化的ETL并投递到数据消费端即可，在1小时内即可完成策略更新。

S306，在需要更新所述粗排模型的情形下，通过物料回刷同时更新所述弹幕召回池中的弹幕物料和索引，以实现模型策略迭代。

在所述个性化推荐弹幕系统中，一旦粗排模型有逻辑更新，则需要重新刷新召回池，也就是进行物料回刷，重新进行召回和淘汰。

如图8所示，为本实施例中物料回刷的示意图。当粗排模型更新时，所述个性化推荐弹幕系统获取全量弹幕和实时增量弹幕，工程系统进行全量物料回刷和增量物料回刷，算法系统通过粗排模型对所述全量物料和增量物料对应的弹幕进行评估，工程系统根据该评估结果淘汰弹幕后，算法系统再对未淘汰的弹幕进行全部模型评估，得到新的索引，最后工程系统更新物料和索引至所述弹幕召回池。

另外，在一种可选实施例中，由于弹幕索引的模型是离线更新，如果新的模型出现逻辑错误只能在精排阶段通过业务指标分组异常发现。而这时极有可能数据刷新已经完成或者进行了一半。为了解决这种场景下的模型策略迭代可灰度、可观测、可回滚，可以过弹幕索引的字段冗余和版本控制来实现。

如图9所示，为本实施例中的模型版本控制示意图。假设目前线上有点赞模型、负向模型两个模型，本次需要更新负向模型版本，则新版负向模型更新在空白字段score16，同时保留旧版负向模型score2。模型内容和分数字段的映射关系在精排服务内维护。若发现新版模型不符合预期，则更新映射关系，使用旧版模型字段score2即可完成回滚。若经线上验证新版模型符合预期，则停止对旧版模型生成评估结果，同时在精排服务中标记旧版模型字段为空白即可完成发布。

在前面索引回刷步骤中提到，为了支持快速实验策略迭代模型回刷会覆盖大多数视频而非全量视频。如果一些冷的视频又火了起来，需要有方法能发现这些视频，并且覆盖最新的模型策略。因此，在一种可选实施例中，可以在精排服务中校验索引的版本，即version字段。若索引版本过低，将视频ID推送到补召回队列中，更新全部最新的模型评估结果。这样就实现了冷热数据的转换。

本实施例提出的弹幕处理方法，可以提供一种工程系统和算法系统深度结合的方案，工程系统负责物料、索引的存储以及淘汰，算法系统负责粗排、精排的模型打分和策略，在百亿数据量级、高并发、低延迟场景下，进行互动内容(弹幕)个性化推荐，数据一致性、稳定性都获得了大幅提升。精排降级率显著下降，在策略不变的情况下弹幕曝光也有大幅增长，再通过扩大召回池容量优化了上屏弹幕的质量，提升了用户互动体验。另外，本实施例将索引回刷和物料回刷进行拆分，当模型策略迭代时，若粗排模型不更新，则只需要采用索引回刷，只有当粗排模型更新时才需要采用物料回刷，可以大大提高策略迭代的数据回刷效率，提升实验能力。

实施例三

如图10所示，为本申请第三实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图11仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述服务端。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如弹幕处理系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述弹幕处理系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例四

如图11所示，为本申请第四实施例提出一种弹幕处理系统60的模块示意图。所述弹幕处理系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述弹幕处理系统60包括：

召回模块600，用于将从弹幕数据库中获取的弹幕信息通过模型进行评估后，保存至弹幕召回池。

所述弹幕召回池是指所述弹幕处理系统60保存召回的弹幕信息的KV数据库。所述弹幕召回池将一个视频第一预设时段(例如一分钟)内经过召回的弹幕存在一个Key中。在本实施例中，所述弹幕召回池包括但不限于物料池、索引池及弹幕物料库。

当从所述弹幕数据库中获取到弹幕物料后，首先通过粗排模型对每条弹幕进行评估，然后聚合第二预设时段(例如每10秒钟)内的所有弹幕物料，根据该评估结果对第二预设时段的所有弹幕进行排序，然后根据将排在后面的弹幕淘汰，再针对未淘汰的弹幕进行全部模型评估，得到弹幕索引，最后将物料列表和索引列表分别存入所述物料池和所述索引池，相应的单条弹幕信息存入所述弹幕物料库。

展示模块602，用于根据客户端用户观看的视频ID和时间段，从所述弹幕召回池中获取相应弹幕信息，根据特征算法进行筛选后，展示至客户端。

当客户端用户在视频播放界面打开弹幕功能时，则需要在播放视频的同时展示相应的弹幕信息。视频ID和用户当前观看的时间段等信息通过弹幕网关层传输至所述弹幕处理系统60。展示模块602根据所述视频ID和时间段从所述弹幕召回池中读取相应的弹幕物料和索引。其中，所述时间段可以依照用户当前观看的视频播放时间点和服务端根据应用场景动态下发的分片大小进行确定，例如6分钟，以免浪费网络带宽。根据所述视频ID和所述时间段对应的各个视频分片，可以从所述弹幕召回池中找到相应的弹幕物料和索引。然后基于预设的特征算法，包括用户特征和稿件(视频)特征，建立个性化推荐的精排逻辑，对相应弹幕进行全部模型评估。再根据该评估结果进行排序、截断，返回推荐结果，也就是需要展示的弹幕信息，通过弹幕网关层将这些弹幕展示至客户端的显示界面中。

实施例五

如图12所示，为本申请第五实施例提出一种弹幕处理系统60的模块示意图。在本实施例中，所述弹幕处理系统60除了包括第四实施例中的所述召回模块600、展示模块602之外，还包括更新模块604。

所述更新模块604，用于在无需更新粗排模型的情形下，通过索引回刷仅更新所述弹幕召回池中的弹幕索引，以实现模型策略迭代。

本实施例的回刷链路包括索引回刷和物料回刷。其中索引回刷应用于在召回、粗排策略不变的情况下刷新一组(或多组)模型评估结果，物料回刷应用于粗排模型更新时通过全量弹幕重新计算召回和粗排淘汰。业务上出现的主要场景是，如何快速支持粗排模型外的一组模型分数更新。如果对全部的存量数据进行回刷，耗时会非常久。针对这一特点，本实施例拆分了索引回刷和物料回刷，区别是是否需要更新粗排模型，重新进行召回和淘汰。这样通过索引回刷即可满足大部分策略迭代需求，减轻了整体的流程。结合前面物料池、索引池分离的存储设计，可以减少一半的数据写入量。

弹幕消费/展示应用场景的一个特点是流量集中在头部稿件(视频)，因此需要通过尽量小的数据回刷来覆盖尽量多的VV百分比。在本实施例中，通过ETL任务计算得到小时更新的高热稿件(视频)表，再通过Clickhouse存储当天的实时增量数据，这样两者结合即可得到完整的高热和实时视频列表，在需要更新索引时只需要更新这部分视频对应的弹幕即可。所述更新模块604进行高热索引回刷和增量索引回刷，并对这两部分索引进行聚合更新，对聚合的索引对应的弹幕进行全部模型评估，根据该评估结果得到新的索引，将新的索引更新至所述弹幕召回池。注意此处只更新索引至索引池，不用更新物料。通过上述冷热数据分离的方式，通过15％计算量可以覆盖90％的VV，大幅提升了实验效率。

此外，部分策略迭代并不需要刷新全部视频下的弹幕。在这种情况下，通过数据仓库更新定制化的ETL并投递到数据消费端即可，在1小时内即可完成策略更新。

所述更新模块604，还用于在需要更新所述粗排模型的情形下，通过物料回刷同时更新所述弹幕召回池中的弹幕物料和索引，以实现模型策略迭代。

当粗排模型更新时，则需要重新刷新召回池，也就是进行物料回刷，重新进行召回和淘汰。所述更新模块604获取全量弹幕和实时增量弹幕后，进行全量物料回刷和增量物料回刷，通过粗排模型对所述全量物料和增量物料对应的弹幕进行评估，根据该评估结果淘汰部分弹幕后，再对未淘汰的弹幕进行全部模型评估，得到新的索引，最后更新物料和索引至所述弹幕召回池。

实施例六

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有弹幕处理程序，所述弹幕处理程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的弹幕处理方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。