数据处理方法、装置、存储介质和电子装置

技术领域

本发明涉及数据处理领域，具体而言，涉及一种数据处理方法、装置、存储介质和电子装置。

背景技术

目前，在业务运营中，对用户进行触达可以与用户保持长期的联系。随着业务不断发展，存在越来越多需要实时触达用户的业务场景，对于触达的时效性要求也越来越高。

在相关技术中，在实现实时触达时，需要涉及到开源处理平台(Kafka)、实时流处理框架(Spark-streaming)或者开源处理框架(Flink)等大数据组件，操作门槛高，且对于大部分业务和运营，并不具备代码能力，从而无法自主制定一些实时触达的策略。

针对现有技术中制定实时触达的策略的难度较大的技术问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种数据处理方法、装置、存储介质和电子装置，以至少解决制定实时触达的策略的难度较大的技术问题。

为了实现上述目的，根据本发明的一个方面，提供了一种数据处理方法。该方法可以包括：确定目标标签以及与目标标签对应的目标触发条件；基于目标触发条件确定目标策略数据，其中，目标策略数据用于表示当至少一个目标对象的行为数据满足目标触发条件时，与目标触发条件对应的目标推送数据允许推送至至少一个目标对象。

可选地，基于第一日志确定目标标签，包括：获取第一日志中的目标字段；将目标字段的取值确定为目标标签。

可选地，该方法还包括：将目标标签通过服务器存储至第一目标数据库；向服务器发送验证请求，其中，验证请求用于请求服务器对第一目标数据库中的目标标签进行验证，如果包括目标标签的第二日志的数量大于等于目标阈值，则目标标签由服务器验证成功。

可选地，确定与目标标签对应的目标触发条件，包括：基于验证成功的目标标签确定目标触发条件。

可选地，该方法还包括：显示至少一个目标标签的配置信息和/或目标标签的验证结果。

可选地，在目标标签的数量为多个的情况下，确定与目标标签对应的目标触发条件，包括：对多个目标标签进行逻辑组合，得到目标触发条件。

可选地，该方法还包括：确定当第一目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，向至少一个目标对象推送目标推送数据。

可选地，该方法还包括：确定当第二目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，禁止向至少一个目标对象推送目标推送数据。

可选地，该方法还包括：将目标策略数据通过服务器存储至第二目标数据库；向服务器发送检测请求，其中，检测请求用于请求服务器检测行为数据是否满足第二目标数据库中存储的目标触发条件，其中，目标策略数据包括目标触发条件。

可选地，该方法还包括：显示目标策略数据和/或目标推送数据。

为了实现上述目的，根据本发明的另一方面，提供了一种数据处理装置。该装置可以包括：第一确定单元，用于确定目标标签以及与所述目标标签对应的目标触发条件，其中，每个所述目标标签用于表示第一日志中目标字段的信息；第二确定单元，用于基于所述目标触发条件确定目标策略数据，其中，所述目标策略数据用于表示当至少一个目标对象的行为数据满足所述目标触发条件时，与所述目标触发条件对应的目标推送数据允许推送至所述至少一个目标对象。

为了实现上述目的，根据本发明的另一方面，提供了一种计算机可读存储介质。该存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行本发明实施例的数据处理方法。

为了实现上述目的，根据本发明的另一方面，提供了一种电子装置。该电子装置包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行本发明实施例的数据处理方法。

在本发明实施例中，通过确定目标标签以及与目标标签对应的目标触发条件，其中，每个目标标签用于表示第一日志中目标字段的信息；基于目标触发条件确定目标策略数据，其中，目标策略数据用于表示当至少一个目标对象的行为数据满足目标触发条件时，与目标触发条件对应的目标推送数据允许推送至至少一个目标对象。也就是说，该实施例基于配置的目标标签确定目标触发条件，进而基于目标触发条件确定目标策略数据，从而实现了赋予业务自主自定义配置实时触发条件，以及用户行为的实时检测触达的目的，解决了现有技术中制定实时触达的策略的难度大的技术问题，达到了降低制定实时触达的策略的难度的技术效果。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的一种数据处理方法的移动终端的硬件结构框图；

图2是根据本发明实施例的一种数据处理方法流程图；

图3是根据本发明实施例的一种目标标签的示意图；

图4是根据本发明实施例的另一种目标标签的示意图；

图5是根据本发明实施例的一种验证目标标签的流程图；

