CN112529632A - 基于流式引擎的计费方法、装置、系统、介质与设备 - Google Patents

Abstract

本公开提供了一种基于流式引擎的计费方法、装置、计费系统、计算机可读存储介质与电子设备，涉及数据处理技术领域。所述计费方法包括：通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；将所述中间数据存储至所述第一数据库；通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。本公开实现了数据计费的实时性，并减少重复计费、漏计费等错误计费的问题。

Description

基于流式引擎的计费方法、装置、系统、介质与设备

技术领域

本公开涉及数据处理技术领域，尤其涉及一种基于流式引擎的计费方法、基于流式引擎的计费装置、计费系统、计算机可读存储介质与电子设备。

背景技术

在互联网服务中，经常需要对大量数据进行计费，例如某提供广告服务的互联网平台需要对每一条广告计费，某提供下载或代理服务的互联网平台需要对每一条流量数据计费等。由于涉及到的数据量较高，相关技术中的计费方法大多存在错误计费的问题，如重复计费、漏计费等，影响服务质量。

发明内容

本公开提供了一种基于流式引擎的计费方法、基于流式引擎的计费装置、计费系统、计算机可读存储介质与电子设备，进而至少在一定程度上解决错误计费的问题。

根据本公开的第一方面，提供一种基于流式引擎的计费方法，包括：通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；将所述中间数据存储至所述第一数据库；通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

根据本公开的第二方面，提供一种基于流式引擎的计费装置，包括：整理模块，被配置为通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；转存模块，被配置为将所述中间数据存储至所述第一数据库；计费模块，被配置为通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；查验模块，被配置为对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

根据本公开的第三方面，提供一种计费系统，包括：第一数据库，用于存储待计费数据与中间数据；第一流式引擎，用于从所述第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据，将所述中间数据存储至所述第一数据库；第二流式引擎，用于从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；查验服务器，用于对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

根据本公开的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面的基于流式引擎的计费方法及其可能的实现方式。

根据本公开的第五方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述第一方面的基于流式引擎的计费方法及其可能的实现方式。

本公开的技术方案具有以下有益效果：

一方面，利用流式引擎执行数据的整理与计费处理，能够在产生数据的同时进行同步处理，以实现较优的实时性。另一方面，利用第一流式引擎与第二流式引擎在两个环节以不同的批次进行数据处理，满足了不同环节对于实时性、数据量的不同要求，并且将数据整理与数据计费两个环节解耦，防止其中一个环节的异常影响另一环节的正常进行，使得整个流程更加灵活。再一方面，通过对中间数据与计费结果数据进行对比查验，可以减少重复计费、漏计费等错误计费的问题，提高服务质量。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施方式，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本示例性实施方式中一种计费系统的架构示意图；

图2示出本示例性实施方式中一种基于流式引擎的计费方法的流程图；

图3示出本示例性实施方式中一种数据清洗方法的流程图；

图4示出本示例性实施方式中一种确定风险等级方法的流程图；

图5示出本示例性实施方式中一种数据聚合计费方法的流程图；

图6示出本示例性实施方式中另一种数据聚合计费方法的流程图；

图7示出本示例性实施方式中一种数据处理的示意图；

图8示出本示例性实施方式中一种基于流式引擎的计费装置的结构图；

图9示出本示例性实施方式中一种电子设备的结构图。

具体实施方式

现在将参考附图更全面地描述示例性实施方式。然而，示例性实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例性实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

相关数据对广告计费时，存在以下问题：

广告主竞价存在差别，例如某广告主在不同日期对同一广告的出价不同，使得同一广告的计费不同，相关技术通常采用订单聚合的方式进行计费，容易发生数据重复或丢失，导致重复计费或漏计费；

广告计费一般采用CPM(Cost Per Mile，千次曝光成本)，即按照每曝光一千次计费，因此一次曝光的计费可能非常低，甚至低于最小计费单位(如1分钱)，相关数据无法解决这部分数据的准确计费；

广告计费对实时性要求高，以及时向广告主反馈预算状况，同时避免累积长时间的数据给处理带来不便，相关技术通常在曝光结束后或者固定的时间节点进行计费，实时性较低。

鉴于上述问题，本公开的示例性实施方式提供一种基于流式引擎的计费方法。图1示出了该方法运行环境的计费系统架构图。如图1所示，该计费系统100可以包括：第一数据库110、第一流式引擎120、第二流式引擎130、查验服务器140。

