CN113515545A - 数据查询方法、装置、系统、电子设备以及存储介质 - Google Patents

Abstract

本公开公开了数据查询方法、装置、系统、电子设备以及存储介质，涉及数据处理领域，尤其涉及数据查询领域。具体实现方案为：边缘节点接收访问端发送的针对时序数据的查询请求；从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，内容分发网络系统的源站节点中采用时序数据库存储时序数据；基于目标时序数据，向访问端反馈查询请求对应的查询结果。通过本公开的方案，实现针对时序数据的高效地查询。

Description

数据查询方法、装置、系统、电子设备以及存储介质

技术领域

本公开涉及数据处理技术领域，尤其涉及数据查询领域，具体涉及数据查询方法、装置、系统、电子设备以及存储介质。

背景技术

针对文档分享平台等能够产生海量时序数据的业务方而言，现有技术中利用关系型数据库对产生的时序数据进行存储，但利用关系型数据库存储时序数据存在存储成本较高，查询效率较低，且每次一个新的图表都需要额外开发的缺点。因此，相对于关系型数据库而言，时序数据库无疑是更好的选择。

发明内容

本公开提供了一种用于利用时序数据库，实现针对时序数据的高效地查询的数据查询方法、装置、系统、电子设备以及存储介质。

根据本公开的一方面，提供了一种数据查询方法，应用于边缘节点，所述方法包括：

接收访问端发送的针对时序数据的查询请求；

从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；其中，所述内容分发网络系统的源站节点中采用时序数据库存储时序数据；

基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果。

根据本公开的另一方面，提供了一种数据查询装置，应用于边缘节点，所述装置包括：

请求接收模块，用于接收访问端发送的针对时序数据的查询请求；

数据请求模块，用于从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；其中，所述内容分发网络系统的源站节点中采用时序数据库存储时序数据；

结果反馈模块，用于基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果。

根据本公开的另一方面，提供了一种数据查询系统，包括：边缘节点、内容分发网络系统和所述内容分发网络系统的源站节点；其中，所述源站节点中采用时序数据库存储时序数据；

所述边缘节点，用于接收访问端发送的针对时序数据的查询请求；从所述内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果；

所述内容分发网络系统，用于在所述边缘节点请求与所述查询请求相匹配的目标时序数据时，向所述边缘节点反馈所述目标时序数据。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开提供的任一种数据查询方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行本公开提供的任一种数据查询方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本公开提供的任一种数据查询方法。

本公开提供的上述方案，边缘节点接收访问端针对时序数据的查询请求，并从内容分发网络CDN系统中获取目标时序数据从而响应访问端发送的查询请求，其中，CDN系统的源站节点中采用时序数据库存储时序数据。由于对于CDN系统而言，只有在CDN系统内不包含访问端所需获取的数据时，才需要向源站节点进行回源，这样可以避免每次均使用时序数据库进行查询请求的响应。可见，本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开提供的数据查询方法的流程图；

图2是根据本公开提供的数据查询方法的另一流程图；

图3是根据本公开提供的数据查询方法的另一流程图

图4是根据本公开提供的数据查询方法的另一流程图；

图5是根据本公开实施例提供的鉴权逻辑的示意图；

图6是根据本公开提供的数据查询方法的另一流程图；

图7是根据本公开提供的数据查询方法的另一流程图；

图8是根据本公开实施例提供的存储的原理图；

图9是根据本公开实施例提供的RANGE-BLOCK分层缓存策略的示意图；

图10是根据本公开提供的数据查询系统的结构示意图；

图11是根据本公开提供的数据查询装置的结构示意图；

图12是用来实现本公开实施例的提供的数据查询方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了方便理解方案，首先对时序数据进行如下说明：

时序数据是按照时间顺序记录的系统、设备等的状态变化的数据，并且，时序数据是以时间进行查询维度，其中，时序数据通常包含时间维度、属性维度和属性值维度等信息。为了更好理解时序数据，以文档分享平台为例进行说明：针对文档分享平台而言，文档被生产、浏览、下载和购买各个过程均可以产出时序数据。例如：以文档购买为例，时序数据可以包含购买时间、购买文档和购买量等信息，如{2021年1月1日17时，文档1，购买1份}；以文档浏览为例，时序数据可以包括浏览时间段、浏览内容和浏览量等信息，如{2021年1月1日，文档1，浏览1次}。

相关技术中，针对文档分享平台(如文库知识店铺)等能够产生海量时序数据的业务方而言，将时序数据存入关系型数据库，并通过业务接口，利用SQL(Structured QueryLanguage，结构化查询语言)查询的方式进行数据查询，其中，由于通过时序数据能够生成图表，例如：折线图、柱状图等，因此，时序数据也可以称为图表类型数据。示例性的：以时效要求不高的业务场景为例，简述相关技术中数据统计、数据存储和数据查询的过程：

数据统计：采用离线统计的方式统计每天产出的时序数据。

数据存储：直接将时序数据写入关系型数据库进行存储。

数据查询：通过业务接口触发sql查询对应的关系型数据库进行统计，再将查询结果进行整理返回给用户。

上述相关技术所提供的方案，至少存在如下问题：

存储和入库成本高：时序数据的查询，通常需要统计多个时间维度，数据量级非常大，关系型数据库没有这类数据的存储优化，会有较高的存储成本；时序数据需要每天入库亿级数据，关系型数据库在写的性能上并不能满足要求。

查询慢甚至影响集群服务：时序数据的查询可能会有较大的时间跨度(比如1年)，一次查询涉及几万到几千万条数据的召回和聚合计算，会导致关系型数据库慢查询甚至影响数据库集群性能进而导致雪崩。

实时性差和可扩展性差：数据统计时一般采用离线任务统计的方式。当数据量较大时会无法实时产出数据，又因为存储结构的关系，不能实现任意时间粒度的聚合查询(比如想按天和月维度统计)。

相对于关系型数据库上述所具有的缺点而言，时序数据库无疑是更好的选择。其中，时序数据库，即时间序列数据库(Time Series Database，简称TSDB)，主要用于存储带时间标签(按照时间的顺序变化，即时间序列化)的数据，能够提供高效读写、高压缩比低成本存储、降精度、插值、多维聚合计算和查询结果可视化功能，解决由于设备采集点数据量巨大、数据采集频率高而造成的存储成本高、写入和查询分析效率低的问题。

