CN118410076A - 指标的查询方法、统计方法、装置、设备和存储介质 - Google Patents

Abstract

本申请公开了一种指标的查询方法、统计方法、装置、设备和存储介质，应用于数据库技术领域。该查询方法包括：接收客户端的查询请求，查询请求用于指示查询目标时间段的目标时间粒度的目标指标；从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存，指标是对客户端上报的流水日志执行聚合与转换得到的；向客户端返回查询请求对应的目标指标。本方案可以减少指标的查询耗时。

Description

指标的查询方法、统计方法、装置、设备和存储介质

技术领域

本申请涉及数据库技术领域，特别涉及一种指标的查询方法、统计方法、装置、设备和存储介质。

背景技术

广告的指标（Indicator）能够反映用户获取、活跃、留存、转化、行为等信息。指标可以对外显示为点赞量、转发量、活跃度等，也可以应用于推荐系统，帮助提升推荐的质量与效率。

相关技术中，客户端的流水日志经过分布式流平台（Kafka）或分布式计算框架（Hadoop）批量导入服务器，服务器通过磁盘来保存一天或多天上报的流水日志，使用索引（Index）和分段（Segment）等方式，提升指标的查询性能。

然而，相关技术每次查询指标都需要在磁盘中检索大量的流水日志，查询比较耗时。例如，查询单个指标的耗时在50毫秒左右，批量查询上千个指标往往需要几十秒甚至几分钟。

发明内容

本申请提供了一种指标的查询方法、统计方法、装置、设备和存储介质。所述技术方案如下：

一方面，提供了一种指标的查询方法，所述方法由服务器执行，包括：

接收客户端的查询请求，所述查询请求用于指示查询目标时间段的目标时间粒度的目标指标；

从所述服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存，所述指标是对所述客户端上报的流水日志执行聚合与转换得到的；

向所述客户端返回所述查询请求对应的所述目标指标。

另一方面，提供了一种指标的统计方法，所述方法由服务器执行，包括：

接收客户端上报的流水日志；

对所述流水日志执行聚合与转换，得到不同时间粒度的指标；

将所述不同时间粒度的所述指标缓存至所述服务器的至少一个存储引擎，所述至少一个存储引擎用于在共享内存中写时缓存或读时缓存所述不同时间粒度的所述指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存。

另一方面，提供了一种指标的查询装置，所述装置包括：

接收模块，用于接收客户端的查询请求，所述查询请求用于指示查询目标时间段的目标时间粒度的目标指标；

查询模块，用于从所述服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存，所述指标是对所述客户端上报的流水日志执行聚合与转换得到的；

返回模块，用于向所述客户端返回所述查询请求对应的所述目标指标。

另一方面，提供了一种指标的统计装置，所述装置包括：

接收模块，用于接收客户端上报的流水日志；

处理模块，用于对所述流水日志执行聚合与转换，得到不同时间粒度的指标；

缓存模块，用于将所述不同时间粒度的所述指标缓存至所述服务器的至少一个存储引擎，所述至少一个存储引擎用于在共享内存中写时缓存或读时缓存所述不同时间粒度的所述指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存。

另一方面，提供了一种计算机设备，所述计算机设备包括：处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如上所述的指标的查询方法和/或指标的统计方法。

另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序由处理器加载并执行以实现如上所述的指标的查询方法和/或指标的统计方法。

另一方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，处理器从所述计算机可读存储介质中获取所述计算机指令，使得所述处理器加载并执行以实现如上所述的指标的查询方法和/或指标的统计方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过服务器中的至少一个存储引擎的读时缓存与写时缓存，将不同时间粒度的指标存储在共享内存中，实现了不同时间粒度的指标的全内存缓存，使得指标在查询时无需从磁盘中检索。由于共享内存读取相比磁盘读取耗时更低，因此能够减少指标的查询耗时，进而还能够满足指标的对外显示的需求和实时推荐系统的需求。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一个示例性实施例提供的计算机系统的结构框图；

图2是本申请一个示例性实施例提供的相关技术的系统示意图；

图3是本申请一个示例性实施例提供的指标的统计及查询的系统示意图；

图4是本申请一个示例性实施例提供的指标的查询方法的流程图；

图5是本申请一个示例性实施例提供的不同时间粒度的指标的示意图；

图6是本申请另一个示例性实施例提供的指标的查询方法的流程图；

图7是本申请一个示例性实施例提供的指标的查询方法的系统示意图；

图8是本申请一个示例性实施例提供的指标的统计方法的流程图；

图9是本申请另一个示例性实施例提供的指标的统计方法的流程图；

图10是本申请一个示例性实施例提供的指标的统计方法的系统示意图；

图11是本申请另一个示例性实施例提供的指标的统计方法的系统示意图；

图12是本申请一个示例性实施例提供的指标的查询装置的框图；

图13是本申请一个示例性实施例提供的指标的统计装置的框图；

图14是本申请一个示例性实施例提供的服务器的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一参数也可以被称为第二参数，类似地，第二参数也可以被称为第一参数。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

需要说明的是，本申请在收集用户的相关数据（例如，与指标的统计及查询、用户获取、活跃、留存、转化、行为等相关的数据）之前以及在收集用户的相关数据的过程中，都可以显示提示界面、弹窗或输出语音提示信息，该提示界面、弹窗或语音提示信息用于提示用户当前正在搜集其相关数据，使得本申请仅仅在获取到用户对该提示界面或弹窗发出的确认操作后，才开始执行获取用户相关数据的相关步骤，否则（即未获取到用户对该提示界面或弹窗发出的确认操作时），结束获取用户相关数据的相关步骤，即不获取用户的相关数据。换句话说，本申请所采集的所有用户数据都是在用户同意并授权的情况下进行采集的，且相关用户数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

首先，对本申请实施例中涉及的名词进行简单介绍。

指标（Indicator）：或称为计数指标，是一种能够反映用户获取、活跃、留存、转化、行为等信息的数据。指标可以对外显示为点赞量、转发量、活跃度等，也可以应用于推荐系统，帮助提升推荐的质量与效率。在一些实施例中，指标包括网页浏览量（Page View，PV）、独立访客数（Unique Visitor，UV）、访客访问次数（Visit View，VV）、独立IP数中的至少一种。网页浏览量是页面浏览的次数，用于衡量网站用户访问的网页数量。独立访客数是指一段时间内访问某网站的用户数。访客访问次数是指一段时间内所有访客访问网站的次数。独立IP数是指一段时间内使用不同IP地址的用户访问网站的次数。本实施例中，统计了不同时间粒度的指标，时间粒度包括分钟、小时、天、月、年中的至少一种。例如，统计每分钟的网页浏览量或统计每小时的独立访客数。

在线计数统计系统：是本申请实施例的提供的一种具有指标的实时在线统计功能以及实时在线查询功能的系统，可以位于或存储于服务器中。在线计数统计系统用于对大量的流水日志执行聚合与转换，将流水日志转换成不同时间粒度的指标并缓存，还提供快速实时查询不同时间粒度的指标的功能。

例如，当用户在短视频的推荐场景或好友场景下，刷到某一个短视频（Feed）时，一条包含内容标识（Feed Id）、用户账号标识、场景值（Scene）、时间戳、行为类型中的至少一种详情信息的流水日志，则会上报到在线计数统计系统，经过聚合与转化，则会生成在某分钟、某小时、某天的关键字（Key）对应的指标加1的操作，其中，关键字可以包括上述内容标识、用户账号标识、场景值和行为类型中的至少之一。当在线报表系统或推荐系统，需要查询目标指标时，只需要提供内容标识、用户账号标识、场景值和行为类型中的至少一种详情信息，以及所需查询的目标时间段以及目标时间粒度，就可以查询到相应的目标时间粒度对应的指标的具体数值。这些指标的具体数值可以对外显示为点赞量、转发量、进入主页的人数，也可以应用于推荐场景中，帮助提升推荐的质量和效率。

在线计数统计系统至少提供下述能力：1、高吞吐：通过客户端与服务器聚合的异步队列，提供高吞吐的日志上报能力，尤其在热点数据上报场景有很好的性能。2、低延迟：从流水日志的上报到指标查询的处理延迟达到秒级，甚至可以达到毫秒级，实现了指标的实时在线统计以及实时在线查询。3、低时延：通过读时缓存和写时缓存，降低指标的查询耗时，提供快速响应能力。4、最终一致性：同一个服务器集群（Set）中的服务器互为主备，主机更新的指标也可以写入备机，主机与备机可以同时对外提供查询服务，提升了查询性能。指标还定期存储至后端的可靠性存储中，避免指标丢失。

接下来，对本申请实施例中涉及的计算机系统进行说明。

图1是本申请一个示例性实施例提供的计算机系统100的结构框图。该计算机系统100可以实现成为指标的查询方法和/或指标的统计方法的系统架构。该计算机系统100包括：终端120和服务器140。

终端120可以是诸如手机、平板电脑、车载终端（车机）、可穿戴设备、PC（PersonalComputer，个人计算机）、无人预定终端等电子设备。终端120中可以安装运行目标应用程序的客户端。本申请实施例对该目标应用程序的形式不作限定，包括但不限于安装在终端120中的App（Application，应用程序）、客户端、小程序等，还可以是网页形式。

可选地，目标应用程序可以是用于指标的查询的应用程序，例如，目标应用程序实现为指标的实时在线查询平台或实时在线查询系统或实时在线查询数据库，也可以是提供有指标的查询功能的其他应用程序。或，目标应用程序可以是用于指标的统计的应用程序，例如，目标应用程序实现为指标的在线计数统计平台或在线计数统计系统或在线计数统计数据库，也可以是提供有指标的统计功能的其他应用程序。或，目标应用程序还可以是用于记录并生成流水日志的应用程序，也可以是提供有流水日志的生成功能的其他应用程序，也可以是提供有流水日志的获取、上报功能的其他应用程序。本申请实施例对此不作限定。

服务器140可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或分布式系统，还可以是提供云计算服务的云服务器、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（Content DeliveryNetwork，CDN）、以及大数据和人工智能平台等基础云计算服务的云服务器。服务器140可以是上述目标应用程序的后台服务器，用于为目标应用程序的客户端提供后台服务。

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

在一些实施例中，服务器140还可以实现为区块链系统中的节点。区块链（Blockchain）是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

终端120和服务器140之间可以通过网络进行通信，如有线或无线网络。

本申请实施例提供的指标的查询方法和/或指标的统计方法，各步骤的执行主体可以是计算机设备，计算机设备是指具备数据计算、处理和存储能力的电子设备。以图1所示的方案实施环境为例，可以由终端120执行指标的查询方法和/或指标的统计方法，例如，由终端120中安装运行的目标应用程序的客户端执行指标的查询方法和/或指标的统计方法，也可以由服务器140执行指标的查询方法和/或指标的统计方法，或由终端120和服务器140交互配合执行，本申请对此不作限定。