第一数据库110用于存储待计费数据与中间数据。考虑到数据存储量较高且可能存在并发请求，第一数据库110可以采用分布式数据库；考虑到便于第一流式引擎120和第二流式引擎130读取数据，第一数据库110可以采用数据订阅系统。

在一种实施方式中，第一数据库110可以是分布式数据订阅系统Kafka。

第一流式引擎120用于从第一数据库110以第一窗口分批次获取待计费数据并进行整理，得到中间数据，将中间数据存储至第一数据库110。其中，第一流式引擎120可以是采用流式计算框架的服务器或服务器集群，流式计算框架可以采用Spark、Storm、Flink等。

在一种实施方式中，第一流式引擎120可以采用基于Spark框架的StructuredStreaming，具有较高的实时处理性能，且能够直接处理来自Kafka的数据。

第二流式引擎130用于从第一数据库110以第二窗口分批次获取中间数据并进行计费，得到计费结果数据。其中，第二流式引擎130可以是采用流式计算框架的服务器或服务器集群，流式计算框架可以采用Spark、Storm、Flink等。第二流式引擎130与第一流式引擎120可以相同，也可以不同。

在一种实施方式中，第二流式引擎130可以采用基于Spark框架的StructuredStreaming，具有较高的实时处理性能，且能够直接处理来自Kafka的数据。

第一流式引擎120对待计费数据进行整理，由于待计费数据的产生频率一般较高，在短时间内可能累积大量的待计费数据，因此需要及时进行整理，即数据整理的实时性要求较高。第二流式引擎130对整理后的中间数据进行计费，中间数据的量小于待计费数据，因此数据计费的实时性要求相对较低(也仅仅是相对于数据整理而言，从绝对意义上来说数据计费的实时性要求可能不低)。基于此，在一种实施方式中，第一流式引擎120的实时处理性能可以高于第二流式引擎130，例如第一流式引擎120采用Structured Streaming，第二流式引擎130采用Spark Streaming，前者的实时处理性能更高。

查验服务器140用于对比中间数据与计费结果数据，以查验是否存在计费异常。其中，查验服务器140是执行数据查验的服务器或服务器集群。

在一种实施方式中，查验服务器140可以部署第三流式引擎，通过第三流式引擎对比中间数据与计费结果数据，以查验是否存在计费异常。一般的，数据查验的实时性要求低于数据整理与数据计费，因此第三流式引擎的实时处理性能可以低于第一流式引擎120与第二流式引擎130，例如第一流式引擎120与第二流式引擎130均采用StructuredStreaming，第三流式引擎采用Spark Streaming。

在一种实施方式中，查验服务器140可以从第一数据库110获取中间数据与计费结果数据，以执行数据查验。在另一种实施方式中，计费系统100还可以包括第二数据库150，用于存储中间数据与计费结果数据，例如第一流式引擎120可以将中间数据存储至第一数据库110和第二数据库150，第二流式引擎130可以将计费结果数据存储至第二数据库150，查验数据库140可以从第二数据库150获取中间数据与计费结果数据，以执行数据查验。相比于第一数据库110，第二数据库150可以采用实时处理性能较低的数据系统，例如HDFS(Hadoop Distributed File System，Hadoop分布文件系统)，其数据更稳定。相比于将所有数据部署在第一数据库110中，设置第二数据库150能够有效分流第一数据库110的读写压力，降低计费系统100的总硬件成本，提高数据读写效率。

在一种实施方式中，可以将第一流式引擎120与第三流式引擎130部署在同一服务器或服务器集群上。也可以将查验服务器140部署在第一流式引擎120或第三流式引擎130所在的服务器或服务器集群上，通过流式引擎执行数据查验。

应当理解，图1中的计费系统100仅是示例性的，根据实现需要，可以将其中任意组件设置为任意数目，或者增加其他组件。计费系统100中各组件的具体功能将在方法部分的实施方式中详细说明。

图2示出了基于流式引擎的计费方法的示例性流程，可以包括：

步骤S210，通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；

步骤S220，将中间数据存储至第一数据库；

步骤S230，通过第二流式引擎从第一数据库以第二窗口分批次获取中间数据并进行计费，得到计费结果数据；

步骤S240，对比中间数据与计费结果数据，以查验是否存在计费异常。

