直播数据处理方法、装置、服务器和存储介质与流程

本申请实施例涉及计算机技术领域，尤其涉及一种直播数据处理方法、装置、服务器和存储介质。

背景技术：

随着直播行业的快速发展，网络直播意味以其直观、内容丰富等特点赢得了用户的青睐。通常为了提升用户观看直播的体验，直播平台会向根据主播的热度向用户推荐优质的直播。

目前的主播的热度确定方案，可能存在以下不足：一、确定方式单一，不能够很好的反映真实的热度，比如，仅根据同时在线观众人数确定热度；二、热度确定存在较大延时。

技术实现要素：

本申请实施例提供一种直播数据处理方法、装置、服务器和存储介质，提高了主播的热度值能够及时更新。

第一方面，本申请实施例提供一种直播数据处理方法，所述方法包括：

获取针对主播的第一操作日志，所述第一操作日志包括在当前时段得到的针对所述主播的至少两个维度的数据，所述至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度；

根据所述第一操作日志，获取每个维度对应的第一业务指标，所述第一业务指标用于表示所述主播在所述维度的关注度；

根据所述每个维度对应的第一业务指标，获取所述主播的热度值。

可选的，所述观看维度对应的第一业务指标为观看指标，包含以下至少之一：累计观看人次、指定时间段同时观看人数、指定时间段内新增观看人数、观看用户留存率；

所述礼物维度对应的第一业务指标为礼物指标，包含以下至少之一：额礼物消费金额、大额礼物送礼人数、普通礼物消费金额、普通礼物送礼人数、特殊礼物消费金额、送礼人数；

所述弹幕维度对应的第一业务指标为弹幕指标，包含以下至少之一：弹幕数量、弹幕产生速度。

可选的，所述根据所述每个维度对应的第一业务指标，获取所述主播的热度值，包括：

所述根据所述每个维度对应的第一业务指标，获取所述主播的热度值，包括：

针对多个主播，对同一维度对应的多个第一业务指标进行归一化处理，获取所述主播在每个维度对应的处理后的第一业务指标，所述多个主播包括所述主播；

针对所述主播，对多个维度对应的多个处理后的第一业务指标进行加权运算，获取所述主播的热度值。

可选的，所述对每个维度对应的处理后的第一业务指标进行加权运算，获取所述主播的热度值，包括：

获取针对所述主播的第二操作日志，所述第二操作日志包括在所述当前时段之前的时段得到的针对所述主播的多个维度的数据；

针对所述第二操作日志，获取所述第二操作日志中每个维度对应的第二业务指标，所述第二业务指标用于表示所述主播在所述维度得到的关注度；

针对所述多个主播，对同一维度对应的多个第二业务指标进行归一化处理，获取所述主播在每个维度对应的处理后的第二业务指标；

针对所述主播，对多个维度对应的多个处理后的第一业务指标和多个维度对应的多个处理后的第二业务指标进行加权运算，获取所述主播的热度值。

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

接收调节指示，并根据所述调节指示将所述主播的热度值调节至预设值。

可选的，所述第一操作日志为客户端日志和/或服务器日志。

可选的，所述获取针对主播的第一操作日志，包括：

接收客户端发送的针对所述主播的客户端日志，所述客户端日志是通过对所述客户端进行埋点得到的，其中，所述第一操作日志包括所述客户端日志。

可选的，所述根据所述第一操作日志，获取每个维度对应的第一业务指标，包括：

判断所述第一操作日志是否为有效日志，所述有效日志的时间戳在所述当前时段内；

若是，根据所述第一操作日志，获取每个维度对应的第一业务指标。

第二方面，本申请实施例提供一种数据处理装置，包括：

获取模块，用于获取针对主播的第一操作日志，所述第一操作日志包括在当前时段得到的针对所述主播的至少两个维度的数据，所述至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度；

根据所述第一操作日志，获取每个维度对应的第一业务指标，所述第一业务指标用于表示所述主播在所述维度得到的关注数据；

根据所述每个维度对应的第一业务指标，获取所述主播的热度值。

第三方面，本申请实施例提供一种服务器，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来第一方面所述的直播数据处理方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时第一方面所述的直播数据处理方法。

