具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

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

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

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

CDN(Content Delivery Network，内容分发网络)：是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

CDN节点：处于网络边缘(不同地域如省份、城市)的分发内容的服务器节点。用于进行内容存储，位于用户接入点，是面向最终用户的内容提供设备，可缓存静态Web内容和流媒体内容，实现内容的边缘传播和存储，以便用户的就近访问。

ICMP(Internet Control Message Protocol，因特网控制报文协议)：是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。其中，控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。

SNMP(Simple Network Management Protocol，简单网络管理协议)：是用于在IP网络管理网络节点(服务器、工作站、路由器、交换机等)的一种标准协议，它是一种应用层协议。可以用于采集节点流量以计算带宽。

HTTP(Hypertext Transfer Protocol，超文本传输协议)：是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应，可以用于判断设备节点的HTTP服务是否正常。

TCP(Transmission Control Protocol，TCP)：是一种面向连接的、可靠的、基于字节流的传输层通信协议传输控制协议，可以用于判断HTTP节点在传输层的通信状态是否正常。

带宽：网络带宽，指在单位时间(一般指的是1秒钟)内传输的数据量。

直播源站：接收主播音视频数据的中心服务器。

在本申请中，提供了一种数据处理方法，本申请同时涉及一种数据处理装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种数据处理方法的流程图，具体包括以下步骤：

步骤102：获取至少一个数据节点的目标数据。

其中，所述数据节点，可以理解为任意的设备节点或虚拟设备节点，比如交换机节点、内容分发节点(CDN节点)、终端节点、服务器节点等，在此不做限制。实际应用中，数据节点的数量可以是一个，也可以是多个，每个数据节点中可以存储任意的数据，比如，状态数据、资源数据、指标数据等，而这些数据还可以进一步分为不同的数据类型，比如状态数据可以分为：网络状态数据、通讯状态数据等类型，资源数据可以分为：视频资源数据、文本资源数据、音频资源数据等类型，指标数据可以分为：性能指标数据、服务指标数据等类型，在此不做限制。

实际应用中，获取至少一个数据节点的目标数据，可以直接获取从至少一个数据节点中预先采集的目标数据，也可以直接从至少一个数据节点获取目标数据，在此不做限制。

可选地，所述数据节点包括内容分发节点(CDN节点)，所述目标数据包括：状态数据。

在视频直播场景或点播场景下，由于直播平台对于网络的要求十分高，为了尽量减少卡顿、花屏、掉线等情况，可以借助CDN节点，提前将直播的音视频数据推送到接近用户的CDN节点上，使得用户就近从CDN节点取得音视频数据，从而提升用户访问的速度和观看的稳定性。

通过CDN节点缓存数据，还可以减轻直播源站的带宽和访问压力，因此，直播平台可以接入大量的CDN节点，通过CDN节点承担接收上行的音视频数据、接收就近观众的请求以提供观看服务的任务，因此，CDN提供服务的稳定性直接影响着用户的体验，一旦CDN的网络健康状态变差，甚至出现掉线情况，监控系统必须及时捕捉，并将故障信息提供给调度层，将对应的故障节点下线，将该节点上的流量转移到相近的节点上，这样才能保证服务的质量、用户的体验。

而如何保证及时、可靠地采集大量CDN节点的网络状态数据，并以结构化的形式将数据通过网络高效地传输给其他系统(如调度系统)，是管理大量CDN节点的难题，并且由于CDN节点数量多，不便于集中部署、发布，所以可以由多个采集节点主动向CDN节点发起通用网络协议的请求收集数据。

具体的，采集节点可以向CDN节点收集(获取)的数据包括：ICMP、SNMP、HTTP、TCP、带宽等数据，其中，ICMP用于判断网络通不通、主机是否可达等；SNMP用于采集CDN节点的流量以计算带宽；HTTP，用于判断CDN节点的HTTP服务是否正常；TCP用于判断CDN节点在传输层的通信状态是否正常；带宽用于判断CDN节点的网络访问量。

步骤104：基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，并基于所述聚合策略对所述目标数据进行聚合。