但是，在文档分享等高流量的场景下，每次直接使用时序数据库进行查询请求的响应并不高效。因此，如何利用时序数据库，实现针对时序数据的高效地查询是亟需解决的技术问题。

为了利用时序数据库，实现针对时序数据的高效地查询的数据查询，本公开实施例提供了数据查询方法、装置、系统、电子设备以及存储介质。

下面首先对本公开实施例所提供的一种数据查询方法进行介绍。

本公共实施例提供的数据查询方法应用于边缘节点，其中，边缘节点指靠近用户的网络边缘侧的网络设备，也就是说，边缘节点是访问端在请求数据时所需访问的节点，该访问端为用户所使用的客户端，例如：网页客户端、App(application，应用程序)、小程序等。在具体应用中，本公开实施例所提及的边缘节点可以为各类电子设备，例如，个人电脑、服务器、以及其他具有数据处理能力的设备。另外，可以理解的是，本公开实施例提供的数据查询方法可以通过软件、硬件或软硬件结合的方式实现。

需要说明的是，为了实现基于时序数据库的高效查询，本公开提供的方案中，边缘节点可以结合CDN(内容分发网络，Content Delivery Network)系统，来对访问端进行请求响应，其中，CDN系统的源站节点中采用时序数据库存储时序数据。这样，通过边缘节点、CDN系统和时序数据库相结合的方式，来实现针对时序数据的数据查询过程。

示例性，在一种实现方式中，边缘节点可以为CDN内的节点，此时，该边缘节点也可以命名为CDN边缘节点，也就是，边缘节点为CDN服务提供的节点。该种实现方式中，边缘节点可以从CDN系统的其他节点中请求数据，若其他节点中不存在所需数据，则进行数据回源。

在另一种实现方式中，边缘节点可以为独立于CDN系统的节点，也就是，边缘节点为用于提供边缘服务的节点，边缘节点位于访问端和CDN系统之间。该种实现方式中，边缘节点可以从CDN系统中处于边缘的节点中请求数据，若请求不到所需数据，则进行数据回源。

可以理解的是，无论边缘节点属于CDN系统，还是独立于CDN系统，边缘节点的数量可以为多个，每个边缘节点所执行的数据查询过程均相同。并且，在具体应用时，每个访问端可以访问物理距离最近的边缘节点，以保证查询速率。

其中，本公开实施例所提供的一种数据查询方法，应用于边缘节点，可以包括如下步骤：

接收访问端发送的针对时序数据的查询请求；

从内容分发网络CDN系统中，请求与查询请求相匹配的目标时序数据；其中，CDN系统的源站节点中采用时序数据库存储时序数据；

基于目标时序数据，向访问端反馈查询请求对应的查询结果。

本公开提供的上述方案，边缘节点接收访问端针对时序数据的查询请求，并从内容分发网络CDN系统中获取目标时序数据从而响应访问端发送的查询请求，其中，CDN系统的源站节点中采用时序数据库存储时序数据。由于对于CDN系统而言，只有在CDN系统内不包含访问端所需获取的数据时，才需要向源站节点进行回源，这样可以避免每次均使用时序数据库进行查询请求的响应。可见，本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。

另外，本公开所提供方案中，访问端通过访问边缘节点来获取所需的时序数据，使得访问端对应的业务服务器无需参与每次的查询过程。可见，由于不需要业务服务器参与针对数据查询的计算和处理，能够达到系统隔离和节约业务资源的效果。其中，业务服务器为上述的访问端所对应的服务器。

并且，相对于相关技术中每次都需要重新查询和计算而浪费机器资源，通过本方案，考虑到时序数据具有冷数据的特点，结合CDN系统进行数据查询，无需每次都通过访问时序数据库来进行查询和计算，因此，可以避免资源浪费。另外，针对允许不同查询粒度或表现形式的需求场景，相关技术中均需要对应不同的关系型数据库，这样导致开发成本过高；而本方案，仅仅通过对边缘节点节点进行配置允许的查询粒度，结合时序数据库所提供的聚合能力，即可满足不同的需求场景，避免了开发成本过高。

下面结合附图对本公开实施例所提供的一种数据查询方法进行介绍。

如图1所示，本公开实施例提供所一种数据查询方法，应用于边缘节点，可以包括如下步骤：

S101，接收访问端发送的针对时序数据的查询请求。

由于边缘节点是接近用户的设备，因此，当访问端需要查询存储于源站节点的时序数据库中的时序数据时，可以向边缘节点发送针对时序数据的查询请求，从而使得边缘节点依赖CDN系统来进行请求响应。其中，用户可以通过访问端提供的查询界面来指示访问端发出查询请求。

针对时序数据的查询请求中可以携带所需查询时序数据的筛选信息，其中，筛选信息可以为时间信息，如查询2021年1月1日至2021年1月5日的时序数据，则2021年1月1日至2021年1月5日为查询请求中所携带的时间信息。当然，该查询请求中还可以携带有访问端的用户标识，以及，需要查询的时序数据的类型信息和所属用户等等，其中，需要查询的时序数据的类型信息根据不同的应用场景不同，示例性的，在文档点击率统计场景下，需要查询的时序数据的类型信息可以为文档的点击率；而在文档上传场景下，需要查询的时序数据的类型信息可以是文档上传量，等等。

其中，查询请求中的时序数据的粒度可以是预设的允许查询的时间粒度；并且允许查询的时间粒度可以是业务方通过配置界面所配置，示例性的，允许查询的时间粒度可以为月、天、小时等等。

S102，从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，从内容分发网络系统的源站节点中采用时序数据库存储时序数据。

在本公开实施例中，文档分享平台等业务方产生的时序数据存储在源站节点的时序数据库中，也就是说，源站节点通过时序数据库存储业务方产生的时序数据。对于CDN系统而言，CDN系统包含各级节点存储有从源站节点中获取的部分数据；而源站节点中存储有完整的时序数据。

