日志处理方法、装置、计算设备和存储介质与流程

本发明涉及云计算技术领域，尤其涉及一种日志处理方法、装置、计算设备和存储介质。

背景技术：

随着云计算技术的发展，越来越多的服务提供方将自己提供的服务部署在云端。目前，云端主要采用中心云+边缘云的分布式云架构，服务提供方提供的服务既可以部署在中心云，也可以部署在边缘云。终端用户可以通过边缘云就近访问服务提供方提供的服务。

对于某服务提供方来说，由于用户访问量与日俱增，那么产生的用户访问日志也会与日俱增，这些用户访问日志最终需要交付给服务提供方。随着数据量规模越来越大，中心云资源有限，依托中心云来完成整个的日志交付流程具有明显的局限性。

技术实现要素：

本发明实施例提供一种日志处理方法、装置、计算设备和存储介质，降低日志交付过程中对中心云资源的占用。

第一方面，本发明实施例提供一种日志处理方法，应用于边缘云节点，该方法包括：

确定使用所述边缘云节点的目标服务提供方，所述目标服务提供方是需要在本地进行日志计算处理的服务提供方；

获取所述目标服务提供方的多个用户访问日志；

根据所述目标服务提供方的配置信息对所述多个用户访问日志进行计算处理，得到目标日志文件；

将所述目标日志文件发送至目标中心云节点，以由所述目标中心云节点将所述目标日志文件提供给所述目标服务提供方。

第二方面，本发明实施例提供一种日志处理装置，位于边缘云节点，该装置包括：

获取模块，用于确定使用所述边缘云节点的目标服务提供方，获取所述目标服务提供方的多个用户访问日志，所述目标服务提供方是需要在本地进行日志计算处理的服务提供方；

计算模块，用于根据所述目标服务提供方的配置信息对所述多个用户访问日志进行计算处理，得到目标日志文件；

发送模块，用于将所述目标日志文件发送至目标中心云节点，以由所述目标中心云节点将所述目标日志文件提供给所述目标服务提供方。

第三方面，本发明实施例提供一种计算设备，位于边缘云节点，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第一方面所述的日志处理方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器至少可以实现如第一方面所述的日志处理方法。

第五方面，本发明实施例提供一种日志处理方法，该方法包括：

接收边缘云节点发送的与目标服务提供方对应的目标日志文件，所述目标日志文件由所述边缘云节点根据所述目标服务提供方的配置信息对所述目标服务提供方的多个用户访问日志进行计算处理得到，所述目标服务提供方是需要在所述边缘云节点进行日志计算处理的服务提供方；

将所述目标日志文件提供给所述目标服务提供方。

第六方面，本发明实施例提供一种日志处理装置，该装置包括：

接收模块，用于接收边缘云节点发送的与目标服务提供方对应的目标日志文件，所述目标日志文件由所述边缘云节点根据所述目标服务提供方的配置信息对所述目标服务提供方的多个用户访问日志进行计算处理得到，所述目标服务提供方是需要在所述边缘云节点进行日志计算处理的服务提供方；

处理模块，用于将所述目标日志文件提供给所述目标服务提供方。

第七方面，本发明实施例提供一种计算设备，位于中心云节点，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第五方面所述的日志处理方法。

第八方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器至少可以实现如第五方面所述的日志处理方法。

本发明实施例提供的日志处理方案可以适用于由中心云和边缘云构成的网络架构中，在该网络架构中，服务提供方提供的服务可以被缓存在一个或多个边缘云节点中，以供终端用户就近访问。针对任一边缘云节点来说，先确定使用该边缘云节点的需要在本地进行日志计算处理的目标服务提供方，假设目标服务提供方的服务缓存在该边缘云节点上，那么在向将该目标服务提供方进行用户访问日志交付的过程中，首先，该边缘云节点获取目标服务提供方的多个用户访问日志，即通过该边缘云节点访问该目标提供方提供的服务的终端用户的访问日志。之后，在该边缘云节点本地根据目标服务提供方的配置信息完成对这些用户访问日志的计算处理，得到由处理后的用户访问日志构成的目标日志文件，将目标日志文件发送至目标中心云节点，以由目标中心云节点将该目标日志文件交付给目标服务提供方。由此可见，在该方案中，通过边缘云与中心云相结合的方式，解耦掉中心云的复杂计算任务，将对用户访问日志的计算任务下沉到边缘云，以缓解日志交付过程对中心云资源的过渡占用。

附图说明

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

图1为本发明实施例提供的一种日志处理系统的示意图；

图2为本发明实施例提供的一种日志处理方法的交互流程图；

图3为本发明实施例提供的一种操作表的示意图；

图4为本发明实施例提供的一种日志处理方法的流程图；