通过上述方法，一方面，利用流式引擎执行数据的整理与计费处理，能够在产生数据的同时进行同步处理，以实现较优的实时性。另一方面，利用第一流式引擎与第二流式引擎在两个环节以不同的批次进行数据处理，满足了不同环节对于实时性、数据量的不同要求，并且将数据整理与数据计费两个环节解耦，防止其中一个环节的异常影响另一环节的正常进行，使得整个流程更加灵活。再一方面，通过对中间数据与计费结果数据进行对比查验，可以减少重复计费、漏计费等错误计费的问题，提高服务质量。

下面分别对图2中的每个步骤进行具体说明。

步骤S210中，通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据。

待计费数据是需要计费的原始数据。在广告计费的场景中，待计费数据包括广告曝光数据，某条广告曝光在客户端时，客户端通过用于信息上报的SDK(SoftwareDevelopment Kit，软件开发工具包)向服务端上报广告曝光日志，即为一条广告曝光数据，其中包括广告信息、广告主信息、客户端信息、曝光时间等；进而可以通过数据采集系统采集广告曝光数据并发送至第一数据库中加以存储，例如通过Flume(一种日志收集系统)采集广告曝光日志，发送至Kafka中存储。在流量计费的场景中，待计费数据包括流量日志数据。

本示例性实施方式中，第一流式引擎通过第一窗口从第一数据库分批次获取待计费数据并进行整理。实际应用中，通常不断产生新的待计费数据，这些数据不断被存储到第一数据库中，当新存入的待计费数据占满第一窗口时，第一流式引擎获取这些数据进行处理。第一窗口是对待计费数据划分批次的单位，可以是第一时间窗口或第一长度窗口。举例来说，第一窗口为第一时间窗口，表示待计费数据的时间跨度，如设为30s，则第一流式引擎每次抽取最近30s内产生或存储的待计费数据，这些待计费数据为一个批次，第一流式引擎对该批次的待计费数据进行整理，下一30s内的待计费数据为另一个批次。第一窗口为第一长度窗口，表示待计费数据所占据的存储位长，如设为16GB，则第一数据库中新存储的待计费数据每达到16GB时，第一流式引擎抽取这16GB的数据，为一个批次，第一流式引擎对该批次的待计费数据进行整理，下一16GB的待计费数据为另一个批次。

由上可知，第一窗口的大小决定了第一流式引擎每次执行数据整理的数据量大小。第一窗口如果过大，则每个批次的待计费数据过多，可能导致数据传输过程可能发生数据丢失，第一流式引擎的处理时间增加，数据整理的实时性降低；第一窗口如果过小，则每个批次的待计费数据过少，导致出现大量的小文件，消耗更多的存储资源，且数据整理的效果降低。实际应用中，可以根据实际需求与设备性能确定第一窗口的合适大小。

第一流式引擎可以主动从第一数据库读取待计费数据，也可以由第一数据库向第一流式引擎主动推送待计费数据。在一种实施方式中，第一数据库采用数据订阅系统，步骤S210可以包括：

通过第一流式引擎订阅第一数据库的第一主题，以抽取待计费数据。

其中，主题(Topic)是指第一数据库中的一类数据或消息。第一主题是第一数据库中关于待计费数据的主题。此外，第一数据库还可以存储其他类数据，建立其他主题，例如第一数据库还存储中间数据，并建立关于中间数据的第二主题。第一流式引擎订阅第一数据库的第一主题，当第一主题满足推送条件时(通常为满足第一窗口)，触发向第一流式引擎推送待计费数据。实际应用中，可以向第一流式引擎推送相关消息，第一流式引擎响应于该消息，从第一数据库抽取待计费数据。通过订阅的方式，可以使第一流式引擎及时获取待计费数据，无需第一流式引擎向第一数据库查询数据状态，减少第一流式引擎与第一数据库的交互次数，节约系统资源。

在步骤S210中，第一流式引擎可以对待计费数据进行ETL(Extract-Transform-Load，抽取-转换-加载)处理，本公开对具体的处理方式不做限定。下面以广告曝光数据为例进行说明。

(1)去重

广告曝光数据中可能存在重复的数据，包括但不限于以下情况：某些恶意用户通过篡改客户端的记录，制造重复的广告曝光数据；客户端上报广告曝光数据时，可能由于网络异常而重复上报。因此需要进行去重。

一般的，可以根据广告曝光数据中的标识判断是否存在重复数据，例如可以将每个批次中标识相同的广告曝光数据去重。

在一种实施方式中，可以将每个批次中曝光事件标识相同的广告曝光数据去重。其中，每一条广告曝光数据表示一次曝光事件，可以具有唯一的曝光事件标识，例如其字段可以是TraceID(Identity Document，身份标识)，如果两条或两条以上广告曝光数据的曝光事件标识相同，则为重复数据，保留其中的一条即可。

