报表数据处理方法、装置、设备及存储介质

技术领域

本申请实施例涉及互联网技术领域，涉及但不限于一种报表数据处理方法、装置、设备及存储介质。

背景技术

在报表数据计算的常用架构中，通常包括实时计算和离线覆盖计算两种方式，实时计算能够保证数据的低延迟，离线覆盖计算能够保证数据的准确性。

相关技术中，为了保证报表数据的准确性，通常同时采用实时计算和离线覆盖计算两种方式。但是，两种计算方式需要两套系统，两套系统需要维护两套代码，开发和运维的成本很高；并且，在一些需要有回溯场景的报表数据计算中，相关技术中的报表计算架构中，由于实时计算时实时数据流的结果不可靠，则需要在某一时刻由数据可靠的离线数据流接管计算，则数据的更新频率会与离线更新的频率保持一致，报表计算架构会导致数据跳变，影响报表服务的数据质量。

发明内容

本申请实施例提供一种报表数据处理方法、装置、设备及存储介质，至少应用于区块链领域，能够降低开发和运维的成本，并且解决回溯场景下数据跳变的问题，提高报表服务的数据质量。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种报表数据处理方法，所述方法包括：

获取目标业务在当前时间段内的新增日志信息；

对所述新增日志信息进行日志解析，得到所述目标业务在第一时间维度上的至少一个增量统计数据；

获取所述目标业务在当前时间段之前的预设历史时间段内的至少一个历史统计数据；其中，所述历史统计数据是在第二时间维度上的统计数据，所述第二时间维度对应的时间间隔大于所述第一时间维度对应的时间间隔；

对全部具有所述第二时间维度的历史统计数据和全部具有所述第一时间维度的增量统计数据进行聚合处理，得到所述目标业务在当前时间段的聚合结果；

将所述聚合结果更新至所述目标业务对应的业务报表中。

本申请实施例提供一种报表数据处理装置，所述装置包括：

第一获取模块，用于获取目标业务在当前时间段内的新增日志信息；

日志解析模块，用于对所述新增日志信息进行日志解析，得到所述目标业务在第一时间维度上的至少一个增量统计数据；

第二获取模块，用于获取所述目标业务在当前时间段之前的预设历史时间段内的至少一个历史统计数据；其中，所述历史统计数据是在第二时间维度上的统计数据，所述第二时间维度对应的时间间隔大于所述第一时间维度对应的时间间隔；

聚合处理模块，用于对全部具有所述第二时间维度的历史统计数据和全部具有所述第一时间维度的增量统计数据进行聚合处理，得到所述目标业务在当前时间段的聚合结果；

更新模块，用于将所述聚合结果更新至所述目标业务对应的业务报表中。

本申请实施例提供一种报表数据处理设备，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现上述报表数据处理方法。

本申请实施例提供一种计算机程序产品或计算机程序，计算机程序产品或计算机程序包括可执行指令，可执行指令存储在计算机可读存储介质中；其中，报表数据处理设备的处理器从计算机可读存储介质中读取可执行指令，并执行可执行指令时，实现上述的报表数据处理方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行所述可执行指令时，实现上述报表数据处理方法。

本申请实施例具有以下有益效果：通过对当前时间段内的新增日志信息进行日志解析，得到目标业务在第一时间维度上的至少一个增量统计数据，以及获取目标业务在预设历史时间段内在第二时间维度上的至少一个历史统计数据，然后对全部历史统计数据和全部增量统计数据进行聚合处理，得到目标业务的聚合结果，从而采用聚合结果更新目标业务的业务报表，实现对目标业务的报表计算。如此，由于整个报表数据处理方法对应的报表计算框架不需要由两套系统来实现处理过程，从而极大地降低开发和运维的成本、降低资源开销；并且，针对有数据回溯的场景，由于是对历史统计数据和当前时间段的统计数据进行全量聚合处理，因此可以解决数据跳变的问题，提高报表服务的数据质量。

附图说明

图1是Lambda架构的实现路径示意图；

图2是本申请实施例提供的有回溯的报表场景示意图；

图3是本申请实施例提供的有回溯的报表场景的数据处理过程示意图；

图4是本申请实施例提供的报表数据处理系统的一个可选的架构示意图；

图5是本申请实施例提供的报表数据处理设备的结构示意图；

图6是本申请实施例提供的报表数据处理方法的一个可选的流程示意图；

图7是本申请实施例提供的报表数据处理方法的另一个可选的流程示意图；

图8是本申请实施例提供的分层聚合处理方法的实现流程示意图；

图9是本申请实施例的技术架构实现的广告投放报表产品界面图；

图10是按照图9所示的选项进行选择后得到的数据报表示意图；

图11是本申请实施例提供的报表计算框架的架构图；

图12是本申请实施例提供的报表计算框架和一些内部的逻辑示意图；

图13是本申请实施例提供的报表数据计算系统的核心聚合逻辑示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

相关技术中，为了保证报表数据的准确性，通常同时采用实时计算和离线覆盖计算两种方式。其中，Lambda架构是报表计算的常用架构，Lambda架构是一种为了在处理大规模数据时，同时发挥流处理和批处理的优势的数据处理架构。Lambda架构通过批处理提供全面、准确的数据，通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。为了满足下游的数据查询，批处理和流处理的结果会进行合并。在报表数据处理过程中，实时计算保证数据的低延迟；离线覆盖计算保证数据的准确性。实时计算通道通常采用消息队列作为输入源，例如，kafka(一种开源流处理平台)、pulsar(一种分布式的消息发布/订阅传递平台)，采用storm(一种开源的WebSerivce测试工具)或flink(一种流处理应用程序打造的开源流处理框架)作为实时计算框架，输出的结果直接实时更新底层的报表库，离线计算通常采用HDFS(一种被设计成适合运行在通用硬件上的分布式文件系统)小时/天分区的数据作为输入源，采用MapReduce(一种编程模型，用于大规模数据集(大于1TB)的并行运算)作为离线计算框架，输出的结果批量更新报表库。Lambda架构的实现路径如图1所示，首先将消息队列101分两条路径分别发送给HDFS系统102和storm/flink框架103，通过storm/flink框架103进行实时计算，得到实时计算结果；并通过HDFS系统102将消息队列101转发给MapReduce框架104进行离线计算，得到离线计算结果。最后，将实时计算结果和离线计算结果以离线计算结果覆盖实时计算结果的方式，更新至报表库105中。