图5为本发明实施例提供的一种日志处理方法的流程图；

图6为本发明实施例提供的一种日志处理方法的应用场景示意图；

图7为本发明实施例提供的一种日志处理装置的结构示意图；

图8为与图7所示实施例提供的日志处理装置对应的计算设备的结构示意图；

图9为本发明实施例提供的一种日志处理装置的结构示意图；

图10为与图9所示实施例提供的日志处理装置对应的计算设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

图1为本发明实施例提供的一种日志处理系统的示意图，如图1所示，该系统包括边缘云和中心云。其中，边缘云中包括若干部署在不同位置的边缘云节点，比如图1中示意的边缘云节点1、边缘云节点2、…、边缘云节点n；中心云中包括多个部署在不同地区（region）的中心云节点，比如图1中示意的中心云节点a、中心云节点b、中心云节点c。

中心云节点亦可以称为中心云机房，部署在不同地区的中心云节点实际上物理上相互独立的数据中心。中心云对外提供诸如数据存储、计算、管理等服务，各个服务提供方购买使用中心云提供的服务。

本文中所说的服务提供方是指使用中心云、边缘云的为终端用户提供服务的服务提供商，并非是云服务提供商，云服务提供商简单来说就是中心云和边缘云的所有者。

实际应用中，云服务提供商一般只会在固定的几个地区部署中心云节点，所以虽然每个中心云节点的资源和处理能力比较强，但是由于中心云节点的部署位置固定、数量少、扩展性差，因此，从整体上来说，中心云的计算和存储资源有限，且中心云是为全部的服务提供方提供服务，中心云一旦出现问题，那么影响是全局的。

为提高终端用户的访问响应速度、节省带宽资源等目的，可以将中心云处理的服务程序和数据下沉部署在边缘侧，在更靠近服务提供方的地方为其提供计算、存储、网络的能力和服务，所以边缘云应运而生。边缘是指网络边缘上的计算和存储资源，无论是从地理距离还是网络距离上来看都比中心云更贴近服务提供方。利用边缘资源为服务提供方提供大量服务或功能接口，大大减少上传至中心云的数据量，有效减少网络和中心云的资源压力。

在实际应用中，可以根据实际需求，在若干地方部署边缘云节点，可扩展性强。不同服务提供方所提供的服务可以被运行在不同的边缘云节点上，不同区域的终端用户可以就近访问对应的边缘云节点中某服务提供方所提供的服务，以获得更快的访问响应速度。

基于上述边缘云+中心云的网络架构，可以提供各种应用解决方案，比如构建内容分发网络（contentdeliverynetwork，简称cdn）。可选地，针对某服务提供方（亦即内容提供方）来说，该服务提供方的源站（源服务器）可以位于某中心云节点，在多个边缘云节点上实现该源站的镜像，缓存该服务提供方的服务内容。由于这些边缘云节点位于网络的边缘，距离终端用户仅“一跳”之遥，可以提高用户访问响应速度和命中率。

终端用户通过某边缘云节点访问某服务提供方提供的服务的过程中，在该边缘云节点中会产生对应的用户访问日志，这些用户访问日志可以在该边缘云节点中长存。对于该服务提供方来说，如果其需要收集自己的用户访问日志，那么可选地，边缘云节点可以将该服务提供方对应的用户访问日志上传至中心云，具体是上传到某中心云节点，中心云节点对收到的用户访问日志进行相关计算处理后，存储在本地。该服务提供方从中心云节点中下载计算后的用户访问日志。

但是，如上文中所说，中心云的存储、计算资源有限，且中心云需要为全部的服务提供方提供服务，而用户访问日志的规模是非常大的，可能达到全网一天几个pb的数据规模，如此海量的用户访问日志上传到中心云进行计算处理，会消耗非常多的计算、存储资源，且会消耗较高的带宽成本，会影响中心云为各服务提供方提供的服务的正常运行。

为此，本发明实施例中提出一种结合边缘云与中心云协作高效的日志交付方案，解耦掉中心云的复杂计算过程，将复杂计算过程下沉到边缘云，解决掉上述方案所面临的中心云资源不够的问题。

下面对本发明实施例提供的日志处理方法的执行过程进行详细说明。

图2为本发明实施例提供的一种日志处理方法的交互流程图，如图2所示，该方法包括如下步骤：

201、边缘云节点确定使用该边缘云节点的目标服务提供方，获取目标服务提供方的多个用户访问日志，目标服务提供方是需要在本地进行日志计算处理的服务提供方。

202、边缘云节点根据目标服务提供方的配置信息对多个用户访问日志进行计算处理，得到目标日志文件。

203、边缘云节点将目标日志文件发送至目标中心云节点。