那么，当边缘节点从CDN系统中，请求与查询请求相匹配的目标时序数据时，若CDN系统的各级节点中存储有目标时序数据，则边缘节点可以直接从存储有目标时序数据的节点中获取目标时序数据的；而若CDN系统的各级节点中未存储目标时序数据，则CDN系统中的节点可以进行回源，从源站节点中获取目标时序数据，并将获取的目标时序数据反馈至边缘节点，同时该节点还可以存储所获取的目标时序数据，这样当后续边缘节点再次请求该目标时序数据时，不再需要再一次进行回源，即可直接将已存储的目标时序数据反馈至边缘节点，从而减小了从时序数据库中获取时序数据的次数。

示例性的，在一种实现方式中，与查询请求相匹配的目标时序数据可以为：与查询请求中所携带的时间信息相同的时序数据，也就是，边缘节点从CDN系统中请求属于查询请求中时间信息的时序数据，作为目标时序数据。并且，可以理解的是，时序数据库中存储的时序数据，属于访问端待访问的某一时间段的时序数据的数据源，也就是说，待访问的某一时间段的时序数据，属于时序数据库所存储的时序数据中的内容；并且，不但时间范围上相匹配，目标时序数据与查询请求所请求时序数据，还在类型信息和所属用户等方面相匹配。

需要说明的是，任何一种通过时序数据库对时序数据进行存储的方式均可以适用于本公开，为了方案清楚及布局清晰，后续示例性介绍源站节点采用时序数据库存储时序数据的实现方式。

S103，基于目标时序数据，向访问端反馈查询请求对应的查询结果。

其中，边缘节点在获取到查询请求所针对的目标时序数据时，即可基于目标时序数据，生成查询请求对应的查询结果，进而向访问端反馈查询请求对应的查询结果。示例性的，若与查询请求相匹配的目标时序数据可以为：与查询请求中所携带的时间信息相同的时序数据，则边缘节点可以直接将目标时序数据作为查询请求的查询结果，反馈给访问端。可以理解的是，访问端在接收到查询请求对应的查询结果后，可以对查询结果进行展示。示例性的，访问端以图表的形式，对查询结果进行展示，图表的类型可以包括折线图、柱状图、饼图等。本公开不对访问端展示查询结果的具体形式进行限定。

本公开提供的上述方案，由于对于CDN系统而言，只有在CDN系统内不包含访问端所需获取的数据时，才需要向源站节点进行回源，这样可以避免每次均使用时序数据库进行查询请求的响应。可见，本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。

另外，本公开所提供方案中，访问端通过访问边缘节点来获取所需的时序数据，使得访问端对应的业务服务器无需参与进入每次的查询过程，这样，由于不需要业务服务器参与针对数据查询的计算和处理，能够达到系统隔离和节约业务资源的效果。其中，业务服务器为上述的访问端所对应的服务器。

如图2所示，本公开的另一实施例所提供的数据查询方法，可以包括步骤S201-S204：

S201，接收访问端发送的针对时序数据的查询请求；

其中，本步骤与S101相同，在此不再赘述。

S202，确定包含有指定时间信息的目标时间段；其中，指定时间信息为查询请求中所给定的时间信息，目标时间段的时间粒度大于指定时间信息的时间粒度；

S203，从内容分发网络系统中，请求目标时间段内的数据块，作为目标时序数据；

考虑到访问端对于时序数据的访问的时间跨度非常零散，导致在CDN系统中会存在碎片化缓存，而碎片化缓存对于查询请求的命中率较低，导致碎片化缓存的问题。因此，本实施例中，采用range-block策略，其中，range可以理解为时间粒度和范围，block可以理解为对应的数据块，比如用户需要查询2021.1.1-2021.1.18天级别的时序数据，在这个场景下CDN系统中可以提供月级别的block，即2021.1月的时序数据的数据块，这样边缘节点只需要从CDN系统拉取2021年1月的数据块，而访问端前端展示1.1-1.18的时序数据即可；而当后续用户需要查询2021.1.11-2021.1.20天级别的时序数据时，边缘节点可以直接获取CDN系统中所存储的2021.1月的数据块，使得命中率得到大大提升。

可见，通过range-block策略可以使得CDN系统存储的数据块对应多个可查询的时间跨度，从而减少缓存碎片化，提升缓存命中率。

基于上述的range-block策略，边缘节点在接收到查询请求后，可以不从CDN系统中获取指定时间信息的时序数据，而是，确定包含有指定时间信息的目标时间段，进而利用该目标时间段来向CDN系统请求时序数据。

其中，该目标时间段包括指定时间信息，且目标时间段的时间粒度大于指定时间信息的时间粒度。可以理解的是，时间粒度为对时间进行划分的基本单位，如年、月、天、时等，根据需求的不同可以划分不同大小的时间粒度。其中，任一时间段的时间粒度可以为该时间段所涉及的最小时间粒度，例如：针对2021.1.1-2021.1.18而言，该时间段的时间粒度可以为天，而针对2021.01-2021.02而言，该时间段的时间粒度可以为月。而目标时间段的时间粒度大于指定时间信息的时间粒度，具体指：若指定时间信息的时间粒度为小时，则目标时间段的时间粒度可以为小时以上的时间粒度，例如：天、月、年等；若指定时间信息的时间粒度为天，则目标时间段的时间粒度可以为天以上的时间粒度，例如：月、年等，以此类推。为了更好的理解目标时间段和指定时间信息的关系，下面结合示例进行说明：假如指定时间信息为2021.1.1-2021.1.18，由于目标时间段需要包括指定时间信息且目标时间段的时间粒度大于指定时间信息的时间粒度，那么，目标时间段可以为2021.01，或者，2021，等等，这都是合理的；又如：假如指定时间信息为2021.1.1-2021.2.18，由于目标时间段需要包括指定时间信息且目标时间段的时间粒度大于指定时间信息的时间粒度，那么，目标时间段可以为2021.1-2021.02，或者，2021。

在保证解决碎片化所带来的命中率低的前提下，为了进一步降低存储空间的占用，可选地，在一种实现方式中，目标时间段为各指定时间段中包含有指定时间信息的最短时间段；其中，各指定时间段属于指定时间信息的时间粒度的上一时间粒度。

