一种数据梳理方法及装置与流程

本申请涉及计算机技术领域，特别涉及一种数据梳理方法及装置、一种计算设备及存储介质。

背景技术：

一个业务系统经过长时间的发展后，系统中会存在各种不利用维护的因素，通常我们称这些因素为具有高度业务语义的因素。这些因素存在隐晦性、复杂性、不统一性以及弱管控性等特性。

以上几个特性随着业务系统发展逐渐庞大臃肿，随着数据量的增长，业务数据会变得更加难于梳理。

技术实现要素：

有鉴于此，本申请实施例提供了一种数据梳理方法及装置、一种计算设备及存储介质，以解决现有技术中存在的技术缺陷。

本申请实施例公开了一种数据梳理方法，包括：

为所述业务系统配置至少一个数据采集组件；

通过所述至少一个数据采集组件采集所述业务系统运行时数据；

将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

另一方面，本申请还提供了一种业务系统数据梳理装置，包括：

配置模块，被配置为为所述业务系统配置至少一个数据采集组件；

采集模块，被配置为通过所述至少一个数据采集组件采集所述业务系统运行时数据；

梳理模块，被配置为将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

另一方面，本申请还提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述数据梳理方法的步骤。

另一方面，本申请还提供了一种计算机可读存储介质，其存储有计算机指令，该程序被处理器执行时实现所述数据梳理方法的步骤。

本申请提供的一种数据梳理方法及装置、一种计算设备及存储介质，其中，所述方法包括为所述业务系统配置至少一个数据采集组件；通过所述至少一个数据采集组件采集所述业务系统运行时数据；将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

附图说明

图1为本说明书一个或多个实施例提供的一种数据梳理方法所应用的系统架构的示意图；

图2为本说明书一个或多个实施例提供的一种数据梳理方法的流程图；

图3为本说明书一个或多个实施例提供的一种数据梳理方法的流程图；

图4为本说明书一个或多个实施例提供的采用预设的梳理规则对运行时数据进行梳理的示意图；

图5为本说明书一个或多个实施例提供的梳理的目标数据的数据量的趋势示意图；

图6为本说明书一个或多个实施例提供的一种数据梳理方法的流程图；

图7为本说明书一个或多个实施例提供的一种数据梳理方法的流程图；

图8为本说明书一个或多个实施例提供的一种数据梳理装置的结构示意图；

图9为本说明书一个或多个实施例提供的一种计算设备的结构框图。

具体实施方式

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

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

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

在本说明书一个或多个实施例中，提供了一种数据梳理方法及装置、计算设备和计算机存储介质，在下面的实施例中逐一进行详细说明。

首先，对于本说明书一个或多个实施例中涉及的术语进行说明。

静态：指在系统未运行的情况下，对系统进行一些动作。

动态：指在系统运行时，利用运行时信息对系统进行一些动作。

嵌入：将一个子系统接入一个大系统中。

领域模型：是对领域内的概念类或现实世界中对象的可视化表示。

具有高度业务语义的因素：所述因素常常不能在代码层面体现出来，一般是开发过程中和上下游的约定。在支付宝系统中，所述因素比较常见，例如支付宝引擎调用下游时，下游支付工具返回的指令类型，通常就是开发前相关人员根据业务场景进行约定的。

参见图1，本说明书一个实施例提供了一种数据梳理方法所应用的系统架构的示意图，包括业务系统102、旁路系统104、数据库106和数据采集组件108。

所述旁路系统104为所述业务系统102提供若干数据采集组件108，所述数据采集组件108设置在所述业务系统102的内部链路的节点上，采集所述业务系统102运行时数据；所述旁路系统104接收采集的所述运行时数据，按照预设的梳理规则对所述运行时数据进行梳理，得到梳理后的目标数据；所述旁路系统104将梳理后的所述目标数据整理后，存储至所述数据库106。

参见图2，本说明书一个或多个实施例提供了一种数据梳理方法，包括步骤202至步骤206。

步骤202：为所述业务系统配置至少一个数据采集组件。

本说明书一个或多个实施例中，所述业务系统可以包括但不限于淘宝订单业务处理系统或者支付宝退款业务处理系统等，根据实际应用进行设定，本申请对此不作任何限定。

为所述业务系统配置至少一个数据采集组件，即将一个、两个或多个所述数据采集组件接入所述业务系统的内部链路上，使得所述数据采集组件在所述内部链路的关键变化点上进行采集。配置所述数据采集组件的多少以及位置根据所述业务系统进行具体设定，本申请对此不作任何限定。