204、目标中心云节点将目标日志文件提供给目标服务提供方。

本实施例中的边缘云节点可以是图1中示意的边缘云中包含的任一个节点。实际应用中，会有很多服务提供方使用同一边缘云节点，上述目标服务提供方可以是使用某边缘云节点的一个服务提供方，且该服务提供方是符合特定条件的服务提供方，即目标服务提供方是根据特定条件确定出的需要在边缘云节点本地进行日志计算处理的服务提供方，下文会在其他实施例中进行该条件的示例性说明。

其中，目标服务提供方对边缘云节点的使用，可以是边缘云节点中缓存有该目标服务提供方的服务资源（比如服务程序、数据等）。当终端用户向该边缘云节点发送与该目标服务提供方对应的访问请求时，如果该边缘云节点中缓存有对应的服务资源，则该边缘云节点可以直接响应终端用户的访问请求，此时无需将终端用户的访问请求传输至某中心云节点，从而，中心云节点不会感知到该终端用户的访问请求。另外，基于终端用户的访问行为，在边缘云节点上会生成对应的用户访问日志。

如上文所述，对于一个边缘云节点来说，会有多个服务提供方使用该边缘云节点，在需要将各服务提供方对应的用户访问日志交付（提供）给对应的服务提供方的情况下，边缘云节点可以定期收集本地产生的若干用户访问日志，之后在本地对获取的用户访问日志进行计算处理，将经过计算处理的用户访问日志上传到中心云，由中心云将处理后的用户访问日志交付给对应的服务提供方。

也就是说，本发明实施例中，将日志交付过程中需要引入的复杂计算过程借助边缘云来完成，轻量级的交付逻辑采用中心云来完成。

概括来说，上述计算处理包括：按照域名/服务提供方+时间维度来组织用户访问日志，按照不同服务提供方提出的字段格式信息对相应服务提供方对应的用户访问日志进行格式转换。

其中，按照域名/服务提供方+时间维度来组织用户访问日志，是指：针对某个域名/服务提供方来说，分别获取其在每个设定的时间段内产生的用户访问日志，将同一域名/服务提供方在某个时间段内产生的用户访问日志构成一个日志文件。因此，按照域名/服务提供方+时间维度来组织用户访问日志，可以理解为是以域名/服务提供方+时间段为索引，来生成对应的日志文件。

举例来说，以上述多个服务提供方中的任一服务提供方（称为目标服务提供方）为例，假设目标服务提供方提供的服务所对应的域名表示为url1，并假设预先针对时间维度的配置结果是：以小时为单位来收集用户访问日志。那么假设在9:00-10:00这个时间段内，域名url1对应的用户访问日志的数量为n1条，在10:00-11:00这个时间段内，域名url1对应的用户访问日志的数量为n2条，那么最终可以生成与域名url1及9:00-10:00这个时间段对应的日志文件1，以及与域名url1及10:00-11:00这个时间段对应的日志文件2。其中，日志文件1中包含上述n1条用户访问日志，日志文件2中包含上述n2条用户访问日志。

另外，如上文所述，对用户访问日志的计算处理还包括：按照不同服务提供方提出的字段格式信息对相应服务提供方对应的用户访问日志进行格式转换。因此，在上述举例中，在得到n1条用户访问日志后，需要先对这n1条用户访问日志进行字段拆分，进而根据目标服务提供方配置的字段格式信息对这些用户访问日志进行格式转换处理，得到包含转换后的n1条用户访问日志的日志文件1。同理进行上述n2条用户访问日志的格式转换处理。

其中，一条用户访问日志中会包含诸如域名、时间戳、ip地址等多个字段，上述字段格式信息中可以描述有目标服务提供方希望的各个字段的排列顺序，当目标服务提供方希望的字段排序顺序与用户访问日志中各字段原本的排列顺序不一致时，需要按照目标服务提供方设置的字段排列顺序来更新用户访问日志。除此之外，可选地，上述字段格式信息中还可以包括字段的数据类型、表示方式等配置信息，也需要按照这些配置信息对相应的字段进行格式转换。

上述举例中以目标服务提供方仅具有一个域名为例进行的说明，实际上，目标服务提供方对外提供服务，可能使用了多个域名。比如某新闻网站，页面中的图片对应的域名为urla，直播视频对应的域名为urlb，点播视频对应的域名为urlc。假设在9:00-10:00这个时间段内，域名urla对应的用户访问日志的数量为m1条，域名urlb对应的用户访问日志的数量为m2条，域名urlc对应的用户访问日志的数量为m3条，此时，按照服务提供方+时间维度来组织用户访问日志的结果是：生成与目标服务提供方及9:00-10:00这个时间段对应的日志文件a，其中，日志文件a中包含上述m1条用户访问日志、m1条用户访问日志和m3条用户访问日志。

