CN108241653A - 数据处理方法及装置 - Google Patents

Abstract

本申请实施例提供了数据处理方法及装置。方法包括：从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；从建模开发人员针对至少一个建模指标开发的初始计算逻辑中，拆解出与至少一个建模指标一一对应的至少一条计算逻辑；根据至少一条计算逻辑，生成对待处理业务逻辑具有业务指导意义的结果表。采用本申请实施例提供的方法，有利于提高数据建模的效率。

Description

数据处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法及装置。

背景技术

数据仓库是对离散数据进行一定整理聚合，形成一套带有数据模型的数据集合，用来做业务决策，数据分析和数据挖掘的系统。其中，对业务数据进行模型抽象即可获得数据模型，数据模型可用于表述业务发展和变化。数据模型一般包括：维度表和事实表。事实表描述较小粒度的业务事实，例如卖家A的平均成交量属于事实表记录的内容；维度表描述业务事实涉及对象的属性，例如卖家A的店铺ID、名称、主营类目、信用度、所在地、好评率等属于维度表记录的内容。

目前，最常用的建模方式是先逻辑建模再物理建模，即业务人员先对整个业务逻辑进行整体梳理和深入理解，然后基于业务人员对业务的理解进行业务拆分，在业务拆分的基础上构建出维度表和事实表。

其中，业务人员对业务逻辑进行整体梳理和深入理解需要花费较长时间，建模效率较低，尤其是当业务逻辑比较复杂或者发展迅速时，建模效率会更低。

发明内容

本申请实施例提供一种数据处理方法及装置，用以提高数据建模的效率。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，提供了一种数据处理方法，包括：

从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

第二方面，提供一种数据处理装置，包括：

提取模块，用于从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

拆解模块，用于从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

生成模块，用于根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

第三方面，提供了一种电子设备，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

在本申请实施例中，从待处理业务逻辑中，提取面向开发人员的至少一个建模指标，使得开发人员可以以建模指标为粒度开发初始计算逻辑；之后，从开发人员开发的初始计算逻辑中拆解出每个建模指标的计算逻辑，进而根据每个建模指标的计算逻辑，生成对待处理业务逻辑具有业务指导意义的结果表。其中，与现有建模方法相比，建模指标的粒度相对小很多，开发人员无需对业务逻辑进行整体梳理和深入理解，只需关注建模指标对应的业务点即可，大大节约了建模时间，提高了建模效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1a为本申请一实施例提供的建模系统的框架图；

图1b为本申请另一实施例提供的建模平台的内部实现结构的示意图；

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

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

图4为本申请又一实施例提供的数据处理装置的结构示意图；

图5为本申请又一实施例提供的电子设备的结构示意图。

图6为本申请又一实施例提供的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

在现有技术中，最常用的建模方式是先逻辑建模再物理建模，即业务人员先对整个业务逻辑进行整体梳理和深入理解，然后基于业务人员对业务的理解进行业务拆分，在业务拆分的基础上构建出维度表和事实表。

其中，业务人员对业务逻辑进行整体梳理和深入理解需要花费较长时间，建模效率较低，尤其是当业务逻辑比较复杂或者发展迅速时，建模效率会更低。

针对上述问题，本申请实施例提供一种解决方案，主要原理是：降低数据建模的粒度，使开发人员直接面向建模指标，而不是整个业务逻辑，这样开发人员无需对业务逻辑进行整体梳理和深入理解，只需关注建模指标对应的业务点即可，可以大大节约建模时间，提高建模效率。

基于上述，本申请一实施例提供一种建模系统，如图1a所示，该建模系统包括：开发部署平台10和建模平台30。

开发部署平台10主要面向业务开发人员提供业务开发功能，以供业务开发人员开发业务逻辑和提交建模需求，并面向建模开发人员提供建模相关的功能，以便于建模开发人员配合建模平台30完成数据建模。

其中，所述业务逻辑可以是整个业务系统的逻辑，也可以是业务系统中的部分逻辑。

其中，业务开发人员与建模开发人员可以是相同的人员，也可以是不同人员。

其中，所述业务逻辑可以是建模系统内部的业务逻辑，也可以是建模系统外部的业务逻辑。相应地，可以自行搭建开发部署平台10，或者，也可以直接采用第三方的开发部署平台10。

建模平台30与开发部署平台10相配合，主要负责数据建模。建模平台30支持新的建模逻辑，不同于现有技术中先逻辑建模再物理建模的建模逻辑。

具体的，建模平台30主要从开发部署平台10开发的业务逻辑中，提取面向建模开发人员的至少一个建模指标。可选的，可由高级业务人员，如项目经理等，基于建模平台30从业务逻辑中提取至少一个建模指标。在本实施例中，所述建模指标直接面向建模开发人员，为以建模指标为粒度构建数据模型提供基础。

对建模开发人员来说，直接面向建模指标，只需了解建模指标对应的业务点，并针对建模指标开发计算逻辑，无需对业务逻辑进行整体梳理和深入理解，有利于节约建模时间，提高建模效率。

可选的，可由单个建模开发人员独自面向一个建模指标进行开发，或者，也可以由多个建模开发人员协作面向一个建模指标进行开发。

基于建模需求，例如需要产出财报或者需要一个对外的统计数据，建模开发人员针对至少一个建模指标开发计算逻辑。为便于区分，将建模开发人员开发的计算逻辑称为初始计算逻辑。建模开发人员针对至少一个建模指标开发初始计算逻辑主要是指：建模开发人员编写可执行的数据库语句，例如SQL语句。其中，初始计算逻辑为至少一个。

