CN112463527A - 一种数据处理方法、装置、设备、***及存储介质 - Google Patents

Abstract

本申请实施例提供一种数据处理方法、装置、设备、***及存储介质。在本申请实施例中，在业务端和计算端之间增加了日志管理设备，日志管理设备可获取业务端提供的日志数据；确定计算端所需的至少一个目标属性字段；从日志数据中提取并存储与至少一个目标属性字段匹配的至少一条日志记录，以供计算端访问至少一条日志记录，以进行数据计算。据此，本实施例中，业务端和计算端之间不再直接通信，这可有效减少对业务端的应用入侵；而且，日志管理设备可按照计算端的计算需求，对业务端提供的日志数据进行采集、整理及存储，可更便于计算端使用，从而降低计算端的数据采集复杂度。

Description

一种数据处理方法、装置、设备、***及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、设备、***及存储介质。

背景技术

目前，在进行特征计算平台的搭建过程中，通常会采用“flume+日志”或者“mysql+canel”等方式来进行日志数据采集。其中，flume为一种高可用的、高可靠的、分布式的海量日志采集、聚合和传输的***。Canel为一个开源项目，基于java实现，通过模拟成为mysql的slave的方式，监听mysql的binlog日志来获取数据。

在“mysql+canel”方式下，存在应用入侵的风险；而在“flume+日志”方式下，日志采集的复杂度过高，效率过低。

发明内容

本申请的多个方面提供一种数据处理方法、装置、设备及存储介质，用以降低数据采集的复杂度和/或减少数据采集过程中的应用入侵。

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

依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；

获取业务端提供的日志数据；

从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；

存储所述至少一条日志记录，以供所述第一计算端访问所述日志记录，以进行数据计算。

本申请实施例还提供一种日志管理装置，包括：

第一交互模块，用于依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；

第二交互模块，用于获取业务端提供的日志数据；

处理模块，用于从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录，以供所述第一计算端访问所述至少一条日志记录，以进行数据计算。

本申请实施例还提供一种计算设备，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个目标属性字段；

通过所述通信组件获取业务端提供的日志数据；

从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录，以供所述第一计算端访问所述至少一条日志记录，以进行数据计算。

本申请实施例还提供一种数据处理***，包括：业务端、日志管理设备和第一计算端，所述日志管理设备分别与所述业务端和所述第一计算端通信连接；

所述日志管理设备，用于依据所述第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；获取所述业务端提供的日志数据；从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录；

所第一计算端，用于从所述日志管理设备中访问所述第一计算端对应的至少一条日志记录，以进行数据计算。

本申请实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的数据处理方法。

在本申请实施例中，在业务端和计算端之间增加了日志管理设备，日志管理设备可获取业务端提供的日志数据；确定计算端所需的至少一个目标属性字段；从日志数据中提取并存储与至少一个目标属性字段匹配的至少一条日志记录，以供计算端访问至少一条日志记录，以进行数据计算。据此，本实施例中，业务端和计算端之间不再直接通信，这可有效减少对业务端的应用入侵；而且，日志管理设备可按照计算端的计算需求，对业务端提供的日志数据进行采集、整理及存储，可更便于计算端使用，从而降低计算端的数据采集复杂度。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的一种数据处理***的结构示意图；

图2为本申请一示例性实施例提供的一种应用场景的示意图；

图3为本申请一示例性实施例提供的一种数据处理方法的流程示意图；

图4为本申请一示例性实施例提供的一种日志管理装置的结构示意图；

图5为本申请一示例性实施例提供的一种计算设备的结构示意图。

具体实施方式

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

针对现有的日志数据采集方案存在的应用入侵风险高或采集复杂度过高等技术问题，本申请实施例的一些实施例中：在业务端和计算端之间增加了日志管理设备，日志管理设备可获取业务端提供的日志数据；确定计算端所需的至少一个目标属性字段；从日志数据中提取并存储与至少一个目标属性字段匹配的至少一条日志记录，以供计算端访问至少一条日志记录，以进行数据计算。据此，本实施例中，业务端和计算端之间不再直接通信，这可有效减少对业务端的应用入侵；而且，日志管理设备可按照计算端的计算需求，对业务端提供的日志数据进行采集、整理及存储，可更便于计算端使用，从而降低计算端的数据采集复杂度。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请一示例性实施例提供的一种数据处理***的结构示意图。如图1所示，该***包括：业务端10、日志管理设备20和第一计算端30。日志管理设备20分别与业务端10和第一计算端30通信连接。

本实施例提供的数据处理***可应用于各种需要依据日志数据进行数据计算的场景中，例如、特征计算场景等。本实施例对应用场景不做限定。