本领域技术人员可以知晓，上述终端120的数量可以更多或更少。比如，上述终端120可以仅为一个，或，上述终端120为几十个或几百个，或，更多数量。本申请实施例对终端120的数量和设备类型不加以限定。

接下来，对本申请实施例提供的指标的统计及查询方法进行简单介绍。

图2是本申请一个示例性实施例提供的相关技术的系统示意图。相关技术中，客户端的流水日志经过分布式流平台（Kafka）或分布式计算框架（Hadoop）批量导入服务器，服务器通过磁盘来保存一天或多天上报的流水日志，使用索引（Index）和分段（Segment）等方式，提升指标的查询性能。

例如，参考图2中的（1）的基于分布式数据存储系统（Durid）的实时分析系统，该实时分析系统是一个包括时间序列数据库、数据仓库和全文检索系统分析性数据平台。在流水日志经过日志收集101之后，依次上报分布式流平台（Kafka）102和分布式流平台组件（Storm ETL）103导入Durid104，进而能处理读请求105，以实现指标的查询。参考图2中的（2）的基于用于在线分析的列式数据库管理系统（ClickHouse）的实时存储系统，实时写入层111将流水日志上报至ClickHouse集群112，ClickHouse集群112结合分布式应用程序协调服务（ZooKeeper）113处理读请求114，以实现指标的查询。

然而，相关技术每次查询指标都需要在磁盘中检索大量的流水日志，查询比较耗时。例如，查询单个指标的耗时在50毫秒左右，批量查询上千个指标往往需要几十秒甚至几分钟。此外，相关技术中的流水日志需要批量写入，或每秒不超过一个写入请求，上报还需要经过Kafka或Hadoop，增加系统复杂度。流水日志生效时延一般是分钟级或者小时级，无法做到秒级实时更新。

基于此，本申请实施例提供了一个在线计数统计系统，其位于服务器中，能够将流水日志执行聚合与转换得到不同时间粒度的指标，并将这些不同时间粒度的指标全内存缓存，保证流水日志的秒级生效，基于该在线计数统计系统可以实现指标的查询，使得指标的查询为低耗时、高可用，进而能够满足指标的对外显示的需求和实时推荐系统的需求。

图3是本申请一个示例性实施例提供的指标的统计及查询的系统示意图。在一种可能的实现方式中，本申请实施例提供的指标的查询方法和/或指标的统计方法，可以由计算机设备执行，计算机设备可以是图1所示的服务器140。其中，执行指标的查询方法的服务器，与执行指标的统计方法的服务器可以是相同服务器或不同服务器。当这两个服务器为不同服务器时，可以是相同服务器集群中的不同服务器。示例性的，结合图3，服务器执行的指标的统计方法的步骤简述为步骤1至步骤3、指标的查询方法的步骤简述为步骤4至步骤6：

步骤1，服务器接收客户端上报的流水日志；可选地，流水日志为攒批上报。

步骤2，服务器对流水日志执行聚合与转换，得到不同时间粒度的指标；可选地，不同时间粒度包括分钟级、小时级、天级。例如，指标为网页浏览量（Page View，PV）和独立访客数（Unique Visitor，UV）。分钟级的指标包括分钟PV序列和分钟UV序列，小时级的指标包括小时PV序列和小时UV序列，天级的指标包括天PV序列和天UV序列。

步骤3，服务器将不同时间粒度的指标缓存至服务器的至少一个存储引擎，至少一个存储引擎用于在共享内存中写时缓存或读时缓存不同时间粒度的指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存。可选地，将不同时间粒度的指标按照对应的关键字缓存至服务器的至少一个存储引擎。

步骤4，服务器接收客户端的查询请求，查询请求用于指示查询目标时间段的目标时间粒度的目标指标。

步骤5，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存，指标是对客户端上报的流水日志执行聚合与转换得到的；可选地，服务器可以依次从至少一个存储引擎中的每个存储引擎查询目标指标，例如，先从写时缓存的存储引擎查询，在未查询到时，再从读时缓存的存储引擎中查询。

步骤6，服务器向客户端返回查询请求对应的目标指标。

具体地，参考图3，客户端包括共享内存，流水日志为攒批上报，客户端用于在共享内存中攒批多个流水日志，当达到设定条件时，将具有相同关键字（Key）的多个流水日志合并得到流水日志210。其中，设定条件可以设置为以下至少一种：达到预设时间点、达到预设时长、流水日志的数量达到预设数量、流水日志占用的存储空间大小达到预设存储空间大小。例如，N个流水日志的关键字均为：（promotion_id_1，action_type_曝光，scene_好友）+1，客户端将这N个流水日志转换成1条（promotion_id_1，action_type_曝光，scene_好友）+N的流水日志，接下来，批量发出一个远程过程调用（Remote Procedure Call，RPC）请求。客户端向服务器攒批上报流水日志210。流水日志210为流水日志1（Log1）、流水日志2（Log2）和流水日志3（Log3），表示为：Log1：（promotion_id_1，action_type_曝光，scene_好友）uin_list=[“123”]，+1；Log2：（promotion_id_1，action_type_曝光，scene_热门）uin_list=[“123”，“456”]，+2；Log3：（promotion_id_2，action_type_点击，scene_好友）uin_list=[“456”]，+1。

服务器对流水日志210执行聚合与转换得到不同关键字各自对应的分钟级、小时级、天级的指标220，指标220可以是为网页浏览量（Page View，PV）和独立访客数（UniqueVisitor，UV）。分钟级的指标220包括分钟PV序列和分钟UV序列，小时级的指标220包括小时PV序列和小时UV序列，天级的指标220包括天PV序列和天UV序列。各个关键字及其对应的指标220分别表示为：Key=promotion_1_曝光+3，uv add [“123”，“456”]；Key=promotion_1_曝光_好友+1，uv add [“123”]；Key=promotion_1_曝光_热门+2，uv add [“123”，“456”]。

查询请求为实时在线查询请求230，服务器接收实时在线查询请求230，实时在线查询请求230用于指示查询目标时间段的目标时间粒度的目标指标，表示为：Q1：promotion_id=1，action_type=曝光，scene=all，最近30分钟每分钟的PV；Q2：promotion_id=1，action_type=曝光，scene=热门，最近1小时的总UV；Q3：promotion_id=2，action_type=点击，scene=all，历史总PV。则服务器在指标220中获取查询请求230对应的目标指标，向客户端返回这些目标指标。

综上所述，本申请实施例提供的指标的统计方法以及查询方法，提供了支持多重条件聚合、多种时间粒度和时间段的在线计数统计系统。多重条件是指查询目标指标时的条件，可以基于关键字确定。例如，可以查询“promotion_id_1，action_type_曝光，scene=all”的指标，也可以查询“promotion_id_1，action_type_曝光，scene_好友”的指标。通过客户端与服务器对流水日志的聚合与转换得到指标，提供了高吞吐的流水日志的上报能力和对流水日志的处理能力，通过服务器中的读时缓存与写时缓存，并将指标存储在共享内存中，实现了指标的全内存缓存，使得指标查询时无需从磁盘中检索，降低指标的查询耗时，进而能够满足指标的对外显示的需求和实时推荐系统的需求。

接下来，对本申请实施例提供的指标的查询方法进行说明。

图4是本申请一个示例性实施例提供的指标的查询方法的流程图。该方法由计算机设备执行，计算机设备可以是图1所示的服务器140。该方法包括步骤320、步骤340和步骤360中的至少部分步骤。

步骤320，接收客户端的查询请求，查询请求用于指示查询目标时间段的目标时间粒度的目标指标。

指标（Indicator）能够反映用户获取、活跃、留存、转化、行为等信息。

可选地，指标包括网页浏览量（Page View，PV）、独立访客数（Unique Visitor，UV）、访客访问次数（Visit View，VV）、独立IP数中的至少一种。网页浏览量是页面浏览的次数，用于衡量网站用户访问的网页数量。独立访客数是指一段时间内访问某网站的用户数。访客访问次数是指一段时间内所有访客访问网站的次数。独立IP数是指一段时间内使用不同IP地址的用户访问网站的次数。前述不同类型的指标，均包括不同时间粒度。可选地，时间粒度包括分钟、小时、天、月、年中的至少一种。例如，以网页浏览量为例，不同时间粒度的指标可以是每分钟的网页浏览量或每天的网页浏览量。则前述的一段时间可以是设定的固定时长，还可以是基于不同的时间粒度来确定。

查询（Query）请求是客户端（Client）发出的请求，查询请求用于指示查询目标时间段的目标时间粒度的目标指标。目标时间粒度是预设的不同时间粒度中的一种。本实施例中，时间粒度包括分钟、小时、天、月、年中的至少一种。例如，查询请求用于指示查询时间段为20240601到20240607的每天的网页访问量，或，用于指示查询时间段为20240601 14:05至20240601 14:46每分钟的访客访问次数。

在一些实施例中，查询请求还可选携带查询详情信息，查询详情信息用于具体确定该查询请求对应的关键字。可选地，查询详情信息包括用户的操作及事件、访问情况、时间戳、协议类型、用户账号标识（promotion_id）、登录方式、登录IP地址、涉及的内容标识、行为类型（action_type）、场景值（scene）中的至少一种详细信息。可选地，行为类型包括点击、长按、曝光、滑动、更新、删除、增加、修改、转发中的至少一种。场景值是基于生成流水日志时的场景确定的，可以表示为场景对应的描述词。例如，场景值为好友、热门、短视频、直播中的至少一种。例如，查询请求携带有内容标识、用户账号标识、场景值和行为类型中的至少一种详情信息，用于指示查询目标时间段的目标时间粒度下，用户在一个具体场景下刷到一个具体内容的次数。还需说明的是，查询请求中的这些详情信息均为经过同意与授权的信息。

在一种可能实施方式中，查询请求包括远程过程调用（Remote Procedure Call，RPC）请求。客户端将用户所需查询的目标时间段、目标时间粒度、目标指标等信息，按照远程过程调用协议封装为查询请求，向服务器（Server）发送查询请求，服务器接收客户端的查询请求，解析查询请求以确定其指示查询的目标时间段、目标时间粒度的目标指标的信息。

步骤340，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存，指标是对客户端上报的流水日志执行聚合与转换得到的。

流水日志是用于记录应用程序或应用系统的各种运行状态、用户的操作及事件、访问情况、时间戳、协议类型、用户账号标识（promotion_id）、登录方式、登录ip地址、涉及的内容标识、行为类型（action_type）、场景值（Scene）中的至少一种详细信息的日志。可选地，行为类型包括点击、长按、曝光、滑动、更新、删除、增加、修改、转发中的至少一种。场景值是基于生成流水日志时的场景确定的，可以表示为场景对应的描述词。例如，场景值为好友、热门、短视频、直播中的至少一种。还需说明的是，流水日志中的这些详情信息均为经过同意与授权的信息。

