CN111813767A - 一种电竞赛事数据的处理方法及系统 - Google Patents

Abstract

本发明涉及电竞数据处理技术领域，公开了一种电竞赛事数据的处理方法，其方法包括步骤：S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中，进入步骤S3或者S4；S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；S4、服务器根据电竞比赛项目完成事件流模型触发类型的数据计算，进入步骤S5；S5、用户通过数据库中查询数据计算和事件流计算的结果。以解决目前电子赛事竞技数据量大，数据维度多，人工处理操作量大的问题。

Description

一种电竞赛事数据的处理方法及系统

技术领域

本发明涉及电竞数据处理技术领域，具体而言，涉及一种电竞赛事数据的处理方法及系统。

背景技术

电竞数据整合的处理方法，是通过对数据的拉取，清洗，根据业务场景不同，对现有数据使用不同算法，得到里程碑数据，从而达到用数据来体现选手的能力，衡量战队的成就，提高游戏的整体水平的目的。其中，里程碑数据即战队、选手在电子竞技比赛中取得的值得纪念的数据。

目前处理数据的方法是人工处理或Excel计算两种，随着选手，赛事的增多，两种处理方法就都显示出了一定的缺陷：(1)电子赛事竞技数据量大，数据维度多，人工处理操作量大、耗时、耗力，消耗人工成本；(2)对于突发事件没有及时性处理对策，不能自动同步赛后数据；(3)操作人员负担较大，容易造成数据错误。

发明内容

本发明的主要目的在于提供一种电竞赛事数据的处理方法及系统，以解决目前电子赛事竞技数据量大，数据维度多，人工处理操作量大的问题，还解决了对于突发事件没有及时性处理对策，不能自动同步赛后数据的问题。

为了实现上述目的，本发明提供了如下技术：

一种电竞赛事数据的处理方法，其方法包括步骤：

S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；

S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中，进入步骤S3或者S4；

S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；

S4、服务器根据电竞比赛项目完成事件流模型触发类型的计算，进入步骤S5；

S5、用户通过数据库查询数据计算和事件流模型计算的结果。

进一步地，事件流模型，将复杂的游戏数据转换成统一的数据格式进行存储，同时使用统一的数据模型进行运算。

进一步地，事件流模型触发类型包括突发事件和累计事件。

进一步地，突发事件计算步骤：S01、以时间为单位，计算当前所有监控和统计维度最高最低值；S02、有新比赛数据录入后，对比监控维度或计算参与者对应所有统计维度最高最低值；S03、将步骤S01中的维度最高最低值与步骤S02中有比赛数据录入后的统计维度最高最低值作出对比，如果产生变更，则即为一个突发事件；S04、将产生的突发事件与电竞赛事、选手和战队进行关联。

进一步地，累计事件计算步骤：S11、定义事件规则，确定累计目标单位；S12、根据累计事件规则读取所有数据，得出满足事件规则的当前数据值，并监控当前数值；S13、有比赛数据更新时，计算所有参与者对应数据值；S14、对于完成或者接近目标时，发送通知信息。

一种电竞赛事数据的处理系统，包括数据源单元、数据清洗单元、存储单元和数据处理单元；

数据源单元，用于提供电竞游戏的计算数据，其数据存在的格式包括二进制、JSON、XML和文本格式中的至少一种，并将数据传输至数据清洗单元；

数据清洗单元，用于将不同格式的数据源清洗为游戏事件流模型中的统一数据格式；

存储单元，用于接收数据清洗单元的信息，存储事件流模型数据；

数据处理单元，用于从存储单元内读取存储数据，计算结果，对结果进行持久化处理，同时发给Apps应用层处理。

进一步地，还包括通知单元，用于将业务中关键计算结果或者识别出的错误事件，及时推送给事件处理人员。

进一步地，还包括代理层，用于提供整个系统的安全保护和对系统内外数据的交互中心。

进一步地，还包括Apps应用层，用于提供应用程序设计端口。

进一步地，数据处理单元包括模型训练模块和实验训练模块；

模型训练模块，用于对电竞玩家标注的数据建立模型，同时对于电竞数据进行实时计算；

实验训练模块，对模型训练模块中建立的数据模型进行灰度处理。