具体的，在获取目标数据的基础上，考虑到获取的目标数据较为零散，因此，为了提高目标数据的使用效率，可以基于数据需求方的需求信息，对目标数据进行聚合，具体的，需要基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，其中，所述数据需求方，可以理解为对数据节点中目标数据的需求方，具体的，数据需求方，可以包括审核平台/系统/服务/模块、监控平台/系统/服务/模块、数据平台/系统/服务/模块、调度平台/系统/服务/模块等，实际应用中，这些数据需求方通常按照周期(比如1分钟、1天、1个月等)获取数据节点中其需要的数据，以便进行相应的处理(比如审核、监控、存储或调度等处理)。

数据需求方的需求信息，包括需求时间信息(比如每天或每小时等)、需求场景信息(比如视频直播场景、视频点播场景等)、需求数据信息(比如需求数据以数据节点为基本单元、需求数据以数据类型为基本单元)等。

具体的，所述聚合策略可以是按照数据量聚合(比如每1000条数据聚合)，按照数据生成时间聚合、或者按照数据类型聚合等，此外还可以两种或两种以上聚合方式的组合，在此不做限制。进一步的，在确定针对目标数据的聚合策略的基础上，对目标数据进行聚合，具体的，对目标数据进行聚合可以理解对目标数据进行汇总。

可选地，本申请实施例提供的一种可选实施方式中，所述基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，并基于所述聚合策略对所述目标数据进行聚合，具体采用如下方式实现：

基于数据需求方的需求信息中的需求数据信息，从所述目标数据中提取数据类型以及所述数据节点的节点信息；

根据所述数据节点的节点信息或所述数据类型，对所述目标数据进行第一次聚合。

实际应用中，所述需求数据信息，可以理解为对所需求的数据的描述信息，比如有的数据需求方需要按照数据节点获取数据，有的数据需求方需要按照数据类型获取数据，其中，数据节点或数据类型都为需求数据信息。进一步的，基于需求数据信息，则可以从目标数据中提取数据节点的节点信息(比如节点标识、节点名称等信息)，或从数据节点采集的数据的数据类型，以便根据数据节点的节点信息或数据类型，对目标数据进行第一次聚合。

其中，所述标识信息，可以唯一地标识一个数据节点；所述数据类型，可以理解为目标数据的类型，以数据节点为CDN节点、目标数据为状态数据为例，目标数据的数据类型包括：ICMP类型、SNMP类型、HTTP类型、TCP类型、BandWidth(带宽)类型等。

以数据节点为CDN节点为例，根据CDN节点的标识信息，将目标数据进行第一次聚合，第一次聚合后的目标数据如下所示：

"cdn_1"：{"icmp"：100ms，"snmp"：1，"http"：1，"tcp"：200ms，"bandwidth"：1Gbps}

根据相同数据类型，将不同CDN节点的目标数据进行第一次聚合，第一次聚合后的目标数据如下所示：

"icmp"：{"cdn_1"：100ms，"cdn_2"：200ms，"cdn_3"：300ms，"cdn_4"：500ms，...，"cdn_n"：80ms}

本申请实施例，基于数据需求方的需求信息中的需求数据信息，对目标数据进行第一次聚合，使得目标数据的结构满足数据需求方的需求，避免了数据需求方对数据进行聚合，提升了数据需求方的处理效率。

进一步的，为了提高对目标数据的使用效率(比如传输效率、存储效率等)，可以在对目标数据进行第一次聚合之后，对目标数据进行第二次聚合，实际应用中，对目标数据进行第二次聚合的方式是多种多样的，考虑到提高第二次聚合的效率，本申请实施例提供的第一种可选实施方式中，所述根据所述数据节点的节点信息或所述数据类型，对所述目标数据进行第一次聚合之后，还包括：

根据预设数据量和/或预设聚合周期，对第一次聚合后的目标数据进行第二次聚合。

其中，所述预设数据量，可以理解为需要进行数据聚合的数据量，该数据量可以是数据量条数，比如1000条，2000条等，也可以是数据量大小，比如50kb、100kb等，所述预设聚合周期，可以理解为预先设置的聚合数据的时间区间，比如预设聚合周期为2020-01-01～2020-01-02这个时间区间。

沿用上例，可以先根据相同的CDN节点(其中，CDN节点通过节点标识比如cnd_1，cdn_2，…，cdn_n等进行区分)，将不同待采集数据类型(比如ICMP、SNMP、HTTP、TCP、BandWidth等数据类型)的数据进行第一次聚合，并按照1000条的数据量进行二次聚合并上报，即满1000条数据量上报一次，具体的聚合后的数据如图2(a)所示。