图6是根据本发明实施例的一种目标策略数据的示意图；

图7是根据本发明实施例的一种目标标签配置信息界面显示示意图；

图8是根据本发明实施例的另一种目标策略数据的示意图；

图9是是根据本发明实施例的一种Flink实时检测程序样例的示意图；

图10是根据本发明实施例的一种基于Flink的海量用户实时行为的检测示意图；

图11是根据本发明实施例的一种数据处理装置的示意图。

具体实施方式

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

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

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

随着运营业务的不断发展，为适应越来越多需要实时触达用户的业务场景，现有方案中主要采取预先开发方案和数据仓库结构化查询语言(Hive SQL)方案来进行实时触达。

预先开发方案的实现过程主要为：业务人员根据需要推送的业务场景汇总业务需求，策划人员与技术人员基于汇总的业务需求讨论具体的解决方案，技术人员对于该解决方案进行技术实现，对已经完成技术实现的解决方案进行质量保证(Quality Assurance，简称为QA)测试无误后，即可将该解决方案进行上线。这种预先开发方案的时效性好，但是整个方案的实现链路较长，需预先开发，研发成本高，且只能针对特定的业务场景实现推送，无法满足业务自主自定义实时触达策略的要求。

Hive SQL方案的实现过程为：技术人员将用户行为数据，准实时落盘到hive上，业务人员通过特定的SQL选择出满足推送要求的用户名单，得到用户名单后上传到推送系统进行推送。在该Hive SQL方案中，业务人员可以自定义SQL从而选择需要进行推送的用户名单，但整个方案的实现数据链路长，且数据需要在不同存储介质传输，时效性差。其中，时效性是指用户发生真实行为到策略真实触达之间的时延。

现有方案中存在制定实时触达的策略的难度较大的技术问题，使得实时触达的操作门槛高。

针对上述问题，申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的一种数据处理方法的移动终端的硬件结构框图。如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的一种数据处理的方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种运行于上述移动终端的一种数据处理方法，图2是根据本发明实施例的一种数据处理方法的流程图。如图2所示，该方法可以包括如下步骤：

步骤S22，确定目标标签以及与目标标签对应的目标触发条件。

在本发明上述步骤S22提供的技术方案中，目标标签用于表示第一日志中目标字段的信息。

在该实施例中，第一日志可以为与用户操作行为相关的日志，比如，为用户登陆日志此处不做具体限制。该实施例可以通过目标标签来表示上述第一日志中目标字段的信息，比如，第一日志为用户登录日志LoginRole，可以包括JSON字段，里面有很多key-value。图3是根据本发明实施例的一种目标标签的示意图。如图3所示，目标标签可以包括登录的角色等级、登录的应用渠道、登录的应用版本、登录的操作系统等，此处不做具体限制。其中，目标标签也可以称为实时标签。

业务制定策略的时候，比如，可以制定登录的一些实时标签分别应该满足什么条件，其本质就相当于这个日志对应的字段需要满足对应的条件才行。

作为一种可选的实施方式，在步骤S22，确定目标标签，包括：基于第一日志确定目标标签。

在该实施例中，业务可以根据实际需要，在图形用户界面上自定义目标标签，可以先获取第一日志，针对该第一日志，可以在该第一日志中确定出与业务需求相对应的目标字段的信息，进而将该目标字段的信息确定为目标标签，从而实现在前端进行自定义目标标签的配置。

作为一种可选的实施方式，基于第一日志确定目标标签，包括：获取第一日志中的目标字段；将目标字段的取值确定为目标标签。

在该实施例中，目标字段可以具有不同的取值，在第一日志中确定出与业务需求相对应的目标字段之后，可以获取该目标字段的取值，比如，目标标签为登录的角色等级，可以将角色等级的取值89确定为上述目标标签。

作为一种可选的实施方式，该数据处理方法还包括以下步骤：

步骤一，将目标标签通过服务器存储至第一目标数据库。

在该实施例中，前端可以将业务配置的目标标签，经由服务器提供的接口，写入到第一目标数据库的目标标签表中进行存储，其中，服务器可以为后端服务器。例如，图4是根据本发明实施例的另一种目标标签的示意图。如图4所示，第一目标数据库可以为目标标签表，该目标标签表中可以记录多个不同的目标标签，比如，目标标签1、目标标签2、目标标签、目标标签4的名称、创建人、调用截止时间、验证状态以及对于目标标签的操作选项等信息。