与现有技术相比较，本发明能够带来如下技术效果：

1、因为业务模块和数据存储的拆分，会导致请求的粒度很小，用户没必要为不关心的那部分数据付出代价，从而节省了大量的资源开销；

2、基于分布式请求的操作是一次性在服务器端完成的，由服务器端会最大化地完成计算结果，然后将计算结果传输到主节点，进行数据计算的合并；极大地降低了不必要的数据传输。比如，统计选手总分，每个机器在本地把分数计算完成，把结果汇总到主节点，主节点把结果累加，得出选手总分，而不是而不是每台机器把数据传给主节点，主节点基于数据在累加；

3、系统利用模块化思维，采用企业分工机制，让业务分层，区分职责；很好地进行了系统的解耦。对于大规模数据处理系统，大量的数据都由数据清洗模块在服务器端实现，用户端需要处理的数据量很小，很适合海量数据扩展。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，使得本发明的其它特征、目的和优点变得更明显。本发明的示意性实施例附图及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明一种电竞赛事数据的处理方法的流程图；

图2是本发明一种电竞赛事数据的处理系统的框架图；

图3是本发明一种电竞赛事数据的处理系统的数据处理单元的流程图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本发明中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本发明及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本发明中的具体含义。

另外，术语“多个”的含义应为两个以及两个以上。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

实施例1

(1)使用大数据技术，把整个系统做了分层定义，并进行有机组合；

(2)借鉴企业责任分工机制，把其应用到本业务系统中，每个模块各司其职，基本上做到和业务来解耦；

(3)对游戏数据抽象成不同事件流，是整个方案可行性的起点，也是该方案使用不同游戏的前提；

(4)对于不同的事件流，继续抽象划分成突发事件和累积事件，对不同的事件类型内置或者支持自定义计算方法，来完成常见单一或组合计算。

如图1、2和3所示，一种电竞赛事数据的处理方法及系统，其方法包括步骤：

S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；在服务器上实现了常见文件类型text、CSV、JSON、KV、Parquet、MessagePack、Protocol buffers等的数据清洗服务，该服务还可以支持自定义的文件类型，来满足不同场景下数据清洗的需求。

S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中(按照电竞项目进行区分的)，进入步骤S3或者S4；按照不同游戏类型进行存储目的是满足对时间要求不高的离线计算，将清洗后的数据推送到流式管道中目的是对时效性要求较高的实时计算。

S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；事件流模型，将复杂的游戏数据转换成统一的数据格式进行存储，同时使用统一的数据模型进行运算。然后将计算结果存入MySQL、MongoDB等常用存储系统中。

S4、服务器根据电竞比赛项目完成突发事件和累计事件的计算，进入步骤S5；突发事件计算步骤：S01、以时间为单位，计算当前所有监控和统计维度最高最低值；S02、有新比赛数据录入后，对比监控维度或计算参与者对应所有统计维度最高最低值；S03、将步骤S01中的维度最高最低值与步骤S02中有比赛数据录入后的统计维度最高最低值作出对比，如果产生变更，则即为一个突发事件；S04、将产生的突发事件与电竞赛事、选手和战队进行关联。累计事件计算步骤：S11、定义事件规则，确定累计目标单位；S12、根据累计事件规则读取所有数据，得出满足事件规则的当前数据值，并监控当前数据值；S13、有比赛数据更新时，计算所有参与者对应数据值；S14、对于完成或者接近目标时，发送通知信息。

S5、用户通过数据库中查询数据计算和事件流计算的结果。用户通过MySQL、MongoDB等常用存储系统或者通知管道得到的结果就是用户需要的价值数据。

一种电竞赛事数据的处理系统，包括数据源单元、数据清洗单元、存储单元、数据处理单元、通知单元、代理层和Apps应用层；

数据源单元，用于提供电竞游戏的计算数据，其数据存在的格式包括二进制、JSON、XML和文本格式中的至少一种，并将数据传输至数据清洗单元。

数据清洗单元，用于将不同格式的数据源清洗为游戏事件流模型中的统一数据格式；

存储单元，用于接收数据清洗单元的信息，存储事件流模型数据；

数据处理单元，用于从存储单元内读取存储数据，计算结果，对结果进行持久化处理，同时发给Apps应用层处理。