此外，还可以根据相同待采集数据类型，将不同CDN节点的数据进行第一次聚合，并且按照聚合时间区间，将2020-01-01 10：10：00-2020-01-01 10：10：03时间段内采集的数据进行第二次聚合并上报，具体的聚合后的数据如图2(b)所示。

本申请实施例，基于预设数据量和/或预设聚合周期对目标数据进行二次聚合，使聚合后的数据更加有条理，便于数据需求方进行数据获取，提高了数据传输的效率。

此外，考虑到提高第二次聚合的灵活性，以及数据聚合所处的当前设备的性能情况，本申请实施例提供的第二种可选实施方式中，所述根据所述数据节点的节点信息或所述数据类型，对所述目标数据进行第一次聚合之后，还包括：

确定当前设备的性能数据；

根据所述性能数据和/或所述需求信息，确定第一次聚合后的目标数据的第二次聚合规则；

基于所述第二次聚合规则，对所述第一次聚合后的目标数据进行第二次聚合。

所述性能数据，可以理解为表示当前设备的性能的数据，具体的，该性能数据可以是CPU的占用率，带宽使用率等数据。并进一步的，根据所述性能数据，确定第一次聚合后的目标数据的第二次聚合规则，其中，第二次聚合规则，可以理解为在第一次对目标数据进行聚合的基础上，第二次对聚合后的目标数据进行聚合的规则，比如：第二次聚合规则可以是以数据量为1000条进行聚合，或以时间周期为2小时进行聚合。

其中，数据量或时间周期的具体数值，可以根据当前网络传输状况、系统当前时间段的忙闲情况等因素动态地进行调节，比如在当前网络传输速率大于传输阈值的情况下，则确定第二次聚合规则为以数据量2000条进行聚合，在当前网络传输速率小于等于传输阈值的情况下，则确定第二次聚合规则为以数据量1000条进行聚合，实现了调节负载、节省资源的目的。

此外，数据量或时间周期的具体数值，也可以根据数据需求方的需求信息(比如需求时间信息、需求数据量等)进行确定，比如，数据需求方A的需求时间信息为每小时，则确定第二次聚合规则为聚合周期1小时进行聚合。

本申请实施例，在对目标数据按照数据需求方的需求进行第一次聚合之后，根据当前设备的性能数据和/或数据需求方的需求信息，对目标数据进行第二次聚合，减少了目标数据在各方(比如需求方、采集节点等)传输的次数，并且提升了目标数据的传输效率。

步骤106：根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长。

在对目标数据进行聚合的基础上，还需要将目标数据写入至预设存储组件，以便数据需求方从该预设存储组件中获取该目标数据。其中，所述预设存储组件，可以理解为用于存储数据的存储介质，优选地，该预设存储组件可以是内存、固态硬盘等存取速率高的存储介质。

所述写入频率，是指将目标数据存储(写入)至预设存储组件的频率；所述存储时长，是指写入预设存储组件中的目标数据在预设存储组件中的存储的时长。

实际应用中，根据需求信息，确定目标数据写入预设存储介质的写入频率以及存储时长，以保障将目标数据在需求之前写入预设存储节点，并在目标数据过期之前(即取用之前)目标数据仍旧存储于预设存储组件，也使存储的过期时间(存储时长)可以根据下游业务方(数据需求方)的要求灵活配置。

具体实施时，确定所述写入频率以及存储时长的确定方式是多种多样的，本申请实施例提供的一种可选实施方式中，所述根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长，包括：

根据所述需求信息中的需求时间信息、需求数据类型和/或需求场景信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长。

实际应用中，可以预设需求时间信息、需求数据类型、需求场景信息等需求信息和写入频率(和/或存储时长)之间的对应关系，并进一步，根据数据需求方的需求信息，确定对应的写入频率以及存储时长。

此外，还可以将需求时间信息、需求数据类型和/或需求场景信息，抽象为具体的数值，并进一步将抽象出的数值输入预设算法或公式进行计算，确定所述写入频率以及存储时长。

比如，需求信息中的需求时间信息为每5分钟需要获取数据，即需求时间周期为5分钟，若基于需求时间信息计算写入频率的公式为1/(0.5*需求时间周期)＝写入频率，则计算而得的写入频率为0.4次/分钟；