本申请实施例提供一种直播数据处理方法、装置、服务器和存储介质，该方法包括：获取针对主播的第一操作日志，第一操作日志包括在当前时段得到的针对主播的至少两个维度的数据，至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度，根据第一操作日志，获取每个维度对应的第一业务指标，第一业务指标用于表示该主播在该维度的关注度，根据每个维度对应的第一业务指标，获取主播的热度值。在本申请中，根据实时操作日志获取主播的热度值，使得热度值具有实时性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的主播热度值的确定系统的架构示意图；

图2为本申请实施例提供的直播数据处理方法的流程示意图一；

图3为本申请实施例提供的直播数据处理方法的流程示意图二；

图4为本申请实施例提供的直播数据处理方法的流程示意图三；

图5为本申请实施例提供的直播数据处理的示意图；

图6为本申请实施例提供的直播数据处理装置的结构示意图；

图7为本申请实施例提供的服务器的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的主播热度值的确定系统的架构示意图，如图1所示，本实施例提供的系统包括客户端101和服务器102，其中，客户端101可以为手机客户端、网页客户端、电脑客户端以及其它内嵌客户端等。本实施例对客户端101的实现方式不做特别限制，只要该客户端101能够实现观看直播即可。

目前，通常每隔一段时间汇总直播间的在线观众人数，通过汇总数据来更新主播的热度值，然而由于汇总数据的汇总需要耗费一定的时间，导致热度值的更新延时较大，这样客户端显示的热度值不能很好的反应当前真实的热度，并且只根据在线观众人数来更新主播的热度值，方式单一。其中，热度值用于表示用户对主播的关注程度，热度值越高，表明该主播越受用户关注，热度值越低，表明用户越不关注该主播。下面采用详细的实施例进行详细说明。

需要说明的是，图1示意客户端和服务器的数量为一个，在实际应用过程中，客户端、服务器的数量包括但不限于一个。

在本申请中，服务器获取针对主播的第一操作日志第一操作日志包括在当前时段得到的针对主播的至少两个维度的数据，至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度，根据第一操作日志，获取每个维度对应的第一业务指标，第一业务指标用于表示主播在维度的关注度，根据每个维度对应的第一业务指标，获取主播的热度值。其中，第一操作日志为客户端日志(即客户端101打印的日志)和/或服务器日志(即服务器102打印的日志)。根据实时操作日志获取主播的热度值，使得热度值具有实时性。

下面，提高具体实施例，对本申请所示的技术方案进行详细说明。需要说明的是，下面几个具体实施例可以相互结合，对于相同或相似的内容，在不同的实施例中不再进行赘述。

图2为本申请实施例提供的直播数据处理方法的流程示意图一，如图2所示，本实施例的执行主体可以为图1所示的服务器，或者其它设备，例如日志处理服务器，该直播数据处理方法可以包括：

s201、获取针对主播的第一操作日志，第一操作日志包括在当前时段得到的针对主播的至少两个维度的数据。

在本实施例中，第一操作日志包括在当前时段得到的针对主播的至少两个维度的数据，至少两个维度至少包括以下至少两种：观看维度、礼物维度、弹幕维度。第一操作日志为客户端日志和/或服务器日志，其中，客户端日志为客户端打印的日志，服务器日志为服务器打印的日志。

当前时段可以为当前时刻之前的预设时长，预设时长可以为1分钟、当前时刻为11点21分，则当前时段可以为11点20分至11点21分，当然，预设时长还可以为30秒、10分钟等，本实施例不对此限制。

在实际应用过程中，用户在客户端触发针对主播的操作后，客户端可以打印针对该主播的客户端日志，其中，针对该主播的操作可以包括进入该直播间、退出直播间、发送弹幕、送礼物、点击关注、参与抽奖等操作。相应的，用户在客户端触发针对该主播的操作时，服务器可以响应于该操作，向客户端下发操作指令，操作指令用于指示客户端执行对应的动作。例如：用户在客户端对应的界面上点击“游艇”，则服务器向客户端下发操作指令，以使在客户端界面上显示“游艇”，其中，服务器响应于该操作指令时，服务器可以打印该操作指令的服务器日志。