本实施例中，业务端10可以是个人终端、企业服务器或其它类型的处理端，本实施例对业务端10的类型不做限定。在物理实现上，业务端10可以是个人电脑、智能手机、平板电脑等计算设备，也可以是常规服务器、云服务器、云主机、虚拟中心等服务器设备。其中，服务器设备的构成主要包括处理器、硬盘、内存、***总线等，和通用的计算机架构类似。

实际应用中，数据处理***中可接入的业务端10的数量可以是一个或多个，图1中仅示例性地示出了一个业务端10，但这不应造成对本申请保护范围的损失。同样，数据处理***中的计算端的数量也可以是一个或多个，图1中仅示例性地示出了第一计算端30，但应当理解的是，数据处理***中还可包含第二计算端等其它计算端。

其中，业务端10中可配置日志记录功能，以生成日志数据。日志数据用于记录业务端10中发生的***事件或操作事件等。

本实施例中，日志管理设备20可获取业务端10提供的日志数据。其中，日志管理设备20可采用kafka的方式或者canel的方式从业务端10获取日志数据。其中，kafka为一种分布式发布订阅消息***，它可以处理业务端的所有动作流数据。在这种方式下，日志管理设备20可通过消费kafka消息的方式获取业务端10的日志数据。Canel为一个开源项目，基于java实现，通过模拟成为mysql的slave的方式，监听mysql的binlog日志来获取数据。在这种方式下，日志管理设备20可从业务端10对应的数据库中拉取日志数据。

当然，日志管理设备20还可采用其它实现方式从业务端10获取日志数据，比如，通过直接查询mysql获取相关数据。另外，对于业务端10来说，可仅向日志管理设备20开放日志访问权限即可。这可有效保证业务端10的应用安全，业务端10不再受到第一计算端30的应用入侵风险。

本实施例中，日志管理设备20可依据第一计算端30的第一计算需求，确定第一计算端30所需的至少一个目标属性字段。值得说明的是，不同计算端的计算需求可能不完全相同，而同一计算端的计算需求也可能随时间发生变化。

其中，第一计算端30可对外提供若干服务接口，实际应用中可以是API接口。不同服务接口对应的数据服务可不完全相同，相应地，不同数据服务所需的日志属性字段可能不完全相同。本实施例中，第一计算端30可分别为各服务接口执行数据计算，因此，第一计算端30在为不同服务接口执行数据计算时，所需的日志属性字段可能不完全相同。

基于此，本实施例中将以第一计算端30执行的任意一次数据计算为例进行技术方案的说明。

本实施例中，日志管理设备20可确定第一计算端30在本次数据计算过程中所需的至少一个日志属性字段，作为第一目标属性字段。例如，第一计算端30执行本次数据计算，需要“query”和“userID”这两个日志属性字段，则日志管理设备20可确定“query”和“userID”为第一计算端30所需的第一目标属性字段。实际应用中，第一计算端30可根据所需的日志属性字段生成反映计算需求的配置信息，并提供给日志管理设备20，以供日志管理设备20确定第一计算端30所需的至少一个第一目标属性字段，当然，本实施例并不限于此。

本实施例中，日志数据中通常包含若干条日志记录。本实施例中，日志管理设备20可从前述的日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录，并进行存储。实际应用中，日志管理设备20可以第一目标属性字段作为查找条件，从日志数据中查找包含第一目标属性字段的日志记录，并存储查找到的日志记录。日志记录中即包含至少一个第一目标属性字段对应的属性信息。当然，日志管理设备20还可从查找到的日志记录中摒弃至少一个第一目标属性字段之外的其它属性字段，例如，一条日志记录中包含30个字段，但其中仅有25个字段为第一目标属性字段，则可在该日志记录中仅保留25个第一目标属性字段及其对应的属性信息，而摒弃其它5个字段及字段值。当然，本实施例对此不做限定。

据此，第一计算端30可从日志管理设备20中访问至少一条日志记录，以进行数据计算。本实施例中，日志管理设备20可为第一计算端30配置对存储的至少一条日志记录的访问权限。实际应用中，日志管理设备20在接收到第一计算端30的访问请求时，可首先对第一计算端30进行权限验证，并在第一计算端30通过权限验证的情况下，允许第一计算端30访问至少一条日志记录，以便第一计算端30获取至少一个第一目标属性字段对应的属性信息。可选地，本实施例中，日志管理设备20可关闭第一计算端30对其对应的至少一条日志记录之外的其它类型日志的访问权限(包括日志文件及存储日志的数据库的访问权限)，这样通过配置日志记录的访问权限，可有效保证日志管理设备20中其它数据以及原始日志数据的安全性。

对第一计算端30来说，可通过flume等方式从日志管理设备20中抽取所需的日志记录。由于日志管理设备20中的日志记录是依据第一计算端30的计算需求所整理的，因此，可更便于第一计算端30直接取用。