在实际开发过程中，一些建模指标之间往往具有关联性。以电子商务系统为例，假设第一建模指标是统计卖家A的平均交易额，第二建模指标是统计卖家A的总交易额，第三建模指标是统计卖家A的总成交量，第四建模指标是统计买家B从卖家A购买的商品总数，等等。其中，第一建模指标和第二建模指标都是有关卖家A的，并且都需要从数据库中读取卖家A的所有交易额，区别在于：第一建模指标是求平均，第二建模指标是求和。这两个建模指标具很强的关联性。建模开发人员在开发初始计算逻辑的过程中，会将两个指标合并开发，从而形成一条如下SQL语句：select sum(交易额)，avg(交易额)from交易表where卖家＝A。这意味着，初始计算逻辑与建模指标不一定是一一对应的关系。

基于建模开发人员针对至少一个建模指标开发的初始计算逻辑，建模平台30需要从所述初始计算逻辑中，拆解出与至少一个建模指标一一对应的至少一条计算逻辑；根据至少一条计算逻辑，生成对上述业务逻辑具有业务指导意义的结果表，至此完成数据建模。

以上述示例中的SQL语句为例，建模平台30需要拆解出第一建模指标的计算逻辑，如select avg(交易额)from交易表where卖家＝A，以及第二建模指标的计算逻辑，如select sum(交易额)from交易表where卖家＝A。

为了便于更加详细的说明建模平台30的建模原理或过程，下面结合图1b所示建模平台30的一种内部实现结构进行说明。值得说明的是，图1b所示建模平台30的内部实现结构仅为一种示例，并不限于此，凡是能够实现上述相关功能的内部实现结构均适用于本申请实施例。

如图1b所示，建模平台30主要包括：任务采集模块、指标逆向模块、指标标注模块和聚合模块。

任务采集模块主要负责从开发部署平台10采集建模开发人员针对建模指标新开发或修改的初始计算逻辑。初始计算逻辑负责实现相应建模指标的需求，通常是一条可执行的语句，如SQL语句，这些语句主要用于从业务逻辑对应的数据库中提取建模指标对应的数据并进行相应计算。举例说明，select sum(交易额)，avg(交易额)from交易表where卖家＝A是任务采集模块采集到的一个初始计算逻辑。

为便于构建数据模型，需要获取每个开发指标的计算逻辑。指标逆向模块的主要作用就是从建模开发人员针对上述至少一个建模指标开发的初始计算逻辑中，拆解出与至少一个建模指标一一对应的至少一条计算逻辑。

可选的，指标逆向模块可以判断初始计算逻辑是否对应至少一个建模指标中的一个建模指标；若初始计算逻辑对应至少一个建模指标中的一个建模指标，将所述初始计算逻辑作为对应建模指标的计算逻辑；若初始计算逻辑对应至少一个建模指标中的多个建模指标，需要从初始计算逻辑中逆向拆分出多个建模指标各自的计算逻辑。

进一步，为了便于后续建模指标对应数据的提取和已有建模指标的维护，可以根据指标体系的标准，标注至少一个建模指标的业务属性。所述指标体系的标准定义了具有标准业务含义的指标形式。基于指标体系的标准，标注建模指标的业务属性，可使建模指标的业务含义更加标准化。

考虑到建模指标之间往往具有继承关系，可选的，可基于建模指标之间的继承关系，标注建模指标的业务属性，以提高标注效率。在本实施例中，所述建模指标之间的继承关系落到具体实现上主要是指表和/或字段之间的继承关系，这种继承关系可以是父子之间的继承关系，也可以是兄弟之间的继承关系。例如，假设一建模指标需要数据A，该数据A来自于另一建模指标要构建的数据表B，则可以认为数据A与数据表B之间具有继承关系，相应的，一建模指标与另一建模之间具有继承关系。

可选的，基于建模指标之间的继承关系，标注建模指标的业务属性的实施方式包括：对至少一个建模指标中的每个建模指标，若所述建模指标与至少一个建模指标中的其它建模指标存在继承关系，则根据指标体系的标准，结合被继承建模指标的业务属性，标注所述建模指标的业务属性。例如，如果被继承建模指标的业务属性符合指标体系的标准，则可以直接将被继承建模指标的业务属性标注为所述建模指标的业务属性。

可选的，一种标注至少一个建模指标的业务属性的实施方式，包括：对至少一个建模指标中的每个建模指标，根据指标体系的标准，显示建模指标的业务属性的取值选项，以供建模开发人员选择或确认；根据建模开发人员选择或确认的取值，标注所述建模指标的业务属性。

可选的，可以标注的业务属性包括但不限于：业务域、维度和类别属性。业务域用于表示建模指标所属的业务领域，例如可以是交易域或风控域等。维度表示建模指标涉及的维度，以交易域为例，所述维度可以是买家维度、卖家维度、店铺维度、商品维度或交易日期维度等。对应于结果表中，维度是具有唯一标识作用的主键。类别属性用于表示建模指标所属类别下的属性。所述类别属性包括维度类的属性(简称为维度属性)或派生类的属性(简称为派生属性)。对一个建模指标来说，要么是维度类的，具有维度属性，要么是派生类的，具有派生属性。维度类建模指标是指用于统计维度的属性信息的建模指标；维度类建模指标之外的其它建模指标可视为派生类建模指标。维度属性是维度的修饰。派生属性包括：时间周期、原子指标以及修饰词。其中，原子指标是指不能再拆分的原子粒度的指标。

