一种实时用户特征的计算方法及装置

技术领域

本申请涉及数据库技术领域，具体而言，涉及一种实时用户特征的计算方法及装置。

背景技术

随着社会的快速发展，越来越多的数据信息出现在人们的面前，于是人们开发了数据库技术，并使用数据库进行了数据信息的存储。然而，在实践中发现，目前数据信息存储至数据库之后，工作人员通常会使用数据库对数据信息相对应的用户数据进行计算，以得到用户的用户特征。但是，该种用户特征的获取方式不具有获取实时性，也无法实现个性化的用户特征获取效果。

发明内容

本申请实施例的目的在于提供一种实时用户特征的计算方法及装置，能够在数据落库的同时自动根据特征配置文件进行用户特征的计算，从而实现用户特征的实时获取，并在同时通过使用特征配置文件实现个性化的用户特征获取。

本申请实施例第一方面提供了一种实时用户特征的计算方法，包括：

当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件；

当所述流式数据处理平台中存在所述特征配置文件时，判断所述特征配置文件是否与所述数据处理结果相对应；

当所述特征配置文件与所述数据处理结果相对应时，在所述数据库中加载与所述数据处理结果相对应的用户数据；

根据所述特征配置文件和所述用户数据进行计算，得到用户特征。

在上述实现过程中，该方法可以实时检测业务数据是否被处理入库，并在检测到业务数据被处理入库的同时，立即获取相应的配置文件和用户数据进行用户特征的计算。可见，实施这种实施方式，能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

进一步地，在所述当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件的步骤之前，所述方法还包括：

获取流式数据处理平台包括的datahub平台和kafka平台中存储的业务数据；

对所述业务数据进行数据处理，得到数据处理结果；

存储所述数据处理结果至mongo数据库中。

在上述实现过程中，该方法可以预先获取datahub平台和kafka平台中业务数据，然后通过flink对业务数据进行数据处理，得到相应的数据处理结果，最后再将该数据处理结果存储至mongo数据库中。可见，实施这种实施方式，能够通过flink对业务数据进行数据处理与落库，从而在保证效率的基础上完成对业务数据的处理，同时也能够触发用户特征计算的过程得以实时进行。

进一步地，所述获取流式数据处理平台中的业务数据的步骤之前，所述方法还包括：

通过数据传输服务将mysql数据库中存储的业务数据输入至流式数据处理平台包括的datahub平台中，通过数据库变更监控服务将所述业务数据输入至所述流式数据处理平台包括的kafka平台中。

在上述实现过程中，该方法可以预先将mysql数据库中的业务数据传输至datahub平台和kafka平台中，以使业务数据可以在两个平台中进行相应存储，从而使得datahub平台可以更有效地对数据进行分发之类处理，使得kafka平台可以配合flink完成配置文件的输出与用户特征的计算，进而保证该种用户特征计算方法的稳定性和准确性。

进一步地，根据预设处理方案对所述业务数据进行数据处理，得到数据处理结果；其中，所述预设处理方案包括数据抽取处理方案、数据转换处理方案、数据加载处理方案、空值数据处理方案、垃圾数据处理方案以及延时数据处理方案中的至少一种。

在上述实现过程中，该方法可以通过flink对业务数据进行ETL处理，并将处理所得到的结果作为数据处理结果，用于与业务数据一起存储至mongo数据库中。可见，实施这种实施方式，能够对业务数据进行ETL处理之后进行落库处理，从而使得落库数据的质量更高。

进一步地，所述当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件的步骤包括：

当检测到数据处理结果被存储至数据库时，判断流式数据处理平台包括的kafka平台中是否存在sql化的特征配置文件；

当所述kafka平台中存在sql化的所述特征配置文件时，触发执行所述判断特征配置文件是否与所述数据处理结果相对应的步骤。

在上述实现过程中，该方法可以获取到类sql化的配置文件，以使后续的用户特征可以根据该种sql化的特征配置文件进行计算，从而实现个性化的用户特征计算，进而能够获取到更优质更具有针对性的用户特征。