通知单元，用于将业务中关键计算结果或者识别出的错误事件，及时推送给事件处理人员。

代理层，用于提供整个系统的安全保护和对系统内外数据的交互中心。

Apps应用层，用于提供应用程序设计端口。

数据处理单元包括模型训练模块和实验训练模块；

模型训练模块，用于对电竞玩家标注的数据建立模型，同时对于电竞数据进行实时计算；

实验训练模块，对模型训练模块中建立的数据模型进行灰度处理。

本套系统之所以能够适用于所有游戏类型，是因为我们抽象了游戏事件流模型。我们业务需要面向不同的游戏，做游戏数据的深度分析和挖掘。不同游戏的游戏角色和数据结构区分很大，针对这种情况想要使用统一的计算模型是分成困难的。为了解决这个问题，我们构建了游戏事件流模型，目的是为了让复杂的游戏数据转换成统一的数据格式进行存储和使用统一的数据计算模型进行运算。

游戏事件流模型格式(Events)如下：

实施例2

如图1、2和3所示，一种电竞赛事数据的处理方法及系统，其方法包括步骤：

S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；在服务器上实现了常见文件类型text、CSV、JSON、KV、Parquet、MessagePack、Protocol buffers等的数据清洗服务，该服务还可以支持自定义的文件类型，来满足不同场景下数据清洗的需求。

S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中(按照电竞项目进行区分的)，进入步骤S3或者S4；按照不同游戏类型进行存储目的是满足对时间要求不高的离线计算，将清洗后的数据推送到流式管道中目的是对时效性要求较高的实时计算。

S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；事件流模型，将复杂的游戏数据转换成统一的数据格式进行存储，同时使用统一的数据模型进行运算。然后将计算结果存入MySQL、MongoDB等常用存储系统中。

S4、服务器根据电竞比赛项目完成突发事件和累计事件的计算，进入步骤S5；

在游戏过程中有些事情具有不确定性，要么发生，要么没有发生。类似这种事情我们称之突发事情。比如说，游戏中的5杀，击杀打小龙，突破最大最小值等，突发事件计算步骤：S01、以时间为单位，计算当前所有监控和统计维度(自己的和所有对比)最高最低值；S02、有新比赛数据录入后，对比监控维度或计算参与者对应所有统计维度最高最低值；S03、将步骤S01中的维度最高最低值与步骤S02中有比赛数据录入后的统计维度最高最低值作出对比，如果产生变更，则即为一个突发事件(通知触达运营人员)；S04、将产生的突发事件与电竞赛事、选手和战队进行关联。

累计事件是指在一个周期时间内统计单位的累加值，到达预测值称之累计事件完成。比如，2017年LPL春季赛完成1000杀的选手。累计事件计算步骤：S11、定义事件规则，确定累计目标单位(击杀、助攻和死亡等)；S12、根据累计事件规则读取所有数据，得出满足事件规则的当前数据值，并监控当前数据值；S13、有比赛数据更新时，计算所有参与者对应数据值；S14、对于完成或者接近目标时，发送通知信息，将计算结果通知管道(通知触达运营人员)。

S5、用户通过数据库中查询数据计算和事件流计算的结果。用户通过MySQL、MongoDB等常用存储系统或者通知管道得到的结果就是用户需要的价值数据。

一种电竞赛事数据的处理系统，包括数据源单元、数据清洗单元、存储单元、数据处理单元、通知单元、代理层和Apps应用层；

数据源单元，用于提供电竞游戏的计算数据，其数据存在的格式包括二进制、JSON、XML和文本格式中的至少一种，并将数据传输至数据清洗单元；甚至还有自定义的数据格式。

数据清洗单元，用于将不同格式的数据源清洗为游戏事件流模型中的统一数据格式；

存储单元，用于存储事件流模型数据和事件触发类型数据；

数据处理单元，用于从存储单元内读取存储数据，计算结果，对结果进行持久化处理，同时发给Apps应用层处理。

通知单元，用于将业务中关键计算结果或者识别出的错误事件，及时推送给事件处理人员。

代理层，用于提供整个系统的安全保护和对系统内外数据的交互中心。

Apps应用层，用于提供应用程序设计端口。

数据处理单元包括模型训练模块和实验训练模块；