例如，按省份维度分析问题，每一个省份就是维度；用于统计每一个省份的属性包括哪些信息的建模指标属于维度类建模指标，其中，省会信息，省长，面积等属于维度属性；用于统计某个省近180天PC端的成交额的建模指标属于派生类建模指标，其中180天是时间周期，成交额是原子指标，PC端是修饰词。

又例如，假设第一建模指标为卖家A的平均交易额，对第一建模指标进行标注，获得标注后的建模指标为：交易域下卖家A近180天PC端的平均交易额。其中，业务域属于交易域，卖家A属于维度，最近180 天是时间周期，交易额是原子指标；PC端和平均是修饰词；最近180天在PC端的平均交易额属于派生类建模指标。

又例如，假设第二建模指标为卖家A的平均交易额，对第二建模指标进行标注，获得标注后的建模指标为：交易域下卖家A近180天手机端的平均交易额。其中，业务域属于交易域，卖家A属于维度，最近180天是时间周期，交易额是原子指标；手机端和平均是修饰词；最近180天手机端的平均交易额属于派生类建模指标。

基于上述，标注至少一个建模指标的业务属性，包括以下至少一种：

根据指标体系的标准，标注至少一个建模指标的业务域；

根据指标体系的标准，标注至少一个建模指标的维度；

根据指标体系的标准，标注至少一个建模指标的类别属性；所述类别属性包括维度类的属性或派生类的属性。

基于建模指标的业务属性，聚合模块可以根据至少一个建模指标的业务属性，聚合至少一条计算逻辑；运行聚合后的计算逻辑，以生成结果表。其中，聚合后的计算逻辑也是一些可执行的语句，例如SQL语句，主要用于从业务逻辑对应的数据库中提取相应数据并进行相应计算，以产出结果表。

可选的，所述结果表包括维度表和事实表。进一步，事实表又可分为明细事实表和汇总事实表。明细事实表包含多个维度和多个维度之间的相互关系。汇总事实表是根据明细事实表进行单个维度的汇总形成的事实表。

举例说明，假设买家A在11月11日买了卖家B的一件商品C，这条记录包括买家A、卖家B、商品C以及时间11月11日等多个维度以及它们之间的关联关系，该条记录会被存储到明细事实表中。其中，可以按照卖家维度来聚合明细事实表，从而形成维度是卖家B的汇总事实表；或者，也可以按照买家维度来聚合明细事实表，从而形成维度是买家A的汇总事实表；或者，也可以按照商品维度来聚合明细事实表，从而形成维度是商品C的汇总事实表；或者，也可以按照时间维度来聚合明细事实表，从而形成维度是时间11月11日的汇总事实表。

基于上述，如图1b所示，聚合模块可执行以下至少一种合并操作：维度表合并、明细事实表合并和汇总事实表合并。

维度表合并是指：将业务域和维度相同的维度类计算逻辑合并为一条计算逻辑。维度类计算逻辑是指维度类建模指标的计算逻辑。简单来说，是指对主键和计算方法相同的计算逻辑进行合并，保留同一个主键，合并其他维度属性。

以SQL语句为例，举例说明维度表合并。假设有以下几条计算逻辑：select卖家from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的名称；select卖家电话from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的电话；select卖家发货地from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的发货地。这几条计算逻辑均属于交易域，均为卖家A维度，卖家A的电话、发货地均属于卖家A的属性，故属于维度类计算逻辑，则可以合并为一条计算逻辑：select卖家，卖家电话，卖家发货地from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的名称、电话和发货地。汇总事实表合并是指：将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑。派生类计算逻辑是指派生类建模指标的计算逻辑。

以SQL语句为例，举例说明汇总事实表合并。假设有以下几条计算逻辑：selectavg(交易额)from交易表where卖家＝A，表示从交易表中取卖家A的平均交易额；selectsum(交易额)from交易表where卖家＝A，表示从交易表中取卖家A的总交易额。这几条计算逻辑均属于交易域，均为卖家A维度，卖家A的平均交易额和总交易额为派生属性，属于派生类计算逻辑，则可以合并为一条计算逻辑：select sum(交易额)，avg(交易额)from交易表where卖家＝A。

明细事实表合并是指：将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

以SQL语句为例，举例说明明细事实表合并。假设有以下事实：买家A在11月11日买了卖家B的一件商品C；卖家B在11月12日向买家A返现，这两个事实均属于交易域，且均涉及买家A和卖家B维度，且相互关联，则可以合并为一条计算逻辑为：select交易表.买家A，交易表.卖家B，交易表.商品C，交易表.11月11日返现表.11月12日from交易表，返现表where返现表.买家A＝交易表.买家A and返现表.卖家B＝交易表.卖家B。

聚合模块执行聚合操作，运行聚合后的计算逻辑，可以避免多次存储和计算，有利于节约资源，提高建模效率。聚合模块产出的结果表可供业务系统使用。

可选的，如图1b所示，建模平台30还可以包括：表拆分模块，主要用于根据结果表的使用情况，对结果表进行拆分。

进一步，如图1b所示，该表拆分模块主要执行热点数据拆分、易变数据拆分和/或长周期数据拆分。