在一些实施例中，客户端向服务器上报流水日志，服务器接收客户端上报的流水日志，对流水日志执行聚合与转换得到不同时间粒度的指标。可选地，客户端包括共享内存，共享内存为客户端的/dev/shm/目录，该目录用于表征挂载在内存的一块存储空间。流水日志为攒批上报，客户端用于在共享内存中攒批多个流水日志，当达到设定条件时，将具有相同关键字（Key）的多个流水日志合并得到预处理后的流水日志，向服务器上报这些预处理后的流水日志。

可选地，设定条件可以设置为以下至少一种：达到预设时间点、达到预设时长、时间最早的流水日志与当前时间的时间差达到预设时间差、流水日志的数量达到预设数量、流水日志占用的存储空间大小达到预设存储空间大小或共享内存的存储空间大小。例如，客户端的共享内存的存储空间大小为1GB，当流水日志已经达到1GB，或已经达到500条，或时间最早的流水日志距今已经100毫秒，则执行多个流水日志的合并。

例如，N个流水日志的关键字均为：（promotion_id_1，action_type_曝光，scene_好友）+1，客户端将这N个流水日志转换成1条（promotion_id_1，action_type_曝光，scene_好友）+N的流水日志，接下来，批量发出一个远程过程调用（Remote Procedure Call，RPC）请求，向客户端攒批上报流水日志。本实施例相当于在共享内存中攒批流水日志。由于客户端可能是多进程多线程的，这种攒批的方式能够用于多进程多线程，通过轻量级锁处理读写冲突。

在一些实施例中，指标是对客户端上报的流水日志执行聚合与转换得到的。其中，聚合与转换的方式为，服务器基于流水日志的日志属性执行排列组合，得到流水日志对应的关键字，接下来，基于关键字读取到不同时间粒度的待更新指标，也即旧的指标，接下来对待更新指标执行加N操作以更新这些待更新指标，从而实现对流水日志的聚合与转换，得到这些不同时间粒度的指标，N大于0。

具体地，流水日志的日志属性包括用户账号标识（promotion_id）、登录方式、登录IP地址、涉及的行为类型（action_type）、场景值（Scene）中的至少一种。例如，流水日志1（Log1）、流水日志2（Log2）和流水日志3（Log3），表示为：Log1：（promotion_id_1，action_type_曝光，scene_好友）uin_list=[“123”]，+1；Log2：（promotion_id_1，action_type_曝光，scene_热门）uin_list=[“123”，“456”]，+2；Log3：（promotion_id_2，action_type_点击，scene_好友）uin_list=[“456”]，+1。服务器对日志属性执行排列组合，确定关键字至少包括：Key=promotion_1_曝光；Key=promotion_1_曝光_好友；Key=promotion_1_曝光_热门。接下来，基于这些关键字读取到待更新指标，对待更新指标执行加N操作以更新这些待更新指标，得到不同时间粒度的指标，这些指标可以表示为：Key=promotion_1_曝光+3，uvadd [“123”，“456”]；Key=promotion_1_曝光_好友+1，uv add [“123”]；Key=promotion_1_曝光_热门+2，uv add [“123”，“456”]。

在一些实施例中，时间粒度包括分钟、小时、天、月、年中的至少一种。例如，不同时间粒度的指标可以是：统计每分钟的网页浏览量或统计每小时的独立访客数。每分钟的网页浏览量也可以称为分钟级的网页浏览量，每小时的独立访客数也可以称为小时级的独立访客数。具体地，不同时间粒度的指标包括两部分，一部分是指标的具体数值（Value），另一部分是日志标识（Uuid）序列集合，日志标识序列集合中包括多个流水日志各自的日志标识，这多个流水日志是聚集到该指标的流水日志。其中，日志标识可以采用字母、数字、随机数、字符中的一种或多种组合来表示。例如，以时间粒度为每分钟、每10分钟，指标是网页浏览量PV和独立访客数UV为例。参考图5的指标222的示意图，指标222包括分钟级的指标2221和10分钟级的指标2222以及日志标识序列集合2223。对于分钟级的指标2221和10分钟级的指标2222，需要记录有限个时间点对应的数值，以统计PV和UV。分钟级的指标2221和10分钟级的指标2222的第1行的Counter_t1，Counter_t2……中的每个Counter为相应时刻对应的64位无符号整数（Unit64），用于统计PV，第2行的Hll_t1，Hll_t2……中的每个Hll为相应时刻对应的基数（Hyperloglog），用于统计UV。Uuid集合2223包含最近聚合到指标222的流水日志的日志标识（Uuid）序列。

在一些实施例中，服务器包括共享内存，共享内存为服务器的/dev/shm/目录，该目录用于表征挂载在内存的一块存储空间。服务器包括至少一个存储引擎，至少一个存储引擎用于在共享内存中缓存相应数据，或理解为，至少一个存储引擎为使用C++编写的嵌入式KV存储引擎（RocksDB）实例，本质上是共享内存上的一个文件，则其缓存的指标是放在服务器的共享内存里。本实施例中，服务器还将对流水日志执行聚合与转换得到的不同时间粒度的指标，缓存到至少一个存储引擎。可选地，缓存时，可以是写时缓存或读时缓存，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取某一个指标时在至少一个存储引擎中缓存，这将在后续实施例中详细说明。本实施例中，服务器的共享内存与磁盘相比，读写性能更高，能够提高指标的查询效率。而且，当进程退出时，共享内存里的数据仍然存在，避免数据丢失。

可选地，服务器接收查询请求，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标。在一些实施例中，在至少一个存储引擎为一个存储引擎时，从该存储引擎获取目标指标即可。在至少一个存储引擎为多个存储引擎时，按照多个存储引擎对应的预设查询顺序，或多个存储引擎对应的预设优先级，或查询请求指示的查询顺序，或查询请求指示的至少一个存储引擎中的目标存储引擎，或目标指标的数据属性，查询目标指标。其中，数据属性包括冷数据、热数据的其中一种。冷数据是指访问频率低于阈值的数据，不会经常被查询。热数据是指访问频率高于阈值的数据，会经常被查询。例如，至少一个存储引擎包括存储引擎1和存储引擎2，预设查询顺序依次为存储引擎1、存储引擎2，或，目标指标的数据属性为热数据，则先从存储引擎1中查询目标指标，当未查询到（miss）时，继续在存储引擎2中查询该目标指标。

在一种可能实现方式中，本实施例的服务器为服务器集群（Set）中的一个服务器，一个服务器集群中的服务器互为主备，同一个服务器集群中的每个服务器中的指标是同步的、完全一致的。当查询目标指标时，可以是从服务器集群中的任意一个服务器中查询。

这里，还对于服务器集群（Set）进行一些补充说明。定义数据分片（Shard），这些与指标相关的数据存储在数据分片上。每一个服务器集群包含多个数据分片，同一个服务器集群中的每一个服务器持有的数据分片相同，不同服务器集群之间的数据分片不重叠。比如，将9个服务器分成3个服务器集群：Set0、Set1、Set2，每个服务器集群中包含3个服务器。定义数据分片数是固定值65536，通过一致性哈希（Hash）算法，每一个数据分片分别对应唯一的一个服务器集群。对于所有的流水日志和指标，他们的关键字（Key）会存在一些公共部分，比如前述实施例的promotion_id，基于promotion_id执行哈希算法得到哈希值，基于哈希值对数据分片数65536取模，得到对应的数据分片标识（Shard_Id），通过一致性哈希算法得到数据分片标识对应的服务器集群标识（Set_Id），接下来，通过路由表确定服务器集群标识对应的服务器集群，路由表存储有服务器集群标识及其对应的服务器集群，从而确定查询所使用到的这个服务器集群中的3个服务器中的任意一个服务器。

具体地，本实施例使用的服务器为服务器集群中的任意一个服务器，在步骤340从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标之前，还需要先确定该服务器所在的服务器集群。具体地，基于查询请求对应的关键字，以及定义的数据分片数，对关键字执行哈希算法得到哈希值，基于哈希值对数据分片数取模，得到关键字对应的数据分片标识；通过一致性哈希算法得到数据分片标识对应的服务器集群标识；通过路由表确定服务器集群标识对应的服务器集群，路由表存储有服务器集群标识及其对应的服务器集群，将该服务器集群中的任一服务器确定为查询所使用到的服务器。

步骤360，向客户端返回查询请求对应的目标指标。

示例性的，服务器向客户端返回查询请求对应的目标指标。可选地，该目标指标可以在客户端对外显示为一个数值，例如，显示为点赞量、转发量、活跃度中的至少一种，或，客户端还用于基于目标指标显示推荐内容，推荐内容可以是短视频、推荐图像、推荐文本、推荐广告中的至少一种。

综上所述，本申请实施例提供的指标的查询方法，服务器接收客户端的查询请求，查询请求用于指示查询目标时间段的目标时间粒度的目标指标；从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存，指标是对客户端上报的流水日志执行聚合与转换得到的；向客户端返回查询请求对应的目标指标。据此，通过服务器中的至少一个存储引擎的读时缓存与写时缓存，将不同时间粒度的指标存储在共享内存中，实现了不同时间粒度的指标的全内存缓存，使得指标在查询时无需从磁盘中检索。由于共享内存读取相比磁盘读取耗时更低，因此能够减少指标的查询耗时，进而还能够满足指标的对外显示的需求和实时推荐系统的需求。

在一些实施例中，为了确保查询的准确度，服务器还采用键值对形式存储不同时间粒度的指标。示例性的，图6是本申请一个示例性实施例提供的指标的查询方法的流程图。步骤340具体实现为步骤342。

步骤342，基于查询请求对应的关键字，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标；其中，至少一个存储引擎用于以键值对形式缓存不同关键字对应的不同时间粒度的指标，关键字与指标一一对应。

键-值对（Key-Value pair）包括关键字（Key）及其一一对应的数值（Value）。其中，关键字用作数据的索引，数值则表示所存储和读取的数据，本实施例中的数据则为不同时间粒度的指标的具体数值。

可选地，在至少一个存储引擎中，至少一个存储引擎用于以键值对形式缓存不同关键字对应的不同时间粒度的指标，关键字与指标一一对应。则服务器基于查询请求对应的关键字，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取查询请求对应的目标指标。

本实施例中，服务器通过键值对形式存储关键字及其对应的指标，使得关键字与指标是唯一对应的，能够提高指标的查询效率，保证查询的准确性。