本申请实施例第二方面提供了一种实时用户特征的计算装置，所述实时用户特征的计算装置包括：

第一判断单元，用于当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件；

第二判断单元，用于当所述流式数据处理平台中存在所述特征配置文件时，判断特征配置文件是否与所述数据处理结果相对应；

加载单元，用于当所述特征配置文件与所述数据处理结果相对应时，在所述数据库中加载与所述数据处理结果相对应的用户数据；

计算单元，用于根据所述特征配置文件和所述用户数据进行计算，得到用户特征。

在上述实现过程中，该装置能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

进一步地，所述计算装置还包括：

获取单元，用于获取流式数据处理平台包括的datahub平台和kafka平台中存储的业务数据；

处理单元，用于对所述业务数据进行数据处理，得到数据处理结果；

存储单元，用于存储所述数据处理结果至mongo数据库中。

在上述实现过程中，该装置能够通过flink对业务数据进行数据处理与落库，从而在保证效率的基础上完成对业务数据的处理，同时也能够触发用户特征计算的过程得以实时进行。

进一步地，所述存储单元还用于通过数据传输服务将mysql数据库中存储的业务数据输入至流式数据处理平台包括的datahub平台中，通过数据库变更监控服务将所述业务数据输入至所述流式数据处理平台包括的kafka平台中。

在上述实现过程中，该装置可以预先将mysql数据库中的业务数据传输至datahub平台和kafka平台中，以使业务数据可以在两个平台中进行相应存储，从而使得datahub平台可以更有效地对数据进行分发之类处理，使得kafka平台可以配合flink完成配置文件的输出与用户特征的计算，进而保证该种用户特征计算方法的稳定性和准确性。

本申请实施例第三方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例第一方面中任一项所述的实时用户特征的计算方法。

本申请实施例第四方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例第一方面中任一项所述的实时用户特征的计算方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种实时用户特征的计算方法的流程示意图；

图2为本申请实施例提供的另一种实时用户特征的计算方法的流程示意图；

图3为本申请实施例提供的一种实时用户特征的计算装置的结构示意图；

图4为本申请实施例提供的另一种实时用户特征的计算装置的结构示意图；

图5为本申请实施例提供的一种实时用户特征的计算方法的系统流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例1

请参看图1，图1为本申请实施例提供了一种实时用户特征的计算方法的流程示意图。其中，该实时用户特征的计算方法包括：

S101、当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件，若是，则执行步骤S102；若否，则结束本流程。

本实施例中，该方法可以根据由业务数据被存储至数据库时所产生的消息触发用户特征的实时计算流程。

本实施例中，该方法可以执行之前编写启动计算程序的配置文件，该配置文件包括程序入口类、消息来源、原始数据所在数据库实例、特征配置文件来源等。

在本实施例中，特征配置文件可以包含事件消息表名、表所在库、依赖表信息、特征计算逻辑以及发送到哪个kafka。

S102、判断特征配置文件是否与数据处理结果相对应，若是，则执行步骤S103~S104；若否，则结束本流程。

本实施例中，数据处理结果与用户办理的业务数据相对应。

S103、在数据库中加载与数据处理结果相对应的用户数据。

本实施例中，用户数据为办理上述业务数据的用户的数据。

S104、根据特征配置文件和用户数据进行计算，得到用户特征。

本实施例中，用户特征用于表示用户的全方面特征。

本实施例中，该方法可以实时根据数据处理结果找到对应的特征配置文件进行对应逻辑的实时特征计算，并将计算得到的用户特征存入数据库中。

本实施例中，本申请具有较优的扩展性、可用性和易用性等特点。其中，关于扩展性，本申请可以通过其使用的系统快速地开发或直接接入第三方插件的形式实现不同消息队列的及数据存储的插拔性；关于可用性，本申请可以通过其使用的开源flink计算框架来实现服务器异常导致失败的自动重启，从而保证了系统任务的高可用性；关于易用性，本申请可以通过配置的形式实现用户特征的快速开发，几分钟完成特征开发、测试、上线，从而实现了用户在不懂程序开发只懂业务逻辑的情况下也能进行用户特征开发、测试以及上线的操作。