在此基础上，第一计算端30可采用spark实时计算、spark stream、flink实时计算等方式进行数据计算，并将计算结果存放在hbase、es或mysql等位置。

本实施例中，在业务端10和第一计算端30之间增加了日志管理设备20，日志管理设备20可获取业务端10提供的日志数据；确定第一计算端30所需的至少一个第一目标属性字段；从日志数据中提取并存储与至少一个第一目标属性字段匹配的至少一条日志记录，以供第一计算端30访问至少一条日志记录，以进行数据计算。据此，本实施例中，业务端10和第一计算端30之间不再直接通信，这可有效减少对业务端10的应用入侵；而且，日志管理设备20可按照第一计算端30的计算需求，对业务端10提供的日志数据进行采集、整理及存储，可更便于第一计算端30使用，从而降低第一计算端30的数据采集复杂度。

在上述或下述实施例中，日志管理设备20可从日志数据中分离出业务操作日志，业务操作日志中包含业务操作类的日志记录；从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录。

本实施例中，日志管理设备20可对业务端10提供的日志数据进行整理。并从中分离出业务操作日志。

实际应用中，可以通过对日志数据中特殊字段值的差异、特别标识等来区分业务操作日志和业务***日志，例如日志管理设备20可基于业务操作日志的标识和业务***日志的标识从日志数据中区分出业务操作日志和业务***日志。其中，业务操作日志中包含与业务操作相关的日志记录；而业务***日志中包含与***处理相关的日志记录。

据此，本实施例中，可将与业务操作相关的日志记录和与***处理相关的日志记录物理分开，两组日志记录相互独立，互不影响。

基于此，本实施例中，日志管理设备20可仅对第一计算端30开放针对业务操作日志的访问权限，而关闭第一计算端30对业务***日志的访问权限，从而避免无关数据泄露的风险。

本实施例中，还可对业务操作日志进行进一步整理，从业务操作日志中提取包含部分或全部第一目标属性字段的至少一条日志记录。这样，可逐步地从全量的日志数据中，精确地提取出与至少一个第一目标属性字段匹配的至少一条日志记录。

在此基础上，可按照指定的日志格式，对至少一条日志记录各自包含的第一目标属性字段对应的属性信息进行结构化整理，以生成并存储整理后日志。

其中，指定的日志格式可以是日志管理设备20与第一计算端30约定的日志格式，以便第一计算端30按照约定的日志格式访问日志管理设备20中存储的整理后日志。指定的日志格式可以是json格式或者xml格式。

一种示例性的日志格式样例可以是：

{"logname":"query","logtime":"2020-07-14 17:25:20","project_name":

"recruit_feature","query":"完美购","user_id":192507}。

其中，logname、logtime、project_name为第一计算端30所需的第一目标属性字段。logname:query代表的是用户搜索行为，project_name:recruit_feature代表的是业务线名称，query:“完美购”则代表的是用户搜索的文本信息。

基于此，日志管理设备20可按指定的日志格式存储至少一个第一目标属性字段对应的属性信息。通过对日志记录的格式转换，可更加便于第一计算端30使用至少一个第一目标属性字段对应的属性信息，降低数据采集复杂度。

这种情况下，本实施例中，日志管理设备20可仅对第一计算端30开放针对其对应的整理后日志的访问权限，而关闭第一计算端30对其它类型日志的访问权限。同样，日志管理设备20也可对于其它计算端开放对应的整理后日志的访问权限，而关闭对其它类型日志的访问权限。从而，避免无关数据泄露的风险。

另外，本实施例中，日志管理设备20还可依据其它计算端的计算需求，分别为其它计算端生成对应的整理后日志。并且，还可构建计算端与整理后日志之间的访问关系，为各计算端配置针对整理后端日志的不同访问权限，以对不同计算端的整理后日志进行隔离，提高数据安全性。这样，在前文中对第一计算端30进行权限验证的过程中，可从至少访问关系及访问的日志类型两个维度进行权限验证。

本实施例中，日志管理设备20所整理出的整理后日志中包含的属性字段可与第一计算端30的计算需求保持同步。若日志管理设备20确定第一计算端30所需的至少一个第一目标属性字段出现增减，则对整理后日志中的属性字段进行同步增减。实际应用中，第一计算端30可在需要增减属性字段的情况下，向日志管理设备20发送第二计算需求，并在第二计算需求中携带需要增减的属性字段或至少一个第二目标属性字段。对日志管理设备20来说，若至少一个第二目标属性字段与至少一个第一目标属性字段不一致，则可以以至少一个第二目标属性字段更新至少一个第一目标属性字段；或者，可按照第二计算需求中携带的需要增减的属性字段更新至少一个第一目标属性字段。之后，可按照更新后的至少一个第一目标属性字段进行后续的日志记录提取及结构化整理等过程，以获得准确的整理后日志。