热点数据拆分是指：根据结果表中数据的查询频度，对结果表进行纵向拆分；主要是指将查询频度较高的数据列拆分出来，将大的结果集分解成小的结果集，优化热点数据的读取，提高读取效率。

易变数据拆分是指：根据结果表中数据的计算逻辑的变化频度，对结果表进行纵向拆分；主要是指经常变化的数据列拆分出来，将大的结果集分解成小的结果集，优化易变数据的计算和读取。

长周期数据拆分：根据结果表中数据的读取频度，对结果表进行横向拆分；主要是指将冷门的历史数据行拆分出来，将大的结果集分解成小的结果集，有利于加快新数据的读取和优化历史数据的存储。

由上述可见，本实施例提供的建模系统，以建模指标为粒度构建数据模型，相较于现有技术中先逻辑建模再物理建模的方式，由于建模开发人员只需了解建模指标对应的业务点，无需对业务逻辑进行整体梳理和深入理解，所以建模周期相对较短，适合业务发展速度，建模的人力成本相对较低。

另外，现有技术中先逻辑建模再物理建模的方式，依靠建模业务人员对业务的理解进行业务的划分，对维度的粒度和事实的聚合都是基于业务理解上，不同建模业务人员对业务的拆分不同，而且业务在不同发展也会有所不同，容易造成数据模型的不可持续性。而本实施例提供的建模系统，直接以建模指标为粒度构建数据模型，建模业务人员无需对业务进行拆分，建模指标比较统一，所构建的数据模型具有良好的可持续性。

再者，本实施例建模系统所构建的数据模型，经过聚合，不仅有利于业务发展，而且可以节省大量的计算资源和存储资源。

基于上述建模系统，本申请实施例还提供一种数据处理方法。如图2所示，该方法包括：

201、从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标。

202、从建模开发人员针对至少一个建模指标开发的初始计算逻辑中，拆解出与至少一个建模指标一一对应的至少一条计算逻辑。

203、根据至少一条计算逻辑，生成对待处理业务逻辑具有业务指导意义的结果表。

本实施例提供一种数据处理方法，可由数据处理装置来执行，主要用于构建数据模型。

在本实施例中，将需要构建数据模型的业务逻辑称为待处理业务逻辑。例如，所述待处理业务逻辑可以是各种涉及大数据处理的业务逻辑，例如各种电子商务平台的业务逻辑。

在本实施例中，从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标，为以建模指标为粒度构建数据模型提供基础。可选的，可以由单个建模开发人员独自面向一个建模指标进行开发，或者，也可以由多个建模开发人员协作面向一个建模指标进行开发。

对建模开发人员来说，需要了解建模指标对应的业务点，并针对建模指标开发计算逻辑。所述计算逻辑主要用于获得建模指标所需业务数据，一般实现为建模语句，例如SQL语句。为便于区分，将建模开发人员开发的计算逻辑称为初始计算逻辑。面向建模指标的建模方式，使得建模开发人员无需对业务逻辑进行整体梳理和深入理解，只需关注建模指标对应的业务点即可，有利于节约建模时间，提高建模效率。另外，面向建模指标的建模方式，因为效率较高，且建模开发人员无需了解整个业务逻辑，因此可以适应业务的快速发展。

在实际开发过程中，建模开发人员往往会合并开发，即通过研究建模指标之间的关联关系，实现一条能够同时获得多个建模指标所需业务数据的初始计算逻辑。举例说明，假设一个建模指标为：计算卖家A的总交易额；另一个建模指标为：计算卖家A的平均交易额。这两个建模指标都和卖家A的所有交易额有关，故可以通过一条计算逻辑同时获得这两个建模指标所需的数据。所述计算逻辑可以是：读取卖家A的所有交易额进行求和和求平均，该计算逻辑实现为SQL语句为：select sum(交易额)，avg(交易额)from交易表where卖家＝A。这意味着，初始计算逻辑与建模指标不一定是一一对应的关系。

在建模开发人员针对至少一个建模指标开发出初始计算逻辑之后，数据处理装置可以获取建模开发人员针对至少一个建模指标开发出初始计算逻辑，从中拆解出与至少一个建模指标一一对应的至少一条计算逻辑，即至少一个建模指标各自的计算逻辑；进而根据至少一条计算逻辑，生成对待处理业务逻辑具有业务指导意义的结果表。

为便于构建数据模型，需要获取每个开发指标的计算逻辑。可选的，可以判断初始计算逻辑是否对应至少一个建模指标中的一个建模指标；若初始计算逻辑对应至少一个建模指标中的一个建模指标，将所述初始计算逻辑作为对应建模指标的计算逻辑；若初始计算逻辑对应至少一个建模指标中的多个建模指标，需要从初始计算逻辑中逆向拆分出多个建模指标各自的计算逻辑。以上述示例中的SQL语句为例，可以拆解出第一建模指标的计算逻辑，如select avg(交易额)from交易表where卖家＝A，以及第二建模指标的计算逻辑，如select sum(交易额)from交易表where卖家＝A。

进一步，为了便于后续建模指标对应数据的提取和已有建模指标的维护，可以根据指标体系的标准，标注至少一个建模指标的业务属性。所述指标体系的标准定义了具有标准业务含义的指标形式。基于指标体系的标准，标注建模指标的业务属性，可使建模指标的业务含义更加标准化。