模型训练模块，用于对电竞玩家标注的数据建立模型，同时对于电竞数据进行实时计算；

实验训练模块，对模型训练模块中建立的数据模型进行灰度处理。

本套系统之所以能够适用于所有游戏类型，是因为我们抽象了游戏事件流模型。我们业务需要面向不同的游戏，做游戏数据的深度分析和挖掘。不同游戏的游戏角色和数据结构区分很大，针对这种情况想要使用统一的计算模型是分成困难的。为了解决这个问题，我们构建了游戏事件流模型，目的是为了让复杂的游戏数据转换成统一的数据格式进行存储和使用统一的数据计算模型进行运算。

游戏事件流模型格式(Events)如下：

实施例3

如图1、2和3所示，一种电竞赛事数据的处理方法及系统，其方法包括步骤：

S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；在服务器上实现了常见文件类型text、CSV、JSON、KV、Parquet、MessagePack、Protocol buffers等的数据清洗服务，该服务还可以支持自定义的文件类型，来满足不同场景下数据清洗的需求。

S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中(按照电竞项目进行区分的)，进入步骤S3或者S4；按照不同游戏类型进行存储目的是满足对时间要求不高的离线计算，将清洗后的数据推送到流式管道中目的是对时效性要求较高的实时计算。

S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；事件流模型，将复杂的游戏数据转换成统一的数据格式进行存储，同时使用统一的数据模型进行运算。然后将计算结果存入MySQL、MongoDB等常用存储系统中。

S4、服务器根据电竞比赛项目完成突发事件和累计事件的计算，进入步骤S5；

在游戏过程中有些事情具有不确定性，要么发生，要么没有发生。类似这种事情我们称之突发事情。比如说，游戏中的5杀，击杀打小龙，突破最大最小值等，突发事件计算步骤：S01、以时间为单位，计算当前所有监控和统计维度(自己的和所有对比)最高最低值；S02、有新比赛数据录入后，对比监控维度或计算参与者对应所有统计维度最高最低值；S03、将步骤S01中的维度最高最低值与步骤S02中有比赛数据录入后的统计维度最高最低值作出对比，如果产生变更，则即为一个突发事件(通知触达运营人员)；S04、将产生的突发事件与电竞赛事、选手和战队进行关联。

累计事件是指在一个周期时间内统计单位的累加值，到达预测值称之累计事件完成。比如，2017年LPL春季赛完成1000杀的选手。累计事件计算步骤：S11、定义事件规则，确定累计目标单位(击杀、助攻和死亡等)；S12、根据累计事件规则读取所有数据，得出满足事件规则的当前数据值，并监控当前数据值；S13、有比赛数据更新时，计算所有参与者对应数据值；S14、对于完成或者接近目标时，发送通知信息，将计算结果通知管道(通知触达运营人员)。

S5、用户通过数据库中查询数据计算和事件流计算的结果。用户通过MySQL、MongoDB等常用存储系统或者通知管道得到的结果就是用户需要的价值数据。

一种电竞赛事数据的处理系统，包括数据源单元、数据清洗单元、存储单元、数据处理单元、通知单元、代理层和Apps应用层；

数据源单元，用于提供电竞游戏的计算数据，其数据存在的格式包括二进制、JSON、XML和文本格式中的至少一种，并将数据传输至数据清洗单元；甚至还有自定义的数据格式。

数据清洗单元，用于将不同格式的数据源清洗为游戏事件流模型中的统一数据格式；为了使用通用的计算方式，必须将不同的数据源加工成上文提到的游戏事件流模型格式(整个业务系统中统一数据格式)，这个过程我们称之为数据清洗。除了统一数据格式之外，还会进行缺失值处理、检查错误数据等操作。一般来说，缺失值是最常见的数据问题，我们主要有两种处理方法，第一步是确定缺失值范围，然后按照字段重要性进行范围填充，其次分别制定策略。第二步就是填充缺失内容，通过业务关联推测填充缺失值。

存储单元，用于接收数据清洗单元的信息，存储事件流模型数据；电竞数据量一般比较大，需要采用集群的解决方案才能满足需求。针对事件流的方式我们采用分布式文件系统实现共享的文件和存储。我们采用的集群文件系统是基于位置的寻址和冗余等功能，这些特性可以提高可靠性或降低集群其他部分的复杂性，而且可以跨多个存储节点传播数据的。当然这里会存在数据冗余，需要在冗余和性能之间找一个度。