例如，整理后日志原格式为{"name":"张三","age":"20"}，如果第一计算端30希望再收集用户的性别，则可在整理后日志中增加对应的属性字段，整理后日志的格式变为：{"name":"张三","age":"20","gender":"男"}。

这使得日志管理设备20以第一计算端30的实际计算需求为依据，执行日志数据采集、整理和存储等操作，而在第一计算端30的计算需求发生变化时，日志管理设备20也同步地及时对日志数据采集、整理和存储等操作做出适应性调整，而整个数据处理***的架构无需变化，更无需重新搭建。因此，数据处理***可快速响应不同数据服务，且可无缝支持新增的数据服务。

在上述或下述实施例中，日志管理设备20还可在获取业务端提供的日志数据之前，将第一计算端30所需的至少一个第一目标属性字段发送给业务端，以供业务端采集至少包含至少一个第一目标属性字段的日志数据。

而在一些对数据收集和传输要求更加严格的情况下，日志管理设备20还可确定第一计算端30在至少一个第一目标属性字段下指定的需求范围，需求范围用于限定属性信息的取值范围；将至少一个第一目标属性字段和需求范围发送到业务端10，以供业务端10采集至少包含至少一个第一目标属性字段下指定的需求范围的日志数据。

其中，第一计算端30可为至少一个第一目标属性字段中的部分或全部指定需求范围。例如，第一计算端30可为第一目标属性字段logtime指定需求范围30天内，可为第一目标属性字段user_id指定需求范围1234-1456等。

日志管理设备20可将这些指定的需求范围配置到业务端10，而对业务端10来说，则可根据这些指定的需求范围采集日志数据。例如，承接上例，业务端10可采集30天内用户1234-1456对应的日志数据，并提供给日志管理设备20，当然，业务端10还可同时采集其它日志数据，本实施例对此不做限定。

据此，本实施例中，日志管理设备20可将第一计算端30指定的需求范围同步至业务端10，这使得业务端10可按第一计算端30的需求范围进行日志数据的收集，这可满足对数据收集和传输要求严格的场景要求，确保其他数据的安全性并使得日志数据的处理过程更加精简。

图2为本申请一示例性实施例提供的一种应用场景的示意图。参考图2，以下结合应用场景进行技术方案的说明。

日志管理设备20可通过消费kafka消息或主动从业务端10的mysql中拉取数据的方式，获取业务端10提供的日志数据，并将获取到的日志数据区分为业务操作日志和业务***日志。之后，从业务操作日志中查找包含字段A、B、C、D和E中部分或全部字段的日志记录。

参考图2，日志管理设备可按照json格式，对查找到的日志记录中包含的字段A、B、C、D和E对应的字段值进行整理，以生成json格式的整理后日志，图2中示为json日志，并对计算端开放json日志的访问权限，而对计算端关闭业务***日志的访问权限。

计算端可通过flume的方式从日志管理设备中抽取json日志。计算端可根据json日志的logname字段下的取值，确定不同日志记录对应的操作行为。并根据选择与操作行为匹配的数据计算方式。

对于逻辑复杂的计算，可以通过flink(实时)、spark(离线)去完成。比如：query代表用户搜索行为，计算端可将这类日志记录简单解析为结构化的数据，并存储在对应的hive表中，以供后续计算使用。日志记录{“name”:”张三”，”age”:20}，在hive中可存储为一个表，name列中存放“张三”，age列中存放“20”。

需要实时计算的，可通过flink计算出结果后存放在hbase。

逻辑简单的可以通过spark sql或flink sql去完成。如对用户搜索行为计算tf-idf，其中，tf需要实时，idf可以允许延时(T+1)。对此，tf的计算可通过flink完成，计算过程包括分词、计算词频、将计算结果存放hbase；idf的计算可通过spark完成。

计算端可提供API接口，API接口可对外提供http或者rpc服务，不同数据服务要求的属性字段下的需求范围可不完全相同。参考图2，日志管理设备可以元信息的方式将不同数据服务要求的属性字段下的需求范围配置到业务端中，这样，业务端可按需生成日志数据。其中，需求范围可包括但不限于日期范围、特定功能对象范围、用户范围等。

数据服务可从计算端的hbase或者es中提取计算结果，计算结果都是计算端预先计算好的，在数据量较大时也能保证查询性能。比如获取用户查询信息30天内的tf-idf，hbase中rowkey设计为：日期+[tf|idf]+用户id+分词关键词，查询时根据日期+用户id的前缀便可以快速的查询到数据了，rowkey除去前缀便是分词后的关键字，相关qualifier对应的便是词频数了。比如tf相关数据，rowkey为“2020-07-24_tf_1234_完美”，qualifier是INFO:day30为3，表示id为1234的用户在近30天内搜索包含‘完美’的有3次。