在一些实施例中，图7是本申请一个示例性实施例提供的指标的查询方法的系统示意图，涉及客户端10和服务器20。客户端10包括共享内存11。服务器20包括共享内存（图7未示出），服务器20包括至少一个存储引擎，至少一个存储引擎具体包括第一存储引擎（LogDB）21和第二存储引擎（Map DB）22。第一存储引擎21用于缓存流水日志，流水日志也可以理解为：客户端近期上报的流水日志。第二存储引擎22用于在共享内存中写时缓存第一类型的指标，第一类型的指标是基于流水日志对不同时间粒度的待更新指标执行更新后得到的指标，第一类型的指标也可以理解为：近期被更新的指标。服务器20的逻辑组件包括日志处理组件（Log ETL）25，日志处理组件25用于基于流水日志（Recent Log Extract）与待更新指标执行聚合与转换（Aggregate&Transformer），以更新待更新指标，得到第一类型的指标，以及，将第一类型的指标更新写入至第二存储引擎22，也即局部加载（Locally Load）至第二存储引擎22。第二存储引擎22缓存第一类型的指标，是基于日志处理组件25对第二存储引擎22的更新写入实现的，则第二存储引擎22缓存第一类型的指标的过程为：写时缓存。

在一些实施例中，在服务器20包括第一存储引擎21和第二存储引擎22的基础上，服务器20的至少一个存储引擎还包括第三存储引擎（Read Cache）23，第三存储引擎23用于读时缓存第二类型的指标，第二类型的指标是从后端存储引擎（TTL KV）24中读取的不同时间粒度的未更新、且被本次的查询请求或被上次的查询请求查询的指标，第二类型的指标也可以理解为：近期未更新但被查询到的指标。后端存储引擎24用于缓存所有的指标，第三存储引擎23缓存第二类型的指标，是基于对后端存储引擎24的读取实现的，则第三存储引擎23缓存第二类型的指标的过程为：读时缓存。

还需说明的是，由于在指标的统计方法中可以不涉及对后端存储引擎24的读取，可以涉及到日志处理组件25对流水日志执行的聚合与转换以及对第二存储引擎22的更新写入，则在指标的统计方法中可以暂时不使用到第三存储引擎23。在另一些实施例中，后端存储引擎24可以位于当前服务器中，还可以位于其他服务器中，还可以是专门用于提供可靠性存储服务的存储引擎，本实施例对此不做限制。

示例性的，继续参考图6，则步骤342可以具体实现为步骤3421。

步骤3421，基于查询请求对应的关键字，从第二存储引擎在共享内存中写时缓存的第一类型的指标中，获取查询请求对应的目标指标。

第二存储引擎（Map DB）用于缓存第一类型的指标，即近期被更新的指标，这些第一类型的指标被放在服务器的共享内存上，并以键值对形式缓存。

示例性的，服务器基于查询请求对应的关键字，从第二存储引擎在共享内存中写时缓存的第一类型的指标中，获取查询请求对应的目标指标。例如，查询请求表示为：Q2：promotion_id=1，action_type=曝光，scene=热门，最近1小时的总UV，则查询请求的关键字Key=promotion_1_曝光_热门，目标时间段是最近1小时，目标指标为总UV，从第二存储引擎查询上述关键字对应的目标指标的具体数值。

本实施例中，基于通常情况下，近期被更新的指标一般在短时间内更容易被查询到的假设，将聚合与转换得到的指标缓存在第二存储引擎（Map DB）作为写时缓存，查询指标时先从第二存储引擎中查询，实现指标的快速查询，以及，将第二存储引擎（Map DB）缓存的这些指标放在共享内存，由于共享内存读取相比磁盘读取耗时更低，因此能够减少指标的查询耗时。

在一些实施例中，当在第二存储引擎中未查询到（miss）目标指标时，表示该目标指标不是近期被更新的指标，可以继续从第三存储引擎中查询。示例性的，步骤342在步骤3421的基础上，还具体实现为步骤3422。

步骤3422，在未从第二存储引擎查询到查询请求对应的目标指标时，基于查询请求对应的关键字，从第三存储引擎在共享内存中读时缓存的第二类型的指标中，获取查询请求对应的目标指标。

第三存储引擎（Read Cache）用于缓存第二类型的指标，即近期未更新但被查询到的指标，这些第二类型的指标被放在服务器的共享内存上，并以键值对形式缓存。

示例性的，服务器在未从第二存储引擎查询到查询请求对应的目标指标时，表示该目标指标不是近期被更新的指标，接下来，基于查询请求对应的关键字，继续从第三存储引擎在共享内存中读时缓存的第二类型的指标中，获取查询请求对应的目标指标。需要说明的是，第三存储引擎在共享内存中读时缓存的第二类型的指标，可以是基于本次的查询请求或基于上次的查询请求读时缓存的。其中，上次的查询请求是指位于本次的查询请求之前的任意一次查询请求。

例如，假设上次的查询请求1用于指示查询到目标指标1，本次的查询请求2用于指示查询到目标指标1。对于上次的查询请求1，服务器在未从第二存储引擎查询到目标指标1时，从第三存储引擎在共享内存中读时缓存的第二类型的指标中，继续查询目标指标1，在仍然未从第三存储引擎查询到目标指标1时，则第三存储引擎穿透至后端存储引擎，以从后端存储引擎中读取到该目标指标1，并缓存该目标指标1以便于下次查询，也即方便于本次的查询请求2；对于本次的查询请求2，服务器在未从第二存储引擎查询到目标指标1时，从第三存储引擎在共享内存中读时缓存的第二类型的指标中，查询目标指标1。假设本次的查询请求2用于指示查询到目标指标2，则服务器在未从第二存储引擎查询到目标指标2时，从第三存储引擎在共享内存中读时缓存的第二类型的指标中，查询目标指标2，在未从第三存储引擎查询到目标指标2时，第三存储引擎用于穿透至后端存储引擎，以从后端存储引擎中读取到该目标指标2，并缓存该目标指标2以便于下次查询。

本实施例中，使用后端存储引擎作为可靠性存储，能够保存全量的指标，保证数据不丢失。当未从第二存储引擎查询到目标指标，则需要穿透到后端存储引擎，将穿透至后端存储引擎读取到的指标缓存在第三存储引擎（Read Cache）作为读时缓存，一是能够成功读取到指标，二是能够方便针对这些指标的下次的查询，提高下次查询时的响应速度。

接下来，对本申请实施例提供的指标的统计方法进行说明。

图8是本申请一个示例性实施例提供的指标的统计方法的流程图。该方法由计算机设备执行，计算机设备可以是图1所示的服务器140。该方法包括步骤420、步骤440和步骤460中的至少部分步骤。

步骤420，接收客户端上报的流水日志。

流水日志是用于记录应用程序或应用系统的各种运行状态、用户的操作及事件、访问情况、时间戳、协议类型、用户账号标识（promotion_id）、登录方式、登录IP地址、涉及的内容标识、行为类型（action_type）、场景值（Scene）中的至少一种详细信息的日志。可选地，行为类型包括点击、长按、曝光、滑动、更新、删除、增加、修改、转发中的至少一种。场景值是基于生成流水日志时的场景确定的，可以表示为场景对应的描述词。例如，场景值为好友、热门、短视频、直播中的至少一种。还需说明的是，流水日志中的这些详情信息均为经过同意与授权的信息。

在一些实施例中，客户端向服务器上报流水日志，服务器接收客户端上报的流水日志。可选地，客户端包括共享内存，共享内存为客户端的/dev/shm/目录，该目录用于表征挂载在内存的一块存储空间。流水日志为攒批上报，客户端用于在共享内存中攒批多个流水日志，当达到设定条件时，将具有相同关键字（Key）的多个流水日志合并得到预处理后的流水日志，向服务器上报这些预处理后的流水日志。

可选地，设定条件可以设置为以下至少一种：达到预设时间点、达到预设时长、时间最早的流水日志与当前时间的时间差达到预设时间差、流水日志的数量达到预设数量、流水日志占用的存储空间大小达到预设存储空间大小或共享内存的存储空间大小。例如，客户端的共享内存的存储空间大小为1GB，当流水日志已经达到1GB，或已经达到500条，或时间最早的流水日志距今已经100毫秒，则执行多个流水日志的合并。

例如，N个流水日志的关键字均为：（promotion_id_1，action_type_曝光，scene_好友）+1，客户端将这N个流水日志转换成1条（promotion_id_1，action_type_曝光，scene_好友）+N的流水日志，接下来，批量发出一个远程过程调用（Remote Procedure Call，RPC）请求，向客户端攒批上报流水日志。本实施例相当于在共享内存中攒批流水日志。由于客户端可能是多进程多线程的，这种攒批的方式能够用于多进程多线程，通过轻量级锁处理读写冲突。

步骤440，对流水日志执行聚合与转换，得到不同时间粒度的指标。

指标（Indicator）能够反映用户获取、活跃、留存、转化、行为等信息。

可选地，指标包括网页浏览量（Page View，PV）、独立访客数（Unique Visitor，UV）、访客访问次数（Visit View，VV）、独立IP数中的至少一种。网页浏览量是页面浏览的次数，用于衡量网站用户访问的网页数量。独立访客数是指一段时间内访问某网站的用户数。访客访问次数是指一段时间内所有访客访问网站的次数。独立IP数是指一段时间内使用不同IP地址的用户访问网站的次数。前述不同类型的指标，均包括不同时间粒度。可选地，时间粒度包括分钟、小时、天、月、年中的至少一种。例如，以网页浏览量为例，不同时间粒度的指标可以是每分钟的网页浏览量或每天的网页浏览量。则前述的一段时间可以是设定的固定时长，还可以是基于不同的时间粒度来确定。

示例性的，服务器对流水日志执行聚合与转换（Aggregate&Transformer），得到不同时间粒度的指标。例如，采用流水日志对应的时间戳，计算流水日志对应的分钟、10分钟、小时、天等时间粒度下的指标。比如，上报的流水日志的时间戳为20240610 10:09，那么流水日志对应的分钟为20240610 10:09，对应的10分钟为20240610 10:00，对应的小时为20240610 10:00，对应的天为20240610 00:00，从原本的指标中找到这些时间戳对应的待更新指标，并更新这些待更新指标后得到流水日志对应的不同时间粒度的指标。在一些实施例中，对流水日志执行聚合与转换是基于服务器中的日志处理组件（Log ETL）实现的。

在一些实施例中，服务器还包括防重入组件（Anti-Reentry）。服务器在对流水日志执行聚合与转换之前，还基于防重入组件过滤客户端重复上报的流水日志。具体地，防重入组件用于生成流水日志对应的日志标识（Uuid），并通过判断流水日志的日志标识是否已经存在于对应的指标包含的日志标识序列集合中，来过滤客户端重复上报的流水日志，避免重复计数。其中，日志标识序列集合一般保存最近10分钟内的最多5000条日志标识。

步骤460，将不同时间粒度的指标缓存至服务器的至少一个存储引擎，至少一个存储引擎用于在共享内存中写时缓存或读时缓存不同时间粒度的指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存。