步骤二，向服务器发送验证请求。

在该实施例中，验证请求用于请求服务器对第一目标数据库中的目标标签进行验证，可选地，如果包括目标标签的第二日志的数量大于等于目标阈值，则目标标签由服务器验证成功。

该实施例可以在服务器中实时检测在真实的日志流中，是否有包括目标标签的第二日志，也即，检测是否有符合目标标签对应的配置的数据的日志，如果有上述第二日志，则确定存在目标标签对应的目标字段，确定验证成功1条。如果包括目标标签的第二日志的数量大于等于目标阈值，则目标标签由服务器验证成功，可以退出验证。

在该实施例中，第二日志为真实用户行为日志，可以为实时读取的日志流，比如，为基于Flink实时读取游戏的日志流。

可选地，如果包括目标标签的第二日志的数量小于目标阈值，可以继续验证，可以进一步比较目标标签的验证时间和预设时间。如果目标标签的验证时间大于等于预设时间，则确定每个目标标签由服务器验证超时，目标标签退出验证；如果目标标签的验证时间小于预设时间，则可以继续比较包括目标标签的第二日志的数量与目标阈值，重复上述步骤。

可选地，该实施例可以在数据侧，部署一套Flink的实时标签验证程序(在后台实时运行)，会实时消费kafka数据，实时验证业务自主配置的目标标签是否符合数据的真实要求，比如，主要验证业务定义的目标标签(对应某个第一日志的某个目标字段)在真实用户行为日志里面是否真实存在。

举例而言，在用户登录日志中，对于目标标签，业务定义了一个登录的角色等级，但是在页面配置的时候，应该是取“表：loginrole，字段：role_level”。业务可能手误配置成了“表：login，字段：rolelevel”。根据业务的这个配置，其实后去不到登录的角色等级的具体的数值。因而，该实施例需要验证业务配置的目标标签，程序这边可以根据其配置，才能能拿到对应真实的值。只有经过验证成功的目标标签才能在策略制定的时候进行组合使用，以形成目标触发条件。

图5是根据本发明实施例的一种验证目标标签的流程图。如图5所示，该过程为建立实时目标标签，将该目标标签放入验证队列的队尾，从Kafka中获取游戏实时日志流，该实时日志流中包括目标标签的第二日志。判断第二日志的数量是否大于等于目标阈值，当结果为是时，则确定目标标签验证成功；当结果为否时，可以进一步判断验证时间是否大于等于预设时间。当验证时间大于等于预设时间时，则确定目标标签验证超时，否则，可以继续比较第二日志的数量和目标阈值，重复上述步骤。

作为一种可选的实施方式，确定与目标标签对应的目标触发条件，包括：基于验证成功的目标标签确定目标触发条件。

在该实施例中，只有验证成功的目标标签，才可以被实时策略所使用，以用于确定目标触发条件。

作为一种可选的实施方式，在目标标签的数量为多个的情况下，步骤S22，确定与目标标签对应的目标触发条件，包括：对多个目标标签进行逻辑组合，得到目标触发条件。

在该实施例中，业务可以在前端的图形用户界面上定义多个目标标签，可以是对多个目标标签按照目标逻辑关系进行逻辑组合，比如，逻辑关系可以为“且”、“或”，还可以为“＝”、“！＝”、“>”、“>＝”、“<”、“<＝”、包括、不包含、在里面、不在里面等，此处不做具体限制。可选地，该实施例对验证成功的多个目标标签进行逻辑组合，从而得到上述目标触发条件。

步骤S24，基于目标触发条件确定目标策略数据。

在本发明上述步骤S24提供的技术方案中，目标策略数据用于表示当至少一个目标对象的行为数据满足目标触发条件时，与目标触发条件对应的目标推送数据允许推送至至少一个目标对象。

在该实施例中，目标策略数据可以为与策略相关的所有数据，比如，为该策略配置的选择分群、黑名单、触发条件、最大发布量、推送内容等，还可以包括策略标识、策略名、创建人、策略分类、生命周期、创建日期、发布状态、灰度机制和进度、发布量和成功量等。该目标策略数据包括目标触发条件和对应的目标推送数据，当至少一个目标对象的行为数据满足目标触发条件时，就可以将与目标触发条件对应的目标推送数据推送至至少一个目标对象。