所述业务系统的关键变化点与所述业务系统的内部链路息息相关，例如未加工的单据在所述业务系统的内部链路运行过程中一直发生变化，有些变化点比较重要，有些变化点不重要，那么比较重要的变化点就可以是关键变化点，也可以理解为所述未加工的单据信息在所述业务系统的运行过程中一步步的补全，当信息补全达到一定程度时，该点就是比较重要的变化点即关键变化点。

所述数据采集组件就可以配置在所述业务系统的内部链路的该关键变化点上。

另外，实际应用中，所述关键变化点还可以设置在一笔支付的资金准备完成时的位置或者是一笔退款的金额分配工作完成时的位置。

步骤204：通过所述至少一个数据采集组件采集所述业务系统运行时数据。

本说明书一个或多个实施例中，所述业务系统采用领域模型设计，所述领域模型包含有一个业务系统完成一次业务动作所需要的所有信息，例如所述业务系统包括加入购物车业务的系统，该领域模型就可以包含加入购物车操作者的信息、商品加入购物车的时间以及加入购物车的商品所在网页的网址等。

所述业务系统运行时数据包括但不限于业务类型、金额大小、支付工具和处理模式等，所述业务系统不同，所述运行时数据也会根据所述业务系统发生改变。

步骤206：将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

本说明书一个或多个实施例中，所述数据梳理方法为所述业务系统配置至少一个数据采集组件，通过所述至少一个数据采集组件自动采集所述业务系统运行时数据，将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据；所述方法将所述数据采集组件配置在所述业务系统的内部链路的关键点上，使得所述数据采集组件基于所述业务系统的关键节点梳理业务数据，可以通过旁路系统进行运行时数据的自动梳理，深入到业务系统内部结构动态采集运行时数据，并且可以专注于单一业务系统的数据梳理。

参见图3，本说明书一个或多个实施例中，将所述运行时数据按照预设的梳理规则进行梳理包括步骤302至步骤306。

步骤302：根据业务类型对所述运行时数据进行第一级分类。

本说明书一个或多个实施例中，若所述业务系统包括支付宝业务系统，则所述业务系统按照所述业务类型可以分为支付业务、退款业务、提现业务、申购业务、赎回业务和冻结业务等。

然后根据上述的业务类型对所述运行时数据进行第一级分类，例如将所述运行时数据根据所述支付业务分为一类，按照所述退款业务分为一类，按照提现业务分为一类，按照申购业务分为一类，按照赎回业务分为一类和按照冻结业务分为一类。

步骤304：根据业务接口对第一级分类的每一类所述运行时数据进行第二级分类。

本说明书一个或多个实施例中，首先所述业务系统按照所述业务类型可以分为支付业务、退款业务、提现业务、申购业务、赎回业务和冻结业务等。

其次，将该支付业务、退款业务、提现业务、申购业务、赎回业务和冻结业务分别按照业务接口分别进行第二级分类。

例如若支付业务的业务接口包括多阶段支付接口、直接支付接口以及支付并冻结接口，则可以将按照多阶段支付接口、直接支付接口以及支付并冻结接口对每一类经过第一级分类后的运行时数据进行第二级分类。

例如使得属于所述支付业务类型的运行时数据根据所述多阶段支付接口分为一类，根据所述直接支付接口分为一类，根据所述支付并冻结接口分为一类。

步骤306：根据业务描述信息对于第二级分类的每一类所述运行时数据进行第三级分类，实现对所述运行时数据的梳理。

本说明书一个或多个实施例中，所述业务描述信息包括描述业务的关键信息。若该业务为支付业务，则业务描述信息包括该支付业务的收款方、付款方以及参与该支付业务的支付工具等。

将上述根据业务接口分类后的每一类运行时数据再根据业务描述信息进行梳理，例如将根据所述多阶段支付接口分为一类的运行时数据按照该支付业务的收款方分为一类、按照该支付业务的付款方分为一类，按照参与该支付业务的支付工具分为一类等。

参见图4，本说明书一个或多个实施例中，提供了一种对采集的运行时数据按照预设规则进行梳理的流程图，包括以下步骤：

第一步：数据采集组件采集业务系统运行时数据；

第二步：将所述运行时数据按照两种业务类型进行第一级分类，分为数据a和数据b；

第三步：将所述数据a和所述数据b分别根据两个业务接口进行第二级分类，所述数据a分为数据a1和数据a2，所述数据b分为数据b1和数据b2；

第四步：将所述数据a1、所述数据a2、所述数据b1和所述数据b2分别根据两种业务描述信息进行第三级分类，实现对所述运行时数据的梳理，其中所述数据a1分为数据a11和数据a12，所述数据a2分为数据a21和数据a22，所述数据b1分为数据b11和数据b12和所述数据b2分为数据b12和数据b22。

实际使用中，还可以根据实际需求对第三级分类后的运行时数据进行第四级、第五级或其他等级的分类，本申请对此不作任何限定。