一种示例性的存放tf和idf的hbase表结构为：

据此，通过日志管理设备为计算端准备所需的日志记录的方式，可有效减少了对业务端的应用侵入，同时也减少了潜在的风险，因为业务端通常会使用第三方的云平台，如果开放数据库访问权限来实现日志数据同步虽然可行但存在风险。

将日志数据转换为指定的日志格式以及按照计算端的计算需求进行日志数据的筛选处理，能够便于计算平台的利用；

依赖现有计算端可以快速响应需求，而数据处理***架构不需要多大变化。***整体结构比较简单，容易搭建。

图3为本申请一实施例提供的一种数据处理方法的流程示意图。参考图3，该方法包括：

步骤300、依据第一计算端的第一计算需求，确定第一计算端所需的至少一个第一目标属性字段；

步骤301、获取业务端提供的日志数据；

步骤302、从日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录；

步骤303、存储至少一条日志记录，以供第一计算端访问日志记录，以进行数据计算。

在步骤300中，可依据第一计算端的第一计算需求，确定第一计算端所需的至少一个第一目标属性字段。

其中，第一计算端可对外提供若干服务接口，实际应用中可以是API接口。不同服务接口对应的数据服务可不完全相同，相应地，不同数据服务所需的日志属性字段可能不完全相同。本实施例中，第一计算端可分别为各服务接口执行数据计算，因此，第一计算端在为不同服务接口执行数据计算时，所需的日志属性字段可能不完全相同。

基于此，本实施例中将以第一计算端执行的任意一次数据计算为例进行技术方案的说明。

本实施例中，可确定第一计算端在本次数据计算过程中所需的至少一个日志属性字段，作为第一目标属性字段。例如，第一计算端执行本次数据计算，需要“query”和“userID”这两个日志属性字段，则本实施例中，可确定第一计算端所需的第一目标属性字段为“query”和“userID”。实际应用中，第一计算端可根据所需的日志属性字段生成配置信息，本实施例中，可获取配置信息，从而确定第一计算端所需的至少一个第一目标属性字段，当然，本实施例并不限于此。

本实施例中，步骤301中，可获取业务端提供的日志数据。其中，可采用kafka的方式或者canel的方式从业务端获取日志数据。其中，kafka为一种分布式发布订阅消息***，它可以处理业务端的所有动作流数据。在这种方式下，日志管理设备可通过消费kafka消息的方式获取业务端的日志数据。Canel为一个开源项目，基于java实现，通过模拟成为mysql的slave的方式，监听mysql的binlog日志来获取数据。在这种方式下，可从业务端对应的数据库中拉取日志数据。

当然，还可采用其它实现方式从业务端获取日志数据，比如，通过直接查询mysql获取相关数据。另外，对于业务端来说，可仅向日志管理设备开放日志访问权限即可。这可有效保证业务端的应用安全，业务端不再受到第一计算端的应用入侵风险。

本实施例中，日志数据中通常包含若干条日志记录。本实施例中，可从前述的日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录，并进行存储。实际应用中，可以第一目标属性字段作为查找条件，从日志数据中查找包含第一目标属性字段的日志记录，并存储查找到的日志记录。日志记录中即包含至少一个第一目标属性字段对应的属性信息。当然，还可从查找到的日志记录中摒弃至少一个第一目标属性字段之外的其它属性字段，例如，一条日志记录中包含30个字段，但其中仅有25个字段为第一目标属性字段，则可在该日志记录中仅保留25个第一目标属性字段及其对应的属性信息，而摒弃其它5个字段及字段值。当然，本实施例对此不做限定。

据此，第一计算端可访问至少一条日志记录，以进行数据计算。

本实施例中，还可为第一计算端配置对存储的至少一条日志记录的访问权限。实际应用中，在接收到第一计算端的访问请求时，可首先对第一计算端进行权限验证，并在第一计算端通过权限验证的情况下，允许第一计算端访问至少一条日志记录，以便第一计算端获取至少一个第一目标属性字段对应的属性信息。可选地，本实施例中，可关闭第一计算端30对其对应的至少一条日志记录之外的其它类型日志的访问权限，这样通过配置日志记录的访问权限，可有效保证其它数据的安全性。

对第一计算端来说，可通过flume等方式抽取所需的日志记录。由于本实施例中的日志记录是依据第一计算端的计算需求所整理的，因此，可更便于第一计算端直接取用。

在此基础上，第一计算端可采用spark实时计算、spark stream、flink实时计算等方式进行数据计算，并将计算结果存放在hbase、es或mysql等位置。