举例而言，该实施例的上述目标策略数据可以是一些业务制定的在游戏应用里，用户实时玩了某些类型的玩法，满足了目标触发条件，就推送目标策略数据中的目标推送数据，比如，用户玩某种玩法失败了，满足目标触发条件，则向其推送攻略数据，或者玩某个玩法，满足目标触发条件，则向其推荐一些法宝数据，以促进玩家继续玩或者付费，其中，目标策略数据包括上述攻略数据和法宝数据。

随着业务不断发展，对于用户触达的要求的时效性也越来越高，存在越来越多需要实时检测和触达用户的业务场景，比如，在线生日祝福、升级实时推送、结拜实时恭喜、言论检测等。因而，该实施例的上述目标策略数据是针对实时触达用户而制定的策略数据，从而目标触发条件可以为实时触发条件，也可以称为实时条件、实时触发要求。

作为一种可选的实施方式，该数据处理方法还包括以下步骤：

步骤一，将目标策略数据通过服务器存储至第二目标数据库。

在该实施例中，前端可以将业务配置的目标策略数据，经由服务器提供的接口，写入到第二目标数据库中的目标策略表进行存储。例如，图6是根据本发明实施例的一种目标策略数据的示意图。如图6所示，图形用户界面中显示目标策略数据，其可以包括策略集名称、策略ID及策略名、创建人、策略分类、生命周期、创建日期、发布状态、灰度机制和进度、发布量和成功量等。在该实施例中，目标策略数据可以是一些业务制定的在游戏里面用户实时玩了某些类型的玩法，就可以推送的策略，比如，玩某种玩法失败了给推送攻略，玩某个玩法给推荐一些法宝，以促进玩家继续玩或者付费。

步骤二，向服务器发送检测请求。

在该实施例中，目标策略数据包括目标触发条件，前端可以向服务器发送检测请求，该检测请求用于请求服务器检测目标对象的行为数据是否满足第二目标数据库中存储的目标触发条件，进而当至少一个目标对象的行为数据满足目标触发条件时，可以将与目标触发条件对应的目标推送数据推送至至少一个目标对象。

在该实施例中，可以在数据侧，部署一套Flink的实时策略检测程序(在后台实时运行)，可以实时消费Kafka数据，主要实时检测哪些目标对象的行为数据，满足哪些目标策略数据设定的目标触发条件。

通过本申请上述步骤S22至步骤S26，确定目标标签以及与目标标签对应的目标触发条件；基于目标触发条件确定目标策略数据，其中，目标策略数据用于表示当至少一个目标对象的行为数据满足目标触发条件时，与目标触发条件对应的目标推送数据允许推送至至少一个目标对象。也就是说，该实施例基于配置的目标标签确定目标触发条件，进而基于目标触发条件确定目标策略数据，从而实现了赋予业务自主自定义配置实时触发条件，以及用户行为的实时检测触达的目的，解决了现有技术中制定实时触达的策略的难度大的技术问题，达到了降低制定实时触达的策略的难度的技术效果。

下面对该实施例的上述方法进行进一步介绍。

作为一种可选的实施方式，该数据处理方法还包括：在图形用户界面上显示至少一个目标标签的配置信息和/或至少一个目标标签的验证结果。

在该实施例中，上述目标标签的配置信息可以包括但不限于：目标标签的标签名称、敏感性、数据类型、标签描述、取值口径信息等，取值口径信息可以包括：数据库、数据表名、用户账号、角色标识(id)、服务器、目标标签的取数字段(取值)、调用截止时间等，如图7所示。其中，图7是根据本发明实施例的一种目标标签配置信息界面显示图。

作为另一种可选的实施方式，该数据处理方法还包括：确定当第一目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，向至少一个目标对象推送目标推送数据。

在该实施例中，可以根据图形用户界面上的分群功能控件确定第一目标对象集合，该第一目标对象集合也即用户名单，可以包括多个用户，比如，包括用户A、用户B、用户C等。该实施例可以从分布式文件系统(HDFS)文件中加载第一目标对象集合，判断第一目标对象集合中是否有行为数据满足目标触发条件的目标对象，如果有，则向该目标对象推送目标推送数据，比如，当该用户名单中用户A和用户B的行为数据满足目标触发条件时，则向用户A和用户B推送目标推送数据。

作为另一种可选的实施方式，该数据处理方法还包括：确定当第二目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，禁止向至少一个目标对象推送目标推送数据。