可以理解的是，对于时间粒度年、月、天、时而言，年是月的上一时间粒度，月是天的上一时间粒度，天是时的上一时间粒度。那么，若指定时间信息的时间粒度为天，则指定时间信息的时间粒度的上一时间粒度为月，若指定时间信息的时间粒度为月，则指定时间信息的时间粒度的上一时间粒度为年，以此类推。为了更好的理解目标时间段为指定时间信息的关系，下面结合示例进行说明：例如，若指定时间信息为2021.1.1-2021.1.18，则指定时间信息的时间粒度为天，上一时间粒度为月，相应的，目标时间段为各指定时间段中包含有指定时间信息的最短时间段，因此，目标时间段为2021.01；若指定时间信息为2021.1.1-2021.2.18，则指定时间信息的时间粒度为天，上一时间粒度为月，相应的，目标时间段为各指定时间段中包含有指定时间信息的最短时间段，因此，目标时间段为2021.01-2021.02；若指定时间信息为2021.1-2021.2，则指定时间信息的时间粒度为月，上一时间粒度为年，相应的，目标时间段为各指定时间段中包含有指定时间信息的最短时间段，因此，则目标时间段可以为2021。

另外，在确定出目标时间段后，边缘节点可以从CDN系统中，请求目标时间段内的数据块，作为目标时序数据。示例性的，边缘节点可以向CDN系统内的节点发送携带目标时间段的数据获取请求，若该节点存储有目标时间段内的数据块，则可以直接向边缘节点反馈目标时间段内的数据块，若该节点未存储目标时间段内的数据块，则该节点可以进行回源，以从源站节点中获取目标时间段内的数据块，进而向边缘节点反馈目标时间段内的数据块，同时该节点可以存储所获取的目标时间段内的数据块。

可见，通过range-block策略，可以使得后续不仅在请求该指定时间信息指示时间段内的时序数据时，边缘节点可以直接从CDN系统中获取，还可以使得在请求目标时间段内的任一时间跨度的时序数据时，均可以直接从CDN系统中获取数据块。从而提高CDN系统的缓存命中率低，并减轻CDN系统内各级节点的碎片化情况。

S204，从目标时序数据中，选取符合指定时间信息的时序数据，并将所选取的时序数据反馈给访问端。

由于目标时间段所涵盖的时间范围大于等于指定时间信息所指示的时间段，因此，在获取到目标时序数据后，可以从目标时序数据中，选取符合指定时间信息的时序数据，并将所选取的时序数据反馈给访问端。示例性的，指定时间信息为2021.1.1-2021.1.18，目标时间段为2021.01，则目标时序数据为2021.01内的时序数据，因此，边缘节点从目标时序数据中选取2021.1.1-2021.1.18内的时序数据，作为查询结果，反馈给访问端。

本实施例所提供方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询；并且，通过采用range-block策略，可以使得CDN系统中的一数据块对应多个可查询的时间跨度，从而减少缓存碎片化，提升缓存命中率。

如图3所示，本公开的另一实施例所提供的数据查询方法，可以包括步骤S301-S304：

S301，接收访问端发送的针对时序数据的查询请求。

其中，本步骤与S101相同，在此不再赘述。

S302，从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，从内容分发网络系统的源站节点中采用时序数据库存储时序数据。

其中，本步骤与S102相同，在此不再赘述。

S303，基于目标时序数据，向访问端反馈查询请求对应的查询结果。

其中，本步骤与S103相同，在此不再赘述。

S304，向从内容分发网络系统发送缓存数据管理指令，以使CDN系统在接收到缓存数据管理指令后，确定用于管理缓存数据的时间滑动窗口的窗口范围，将本地缓存的早于窗口范围的时序数据进行持久化存储，以及将本地缓存的位于窗口范围内时序数据，在满足预定缓存清除条件时进行清除。

对于时序数据而言，CDN系统内缓存的一些时序数据始终不会过期，即不会发生更改，而另一些时序数据则会在一段时间后过期，即会发生更改，因此，可以采用保障冷热数据的分层缓存，具体而言，对于不会过期的时序数据，可以对其进行持久化存储，而对于在一段时间后过期的时序数据，则可以对其进行清除，以节约CDN系统的缓存空间。例如：若当前时间是2021.01.28，访问端请求2021.1.1-2021.1.18，目标时间段为2021.01，则CDN系统内缓存有2021.01这个时间跨度的时序数据，由于源站节点中会增加2021.01.29-2021.01.31的时序数据，那么，可以认为CDN系统内的2021.01这个时间跨度的时序数据会过期，需要被定时清除；类似的，若当前时间是2021.01.28，访问端请求2020.12.1-2020.12.18，目标时间段为2020.12，则CDN系统内缓存有2020.12这个时间跨度的时序数据，由于源站节点中不会增加2020.12这个时间跨度的时序数据，因此，可以认为CDN系统内的2020.12这个时间跨度的时序数据不会过期，可以进行持久化存储。

其中，用于管理缓存数据的时间滑动窗口的窗口范围可以是携带于缓存数据管理指令中的信息，也可以是CDN系统中预先存储的信息，这都是合理的。并且，针对CDN系统本地缓存的任一时序数据，可以将该时序数据所涉及的时间范围与时间滑动窗口的窗口范围进行比较，从而确定出该时序数据是位于时间滑动窗口的窗口范围内，还是早于该时间滑动窗口的窗口范围。示例性的，时间滑动窗口的窗口范围可以包括当前时间，且时间跨度的粒度可以与时序数据库中时序数据的存储粒度相同，例如：时序数据库中的时序数据的存储粒度是天，时间跨度的粒度可以天；并且，可以理解的是，在时间跨度确定后，由于时间滑动窗口处于滑动状态，那么，时间滑动窗口的窗口范围是持续发生变化的。例如：时间跨度设置为两天，那么，若当前时间是2021.01.21，则时间滑动窗口的窗口范围可以为2021.01.20-2021.01.21，而若当前时间为2021.01.22，时间滑动窗口的窗口范围是2021.01.21-2021.01.22。

另外，预定缓存清除条件可以为用于清除一段时间后过期的时序数据的条件，可以结合实际的使用场景和经验进行设定。例如，缓存清除条件可以为：缓存时长超过预定时长阈值。

本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。同时，通过时间滑动窗口，可以清除CDN系统内本地存储的可能过期的时序数据，可以进一步的节约CDN系统的缓存空间，并提高CDN系统的响应速度。

如图4所示，本公开的另一实施例所提供的数据查询方法，可以包括步骤S401-S404：

S401，接收访问端发送的针对时序数据的查询请求。