在另一种实施方式中，可以将每个批次中曝光目标标识与广告标识均相同的广告曝光数据去重。其中，曝光目标标识可以是广告曝光的客户端标识，包括但不限于：客户端的IMEI(International Mobile Equipment Identity，国际移动设备识别码)，IP地址(Internet Protocol，网络协议地址)，用户ID。广告标识是指每一条广告所具有的唯一标识，其字段可以是AdID。一般的，一条广告在一台客户端上仅曝光一次，如果两条或两条以上广告曝光数据的曝光目标标识与广告标识均相同，则为重复数据，保留其中的一条即可。

(2)清洗

广告曝光数据中可能存在错误或虚假的数据，包括但不限于以下情况：客户端产生或发送广告曝光数据时发生错误，导致数据错误；第一流式引擎从第一数据库获取广告曝光数据时发生错误，导致数据错误；某些恶意用户制造虚假数据。因此需要进行清洗。

一般的，通过检查数据格式，如字段是否完整，每个字段的数据是否可识别，格式是否正确等，可以检查出错误数据，进而清洗掉错误数据。

对于虚假数据，在一种实施方式中，参考图3所示，可以通过以下步骤S310和S320实现清洗：

步骤S310，确定每个批次中每一条广告曝光数据的风险等级。

风险等级用于度量每一条广告曝光数据为虚假数据的概率，风险等级越高，广告曝光数据为虚假数据的概率越高。

在一种实施方式中，可以根据每一条广告曝光数据中的曝光目标标识确定风险等级。例如系统可以根据不用客户端的历史行为，对其进行风险评级，如果某些用户存在历史作弊行为，则将其确定为较高的风险等级。

在另一种实施方式中，可以根据每一条广告曝光数据是否满足系统设定的规则来确定风险等级。例如广告曝光数据中的相关标识是否满足系统设定标识的规则，曝光时间与系统设定的曝光时间是否存在差别等等，从而判断是否为用户伪造的数据。

在一种实施方式中，参考图4所示，步骤S310包括：

步骤S410，调用反作弊接口处理广告曝光数据，得到广告曝光数据的风险等级；

步骤S420，如果反作弊接口处理广告曝光数据超时，则将广告曝光数据的风险等级确定为默认等级。

其中，反作弊接口是系统中反作弊服务提供的接口，调用反作弊接口可以将广告曝光数据加载至反作弊服务中，以进行处理。反作弊接口可以返回广告曝光数据的风险等级，例如可以采用键-值(Key-Value)数据的形式，以曝光事件标识或者曝光目标标识加广告标识为Key，以风险等级为Value。

反作弊接口可能处理某一条或多条广告曝光数据超时，例如数据传输异常、反作弊任务数量较多等情况，为了保证后续的流程正常进行，对于反作弊接口返回风险等级超时的广告曝光数据，可以将其风险等级确定为默认等级。默认等级可以是较低的等级。

步骤S320，滤除风险等级高于预设等级的广告曝光数据。

预设等级是衡量广告曝光数据的真实性是否可靠的标准，可以根据经验或实际需求设定。当某一条或多条广告曝光数据的风险等级高于预设等级时，认为该广告曝光数据为虚假数据，予以清洗。

待计费数据经过上述去重、清洗等整理处理后，得到中间数据。

继续参考图2，步骤S220中，将中间数据存储至第一数据库。

一般的，第一流式引擎对待计费数据分批次进行处理，每处理一个批次的待计费数据，得到对应的中间数据后，将中间数据发送至第一数据库进行存储。第一数据库可以对中间数据分片存储，即第一流式引擎发送的每个批次的中间数据为一个数据分片，也可以对中间数据不分片。

后续需要由第二流式引擎对中间数据进行处理。在第二流式引擎处理前先由第一数据库存储中间数据，可以将中间数据持久化，并且无需第二流式引擎在第一流式引擎完成待计费数据的处理后立即对中间数据进行处理，从而将第一流式引擎的数据整理与第二流式引擎的数据计费两个环节解耦，防止其中一个环节的异常影响另一环节的正常进行，使得整个流程更加灵活。