实际应用中，边缘云节点可以被配置为定期进行使用其的多个服务提供方的用户访问日志的采集，比如在每天的晚上11点采集此前24小时内产生的用户访问日志，或者，比如每隔6小时采集一次用户访问日志。

结合上述举例可知，上述步骤101中获取目标服务提供方的多个用户访问日志可以是：若当前时间达到边缘云节点的日志采集时间，则本地采集此时还未交付给对应的服务提供方的全部用户访问日志，将这些用户访问日志按照服务提供方的不同进行划分，以得到各个服务提供方对应的用户访问日志，这其中便包括目标服务提供方的多个用户访问日志。

上述步骤102中根据目标服务提供方的配置信息对所述多个用户访问日志进行计算处理，得到目标日志文件，可以是：分别对多个用户访问日志进行字段拆分，根据目标服务提供方配置的字段格式信息对所述多个用户访问日志进行格式转换处理，另外，还可以按照设定的时间段，对这多个用户访问日志进行划分，得到每个时间段对应的目标日志文件，每个目标日志文件中包含相应时间段内产生的经过格式转换的用户访问日志。

可以理解的是，如果上述时间段的设置结果与边缘云节点的日志采集周期的设置结果相一致，那么针对当前获得的目标服务提供方的多个用户访问日志来说，最终便会生成一个目标日志文件。因此，根据日志文件对应的时间段的不同设置结果，边缘云节点可以得到与目标服务提供方对应的至少一个目标日志文件。

综上，在边缘云节点中，可以进行用户访问日志的字段拆分、格式转换、文件组织等计算处理。

边缘云节点在得到上述至少一个目标日志文件后，将该至少一个目标日志文件发送至目标中心云节点。为便于描述，下文中不区分目标日志文件的数量，统称为目标日志文件。

本实施例中的上述目标中心云节点，可以是图1中示意的中心云中包含的任一个节点。或者，可选地，目标中心云节点也可以是部署位置与目标服务提供方的位置信息匹配的中心云节点。举例来说，假设目标服务提供方的位置在城市x，而中心云中恰好存在部署在城市x的中心云节点，则针对该目标服务提供方来说，目标中心云节点即为部署在城市x的中心云节点。基于此，上述“匹配”可以理解为是：部署位置与目标服务提供方的所在位置最为接近的中心云节点，作为与目标服务提供方对应的目标中心云节点。实际应用中，可选地，针对某个目标服务提供方来说，该目标服务提供方也可以自主指定一个中心云节点作为与其对应的目标中心云节点。

实际应用中，由于目标服务提供方使用的边缘云节点的数量可能不止一个，当目标服务提供方使用了多个边缘云节点时，这多个边缘云节点都会执行上文中所说的用户访问日志计算处理，并将得到的日志文件上传到中心云。由于中心云中包括多个中心云节点，当多个边缘云节点上传各自得到的日志文件到不同的中心云节点时，不同的中心云节点之间需要彼此通信，以将同一目标服务提供方对应的多个日志文件集中到某一个中心云节点，以便于目标服务提供方从该中心云节点下载自己的日志文件。但是，目前各个中心云节点之间的数据通信成本较高，为了避免引入中心云节点之间的数据拷贝，在本发明实施例中，可以在多个边缘云节点上传过程中，将各自生成的对应于同一目标服务提供方的日志文件上传到同一中心云节点。此时，该中心云节点即可以是根据目标服务提供方的配置或根据目标服务提供方所处的位置与各中心云节点的部署位置之间的距离来确定的。

由此可知，上文中任一边缘云节点在生成与目标服务提供方对应的目标日志文件后，将该目标日志文件上传至同一中心云节点：目标中心云节点。当边缘云中还有其他边缘云节点生成与该目标服务提供方对应的目标日志文件时，同样上传到该目标中心云节点。

目标中心云节点在接收到至少一个边缘云节点上传的与目标服务提供方对应的目标日志文件后，将目标日志文件交付给目标服务提供方。实际应用中，目标服务提供方可以向中心云触发日志获取请求，中心云响应于该请求，控制上述目标中心云节点将目标服务提供方对应的目标日志文件发送给目标服务提供方。或者，目标中心云节点也可以主动将目标日志文件发送至目标服务提供方。

目标中心云节点在收到目标服务提供方对应的目标日志文件后，可以暂存该目标日志文件（如存储设定的时长），之后，便可以将目标日志文件交付给目标服务提供方，以避免对存储空间的长期占用。在暂存时间内，目标中心云节点可能还会收到边缘云节点上传的与目标服务提供方对应的目标日志文件，在暂存时长到达时，将已经存储的目标服务提供方对应的全部日志文件交付给目标服务提供方。另外，将目标服务提供方对应的目标日志文件交付给目标服务提供方后，还可以暂存该目标日志文件（如存储设定的时长），这样当目标日志文件此前传输过程中出现异常时，可以重新传输。之后，便可以将目标日志文件删除，以释放存储空间。