Lambda架构系统实现简单，但是本身存在的问题也是非常明显的，首先，两套系统需要维护两套代码，开发和运维的成本很高，极易导致两套系统输出的结果不一致；其次，两套系统需要各自部署，资源开销巨大；最后，在一些需要有回溯场景的报表场景中，Lambda架构会导致数据跳变，影响报表服务的数据质量。尤其是最后一点，在广告业务报表系统中会显得尤为突出。

基于相关技术中所存在的问题，本申请实施例提供一种报表数据处理方法，该方法是一种基于spark streaming框架的实时、批量一体的报表聚合计算框架，同时解决了数据延迟和准确性的问题，并且在广告对外报表系统中得到了广泛的使用。

本申请实施例提供的报表数据处理方法中，首先，获取目标业务在当前时间段内的新增日志信息；对新增日志信息进行日志解析，得到目标业务在第一时间维度上的至少一个增量统计数据；然后，获取目标业务在当前时间段之前的预设历史时间段内的至少一个历史统计数据；其中，历史统计数据是在第二时间维度上的统计数据，第二时间维度对应的时间间隔大于第一时间维度对应的时间间隔；再然后，对全部历史统计数据和全部增量统计数据进行聚合处理，得到目标业务在当前时间段的聚合结果；最后，将聚合结果更新至目标业务对应的业务报表中。如此，由于整个报表数据处理方法对应的报表计算框架不需要由两套系统来实现处理过程，从而极大地降低开发和运维的成本、降低资源开销；并且，针对有数据回溯的场景，由于是对历史统计数据和当前时间段的统计数据进行全量聚合处理，因此可以解决数据跳变的问题，提高报表服务的数据质量。

这里，说明一下什么是有回溯的报表场景，首先来看这样一个例子，图2是本申请实施例提供的有回溯的报表场景示意图，如图2所示，一个用户在9月1号看到了广告，并进行了点击，跳转到落地页后将准备购买的商品加入了购物车，并且在9月29号进行了下单操作，针对9月29号的这条下单行为，如果按照上报时间统计，那么9月29号的下单量为1，但是如果按照下单对应的广告的扣费时间来统计，那么9月1日的下单量为1。这就相当于9月29号还要去改9月1号的数据，这就是带有回溯场景的报表，而这两种口径都是明确需要的。特别是第二种计费口径，用户可以直观感受到9月1号有多少广告消耗，这些广告消耗给广告主带来了多少下单。

本申请实施例的报表数据处理方法就是要解决图2所示的有回溯的报表场景的数据处理过程，保证报表数据的准确性。图3是本申请实施例提供的有回溯的报表场景的数据处理过程示意图，如图3所示，假设系统源源不断的收到计费时间是早上8点的下单数据，实时计算通道(即实时通道报表)忽略延迟，离线通道报表的数据有3个小时的延迟，也就是说，计费时间为8点至9点的下单量，实时通道是没有延迟的，但是离线通道有3小时的延迟。图3中横着的时间轴表示在不同的自然时间，广告主查看实时或者离线数据看到的计费时间是8点的下单量有多少，例如11点时，实时表是400个下单，离线表是100个下单，当然这里只是打个比方，系统是不会暴露所谓“实时”“离线”的概念给广告主的，广告主登录系统看到的值只有一个，由于实时流可能丢数据，因此一定要在某个时间点由离线流来接管。假设在12点，决定让离线流来接管实时流，那么客户看到的计费时间是8点的下单量的变化就是100，200，300，400，500，200……当然，也可以通过一些特殊的手段，例如让实时流只更新比如最近2个小时的数据来降低这种接管时引起的跳变，但是这种方式一旦协调不好，还是会引起指标的回退。

下面说明本申请实施例的报表数据处理设备的示例性应用，本申请实施例提供的报表数据处理设备可以实施为终端，也可以实施为服务器。在一种实现方式中，本申请实施例提供的报表数据处理设备可以实施为笔记本电脑，平板电脑，台式计算机，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)、智能机器人、智能家电和智能车载设备等任意的能够生成日志信息并形成报表数据的终端；在另一种实现方式中，本申请实施例提供的报表数据处理设备还可以实施为服务器，其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(CDN，Content Delivery Network)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。下面，将说明报表数据处理设备实施为服务器时的示例性应用。

参见图4，图4是本申请实施例提供的报表数据处理系统的一个可选的架构示意图，为实现支撑任意一个报表处理应用，通过报表处理应用准确的生成对应于日志信息的报表数据，本申请实施例的终端上至少安装有报表处理应用，其中，报表处理应用可以是任意一种能够生成流数据的应用，例如可以是广告应用。报表数据处理系统10中至少包括终端100、网络200和服务器300，其中服务器300是报表处理应用的服务器，即可以是广告应用的服务器，也可以是独立于广告应用的第三方服务器，该第三方服务器用于对广告应用中产生的日志信息进行聚合处理，得到广告应用中的目标业务的报表数据，生成该目标业务的业务报表。服务器300可以构成本申请实施例的报表数据处理设备。终端100通过网络200连接服务器300，网络200可以是广域网或者局域网，又或者是二者的组合。在实现报表数据处理时，终端100通过报表处理应用的客户端采集目标业务在当前时间段内的新增日志信息，并将新增日志信息通过网络200发送给服务器300，服务器300对新增日志信息进行日志解析，得到目标业务在第一时间维度上的增量统计数据；同时，服务器300获取目标业务在当前时间段之前的预设历史时间段内的历史统计数据；其中，历史统计数据是在第二时间维度上的统计数据，第二时间维度对应的时间间隔大于第一时间维度对应的时间间隔；并对全部的历史统计数据和全部的增量统计数据进行聚合处理，得到目标业务在当前时间段的聚合结果；最后将聚合结果更新至目标业务对应的业务报表中。在生成目标业务对应的业务报表之后，将业务报表反馈给终端100。