在该实施例中，可以根据图形用户界面上的黑名单功能控件设置第二目标对象集合，该第二目标对象集合中的对象是禁止接收与目标触发条件对应的目标推送数据的，也即，该第二目标对象集合为黑名单。可选地，该实施例可以从HDFS文件中加载第二目标对象集合，即使当第二目标对象集合中的至少一个目标对象的行为数据满足目标触发条件，也禁止向至少一个目标对象推送目标推送数据。比如，有一用户D，其处于黑名单中，即使用户D的行为数据满足目标触发条件，也不向用户D推送与目标触发条件对应的目标推送数据。

可选地，该实施例可以实时读取Kafka中用户的行为数据，可以利用程序检测逻辑定义一些算子，通过该算子检测哪些用户的行为数据满足目标策略数据设定的目标触发条件，进而可以向下游实时输出满足目标策略数据中的目标触发条件的目标对象的名单。可选地，该实施例可以基于Flink从对应游戏的Kafka Topic中实时读取游戏日志流，可以从目标策略数据的配置表中，加载目标策略数据的配置，以及目标策略数据中所配置的目标触发条件。如果选择了用户分群或者黑名单，则从已经计算好的HDFS文件中加载对应的第一目标对象集合或第二目标对象集合，进而确定当第一目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，向至少一个目标对象推送目标推送数据，或者确定当第二目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，禁止向至少一个目标对象推送目标推送数据。

可选地，如果该实施例未选择特定的分群或者黑名单，针对该类型的目标策略数据，不需要针对特定的目标对象集合生效，任意用户的真实行为数据只要满足目标触发条件，都会向用户推送对应的目标数据。

作为一种可选的实施方式，该数据处理方法还包括：显示目标策略数据和/或目标推送数据。

在该实施例中，业务可以在图形用户界面上自定义目标策略数据，可以在图形用户界面上显示出目标策略数据，也可以显示目标推送数据，以方便业务可以查看，从而达到查看目标策略数据和/或与目标策略数据相关的信息等。

图8是根据本发明实施例的另一种目标策略数据的示意图。如图8所示，业务在前端页面配置策略时，其中圈定人群处可以选择配置实时触发条件，可以在图形用户界面上配置选择分群、黑名单、触发条件、最大发布量等数据。

图9是根据本发明实施例的一种Flink实时检测程序样例的示意图。如图9所示，针对某个游戏下正在实时运行的目标策略数据，可以执行以下步骤：

步骤S91，实时读取Kafka中用户的行为数据。

步骤S92，利用程序检测逻辑定义一些算子，用于检测哪些用户的行为数据满足目标策略数据设定的目标触发条件。

步骤S93，实时输出满足目标策略数据中的目标触发条件的用户名单。

下面对该实施例的上述S93进行进一步介绍。

步骤3.1，基于Flink的实时策略检测程序从对应游戏的Kafka Topic中实时读取游戏日志流。

步骤3.2，从策略配置表中，加载目标策略数据的配置，以及目标策略数据中所配置的目标触发条件。

步骤3.3，如果目标策略数据选择了分群或者黑名单，则从已经计算好的HDFS文件中加载对应的策略名单，也即，用户名单。

在该实施例中，如果业务在前端未选择特定的分群或者黑名单，针对该类型的目标策略数据，不需要针对特定的策略名单生效，任意用户的真实行为数据只要满足实时触发条件，都会向用户推送对应的内容。

如果业务在前端选择了分群或者黑名单，这类策略需要针对特定的策略名单才能生效，或者针对特定的黑名单需要过滤掉。这类型策略，不仅需要用户的行为数据满足设定的实时触发条件，还需要用户在这个策略数据设定的策略名单或黑名单里面。

步骤3.4，在策略检测逻辑模块中实时检测用户的行为是否满足目标策略数据中的目标触发条件。

该实施例可以将满足目标触发条件的目标对象写入到另一个kafka topic中。在推送服务中，可以实时消费kafka topic数据，向目标对象推送对应的目标数据。

相较于现有Hive SQL方案，本申请实施例提出的数据处理方法的时效性更为突出。下面以数据传输的整体过程为例，比较Hive SQL方案与本申请实施例提出的数据处理方法的时效性。