由上述介绍可知，在中心云的日志交付逻辑中，中心云侧会为边缘云节点提供数据存储服务，用于存储边缘云节点上传的日志文件。除此之外，在中心云侧执行的日志交付逻辑中，还会涉及到数据计算服务，该数据计算服务与边缘云侧对用户访问日志的拆分、重组的计算过程是不同的，该数据计算服务的核心目的是：为服务提供方提供可视化的数据分析能力。

概括来说，以目标服务提供方对应的目标日志文件为例，目标中心云节点在将目标日志文件提供给目标服务提供方的过程中，可以通过集成的数据分析服务对目标日志文件进行设定的数据分析处理，得到数据分析结果，将数据分析结果发送至目标服务提供方。除此之外，目标中心云节点也可以通过集成的数据分析服务生成与目标日志文件对应的操作表，将操作表发送至目标服务提供方，以供目标服务提供方根据操作表对目标日志文件进行数据分析处理，其中，操作表的各行对应于目标日志文件中的各个用户访问日志，操作表的各列对应于所述各个用户访问日志中的各字段。

实际应用中，上述数据分析服务比如可以是数据湖分析（datalakeanalytics，简称dla）服务。通过集成dla，目标中心云节点可以实现将存储在自身数据库（如oss）的数据（即目标日志文件）快速交付给目标服务提供方，并可以提供给目标服务提供方可视化的数据分析能力，赋能原始日志更多的分析可能。

实际上，在目标中心云节点返回给目标服务提供方其对应的目标日志文件时，不限于将原始的该目标日志文件提供给目标服务提供方。因为大部分服务提供方并不只是需要知道有这个日志文件，而是希望通过日志文件，借助分析系统去进行数据挖掘、分析。在本发明实施例中，可以为服务提供方提供与dla集成的数据分析服务，既可以提供通用的数据分析报告，也提供出可方便再分析的数据载体：dla服务中的操作表。

具体来说，数据分析服务中可以默认配置有多种数据分析功能，比如：终端用户位置分布、不同时间片段内的访问量、不同位置范围内的访问量等多种数据分析功能。针对目标服务提供方对应的目标日志文件来说，基于数据分析服务中具有的这些数据分析功能，对目标日志文件进行数据分析处理，得到对应的数据分析结果，将数据分析结果发送至目标服务提供方。其中，该数据分析结果可以以图表等可视化形式来表示。

由于目标服务提供方还可能有自己的数据分析需求，而该数据分析需求可能是上述数据分析服务中默认配置的数据分析功能所不具备的，此时，目标中心云节点还可以通过集成的数据分析服务生成与目标日志文件对应的操作表，将操作表发送至目标服务提供方。简单来说，该操作表就是目标日志文件的另一种表达方式，目标日志文件中包含文字记录的各条用户访问日志（经过格式转换后的用户访问日志），而操作表是一个表格，这个表格中n行对应于目标日志文件中包含的n个用户访问日志，每个用户访问日志中包括多个字段，这个表格中的各列即对应于各用户访问日志中包含的各个字段。

为便于理解，结合图3示例性说明。在图3中，假设目标日志文件中包括n个用户访问日志，每个用户访问日志中包括时间戳、用户ip地址、url等多个字段，基于该假设，可以生成图3中示意的表格。基于该表格目标服务提供方可以直观地看到各用户访问日志的字段取值情况。基于该表格，用户可以方便地触发一些数据分析操作，比如触发查询指令：时间戳=t1-t2，url=urli，即查询在t1-t2这个时间段内urli的用户访问量。数据分析服务可以响应该查询指令，输出对应的查询结果。

由此可见，中心云对用户访问日志的交付形式由之前的原始文件方式变为结构化形式（如各种数据分析报表、操作表），并为服务提供方提供数据分析服务，赋能服务提供方可以对操作表进行操作，方便服务提供方的数据分析行为。

综上，本发明实施例基于全网日志数据按照域名/服务提供方+时间维度组织数据并交付服务提供方这一事实，提出将日志交付过程中需要引入的复杂计算借助边缘云完成，轻量级的交付逻辑采用中心云来完成，通过边缘云与中心云相结合的方式，解决海量日志交付过程中对中心云资源的过渡占用的问题。

上文中提及目标服务提供方是满足特定条件的服务提供方，下面结合图4和图5示例性说明目标服务提供方的两种可选的确定方式。