在一种实施方式中，在得到中间数据后，还可以将中间数据存储至第二数据库。第二数据库可以用于提供数据查验所需的数据，以分流并减轻第一数据库的读写压力。第二数据库可以采用实时处理性能低于第一数据库的数据系统，如第一数据库为Kafka，第二数据库为HDFS。写入第一数据库与第二数据库的中间数据应当相同，第一流式引擎可以将中间数据复制为两份，分别写入两个数据库。

在一种实施方式中，第一流式引擎为分布式集群时，可以利用本地事务确保写入第一数据库与第二数据库的中间数据具有一致性。

在一种实施方式中，由于第二数据库用于提供数据查验所需的数据，而数据查验的实时性要求不高，因此第一流式引擎无需实时向第二数据库写入中间数据，写入时间可以晚于第一流式引擎向第一数据库写入中间数据的时间，从而减少并发请求，进一步提高效率。

继续参考图2，步骤S230中，通过第二流式引擎从第一数据库以第二窗口分批次获取中间数据并进行计费，得到计费结果数据。

第二流式引擎通过第二窗口从第二数据库分批次获取中间数据并进行计费。第二窗口是对中间数据划分批次的单位，可以是第二时间窗口或第二长度窗口，具体请参考第一窗口部分的内容。需要说明的是，第二流式引擎对中间数据分批次处理时，中间数据的批次与第一流式引擎写入第一数据库的中间数据的批次可以是不同的批次概念，例如第一流式引擎分批次向第一数据库写入中间数据后，第一数据库对中间数据进行整体存储，第二流式引擎再以第二窗口分批次读取中间数据并计费。

第二窗口与第一窗口可以相同，也可以不同。在一种实施方式中，第一窗口可以小于第二窗口，例如第一时间窗口为30s，第二时间窗口为1分钟。由此，第一流式引擎进行数据整理时，每个批次处理的数据较少，第二流式引擎进行数据计费时，每个批次处理的数据较多，从而更好地对应了数据整理的实时性要求较高，数据计费的实时性要求较低。

在一种实施方式中，第二流式引擎为Structured Streaming，其设置Event Time(通常为数据产生的时间)为1分钟的第二时间窗口，每次从第一数据库获取1分钟内的中间数据，并进行计费。

在一种实施方式中，步骤S230可以包括：

通过第二流式引擎订阅第一数据库的第二主题，以抽取中间数据。

其中，第二主题是第一数据库中关于中间数据的主题。第二流式引擎订阅第一数据库的第二主题，当第二主题满足推送条件时(通常为满足第二窗口)，触发向第二流式引擎推送中间数据。实际应用中，可以向第二流式引擎推送相关消息，第二流式引擎响应于该消息，从第一数据库抽取中间数据。通过订阅的方式，可以使第二流式引擎及时获取中间数据，无需第二流式引擎向第一数据库查询数据状态，减少第二流式引擎与第一数据库的交互次数，节约系统资源。

在一种实施方式中，为了避免重复计费，步骤S230可以包括：

在通过所述第二流式引擎从所述第一数据库读取中间数据时，记录当前所读取的中间数据在所述第一数据库中的偏移值。

其中，偏移值是指中间数据在第一数据库中的存储地址相对于基地址的偏移值(offset)，用于查找中间数据的存储地址。在第一数据库中，中间数据通常是连续存储的，设置检查点(checkpoint)以在第二流式引擎读取中间数据时记录当前所读取的中间数据的偏移值(如last committed offset)，这样即使发生任务异常终端，也可以根据偏移值确定中间数据的位置，从而恢复到当前所读取的中间数据，保证数据不会丢失与重复。

考虑到中间数据仍然较为零散，可以采用聚合计费的方式。下面以广告曝光数据为例进行说明。

第一流式引擎对广告曝光数据进行整理后，得到中间数据，中间数据包含广告标识(AdID)。在一种实施方式中，参考图5所示，步骤S230可以包括：

步骤S510，将每个批次中广告标识相同的中间数据聚合；

步骤S520，对聚合后的中间数据进行计费。

举例来说，可以在每个批次的中间数据中，查找广告A的中间数据，统计其曝光次数以及其他相关数据，以聚合为一条中间数据，然后对该中间数据进行计费，则确定广告A的金额。

在一种实施方式中，进行计费前，可以对每个批次的中间数据进行去重，去重的方式可以参考第一流式引擎的去重方式，这里相当于二次去重，能够进一步改善数据重复情况，特别是减少第一流式引擎向第一数据库写入中间数据，以及第二流式引擎从第一数据库读取中间数据的过程中所产生的数据重复情况。

在一种实施方式中，参考图6所示，步骤S230可以包括：