本申请实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本申请实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的实时用户特征的计算方法，能够实时检测业务数据是否被处理入库，并在检测到业务数据被处理入库的同时，立即获取相应的配置文件和用户数据进行用户特征的计算。可见，实施这种实施方式，能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

实施例2

请参看图2，图2为本申请实施例提供的一种实时用户特征的计算方法的流程示意图。如图2所示，其中，该实时用户特征的计算方法包括：

S201、通过数据传输服务将mysql数据库中存储的业务数据输入至流式数据处理平台包括的datahub平台中，通过数据库变更监控服务将业务数据输入至流式数据处理平台包括的kafka平台中。

本实施例中，该方法可以通过DTS的方式将业务数据写入datahub平台，也可以通过canal将业务数据写入至kafka平台中。

S202、获取流式数据处理平台包括的datahub平台和kafka平台中存储的业务数据。

S203、对业务数据进行数据处理，得到数据处理结果。

本实施例中，该方法可以对业务数据进行ETL处理，并将处理后的数据处理结果存入mongo并往后发消息。其中，ETL包括数据格式的转换、空值的处理、垃圾数据处理、延时数据处理等。

作为一种可选的实施方案，对业务数据进行数据处理，得到数据处理结果的步骤包括：

根据预设处理方案对业务数据进行数据处理，得到数据处理结果；其中，预设处理方案包括数据抽取处理方案、数据转换处理方案、数据加载处理方案、空值数据处理方案、垃圾数据处理方案以及延时数据处理方案中的至少一种。

本实施例中，数据抽取处理方案用于指代从数据库中抽取数据的数据处理方案。

本实施例中，数据转换处理方案用于指代将数据从一种表示形式转换为另一种表现形式的数据处理方案。

本实施例中，数据加载处理方案用于指代将转换好的数据保存到数据库中的数据处理方案。

本实施例中，空值数据处理方案用于指代删除含有缺失值的记录的数据处理方案或插补缺失值的数据处理方案。

本实施例中，垃圾数据处理方案用于指代对垃圾数据进行删除或跳过的数据处理方案。

本实施例中，延时数据处理方案用于指代对数据进行滞后或延迟处理的数据处理方案。

S204、存储数据处理结果至mongo数据库中。

本实施例中，该方法可以优先完成对业务数据的处理。其中，该处理过程可以包括对业务数据的同步、处理及落库。

在本实施例中，业务数据经过ETL处理落库并往后发送用于触发实时特征计算的消息，以使事件发生后就能够立即计算用户特征的功能。

S205、当检测到数据处理结果被存储至数据库时，判断流式数据处理平台包括的kafka平台中是否存在sql化的特征配置文件，若是，则执行步骤S206；若否，则结束本流程。

本实施例中，因为计算用户的特征需要有一定的逻辑（即用户需求逻辑），因此，该方法中已经将这些实现逻辑进行了配置化，得到了sql化的特征配置文件。其原理是，将用户需求转化成sql语句，然后根据sql的逻辑再转化成特征配置文件。

S206、判断特征配置文件是否与数据处理结果相对应，若是，则执行步骤S207~S208；若否，则结束本流程。

本实施例中，若特征配置文件不与数据处理结果相对应，则获取与数据处理结果相对应的特征配置文件，并触发后续步骤S207~S208。

S207、在数据库中加载与数据处理结果相对应的用户数据。

S208、根据特征配置文件和用户数据进行计算，得到用户特征。

本实施例中，flink（Apache Flink）是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。

本实施例中，mysql是一个关系型数据库。

本实施例中，canal可用于对数据库增量日志进行解析，还用于提供增量数据订阅与消费。

本实施例中，dts（Data Transmission Service，简称DTS）指代数据传输服务。

本实施例中，DataHub平台是流式数据（Streaming Data）的处理平台，提供对流式数据的发布（Publish），订阅（Subscribe）和分发功能。