图4为本发明实施例提供的一种日志处理方法的流程图，该日志处理方法可以由任一边缘云节点来执行。如图4所示，该方法可以包括如下步骤：

401、边缘云节点确定下载过对应的用户访问日志的服务提供方为目标服务提供方。

402、边缘云节点获取目标服务提供方的多个用户访问日志。

403、边缘云节点根据目标服务提供方的配置信息对多个用户访问日志进行计算处理，得到目标日志文件。

404、边缘云节点将目标日志文件发送至目标中心云节点，以使目标中心云节点将目标日志文件提供给目标服务提供方。

实际应用中，同一个边缘云节点上服务的服务提供方可能有几万个，每个服务提供方使用的域名数量也可能不止一个，如果每个服务提供方对应的全部用户访问日志都进行字段拆分、格式转换、按照域名/服务提供方和时间维度进行日志文件的组织的话，同一个边缘云节点每隔一定时间就会产生大量的日志文件，对于若干个边缘云节点来说，这些文件带来的碎片化是非常明显的，文件的碎片化会降低各环节的处理性能。

为此，本实施例提供了一种解决方案，其核心思路是：目前全网只有一部分服务提供方对于其用户访问日志是关心的，在边缘云节点处可以仅针对这些服务提供方进行用户访问日志的拆分、重组装、组织日志文件的计算处理，并将得到的日志文件回传中心云。这样一方面降低了日志数据回传中心云所占用的带宽资源，另一方面也降低了边缘云和中心云的处理压力。

实际应用中，比如某服务提供方仅关心自身提供服务的用户访问量，用户访问量的确定无需将用户访问日志回传到中心云进而交付给该服务提供方，因此，可以认为该服务提供方是不关心其用户访问日志的。

本实施例中，某服务提供方是否关心其用户访问日志，可以通过该服务提供方是否下载过自身的用户访问日志来判定。比如，某服务提供方曾经向某中心云节点触发过下载用户访问日志的请求，则中心云节点可以生成该服务提供方的下载记录，并将该服务提供方的标识通知各边缘云节点，从而各边缘云节点便得知下载过对应的用户访问日志的服务提供方都有哪些。边缘云节点确定下载过对应的用户访问日志的服务提供方为目标服务提供方，进而采集各目标服务提供方的用户访问日志并进行相关的计算处理。至于其他服务提供方的用户访问日志，可以长存在边缘云节点中，不回传到中心云，也就不会交付给对应的服务提供方。

边缘云节点对各目标服务提供方的用户访问日志的计算处理过程，参考前述其他实施例中的相关说明，在此不赘述。

图5为本发明实施例提供的一种日志处理方法的流程图，该日志处理方法可以由任一边缘云节点来执行。如图5所示，该方法可以包括如下步骤：

501、边缘云节点确定用户访问量满足设定条件的服务提供方为目标服务提供方。

502、边缘云节点获取目标服务提供方的多个用户访问日志，以及其他服务提供方的用户访问日志。

503、边缘云节点根据目标服务提供方的配置信息对目标服务提供方的多个用户访问日志进行计算处理，得到目标日志文件。

504、边缘云节点将目标日志文件发送至第一中心云节点，以使第一中心云节点将目标日志文件提供给目标服务提供方。

505、边缘云节点将所述其他服务提供方的用户访问日志发送至第二中心云节点，以使第二中心云节点根据所述其他服务提供方的配置信息分别对所述其他服务提供方的用户访问日志进行计算处理。

除了可以采用图4所示实施例提供的方案来缓解边缘云和中心云的处理压力外，本实施例还提供了另一种解决方案，其核心思路是：考虑随着越来越多的服务提供方关心自己的用户访问日志，将来便可能面临全网所有的服务提供方都开始关心自己的用户访问日志的情形。对于这种情况，结合实际的用户访问量分布情况（可能10%的服务提供方的用户访问日志占据了全网90%的数据体量），提出一种1/9策略，即针对用户访问量排在top10%的服务提供方（作为目标服务提供方）的用户访问日志在边缘云侧进行字段拆分、重组装、日志文件组织等计算处理，剩余的90%的服务提供方的用户访问日志不在边缘云进行上述计算处理。由于这90%的服务提供方的用户访问日志仅占全网数据量的10%左右，所以对中心云资源的消耗是比较小的，因此，可以将剩余的这90%的服务提供方的用户访问日志打包为一个日志文件，上传到中心云，由中心云进行相关计算处理。

可以理解的是，上述百分比的数值仅为举例，实际应用中，可以根据实际情况而灵活设定。

实际应用中，可以由中心云中任一中心云节点来统计各个服务提供方在设定历史时间内的用户访问量，并按照各服务提供方的用户访问量进行排名，以得到上述10%的服务提供方。