本说明书一个或多个实施例中，根据业务描述信息对于第二级分类的每一类所述运行时数据进行第三级分类之后，还包括：

根据业务操作信息对于第三级分类的每一类所述运行时数据进行第四级分类，实现对所述运行时数据的梳理。

本说明书一个或多个实施例中，所述业务操作信息包括描述业务如何进行操作的关键信息。若该业务为提现业务，则所述业务操作信息包括提现时需要如何调动银行划拨资金到提现业务系统内部以及需要如何将资金打到商户银行卡中等。

本说明书一个或多个实施例中，可以根据提现时需要如何调动银行划拨资金到提现业务系统内部以及需要如何将资金打到商户银行卡中对于第三级分类的每一类所述运行时数据进行第四级分类，实现对所述运行时数据的梳理。

例如，若第三级分类后的运行时数据包括：一笔淘宝担保交易场景下的支付，用花呗和银行卡付款，收款方是支付宝担保户；则第四级分类后的运行时数据包括：支付系统首先调用银行做充值操作，将外部资金准备到支付宝内部的一个账户，然后调用花呗的额度扣减，最后相应金额做一笔核算补账，在担保户中增加相应的金额。

本说明书一个或多个实施例中，根据业务操作信息对于第三级分类的每一类所述运行时数据进行第四级分类之后，还包括：

根据业务属性信息对于第四级分类的每一类所述运行时数据进行第五级分类，实现对所述运行时数据的梳理。

本说明书一个或多个实施例中，所述业务属性信息可以对运行时数据进行更加细致的梳理，常常与业务系统改造、特殊约定有关系。例如新支付/老支付，然后根据确定是新支付还是老支付来决定调用那个下游。

本说明书一个或多个实施例中，根据业务属性信息对于第四级分类的每一类所述运行时数据进行第五级分类可以根据实际情况实时配置和调整，从而进一步完善对所述运行时数据的梳理。

参见图5，其中，x轴表示业务系统的运行时间，y轴表示梳理出的业务系统的目标数据的数据量。当完成上述预设梳理规则的配置后，业务系统运行开始会存在大量的运行时数据被数据采集组件采集得到，将所述运行时数据按照预设的梳理规则进行梳理后得到目标数据，然后随着业务系统的运行时间的增加，会有增量的少量运行时数据逐渐被发现并采集，然后将该增量的少量运行时数据按照预设的梳理规则进行梳理后得到目标数据，最后还可以在业务系统运行中调节梳理规则，得到更加详细的少量目标数据，使得梳理后的目标数据更加详细和清晰。

本说明书一个或多个实施例中，将所述运行时数据先按照业务类型分类，再根据业务接口对同属于一个业务类型的运行时数据再分类，最后根据业务描述信息对同属于一个业务接口的运行时数据进行梳理的方式，得到梳理后的目标数据，使得所述目标数据更加清晰，便于后续开发人员根据所述目标数据对所述业务系统进行维护。

参见图6，本说明书一个或多个实施例提供了一种数据梳理方法，包括步骤602至步骤612。

步骤602：为所述业务系统配置至少一个数据采集组件。

步骤604：通过所述至少一个数据采集组件采集所述业务系统运行时数据。

步骤606：将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

步骤608：对所述目标数据进行整理。

本说明书一个或多个实施例中，对所述目标数据进行整理包括对所述目标数据的加工，对所述目标数据加工的目的就是为了方便展示和管理，可以是对目标数据规范化和结构化，例如金额转化为分，将关键账户转化为户名，将离散的收款和付款数据，整理为双边的收-付关系等。

步骤610：将所述目标数据存储至数据库。

步骤612：展示所述目标数据。

本说明书一个或多个实施例中，所述数据梳理方法整个流程中，大部分任务均可自动完成，并且利用领域模型进行动态运行时数据梳理，可以获得更多运行时数据，该方法深入到业务系统运行时上下文中，接入方式灵活，通过在一些关键节点上接入数据采集组件进行采集运行时数据，使得采集的运行时数据更加深入，完善。

其次，所述数据梳理方法还可以对目标数据进行整理、存储和展示，增加用户体验效果。

参见图7，将本说明书一个或多个实施例提供了一种数据梳理方法应用在支付宝的支付请求中，包括步骤702至步骤730。

步骤702：上游系统接收支付请求。

步骤704：上游系统向业务系统发送支付资金准备请求。

步骤706：业务系统驱动相关支付工具准备资金，准备完成后生成支付订单。

步骤708：旁路梳理系统配置在所述业务系统中的第一数据采集组件采集所述业务系统运行时的第一数据。

步骤710：旁路梳理系统接收所述第一数据，然后按照预设的梳理规则对所述第一数据进行梳理，并得到梳理后的第一目标数据。