在本示例中，第一操作日志可以为客户端日志，例如：进入直播间、退出直播间等操作对应的客户端日志；进一步地，为了节省客户端日志的占用内存，第一操作日志还可以为服务器日志，例如：送礼物时客户端、服务器都打印了对应的日志，为了节省客户端的日志占用内存，第一操作日志可以为服务器日志；当然，在一些场景下，第一操作日志还可以为客户端日志和服务器日志。

在本示例中，进入直播间、退出直播间打印的日志可以对应观看维度的数据，送礼物、参与抽奖打印的日志可以对应礼物维度的数据，发送弹幕打印的日志可以对应弹幕维度的数据。

其中，观看维度的数据可以用于确定观看维度对应的第一业务指标，礼物维度的数据可以用于确定礼物维度对应的第一业务指标，弹幕维度的数据可以用于确定弹幕维度对应的第一业务指标。

当然，上述示例只是示例性对第一操作日志进行了说明，在实际应用过程中，第一操作日志包括但不限于上述维度的数据。

其中，在第一操作日志为客户端日志时，可以通过如下可行的实现方式获取针对主播的第一操作日志，包括：

接收客户端发送的针对主播的客户端日志，客户端日志是通过对客户端进行埋点得到的。

其中，埋点指的是通过植入代码以在用户触发针对主播的操作时打印客户端日志。例如：当针对该主播的操作为进入直播间时，客户端日志可以为进入直播间的日志，当针对该主播的操作为送礼物时，客户端日志可以为送礼物的日志。然后，客户端将打印的客户端日志发送给服务器，相应的，服务器接收客户端发送的针对该主播的客户端日志。

s202、根据第一操作日志，获取每个维度对应的第一业务指标，第一业务指标用于表示主播在该维度的关注度。

其中，观看维度对应的第一业务指标为观看指标，包含以下至少之一：累计观看人次、指定时间段同时观看人数、指定时间段内新增观看人数、观看用户留存率。

礼物维度对应的第一业务指标为礼物指标，包含以下至少之一：大额礼物消费金额、大额礼物送礼人数、普通礼物消费金额、普通礼物送礼人数、特殊礼物消费金额、送礼人数；

弹幕维度对应的第一业务指标为弹幕指标，包含以下至少之一：弹幕数量、弹幕产生速度。

其中，该维度对应的第一业务指标越高，表明该主播在该维度的关注度越高，反之，该主播在该维度的关注度越低。例如：每分钟观看的人数、和/或每分钟新增的观看人数、和/或观看用户留存率越高，表明该主播在视频维度上越受用户关注，也即，用户越喜欢观看该主播的视频。

示例性地，对于视频维度，当前时段为当前时刻之前1分钟、当前时刻为开播第1分钟，第一操作日志包括20条进入直播间对应的客户端日志、10条退出直播间对应的客户端日志，则每分钟观看人数为20人、每分钟新增人数为10人、留存率为1/2；当前时刻为开播第2分钟，第一操作日志包括5条进入直播间对应的客户端日志、2条退出直播间对应的客户端日志，则每分钟观看人数为10+5-2＝13人、每分钟新增人数为5人、每分钟留存率为8/10，留存率表示上一分钟看过直播的人数中，在本分钟内还留存的人数。

对于礼物维度，第一操作日志包括送礼对应的10条服务器日志，则可以获取大额礼物消费金额、大额礼物送礼人数、普通礼物消费金额、普通礼物送礼人数、特殊礼物消费金额、特殊礼物送礼人数。

可选的，根据第一操作日志，获取每个维度对应的第一业务指标包括：

判断第一操作日志是否为有效日志，有效日志的时间戳在当前时段内。

若是，根据第一操作日志，获取每个维度对应的第一业务指标。

其中，第一操作日志中包括该日志生成的时间戳，为保证热度值的实时性，避免根据过期时间(当前时段之前的时间)的日志得到主播的热度值，获取第一操作日志的时间戳，判断该时间戳是否在当前时段内，若是，则根据第一操作日志获取每个维度对应的第一业务指标，若否，将该日志剔除，并根据剔除后的第一操作日志获取每个维度对应的第一业务指标。例如：当前时段为10分钟，则将10分钟之前打印的日志剔除。