当然，可选地，也可以设定用户访问量阈值，如果统计出的某服务提供方的用户访问量大于该阈值，则认为该服务提供方是目标服务提供方，需要在边缘云完成对应用户访问日志的计算处理。

上述中心云节点基于统计结果得知哪些服务提供方作为目标服务提供方，将目标服务提供方告知各边缘云节点。

从而，针对任一边缘云节点来说，如果使用它的服务提供方中包含某目标服务提供方，则获取该目标服务提供方的用户访问日志，在本地进行相关计算处理，得到对应的目标日志文件，并上传第一中心云节点。该第一中心云节点即对应于前文中所述的目标中心云节点，即是上述目标服务提供方自主选择的一个中心云节点或者根据目标服务提供方所处的位置确定出的一个中心云节点。

至于剩余的其他服务提供方（非目标服务提供方），该边缘云节点可以将这些剩余的服务提供方的用户访问日志打包上传至第二中心云节点。第二中心云节点可以是中心云中的任一个节点，可能与第一中心云节点相同，也可能不同。

与边缘云对用户访问日志的计算处理过程相似，第二中心云节点也会根据这些其他服务提供方各自的配置信息分别对其各自对应的用户访问日志进行计算处理，得到与每个服务提供方对应的日志文件，进而将得到的日志文件交付给对应的服务提供方。

为了能够从宏观的视角来理解本发明实施例提供的日志处理方案，结合图6来示例性说明该日志处理方案的一种实际应用场景。

实际应用中，一个边缘云节点可以由多个计算设备构成，一个服务提供方提供的服务可以运行在一个边缘云节点中的一个或多个计算设备中，可以配置由边缘云节点中的某个计算设备来采集本边缘云节点中各计算设备中生成的用户访问日志。

在图6中，假设的是某个边缘云节点中的某个计算设备e采集到本边缘云节点中各个计算设备在某时间范围内生成的用户访问日志，表示为：scrolllog。另外，假设该计算设备e已经接收到各个服务提供方的配置信息，该配置信息可以包括：字段格式信息、中心云节点的选择信息，等等。另外，假设该计算设备e也收到了不同服务提供方的用户访问量的排名结果。

基于上述假设，计算设备e对于采集的任一服务提供方的用户访问日志，先根据上述用户访问量排名结果确定该服务提供方的用户访问日志是否需要在本地进行计算处理。若排名符合设定条件，则确定在本地进行计算处理，反之，不在本地进行计算处理。

在图6中，假设计算设备e确定服务提供方s1和服务提供方s2的用户访问日志需要在本地进行计算处理，那么在本地进行日志字段拆分、按照对应的字段格式信息进行字段格式转换，组织成日志文件等处理，分别得到与服务提供方s1对应的日志文件f1以及与服务提供方s2对应的日志文件f2。为节省存储空间，计算设备e可以对日志文件f1和日志文件f2压缩存储，存储格式可以自定义。

在图6中，假设计算设备e确定服务提供方s3和服务提供方s4的用户访问日志不需要在本地进行计算处理，那么将这两个服务提供方的用户访问日志合并在一个日志文件f3中，对日志文件f3压缩存储。

在图6中，假设中心云中包括图中示意的中心云节点c1、中心云节点c2、中心云节点c3，以及出于容灾目的，在每个中心云节点中都包括两个oss数据库，并且每个中心云节点中都集成有dla服务。另外，假设服务提供方s1选定的中心云节点为中心云节点c1，服务提供方s2选定的中心云节点为中心云节点c2，基于此，根据上述选择结果，计算设备e可以将日志文件f1发送至中心云节点c1，将日志文件f2发送至中心云节点c2，将日志文件f3发送至中心云节点c3，其中，假设中心云节点c3是基于随机选择或负载均衡确定的。

针对日志文件f1和日志文件f2，可以由相应中心云节点中集成的dla服务进行设定的数据分析处理以得到对应的数据分析结果，以及生成日志文件f1和日志文件f2各自对应的操作表，最终，中心云节点c1将日志文件f1对应的数据分析结果以及操作表发送至服务提供方s1，同理，中心云节点c2将日志文件f2对应的数据分析结果以及操作表发送至服务提供方s2。