数据处理单元，用于从存储单元内读取存储数据，计算结果，对结果进行持久化处理，同时发给Apps应用层处理。电竞数据对于准确性和实时性要求较高。特别是电竞赛事实时直转播业务，更是要求数据计算的实时性。数据处理单元是一个基于Storm和SparkStreaming的流式实时分布式计算系统，计算系统从存储集群中读取数据，经过计算后，把结果持久化或发送消息给上层应用。由于Storm和Spark Streaming不提供消息状态管理，而且为了达到水平扩展，最好是events之间无状态。对于大数据量、低精度的需求，需要做到无状态。而像累计类型的实时统计这样数据量不算太大，但准确要求极高的场景，需要记录Events处理状态。而为了应付重启、分布式扩展的场景，往往需要额外的介质来存储状态。状态信息我们使用过Redis作为存储，基于Kafka消息队列系统解决重启回滚计算需求。

通知单元，用于将业务中关键计算结果或者识别出的错误事件，及时推送给事件处理人员。业务对于关键计算结果或者识别出来的严重错误，需要及时地推送给相关的负责人是很重要的。是1对1的通知，还是一对多的通知；是实时的业务通知，还是能够容忍一定延时的系统通知。统计系统结合具体的场景来进行设计，根据不同业务负责人来灵活配置通知的渠道，是微信、手机短信还是钉钉。当前计算结果更新时，就会激活程序通知对应的业务负责人。

代理层，用于提供整个系统的安全保护和对系统内外数据的交互中心。考虑到业务数据的安全性，又能给合作伙伴提供对外的计算能力，就需要对外开放以上的功能模块。为了解决这个痛点，我们增加代理层。它一方面完成集群业务隔离、内部访问鉴权、IP白名单、业务请求限流策略、恶意请求识别等安全策略，另一方面对内对外输出业务计算模型结果数据和业务计算能力。

Apps应用层，用于提供应用程序设计端口。该层(Apps)提供一些核心应用程序，例如玩加数据、小加复盘、LOL直转播服务、KPL直转播服务、KPL里程碑、LOL里程碑等。同时，合作伙伴可以利用Proxy开放的API，选择自己团队熟悉的任何语言设计和编写属于自己的应用程序来满足用户的不同需求。

数据处理单元包括模型训练模块和实验训练模块；

模型训练模块，用于对电竞玩家标注的数据建立模型，同时对于电竞数据进行实时计算；模型训练，利用电竞专业玩家标注的数据建立可用模型的过程，并且需要对模型有效评价，常用评价方法有：得分(对的比例)、查准率、查全率、专家复验。评价通过的模型被标记为现网模型，可进入AB实验阶段。电竞模型的训练不同于互联网常规业务，可以从海量的用户行为数据中，学习出很多可用的不错的模型。同时电竞数据对于准确性和实时性要求较高，同时需要满足对于实时计算的要求，所以模型训练也需要满足实时性要求。

实验训练模块，对模型训练模块中建立的数据模型进行灰度处理。通过训练得出模型，会存在过拟合或者欠拟合的情况，可能得出的评价很好，但是到生成环境之后表现出很大的偏差，会给用户带来严重影响。因此需要试验系统来减少模型偏差带来的损失。通过试验系统，一部分用户会得到新模型，然后新模型和老模型进行指标对比，评价指标高于老模型时，就会慢慢自动放量给新模型。从而实现新模型的灰度发布。

事件流模型，事件流模型定义了不同游戏数据的通用结构，规范了游戏数据的存储，同时也保留用户自定义数据类型和数据结构的能力。

数据事件类型，使用突发事件和累计事件规范了计算方法，允许用户可以获取不同的事件计算类型。

业务架构模型，本解决方案借鉴了大数据思想和Android的架构体系结构创造性进行整合，并且新增关键系统，形成整体解决电竞计算的难题架构模型。

业务流程方法，实时稳定计算、自动化通知、不同游戏统一的数据计算技术。

与现有技术相比较，本发明能够带来如下技术效果：