步骤S610，将当前批次中广告标识相同的中间数据聚合；

步骤S620，从第三数据库读取未计费数据；

步骤S630，将当前批次中聚合后的中间数据与所读取的未计费数据聚合；

步骤S640，对聚合后金额达到预设金额的数据进行计费；

步骤S650，将聚合后金额低于预设金额的数据存储至第三数据库的未计费数据中。

其中，未计费数据是每一批次聚合后金额低于预设金额的数据。预设金额是确定零散金额的标准，可以根据经验或实际需求设定，例如设为1分钱，则低于1分钱的金额为零钱金额，其对应的数据不被计费，而是存储为未计费数据，与下一批次聚合后再计费。第三数据库用于存储未计费数据，考虑到未计费数据的数量相对较少，第三数据库可以采用关系型数据库，如MySQL，或者考虑到未计费数据的存储周期较短，第三数据库可以采用缓存数据库，如Redis。

从图6可知，当前批次的数据聚合实际上包括两个阶段：首先是将当前批次本身的中间数据聚合；然后再与上一批次遗留的未计费数据聚合，可以将广告标识相同的中间数据与未计费数据聚合为一条数据。聚合完成后，将数据按照预设金额进行划分，对高于或等于预设金额的数据正常计费，对低于预设金额的数据写入第三数据库加以存储。由此可以解决小金额(零钱)数据难以计费的问题，保证计费结果的准确性。

在一种实施方式中，对于每个批次中聚合后的每一条数据，可以对应生成一个订单号，该订单号具有全局唯一性，以保证计费的幂等性。

在计费时，可以调用扣费接口从相关广告主的账户中抠取相应费用，例如可以采用HTTP(Hyper Text Transfer Protocol，超文本传输协议)代理访问账务系统提供的Dubbo(一种分布式服务框架)接口，以实现扣费。

本示例性实施方式中，完成计费后可以得到计费结果数据，其中记录每一笔费用的扣费结果，扣费成功或失败等。

在一种实施方式中，上述聚合过程也可以由第一流式引擎在步骤S210中执行，则第二流式引擎在步骤S230中可以直接获取经过聚合的中间数据并进行计费，从而减轻数据计费的压力。实际应用中，可以根据具体情况灵活设置，例如第一流式引擎的压力较小时，由第一流式引擎执行数据聚合，第一流式引擎的压力较大时，由第二流式引擎执行数据聚合。本公开对此不做限定。

在一种实施方式中，在得到计费结果数据后，可以将计费结果数据写入第一数据库。后续从第一数据库获取中间数据与计费结果数据，以执行步骤S240。

在一种实施方式中，在得到计费结果数据后，可以将计费结果数据存储至第二数据库，以分流并减轻第一数据库的读写压力。

在一种实施方式中，由于第二数据库用于提供数据查验所需的数据，而数据查验的实时性要求不高，因此第二流式引擎无需实时向第二数据库写入计费结果数据，例如可以在得到计费结果数据后，选择较为空闲的时间向第二数据库写入计费结果数据，进一步提高效率。

继续参考图2，步骤S240中，对比中间数据与计费结果数据，以查验是否存在计费异常。

根据系统的实际架构，可以从第一数据库或第二数据库读取中间数据与计费结果数据，并进行对比。

通过对比中间数据与计费结果数据，可以查验是否存在漏计费的情况。在一种实施方式中，步骤S240可以包括：

检查计费结果数据中是否具有中间数据对应的计费结果数据，以查验是否对中间数据漏计费。

具体地，如果存在某一条或多条中间数据，计费结果数据中不包含该中间数据对应的计费结果(或者扣费失败)，则确定对该中间数据漏计费，可以触发生成针对该中间数据的重新计费任务，从而避免漏计费的发生。

图7示出了本示例性实施方式中数据处理的示意图。其中，第一数据库采用Kafka，第二数据库采用HDFS，第三数据库采用MySQL；第一流式引擎与第二流式引擎均采用Structured Streaming，第三流式引擎采用Spark Streaming。第一流式引擎从Kafka获取待计费数据，调用反作弊接口返回每一条待计费数据的风险等级，然后进行数据清洗与去重，得到中间数据；第一流式引擎将中间数据发送至Kafka与HDFS进行存储；第二流式引擎从Kafka获取中间数据，从MySQL获取上一批次的未计费数据，进行聚合计费，将金额低于预设金额的数据再次存储至MySQL的未计费数据中；第二流式引擎将计费结果数据存储至HDFS；第三流式引擎从HDFS获取中间数据与计费结果数据，通过比对中间数据与计费结果数据，查验是否存在计费异常，以消除重复计费、漏计费等问题。