本实施例中，可获取业务端提供的日志数据；确定第一计算端所需的至少一个第一目标属性字段；从日志数据中提取并存储与至少一个第一目标属性字段匹配的至少一条日志记录，以供第一计算端访问至少一条日志记录，以进行数据计算。据此，本实施例中，业务端和第一计算端之间不再直接通信，这可有效减少对业务端的应用入侵；而且，可按照第一计算端的计算需求，对业务端提供的日志数据进行采集、整理及存储，可更便于第一计算端使用，从而降低第一计算端的数据采集复杂度。

在上述或下述实施例中，可从日志数据中分离出业务操作日志，业务操作日志中包含业务操作类的日志记录；从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录。

本实施例中，可对业务端提供的日志数据进行整理。并从中分离出业务操作日志。

实际应用中，可基于业务操作日志的标识和业务***日志的标识从日志数据中区分出业务操作日志和业务***日志。其中，业务操作日志中包含与业务操作相关的日志记录；而业务***日志中包含与***处理相关的日志记录。

据此，本实施例中，可将与业务操作相关的日志记录和与***处理相关的日志记录物理分开，两组日志记录相互独立，互不影响。

基于此，本实施例中，可仅对第一计算端开放针对业务操作日志的访问权限，而关闭第一计算端对业务***日志的访问权限，从而避免无关数据泄露的风险。

本实施例中，还可对业务操作日志进行进一步整理，从业务操作日志中提取包含部分或全部第一目标属性字段的至少一条日志记录。这样，可逐步地从全量的日志数据中，精确地提取出与至少一个第一目标属性字段匹配的至少一条日志记录。

在此基础上，可按照指定的日志格式，对至少一条日志记录各自包含的第一目标属性字段对应的属性信息进行结构化整理，以生成并存储整理后日志。

其中，指定的日志格式可以是日志管理设备与第一计算端约定的日志格式，以便第一计算端按照约定的日志格式访问日志管理设备中存储的整理后日志。指定的日志格式可以是json格式或者xml格式。

本实施例中，可按指定的日志格式存储至少一个第一目标属性字段对应的属性信息。通过对日志记录的格式转换，可更加便于第一计算端使用至少一个第一目标属性字段对应的属性信息，降低数据采集复杂度。

这种情况下，本实施例中，可仅对第一计算端开放针对其对应的整理后日志的访问权限，而关闭第一计算端对其它类型日志的访问权限。同样，也可对于其它计算端开放对应的整理后日志的访问权限，而关闭对其它类型日志的访问权限。从而，避免无关数据泄露的风险。

另外，本实施例中，还可依据其它计算端的计算需求，分别为其它计算端生成对应的整理后日志。并且，还可构建计算端与整理后日志之间的访问关系，以对不同计算端的整理后日志进行隔离，提高数据安全性。这样，在前文中对第一计算端进行权限验证的过程中，可从至少访问关系及访问的日志类型(日志对象)两个维度进行权限验证。

本实施例中，整理出的整理后日志中包含的属性字段可与第一计算端的计算需求保持同步。若确定第一计算端所需的至少一个第一目标属性字段出现增减，则对整理后日志中的属性字段进行同步增减。实际应用中，第一计算端可在需要增减属性字段的情况下，发起第二计算需求，并在第二计算需求中携带需要增减的属性字段或至少一个第二目标属性字段。这样，本实施例中，若至少一个第二目标属性字段与至少一个第一目标属性字段不一致，则可以以至少一个第二目标属性字段更新至少一个第一目标属性字段；或者，可按照第二计算需求中携带的需要增减的属性字段更新至少一个第一目标属性字段。之后，可按照更新后的至少一个第一目标属性字段进行后续的日志记录提取及结构化整理等过程，以获得准确的整理后日志。

这使得可以第一计算端的实际计算需求为依据，执行日志数据采集、整理和存储等操作，而在第一计算端的计算需求发生变化时，也可同步地及时对日志数据采集、整理和存储等操作做出适应性调整，而整个数据处理***的架构无需变化，更无需重新搭建。因此，数据处理***可快速响应不同数据服务，且可无缝支持新增的数据服务。

在上述或下述实施例中，可在获取业务端提供的日志数据之前，将第一计算端所需的至少一个第一目标属性字段发送给业务端，以供业务端采集至少包含至少一个第一目标属性字段的日志数据。

而在一些对数据收集和传输要求更加严格的情况下，还可确定第一计算端在至少一个第一目标属性字段下指定的需求范围，需求范围用于限定属性信息的取值范围；将至少一个第一目标属性字段和需求范围发送到业务端，以供业务端采集至少包含至少一个第一目标属性字段下指定的需求范围的日志数据。