在一些实施例中，还可以由终端100实现报表数据处理过程，也就是说，由终端作为执行主体实现本申请实施例的报表数据处理方法，确定目标业务在当前时间段的聚合结果，并将聚合结果更新至目标业务对应的业务报表中。

本申请实施例所提供的报表数据处理方法还可以基于云平台并通过云技术来实现，例如，上述服务器300可以是云端服务器。通过云端服务器对新增日志信息进行日志解析，得到目标业务在第一时间维度上的增量统计数据，或者，通过云端服务器获取目标业务在当前时间段之前的预设历史时间段内的历史统计数据，或者，通过云端服务器对全部的历史统计数据和全部的增量统计数据进行聚合处理，得到目标业务在当前时间段的聚合结果，或者，通过云端服务器将聚合结果更新至目标业务对应的业务报表中等。

在一些实施例中，还可以具有云端存储器，可以将新增日志信息和预设历史时间段内的历史统计数据存储至云端存储器中，或者，还可以将目标业务对应的业务报表存储至云端存储器中。这样，在后续再次更新目标业务的业务报表时，可以直接从云端服务器中获取计算所需的数据，从而对目标业务的业务报表进行准确快速的计算。

这里需要说明的是，云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

本申请实施例涉及的报表数据处理系统10也可以是区块链系统的分布式系统，其中，所述分布式系统可以是由多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端形成的分布式节点，节点之间形成组成的点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。本申请实施例中，区块链系统中各节点的功能，涉及的功能包括：1)路由，节点具有的基本功能，用于支持节点之间的通信。节点除具有路由功能外，还可以具有以下功能：2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。4)共识(Consensus)，是区块链网络中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Proof of Stake)、股份授权证明(DPoS，Delegated Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。

本申请实施例中，在区块链系统的分布式系统中，每一节点均可以记录目标业务对应的业务报表，在对区块链系统中的节点中记录的业务报表进行更新时，可以基于前一节点中已存储的历史统计数据，生成用于更新后一节点的聚合结果，并基于所生成的聚合结果，对后一节点中的数据进行更新，生成目标业务最新的业务报表，并将业务报表存储至后一节点中，避免数据被篡改，且能够保证数据的准确性。

图5是本申请实施例提供的报表数据处理设备的结构示意图，图5所示的报表数据处理设备包括：至少一个处理器310、存储器350、至少一个网络接口320和用户接口330。报表数据处理设备中的各个组件通过总线系统340耦合在一起。可理解，总线系统340用于实现这些组件之间的连接通信。总线系统340除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5中将各种总线都标为总线系统340。

处理器310可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口330包括使得能够呈现媒体内容的一个或多个输出装置331，以及一个或多个输入装置332。

存储器350可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器350可选地包括在物理位置上远离处理器310的一个或多个存储设备。存储器350包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器350旨在包括任意适合类型的存储器。在一些实施例中，存储器350能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统351，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块352，用于经由一个或多个(有线或无线)网络接口320到达其他计算设备，示例性的网络接口320包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

输入处理模块353，用于对一个或多个来自一个或多个输入装置332之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可采用软件方式实现，图5示出了存储在存储器350中的一种报表数据处理装置354，该报表数据处理装置354可以是报表数据处理设备中的报表数据处理装置，其可以是程序和插件等形式的软件，包括以下软件模块：第一获取模块3541、日志解析模块3542、第二获取模块3543、聚合处理模块3544和更新模块3545，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，例如，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的报表数据处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logi c Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

本申请各实施例提供的报表数据处理方法可以由报表数据处理设备来执行，其中，该报表数据处理设备可以是任意一种能够生成日志信息并形成报表数据的终端，或者也可以是服务器，即本申请各实施例的报表数据处理方法可以通过终端来执行，也可以通过服务器来执行，或者还可以通过终端与服务器进行交互来执行。

参见图6，图6是本申请实施例提供的报表数据处理方法的一个可选的流程示意图，下面将结合图6示出的步骤进行说明，需要说明的是，图6中的报表数据处理方法是通过服务器作为执行主体为例来说明的。

步骤S601，获取目标业务在当前时间段内的新增日志信息。

这里，可以获取终端上所安装的报表处理应用的目标业务的新增日志信息，也就是说，可以针对于报表处理应用的任意一种业务，采用本申请实施例的报表数据处理方法对该业务的业务报表进行生成和更新。

目标业务可以是报表处理应用中的任意一种业务，例如当报表处理应用为广告应用时，则目标业务可以是广告业务。

当前时间段表示当前的一段时间，例如，当前的一分钟时长、一小时时长、一天时长等时间段。

需要说明的是，在报表处理应用的运行过程中，会实时的产生日志信息，即每一时刻均对应产生该时刻下的日志信息。新增日志信息是当前时间段内所产生的日志信息。日志信息中记录有用于表征针对目标业务的流数据，例如，请求操作、曝光量、点击量、转化量、互动量等流数据。通过解析新增日志信息，可以确定出当前时间段内针对目标业务的请求操作量、曝光量、点击量、转化量、互动量等数据。

步骤S602，对新增日志信息进行日志解析，得到目标业务在第一时间维度上的至少一个增量统计数据。

本申请实施例中，每一日志信息对应一时间戳，在确定目标业务在第一时间维度上的增量统计数据时，可以采用以下任意一种方式实现：

方式一：在对新增日志信息在进行日志解析之前，可以先基于每一日志信息的时间戳，对当前时间段内的新增日志信息进行划分，即采用相等的划分时间间隔的方式，对当前时间段内的新增日志信息进行划分，将新增日志信息划分成多个新增日志片段，每一新增日志片段对应一段时间段，且该时间段的时长小于当前时间段的时长。在得到多个新增日志片段之后，依次对每一新增日志片段进行日志解析，得到每一新增日志片段对应的统计数据片段，每一统计数据片段均是在第一时间维度上的增量统计数据。需要说明的是，第一时间维度对应的时间间隔，与对新增日志信息进行划分时的划分时间间隔相同。

方式二：对新增日志信息在进行日志解析，得到目标业务在当前时间段维度上的当前完整统计数据，其中，当前完整统计数据中的每一数据与对应的日志信息的时间戳相同；然后对当前完整统计数据进行划分。在划分的时候，可以基于第一时间维度对应的时间间隔，对当前完整统计数据进行划分，得到至少一个增量统计数据。

也就是说，上述方式一中是先对新增日志信息进行划分，然后再进行日志解析；上述方式二中是先对新增日志信息进行日志解析，然后再进行划分。

本申请实施例中，增量统计数据可以是关于目标业务上的任意一种类型的数据，例如请求操作量、曝光量、点击量、转化量、互动量等数据。在对新增日志信息进行日志解析时，可以指定需要解析的增量统计数据的类型，以及，指定第一时间维度对应的时间间隔，然后从新增日志信息中解析出该指定类型的增量统计数据。例如，当目标业务为目标广告时，可以指定需要解析出目标广告的转化量，且指定第一时间维度为一分钟，则所得到的增量统计数据即为当前时间段内每一分钟的转化量。

本申请实施例中，由于增量统计数据是对当前时间段内的新增日志信息进行日志解析后得到的数据，因此，当前时间段内增量统计数据可以是实时数据。

步骤S603，获取目标业务在当前时间段之前的预设历史时间段内的至少一个历史统计数据。其中，历史统计数据是在第二时间维度上的统计数据，第二时间维度对应的时间间隔大于第一时间维度对应的时间间隔。

这里，历史统计数据是对预设历史时间段内的历史日志信息进行日志解析后得到的统计数据。由于在每一时刻生成日志信息后，可以对当前时刻或者短期时间内的日志信息进行解析，得到在一个较小时间间隔的时间维度上的统计数据，因此，随着时间的推进，日志信息的累积，统计数据也会累积，那么，当在一个较小时间间隔的时间维度上的统计数据累积到一定量时，可以将这些统计数据进行再次统计，得到在一个较大时间间隔的时间维度上的统计数据，即得到一个历史统计数据。

举例来说，可以先统计多个一分钟内的转化量，当具有60个一分钟内的转化量时，可以将这60个一分钟内的转化量求和，得到一小时内的转化量，此时的一分钟就是一个较小时间间隔的时间维度，此时的一小时就是一个较大时间间隔的时间维度。

本申请实施例中，在确定预设历史时间段内的历史统计数据的时候，可以采用上述方法，先统计第一时间间隔的时间维度上的统计数据，然后统计第二时间间隔的时间维度上的统计数据，第一时间间隔小于第二时间间隔；再统计第三时间间隔的时间维度上的统计数据，第二时间间隔小于第三时间间隔，以此类推，直至按照预设条件，统计得到多个时间间隔下的统计数据为止，或者，直至统计到一定时间为止。

本申请实施例中，预设历史时间段内的历史统计数据既可以通过在预设历史时间段内进行实时统计计算得到，也可以在实时统计之后结合离线数据进行更新，因此预设历史时间段内的历史统计数据是结合实时数据和离线数据统计得到的能够真实反映预设历史时间段的数据水平的统计数据。

步骤S604，对全部具有第二时间维度的历史统计数据和全部具有第一时间维度的统计数据进行聚合处理，得到目标业务在当前时间段的聚合结果。

本申请实施例中，对全部具有第二时间维度的历史统计数据和全部具有第一时间维度的统计数据进行聚合处理，也就是对历史统计数据和统计数据进行全量聚合处理，全量聚合处理是指对所获取的历史统计数据和当前时间段内的统计数据全部参与计算，即全量聚合处理是对预设历史时间段内的全部历史统计数据和当前时间段内的全部统计数据进行聚合处理，将全部的历史统计数据和统计数据进行统计求和运算，得到目标业务在当前时间段的统计求和结果，即该聚合结果，其中，该聚合结果能够表征目标业务在预设历史时间段和当前时间段内的全量的统计数据。

需要说明的是，第二时间维度的数量可以是多个，也就是说，可以具有多个不同时间间隔的第二时间维度。并且，由于第二时间维度对应的时间间隔大于第一时间维度对应的时间间隔，因此多个第二时间维度中的每个第二时间维度对应的时间间隔均大于第一时间维度对应的时间间隔。本申请实施例中，不同的第二时间维度上的历史统计数据不同，在进行全量聚合计算时，是将不同的第二时间维度上对应于不同时间段的统计数据提取出进行计算，也就是说，可以基于已有第二时间维度上的历史统计数据进行再次聚合处理(对多个第二时间维度上的统计数据依次进行再次聚合处理即构成分层聚合处理过程)，得到具有更大时间间隔的第二时间维度上的历史统计数据。将在下文中对分层聚合处理进行详细说明。

步骤S605，将聚合结果更新至目标业务对应的业务报表中。

这里，在更新业务报表时，可以将当前时刻与聚合结果映射之后更新至业务报表中，也可以覆盖业务报表中历史时间段内的历史聚合结果，采用当前时间段的聚合结果替换历史聚合结果，即在业务报表中呈现目标业务最新的统计数据。

本申请实施例提供的报表数据处理方法，通过对当前时间段内的新增日志信息进行日志解析，得到目标业务在第一时间维度上的统计数据，以及获取目标业务在预设历史时间段内在第二时间维度上的历史统计数据，然后对全部具有第二时间维度的历史统计数据和全部具有第一时间维度的统计数据进行全量聚合处理，得到目标业务的聚合结果，从而采用聚合结果更新目标业务的业务报表，实现对目标业务的报表计算。如此，由于整个报表数据处理方法对应的报表计算框架不需要由两套系统来实现处理过程，从而极大地降低开发和运维的成本、降低资源开销；并且，针对有数据回溯的场景，由于是对历史统计数据和当前时间段的统计数据进行全量聚合处理，既考虑了预设历史时间段内的历史统计数据，还考虑当前时间段内的统计数据，即同时考虑了预设历史时间段内的历史统计数据和相对于预设历史时间段的增量数据，因此可以解决数据跳变的问题，提高报表服务的数据质量。

在一些实施例中，报表数据处理系统中至少包括终端和服务器，其中，终端上安装有广告应用，广告应用在对目标广告(即目标业务)进行投放的过程，会生成一系列的日志信息，日志信息中包括用于表征针对目标广告的流数据，例如，请求操作、曝光量、点击量、转化量、互动量等流数据。

下面以目标业务为广告投放对应的广告场景为例，对本申请实施例的报表数据处理方法进行说明。本申请实施例的报表数据处理方法可以通过报表计算框架来实现，报表计算框架被部署在服务器上，因此，可以通过服务器实现本申请实施例的报表数据处理方法。

图7是本申请实施例提供的报表数据处理方法的另一个可选的流程示意图，如图7所示，方法包括以下步骤：

步骤S701，终端通过广告应用的客户端采集针对目标业务的流数据，并基于流数据生成日志信息。

这里，目标业务的流数据是一组顺序、大量、快速、连续到达的，用于表征针对目标业务的任意一种操作的数据序列，目标业务的流数据是一个随时间延续而无限增长的动态数据集合。

步骤S702，终端将当前时间段内的新增日志信息发送给服务器。

在一些实施例中，可以是将当前时间段内的新增日志信息发送至分布式文件系统中，这样，服务器在获取新增日志信息时，可以从分布式文件系统中获取目标业务在当前时间段内的新增日志信息；其中，分布式文件系统是能够被多次访问，以请求获取目标业务的日志信息的文件系统，且分布式文件系统中的部分日志信息能够被删除。

步骤S703，服务器对新增日志信息进行日志解析，得到目标业务在第一时间维度上的至少一个增量统计数据。

步骤S704，服务器从具有不同时间间隔的时间维度中，将时间间隔大于第一时间维度的时间间隔的时间维度，确定为第二时间维度；其中，第二时间维度的数量为一个或多个。

本申请实施例中，可以预先提供多个具有不同时间间隔的时间维度；其中，在每一时间维度下，目标业务具有与时间维度对应的聚合统计数据。这里，聚合统计数据是针对目标业务的任意一种操作的统计数据。

举例来说，当具有三个第二时间维度时，这三个第二时间维度分别为10分钟、一小时、一天，则针对目标广告的转化量，聚合统计数据分别是：10分钟维度上的每10分钟的转化量、一小时维度上的每一小时的转化量、一天维度上的每一天的转化量。

步骤S705，服务器获取目标业务在历史时间段内对应于每一第二时间维度的聚合统计数据。

步骤S706，服务器对每一第二时间维度的聚合统计数据进行分层聚合处理，得到相应的第二时间维度下的分层聚合结果。

基于图7所示的实施例，本申请实施例再提供一种分层聚合处理方法，图8是本申请实施例提供的分层聚合处理方法的实现流程示意图，如图8所示，方法包括以下步骤(即步骤S706可以通过以下步骤实现)：

步骤S801，当第二时间维度的数量为多个时，确定每一第二时间维度对应的时间间隔。

步骤S802，按照时间间隔递增的顺序，对多个第二时间维度进行排序，形成时间维度序列。

举例来说，当具有三个第二时间维度时，这三个第二时间维度分别为10分钟、一小时、一天，那么这三个第二时间维度形成的时间维度序列为：10分钟的时间维度、一小时的时间维度、一天的时间维度。

步骤S803，按照时间维度序列，依次在每一第二时间维度上对在先的第二时间维度上的聚合统计数据进行再次聚合处理，对应得到目标业务在相应的第二时间维度上的分层聚合结果。

这里，是基于在先的第二时间维度上的聚合统计数据，聚合计算得到当前的第二时间维度上的分层聚合结果，也就是说，基于与当前的第二时间维度相邻的在先的第二时间维度上的聚合统计数据，聚合计算得到当前的第二时间维度上的结果。

需要说明的是，随着时间间隔的递增，对于时间维度序列中的第N个第二时间维度和第N-1个第二时间维度，其中，第N-1个第二时间维度上的统计数据对应的数据采集时长，大于或等于第N个第二时间维度上的统计数据对应的数据采集时长。

举例来说，第N-1个第二时间维度对应的时间间隔为10分钟，第N个第二时间维度对应的时间间隔为15分钟。那么，如果总共的数据采集时长为50分钟，在第N-1个第二时间维度上进行统计和聚合处理，是每10分钟统计一次数据，则可以得到5个统计数据；在第N个第二时间维度上进行统计和聚合处理，是每15分钟统计一次数据，由于50分钟的数据采集时长在基于15分钟的时间间隔进行划分时，仅能够得到3个完整且连续的15分钟，因此可以得到3个统计数据，对于这50分钟中最后的5分钟对应的数据，则不再进行第N个第二时间维度上的统计和聚合处理，并且，如果时间维度序列中仅包括第N个第二时间维度和第N-1个第二时间维度这两个第二时间维度，则预设历史时间段内的历史统计数据包括：在第N个第二时间维度上统计得到的3个统计数据和最后的5分钟对应的数据。即，预设历史时间段内的历史统计数据是总共的数据采集时长下的全部数据的统计数据，但是如果有更大的时间间隔对应的第二时间维度上的统计数据时，则优先采用更大的时间间隔对应的第二时间维度上统计得到的统计数据。也就是说，在获取预设历史时间段内的历史统计数据时，是得到预设历史时间段内在多个第二时间维度上的统计数据，并且，在任意两个第二时间维度上的统计数据中，具有较大时间间隔的第二时间维度上的统计数据的优先级，高于具有较小时间间隔的第二时间维度上的统计数据的优先级，在选择预设历史时间段内的历史统计数据时，可以按照优先级从不同的第二时间维度上选择统计数据，最终只要保证所得到的历史统计数据是预设历史时间段内的数据即可。

在一些实施例中，步骤S803可以通过以下步骤S8031和步骤S8031(图中未示出)实现：

步骤S8031，当在时间维度序列中的第N个第二时间维度上，对聚合统计数据进行再次聚合处理时，将在第N-1个第二时间维度上所得到的聚合统计数据，确定为在先的第二时间维度上的聚合统计数据。

步骤S8032，对在第N-1个第二时间维度上所得到的聚合统计数据进行再次聚合处理，对应得到目标业务在第N个第二时间维度上的聚合统计数据。其中，N为大于1的整数。

在一些实施例中，每一再次聚合处理对应一聚合任务；对应地，本申请实施例提供的报表数据处理方法，还可以包括以下处理方式中的至少之一：

方式一：当任一聚合任务的当前任务状态发生改变时，采用预设调度程序对聚合任务进行任务状态管理；其中，当前任务状态包括：待执行状态、正在执行状态、已执行状态和任务失败状态。

方式二：当在同一时刻下，在同一任务执行环境下处于待执行状态的聚合任务的数量大于数量阈值时，采用预设调度程序对处于待执行状态的聚合任务进行任务调度。

方式三：当任一聚合任务的当前任务状态为任务失败状态时，采用预设调度程序对聚合任务进行任务恢复处理，并将恢复处理后的聚合任务的当前任务状态调整为待执行状态。

请继续参照图7，方法还包括以下步骤：

步骤S707，服务器基于每一第二时间维度下的分层聚合结果，确定预设历史时间段内的历史统计数据。

本申请实施例中，历史统计数据是在第二时间维度上的统计数据，第二时间维度对应的时间间隔大于第一时间维度对应的时间间隔。历史统计数据的数量可以为多个。

在一些实施例中，步骤S707可以通过以下步骤S7071至步骤S7073(图中未示出)实现：

步骤S7071，确定每一第二时间维度上的分层聚合结果对应的起始统计时间点和终止统计时间点。

步骤S7072，根据起始统计时间点和终止统计时间点，确定第N-1个第二时间维度上的分层聚合结果，相对于第N个第二时间维度上的分层聚合结果的增量数据。

这里，这里，由于第N个第二时间维度的时间间隔大于第N-1个第二时间维度的时间间隔，因此，第N个第二时间维度上的统计数据的数量小于或等于第N-1个第二时间维度上的统计数据的数量。

当第N个第二时间维度上的统计数据的数量等于第N-1个第二时间维度上的统计数据(即分层聚合结果)的数量时，第N-1个第二时间维度上的分层聚合结果，相对于第N个第二时间维度上的分层聚合结果的增量数据为0；当第N个第二时间维度上的统计数据的数量小于第N-1个第二时间维度上的统计数据的数量时，第N-1个第二时间维度上的分层聚合结果，相对于第N个第二时间维度上的分层聚合结果的增量数据，是第N-1个第二时间维度上的分层聚合结果相对于第N个第二时间维度上的分层聚合结果所多出的统计数据。

步骤S7073，将全部第二时间维度上的增量数据，确定为预设历史时间段内的历史统计数据。

这里，当第二时间维度为时间维度序列中的最后一个时间维度时，第二时间维度上的增量数据是第二时间维度上的全部分层聚合结果。

在一些实施例中，第N个第二时间维度的层级高于第N-1个第二时间维度的层级。对应地，步骤S707中基于每一第二时间维度下的分层聚合结果，确定预设历史时间段内的历史统计数据，可以是当在两个第二时间维度中存在较高层级的第二时间维度的分层聚合结果时，采用较高层级的第二时间维度的分层聚合结果确定预设历史时间段内的历史统计数据。

在一些实施例中，在得到每一第二时间维度上的分层聚合结果时，可以将分层聚合结果缓存至分布式数据集中。这样，能够减少计算时对HDFS的访问，减少反序列化的开销。

步骤S708，服务器对历史统计数据和增量统计数据进行全量聚合处理，得到目标业务在当前时间段的聚合结果。

这里，全量聚合处理即对全部具有第二时间维度的历史统计数据和全部具有第一时间维度的增量统计数据进行统计计算。

步骤S709，服务器将聚合结果更新至目标业务对应的业务报表中。

本申请实施例中，可以以覆盖更新方式，将聚合结果更新至目标业务对应的业务报表中，以覆盖业务报表中的已有聚合结果。

步骤S710，服务器将业务报表发送给终端。

步骤S711，终端在当前界面上显示目标业务的业务报表。

本申请实施例提供的报表数据处理方法，由于是对历史统计数据和当前时间段的统计数据进行全量聚合处理，因此可以解决数据跳变的问题，提高报表服务的数据质量。

在一些实施例中，每一时刻的新增日志信息对应一时间戳；对应地，对新增日志信息进行日志解析，得到目标业务在第一时间维度上的统计数据，可以通过以下步骤实现：

步骤S11，对新增日志信息进行日志管理。

步骤S12，当确定出新增日志信息处于就绪状态时，基于时间戳，按照第一时间维度对应的时间间隔，对新增日志信息进行分割，形成多个新增日志片段。

步骤S13，对每一新增日志片段进行日志解析，得到目标业务在第一时间维度上的多个增量统计数据。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

由于Lambda架构无法很好支持回溯场景的报表计算，本质是因为实时流的结果不可靠，一定要在某个时刻由可靠的离线流来接管，但是这个接管的时机很难控制，一旦协调不好就会导致数据的跳变，另外一旦被离线流接管后，数据的更新频率就会和离线更新的频率保持一致，客户会明显感受到数据更新的节奏突然变慢了，在广告这种长回流周期窗口的业务形态下，这些问题显得尤为突出，给广告主非常不好的体验。

为了解决上述问题，本申请实施例提供一种报表数据处理方法，该方法通过报表计算框架来实现，本申请实施例以报表计算框架为spark streaming框架为例进行说明。本申请实施例是一种基于spark streaming的实时、批量一体的报表计算架构，从而很好的解决了以上的问题。

本申请实施例可以应用到各种提供行为识别(BI，Behavior Identity)分析能力的产品当中，例如广告投放系统的投放报表、广告诊断分析的诊断报表等。图9是本申请实施例的技术架构实现的广告投放报表产品界面图，如图9所示，在投放管理平台901上，具有报表页，在该报表页中，包括不同数据、不同日期范围、不同时间维度、不同指标口径和不同选择细分维度的数据。图10是按照图9所示的选项进行选择后得到的数据报表示意图。

图11是本申请实施例提供的报表计算框架的架构图，如图11所示，可以将消息队列1101里的数据分钟级落地到HDFS 1102上，然后通过一个统一的基于spark streaming的计算框架1103将聚合后的结果实时更新到报表库1104中。

本申请实施例中，spark steaming计算框架是计算的重点，接下来做进一步的详细展开。

图12是本申请实施例提供的报表计算框架和一些内部的逻辑示意图，整个框架使用H DFS上分钟级别的落地日志HDFS日志121作为输入，采用spark streaming 122作为报表计算引擎，计算结果可以输出到多种外部存储123中，其中，外部存储123可以是Hbase(一种分布式的、面向列的开源数据库)、HDFS、PIVOT(一套采用Java构建丰富互联网程序R IA应用程序的开源平台)、分布式数据仓库(TDW，Tencent distributed Data Warehouse)、MYSQL(一种关系型数据库管理系统)等。

如图12所示，spark streaming 122内部包括具体业务逻辑1221、具体任务1222、任务调度模块1223和外围模块1224。

其中，具体业务逻辑1221主要分成3个部分，第一部分是日志管理，例如这一分钟哪些日志已经就绪了，可以参与计算，这部分工作绝大部分是在驱动上完成的，第二部分是对日志进行聚合管理和计算，第三部分是将结果进行输出的输出管理部分，第二部分和第三部分基本是在executor(实现的是线程池的功能)上执行的。具体任务1222是由业务逻辑翻译成的可被spark引擎执行的具体的任务，主要有2类任务，一类任务是做各种粒度的聚合计算，另一类任务是将结果输出到存储引擎。任务调度模块1223是spark streaming这个框架本身提供的任务调度的能力，从而系统性保证任务的成功执行。外围模块1224是实一些外围的性能和业务指标的监测。

本申请实施例中，输入部分使用HDFS代替原来tdbank的方案，这里主要的考虑是希望输入是确定的，并且是可回放的，可回放带来两个主要的好处：一个是当计算任务失败时，可以通过读取历史日志，补做未完成的任务，保证数据不会丢失；另外一点是当发现原始日志有问题时，可以实现手术刀式的剔除历史的脏数据。这两点都是tdbank很难做到的。

计算部分，用spark streaming代替了原来的storm的方案，spark streaming本身的思想就是基于小批量(mini batch)的，保证了每一次计算结果的稳定性和正确性，并且spark worker是常驻的，消除了JVM启停的开销。另外通过自定义的HDFS上的聚合结果来作为任务的检查点，很好的规避了spark streaming检查点兼容性差，序列化反序列化低效的缺点。这里的检查点记录了任务当时的状态，是任务恢复重启的依据。

本申请实施例的报表计算框架是通过分层聚合、全量计算、幂等更新，很好的解决了报表回溯计算的挑战，另外通过不断的优化和打磨，这套计算框架的性能也是非常优异的。

图13是本申请实施例提供的报表数据计算系统的核心聚合逻辑示意图，如图13所示，聚合任务负责将1分钟的落地日志，生成各个表的聚合结果。以文件的形式保存在HDFS上对应的时间分片里，随着时间的推移，各表的统计结果在HDFS上源源不断的产生。当有一批增量的数据需要更新到外部存储(例如Hbase)的结果时，有2种选择，一种是增量的更新，将增量数据累加到之前的结果上，但是这样会破坏幂等性，重做任务会导致数据重复。所以选择全量的计算方式，扫描一段时间的历史数据，全量进行计算，将最终结果覆盖到报表库，这样的输出结果是幂等的，即使在开启推测执行的情况下，也可以保证结果的准确性。这就是全量计算(即全量聚合处理)，幂等更新。当做全量计算时，如果仅仅用1分钟粒度的历史数据来进行扫描，那么性能会很差，因此会不停的去计算出更高粒度(即较大时间间隔)的聚合结果，例如1小时、一天、五天的聚合结果，在全量计算时优先使用高层级(即较大时间间隔)的结果来拼接出需要扫描的全量数据，这就是分层聚合。另外将这些HDFS上不同粒度的聚合结果缓存在计算引擎(例如，Apache Spark，简称spark)的弹性分布式数据集缓存器(RDD cache，Resilient Distributed Datasets cache)中，尽量减少计算时对H DFS的访问，减少反序列化的开销。要说明的是，全量计算并不是将历史结果全部都输出一次，而是选择增量中的关键字进行筛选，也就是说只计算增量中有变化的数据，从而减少输出量。这套框架通过分层聚合、全量计算、幂等更新，很好解决了回溯的场景。

请继续参照图13，图中HDFS中间聚合结果文件即展示了分成聚合处理和全量聚合处理过程，其中，对于第一行1分钟(即1m)聚合结果中的增量131，即上述当前时间段内的增量统计数据，第一行的1m聚合结果对应的数据采集时长即预设历史时间段与当前时间段的时长之和，其中第一行的1m聚合结果对应的第一时间维度为1分钟时间维度。

第二行10分钟(即10m)聚合结果至第四行1天(即1d)聚合结果中，其中第一行至第四行的聚合结果均对应第二时间维度，且第二时间维度分别问10分钟(10m)、1小时(1h)、1天(1d)。

第二行的10m聚合结果对应的数据采集时长即预设历史时间段的时长，其中，粗线框框出的数据即第二时间维度为10m时的历史统计数据；第三行的1h聚合结果中，粗线框框出的数据即第二时间维度为1h时的历史统计数据；第四行的1d聚合结果中，粗线框框出的数据即第二时间维度为1d时的历史统计数据。由于第四行的1d聚合结果的第二时间维度是当前分层聚合处理过程中最大时间间隔的时间维度，因此，第四行的1d聚合结果中的全部数据均构成历史统计数据。本申请实施例中，在每一行对应的时间维度下，均基于上一行的聚合结果进行再次聚合处理。

本申请实施例中，HDFS上的各个层级的中间结果就是检查点(Checkpoint)；采用合理的RDD缓存，极大降低了对HDFS的访问以及反序列化的开销；只输出增量中出现的关键字，减少数据量。

本申请实施例提出的基于spark streaming的实时批量一体的报表计算框架，解决了la mbda架构可维护性差、资源开销大、回溯场景数据跳变等诸多问题，这一技术应用在了广告报表系统中，优化了50％资源，并且解决了广告主投诉的数据跳变问题。

可以理解的是，在本申请实施例中，涉及到用户信息的内容，例如，广告数据、日志信息、业务报表、目标业务等信息，如果涉及与用户信息或企业信息相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

下面继续说明本申请实施例提供的报表数据处理装置354实施为软件模块的示例性结构，在一些实施例中，如图5所示，报表数据处理装置354包括：

第一获取模块，用于获取目标业务在当前时间段内的新增日志信息；日志解析模块，用于对所述新增日志信息进行日志解析，得到所述目标业务在第一时间维度上的至少一个增量统计数据；第二获取模块，用于获取所述目标业务在当前时间段之前的预设历史时间段内的至少一个历史统计数据；其中，所述历史统计数据是在第二时间维度上的统计数据，所述第二时间维度对应的时间间隔大于所述第一时间维度对应的时间间隔；聚合处理模块，用于对全部具有所述第二时间维度的历史统计数据和全部具有所述第一时间维度的增量统计数据进行聚合处理，得到所述目标业务在当前时间段的聚合结果；更新模块，用于将所述聚合结果更新至所述目标业务对应的业务报表中。

在一些实施例中，所述第二获取模块还用于：提供多个具有不同时间间隔的时间维度；其中，在每一时间维度下，所述目标业务具有与所述时间维度对应的聚合统计数据；从所述具有不同时间间隔的时间维度中，将时间间隔大于所述第一时间维度的时间间隔的时间维度，确定为所述第二时间维度；其中，所述第二时间维度的数量为至少一个；获取所述目标业务在所述历史时间段内对应于每一所述第二时间维度的聚合统计数据；对每一所述第二时间维度的聚合统计数据进行分层聚合处理，得到相应的第二时间维度下的分层聚合结果；基于每一所述第二时间维度下的分层聚合结果，确定所述预设历史时间段内的每一历史统计数据。

在一些实施例中，所述第二获取模块还用于：当所述第二时间维度的数量为多个时，确定每一第二时间维度对应的时间间隔；按照所述时间间隔递增的顺序，对多个第二时间维度进行排序，形成时间维度序列；按照所述时间维度序列，依次在每一所述第二时间维度上对在先的第二时间维度上的所述聚合统计数据进行再次聚合处理，对应得到所述目标业务在相应的第二时间维度上的分层聚合结果。

在一些实施例中，所述第二获取模块还用于：当在所述时间维度序列中的第N个第二时间维度上，对所述聚合统计数据进行再次聚合处理时，将在第N-1个第二时间维度上所得到的聚合统计数据，确定为所述在先的第二时间维度上的聚合统计数据；对在所述第N-1个第二时间维度上所得到的聚合统计数据进行所述再次聚合处理，对应得到所述目标业务在所述第N个第二时间维度上的聚合统计数据；其中，N为大于1的整数。

在一些实施例中，所述第二获取模块还用于：确定每一所述第二时间维度上的分层聚合结果对应的起始统计时间点和终止统计时间点；根据所述起始统计时间点和所述终止统计时间点，确定第N-1个第二时间维度上的分层聚合结果，相对于第N个第二时间维度上的分层聚合结果的增量数据；将全部第二时间维度上的增量数据，确定为所述预设历史时间段内的历史统计数据；其中，当所述第二时间维度为所述时间维度序列中的最后一个时间维度时，所述第二时间维度上的增量数据是所述第二时间维度上的全部分层聚合结果。

在一些实施例中，第N个第二时间维度的层级高于第N-1个第二时间维度的层级；所述第二获取模块还用于：当在两个第二时间维度中存在较高层级的第二时间维度的分层聚合结果时，采用所述较高层级的第二时间维度的分层聚合结果确定所述预设历史时间段内的历史统计数据。

在一些实施例中，所述装置还包括：缓存模块，用于在得到每一所述第二时间维度上的分层聚合结果时，将所述分层聚合结果缓存至分布式数据集中。

在一些实施例中，每一所述再次聚合处理对应一聚合任务；所述装置还包括：处理模块，用于实现以下处理方式中的至少之一：当任一聚合任务的当前任务状态发生改变时，采用预设调度程序对所述聚合任务进行任务状态管理；其中，所述当前任务状态包括：待执行状态、正在执行状态、已执行状态和任务失败状态；当在同一时刻下，在同一任务执行环境下处于所述待执行状态的聚合任务的数量大于数量阈值时，采用所述预设调度程序对处于所述待执行状态的聚合任务进行任务调度；当任一聚合任务的当前任务状态为所述任务失败状态时，采用所述预设调度程序对所述聚合任务进行任务恢复处理，并将恢复处理后的聚合任务的当前任务状态调整为所述待执行状态。

在一些实施例中，每一时刻的新增日志信息对应一时间戳；所述日志解析模块还用于：对所述新增日志信息进行日志管理；当确定出所述新增日志信息处于就绪状态时，基于所述时间戳，按照所述第一时间维度对应的时间间隔，对所述新增日志信息进行分割，形成多个新增日志片段；对每一所述新增日志片段进行日志解析，得到所述目标业务在第一时间维度上的多个增量统计数据。

在一些实施例中，所述第一获取模块还用于：从分布式文件系统中获取所述目标业务在当前时间段内的新增日志信息；其中，所述分布式文件系统是能够被多次访问，以请求获取所述目标业务的日志信息的文件系统，且所述分布式文件系统中的部分日志信息能够被删除。

在一些实施例中，所述更新模块还用于：以覆盖更新方式，将所述聚合结果更新至所述目标业务对应的业务报表中，以覆盖所述业务报表中的已有聚合结果。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括可执行指令，该可执行指令是一种计算机指令；该可执行指令存储在计算机可读存储介质中。当报表数据处理设备的处理器从计算机可读存储介质读取该可执行指令，处理器执行该可执行指令时，使得该报表数据处理设备执行本申请实施例上述的方法。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图6示出的方法。

在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(FRAM，Ferromagnetic Random Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(E PROM，Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPR OM，Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，Compact Disk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备(可以是作业运行时长确定设备)上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。