图7所示的数据处理流程，支持单元测试，自动化测试即线上数据校验工具等。

本公开的示例性实施方式还提供一种基于流式引擎的计费装置。参考图8所示，该计费装置800可以包括：

整理模块810，被配置为通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；

转存模块820，被配置为将中间数据存储至第一数据库；

计费模块830，被配置为通过第二流式引擎从第一数据库以第二窗口分批次获取中间数据并进行计费，得到计费结果数据；

查验模块840，被配置为对比中间数据与计费结果数据，以查验是否存在计费异常。

在一种实施方式中，转存模块820，还被配置为：

将中间数据存储至第二数据库。

在一种实施方式中，转存模块820，还被配置为：

将计费结果数据存储至第二数据库。

在一种实施方式中，查验模块840，被配置为：

从第二数据库读取中间数据与计费结果数据，并进行对比。

在一种实施方式中，待计费数据包括广告曝光数据。

在一种实施方式中，整理模块810，被配置为：

将每个批次中标识相同的广告曝光数据去重。

在一种实施方式中，整理模块810，被配置为：

将每个批次中曝光目标标识与广告标识均相同的广告曝光数据去重。

在一种实施方式中，整理模块810，被配置为：

确定每个批次中每一条广告曝光数据的风险等级；

滤除风险等级高于预设等级的广告曝光数据。

在一种实施方式中，整理模块810，被配置为：

调用反作弊接口处理广告曝光数据，得到广告曝光数据的风险等级；

如果反作弊接口处理广告曝光数据超时，则将广告曝光数据的风险等级确定为默认等级。

在一种实施方式中，计费模块830，被配置为：

将每个批次中广告标识相同的中间数据聚合；

对聚合后的中间数据进行计费。

在一种实施方式中，计费模块830，被配置为：

将当前批次中广告标识相同的中间数据聚合；

从第三数据库读取未计费数据；

将当前批次中聚合后的中间数据与所读取的未计费数据聚合；

对聚合后金额达到预设金额的数据进行计费；

将聚合后金额低于预设金额的数据存储至第三数据库的未计费数据中。

在一种实施方式中，计费模块830，被配置为：

在通过第二流式引擎从第一数据库读取中间数据时，记录当前所读取的中间数据在第一数据库中的偏移值。

在一种实施方式中，查验模块840，被配置为：

检查计费结果数据中是否具有中间数据对应的计费结果数据，以查验是否对中间数据漏计费。

在一种实施方式中，整理模块810，被配置为：

通过第一流式引擎订阅第一数据库的第一主题，以抽取待计费数据。

计费模块830，被配置为：

通过第二流式引擎订阅第一数据库的第二主题，以抽取中间数据。

在一种实施方式中，第一窗口小于第二窗口。

在一种实施方式中，查验模块840，被配置为：

通过第三流式引擎对比中间数据与计费结果数据，以查验是否存在计费异常。

在一种实施方式中，第一流式引擎与第二流式引擎相同。

上述装置中各部分的具体细节在方法部分实施方式中已经详细说明，因而不再赘述。

本公开的示例性实施方式还提供了一种计算机可读存储介质，可以实现为一种程序产品的形式，其包括程序代码，当程序产品在电子设备上运行时，程序代码用于使电子设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。在一种实施方式中，该程序产品可以实现为便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本公开的示例性实施方式还提供了一种电子设备，可以是信息平台的后台服务器。下面参考图9对该电子设备进行说明。应当理解，图9显示的电子设备900仅仅是一个示例，不应对本本公开实施方式的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：至少一个处理单元910、至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。

其中，存储单元存储有程序代码，程序代码可以被处理单元910执行，使得处理单元910执行本说明书上述"示例性方法"部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元910可以执行如图2所示的方法步骤等。

存储单元920可以包括易失性存储单元，例如随机存取存储单元(RAM)921和/或高速缓存存储单元922，还可以进一步包括只读存储单元(ROM)923。

存储单元920还可以包括具有一组(至少一个)程序模块925的程序/实用工具924，这样的程序模块925包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以包括数据总线、地址总线和控制总线。