若基于需求时间信息计算存储时长的公式为1.5*需求时间周期＝存储时长，则计算而得的存储时长为7.5分钟。

再比如，针对需求数据类型1，需求数据类型1对应(抽象为)数值8，具体的，该对应关系(抽象关系)为预先设置的，若基于需求数据类型计算写入频率的公式为1/需求数据类型对应的数值＝写入频率，则计算而得的写入频率为0.125次/分钟；若基于需求数据类型计算存储时长的公式为0.5*需求数据类型对应的数值＝存储时长，则计算而得的存储时长为4分钟。

本申请实施例，根据需求信息中需求时间信息、需求数据类型和/或需求场景信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在预设存储组件中的存储时长，增加了确定写入频率以及存储时长的灵活性，保障了对聚合后的目标数据在预设存储介质中进行存取的实际，可以在需求的至少一个层面被有力控制。

步骤108：按照所述写入频率，将所述聚合后的目标数据写入预设存储组件，并将达到所述存储时长的目标数据从所述预设存储组件中删除。

在上述确定写入频率以及存储时长的基础上，将聚合后的目标数据按照写入频率写入预设存储组件，以便从预设存储组件中提取供数据需求方所使用的数据，并在存储达到存储时长的目标数据从预设存储组件中删除，避免了大量过期数据占用预设存储组件中的存储空间。

具体的，在预设存储组件为内存时，因为内存的访问速度远远快于访问其他的存储组件的速度，这样数据收拢服务提供的查询接口(即针对目标数据的查询接口)性能就得到了大幅提升。

进一步的，本申请实施例提供的一种可选实施方式中，在所述数据节点包括内容分发节点，所述目标数据包括状态数据的情况下，相应地，所述将所述聚合后的目标数据写入预设存储组件之后，还包括：

通过所述数据需求方提交的数据请求，从所述预设存储组件获取所述数据请求对应的状态数据。

具体的，将聚合后的目标数据写入预设存储组件的目的是为了便于对该数据进行取用，实际应用中，数据需求方可以针对存储的状态数据提交数据请求，以便从预设存储组件中获取该数据请求对应的状态数据，具体的，该数据请求中可以携带状态数据的生成时间区间、数据标识等信息，以便基于这些信息可以确定对应的状态数据并获取，提高了针对状态数据的获取效率。

比如，状态数据存储于内存中，且所述数据请求中携带的状态数据的生成时间区间为[2020-05-12～2020-05-13]，则通过数据需求方提交的数据请求，从内存中获取在2020-05-12～2020-05-13这个时间段内的状态数据。

在上述获取对应的状态数据的基础上，本申请实施例提供的一种可选实施方式中，所述从所述预设存储组件获取所述数据请求对应的状态数据之后，还包括：

对所述数据请求对应的状态数据进行分析，确定所述内容分发节点的节点状态；

根据所述节点状态以及所述数据需求方，确定对所述内容分发节点的处理策略，并基于所述处理策略执行处理任务。

实际应用中，内容分发节点(CDN节点)的状态数据，可以用于表示该CDN节点的状态，比如该CDN节点是否可以正常对外提供服务等，具体的，对获取的状态数据进行分析，可以将获取的状态数据与预先设置的正常状态下的状态数据阈值区间进行对比，若获取的状态数据处于预设的状态数据阈值区间，表明内容分发节点的节点状态为正常，不做处理即可，若获取的状态数据处于预设的状态数据阈值区间之外，表明该内容分发节点的节点状态为异常，需要基于数据需求方的功能，确定对内容分节点的处理策略并处理。

其中，所述处理策略，包括：告警处理、流量调度处理、移除处理、标记处理等策略，在此不做限制。相应的，所述处理任务，包括：执行前述告警处理、流量调度处理、移除处理、标记处理等任务。实际应用中，由于各种数据需求方获取内容分发节点的目的不同，因此，在确定节点状态为异常的基础上，不同的数据需求方对内容分发节点的处理策略也不同，比如数据需求方为资源管理平台的情况下，需要对异常的内容分发节点进行移除处理。

本申请实施例，通过对获取的状态数据进行分析，确定内容分发节点的节点状态，并基于节点状态和数据需求方，确定对内容分发节点的处理策略并处理，实现了基于获取的状态数据对内容分发节点进行状态检测并进行相应处理，保障了内容分发节点的服务质量。