其中，本步骤与S101相同，在此不再赘述。

S402，基于访问端的令牌token，对访问端进行鉴权，并在鉴权通过之后，执行从内容分发网络系统中，请求与查询请求相匹配的目标时序数据的步骤。

为了提高数据的安全性，可以基于访问端的令牌token，对访问端进行鉴权。若访问端通过鉴，则执行从内容分发网络CDN系统中，请求与查询请求相匹配的目标时序数据的步骤；否则，边缘节点可以忽略访问端的查询请求，并向访问端反馈用于提醒访问失败的信息。其中，令牌token为访问端所属业务服务器为访问端所分配的，该令牌token中可以携带的信息用于表征该访问端的用户的访问权限，示例性的，该令牌token包括但不局限于：访问端可访问的用户账户，访问端可访问的时序数据库的标识信息、访问端可访问的时序数据的粒度，等等，本公开对此不做限定。并且，示例性的，查询请求中可以携带有访问端的令牌token，或者，查询请求和token作为两种独立信息分别发送给边缘节点，这都是合理的。

为了更好的理解方案，结合图5示例性地介绍下鉴权流程。如图5所示，在某一应用场景下，访问端在向边缘节点访问数据之前，可以向业务方服务器发送token获取请求，并且，在整个页面生命周期内只需获取一次令牌token；相应的，业务方服务器接收到访问端发送的token获取请求后，可以对用户进行身份合法性判定，在判定合法后，基于预先记录的该访问端的访问权限相关信息，生成该访问端的令牌token，并下发给该访问端；访问端在向边缘节点访问数据时，可以向边缘节点发送token以及查询请求，这样，边缘节点可以基于访问端的token对于访问端进行鉴权，即判断访问端是否具有访问所需时序数据的权限，并鉴权通过后，从CDN系统中拉取访问端所请求的时序数据(即指定block数据)；进而，CDN系统可以从一级缓存或二级缓存中获取相应的时序数据，若获取不到在进行回源，其中，一级缓存中的数据是CDN系统中缓存的数据，二级缓存中的数据是CDN系统中持久化存储的数据。

S403，从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，从内容分发网络系统的源站节点中采用时序数据库存储时序数据。

其中，本步骤与S102相同，在此不再赘述。

S404，基于目标时序数据，向访问端反馈查询请求对应的查询结果。

其中，本步骤与S103相同，在此不再赘述。

本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。进一步的，通过对访问端进行鉴权，可以提高时序数据的安全性，并且，避免业务方实现频繁鉴权便可以保证数据安全性。

如图6所示，本公开的另一实施例所提供的数据查询方法，可以包括步骤S601-604：

S601，接收访问端发送的针对时序数据的查询请求。

其中，本步骤与S101相同，在此不再赘述。

S602，检测查询请求所请求数据的时间粒度是否属于访问端对应的可查询粒度；

其中，不同的访问端可以具有不同的可查询粒度。例如，访问端1的可访问粒度为天，即只能访问某一天的时效数据，而不能访问某一月或某一年的时效数据。其中，访问端对应的可查询粒度为：访问端所属业务方通过配置界面所配置的允许查询的时间粒度。

因此，在接收到访问端的查询请求后，可以检测查询请求所请求数据的时间粒度是否属于访问端对应的可查询粒度。其中，访问端对应的可查询粒度为：访问端所属业务方通过配置界面所配置的允许查询的时间粒度。若查询请求所请求数据的时间粒度属于访问端对应的可查询粒度，则执行S603。若查询请求所请求数据的时间粒度不属于访问端对应的可查询粒度，则边缘节点忽略访问端的查询请求，并向访问端反馈用于提醒访问失败的信息。

S603，从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，从内容分发网络系统的源站节点中采用时序数据库存储时序数据。

其中，本步骤与S102相同，在此不再赘述。

S604，基于目标时序数据，向访问端反馈查询请求对应的查询结果。

其中，本步骤与S103相同，在此不再赘述。

本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。进一步的，通过配置访问端的允许查询的时间粒度，可以使业务方灵活地对访问端进行管理。

如图7所示，本发明的另一实施例所提供的数据查询方法，可以包括步骤S701-S704：

S701，接收访问端发送的针对时序数据的查询请求。

其中，本步骤与S101相同，在此不再赘述。

S702，检测查询请求的查询语句结构是否符合指定语句结构；

其中，指定语句结构为：访问端所属业务方通过配置界面所配置的查询语句的语句结构。

查询语句的不同语句结构可以用于查询不同的时序数据，因此，在接收到访问端的查询请求后，可以检测查询请求的查询语句结构是否符合指定语句结构。若检测查询请求的查询语句结构符合指定语句结构，则执行S703。若检测查询请求的查询语句结构不符合指定语句结构，则边缘节点忽略访问端的查询请求，并向访问端反馈提醒信息。

S703，从内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，从内容分发网络系统的源站节点中采用时序数据库存储时序数据。

其中，本步骤与S102相同，在此不再赘述。

S704，基于目标时序数据，向访问端反馈查询请求对应的查询结果。

其中，本步骤与S103相同，在此不再赘述。

本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。进一步的，通过配置访问端的指定语句结构，可以使业务方灵活地对访问端进行管理。

本公开所提供方案，可以抽象出针对业务方的接入层，这样，业务方的开发者仅仅需要针对不同的业务场景或需求，配置出个性化查询语句和访问端对应的可查询粒度，即可快速接入边缘节点，无需额外开发，让业务需求快速上线；并且，提供了自定义的处理层，能够快速提供边缘计算能力扩展。

可选地，在一实施例中，源站节点采用时序数据库存储时序数据的方式包括：

按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中；其中，各个数据类别为基于数据生成场景所划分的类别。

其中，在一种实现方式中，各个数据类别包括：流式数据类别和非流式数据类别，非流式数据类别包括时效数据类别和非时效数据类别。其中，流式数据类别的时序数据为流数据。流数据是一组顺序、大量、快速、连续到达的数据序列，一般情况下，数据流可被视为一个随时间延续而无限增长的动态数据集合。时效数据类别的时序数据为具有时效性的时序数据。相应的，非时效数据类别的时序数据为对时效没有要求的时序数据。

由于不同数据类型的时序数据具有不同的写入需求，因此，可以按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中。可选的，在一种实现方式中，可以包括如下三种方式：