1、因为业务模块和数据存储的拆分，会导致请求的粒度很小，用户没必要为不关心的那部分数据付出代价，从而节省了大量的资源开销；

2、基于分布式请求的操作是一次性在服务器端完成的，由服务器端会最大化地完成计算结果，然后将计算结果传输到主节点，进行数据计算的合并；极大地降低了不必要的数据传输。比如，统计选手总分，每个机器在本地把分数计算完成，把结果汇总到主节点，主节点把结果累加，得出选手总分，而不是而不是每台机器把数据传给主节点，主节点基于数据在累加；

3、系统利用模块化思维，采用企业分工机制，让业务分层，区分职责；很好地进行了系统的解耦。对于大规模数据处理系统，大量的数据都由数据清洗模块在服务器端实现，用户端需要处理的数据量很小，很适合海量数据扩展。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种电竞赛事数据的处理方法，其特征在于，包括步骤：

S1、首先对服务器上接收的文件类型数据进行数据清洗，进入步骤S2；

S2、将清洗后的数据按照不同游戏类型进行存储，同时将清洗后的数据推送到流式管道的事件流模型中，进入步骤S3或者S4；

S3、服务器按照不同的电竞项目配置不同流式管道的事件流模型的消费者，根据电竞比赛项目结果数据的要求，对数据进行计算，进入步骤S5；

S4、服务器根据电竞比赛项目完成事件流模型触发类型的数据计算，进入步骤S5；

S5、用户通过数据库查询数据计算和事件流模型计算的结果。

2.如权利要求1所述的一种电竞赛事数据的处理方法，其特征在于，事件流模型，将复杂的游戏数据转换成统一的数据格式进行存储，同时使用统一的数据模型进行运算。

3.如权利要求1或2所述的一种电竞赛事数据的处理方法，其特征在于，事件流模型触发类型包括突发事件和累计事件。

4.如权利要求3所述的一种电竞赛事数据的处理方法，其特征在于，突发事件计算步骤：S01、以时间为单位，计算当前所有监控和统计维度最高最低值；S02、有新比赛数据录入后，对比监控维度或计算参与者对应所有统计维度最高最低值；S03、将步骤S01中的维度最高最低值与步骤S02中有比赛数据录入后的统计维度最高最低值作出对比，如果产生变更，则即为一个突发事件；S04、将产生的突发事件与电竞赛事、选手和战队进行关联。

5.如权利要求1或4所述的一种电竞赛事数据的处理方法，其特征在于，累计事件计算步骤：S11、定义事件规则，确定累计目标单位；S12、根据累计事件规则读取所有数据，得出满足事件规则的当前数据值，并监控当前数据值；S13、有比赛数据更新时，计算所有参与者对应数据值；S14、对于完成或者接近目标时，发送通知信息。

6.一种电竞赛事数据的处理系统，其特征在于，包括数据源单元、数据清洗单元、存储单元和数据处理单元；

数据源单元，用于提供电竞游戏的计算数据，其数据存在的格式包括二进制、JSON、XML和文本格式中的至少一种，并将数据传输至数据清洗单元；

数据清洗单元，用于将不同格式的数据源清洗为游戏事件流模型中的统一数据格式；

存储单元，用于接收数据清洗单元的信息，存储事件流模型数据；

数据处理单元，用于从存储单元内读取存储数据，计算结果，对结果进行持久化处理，同时发给Apps应用层处理。

7.如权利要求6所述的一种电竞赛事数据的处理系统，其特征在于，还包括通知单元，用于将业务中关键计算结果或者识别出的错误事件，及时推送给事件处理人员。

8.如权利要求7所述的一种电竞赛事数据的处理系统，其特征在于，还包括代理层，用于提供整个系统的安全保护和对系统内外数据的交互中心。

9.如权利要求6或8所述的一种电竞赛事数据的处理系统，其特征在于，还包括Apps应用层，用于提供应用程序设计端口。

10.如权利要求9所述的一种电竞赛事数据的处理系统，其特征在于，数据处理单元包括模型训练模块和实验训练模块；

模型训练模块，用于对电竞玩家标注的数据建立模型，同时对于电竞数据进行实时计算；

实验训练模块，对模型训练模块中建立的数据模型进行灰度处理。

Images