其中，第一计算端可为至少一个第一目标属性字段中的部分或全部，指定需求范围。例如，第一计算端可为第一目标属性字段logtime指定需求范围30天内，可为第一目标属性字段user_id指定需求范围1234-1456等。

本实施例中，可将这些指定的需求范围配置到业务端，而对业务端来说，则可根据这些指定的需求范围采集日志数据。例如，承接上例，业务端可收集30天内用户1234-1456对应的日志数据，当然，业务端还可采集其它日志数据，本实施例对此不做限定。

据此，本实施例中，可将第一计算端指定的需求范围同步至业务端，这使得业务端可按第一计算端的需求范围进行日志数据的收集，这可满足对数据收集和传输要求严格的场景要求，使得日志数据的处理过程更加精简。

值得说明的是，上述关于数据处理方法相关实施例中的技术细节，可参考前述数据处理***各实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤301至步骤303的执行主体可以为设备A；又比如，步骤301和302的执行主体可以为设备A，步骤303的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如301、302等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

上述实施例提供的数据处理方法可以由一日志管理装置来执行。图4为本申请一示例性实施例提供的一种日志管理装置的结构示意图，参考图4，该日志管理装置可包括：第一交互模块40、第二交互模块41和处理模块42。

第一交互模块40，用于依据第一计算端的第一计算需求，确定第一计算端所需的至少一个第一目标属性字段；

第二交互模块41，用于获取业务端提供的日志数据；

处理模块42，用于从日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录；存储至少一条日志记录，以供第一计算端访问至少一条日志记录，以进行数据计算.

在一可选实施例中，处理模块42在从日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录时，用于：从日志数据中分离出业务操作日志，业务操作日志中包含业务操作类的日志记录；从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录。

在一可选实施例中，处理模块42从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录时，用于：从业务操作日志中提取包含部分或全部第一目标属性字段的至少一条日志记录；按照指定的日志格式，对至少一条日志记录各自包含的第一目标属性字段对应的属性信息进行结构化整理，以生成整理后日志。

在一可选实施例中，日志格式采用json格式或xml格式。

在一可选实施例中，处理模块42还用于：依据第一计算端的第二计算需求，确定第一计算端所需至少一个第二目标属性字段；若至少一个第二目标属性字段与至少一个第一目标属性字段不一致，则以至少一个第二目标属性字段更新至少一个第一目标属性字段。

在一可选实施例中，处理模块42还用于：依据其它计算端的计算需求，分别为其它计算端生成对应的整理后日志；构建计算端与整理后日志之间的访问关系，以供第一计算端通过访问其对应的整理后日志而获取符合其计算需求的属性信息。

在一可选实施例中，处理器42还用于：关闭第一计算端及其它计算端对整理后日志之外的其它类型日志的访问权限。

在一可选实施例中，第一交互模块40在获取业务端提供的日志数据时，用于：消费业务端提供的kafka消息，以获得日志数据；或者，从业务端对应的数据库中拉取日志数据。

在一可选实施例中，处理模块42在获取业务端提供的日志数据之前，还用于：依据第一计算需求，确定第一计算端在至少一个第一目标属性字段下指定的需求范围，需求范围用于限定属性信息的取值范围；将至少一个目标属性字段和需求范围发送到业务端，以供业务端采集至少包含至少一个第一目标属性字段下指定的需求范围的日志数据。

值得说明的是，上述关于日志管理装置相关实施例中的技术细节，可参考前述数据处理***各实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

上述实施例中的日志管理装置可以实现为软件或实现为软件和硬件的组合，该日志管理装置可集成设置在计算设备中。图5为本申请一示例性实施例提供的一种计算设备的结构示意图。如图5所示，该计算设备包括：存储器50、处理器51以及通信组件52。

存储器50，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器50可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器51，与存储器50和通信组件52耦合，用于执行存储器50中的计算机程序，以用于：依据第一计算端的第一计算需求，确定第一计算端所需的至少一个目标属性字段；通过通信组件52获取业务端提供的日志数据；从日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录；存储至少一条日志记录，以供第一计算端访问至少一条日志记录，以进行数据计算。

在一可选实施例中，处理器51在从日志数据中提取与至少一个第一目标属性字段匹配的至少一条日志记录时，用于：从日志数据中分离出业务操作日志，业务操作日志中包含业务操作类的日志记录；从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录。

在一可选实施例中，处理器51从业务操作日志中提取与至少一个第一目标属性字段匹配的至少一条日志记录时，用于：从业务操作日志中提取包含部分或全部第一目标属性字段的至少一条日志记录；按照指定的日志格式，对至少一条日志记录各自包含的第一目标属性字段对应的属性信息进行结构化整理，以生成整理后日志。