在一可选实施方式中，考虑到建模指标之间往往具有继承关系，因此可基于建模指标之间的继承关系，标注建模指标的业务属性，以提高标注效率。在本实施例中，所述建模指标之间的继承关系落到具体实现上主要是指表和/或字段之间的继承关系，这种继承关系可以是父子之间的继承关系，也可以是兄弟之间的继承关系。例如，假设一建模指标需要数据A，该数据A来自于另一建模指标要构建的数据表B，则可以认为数据A与数据表B之间具有继承关系，相应的，一建模指标与另一建模之间具有继承关系。

可选的，基于建模指标之间的继承关系，标注建模指标的业务属性的实施方式包括：对至少一个建模指标中的每个建模指标，若所述建模指标与至少一个建模指标中的其它建模指标存在继承关系，则根据指标体系的标准，结合被继承建模指标的业务属性，标注所述建模指标的业务属性。例如，如果被继承建模指标的业务属性符合指标体系的标准，则可以直接将被继承建模指标的业务属性标注为所述建模指标的业务属性。

可选的，一种标注至少一个建模指标的业务属性的实施方式，包括：对至少一个建模指标中的每个建模指标，根据指标体系的标准，显示建模指标的业务属性的取值选项，以供建模开发人员选择或确认；根据建模开发人员选择或确认的取值，标注所述建模指标的业务属性。

可选的，可以标注的业务属性包括但不限于：业务域、维度和类别属性。业务域用于表示建模指标所属的业务领域，例如可以是交易域或风控域等。维度表示建模指标涉及的维度，以交易域为例，所述维度可以是买家维度、卖家维度、店铺维度、商品维度或交易日期维度等。对应于结果表中，维度是具有唯一标识作用的主键。类别属性用于表示建模指标所属类别下的属性。所述类别属性包括维度类的属性(简称为维度属性)或派生类的属性(简称为派生属性)。对一个建模指标来说，要么是维度类的，具有维度属性；要么是派生类的，具有派生属性。维度类建模指标是指用于统计维度的属性信息的建模指标；维度类建模指标之外的其它建模指标可视为派生类建模指标。维度属性是维度的修饰。派生属性包括：时间周期、原子指标以及修饰词。

例如，按省份维度分析问题，每一个省份就是维度；用于统计每一个省份的属性包括哪些信息的建模指标属于维度类建模指标，其中，省会信息，省长，面积等属于维度属性；用于统计某个省近180天PC端的成交额的建模指标属于派生类建模指标，其中180天是时间周期，成交额是原子指标，PC端是修饰词。

又例如，假设第一建模指标为卖家A的平均交易额，对第一建模指标进行标注，获得标注后的建模指标为：交易域下卖家A近180天PC端的平均交易额。其中，业务域属于交易域，卖家A属于维度，最近180天是时间周期，交易额是原子指标；PC端和平均是修饰词；最近180天在PC端的平均交易额属于派生类建模指标。

又例如，假设第二建模指标为卖家A的平均交易额，对第二建模指标进行标注，获得标注后的建模指标为：交易域下卖家A近180天手机端的平均交易额。其中，业务域属于交易域，卖家A属于维度，最近180天是时间周期，交易额是原子指标；手机端和平均是修饰词；最近180天手机端的平均交易额属于派生类建模指标。

基于上述，标注所述至少一个建模指标的业务属性，包括以下至少一种：

根据所述指标体系的标准，标注至少一个建模指标的业务域；

根据所述指标体系的标准，标注至少一个建模指标的维度；

根据所述指标体系的标准，标注至少一个建模指标的类别属性；所述类别属性包括维度类的属性或派生类的属性。

在一可选实施方式中，可基于建模指标的业务属性，生成结果表。可选的，可以根据至少一个建模指标的业务属性，聚合至少一个计算逻辑；运行聚合后的计算逻辑，以生成结果表。其中，聚合后的计算逻辑也是一些可执行的语句，如SQL语句，主要用于从业务逻辑对应的数据库中提取相应数据并进行相应计算，以产出结果表。

可选的，所述结果表包括维度表和事实表。进一步，事实表又可分为明细事实表和汇总事实表。明细事实表包含多个维度和多个维度之间的相互关系。汇总事实表是根据明细事实表进行单个维度的汇总形成的事实表。

举例说明，假设买家A在11月11日买了卖家B的一件商品C，这条记录包括买家A、卖家B、商品C以及时间11月11日等多个维度以及它们之间的关联关系，该条记录会被存储到明细事实表中。其中，可以按照卖家维度来聚合明细事实表，从而形成维度是卖家B的汇总事实表；或者，也可以按照买家维度来聚合明细事实表，从而形成维度是买家A的汇总事实表；或者，也可以按照商品维度来聚合明细事实表，从而形成维度是商品C的汇总事实表；或者，也可以按照时间维度来聚合明细事实表，从而形成维度是时间11月11日的汇总事实表。

基于上述，数据处理装置可执行以下至少一种合并操作：维度表合并、明细事实表合并和汇总事实表合并。

维度表合并是指：将业务域和维度相同的维度类建模指标的计算逻辑合并为一条计算逻辑。维度类计算逻辑是指维度类建模指标的计算逻辑。简单来说，是指对主键和计算方法相同的计算逻辑进行合并，保留同一个主键，并合并其他维度属性。

以SQL语句为例，举例说明维度表合并。假设有以下几条计算逻辑：select卖家from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的名称；select卖家电话from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的电话；select卖家发货地from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的发货地。这几条计算逻辑均属于交易域，均为卖家A维度，卖家A的电话、发货地均属于卖家A的属性，故属于维度类计算逻辑，则可以合并为一条计算逻辑：select卖家，卖家电话，卖家发货地from卖家信息表where卖家＝A，表示从卖家信息表中取卖家A的名称、电话和发货地。