s203、根据每个维度对应的第一业务指标，获取主播的热度值。

其中，热度值用于表示用户对主播的关注程度，每个维度对应的第一业务指标用于表示主播在该维度的关注度，可以采用预设计算方法，根据每个维度对应的第一业务指标获取主播的热度值，例如：计算每个维度对应的第一业务指标的平均值，将该平均值作为该主播的热度值，或者，对每个维度对应的第一业务指标进行加权运算，得到主播的热度值。

当然，根据主播在每个维度的关注度得到该主播的热度值的方式包括但不限于以上两种，本领域技术人员可以采用任一可行的实现方式根据每个维度对应的第一业务指标获取主播的热度值。

其中，服务器还可以将主播的热度值发送给客户端，客户端将该主播的热度值进行显示，便于用户查看以及根据热度值选择进入直播间。

本实施例提供的直播数据处理方法，包括：获取针对主播的第一操作日志，第一操作日志包括在当前时段得到的针对主播的至少两个维度的数据，至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度，根据第一操作日志，获取每个维度对应的第一业务指标，第一业务指标用于表示该主播在该维度的关注度，根据每个维度对应的第一业务指标，获取主播的热度值。在本申请中，根据实时操作日志获取主播的热度值，使得热度值具有实时性。

在图2实施例的基础上，可以通过如下可行的方式实现步骤s203，图3为本申请实施例提供的直播数据处理方法的流程示意图二，如图3所示，步骤s203具体包括如下步骤：

s301、针对多个主播，对同一维度对应的多个第一业务指标进行归一化处理，获取该主播在每个维度对应的处理后的第一业务指标。

s302、针对该主播，对多个维度对应的多个处理后的第一业务指标进行加权运算，获取该主播的热度值。

其中，多个主播包括该主播。在多个主播在同一维度对应的多个第一业务指标相差在第一预设范围内时，认为这些第一业务指标相差不大，则为了多个主播的同一维度对应的多个第一业务指标能够具有明显的差异，从而加权得到的各个主播的热度值也具有明显差异，以便用户可以根据各个主播的热度选择进入相应的直播间。在本实施例中，对多个主播在同一维度对应的多个第一业务指标进行归一化处理，获取该主播在每个维度对应的处理后的第一业务指标，然后对该主播在每个维度对应的处理后的第一业务指标进行加权运算，得到该主播的热度值。

示例性地，维度为视频维度、第一业务指标包括每分钟观看人数。主播a的第一业务指标为：每分钟观看人数98、主播b的第一业务指标为：每分钟观看人数97、主播c的第一业务指标为：每分钟观看人数99，可见，这三个数据的百分比差异很小，采用设定值、例如90，对这三个数据进行归一化处理，主播a处理后的第一业务指标为：每分钟观看人数8、主播b处理后的第一业务指标为：每分钟观看人数7、主播c处理后的第一业务指标为：每分钟观看人数9。由此可见，这三个数据的百分比差异显著增加、区分明显。

然后，针对该主播，对多个维度对应的多个处理后的第一业务指标进行加权运算得到该主播的热度值，基于上述过程可知，各个主播在各个维度的第一业务指标有了明显的差异，那么针对每个主播，对多个维度对应的多个处理后的第一业务指标进行加权运算，得到的每个主播的热度值也有明显的差异。

在多个主播在同一维度对应的多个第一业务指标相差大于第二预设范围时，则认为这些第一业务指标相差过大，为了避免主播之间的热度值差异过大，这样在明显的差异化下可能导致热度值过小的主播持续无法吸引观看用户、陷入死循环。本实施例还可以采用以下归一化方案来均衡各个主播的同一维度对应的多个第一业务指标。

示例性地，主播a的第一业务指标为：每分钟观看人数1、主播b的第一业务指标为：每分钟观看人数100，可见，这两个数据的百分比差异很大，可以采用归一化方案：(第一业务指标/200)^0.1*100，进行归一化处理，主播a处理后的第一业务指标为：每分钟观看人数0.05^0.1*100＝74、主播b处理后的第一业务指标为：每分钟观看人数0.5^0.1*100＝93。由此可见，这两个数据的百分比差异变小、数据曲线更加平滑。