在一可选实施例中，日志格式采用json格式或xml格式。

在一可选实施例中，处理器51还用于：依据第一计算端的第二计算需求，确定第一计算端所需至少一个第二目标属性字段；若至少一个第二目标属性字段与至少一个第一目标属性字段不一致，则以至少一个第二目标属性字段更新至少一个第一目标属性字段。

在一可选实施例中，处理器51还用于：依据其它计算端的计算需求，分别为其它计算端生成对应的整理后日志；构建计算端与整理后日志之间的访问关系，以供第一计算端通过访问其对应的整理后日志而获取符合其计算需求的属性信息。

在一可选实施例中，处理器51还用于：关闭第一计算端及其它计算端对整理后日志之外的其它类型日志的访问权限。

在一可选实施例中，处理器51在获取业务端提供的日志数据时，用于：消费业务端提供的kafka消息，以获得日志数据；或者，从业务端对应的数据库中拉取日志数据。

在一可选实施例中，处理器51在获取业务端提供的日志数据之前，还用于括：依据第一计算需求，确定第一计算端在至少一个第一目标属性字段下指定的需求范围，需求范围用于限定属性信息的取值范围；将至少一个目标属性字段和需求范围发送到业务端，以供业务端采集至少包含至少一个第一目标属性字段下指定的需求范围的日志数据。

值得说明的是，上述关于计算设备相关实施例中的技术细节，可参考前述数据处理***各实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

进一步，如图5所示，该计算设备还包括：电源组件53等其它组件。图5中仅示意性给出部分组件，并不意味着计算设备只包括图5所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由计算设备执行的各步骤。

上述图5中的通信组件，被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理***的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

上述图5中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理***，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种数据处理方法，其特征在于，包括：

依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；

获取业务端提供的日志数据；

从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；

存储所述至少一条日志记录，以供所述第一计算端访问所述日志记录，以进行数据计算。

2.根据权利要求1所述的方法，其特征在于，所述从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录，包括：

从所述日志数据中分离出业务操作日志，所述业务操作日志中包含业务操作类的日志记录；

从所述业务操作日志中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录。

3.根据权利要求2所述的方法，其特征在于，所述从所述业务操作日志中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录，包括：

从所述业务操作日志中提取包含部分或全部第一目标属性字段的至少一条日志记录；

按照指定的日志格式，对所述至少一条日志记录各自包含的第一目标属性字段对应的属性信息进行结构化整理，以生成整理后日志。

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

依据所述第一计算端的第二计算需求，确定所述第一计算端所需至少一个第二目标属性字段；

若所述至少一个第二目标属性字段与所述至少一个第一目标属性字段不一致，则以所述至少一个第二目标属性字段更新所述至少一个第一目标属性字段。

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

依据其它计算端的计算需求，分别为其它计算端生成对应的整理后日志；

构建计算端与整理后日志之间的访问关系，以供所述第一计算端通过访问其对应的整理后日志而获取符合其计算需求的属性信息。

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

关闭所述第一计算端及所述其它计算端对所述整理后日志之外的其它类型日志的访问权限。

7.根据权利要求1所述的方法，其特征在于，获取业务端提供的日志数据之前，还包括：

依据所述第一计算需求，确定所述第一计算端在所述至少一个第一目标属性字段下指定的需求范围，所述需求范围用于限定属性信息的取值范围；

将所述至少一个目标属性字段和所述需求范围发送到所述业务端，以供所述业务端采集至少包含所述至少一个第一目标属性字段下指定的所述需求范围的日志数据。

8.一种日志管理装置，其特征在于，包括：

第一交互模块，用于依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；

第二交互模块，用于获取业务端提供的日志数据；

处理模块，用于从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录，以供所述第一计算端访问所述至少一条日志记录，以进行数据计算。

9.一种计算设备，其特征在于，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

依据第一计算端的第一计算需求，确定所述第一计算端所需的至少一个目标属性字段；

通过所述通信组件获取业务端提供的日志数据；

从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录，以供所述第一计算端访问所述至少一条日志记录，以进行数据计算。

10.一种数据处理***，其特征在于，包括：业务端、日志管理设备和第一计算端，所述日志管理设备分别与所述业务端和所述第一计算端通信连接；

所述日志管理设备，用于依据所述第一计算端的第一计算需求，确定所述第一计算端所需的至少一个第一目标属性字段；获取所述业务端提供的日志数据；从所述日志数据中提取与所述至少一个第一目标属性字段匹配的至少一条日志记录；存储所述至少一条日志记录；

所第一计算端，用于从所述日志管理设备中访问所述第一计算端对应的至少一条日志记录，以进行数据计算。

11.一种存储计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求1-7任一项所述的数据处理方法。

Images