汇总事实表合并是指：将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑。派生类计算逻辑是指派生类建模指标的计算逻辑。

以SQL语句为例，举例说明汇总事实表合并。假设有以下几条计算逻辑：selectavg(交易额)from交易表where卖家＝A，表示从交易表中取卖家A的平均交易额；selectsum(交易额)from交易表where卖家＝A，表示从交易表中取卖家A的总交易额。这几条计算逻辑均属于交易域，均为卖家A维度，卖家A的平均交易额和总交易额为派生属性，属于派生类计算逻辑，则可以合并为一条计算逻辑：select sum(交易额)，avg(交易额)from交易表where卖家＝A。

明细事实表合并是指：将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

以SQL语句为例，举例说明明细事实表合并。假设有以下事实：买家A在11月11日买了卖家B的一件商品C；卖家B在11月12日向买家A返现，这两个事实均属于交易域，且均涉及买家A和卖家B维度，且相互关联，则可以合并为一条计算逻辑为：select交易表.买家A，交易表.卖家B，交易表.商品C，交易表.11月11日返现表.11月12日from交易表，返现表where返现表.买家A＝交易表.买家A and返现表.卖家B＝交易表.卖家B。

对建模指标的计算逻辑进行聚合操作，运行聚合后的计算逻辑，可以避免多次存储和计算，有利于节约资源，提高建模效率。

在图2所示实施例的基础上，如图3所示，本申请又一实施例提供的数据处理方法，在输出结果表之后，还包括：

204、根据结果表的使用情况，对结果表进行拆分。

可选的，对结果表进行拆分包括但不限于：热点数据拆分、易变数据拆分和/或长周期数据拆分。

热点数据拆分是指：根据结果表中数据的查询频度，对结果表进行纵向拆分；主要是指将查询频度较高的数据列拆分出来，将大的结果集分解成小的结果集，优化热点数据的读取，提高读取效率。

易变数据拆分是指：根据结果表中数据的计算逻辑的变化频度，对结果表进行纵向拆分；主要是指经常变化的数据列拆分出来，将大的结果集分解成小的结果集，优化易变数据的计算和读取。

长周期数据拆分：根据结果表中数据的读取频度，对结果表进行横向拆分；主要是指将冷门的历史数据行拆分出来，将大的结果集分解成小的结果集，有利于加快新数据的读取和优化历史数据的存储。

由上述可见，本实施例以建模指标为粒度构建数据模型，相较于现有技术中先逻辑建模再物理建模的方式，由于建模开发人员只需了解建模指标对应的业务点，无需对业务逻辑进行整体梳理和深入理解，所以建模周期相对较短，适合业务发展速度，建模的人力成本相对较低。

另外，现有技术中先逻辑建模再物理建模的方式，依靠建模业务人员对业务的理解进行业务的划分，对维度的粒度和事实的聚合都是基于业务理解上，不同建模业务人员对业务的拆分不同，而且业务在不同发展也会有所不同，容易造成数据模型的不可持续性。而本实施例直接以建模指标为粒度构建数据模型，建模业务人员无需对业务进行拆分，建模指标比较统一，所构建的数据模型具有良好的可持续性。

再者，本实施例所构建的数据模型，经过聚合，不仅有利于业务发展，而且可以节省大量的计算资源和存储资源。

图4为本申请又一实施例提供的数据处理装置的结构示意图。如图4所示，该装置包括：提取模块41、拆解模块42和生成模块43。

提取模块41，用于从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标。

拆解模块42，用于从建模开发人员针对至少一个建模指标开发的初始计算逻辑中，拆解出与至少一个建模指标一一对应的至少一条计算逻辑。

生成模块43，用于根据至少一条计算逻辑，生成对待处理业务逻辑具有业务指导意义的结果表。

在一可选实施方式中，拆解模块42具体用于：在初始计算逻辑对应至少一个建模指标中的一个建模指标时，将初始计算逻辑作为对应建模指标的计算逻辑；或者，在初始计算逻辑对应至少一个建模指标中的多个建模指标时，从初始计算逻辑中逆向拆分出多个建模指标各自的计算逻辑。

在一可选实施方式中，生成模块43具体用于：根据至少一个建模指标的业务属性，聚合至少一个计算逻辑；运行聚合后的计算逻辑，以生成结果表。

在一可选实施方式中，如图5所示，装置还包括：标注模块44。

标注模块44，用于在生成模块43聚合至少一个计算逻辑之前，根据指标体系的标准，标注至少一个建模指标的业务属性。

可选的，标注模块44具体用于：对至少一个建模指标中的每个建模指标，若建模指标与至少一个建模指标中的其它建模指标存在继承关系，根据指标体系的标准，结合被继承建模指标的业务属性，标注建模指标的业务属性。

可选的，标注模块44具体用于：对至少一个建模指标中的每个建模指标，根据指标体系的标准，显示建模指标的业务属性的取值选项；根据建模开发人员选择或确认的取值，标注建模指标的业务属性。

可选的，标注模块44具体用于执行以下至少一种标注操作：

根据指标体系的标准，标注至少一个建模指标的业务域；

根据指标体系的标准，标注至少一个建模指标的维度；