电子设备900也可以与一个或多个外部设备1000(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过输入/输出(I/O)接口940进行。电子设备900还可以通过网络适配器950与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器950通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限定。

Claims (21)

1.一种基于流式引擎的计费方法，其特征在于，包括：

通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；

将所述中间数据存储至所述第一数据库；

通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；

对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

2.根据权利要求1所述的方法，其特征在于，在得到中间数据后，所述方法还包括：

将所述中间数据存储至第二数据库。

3.根据权利要求2所述的方法，其特征在于，在得到计费结果数据后，所述方法还包括：

将所述计费结果数据存储至所述第二数据库。

4.根据权利要求3所述的方法，其特征在于，所述对比所述中间数据与所述计费结果数据，包括：

从所述第二数据库读取所述中间数据与所述计费结果数据，并进行对比。

5.根据权利要求1所述的方法，其特征在于，所述待计费数据包括广告曝光数据。

6.根据权利要求5所述的方法，其特征在于，所述通过流式引擎从第一数据库获取以第一窗口确定批次的待计费数据并进行整理，包括：

将每个批次中标识相同的广告曝光数据去重。

7.根据权利要求6所述的方法，其特征在于，所述将每个批次中标识相同的广告曝光数据去重，包括：

将每个批次中曝光目标标识与广告标识均相同的广告曝光数据去重。

8.根据权利要求5所述的方法，其特征在于，所述通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，包括：

确定每个批次中每一条广告曝光数据的风险等级；

滤除风险等级高于预设等级的广告曝光数据。

9.根据权利要求8所述的方法，其特征在于，所述确定每个批次中每一条广告曝光数据的风险等级，包括：

调用反作弊接口处理所述广告曝光数据，得到所述广告曝光数据的风险等级；

如果所述反作弊接口处理所述广告曝光数据超时，则将所述广告曝光数据的风险等级确定为默认等级。

10.根据权利要求5所述的方法，其特征在于，所述通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，包括：

将每个批次中广告标识相同的中间数据聚合；

对聚合后的中间数据进行计费。

11.根据权利要求10所述的方法，其特征在于，在将每个批次中广告标识相同的中间数据聚合后，所述方法还包括：

从第三数据库读取未计费数据；

将当前批次中聚合后的中间数据与所读取的未计费数据聚合；

所述对聚合后的中间数据进行计费，包括：

对聚合后金额达到预设金额的数据进行计费；

将聚合后金额低于所述预设金额的数据存储至所述第三数据库的未计费数据中。

12.根据权利要求1所述的方法，其特征在于，所述通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，包括：

在通过所述第二流式引擎从所述第一数据库读取中间数据时，记录当前所读取的中间数据在所述第一数据库中的偏移值。

13.根据权利要求1所述的方法，其特征在于，所述对比所述中间数据与所述计费结果数据，以查验是否存在计费异常，包括：

检查所述计费结果数据中是否具有所述中间数据对应的计费结果数据，以查验是否对所述中间数据漏计费。

14.根据权利要求1至13任一项所述的方法，其特征在于，所述通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，包括：

通过所述第一流式引擎订阅所述第一数据库的第一主题，以抽取所述待计费数据；

所述通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，包括：

通过所述第二流式引擎订阅所述第一数据库的第二主题，以抽取所述中间数据。

15.根据权利要求1至13任一项所述的方法，其特征在于，所述第一窗口小于所述第二窗口。

16.根据权利要求1至13任一项所述的方法，其特征在于，所述对比所述中间数据与所述计费结果数据，以查验是否存在计费异常，包括：

通过第三流式引擎对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

17.根据权利要求1至13任一项所述的方法，其特征在于，所述第一流式引擎与所述第二流式引擎相同。

18.一种基于流式引擎的计费装置，其特征在于，包括：

整理模块，被配置为通过第一流式引擎从第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据；

转存模块，被配置为将所述中间数据存储至所述第一数据库；

计费模块，被配置为通过第二流式引擎从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；

查验模块，被配置为对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

19.一种计费系统，其特征在于，包括：

第一数据库，用于存储待计费数据与中间数据；

第一流式引擎，用于从所述第一数据库以第一窗口分批次获取待计费数据并进行整理，得到中间数据，将所述中间数据存储至所述第一数据库；

第二流式引擎，用于从所述第一数据库以第二窗口分批次获取所述中间数据并进行计费，得到计费结果数据；

查验服务器，用于对比所述中间数据与所述计费结果数据，以查验是否存在计费异常。

20.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至17任一项所述的方法。

21.一种电子设备，其特征在于，包括：

处理器；以及

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

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至17任一项所述的方法。

Images