然后，针对该主播，对多个维度对应的多个处理后的第一业务指标进行加权运算得到该主播的热度值，基于上述过程可知，各个主播在各个维度的第一业务指标的差异不是过于大，那么针对每个主播在多个维度对应的多个处理后的第一业务指标进行加权运算，得到的每个主播的热度值也不会差异过大，从而热度值过低的主播也不会陷入无法吸引用户的死循环。

需要说明的是，第一预设范围和第二预设范围可以根据实际情况确定，本实施例对此不做限制。此外，本领域技术人员可以采用任一可行的归一化算法对同一维度对应的多个第一业务指标进行归一化处理，本实施例对此不做限制。

示例性地，该主播的热度值可以采用如下可行方式获得：

热度值＝权重系数1*视频维度对应的处理后的第一业务指标+权重系数2*礼物维度对应的处理后的第一业务指标+权重系数3*弹幕维度对应的第一业务指标

其中，权重系数1、权重系数2、权重系数3可以根据实际情况确定，如权重系数1、权重系数2、权重系数3均为1/3，或者权重系数1为1/2、权重系数2为1/4、权重系数3为1/4。

可选的，该方法还包括：

接收调节指示，并根据该调节指示将该主播的热度值调节至预设值。

示例性地，直播平台主板一个直播活动，使用新的主播账号进行推广，由于新的主播账号的热度值很低，为了在得到有效地推广，可以接收调节热度值的指示，并根据该调节指示将该主播的热度值调节至预设值。其中，预设值可以高于通过上述过程得到的热度值、也可以低于通过上述过程得到的热度值，本实施例对此不做限制。

示例性地，对于一些违规的主播，还可以接收操作指令不向客户端下发指定主播的热度值，这样客户端可以不显示该违规主播的热度值，由于用户通常由于热度值而注意到主播，这样控制了违规主播的关注度。

本实施例提供的直播数据处理方法，包括：针对多个主播，对同一维度对应的多个第一业务指标进行归一化处理，获取该主播在每个维度对应的处理后的第一业务指标，多个主播包括该主播，针对该主播，对多个维度对应的多个处理后的第一业务指标进行加权运算，获取该主播的热度值。这样，在增加或删除任一维度对应的数据时，只需调整对应的权重系数，提高了热度值的获取效率；根据实际情况调整权重系数有利于主播和用户的互动；对第一业务指标进行归一化处理，使得各个主播的热度值差异的合理化，有利于提高主播的关注度。

在图3实施例的基础上，在主播刚开播时由于热度值较低，为了有效地提高该主播的热度值，还可以结合主播的历史指标来获取热度值。可以通过如下可行的方式实现步骤s302，图4为本申请实施例提供的直播数据处理方法的流程示意图二，如图4所示，步骤s302具体包括如下步骤：

s401、获取针对该主播的第二操作日志，第二操作日志包括在当前时段之前的时段得到的针对主播的多个维度的数据。

第二操作日志为客户端日志和/或服务器日志。当前时段之前的时段为历史时段，若当前时段为当前时刻之前1分钟，则当前时段之前的时段可以为当前时段之前10分钟、1小时、1天等。

s402、针对第二操作日志，获取第二操作日志中每个维度对应的第二业务指标，第二业务指标用于表示主播在该维度得到的关注度。

s403、针对多个主播，对同一维度对应的多个第二业务指标进行归一化处理，获取该主播在每个维度对应的处理后的第二业务指标。

步骤s401-s403的实现过程和步骤s101-s102、s301的实现过程类似，在此不再赘述。

其中，步骤s403之前，还可以判断第二操作日志是否为有效日志，有效日志的时间戳在当前时段内，若是，则执行步骤s403，若否，将该日志剔除，并对剔除后的第二操作日志进行归一化处理，获取第二操作日志中每个维度对应的处理后的第二业务指标。

其中，第一操作日志中的维度可以和第二操作日志中的维度相同，也可以不同；第一操作日志中的维度数目可以和第二操作日志中的维度数目相同、也可以多于第二操作日志中的维度数目、或者少于第二操作日志中的维度数目。