第一方式：通过在线写入方式，将属于时效数据类别的第一类时序数据写入到时序数据库中。其中，在线写入方式包括：实时获取第一类时序数据，并将所获取到的第一类时序数据实时写入到时序数据库中。

示例性的，第一类时序数据可以为时效要求较高的订单数据，在产生订单数据后，可以通过业务方提供的访问接口，获取订单数据，并存储到时序数据库中，订单数据可以存储于消息队列中，从而，可以从消息队列中获取订单数据并进行存储。通过在时序数据库中存储第一类时序数据，后续在进行数据查询时，可以根据查询需求，时序数据库对第一类时序数据进行聚合，从而形成符合查询需求的数据。

第二方式：通过近线写入方式，将属于流式数据类别的第二类时序数据写入到时序数据库中。

其中，近线写入方式包括：实时获取第二类时序数据，将所获取到的第二类时序数据按照第一初始时间粒度进行聚合后，将聚合后数据写入到时序数据库中。

其中，流式数据为流式场景下所产生的时序数据。示例性的：对于某个页面的各种访问行为(点赞、浏览等)，属于流式计算的场景；针对流式数据而言，为了方便存储，在将第二类数据写入时序数据库之前，可以先对第二时序类数据按照第一初始时间粒度进行聚合，然后，将聚合后的数据写入到时序数据库中，例如：对于浏览行为，先按照分钟，对浏览行为数据进行聚合。在时序数据库中存储第二类时序数据，后续在进行数据查询时，可以根据查询需求，时序数据库对第二类时序数据进行再次聚合，从而形成符合查询需求的数据。其中，第一初始时间粒度可以根据实际情况进行设定。

第三方式：通过离线写入方式，将属于非时效数据类别的第三类数据写入到时序数据库中。

其中，离线写入方式包括：周期性获取第三类时序数据，将获取到的第三类时序数据按照第二初始时间粒度进行聚合后，将聚合后数据写入到时序数据库中。

示例性的，第三类数据可以为天级统计任务所产生的时序数据，此时，可以周期性获取数据，将获取到的第三类时序数据按照第二初始时间粒度进行聚合后，将聚合后数据写入到时序数据库中。通过在时序数据库中存储第三类时序数据，后续在进行数据查询时，可以根据查询需求，时序数据库对第三类时序数据进行再次聚合，从而形成符合查询需求的数据。其中，第二初始时间粒度可以根据实际情况进行设定。

通过上述的存储方式，可以使得存储根据数据实际的特性，选取在线、近线或离线方式进行存储，保证存储的快捷以及有效性，支持每秒千万级的高写能力。如图8所示的原理图，数据入库过程中，通过在线、近线、离线方式来将业务方产生的时序数据写入到TSDB中，即时序数据库中；进而，结合边缘计算、CDN缓存，以及轻业务/鉴权,和range-block策略，来实现数据查询过程，进而实现访问端的图表展示。其中，轻业务是业务利用本公开所提供的方案即可实现的业务效果，即业务方仅仅通过执行简单的配置信息，即可实现存储和查询。

为了更好的理解本公开所提供的方案，如图9以文库知识店铺x_privateflow这个场景为例，介绍下本公开所提供的方案：

为了方便理解，先对TSDB中所涉及的概念进行如下介绍:

metric:度量，相当于关系型数据库中的table。

timestamp：时间戳，代表数据点产生的时间。

field:度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。

tag:标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。

针对知识店铺，TSDB中存储有该知识店铺的metric:shop_privateflow，即包含时序数据的数据表；fields包括：pv(Page View的缩写，即含有广告展示位的页面被用户打开的次数)，click，rate(点击率)，tag为xid。

在数据查询过程中，若CDN系统中不存在访问端所请求的目标时序数据，则可以进行数据回源，此时，TSDB可以对知识店铺的时序数据采用聚合计算策略进行聚合，从而得到边缘节点所需的目标时序数据，其中，聚合计算策略为TSDB所提供的策略，图9中的，point、time_bucket/sum、max_by，均是TSDB所提供的聚合策略的策略方式；并且，CDN系统中按照时间滑动窗口对于缓存的时序数据进行持久化存储，即永久缓存，或者，在满足过期条件时，进行缓存清除，该图9中，window为时间滑动窗口，该时间滑动窗口的时间跨度为两天，该时间滑动窗口的窗口范围是持续变化的，在时间滑动窗口的窗口范围之前的时序数据为可以持久化存储的数据，即图9中的通过c所标识的数据，而窗口范围内和晚于窗口范围的数据为可以被缓存的数据。

在数据查询过程中，边缘节点可以根据查询请求的指定时间信息，基于上述的rang-block策略，从CDN系统中获取待请求的数据块(即目标时序数据)：持久化存储的c_block或缓存的e_block，进而，从目标时序数据中选取访问端所需时间范围的数据，反馈给访问端。

基于上述的方案描述，采用本公开所提供的方案，具体如下优势：

一、性能上提升：

因为查询转移到边缘节点，迁移后时序数据获取速度从200ms降低至30ms，用户体验有所提升；

查询速率大大提升。例如：店铺目前付费类报表，因为查询转移至边缘节点，计算周期由相关技术中的1小时可以变更为实时，解决漏数据和计算的问题。

采用上述的在线、近线和离线方式将时序数据写入时序数据库，能够提供每秒千万级写入能力和存储能力，海量的分析数据入库已不存在问题。

由于时序数据库提供多种聚合计算函数，能够支持不同时间粒度的聚合计算，相对之前的离线计算提供了多样性的扩展能力。

二、解决了以下系统性风险:

相关技术中，查询大量连续时间点数据存在慢查询的风险，影响线上稳定性。

查询请求通过边缘计算和CDN，不经过业务集群，和业务方隔离风险，互不影响。

三、成本降低:

之前开发的人力成本大概在6人日左右，采用本方案提供的基于时序数据库的数据存储和查询技术的支撑，人力可以预期降低至0.25-1.5人日左右。

相对业界单纯使用时序数据库的解决方案，结合CDN和边缘计算以及range-block策略，能够随着查询流量的提升，大幅度节省成本，目前店铺按平均1个用户3次重复查询算，至少节约68％的成本。