根据指标体系的标准，标注至少一个建模指标的类别属性；类别属性包括维度类的属性或派生类的属性。

可选的，生成模块43具体用于执行以下至少一种聚合操作：

将业务域和维度相同的维度类计算逻辑合并为一条计算逻辑；

将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑；

将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

在一可选实施方式中，如图5所示，装置还包括：拆分模块45，用于根据结果表的使用情况，对结果表进行拆分。

进一步，拆分模块45具体用于执行以下至少一种拆分操作：

根据结果表中数据的查询频度，对结果表进行纵向拆分；

根据结果表中数据的计算逻辑的变化频度，对结果表进行纵向拆分；

根据结果表中数据的读取频度，对结果表进行横向拆分。

本实施例提供的数据处理装置，可用于执行前述方法实施例的流程，在此不再赘述。

本实施例提供的数据处理装置，以建模指标为粒度构建数据模型，相较于现有技术中先逻辑建模再物理建模的方式，由于建模开发人员只需了解建模指标对应的业务点，无需对业务逻辑进行整体梳理和深入理解，所以建模周期相对较短，适合业务发展速度，建模的人力成本相对较低。

另外，现有技术中先逻辑建模再物理建模的方式，依靠建模业务人员对业务的理解进行业务的划分，对维度的粒度和事实的聚合都是基于业务理解上，不同建模业务人员对业务的拆分不同，而且业务在不同发展也会有所不同，容易造成数据模型的不可持续性。而本实施例提供的数据处理装置，直接以建模指标为粒度构建数据模型，建模业务人员无需对业务进行拆分，建模指标比较统一，所构建的数据模型具有良好的可持续性。

再者，本实施例提供的数据处理装置所构建的数据模型，经过聚合，不仅有利于业务发展，而且可以节省大量的计算资源和存储资源。

以上描述了数据处理装置的内部功能和结构，如图6所示，实际中，该数据处理装置可实现为一种电子设备，包括：存储器61和处理器62。

存储器61，用于存储程序。

除上述程序之外，存储器61还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

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

处理器62，耦合至存储器61，用于执行存储器61中的程序，以用于：

从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

可选的，处理器62在拆解出与至少一个建模指标一一对应的至少一条计算逻辑时，具体用于：在所述初始计算逻辑对应所述至少一个建模指标中的一个建模指标时，将所述初始计算逻辑作为所述对应建模指标的计算逻辑；或者，在所述初始计算逻辑对应所述至少一个建模指标中的多个建模指标时，从所述初始计算逻辑中逆向拆分出所述多个建模指标各自的计算逻辑。

可选的，处理器62在生成结果表时，具体用于：根据所述至少一个建模指标的业务属性，聚合所述至少一个计算逻辑；运行聚合后的计算逻辑，以生成所述结果表。

可选的，处理器62还用于：根据指标体系的标准，标注所述至少一个建模指标的业务属性。

可选的，处理器62在标注所述至少一个建模指标的业务属性时，具体用于：对所述至少一个建模指标中的每个建模指标，若所述建模指标与所述至少一个建模指标中的其它建模指标存在继承关系，根据所述指标体系的标准，结合被继承建模指标的业务属性，标注所述建模指标的业务属性。

可选的，处理器62在标注所述至少一个建模指标的业务属性时，具体用于：对所述至少一个建模指标中的每个建模指标，根据所述指标体系的标准，显示所述建模指标的业务属性的取值选项；根据所述建模开发人员选择或确认的取值，标注所述建模指标的业务属性。

可选的，处理器62在标注所述至少一个建模指标的业务属性时，具体用于执行以下至少一种标注操作：

根据所述指标体系的标准，标注所述至少一个建模指标的业务域；

根据所述指标体系的标准，标注所述至少一个建模指标的维度；

根据所述指标体系的标准，标注所述至少一个建模指标的类别属性；所述类别属性包括维度类的属性或派生类的属性。

可选的，处理器62在聚合所述至少一个计算逻辑时，具体用于执行以下至少一种合并操作：

将业务域和维度相同的维度类计算逻辑合并为一条计算逻辑；

将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑；

将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

可选的，处理器62还用于：根据所述结果表的使用情况，对所述结果表进行拆分。

可选的，处理器62在对所述结果表进行拆分时，具体用于执行以下至少一种拆分操作：

根据所述结果表中数据的查询频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的计算逻辑的变化频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的读取频度，对所述结果表进行横向拆分。

进一步，如图6所示，电子设备还包括：通信组件63、电源组件64、音频组件65、显示器66等其它组件。图6中仅示意性给出部分组件，并不意味着电子设备只包括图6所示组件。

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

电源组件64，为电子设备的各种组件提供电力。电源组件66可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件65被配置为输出和/或输入音频信号。例如，音频组件65包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器61或经由通信组件63发送。在一些实施例中，音频组件65还包括一个扬声器，用于输出音频信号。

显示器66包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (21)

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

从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

2.根据权利要求1所述的方法，其特征在于，所述从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑，包括：

若所述初始计算逻辑对应所述至少一个建模指标中的一个建模指标，将所述初始计算逻辑作为所述对应建模指标的计算逻辑；

若所述初始计算逻辑对应所述至少一个建模指标中的多个建模指标，从所述初始计算逻辑中逆向拆分出所述多个建模指标各自的计算逻辑。

3.根据权利要求1所述的方法，其特征在于，所述根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表，包括：