进一步的，本申请实施例提供的一种可选实施方式中，所述根据所述节点状态以及所述数据需求方，确定对所述数据节点的处理策略并处理，具体采用如下方式实现：

在所述节点状态为异常且所述数据需求方为监控方的情况下，确定所述处理策略为发送针对异常的内容分发节点的状态通知；或

在所述节点状态为异常且所述数据需求方为调度方的情况下，确定所述处理策略为对异常的内容分发节点进行调度处理。

在数据需求方为监控方的场景下，监控方用于对内容分发节点的异常状态进行监控并通知，具体的，在监控方监控到节点状态为异常的情况下，需要将异常的内容分发节点作为故障节点，并确定所述处理策略为发送针对内容分发节点的状态通知。具体实施时，该状态通知中可以包括：异常的内容分发节点的标识信息以及异常的状态数据等信息，以便接收方可以基于该状态通知尽快对故障节点进行故障修复。

在数据需求方为调度方的场景下，调度方用于对异常的内容分发节点进行流量均衡或移除处理(即调度处理)。其中，所述流量调度，可以理解为将访问量大的内容分发节点的访问量调度至访问量小的内容分发节点中。比如网络状态数据中的带宽大于预设带宽阈值时，表明针对对应的内容分发节点的流量很大，则可以将针对该内容分发节点的流量转移至其他带宽较小的内容分发节点中。而移除处理，可以理解为将CDN节点从对外服务中进行移除，即使通讯异常的CDN节点不对外提供访问服务。比如，某一内容分发节点的通讯状态数据异常，表明该内容分发节点不能正常通讯，为了避免影响用户的访问体验，则确定所述处理策略为对该内容分发节点进行移除处理。

本申请实施例，通过监控方对节点状态异常的内容分发节点发送状态通知，或通过调度方对异常的内容分发节点进行调度处理，提高了对内容分发节点的处理效率，保障了内容分发节点的服务质量。

此外，由于在预设存储组件中存储的数据需要按照存储时长进行删除，因此，可以在将聚合后的目标数据写入预设存储组件之后，并将该目标数据从预设存储组件中进行删除之前，可以将该聚合后的目标数据转储至其他数据存储组件，比如硬盘、光盘等，以便对目标数据进行追溯并分析。

参见图3所示的一种数据处理方法的架构示意图，本申请提供的数据处理方法，以待采集节点为CDN节点为例进行描述，具体的，资源管理用于对待采集的CDN节点进行配置，而采集节点在对CDN节点进行数据采集之前，先从资源管理获取待采集的CDN列表，CDN列表中包括待采集的CDN节点(具体的，CDN节点在CDN列表中可以通过节点标识进行标识)以及每个待采集的CDN节点需要采集的数据类型，以便采集节点基于CDN列表采集节点对应的状态数据，并在采集完成后，对采集的数据进行聚合并上报至数据收拢服务，以便调度、数据存储、监控和/或其他服务/系统/平台，从数据收拢服务拉取聚合后的数据进行相应的处理，其中，调度服务/系统/平台可以基于拉取的数据对CDN节点进行流量调度，数据存储服务/系统/平台(比如数据平台)用于对拉取的数据进行数据存储，以便后续对数据进行跟踪或分析，而监控服务/系统/平台用于对拉取的数据进行监控，以确定CDN节点是否存在异常状态并进行告警处理。

综上所述，本申请提供的数据处理方法，在获取至少一个数据节点的目标数据的基础上，基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，并基于所述聚合策略对所述目标数据进行聚合，实现了基于数据需求方的需求信息对数据进行聚合，并通过聚合实现了对数据的结构化处理，在聚合之后，根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长，并按照所述写入频率，将所述聚合后的目标数据写入预设存储组件，并将达到所述存储时长的目标数据从所述预设存储组件中删除，实现了对基于数据需求方的需求，调节对数据的写入频率以及存储时长，并通过对结构化数据进行写入以及存储，提高了数据处理效率。

下述结合附图4，以本申请提供的数据处理方法在直播场景的应用为例，对所述数据处理方法进行进一步说明。其中，图4示出了本申请一实施例提供的一种应用于直播场景的数据处理方法的处理流程图，具体包括以下步骤：

步骤402：通过采集节点从CDN节点采集数据。