在一些实施例中，服务器包括共享内存，共享内存为服务器的/dev/shm/目录，该目录用于表征挂载在内存的一块存储空间。服务器包括至少一个存储引擎，至少一个存储引擎用于在共享内存中缓存相应数据，或理解为，至少一个存储引擎为使用C++编写的嵌入式KV存储引擎（RocksDB）实例，本质上是共享内存上的一个文件，则其缓存的指标是放在服务器的共享内存里。本实施例中，服务器还将对流水日志执行聚合与转换得到的不同时间粒度的指标，缓存到至少一个存储引擎。可选地，缓存时，可以是写时缓存或读时缓存，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取某一个指标时在至少一个存储引擎中缓存，这将在后续实施例中详细说明。本实施例中，服务器的共享内存与磁盘相比，读写性能更高，能够提高指标的查询效率。而且，当进程退出时，共享内存里的数据仍然存在，避免数据丢失。

可选地，服务器将不同时间粒度的指标缓存至服务器的至少一个存储引擎，至少一个存储引擎用于在共享内存中写时缓存或读时缓存不同时间粒度的指标。需要说明的是，步骤420、步骤440和步骤460可以在步骤320之前执行，或，步骤320在步骤460之后执行，或，步骤320与步骤460同步执行。

综上所述，本申请实施例提供的指标的统计方法，服务器接收客户端上报的流水日志；对流水日志执行聚合与转换，得到不同时间粒度的指标；将不同时间粒度的指标缓存至服务器的至少一个存储引擎，至少一个存储引擎用于在共享内存中写时缓存或读时缓存不同时间粒度的指标，写时缓存是指将指标写入至少一个存储引擎时缓存，读时缓存是指读取指标时在至少一个存储引擎中缓存。据此，服务器能够对客户端上报的流水日志执行聚合与转换，得到不同时间粒度的指标，能够提高指标的统计速度。通过服务器中的至少一个存储引擎的读时缓存与写时缓存，将不同时间粒度的指标存储在共享内存中，实现了不同时间粒度的指标的全内存缓存，从而使得指标在查询时无需从磁盘中检索。由于共享内存读取相比磁盘读取耗时更低，因此能够减少指标的查询耗时，进而还能够满足指标的对外显示的需求和实时推荐系统的需求。

在一些实施例中，服务器包括日志处理组件（Log ETL），日志处理组件用于对流水日志执行聚合与转换。图9是本申请一个示例性实施例提供的指标的统计方法的流程图。则步骤440具体实现为步骤442。

步骤442，基于日志处理组件对流水日志执行聚合与转换，得到不同时间粒度的指标。

具体地，日志处理组件（Log ETL）用于基于客户端近期上报的流水日志（RecentLog Extract）执行聚合与转换（Aggregate&Transformer），得到不同时间粒度的指标。则服务器基于日志处理组件对流水日志执行聚合与转换，得到不同时间粒度的指标。

本实施例中，通过服务器的日志处理组件能够实现对流水日志的聚合与转换，从而能够快速得到不同时间粒度的指标，提高了指标的统计效率。

在一些实施例中，不同时间粒度的指标为第一类型的指标，至少一个存储引擎包括第一存储引擎（Log DB）和第二存储引擎（Map DB）。第一存储引擎用于缓存流水日志，流水日志也可以理解为：客户端近期上报的流水日志。第二存储引擎用于在共享内存中写时缓存第一类型的指标，第一类型的指标是基于流水日志对不同时间粒度的待更新指标执行更新后得到的指标，第一类型的指标也可以理解为：近期被更新的指标。

示例性的，继续参考图9，步骤442可选具体实现为步骤4421和步骤4422。

步骤4421，基于日志处理组件从第一存储引擎中批量读取流水日志，从第二存储引擎查询不同时间粒度的待更新指标。

第一存储引擎（Log DB）用于缓存流水日志，则日志处理组件（Log ETL）可以是按照设定的读取周期，或设定的读取数量，从第一存储引擎中批量读取流水日志。以及，从第二存储引擎（Map DB）查询到不同时间粒度的待更新指标。

示例性的，服务器基于日志处理组件从第一存储引擎中批量读取流水日志，从第二存储引擎查询不同时间粒度的待更新指标，这两个过程可以是先后执行或同步执行，本实施例对此不做限制。

步骤4422，基于流水日志与待更新指标执行聚合与转换，以更新待更新指标，得到第一类型的指标。

服务器通过日志处理组件，基于流水日志与待更新指标执行聚合与转换，以更新待更新指标，得到第一类型的指标。可选地，服务器通过日志处理组件，基于流水日志的日志属性执行排列组合，得到流水日志对应的关键字；基于关键字读取到待更新指标，对待更新指标执行加N操作以更新待更新指标，得到第一类型的指标，N大于0。在一些实施例中，在至少一个存储引擎为一个存储引擎时，在基于关键字读取到待更新指标时，从该存储引擎获取待更新指标即可。在至少一个存储引擎为多个存储引擎时，按照多个存储引擎对应的预设查询顺序，或多个存储引擎对应的预设优先级查询到待更新指标。

例如，日志处理组件基于流水日志的日志属性执行排列组合，生成不同时间粒度的指标对应的关键字（Key），接下来，依次从第二存储引擎（Map DB）、第三存储引擎（ReadCache）、后端存储引擎（TTL KV）中读取到待更新指标，对待更新指标执行+N得到新指标，即第一类型的指标，返回新指标。后续，日志处理组件还可以将该新指标写入第二存储引擎。

本实施例中，通过日志处理组件从第一存储引擎中批量读取流水日志，从第二存储引擎查询不同时间粒度的待更新指标。接下来，基于流水日志与待更新指标执行聚合与转换，以更新待更新指标，得到第一类型的指标，实现了对指标的更新，提高了指标的统计效率。

在一些实施例中，为了降低流水日志生效时延，将日志处理组件（Log ETL）拆分成多个线程。但是，当多个线程中的每个线程均用于扫描同一个第一存储引擎（Log DB），则会产生大量无效的重复扫描。因此，本实施例还将第一存储引擎（Log DB）拆分成多个列族（Column Family，CF），多个列族中的每个列族包括第一存储引擎（Log DB）中的一部分的流水日志，每个列族的读写是独立的，则日志处理组件（Log ETL）的每个线程用于扫描第一存储引擎中的至少一个列族对应的流水日志，也即一部分的流水日志，线程数与列族数可以相同。

具体地，本实施例的服务器为服务器集群中的一个服务器。结合前述实施例可知，一个服务器集群中的服务器持有的数据分片是完全一致的。则通常需要选择服务器集群中一个服务器作为主机，其他服务器作为备机。但是，这样会造成只有主机能够写入，导致中央处理器（Central Processing Unit，CPU）资源不均衡。因此，本实施例还配置了每个服务器集群中的线程数。例如，将一个服务器集群配置成9个线程，对应的，在第一存储引擎（LogDB）配置出9个列族（Column Family，CF）。9个线程通过优先级选主的方式，尽量使得服务器集群中的每个服务器持有的主线程数相等。比如，服务器集群包括3个服务器：M0、M1、M2，配置线程数为9个，则每个服务器均有9个线程，相对应的，第一存储引擎（Log DB）有9个列族。当流水日志上报并写入第一存储引擎（Log DB）时，服务器基于流水日志对应的关键词的哈希值对9取模，计算该流水日志对应的列族标识，从而将该流水日志同步写入3个服务器中的第一存储引擎（Log DB）中的该列族标识对应的列族。其中，9个线程通过优先级选主的方式，比如，默认情况下0、1、2线程的主是M0；3、4、5线程的主是M1；6、7、8线程的主是M2。则对于0、1、2线程，在M0服务器上分别对列族0、1、2里的流水日志执行聚合与转换，生成不同时间粒度的指标后，写入到本机的第二存储引擎（Map DB），并删除本机的第一存储引擎（MapDB）的列族0、1、2已处理的流水日志，同时，通过RPC请求写入到M1和M2服务器中的第二存储引擎（Map DB），并删除M1和M2服务器上第一存储引擎（Map DB）的列族0、1、2相对应的流水日志。由于这里主机与备机是以线程为粒度的，因此以服务器的粒度来看，同一个服务器集群中的服务器互为主备。还需说明的是，对于服务器的其他逻辑组件：防重入组件（Anti-Reentry）、第一同步组件（Bin Log Sync）、第二同步组件（In-Set Sync）均以服务器为粒度的，是多个线程共享的。

示例性的，日志处理组件（Log ETL）包括多个线程，多个线程中包括主线程，由日志处理组件（Log ETL）的主线程执行对流水日志的聚合与转换。在另一些实施例中，当服务器为服务器集群中的一个服务器，还将日志处理组件（Log ETL）的这条主线程所在的服务器称为主机，其他服务器称为备机。继续参考图9，步骤4422具体包括步骤4422A和步骤4422B。

步骤4422A，通过日志处理组件的主线程，基于流水日志的日志属性执行排列组合，得到流水日志对应的关键字。

步骤4422B，基于关键字读取到待更新指标，对待更新指标执行加N操作以更新待更新指标，得到第一类型的指标，N大于0。

示例性的，服务器通过日志处理组件的主线程，基于流水日志的日志属性执行排列组合，得到流水日志对应的关键字；基于关键字读取到待更新指标，对待更新指标执行加N操作以更新待更新指标，得到第一类型的指标，N大于0。在一些实施例中，在至少一个存储引擎为一个存储引擎时，在基于关键字读取到待更新指标时，从该存储引擎获取待更新指标即可。在至少一个存储引擎为多个存储引擎时，按照多个存储引擎对应的预设查询顺序，或多个存储引擎对应的预设优先级查询到待更新指标。

例如，日志处理组件的主线程基于流水日志的日志属性执行排列组合，生成不同时间粒度的指标对应的关键字（Key），接下来，依次从第二存储引擎（Map DB）、第三存储引擎（Read Cache）、后端存储引擎中读取到待更新指标，对待更新指标执行+N得到新指标，即第一类型的指标，返回新指标。后续，日志处理组件还可以将该新指标写入第二存储引擎。

本实施例中，通过将日志处理组件拆分为多个线程，通过主线程对流水日志执行聚合与转换，一是能够基于这些流水日志得到不同时间粒度的指标，避免多个线程重复扫描流水日志，二是能够将服务器的选主逻辑从服务器这一机器级别下移到线程级别，使得每一个服务器集群（Set）中的服务器互为主备，降低了单个主机的CPU消耗。需要说明的是，选主是复杂分布式服务的一个特有机制，旨在保障系统数据的一致性。其中，分布式服务一般对于数据的存储形式是：每个节点（也即服务器）都保存全量的数据，使得每个节点都可以对外提供“一致”的服务，这就涉及到不同节点间的数据同步，选主则是保证服务内数据变更触发、控制及变更后服务各节点数据的一致性的重要环节。