相应于上述的方法实施例，如图10，本公开还提供了一种数据查询系统，包括：边缘节点1001、内容分发网络CDN系统1002和CDN系统1002的源站节点1003；其中，源站节点1003中采用时序数据库存储时序数据；

边缘节点1001，用于接收访问端发送的针对时序数据的查询请求；从CDN系统1002中，请求与查询请求相匹配的目标时序数据；基于目标时序数据，向访问端反馈查询请求对应的查询结果；

CDN系统1002，用于在边缘节点请求与查询请求相匹配的目标时序数据时，向边缘节点反馈目标时序数据。

其中，关于边缘节点和CDN系统的功能的详细介绍，可以参见上述方法实施例的相应内容，在此不做赘述。

根据本公开的实施例，如图11所示，本公开还提供了一种数据查询装置，应用于边缘节点，装置包括：

请求接收模块1101，用于接收访问端发送的针对时序数据的查询请求；

数据请求模块1102，用于从内容分发网络内容分发网络系统中，请求与查询请求相匹配的目标时序数据；其中，内容分发网络系统的源站节点中采用时序数据库存储时序数据；

结果反馈模块1103，用于基于目标时序数据，向访问端反馈查询请求对应的查询结果。

可选的，数据请求模块，具体用于确定包含有指定时间信息的目标时间段；其中，指定时间信息为查询请求中所给定的时间信息，目标时间段的时间粒度大于指定时间信息的时间粒度；从内容分发网络系统中，请求目标时间段内的数据块，作为目标时序数据；

结果反馈模块，具体用于从目标时序数据中，选取符合指定时间信息的时序数据，并将所选取的时序数据反馈给访问端。

可选的，目标时间段为各指定时间段中包含有指定时间信息的最短时间段；其中，各指定时间段属于指定时间信息的时间粒度的上一时间粒度。

可选的，装置还包括：

指令发送模块，用于向内容分发网络系统发送缓存数据管理指令，以使内容分发网络系统在接收到缓存数据管理指令后，确定用于管理缓存数据的时间滑动窗口的窗口范围，将本地缓存的早于窗口范围的时序数据进行持久化存储，以及将本地缓存的位于窗口范围内时序数据，在满足预定缓存清除条件时进行清除。

可选地，源站节点采用时序数据库存储时序数据的方式包括：

按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中；其中，各个数据类别为基于数据生成场景所划分的类别。

可选地，各个数据类别包括：流式数据类别和非流式数据类别，非流式数据类别包括时效数据类别和非时效数据类别；

按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中，包括：

通过在线写入方式，将属于时效数据类别的第一类时序数据写入到时序数据库中；通过近线写入方式，将属于流式数据类别的第二类时序数据写入到时序数据库中；通过离线写入方式，将属于非时效数据类别的第三类数据写入到时序数据库中；

其中，在线写入方式包括：实时获取第一类时序数据，并将所获取到的第一类时序数据实时写入到时序数据库中；

近线写入方式包括：实时获取第二类时序数据，将所获取到的第二类时序数据按照第一初始时间粒度进行聚合后，将聚合后数据写入到时序数据库中；

离线写入方式包括：周期性获取第三类时序数据，将获取到的第三类时序数据按照第二初始时间粒度进行聚合后，将聚合后数据写入到时序数据库中。

可选地，装置还包括：

第一处理模块，用于在请求接收模块接收访问端发送的针对时序数据的查询请求之后，且数据请求模块在从内容分发网络系统中，请求与查询请求相匹配的目标时序数据之前，检测查询请求所请求数据的时间粒度是否属于访问端对应的可查询粒度，若属于，则触发数据请求模块；

其中，访问端对应的可查询粒度为：访问端所属业务方通过配置界面所配置的允许查询的时间粒度。

可选地，装置还可以包括：

第二处理模块，用于在请求接收模块接收访问端发送的针对时序数据的查询请求之后，且数据请求模块从内容分发网络系统中，请求与查询请求相匹配的目标时序数据之前，检测查询请求的查询语句结构是否符合指定语句结构，若符合，则触发数据请求模块；

其中，指定语句结构为：访问端所属业务方通过配置界面所配置的查询语句的语句结构。

可选地，装置还可以包括：

第三处理模块，用于在请求接收模块接收访问端发送的针对时序数据的查询请求之后，且数据请求模块从内容分发网络系统中，请求与查询请求相匹配的目标时序数据之前，基于访问端的令牌token，对访问端进行鉴权，并在鉴权通过之后，触发数据请求模块；

其中，令牌token为访问端所属业务服务器为访问端所分配的。

本公开实施例提供的上述方案，由于对于CDN系统而言，只有在CDN系统内不包含访问端所需获取的数据时，才需要向源站节点进行回源，这样可以避免每次均使用时序数据库进行查询请求的响应。可见，本方案通过边缘节点、CDN系统和时序数据库相结合的方式，可以利用时序数据库，实现针对时序数据的高效地查询。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

本公开一实施例所提供的一种电子设备，包括：

至少一个处理器；以及

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述的数据查询方法。

本公开一实施例提供的一种存储有计算机指令的非瞬时计算机可读存储介质，计算机指令用于使计算机执行上述的数据查询方法。

本公开一实施例所提供的一种计算机程序产品，包括计算机程序，计算机程序在被处理器执行时实现上述的数据查询方法。

图12示出了可以用来实施本公开的实施例的示例电子设备1200的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(ROM)1202中的计算机程序或者从存储单元1208加载到随机访问存储器(RAM)1203中的计算机程序，来执行各种适当的动作和处理。在RAM 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

设备1200中的多个部件连接至I/O接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元1208，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如数据查询方法。例如，在一些实施例中，数据查询方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1208。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1202和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到RAM 1203并由计算单元1201执行时，可以执行上文描述的方法X数据查询一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据查询方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (20)

1.一种数据查询方法，应用于边缘节点，所述方法包括：

接收访问端发送的针对时序数据的查询请求；

从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；其中，所述内容分发网络系统的源站节点中采用时序数据库存储时序数据；

基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果。

2.根据权利要求1所述的方法，其中，所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据，包括：

确定包含有指定时间信息的目标时间段；其中，所述指定时间信息为所述查询请求中所给定的时间信息，所述目标时间的时间粒度大于所述指定时间信息的时间粒度；