具体的，采集方式可以参考上述方法实施例，在此不做赘述。其中，CDN节点数量为至少一个，采集的数据可以包括：：ICMP、SNMP、HTTP、TCP、带宽等状态数据，其中，ICMP用于判断网络通不通、主机是否可达等；SNMP用于采集CDN节点的流量以计算带宽；HTTP，用于判断CDN节点的HTTP服务是否正常；TCP用于判断CDN节点在传输层的通信状态是否正常；带宽用于判断CDN节点的网络访问量。

步骤404：通过采集节点聚合数据并将数据上报至数据收拢服务。

具体的，采集节点将从CDN节点采集的数据进行聚合处理，可以根据CDN节点ID(标识)以及数据数量(比如1000条进行聚合)实现，此外，还可以根据数据类型(即上述方法实施例中的待采集数据类型)、数据采集时间聚合，并将聚合后的数据上报至数据收拢服务。

步骤406：通过数据收拢服务聚合数据。

具体的，数据收拢服务可以根据不同的数据需求方(比如调度、数据平台、或其他系统或服务)的数据需求，在上述数据聚合(第一次数据聚合)的基础上，进行第二次数据聚合，形成结构化的数据。

步骤408：通过数据收拢服务定时将结构化的数据从存储中缓存到内存中。

具体的，可以按照预设周期，将上述第二次聚合后的数据从存储中缓存到内存中，以便增加针对该结构化数据的获取效率。其中，存储可以理解为上述预设存储组件。

步骤410：在数据需求方向数据收拢服务发送拉取请求的情况下，通过数据收拢服务基于所述拉取请求向数据需求方返回对应的数据。

实际应用中，数据需求方(比如调度、数据平台、或其他系统或服务)可以定期向数据收拢服务发送拉取请求。

综上所述，本申请提供的数据处理方法，通过对从CDN节点进行数据采集，并对采集到的数据进行数据集合并存储于内存中，提高了数据存储的效率，也便于数据需求方从内存中拉取相应的数据，加快了数据需求方的拉取速率。

下述结合附图5，以本申请提供的数据处理方法在点播场景的应用为例，对所述数据处理方法进行进一步说明。其中，图5示出了本申请一实施例提供的一种应用于点播场景的数据处理方法的处理流程图，具体包括以下步骤：

步骤502：获取至少一个内容分发节点的视频点播数据。

具体的，视频点播数据包括：访问量、加载时长、码率等数据，通过这些数据即可对内容分发节点的视频点播状态进行监控和分析。

步骤504：基于数据需求方的需求信息中的需求数据信息，从所述视频点播数据中提取数据类型以及所述内容分发节点的节点信息。

具体的，数据需求方可以是调度方服务/系统/平台、监控服务/系统/平台、数据存储服务/系统/平台等；所述数据类型，可以是访问量类型、加载时长类型、码率类型等；所述节点信息，可以是内容分发节点的节点标识、节点名称等，在此不做限制。

步骤506：根据所述数据节点的节点信息或所述数据类型，对所述视频点播数据进行第一次聚合。

步骤508：确定当前设备的性能数据。

步骤510：根据所述性能数据和/或所述需求信息，确定第一次聚合后的视频点播数据的第二次聚合规则。

步骤512：基于所述第二次聚合规则，对所述第一次聚合后的视频点播数据进行第二次聚合。

步骤514：根据所述需求信息中的需求时间信息、需求数据类型和/或需求场景信息，确定聚合后的视频点播数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长。

步骤516：按照所述写入频率，将所述聚合后的目标数据写入预设存储组件。

步骤518：通过所述数据需求方提交的数据请求，从所述预设存储组件获取所述数据请求对应的视频点播数据。

步骤520：对所述数据请求对应的视频点播数据进行分析，确定所述内容分发节点的点播状态。

步骤522：在所述点播状态为异常且所述数据需求方为监控方的情况下，确定处理策略为发送针对异常的内容分发节点的状态通知。

此外，在所述节点状态为异常且所述数据需求方为调度方的情况下，还可以确定处理策略为对异常的内容分发节点进行调度处理。

步骤524：基于处理策略执行发送针对异常的内容分发节点的状态通知。

步骤526：将达到所述存储时长的视频点播数据从所述预设存储组件中删除。