针对日志文件f3，中心云节点c3解析得到其中包含的服务提供方s3的用户访问日志和服务提供方s4的用户访问日志。对于服务提供方s3的用户访问日志，在本地进行日志字段拆分、按照对应的字段格式信息进行字段格式转换，组织成日志文件等处理，得到与服务提供方s3对应的日志文件f4，进而由中心云节点c3中集成的dla服务对日志文件f4进行设定的数据分析处理以得到对应的数据分析结果，以及生成日志文件f4对应的操作表，最终，中心云节点c3将日志文件f4对应的数据分析结果以及操作表发送至服务提供方s3。同理，对服务提供方s3的用户访问日志进行相同的处理，得到与服务提供方s4对应的日志文件f5，由中心云节点c3中集成的dla服务对日志文件f5进行设定的数据分析处理以得到对应的数据分析结果，以及生成日志文件f5对应的操作表，最终，中心云节点c3将日志文件f4对应的数据分析结果以及操作表发送至服务提供方s4。

在图6中，假设上述四个服务提供方本地都采用oss数据库，那么各服务提供方将从对应中心云节点接收到的数据分析结果、操作表存储到各自对应的oss数据库中。

可以理解的是，中心云节点也可以将相应的日志文件发送至对应的服务提供方。

以下将详细描述本发明的一个或多个实施例的日志处理装置。本领域技术人员可以理解，这些装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图7为本发明实施例提供的一种日志处理装置的结构示意图，该装置位于边缘云节点，如图7所示，该装置包括：获取模块11、计算模块12、发送模块13。

获取模块11，用于确定使用所述边缘云节点的目标服务提供方，获取所述目标服务提供方的多个用户访问日志，所述目标服务提供方是需要在本地进行日志计算处理的服务提供方。

计算模块12，用于根据所述目标服务提供方的配置信息对所述多个用户访问日志进行计算处理，得到目标日志文件。

发送模块13，用于将所述目标日志文件发送至目标中心云节点，以由所述目标中心云节点将所述目标日志文件提供给所述目标服务提供方。

可选地，计算模块12具体可以用于：分别对所述多个用户访问日志进行字段拆分；根据所述目标服务提供方配置的字段格式信息对所述多个用户访问日志进行格式转换处理，得到包含转换后的多个用户访问日志的目标日志文件。

可选地，发送模块13具体可以用于：将所述目标日志文件发送至部署位置与所述目标服务提供方的位置信息匹配的目标中心云节点。

可选地，获取模块11具体可以用于：确定下载过对应的用户访问日志的服务提供方为所述目标服务提供方；或者，确定用户访问量满足设定条件的服务提供方为所述目标服务提供方。

可选地，发送模块13还可以用于：将用户访问量不满足所述设定条件的多个服务提供方的用户访问日志发送至中心云节点，以使所述中心云节点根据所述多个服务提供方的配置信息分别对所述多个服务提供方的用户访问日志进行计算处理。

图7所示装置可以执行前述实施例中边缘云节点执行的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图7所示日志处理装置的结构可实现为一计算设备，位于边缘云节点，如图8所示，该计算设备可以包括：第一处理器21、第一存储器22。其中，第一存储器22上存储有可执行代码，当所述可执行代码被第一处理器21执行时，使第一处理器21至少可以实现如前述实施例中边缘云节点执行的步骤。

可选地，该计算设备中还可以包括第一通信接口23，用于与其他设备进行通信。

图9为本发明实施例提供的一种日志处理装置的结构示意图，该装置位于中心云节点，如图9所示，该装置包括：接收模块31、处理模块32。

接收模块31，用于接收边缘云节点发送的与目标服务提供方对应的目标日志文件，所述目标日志文件由所述边缘云节点根据所述目标服务提供方的配置信息对所述目标服务提供方的多个用户访问日志进行计算处理得到，所述目标服务提供方是需要在所述边缘云节点进行日志计算处理的服务提供方。

处理模块32，用于将所述目标日志文件提供给所述目标服务提供方。

可选地，所述处理模块32具体可以用于：通过集成的数据分析服务对所述目标日志文件进行设定的数据分析处理，得到数据分析结果；将所述数据分析结果发送至所述目标服务提供方；和/或，通过所述数据分析服务生成与所述目标日志文件对应的操作表，将所述操作表发送至所述目标服务提供方，以供所述目标服务提供方根据所述操作表对所述目标日志文件进行数据分析处理，其中，所述操作表的各行对应于所述目标日志文件中的各个用户访问日志，所述操作表的各列对应于所述各个用户访问日志中的各字段。

图9所示装置可以执行前述实施例中中心云节点执行的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图9所示日志处理装置的结构可实现为一计算设备，位于中心云节点，如图10所示，该计算设备可以包括：第二处理器41、第二存储器42。其中，第二存储器42上存储有可执行代码，当所述可执行代码被第二处理器41执行时，使第二处理器41至少可以实现如前述实施例中中心云节点执行的步骤。

可选地，该计算设备中还可以包括第二通信接口43，用于与其他设备进行通信。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器至少可以实现如前述实施例中提供的日志处理方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、cd-rom、光学存储器等）上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。