在一些实施例中，不同时间粒度的指标是指第一类型的指标，第一类型的指标也可以理解为：近期被更新的指标。在已经基于流水日志更新指标之后，还可以将这些第一类型的指标更新写入第二存储引擎，以缓存这些第一类型的指标。则步骤460具体实现为步骤462。

步骤462，基于日志处理组件将第一类型的指标更新写入服务器的第二存储引擎。

日志处理组件还用于将这些第一类型的指标更新写入服务器的第二存储引擎中。示例性的，服务器基于日志处理组件将第一类型的指标更新写入服务器的第二存储引擎。其中，更新写入也可以理解为覆盖写入。

本实施例中，通过基于日志处理组件将第一类型的指标更新写入服务器的第二存储引擎，能够将新指标缓存至第二存储引擎，以便于指标的查询。

在一些实施例中，服务器包括第一同步组件（Bin Log Sync）。在步骤460之后或与步骤460同时，该方法还可选包括步骤470。

步骤470，基于第一同步组件将第一类型的指标同步至后端存储引擎。

第一同步组件（Bin Log Sync）用于同步各种不同时间粒度的指标以及更新过的指标至后端存储引擎（TTL KV），后端存储引擎用于缓存所有的指标，包括更新过与未更新过的指标。示例性的，服务器还基于第一同步组件将第一类型的指标同步至后端存储引擎。需要说明的是，后端存储引擎可以位于当前服务器中，还可以位于其他服务器中，还可以是专门用于提供可靠性存储服务的存储引擎，本实施例对此不做限制。

本实施例中，通过基于第一同步组件将第一类型的指标同步至后端存储引擎，能够确保指标的可靠性存储，有效避免指标丢失。

在一些实施例中，在已经基于流水日志更新指标之后，还可以将这些已经经过聚合与转换的流水日志删除。则在步骤460和/或步骤470之后，或与步骤460和/或步骤470同时，该方法还可选包括步骤480。

步骤480，基于日志处理组件删除第一存储引擎中的已处理的流水日志。

日志处理组件还能够直接删除第一存储引擎中的已处理的流水日志。示例性的，服务器还基于日志处理组件删除第一存储引擎中的已处理的流水日志。

本实施例中，通过基于日志处理组件删除第一存储引擎中的已处理的流水日志，能够及时将第一存储引擎中的已处理（或已聚合）的流水日志删除，以免占用第一存储引擎的存储空间，方便后续继续存储新的流水日志。

在一些实施例中，服务器包括第二同步组件（In-Set Sync）。可选地，本实施例还设置了服务器集群（Set），一个服务器集群中包括多个服务器。对于一个服务器集群，其包含的每一个服务器持有的数据分片是相同的，不同服务器集群之间的数据分片不重叠。本实施例还将主机更新的指标写入备机，主机与备机可以同时提供查询服务。前述实施例的步骤均由服务器执行，该服务器可以是服务器集群中的一个服务器，也称为主机，其他服务器称为备机。服务器集群中的每个服务器分别包括至少一个存储引擎，每个服务器用于同步接收客户端上报的流水日志，以及，将流水日志缓存至至少一个存储引擎中的第一存储引擎。

示例性的，在主机已经基于流水日志更新指标之后，除了删除主机中的这些已经聚合与转换的流水日志之外，还可以将备机中的这些已经经过聚合与转换的流水日志删除，以免占用备机的第一存储引擎的存储空间。则在步骤460和/或步骤470之后，或与步骤460和/或步骤470同时，该方法还可选包括步骤520。

步骤520，基于日志处理组件向第二同步组件发送第一通知消息；其中，第一通知消息用于指示第二同步组件，删除服务器集群中的其他服务器的第一存储引擎中的已处理的流水日志。

日志处理组件还用于通知第二同步组件删除备机中已处理的流水日志，第二同步组件用于直接删除备机中已处理的流水日志。示例性的，服务器基于日志处理组件向第二同步组件发送第一通知消息，第一通知消息用于指示第二同步组件，删除服务器集群中的其他服务器的第一存储引擎中的已处理的流水日志。

本实施例中，由于主机与备机是同步接收客户端上报的流水日志，则基于日志处理组件可以向第二同步组件发送第一通知消息，用于指示第二同步组件，删除服务器集群中的其他服务器的第一存储引擎中的已处理的流水日志，能够及时将主机和备机的第一存储引擎中的已处理（或已聚合）的流水日志删除，以免占用备机第一存储引擎的存储空间，方便备机后续继续存储新的流水日志。

在一些实施例中，在主机已经基于流水日志更新指标之后，还可以将这些第一类型的指标更新写入备机的第二存储引擎，以在备机中也缓存这些第一类型的指标。则在步骤460和/或步骤470和/或步骤480之后，或与步骤460和/或步骤470和/或步骤480同时，该方法还可选包括步骤540。

步骤540，基于日志处理组件向第二同步组件发送第二通知信息；其中，第二通知信息用于指示第二同步组件，将第一类型的指标同步至服务器集群中的其他服务器的至少一个存储引擎中的第二存储引擎。

日志处理组件还用于通知第二同步组件将第一类型的指标同步到备机，第二同步组件用于将第二同步组件同步到备机的第二存储引擎。示例性的，服务器基于日志处理组件向第二同步组件发送第二通知信息，第二通知信息用于指示第二同步组件，将第一类型的指标同步至服务器集群中的其他服务器的至少一个存储引擎中的第二存储引擎。

本实施例中，通过基于日志处理组件向第二同步组件发送第二通知信息，用于指示第二同步组件，将第一类型的指标同步至服务器集群中的其他服务器的至少一个存储引擎中的第二存储引擎，能够将这些指标也同步到备机中。当一台主机的重启过程中，或主机产生异常时，主机中的针对指标的统计任务还可以在备机中继续执行，并且，备机与主机中的指标能够保持一致性，从而保证了指标的读写性能和最终一致性。

接下来，结合图示对本申请实施例提供的指标的统计及查询方法进行说明。

整体架构。

图10是本申请一个示例性实施例提供的指标的统计方法的示意图，主要涉及客户端10和服务器20（也称为主机20），还涉及后端存储引擎24，其中，后端存储引擎24可以位于服务器20，也可以位于其他服务器，还可以是专门用于提供可靠性存储服务的存储引擎，本实施例对此不做限制。

客户端10包括共享内存11，客户端10涉及一个逻辑组件，包括共享内存聚合组件（Share Memory Aggregation）（图10未示出），用于实现客户端10的基于共享内存11的流水日志攒批与合并逻辑。

服务器20包括共享内存（图10未示出），服务器20包括3个存储引擎和4个逻辑组件。3个存储引擎包括第一存储引擎（Log DB）21、第二存储引擎（Map DB）22、第三存储引擎（Read Cache）23。4个逻辑组件包括日志处理组件（Log ETL）25、第一同步组件（Bin LogSync）28、第二同步组件（In-Set Sync）27、防重入组件（Anti-Reentry）29。在另一些实施例中，服务器20的上述3个存储引擎和4个逻辑组件还可以组合称为在线计数统计系统。

第一存储引擎21用于缓存客户端10近期上报的流水日志。第二存储引擎22用于在共享内存中写时缓存近期被更新的指标。第三存储引擎23用于在共享内存中读时缓存近期未更新但被查询到的指标。

防重入组件（Anti-Reentry）29用于生成流水日志对应的日志标识（Uuid），通过判断流水日志的日志标识是否已经存在于对应的指标包含的日志标识序列集合中，来过滤客户端10重复上报的流水日志，避免重复计数。其中，日志标识序列集合一般保存最近10分钟内的最多5000条日志标识。

日志处理组件25用于从第一存储引擎21批量读取近期的流水日志（Recent LogExtract）与共享内存中的原有的指标（待更新指标）执行聚合与转换（Aggregate&Transformer），以更新待更新指标得到新的指标，以及，将新的指标更新写入至第二存储引擎22，也即局部加载（Locally Load）至第二存储引擎22。第一同步组件（Bin Log Sync）28用于将近期被更新的指标同步到后端存储引擎24。同一个服务器集群（Set）中的服务器互为主备，当主机的流水日志经过聚合与转换得到指标之后，第二同步组件（In-Set Sync）27用于删除服务器集群中的相关流水日志，以及，将被更新的指标同步到服务器所在的服务器集群中的其他服务器30（也称为备机30）。

聚合和主备同步的整体流程。

参考图11，客户端10将流水日志同步上报（Report）至主机20的第一存储引擎21和备机30的第一存储引擎31；对于主机20，日志处理组件25定期批量扫描流水日志，以及，从第二存储引擎22查询到需要更新的待更新指标，日志处理组件25基于从第一存储引擎21中批量扫描的流水日志与待更新指标执行聚合与转换，以更新待更新指标得到新的指标，以及，通知第二同步组件27将这些新的指标同步到备机30中的第二存储引擎32。日志处理组件25删除第一存储引擎21中的已处理的流水日志，以及，通知第二同步组件27删除备机30中的第一存储引擎31中的相应的流水日志。同时，第一同步组件28（图11未示出）还将这些新的指标同步到后端存储引擎24。

指标查询的整体流程。

结合参考图7和图10，客户端10向服务器20发送查询（Query）请求，查询请求用于指示查询目标指标，服务器20接收查询请求，基于查询请求对应的关键字，先从第二存储引擎22中查询目标指标，当未查询到时，表示该目标指标近期未被更新，接下来，从第三存储引擎23中查询目标指标，当未查询到时，穿透到后端存储引擎24，从后端存储引擎24拉取目标指标并缓存至第三存储引擎23，获取到目标指标并方便于下次查询。

应用场景。

本申请实施例的方法能够应用于短视频、游戏直播、产品推荐、内容推荐等离线或在线指标的统计与查询场景中，实现快速准确的统计各种不同时间粒度的指标，提供实时高性能的指标的查询能力，从而提升推荐准确性和实时性。

在一种可能实现方式中，本实施例以应用场景是短视频场景，指标为独立访客数为例，用户可以通过短视频客户端刷到不同内容的短视频，以及，实时显示刷到该短视频的人数。示例性的，当用户刷到某一个短视频内容时，客户端向服务器上报流水日志；可选地，流水日志包括内容标识、用户账号标识、场景值、时间戳、行为类型中的至少一种详情信息，场景值可以是短视频，时间戳可以为某日某时某分某秒，行为类型可以是滑动或点击；服务器接收流水日志，对流水日志执行聚合与转化，生成在某分钟、某小时、某天的关键字（Key）对应的独立访客数加1的操作，得到分钟级、小时级、天级的独立访客数；将前述独立访客数写时缓存至服务器的至少一个存储引擎中。