本实施例中，Kafka凭条是一个开源流处理平台，由Scala和Java编写。

本实施例中，ETL（Extract-Transform-Load）用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。

本实施例中，Config用于指代特征配置文件。

本实施例中，Mongo用于指代mongo数据库。

请参阅图5，图5是该方法的系统流程示意图，对于该系统流程示意图的解释说明可以参照实施例1或实施例2。

举例来说，该方法可以通过dts和canal获取mysql中的业务数据，然后再通过datahub平台和kafka平台分别获取上述的业务数据，以使flink在datahub平台和kafka平台中过去到上述的业务数据。在flink获取到上述业务数据时，对上述业务数据进行简单ETL处理，并将处理结果落入mongo数据库，以使flink根据落库的时间直接获取到kafka平台中的类sql化的特征配置文件，并在同时提取mongo数据库中的中用户数据，以使flink可以根据特征配置文件和用户数据计算出用户特征。

具体举例来说，用户为王五，王五办理了一笔业务，此时办理完成的业务会生成相应的数据进行数据落库存储。与此同时，flink可以检测到王五办理的业务数据已经落库，因此，立刻调取与王五相对应的类sql化的特征配置文件和王五的用户信息，并通过flink根据王五的特征配置文件和王五的用户信息计算出王五的用户特征。

可见，实施本实施例所描述的实时用户特征的计算方法，能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

实施例3

请参看图3，图3为本申请实施例提供的一种实时用户特征的计算装置的结构示意图。如图3所示，该实时用户特征的计算装置包括：

第一判断单元310，用于当检测到数据处理结果被存储至数据库时，判断流式数据处理平台中是否存在特征配置文件；

第二判断单元320，用于当流式数据处理平台中存在特征配置文件时，判断特征配置文件是否与数据处理结果相对应；

加载单元330，用于当特征配置文件与数据处理结果相对应时，在数据库中加载与数据处理结果相对应的用户数据；

计算单元340，用于根据特征配置文件和用户数据进行计算，得到用户特征。

本申请实施例中，对于实时用户特征的计算装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的实时用户特征的计算装置，能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

实施例4

请一并参阅图4，图4是本申请实施例提供的一种实时用户特征的计算装置的结构示意图。其中，图4所示的实时用户特征的计算装置是由图3所示的实时用户特征的计算装置进行优化得到的。如图4所示，计算装置还包括：

获取单元350，用于获取流式数据处理平台包括的datahub平台和kafka平台中存储的业务数据；

处理单元360，用于对业务数据进行数据处理，得到数据处理结果；

存储单元370，用于存储数据处理结果至mongo数据库中。

作为一种可选的实施方式，存储单元370还用于通过数据传输服务将mysql数据库中存储的业务数据输入至流式数据处理平台包括的datahub平台中，通过数据库变更监控服务将业务数据输入至流式数据处理平台包括的kafka平台中。

作为一种可选的实施方式，处理单元360具体用于对业务数据进行数据抽取处理、数据转换处理、数据加载处理、空值处理、垃圾数据处理以及延时数据处理，得到数据处理结果。

作为一种可选的实施方式，第一判断单元310具体用于当检测到数据处理结果被存储至数据库时，判断流式数据处理平台包括的kafka平台中是否存在sql化的特征配置文件；并当kafka平台中存在sql化的特征配置文件时，触发第二判断单元320执行判断特征配置文件是否与数据处理结果相对应的操作。

本申请实施例中，对于实时用户特征的计算装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的实时用户特征的计算装置，能够通过特定的配置文件实现用户特征的自定义计算，从而计算得到更准确的用户特征；同时，还能够通过数据落库实时计算的方式，实现对用户特征进行实时计算的效果。

本申请实施例提供了一种电子设备，包括存储器以及处理器，存储器用于存储计算机程序，处理器运行计算机程序以使电子设备执行本申请实施例1或实施例2中任一项实时用户特征的计算方法。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例1或实施例2中任一项实时用户特征的计算方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。