根据所述至少一个建模指标的业务属性，聚合所述至少一个计算逻辑；

运行聚合后的计算逻辑，以生成所述结果表。

4.根据权利要求3所述的方法，其特征在于，所述根据所述至少一个建模指标的业务属性，聚合所述至少一个计算逻辑之前，还包括：

根据指标体系的标准，标注所述至少一个建模指标的业务属性。

5.根据权利要求4所述的方法，其特征在于，所述根据指标体系的标准，标注所述至少一个建模指标的业务属性，包括：

对所述至少一个建模指标中的每个建模指标，若所述建模指标与所述至少一个建模指标中的其它建模指标存在继承关系，根据所述指标体系的标准，结合被继承建模指标的业务属性，标注所述建模指标的业务属性。

6.根据权利要求4所述的方法，其特征在于，所述根据指标体系的标准，标注所述至少一个建模指标的业务属性，包括：

对所述至少一个建模指标中的每个建模指标，根据所述指标体系的标准，显示所述建模指标的业务属性的取值选项；

根据所述建模开发人员选择或确认的取值，标注所述建模指标的业务属性。

7.根据权利要求4或5或6所述的方法，其特征在于，所述根据指标体系的标准，标注所述至少一个建模指标的业务属性，包括以下至少一种：

根据所述指标体系的标准，标注所述至少一个建模指标的业务域；

根据所述指标体系的标准，标注所述至少一个建模指标的维度；

根据所述指标体系的标准，标注所述至少一个建模指标的类别属性；所述类别属性包括维度类的属性或派生类的属性。

8.根据权利要求7所述的方法，其特征在于，所述根据所述至少一个建模指标的业务属性，对所述至少一个计算逻辑进行聚合，包括以下至少一种：

将业务域和维度相同的维度类计算逻辑合并为一条计算逻辑；

将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑；

将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

9.根据权利要求1-6任一项所述的方法，其特征在于，还包括：

根据所述结果表的使用情况，对所述结果表进行拆分。

10.根据权利要求9所述的方法，其特征在于，所述根据所述结果表的使用情况，对所述结果表进行拆分，包括以下至少一种：

根据所述结果表中数据的查询频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的计算逻辑的变化频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的读取频度，对所述结果表进行横向拆分。

11.一种数据处理装置，其特征在于，包括：

提取模块，用于从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

拆解模块，用于从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

生成模块，用于根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

12.一种电子设备，其特征在于，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

从待处理业务逻辑中，提取面向建模开发人员的至少一个建模指标；

从所述建模开发人员针对所述至少一个建模指标开发的初始计算逻辑中，拆解出与所述至少一个建模指标一一对应的至少一条计算逻辑；

根据所述至少一条计算逻辑，生成对所述待处理业务逻辑具有业务指导意义的结果表。

13.根据权利要求12所述的电子设备，其特征在于，所述处理器具体用于：

若所述初始计算逻辑对应所述至少一个建模指标中的一个建模指标，将所述初始计算逻辑作为所述对应建模指标的计算逻辑；

若所述初始计算逻辑对应所述至少一个建模指标中的多个建模指标，从所述初始计算逻辑中逆向拆分出所述多个建模指标各自的计算逻辑。

14.根据权利要求12所述的电子设备，其特征在于，所述处理器具体用于：

根据所述至少一个建模指标的业务属性，聚合所述至少一个计算逻辑；

运行聚合后的计算逻辑，以生成所述结果表。

15.根据权利要求14所述的电子设备，其特征在于，所述处理器还用于：

根据指标体系的标准，标注所述至少一个建模指标的业务属性。

16.根据权利要求15所述的电子设备，其特征在于，所述处理器具体用于：

对所述至少一个建模指标中的每个建模指标，若所述建模指标与所述至少一个建模指标中的其它建模指标存在继承关系，根据所述指标体系的标准，结合被继承建模指标的业务属性，标注所述建模指标的业务属性。

17.根据权利要求15所述的电子设备，其特征在于，所述处理器具体用于：

对所述至少一个建模指标中的每个建模指标，根据所述指标体系的标准，显示所述建模指标的业务属性的取值选项；

根据所述建模开发人员选择或确认的取值，标注所述建模指标的业务属性。

18.根据权利要求15或16或17所述的电子设备，其特征在于，所述处理器具体用于执行以下至少一种标注操作：

根据所述指标体系的标准，标注所述至少一个建模指标的业务域；

根据所述指标体系的标准，标注所述至少一个建模指标的维度；

根据所述指标体系的标准，标注所述至少一个建模指标的类别属性；所述类别属性包括维度类的属性或派生类的属性。

19.根据权利要求18所述的电子设备，其特征在于，所述处理器具体用于执行以下至少一种合并操作：

将业务域和维度相同的维度类计算逻辑合并为一条计算逻辑；

将业务域和维度相同的派生类计算逻辑合并为一条计算逻辑；

将业务域和维度相同，且存在关联关系的维度类计算逻辑和派生类计算逻辑合并为一条计算逻辑。

20.根据权利要求12-17任一项所述的电子设备，其特征在于，所述处理器还用于：

根据所述结果表的使用情况，对所述结果表进行拆分。

21.根据权利要求20所述的电子设备，其特征在于，所述处理器具体用于执行以下至少一种拆分操作：

根据所述结果表中数据的查询频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的计算逻辑的变化频度，对所述结果表进行纵向拆分；

根据所述结果表中数据的读取频度，对所述结果表进行横向拆分。