步骤712：调用下游系统选择支付工具。

步骤714：下游系统返回选择的支付工具信息。

步骤716：支付资金准备请求结束。

步骤718：上游系统向业务系统发送支付推进请求。

步骤720：业务系统根据选择的支付工具完成支付。

步骤722：旁路梳理系统配置在所述业务系统中的第二数据采集组件采集所述业务系统运行时的第二数据。

步骤724：旁路梳理系统接收所述第二数据，然后按照预设的梳理规则对所述第二数据进行梳理，并得到梳理后的第二目标数据。

步骤726：支付推进请求结束。

步骤728：支付请求结束。

步骤730：对所述第一目标数据和所述第二目标数据进行离线整理并展示。

本说明书一个或多个实施例中，所述支付请求包括支付资金准备和支付推进两个阶段，所述支付资金准备为第一阶段，驱动相关支付工具准备资金，准备完成后生成支付单，旁路梳理系统在此处配置一个数据采集组件采集运行时数据，可以根据梳理后的目标数据了解支付业务和各个支付工具的关系；所述支付推进为第二阶段，推进各个支付工具完成支付动作，当支付完成后，旁路梳理系统在此处配置一个数据采集组件采集运行时数据，可以根据梳理后得到的目标数据了解各个支付工具的支付时效等；并且还可以对梳理后的目标数据进行离线整理和展示，提升用户体验。

参见图8，本说明书一个或多个实施例中提供了一种数据梳理装置，包括：

配置模块802，被配置为为所述业务系统配置至少一个数据采集组件；

采集模块804，被配置为通过所述至少一个数据采集组件采集所述业务系统运行时数据；

梳理模块806，被配置为将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据。

可选地，所述装置还包括：

整理模块，被配置为对所述目标数据进行整理。

可选地，所述装置还包括：

存储模块，被配置为将所述目标数据存储至数据库。

可选地，所述装置还包括：

展示模块，被配置为展示所述目标数据。

可选地，所述梳理模块806包括：

第一分类子模块，被配置为根据业务类型对所述运行时数据进行第一级分类；

第二分类子模块，被配置为根据业务接口对第一级分类的每一类所述运行时数据进行第二级分类；

第三分类子模块，被配置为根据业务描述信息对于第二级分类的每一类所述运行时数据进行第三级分类，实现对所述运行时数据的梳理。

可选地，所述梳理模块806还包括：

第四分类子模块，被配置为根据业务操作信息对于第三级分类的每一类所述运行时数据进行第四级分类，实现对所述运行时数据的梳理。

可选地，所述梳理模块806还包括：

第五分类子模块，被配置为根据业务属性信息对于第四级分类的每一类所述运行时数据进行第五级分类，实现对所述运行时数据的梳理。

可选地，所述业务系统采用领域模型设计。

本说明书一个或多个实施例中，所述数据梳理装置为所述业务系统配置至少一个数据采集组件，通过所述至少一个数据采集组件自动采集所述业务系统运行时数据，将所述运行时数据按照预设的梳理规则进行梳理，并得到梳理后的目标数据；所述方法将所述数据采集组件配置在所述业务系统的内部链路的关键点上，使得所述数据采集组件基于所述业务系统的关键节点梳理业务数据，通过旁路系统进行数据的自动梳理，深入到系统内部结构动态采集运行时数据，并且可以专注于单一业务系统的数据梳理。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

参照图9，示出了根据本说明书的一个或多个实施例提供的一种计算设备的结构示意图，包括存储器906、处理器902及存储在存储器906上并可在处理器902上运行的计算机指令，所述处理器902执行所述指令时实现所述数据梳理方法的步骤。本说明书具体实施例并不对计算设备的具体实现做限定。

如图9所示，该计算设备还可以包括：通信接口(communications

interface)904以及通信总线908。

其中：

处理器902、通信接口904、以及存储器906通过通信总线908完成相互间的通信。

通信接口904，用于与其它终端设备或服务器进行通信。

处理器902，用于执行程序910，具体可以执行上述数据处理方法实施例中的相关步骤。

具体地，程序910可以包括程序代码，该程序代码包括计算机指令。

处理器902可能是中央处理器cpu，或者是特定集成电路asic(applicationspecificintegratedcircuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。终端设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。

存储器906，用于存放程序910。存储器906可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

程序910具体可以用于使得处理器902执行实现上述数据存储的操作。

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

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

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

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

本申请实施例中所述支付涉及的技术载体，例如可以包括近场通信(nearfieldcommunication，nfc)、wifi、3g/4g/5g、pos机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(shortmessageservice，sms)、多媒体消息(multimediamessageservice，mms)等。

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

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

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

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