在相关技术中，Hive SQL方案是一种准实时的方案，首先，其需要先把Kafka数据上的用户实时行为数据写入到hdfs上，然后添加到hive的对应分区，此步骤的处理时长为小时级别；其次，业务人员编写SQL并基于hive上获取符合要求的用户名单，此步骤的处理时长至少为分钟级别；最后，将用户名单再上传到对应的推送系统进行推送，此步骤中上传名单也需要一定耗时。在Hive SQL方案中，用户数据的传输路径为：Kafka＝>hive＝>sql出名单＝>推送系统，用户数据在多个不同系统中进行传输。应用Hive SQL方案时，例如检测用户登录：一个用户登录后，一般需要小时级别，才能进行推送。

然而，在本申请实施例提出的数据处理方法中，可以预先存储业务的策略配置，其中策略配置里面定义了触发条件，该业务在前端完成配置，就会实时存储到数据库。本申请实施例提出的数据处理方法不涉及存储用户的真实行为数据，因而可以有效节省数据处理时长。本申请实施例提出的数据处理方法中对用户进行实时监测时数据的传输路径为：Kafka(用户实时行为数据)＝>基于Flink流式计算框架实时检测＝>Kafka(符合要求的用户名单)＝>推送服务实时读取，整个方案从用户真实行为发生到推送触达，通常只需要秒级别，不超过一分钟。因此，本申请提实施例提出的数据处理方法可以实现赋予业务自主自定义配置实时触发条件，以及用户行为的实时检测触达的目的。

图10是根据本发明实施例的一种基于Flink的海量用户实时行为的检测示意图。如图10所示，Flink中的策略配置解析模块可以获取策略配置表，Flink中的策略名单加载模块获取策略名单，Flink中的实时日志加载模块获取游戏实时日志。将策略配置解析模块、策略名单加载模块以及实施日志加载模块的处理结果输入到策略检测逻辑模块，对推送名单中用户进行推送服务。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本发明实施例还提供了一种数据处理装置。该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“单元”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。需要说明的是，该实施例的数据处理装置可以用于执行本发明实施例图2所示的数据处理方法。

图11是根据本发明实施例的一种数据处理装置的示意图。如图11所示，该数据处理装置110包括：第一确定单元111和第二确定单元112。

第一确定单元111，用于确定目标标签以及与目标标签对应的目标触发条件。

第二确定单元112，用于基于目标触发条件确定目标策略数据，其中，目标策略数据用于表示当至少一个目标对象的行为数据满足目标触发条件时，与目标触发条件对应的目标推送数据允许推送至至少一个目标对象。

可选地，第一确定单元111包括：第一确定模块，用于基于第一日志确定目标标签。

可选地，该装置还包括：第一存储单元，用于将目标标签通过服务器存储至第一目标数据库；第一发送单元，用于向服务器发送验证请求，其中，验证请求用于请求服务器对第一目标数据库中的目标标签进行验证，如果包括目标标签的第二日志的数量大于等于目标阈值，则目标标签由服务器验证成功。

可选地，第一确定单元111包括：第二确定模块，用于基于验证成功的目标标签确定目标触发条件。

可选地，该装置还包括：第一显示单元，用于显示至少一个目标标签的配置信息和/或目标标签的验证结果。

可选地，第一确定单元111包括：组合模块，用于在目标标签的数量为多个的情况下，对多个目标标签进行逻辑组合，得到目标触发条件。

可选地，该装置还包括：推送单元，用于确定当第一目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，向至少一个目标对象推送目标推送数据。

可选地，该装置还包括：禁止单元，用于确定当第二目标对象集合中的至少一个目标对象的行为数据满足目标触发条件时，禁止向至少一个目标对象推送目标推送数据。

可选地，该装置还包括：第二存储单元，用于将目标策略数据通过服务器存储至第二目标数据库；第二发送单元，用于向服务器发送检测请求，其中，检测请求用于请求服务器检测行为数据是否满足第二目标数据库中存储的目标触发条件，其中，目标策略数据包括目标触发条件。

可选地，该装置还包括：第二显示单元，用于显示目标策略数据和/或目标推送数据。

通过本申请上述实施例，基于配置的目标标签确定目标触发条件，进而基于目标触发条件确定目标策略数据，从而实现了赋予业务自主自定义配置实时触发条件，以及用户行为的实时检测触达的目的，解决了现有技术中制定实时触达的策略的难度大的技术问题，达到了降低制定实时触达的策略的难度的技术效果。

本发明的实施例还提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

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

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM)、随机存取存储器(RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。