s404、针对该主播，对多个维度对应的多个处理后的第一业务指标和多个维度对应的多个处理后的第二业务指标进行加权运算，获取该主播的热度值。

针对该主播，可以采用任一可行的加权算法，对多个维度对应的多个处理后的第一业务指标和多个维度对应的多个处理后的第二业务指标进行加权运算，获取该主播的热度值，也即，结合实时的操作日志和历史操作日志得到主播的热度值，这样在刚开播时，历史指标(第二业务指标)高的主播的热度值比较高。

示例性地，该主播的热度值可以采用如下可行方式获得：

热度值＝权重系数4*多个维度对应的多个处理后的第一业务指标之和+权重系数5*多个维度对应的多个处理后的第二业务指标之和

其中，权重系数4、权重系数5可以根据实际情况确定，权重系数5可以大于权重系数4，这样历史指标好的主播在刚开播时的热度值高于历史指标差的主播。

在开播预设时长之后，则根据实时的操作日志获取该主播的热度值，即，将权重系数4调大、权重系数5调小，还可以在开播预设时长之后，执行图2、图3实施例的技术方案，即权重系数5为0。

可选的，服务器还可以将主播的热度值发送给客户端，以使客户端的客户端上显示该主播的热度值。

本实施例提供的直播数据处理方法，包括：获取针对主播的第二操作日志，第二操作日志包括在当前时段之前的时段得到的针对该主播的多个维度的数据，针对第二操作日志，获取第二操作日志中每个维度对应的第二业务指标，第二业务指标用于表示主播在该维度得到的关注度，针对多个主播，对同一维度对应的多个第二业务指标进行归一化处理，获取所述主播在每个维度对应的处理后的第二业务指标，针对该主播，对多个维度对应的多个处理后的第一业务指标和多个维度对应的多个处理后的第二业务指标进行加权运算，获取该主播的热度值。这样在刚开播时，结合历史指标有效地提高了历史指标高的主播的热度值，有利于提高主播的关注度。

下面采用一个具体实施例对本申请的技术方案进行说明。图5为本申请实施例提供的直播数据处理的示意图，如图5所示，该数据处理过程可以包括以下几个步骤：

第一步、电脑客户端、网页客户端、手机客户端在用户触发针对主播的操作后，分别打印客户端日志并将客户端日志打印在服务器指定目录，例如：将送礼物日志保存在服务器a的目录/home/log/gift/、将弹幕日志保存至服务器b的目录/home/log/barrage。

其中，客户端和服务器采用超文本传输协议http协议进行数据交互，http的超时设置为5秒、客户端日志收集的延时为3秒之内，客户端日志收集的延时为收集到日志的时间与日志触发的时间之差。

第二步、电脑客户端、网页客户端、手机客户端分别对应至少一个日志收集服务器，各个日志收集服务器将服务器日志打印在服务器指定目录，例如：将送礼物日志保存在服务器a的目录/home/log/gift/、将弹幕日志保存至服务器b的目录/home/log/barrage。

其中，服务器日志收集延时在2秒之内，服务器日志收集的延时为收集到日志的时间与日志触发的时间之差。

第三步、日志处理服务器的日志收集agent监听指定的目录，将客户端日志和服务器日志推送到kafka，其中，按照日志的收集路径、日志收集服务器将各个客户端日志和各个服务器日志推送到不同的topic。

其中，日志推送延时在4秒之内，还可以定时检查延时，延时大于4秒时可以将客户端日志和/或服务器日志进行拆分到不同的topic，以降低延时。

第四步、日志处理服务器从kafka中订阅需要的日志，并从kafka中获取日志进行消费，剔除时间戳异常的日志，根据剔除后的日志，计算每个维度对应的第一业务指标，并将各个第一业务指标进行存储。

各个第一业务指标的存储介质可以为redis或mongodb或hdfs，并在10秒后，将各个第一业务指标落盘到mongodb。其中，数据落盘是将数据从保存在内存中转为保存在硬盘上。实时计算时，为了保证处理速度，数据保存在内存(redis或mongodb或hdfs)。如果直接将维度指标在计算时就保存在mongodb，会加大延时。