从内容分发网络系统中，请求所述目标时间段内的数据块，作为目标时序数据；

所述基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果，包括：

从所述目标时序数据中，选取符合所述指定时间信息的时序数据，并将所选取的时序数据反馈给所述访问端。

3.根据权利要求2所述的方法，其中，所述目标时间段为各指定时间段中包含有所述指定时间信息的最短时间段；

其中，各指定时间段属于所述指定时间信息的时间粒度的上一时间粒度。

4.根据权利要求1-3任一项所述的方法，其中，所述方法还包括：

向所述内容分发网络系统发送缓存数据管理指令，以使所述内容分发网络系统在接收到所述缓存数据管理指令后，确定用于管理缓存数据的时间滑动窗口的窗口范围，将本地缓存的早于所述窗口范围的时序数据进行持久化存储，以及将本地缓存的位于所述窗口范围内时序数据，在满足预定缓存清除条件时进行清除。

5.根据权利要求1-3任一项所述的方法，其中，所述源站节点采用时序数据库存储时序数据的方式包括：

按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中；其中，各个数据类别为基于数据生成场景所划分的类别。

6.根据权利要求4所述的方法，其中，所述各个数据类别包括：流式数据类别和非流式数据类别，所述非流式数据类别包括时效数据类别和非时效数据类别；

所述按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中，包括：

通过在线写入方式，将属于时效数据类别的第一类时序数据写入到时序数据库中；

通过近线写入方式，将属于流式数据类别的第二类时序数据写入到时序数据库中；

通过离线写入方式，将属于非时效数据类别的第三类数据写入到时序数据库中。

7.根据权利要求6所述的方法，其中，

所述在线写入方式包括：实时获取第一类时序数据，并将所获取到的第一类时序数据实时写入到时序数据库中；

所述近线写入方式包括：实时获取第二类时序数据，将所获取到的第二类时序数据按照第一初始时间粒度进行聚合后，将聚合后数据写入到所述时序数据库中；

所述离线写入方式包括：周期性获取第三类时序数据，将获取到的第三类时序数据按照第二初始时间粒度进行聚合后，将聚合后数据写入到所述时序数据库中。

8.根据权利要求1-3任一项所述的方法，其中，在所述接收访问端发送的针对时序数据的查询请求之后，且在所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据之前，所述方法还包括：

检测所述查询请求所请求数据的时间粒度是否属于所述访问端对应的可查询粒度，若属于，则执行所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据的步骤；

其中，所述访问端对应的可查询粒度为：所述访问端所属业务方通过配置界面所配置的允许查询的时间粒度。

9.根据权利要求1-3任一项所述的方法，其中，在所述接收访问端发送的针对时序数据的查询请求之后，且在所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据之前，所述方法还包括：

检测所述查询请求的查询语句结构是否符合指定语句结构，若符合，则执行所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据的步骤；

其中，所述指定语句结构为：所述访问端所属业务方通过配置界面所配置的查询语句的语句结构。

10.根据权利要求1-3任一项所述的方法，在所述接收访问端发送的针对时序数据的查询请求之后，且在所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据之前，所述方法还包括：

基于所述访问端的令牌token，对所述访问端进行鉴权，并在鉴权通过之后，执行所述从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据的步骤；

其中，所述令牌token为所述访问端所属业务服务器为所述访问端所分配的。

11.一种数据查询装置，应用于边缘节点，所述方法包括：

请求接收模块，用于接收访问端发送的针对时序数据的查询请求；

数据请求模块，用于从内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；其中，所述内容分发网络系统的源站节点中采用时序数据库存储时序数据；

结果反馈模块，用于基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果。

12.根据权利要求11所述的装置，其中，所述数据请求模块，具体用于确定包含有指定时间信息的目标时间段；其中，所述指定时间信息为所述查询请求中所给定的时间信息，所述目标时间段的时间粒度大于所述指定时间信息的时间粒度；从内容分发网络系统中，请求所述目标时间段内的数据块，作为目标时序数据；

所述结果反馈模块，具体用于从所述目标时序数据中，选取符合所述指定时间信息的时序数据，并将所选取的时序数据反馈给所述访问端。

13.根据权利要求12所述的装置，其中，所述目标时间段为各指定时间段中包含有所述指定时间信息的最短时间段；

其中，各指定时间段属于所述指定时间信息的时间粒度的上一时间粒度。

14.根据权利要求11-13任一项所述的装置，其中，所述装置还包括：

指令发送模块，用于向所述内容分发网络系统发送缓存数据管理指令，以使所述内容分发网络系统在接收到所述缓存数据管理指令后，确定用于管理缓存数据的时间滑动窗口的窗口范围，将本地缓存的早于所述窗口范围的时序数据进行持久化存储，以及将本地缓存的位于所述窗口范围内时序数据，在满足预定缓存清除条件时进行清除。

15.根据权利要求11-13任一项所述的装置，其中，所述源站节点采用时序数据库存储时序数据的方式包括：

按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中；其中，各个数据类别为基于数据生成场景所划分的类别。

16.根据权利要求15所述的装置，其中，所述各个数据类别包括：流式数据类别和非流式数据类别，所述非流式数据类别包括时效数据类别和非时效数据类别；

所述按照与各个数据类别对应的写入方式，将待存储的各个数据类别的时序数据写入到时序数据库中，包括：

通过在线写入方式，将属于时效数据类别的第一类时序数据写入到时序数据库中；通过近线写入方式，将属于流式数据类别的第二类时序数据写入到时序数据库中；通过离线写入方式，将属于非时效数据类别的第三类数据写入到时序数据库中。

17.一种数据查询系统，包括：边缘节点、内容分发网络系统和所述内容分发网络系统的源站节点；其中，所述源站节点中采用时序数据库存储时序数据；

所述边缘节点，用于接收访问端发送的针对时序数据的查询请求；从所述内容分发网络系统中，请求与所述查询请求相匹配的目标时序数据；基于所述目标时序数据，向所述访问端反馈所述查询请求对应的查询结果；

所述内容分发网络系统，用于在所述边缘节点请求与所述查询请求相匹配的目标时序数据时，向所述边缘节点反馈所述目标时序数据。

18.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-10中任一项所述的方法。

19.一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行根据权利要求1-10中任一项所述的方法。

20.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-10中任一项所述的方法。

Images