当需要查询目标时间段的目标时间粒度的独立访客数时，客户端向服务器发送查询请求，例如，查询请求用于指示查询某月某日的天级的独立访客数，查询请求还包括内容标识、用户账号标识、场景值和行为类型中的至少一种详情信息；服务器接收查询请求，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的分钟级、小时级、天级的独立访客数中，获取某月某日的天级的独立访客数，向客户端返回某月某日的天级的独立访客数。客户端可以将某月某日的天级的独立访客数对外显示为刷到该短视频的人数，还可以在后续向该用户账号推荐其他短视频。

在另一种可能实现方式中，本实施例以应用场景是直播场景，指标为独立访客数为例，用户可以通过直播客户端进入不同的直播间，以观看不同的直播，例如，游戏直播、购物直播、公益直播，以及，实时显示该直播间的观看人数。

示例性的，当用户进入到某一直播间时，客户端向服务器上报流水日志；可选地，流水日志包括直播间标识、用户账号标识、场景值、时间戳、行为类型中的至少一种详情信息，场景值可以是直播，时间戳可以为某日某时某分某秒，行为类型可以是点击；服务器接收流水日志，对流水日志执行聚合与转化，生成在某分钟、某小时、某天的关键字（Key）对应的独立访客数加1的操作，得到分钟级、小时级、天级的独立访客数；将前述独立访客数写时缓存至服务器的至少一个存储引擎中。

当需要查询目标时间段的目标时间粒度的独立访客数时，客户端向服务器发送查询请求，例如，查询请求用于指示查询某月某日的分钟级的独立访客数，查询请求还包括直播间标识、用户账号标识、场景值和行为类型中的至少一种详情信息；服务器接收查询请求，从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的分钟级、小时级、天级的独立访客数中，获取某月某日的分钟级的独立访客数，向客户端返回某月某日的分钟级的独立访客数。客户端可以将某月某日的分钟级的独立访客数对外显示为该直播间的观看人数，还可以在后续向该用户账号推荐其他直播间。

有益效果。

本申请实施例的有益效果至少包括以下几个方面。

1、热点关键字（Key）的流水日志上报优化：对于单热点关键字的流水日志并发上报场景，比如：热点视频、超级直播间等场景中，针对单个热点关键字的流水日志瞬时上报量非常高。一般情况下这种单热点关键字的流水日志最后都会落在同一个服务器，由单机的事务保证一致性。由于单机性能一般受限于服务器的CPU，磁盘输入/输出（Input/Output，I/O），网络I/O等资源，难以线性扩容，但是，上报的客户端可能来自很多的上游机器。对此，本实施例在客户端的共享内存上进行非常短时间（比如500毫秒ms）的攒批，可以把对服务器的单个请求写入单条流水日志转化成单个请求批量写入流水日志，减少传输开销。而且，对于同一个热点关键字的流水日志写入，在客户端执行简单合并，可以把100条指标加1的流水日志，转成1条指标加100的流水日志，从而减少写入的流水日志数量，减轻服务器聚合和转换的压力。同时，在服务器中使用C++编写的嵌入式KV存储引擎（RocksDB）开发实现第一存储引擎（Log DB），在服务器中增加异步写入队列，把对RocksDB一个一个的事务型写入改成一批一批的事务型写入，减少RocksDB的写入毛刺，进一步提升写性能。

2、流水日志生效时延优化：为了降低流水日志生效时延，由于流水日志的聚合是由日志处理组件（Log ETL）完成，因此可以将日志处理组件（Log ETL）拆分成多个线程。但是，如果每个线程都去扫描同一个第一存储引擎（Log DB），就会产生大量无效的重复扫描，因此将第一存储引擎（Log DB）中的数据按照哈希（Hash）拆分成多个列族（Column Family，CF），每个列族是独立的存储空间，事务的读写也是独立的，避免产生日志处理组件（LogETL）的多个线程扫描重复流水日志的问题。本实施例还进一步优化了主备逻辑，把服务器的选主逻辑从机器级别下移到线程级别，使得每一个服务器集群（Set）中的服务器互为主备，降低了单个主机的CPU消耗。

3、查询耗时优化：为了满足在线推荐计算业务的实时性，提升推荐效果，并基于通常情况下，近期被更新的指标一般在短时间内更容易被查询到的假设，将聚合与转换得到的不同时间粒度的指标缓存在第二存储引擎（Map DB）作为写时缓存，而且将第二存储引擎（Map DB）缓存的这些指标放在共享内存，查询指标时先从第二存储引擎（Map DB）中查询，能够实现指标的快速查询，而且由于共享内存读取相比磁盘读取耗时更低，因此能够减少指标的查询耗时。出于对存储和性能的考虑，还使用后端存储引擎作为可靠性存储，使用第一同步组件（Bin Log Sync）定期将第二存储引擎（Map DB）的数据写入后端存储引擎。当查询请求读取冷数据时可能会穿透到后端存储引擎，为了保证对冷数据下次查询的响应速度更快，将穿透至后端存储引擎读取到的指标缓存在第三存储引擎（Read Cache）作为读时缓存，能够方便针对这些指标的下次查询。因此，第二存储引擎（Map DB）的写时缓存和第三存储引擎（Read Cache）的读时缓存保证了单机查询的低耗时和高可用性。

经过性能优化后，单个服务器的流水日志上报吞吐可达300w/min，平均日志长度200Bytes。受益于客户端的攒批合并，在单热点关键字的情况下，单热点关键字的流水日志上报量可达1.3kw/min。另外，流水日志生效延迟缩短至秒级，甚至在一些追求实时性的配置条件下，可以达到毫秒级别。以及，通过设计读时缓存和写时缓存，使得指标查询缓存命中率达97.75%，批量读取200个指标仅需3ms，减少了查询耗时，提高了查询速度。

图12是本申请一个示例性实施例提供的指标的查询装置800的框图。示例性的，指标的查询装置800包括接收模块810、查询模块820和返回模块830中的至少部分模块。

接收模块810，用于接收客户端的查询请求，所述查询请求用于指示查询目标时间段的目标时间粒度的目标指标；

查询模块820，用于从所述服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存，所述指标是对所述客户端上报的流水日志执行聚合与转换得到的；

返回模块830，用于向所述客户端返回所述查询请求对应的所述目标指标。

在一些实施例中，查询模块820，用于：

基于所述查询请求对应的关键字，从所述服务器的所述至少一个存储引擎在所述共享内存中写时缓存或读时缓存的所述不同时间粒度的所述指标中，获取所述查询请求对应的所述目标指标；

其中，所述至少一个存储引擎用于以键值对形式缓存不同所述关键字对应的所述不同时间粒度的所述指标，所述关键字与所述指标一一对应。

在一些实施例中，所述至少一个存储引擎包括第一存储引擎和第二存储引擎，所述第一存储引擎用于缓存所述流水日志，所述第二存储引擎用于在所述共享内存中写时缓存第一类型的指标，所述第一类型的指标是基于所述流水日志对不同时间粒度的待更新指标执行更新后得到的指标；

所述服务器包括日志处理组件，所述日志处理组件用于基于所述流水日志与所述待更新指标执行聚合与转换，以更新所述待更新指标，得到所述第一类型的指标，以及，将所述第一类型的指标更新写入所述第二存储引擎；

在一些实施例中，查询模块820，用于：

基于所述查询请求对应的所述关键字，从所述第二存储引擎在所述共享内存中写时缓存的所述第一类型的指标中，获取所述查询请求对应的所述目标指标。

在一些实施例中，所述至少一个存储引擎还包括第三存储引擎，所述第三存储引擎用于读时缓存第二类型的指标，所述第二类型的指标是从后端存储引擎中读取的不同时间粒度的未更新、且被本次的所述查询请求或被上次的查询请求查询的指标，所述后端存储引擎用于缓存所有的指标；

在一些实施例中，查询模块820，还用于：

在未从所述第二存储引擎查询到所述查询请求对应的所述目标指标时，基于所述查询请求对应的所述关键字，从所述第三存储引擎在所述共享内存中读时缓存的所述第二类型的指标中，获取所述查询请求对应的所述目标指标。

图13是本申请一个示例性实施例提供的指标的统计装置900的框图。示例性的，指标的统计装置900包括接收模块910、处理模块920和缓存模块930中的至少部分模块。

接收模块910，用于接收客户端上报的流水日志；

处理模块920，用于对所述流水日志执行聚合与转换，得到不同时间粒度的指标；

缓存模块930，用于将所述不同时间粒度的所述指标缓存至所述服务器的至少一个存储引擎，所述至少一个存储引擎用于在共享内存中写时缓存或读时缓存所述不同时间粒度的所述指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存。

在一些实施例中，所述服务器包括日志处理组件；

在一些实施例中，处理模块920，用于：

基于所述日志处理组件对所述流水日志执行聚合与转换，得到所述不同时间粒度的所述指标。

在一些实施例中，所述不同时间粒度的指标为第一类型的指标，所述至少一个存储引擎包括第一存储引擎和第二存储引擎，所述第一存储引擎用于缓存所述流水日志，所述第二存储引擎用于在所述共享内存中写时缓存所述第一类型的指标，所述第一类型的指标是基于所述流水日志对不同时间粒度的待更新指标执行更新后得到的指标；

在一些实施例中，处理模块920，用于：

基于所述日志处理组件从所述第一存储引擎中批量读取所述流水日志，从所述第二存储引擎查询所述不同时间粒度的待更新指标；

基于所述流水日志与所述待更新指标执行聚合与转换，以更新所述待更新指标，得到所述第一类型的指标。

在一些实施例中，所述日志处理组件包括多个线程，所述多个线程中包括主线程；

在一些实施例中，处理模块920，用于：

通过所述日志处理组件的所述主线程，基于所述流水日志的日志属性执行排列组合，得到所述流水日志对应的关键字；

基于所述关键字读取到所述待更新指标，对所述待更新指标执行加N操作以更新所述待更新指标，得到所述第一类型的指标，N大于0。

在一些实施例中，缓存模块930，用于：

基于所述日志处理组件将所述第一类型的指标更新写入所述服务器的所述第二存储引擎。

在一些实施例中，所述服务器包括第一同步组件；

在一些实施例中，所述装置还包括同步模块，同步模块，用于：

基于所述第一同步组件将所述第一类型的指标同步至所述后端存储引擎。

在一些实施例中，处理模块，还用于：

基于所述日志处理组件删除所述第一存储引擎中的已处理的流水日志。

在一些实施例中，所述服务器包括第二同步组件，所述服务器是服务器集群中的一个服务器，所述服务器集群中的每个服务器分别包括所述至少一个存储引擎，所述每个服务器用于同步接收所述客户端上报的所述流水日志，以及，将所述流水日志缓存至所述至少一个存储引擎中的所述第一存储引擎；

在一些实施例中，同步模块，用于：