综上所述，本申请提供的数据处理方法，在获取至少一个内容分发节点的视频点播数据的基础上，基于数据需求方的需求信息，确定针对所述视频点播数据的聚合策略，并基于所述聚合策略对所述视频点播数据进行聚合，实现了基于数据需求方的需求信息对视频点播数据进行聚合，并通过聚合实现了对视频点播数据的结构化处理，在聚合之后，根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长，并按照所述写入频率，将所述聚合后的视频点播数据写入预设存储组件，并将达到所述存储时长的视频点播数据从所述预设存储组件中删除，实现了对基于数据需求方的需求，调节对数据的写入频率以及存储时长，并通过对结构化数据进行写入以及存储，提高了数据处理效率。

与上述方法实施例相对应，本申请还提供了数据处理装置实施例，图6示出了本申请一实施例提供的一种数据处理装置的结构示意图。如图6所示，该装置包括：

获取模块602，被配置为获取至少一个数据节点的目标数据；

聚合模块604，被配置为基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，并基于所述聚合策略对所述目标数据进行聚合；

确定模块606，被配置为根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长；

写入模块608，被配置为按照所述写入频率，将所述聚合后的目标数据写入预设存储组件，并将达到所述存储时长的目标数据从所述预设存储组件中删除。

可选地，所述聚合模块604，进一步被配置为：

基于数据需求方的需求信息中的需求数据信息，从所述目标数据中提取数据类型以及所述数据节点的节点信息；

根据所述数据节点的节点信息或所述数据类型，对所述目标数据进行第一次聚合。

可选地，所述聚合模块604，还包括：

根据预设数据量和/或预设聚合周期，对第一次聚合后的目标数据进行第二次聚合。

可选地，所述聚合模块604，还包括：

确定当前设备的性能数据；

根据所述性能数据和/或所述需求信息，确定第一次聚合后的目标数据的第二次聚合规则；

基于所述第二次聚合规则，对所述第一次聚合后的目标数据进行第二次聚合。

可选地，所述确定模块606，进一步被配置为：

根据所述需求信息中的需求时间信息、需求数据类型和/或需求场景信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长。

可选地，所述数据节点包括：内容分发节点，所述目标数据包括：状态数据；

相应地，所述数据处理装置，还包括：

获取数据模块，被配置为通过所述数据需求方提交的数据请求，从所述预设存储组件获取所述数据请求对应的状态数据。

可选地，所述数据处理装置，还包括：

确定状态模块，被配置为对所述数据请求对应的状态数据进行分析，确定所述内容分发节点的节点状态；

处理模块，被配置为根据所述节点状态以及所述数据需求方，确定对所述内容分发节点的处理策略，并基于所述处理策略执行处理任务。

可选地，所述处理模块，进一步被配置为：

在所述节点状态为异常且所述数据需求方为监控方的情况下，确定所述处理策略为发送针对异常的内容分发节点的状态通知；或

在所述节点状态为异常且所述数据需求方为调度方的情况下，确定所述处理策略为对异常的内容分发节点进行调度处理。

综上所述，本申请提供的数据处理装置，在获取至少一个数据节点的目标数据的基础上，基于数据需求方的需求信息，确定针对所述目标数据的聚合策略，并基于所述聚合策略对所述目标数据进行聚合，实现了基于数据需求方的需求信息对数据进行聚合，并通过聚合实现了对数据的结构化处理，在聚合之后，根据所述需求信息，确定聚合后的目标数据写入至预设存储组件的写入频率以及在所述预设存储组件中的存储时长，并按照所述写入频率，将所述聚合后的目标数据写入预设存储组件，并将达到所述存储时长的目标数据从所述预设存储组件中删除，实现了对基于数据需求方的需求，调节对数据的写入频率以及存储时长，并通过对结构化数据进行写入以及存储，提高了数据处理效率。

上述为本实施例的一种数据处理装置的示意性方案。需要说明的是，该数据处理装置的技术方案与上述的数据处理方法的技术方案属于同一构思，数据处理装置的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

图7示出了根据本说明书一个实施例提供的一种计算设备700的结构框图。该计算设备700的部件包括但不限于存储器710和处理器720。处理器720与存储器710通过总线730相连接，数据库750用于保存数据。

计算设备700还包括接入设备740，接入设备740使得计算设备700能够经由一个或多个网络760通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备740可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备700的上述部件以及图7中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图7所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备700可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备700还可以是移动式或静止式的服务器。

其中，处理器720执行所述计算机指令时实现所述的数据处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，所述计算机指令被处理器执行时实现如前所述数据处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。