第五步、离线指标计算。日志处理服务器计算当前时段之前时段的第二操作日志中每个维度对应的第二业务指标并存储。

其中，当前时段之前时段的第二操作日志(历史日志)保存在hdfs中。按照上述方式计算得到第二操作日志中每个维度对应的第二业务指标。

第六步、后台调控

日志处理服务器可以调整不同维度的权重系数，调整后下次更新热度值时及时生效、日志处理服务器还可以调整主播的热度值，以支持特殊活动需求，即将热度值即时写入mongodb、马上生效；对于违规主播，日志服务器可以将其加入黑名单，不予显示热度值。

第七步、日志处理服务器多每个维度对应的第一业务指标和每个维度对应的第二业务指标进行加权运算，得到该主播的热度值。

第八步、日志处理服务器将主播的热度值下发给电脑客户端、网页客户端、手机客户端，以更新主热度值。

图6为本申请实施例提供的直播数据处理装置的结构示意图，在本实施例中，该数据处理装置可以集成在服务器中，也可以为一服务器。可选的，如图5所示，该数据处理装置包括：

获取模块61，用于获取针对主播的第一操作日志，所述第一操作日志包括在当前时段得到的针对所述主播的多个维度的数据；

根据所述第一操作日志，获取针对主播的第一操作日志，所述第一操作日志包括在当前时段得到的针对所述主播的至少两个维度的数据，所述至少两个维度包含以下至少两种：观看维度、礼物维度、弹幕维度；

根据所述第一操作日志，获取每个维度对应的第一业务指标，所述第一业务指标用于表示所述主播在所述维度的关注度；

根据所述每个维度对应的第一业务指标，获取所述主播的热度值。

可选的，所述观看维度对应的第一业务指标为观看指标，包含以下至少之一：累计观看人次、指定时间段同时观看人数、指定时间段内新增观看人数、观看用户留存率；

所述礼物维度对应的第一业务指标为礼物指标，包含以下至少之一：额礼物消费金额、大额礼物送礼人数、普通礼物消费金额、普通礼物送礼人数、特殊礼物消费金额、送礼人数；

所述弹幕维度对应的第一业务指标为弹幕指标，包含以下至少之一：弹幕数量、弹幕产生速度。

可选的，所述获取模块61，具体用于：

针对多个主播，对同一维度对应的多个第一业务指标进行归一化处理，获取所述主播在每个维度对应的处理后的第一业务指标，所述多个主播包括所述主播；

针对所述主播，对多个维度对应的多个处理后的第一业务指标进行加权运算，获取所述主播的热度值。

可选的，所述获取模块61，具体用于：

获取针对所述主播的第二操作日志，所述第二操作日志包括在所述当前时段之前的时段得到的针对所述主播的多个维度的数据；

针对所述第二操作日志，获取所述第二操作日志中每个维度对应的第二业务指标，所述第二业务指标用于表示所述主播在所述维度得到的关注度；

针对所述多个主播，对同一维度对应的多个第二业务指标进行归一化处理，获取所述主播在每个维度对应的处理后的第二业务指标；

针对所述主播，对多个维度对应的多个处理后的第一业务指标和多个维度对应的多个处理后的第二业务指标进行加权运算，获取所述主播的热度值。

可选的，所述处理模块用于：

接收调节指示，并根据所述调节指示将所述主播的热度值调节至预设值。

可选的，所述第一操作日志为客户端日志和/或服务器日志。

可选的，所述获取模块61，具体用于：

接收客户端发送的针对所述主播的客户端日志，所述客户端日志是通过对所述客户端进行埋点得到的，其中，所述第一操作日志包括所述客户端日志。

可选的，所述处理模块还用于：

判断所述第一操作日志是否为有效日志，所述有效日志的时间戳在所述当前时段内；

若是，根据所述第一操作日志，获取每个维度对应的第一业务指标。

本申请实施例提供的数据处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

图7为本申请实施例提供的服务器的结构示意图，如图7所示，该服务器包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行上述方法实施例所示的技术方案。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行上述方法实施例所示的技术方案。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请实施例的技术方案，而非对其限制；尽管参照前述各实施例对本申请实施例进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请实施例方案的范围。