基于所述日志处理组件向所述第二同步组件发送第一通知消息；

其中，所述第一通知消息用于指示所述第二同步组件，删除所述服务器集群中的其他服务器的所述第一存储引擎中的已处理的流水日志。

在一些实施例中，同步模块，用于：

基于所述日志处理组件向所述第二同步组件发送第二通知信息；

其中，所述第二通知信息用于指示所述第二同步组件，将所述第一类型的指标同步至所述服务器集群中的其他服务器的所述至少一个存储引擎中的所述第二存储引擎。

需要说明的是，上述实施例提供的一个或多个指标的查询装置800、指标的统计装置900的实施例中的具体限定可以参见上文中对于指标的查询方法、指标的统计方法的限定，在此不再赘述。上述实施例的装置的各模块可全部或部分通过软件、硬件及其组合来实现，各模块可以以硬件形式内嵌或独立于计算机设备的处理器中，也可以以软件形式存储在计算机设备的存储器中，以便于处理器调用执行各模块对应的操作。

本申请实施例还提供了一种计算机设备，该计算机设备包括：处理器和存储器，存储器中存储有计算机程序；处理器，用于执行存储器中的计算机程序以实现上述各方法实施例提供的指标的查询方法和/或指标的统计方法。

示例地，计算机设备可以是服务器。图14是本申请一个示例性实施例提供的服务器1000的结构框图。

通常，服务器1000包括有：处理器1001和存储器1002。

处理器1001可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1001可以采用数字信号处理（Digital Signal Processing，DSP）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）、可编程逻辑阵列（Programmable Logic Array，PLA）中的至少一种硬件形式来实现。处理器1001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器（CentralProcessing Unit，CPU）；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1001可以在集成有图像处理器（Graphics Processing Unit，GPU），GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1001还可以包括人工智能（Artificial Intelligence，AI）处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1002中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1001所执行以实现本申请中方法实施例提供的指标的查询方法和/或指标的统计方法。

在一些实施例中，服务器1000还可选包括有：输入接口1003和输出接口1004。处理器1001、存储器1002和输入接口1003、输出接口1004之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与输入接口1003、输出接口1004相连。输入接口1003、输出接口1004可被用于将输入/输出（Input/Output，I/O）相关的至少一个外围设备连接到处理器1001和存储器1002。在一些实施例中，处理器1001、存储器1002和输入接口1003、输出接口1004被集成在同一芯片或电路板上；在一些其他实施例中，处理器1001、存储器1002和输入接口1003、输出接口1004中的任意一个或两个可以在单独的芯片或电路板上实现，本申请实施例对此不加以限定。

本领域技术人员可以理解，图14中示出的结构并不构成对服务器1000的限定，可以包括比图示更多或更少的组件，或组合某些组件，或采用不同的组件布置。

在示例性实施例中，本申请提供了一种芯片，所述芯片包括可编程逻辑电路和/或程序指令，当芯片在计算机设备上运行时，用于实现上述方法实施例提供的指标的查询方法和/或指标的统计方法。

本申请提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序由处理器加载并执行以实现上述方法实施例提供的指标的查询方法和/或指标的统计方法。

本申请提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取所述计算机指令，处理器执行所述计算机指令，使得所述计算机设备的处理器加载并执行以实现上述方法实施例提供的指标的查询方法和/或指标的统计方法。

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的计算机可读存储介质可以是只读存储器，磁盘或光盘等。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (17)

1.一种指标的查询方法，其特征在于，所述方法由服务器执行，包括：

接收客户端的查询请求，所述查询请求用于指示查询目标时间段的目标时间粒度的目标指标；

从所述服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存，所述指标是对所述客户端上报的流水日志执行聚合与转换得到的；

向所述客户端返回所述查询请求对应的所述目标指标。

2.根据权利要求1所述的方法，其特征在于，所述从所述服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，包括：

基于所述查询请求对应的关键字，从所述服务器的所述至少一个存储引擎在所述共享内存中写时缓存或读时缓存的所述不同时间粒度的所述指标中，获取所述查询请求对应的所述目标指标；

其中，所述至少一个存储引擎用于以键值对形式缓存不同所述关键字对应的所述不同时间粒度的所述指标，所述关键字与所述指标一一对应。

3.根据权利要求2所述的方法，其特征在于，所述至少一个存储引擎包括第一存储引擎和第二存储引擎，所述第一存储引擎用于缓存所述流水日志，所述第二存储引擎用于在所述共享内存中写时缓存第一类型的指标，所述第一类型的指标是基于所述流水日志对不同时间粒度的待更新指标执行更新后得到的指标；

所述服务器包括日志处理组件，所述日志处理组件用于基于所述流水日志与所述待更新指标执行聚合与转换，以更新所述待更新指标，得到所述第一类型的指标，以及，将所述第一类型的指标更新写入所述第二存储引擎；

所述基于所述查询请求对应的关键字，从所述服务器的所述至少一个存储引擎在所述共享内存中写时缓存或读时缓存的所述不同时间粒度的所述指标中，获取所述查询请求对应的所述目标指标，包括：

基于所述查询请求对应的所述关键字，从所述第二存储引擎在所述共享内存中写时缓存的所述第一类型的指标中，获取所述查询请求对应的所述目标指标。

4.根据权利要求3所述的方法，其特征在于，所述至少一个存储引擎还包括第三存储引擎，所述第三存储引擎用于读时缓存第二类型的指标，所述第二类型的指标是从后端存储引擎中读取的不同时间粒度的未更新、且被本次的所述查询请求或被上次的查询请求查询的指标，所述后端存储引擎用于缓存所有的指标；

所述基于所述查询请求对应的关键字，从所述服务器的所述至少一个存储引擎在所述共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，还包括：

在未从所述第二存储引擎查询到所述查询请求对应的所述目标指标时，基于所述查询请求对应的所述关键字，从所述第三存储引擎在所述共享内存中读时缓存的所述第二类型的指标中，获取所述查询请求对应的所述目标指标。

5.一种指标的统计方法，其特征在于，所述方法由服务器执行，包括：

接收客户端上报的流水日志；

对所述流水日志执行聚合与转换，得到不同时间粒度的指标；

将所述不同时间粒度的所述指标缓存至所述服务器的至少一个存储引擎，所述至少一个存储引擎用于在共享内存中写时缓存或读时缓存所述不同时间粒度的所述指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存。

6.根据权利要求5所述的方法，其特征在于，所述服务器包括日志处理组件；

所述对所述流水日志执行聚合与转换，得到不同时间粒度的指标，包括：

基于所述日志处理组件对所述流水日志执行聚合与转换，得到所述不同时间粒度的所述指标。

7.根据权利要求6所述的方法，其特征在于，所述不同时间粒度的指标为第一类型的指标，所述至少一个存储引擎包括第一存储引擎和第二存储引擎，所述第一存储引擎用于缓存所述流水日志，所述第二存储引擎用于在所述共享内存中写时缓存所述第一类型的指标，所述第一类型的指标是基于所述流水日志对不同时间粒度的待更新指标执行更新后得到的指标；

所述基于所述日志处理组件对所述流水日志执行聚合与转换，得到所述不同时间粒度的所述指标，包括：

基于所述日志处理组件从所述第一存储引擎中批量读取所述流水日志，从所述第二存储引擎查询所述不同时间粒度的待更新指标；

基于所述流水日志与所述待更新指标执行聚合与转换，以更新所述待更新指标，得到所述第一类型的指标。

8.根据权利要求7所述的方法，其特征在于，所述日志处理组件包括多个线程，所述多个线程中包括主线程；

所述基于所述流水日志与所述待更新指标执行聚合与转换，以更新所述待更新指标，得到所述第一类型的指标，包括：

通过所述日志处理组件的所述主线程，基于所述流水日志的日志属性执行排列组合，得到所述流水日志对应的关键字；

基于所述关键字读取到所述待更新指标，对所述待更新指标执行加N操作以更新所述待更新指标，得到所述第一类型的指标，N大于0。

9.根据权利要求7所述的方法，其特征在于，所述将所述不同时间粒度的所述指标缓存至所述服务器的至少一个存储引擎，包括：

基于所述日志处理组件将所述第一类型的指标更新写入所述服务器的所述第二存储引擎。

10.根据权利要求9所述的方法，其特征在于，所述服务器包括第一同步组件，所述方法还包括：

基于所述第一同步组件将所述第一类型的指标同步至后端存储引擎。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

基于所述日志处理组件删除所述第一存储引擎中的已处理的流水日志。

12.根据权利要求7至11任一所述的方法，其特征在于，所述服务器包括第二同步组件，所述服务器是服务器集群中的一个服务器，所述服务器集群中的每个服务器分别包括所述至少一个存储引擎，所述每个服务器用于同步接收所述客户端上报的所述流水日志，以及，将所述流水日志缓存至所述至少一个存储引擎中的所述第一存储引擎；

所述方法还包括：

基于所述日志处理组件向所述第二同步组件发送第一通知消息；

其中，所述第一通知消息用于指示所述第二同步组件，删除所述服务器集群中的其他服务器的所述第一存储引擎中的已处理的流水日志。

13.根据权利要求12所述的方法，其特征在于，所述方法还包括：

基于所述日志处理组件向所述第二同步组件发送第二通知信息；

其中，所述第二通知信息用于指示所述第二同步组件，将所述第一类型的指标同步至所述服务器集群中的其他服务器的所述至少一个存储引擎中的所述第二存储引擎。

14.一种指标的查询装置，其特征在于，所述装置包括：

接收模块，用于接收客户端的查询请求，所述查询请求用于指示查询目标时间段的目标时间粒度的目标指标；

查询模块，用于从服务器的至少一个存储引擎在共享内存中写时缓存或读时缓存的不同时间粒度的指标中，获取所述查询请求对应的所述目标指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存，所述指标是对所述客户端上报的流水日志执行聚合与转换得到的；

返回模块，用于向所述客户端返回所述查询请求对应的所述目标指标。

15.一种指标的统计装置，其特征在于，所述装置包括：

接收模块，用于接收客户端上报的流水日志；

处理模块，用于对所述流水日志执行聚合与转换，得到不同时间粒度的指标；

缓存模块，用于将所述不同时间粒度的所述指标缓存至服务器的至少一个存储引擎，所述至少一个存储引擎用于在共享内存中写时缓存或读时缓存所述不同时间粒度的所述指标，所述写时缓存是指将所述指标写入所述至少一个存储引擎时缓存，所述读时缓存是指读取所述指标时在所述至少一个存储引擎中缓存。

16.一种计算机设备，其特征在于，所述计算机设备包括：处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如权利要求1至4任一所述的指标的查询方法或如权利要求5至13任一所述的指标的统计方法。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序由处理器加载并执行以实现如权利要求1至4任一所述的指标的查询方法或如权利要求5至13任一所述的指标的统计方法。