CN114331679A - 数据问题的分析方法及相关装置 - Google Patents

Abstract

本申请公开的数据问题的分析方法及相关装置可用于人工智能领域或其他领域。本申请提供的技术方案中，获取业务系统中的非结构化数据和结构化数据，非结构化数据包括业务系统的需求文档、设计文档、数据核对依据和问题处理跟踪记录，数据核对依据包括核对依据指标和核对依据指标数值，问题处理跟踪记录包括业务系统的常用分析路径和问题描述；根据非结构化数据和结构化数据构建业务系统的知识图谱，该知识图谱的逻辑概念包括产品、指标、质量问题和核对依据指标；根据业务系统的问题描述、指标加工规则和核对依据指标数值，确定业务系统的源头问题指标；根据源头问题指标和常用分析路径，确定业务系统的源头问题数据，实现了业务系统的问题定位。

Description

数据问题的分析方法及相关装置

技术领域

本申请涉及人工智能领域，尤其涉及一种数据问题的分析方法及相关装置。

背景技术

目前，很多业务系统，例如银行业务系统，由于业务种类和子系统繁多、业务逻辑复杂以及业务数据量庞大，使得业务系统出现问题数据时，业务人员很难定位到该问题数据的问题原因和问题源头。

因此，如何对业务系统中的问题进行定位，成为了亟待解决的问题。

发明内容

本申请提供了一种数据问题的分析方法及相关装置，实现了业务系统的问题定位。

第一方面，本申请提供一种数据问题的分析方法，所述方法包括：获取业务系统中的非结构化数据和结构化数据，所述非结构化数据包括所述业务系统的需求文档、设计文档、数据核对依据和问题处理跟踪记录，所述结构化数据包括所述业务系统的业务数据，所述数据核对依据包括核对依据指标和核对依据指标数值，所述问题处理跟踪记录包括所述业务系统的常用分析路径和问题描述；根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱，所述知识图谱的逻辑概念包括产品、指标、质量问题和所述核对依据指标，所述知识图谱包括所述业务系统的指标加工规则；根据所述业务系统的问题描述、所述指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标；根据所述业务系统的源头问题指标、所述常用分析路径和所述核对依据指标数值，确定所述业务系统的源头问题数据。

本方法中，通过获取的业务系统的非结构化数据和结构化数据构建业务系统的知识图谱，根据该知识图谱中的逻辑概念、物理概念、每个概念的属性以及相互之间的关系，再结合业务系统的问题描述、常用分析路径和指标加工规则等确定业务系统的源头问题指标和源头问题数据，实现了业务系统的问题定位，相比于通过开发人员人为查找业务系统的问题数据，提高了业务系统的问题定位的效率，节约了时间，节省了人力资源。

在一种可能的实现方式中，在所述根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱之前，所述方法还包括：通过自然语言处理技术NLP或关系数据库与资源描述框架的映射语言R2RML对所述非结构化数据和所述结构化数据进行转化，得到转化后的非结构数据和转化后的结构数据；对所述转化后的非结构数据和所述转化后的结构数据进行标准化处理，得到所述标准化后的非结构数据和所述标准化后的结构数据；

相应地，所述根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱，包括：根据所述标准化后的非结构化数据和所述标准化后的结构化数据构建所述业务系统的知识图谱。

该实现方式中，将获取的业务系统的非结构化数据和结构化数据进行转化，再对转化后的非结构化数据和结构化数据进行标准化，根据标准化后的非结构化数据和结构化数据构建业务系统的知识图谱，提高了业务系统的知识图谱的准确度和构建知识图谱的效率。

在一种可能的实现方式中，所述业务系统的知识图谱的物理概念包括数据库对象集合、表、视图、字段。

在一种可能的实现方式中，所述知识图谱中的关系包括所述产品间的上下级关系、所述产品与所述指标间的描述关系、所述质量问题与所述产品间的从属关系、所述质量问题与所述指标间的从属关系、所述表与所述产品间的映射关系、所述表与所述指标间的映射关系、所述表与所述字段间的属性关系、所述维度与所述指标间的属性关系、所述时间与所述指标间的属性关系、所述限制条件与所述指标间的属性关系、所述问题性质与所述质量问题间的描述关系。

该实现方式中，明确了业务系统的知识图谱中的关系，使得通过业务系统的知识图谱对该业务系统的问题定位的准确度更高。

在一种可能的实现方式中，所述根据所述业务系统的问题描述、所述指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标，包括：基于所述质量问题和所述知识图谱，推理补充所述质量问题的缺失信息，得到质量问题知识图谱，所述质量问题知识图谱包括目标指标的物理位置；将根据所述物理位置提取的所述目标指标对应的数据与所述问题描述中的数据比对，对所述目标指标进行定位；根据所述目标指标的指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标。

该实现方式中，基于质量问题和业务系统的知识图谱构建质量问题知识图谱，根据质量问题知识图谱中目标指标的物理位置提取该目标指标对应的数据，并将目标指标对应的数据与问题描述中的数据比对，对目标指标进行定位，再根据目标指标的加工规则和核对依据指标数值，确定业务系统的源头问题指标，实现了对业务系统的源头问题指标的定位。

在一种可能的实现方式中，所述根据所述业务系统的源头问题指标、所述常用分析路径和所述核对依据指标数值，确定所述业务系统的源头问题数据，包括：根据所述业务系统的常用分析路径提取与所述源头问题指标的相关数据；将所述源头问题指标的相关数据与所述核对依据指标数值进行比对，得到目标数据，所述目标数据为所述源头问题指标的相关数据中与所述核对依据指标数值相差最大的数据；对所述目标数据进行分析，得到所述业务系统的源头问题数据。

该实现方式中，根据业务系统的常用分析路径提取源头问题指标的相关数据；将源头问题指标的相关数据与数据核对依据进行比对，得到目标数据；对目标数据进行分析，得到业务系统的源头问题数据，实现了对业务系统的源头问题数据的定位。

在一种可能的实现方式中，所述方法还包括：通过知识融合与知识推理将所述业务系统的源头问题指标和所述业务系统的源头问题数据更新至所述业务系统的知识图谱。

该实现方式中，将业务系统的源头问题指标和源头问题数据更新至业务系统的知识图谱中，进一步提高了业务系统的知识图谱的准确度。

在一种可能的实现方式中，所述方法还包括：接收用户输入的反馈信息；若所述反馈信息指示所述业务系统的源头问题指标和/或所述业务系统的源头问题数据错误，则根据所述反馈信息重新对所述业务系统进行分析。

第二方面，本申请提供一种数据问题的分析装置，所述装置可以包括用于实现第一方面中的方法的各个模块，这些模块可以通过软件和/或硬件的方式实现。

第三方面，本申请提供一种数据问题的分析装置。该装置可以包括与存储器耦合的处理器。其中，该存储器用于存储程序代码，该处理器用于执行该存储器中的程序代码，以实现第一方面或其中任意一种实现方式中的方法。

可选地，该装置还可以包括该存储器。

第四方面，本申请提供一种芯片，包括至少一个处理器和通信接口，所述通信接口和所述至少一个处理器通过线路互联，所述至少一个处理器用于运行计算机程序或指令，以执行如第一方面或其中任意一种可能的实现方式所述的方法。

第五方面，本申请提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行如第一方面或其中任意一种可能的实现方式所述的方法。

第六方面，本申请提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行如第一方面或其中任意一种可能的实现方式所述的方法。

第七方面，本申请提供一种计算设备，包括至少一个处理器和通信接口，所述通信接口和所述至少一个处理器通过线路互联，所述通信接口与目标系统通信，所述至少一个处理器用于运行计算机程序或指令，以执行如第一方面或其中任意一种可能的实现方式所述的方法。

第八方面，本申请提供一种计算系统，包括至少一个处理器和通信接口，所述通信接口和所述至少一个处理器通过线路互联，所述通信接口与目标系统通信，所述至少一个处理器用于运行计算机程序或指令，以执行如第一方面或其中任意一种可能的实现方式所述的方法。

附图说明

图1为本申请的实施例的一种系统架构的示意图；

图2为本申请的实施例的一种数据问题的分析方法的流程示意图；

图3为本申请一个实施例的数据问题的分析装置的示意性结构图；

图4为本申请一个实施例提供的数据问题的分析装置的结构示意图。

具体实施方式

下面将结合本申请的实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请公开的数据问题的分析方法及相关装置可用于人工智能领域，也可用于除人工智能领域以外的任意领域，本申请对应用领域不作限定。

图1为本申请的实施例的一种系统架构的示意图。如图1所示，数据问题分析系统100包括数据来源层110、数据接入层120、数据计算层130和数据展示层140。

数据来源层110用于获取业务系统的结构化数据和非结构化数据。其中，非结构化数据的来源主要为业务系统的项目文档和业务问题记录，结构化数据主要包括数据库中存储的业务系统的业务数据。例如，非结构化数据包括业务系统的需求文档、设计文档、业务提供的数据核对依据、业务问题处理的跟踪问题记录等，需求文档、设计文档和业务提供的数据核对依据用于提取业务系统的相关业务知识，业务问题处理的跟踪记录用于提取业务系统的常用分析路径和待分析业务问题。结构化数据主要包括相关数据库对象集合(schema)中的业务数据。

数据接入层120用于数据接入和标准化处理，将获取的业务系统的非结构化数据和结构化数据映射为三元组形式。例如，针对非结构化数据和结构化数据分别通过自然语言处理(natural language processing，NLP)或者关系数据库与资源描述框架的映射语言(relational database to resource description framework mapping language，R2RML)进行转化，并对转化后的数据做标准化处理。

数据计算层130用于确定业务系统的源头问题指标和源头问题数据，对业务系统的数据问题进行定位。其中，数据计算层130包括知识图谱构建模块131、问题指标定位模块132、知识图谱分析模块133和历史问题融合模块134。

知识图谱构建模块131用于根据标准化后的非结构化数据和结构化数据构建业务系统的知识图谱；问题指标定位模块132用于根据业务系统的问题描述拆解问题，并根据知识图谱提供的指标加工规则和核对依据指标数据，确定业务系统的源头问题指标；知识图谱分析模块133用于结合业务系统的相关业务知识进行知识推理，根据常用分析路径和核对依据指标数据确定业务系统的源头问题数据；历史问题融合模块134用于通过知识融合与知识推理不断将业务系统的源头问题指标和源头问题数据更新至知识图谱中。

数据展示层140用于展示业务系统的分析过程和分析结论，并实现与用户的交互。其中，数据展示层140包括交互式问题分析模块141、问题检索模块142和常用分析路径模块143。交互式问题分析模块141用于向用户展示业务系统的可视化分析过程和分析结论，并由用户确认分析结果是否正确，如不正确，则可以进行纠正，并重新启动数据计算层130的相关模块功能进行重新分析；如果正确，则由用户进行后续跟踪处理，问题处理完毕后，用户可关闭该问题。问题检索模块142用于根据用户需求对业务系统的历史问题进行检索和显示；常用分析路径模块143用于根据用户需求对业务系统的常用分析路径进行查找和显示。

可以理解的是，图1所示的系统架构仅是本申请提供的数据问题分析系统的一种示例，在本申请另一些实施例中，数据问题分析系统100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或软件和硬件的组合实现，本申请不作限定。

图2为本申请的实施例的一种数据问题的分析方法的流程示意图。如图2所示，该方法至少包括S201至S204。

S201，获取业务系统中的非结构化数据和结构化数据，非结构化数据包括业务系统的需求文档、设计文档、数据核对依据和问题处理跟踪记录，结构化数据包括业务系统的业务数据，数据核对依据包括核对依据指标和核对依据指标数值，问题处理跟踪记录包括业务系统的常用分析路径和问题描述。

业务系统的非结构化数据的来源主要为项目文档和业务问题记录，结构化数据主要包括数据库中存储的业务数据。

具体地，非结构化数据主要有业务系统的需求文档、设计文档、业务提供的数据核对依据和业务问题处理的跟踪问题记录，其中，需求文档、设计文档和业务提供的数据核对依据用于提取相关业务知识，业务问题处理的跟踪记录用于提取业务系统的常用分析路径和待分析业务问题的问题描述。结构化数据主要包括相关schema中的业务数据。其中，数据核对依据包括核对依据指标和核对依据指标数值，待分析业务问题的问题描述包括待分析业务的问题指标和问题数据。

可选的，业务提供的数据核对依据可以为业务系统中各类业务中的每个业务指标以及每个业务指标对应的参考值。

可选的，业务系统的常用分析路径可以包括业务系统中的任意一个指标出现数据问题时最常使用的分析路径，其中，分析路径可以包括任意一个指标在全链路中的指标加工公式。

可选的，待分析业务问题的问题描述可以包括待分析业务中出现问题的指标和该指标对应的数值。

S202，根据非结构化数据和结构化数据构建业务系统的知识图谱，知识图谱的逻辑概念包括产品、指标、质量问题和核对依据指标，知识图谱包括业务系统的指标加工规则。

在一种可能的实现方式中，在根据非结构化数据和结构化数据构建业务系统的知识图谱之前，对业务系统的非结构化数据和结构化数据进行转化，再对转化后的非结构化数据和结构化数据进行标准化处理。

示例性的，通过NLP技术或R2RML技术对非结构化数据和结构化数据进行转化，得到转化后的非结构数据和转化后的结构数据；再对转化后的非结构数据和转化后的结构数据进行标准化处理，得到标准化后的非结构数据和标准化后的结构数据。例如，标准化处理方法包括最小-最大标准化(min-max normalization)、小数定标标准化和标准差标准化等。

在一种可能的实现方式中，本申请实施例提供的业务系统的知识图谱采用网络本体语言(web ontology language，OWL)形式进行组织，由于领域知识图谱有非常明确的行业应用目的，对知识图谱的专业性和准确性要求非常高，故采用自顶向下的方法，根据专家经验进行本体建模。

与广泛的知识图谱实践一样，实体是业务系统知识图谱的基础要素，是整个模型的“砖瓦”，而实体间的关系则为这个模型的构建框架，使模型变得立体化与具象化，同时实体属性和关系属性则描述了每个实体和关系的个性特征，使整个模型成为现实世界中业务系统的映射。

其中，实体指的是具有可区别性且独立存在的某种事物。如某一个人、某一个城市、某一种植物、某一种商品等。实体是知识图谱中的最基本元素，不同的实体间存在不同的关系。进一步通过一系列的属性来描述这个实体，用以描述实体间的差别。

实体属性指用来描述实体特征的指向，每一个实体都具有多个特性，每一个特性称为属性。一个实体的实例是由属性指向它的属性值而形成，例如“客户姓名”是“客户”的一个属性，而这个属性指向“张三”这个明确的属性值，其数据类型可以是整数型、日期型、字符串型等。

在构建知识图谱的过程中必须明确的是实体的属性，对于同一个实体只能包含一个同名的属性，并要对该属性的含义予以说明，例如，通过枚举方式表示值的，需要明确枚举范围。同时为了保证实体间关系的可溯源性，需要明确实体属性的来源，该来源一般包括两类：父类继承和关系产生。父类继承表示，该属性来源自其父类实体，是由父类实体的某个属性直接引用或演化而来的，如“客户名称”是“客户”实体的一个属性，但是站在“个人客户”角度来说，往往是用“姓名”来形容一个人的称谓，所以“客户姓名”是一个从“客户名称”继承演化而来的属性。对于属性“社会保险号”是由客户缴纳社会保险而持有的“社保卡”而来的，所以从客户角度而言，“个人客户”的“社会保险号”就是实体“社保卡”的“社会保险号”属性。

数据对象彼此之间相互连接的方式称为关系，也称为联系。实体关系是为展现孤立的实体节点之间复杂而多样的拓扑结构而构建的网络，例如，在金融领域的知识图谱的构建过程中，通常着重于展现银行或金融机构的业务与IT系统中实体间的关系。

实体识别完成后，则可以进一步建立实体间关系，关系的内容包括：关系名称、方向、条件、关系属性等。通过对不同实体的识别和划分，从而明确实体间的关系类型，建立对应的实体间关系。

关系属性指用来描述实体间关系的特征。不同的关系之间存在一定程度上共性特征和个性特征，然而对于建立在不同实体之间相同的关系也存在着个性特征。如果说当实体拥有了明确存在着的实例时，实体属性才存在明确的值；对于关系而言，实体间关系一旦建立就是建立了这个关系的一个实例，相应的，这个关系实例的属性也有了明确的值。

业务系统的知识图谱的知识抽取的过程主要来源于两个方向，一方面是在银行业业务领域与科技领域工作多年，具备丰富业务经验与开发经验的专家，包括银行业各业务线的业务专家、银行互联网技术(internet technology，IT)架构咨询专家以及银行IT治理专家等，将他们的经验通过报告、文档、头脑风暴会议等诸多形式进行汇总收集，作为知识来源的重要基础；另一方面关于银行业行业知识与完整的业务系统的知识图谱模型等相关内容在多年的积累中所沉淀的文档、知识库、数据库表结构等非结构化或半结构化数据同样是知识图谱构建的重要知识来源。

知识图谱模型的构建是建立实体与实体间关系的过程，是通过实体识别、实体属性识别、实体关系识别、关系属性识别等一系列处理过程实现的。

在本实施例中，对于实体的识别采用“自上而下”的方式。其中，“自上而下”的方式指先参照既有的数据模型、整理的业务知识为图谱定义数据实体完成基础建模，而后进行实体属性、实体关系的建模，再将实体融合到图谱中，该构建方式需要利用一些现有的结构化知识库作为其基础知识库，层级延伸出相关实体内容。

本体是对概念进行建模的规范，是描述客观世界的抽象模型，以形式化方式对概念及其之间的联系给出明确定义。本体层是一种由核心实体和代表关系组成的树状结构，这种拓展的关系有助于知识推理和延展，后续不断补充的实体都是本体层的拓展，而实体关系的补充则是本体层关系的特征化。在知识图谱中，本体是建设的基础，用于描述实体层次关系体系，是知识图谱中知识的概念模板。

在知识图谱构建之初，首先应健全知识图谱的本体架构，即采用自上向下的构建方式为知识图谱搭建骨架，所依赖的是基于领域驱动建模的方法，划定业务系统知识图谱的研究领域和研究范围，明确相关领域之间的领域上下文关系。

在前期的本体层构建工作中需要对一些基础的本体类的核心实体进行识别和关系的确定，该过程是一个重要的框架设计，是后期知识图谱建设范围和方向的指导，所以需要专家组对核心实体进行人工识别和定义。

示例性的，本体层构建主要包括以下几个步骤：

步骤一，选取核心实体并建立核心实体派生关系。

根据知识图谱的建设目标，基于领域建模技术从数据模型中选定核心实体并建立该实体的派生关系，通过这种方式确定研究领域，明确知识图谱的范围和层次关系。

步骤二，构建核心实体间的关系。

基于数据模型中的朴素关系构建核心实体之间的主要联系，结合头脑风暴会议分批次对核心实体的关系进行整理。

步骤三，回归验证框架可用性。

将全部三元组落入图数据库，基于主体业务流程在图数据库上进行核对验证，检查是否有遗漏。

最终，将完整图谱录入图数据库中，以供后续分析和优化。

在完成了知识图谱的框架建设之后，需要持续性的完善图谱，包括从结构化文档和非结构化文档中抽取和识别三元组补充到图谱中，同时验证检查当前图谱并迭代更新。

示例性的，本申请的实施例提供的业务系统的知识图谱的概念分为逻辑概念和物理概念。其中，逻辑概念包括产品、指标、核对依据指标和质量问题；物理概念包括schema、表、视图、字段。

产品属性包括产品种类、产品层级，指标属性包括粒度、维度、时间、限制条件，核对依据指标属性包括粒度、维度、时间、限制条件，质量问题的属性包括问题分类、问题性质、数值。schema的属性包括技术平台、容量、用户、权限等，表属性包括schema、视图、时效、用户、权限等，视图属性包括字段、用户、权限等，字段属性包括长度、精度、涉敏信息等。

描述属性的限制包括但不限于：指标属性粒度、维度、时间、限制条件必须同时存在、每一个用户必然存在一个权限等。

本体间的关系包括产品与产品间的上下级关系、产品与指标间的描述关系、质量问题与产品间的从属关系、质量问题与指标间的从属关系、表与产品间的映射关系、表与指标间的映射关系、表与字段间的属性关系、维度与指标间的属性关系、时间与指标间的属性关系、限制条件与指标间的属性关系、问题性质与质量问题间的描述关系等等。

最终形成的三元组采用图数据库进行存储，图数据库包括但不限于开源数据库RDF4j、gStroe或者原生图数据库Neo4j等。

S203，根据业务系统的问题描述、指标加工规则和核对依据指标数值，确定业务系统的源头问题指标。

在一种可能的实现方式中，基于质量问题和业务系统的知识图谱，推理补充质量问题的缺失信息，得到质量问题知识图谱，质量问题知识图谱包括目标指标的物理位置；将根据物理位置提取的目标指标对应的数据与问题描述中的问题数据比对，对目标指标进行定位；根据目标指标的指标加工规则和核对依据指标数值，确定业务系统的源头问题指标。

作为一种示例，根据业务系统的问题描述、指标加工规则和核对依据指标数值确定业务系统的源头问题指标可以包括以下步骤：

步骤一，将根据质量问题描述提取出来的问题分类、问题性质、产品、指标、维度、限制条件、日期、shema、表、字段等实体及属性与业务系统的知识图谱通过记录链接实现实体融合，再推理补充质量问题的缺失信息，得到完整质量问题知识图谱。

示例性的，假设当前业务问题为“2020年全行法人客户存款营业贡献为50亿，而动产(mova)产品贡献为60亿”，则该问题知识图谱表述的完整信息应为从A表提取全行法人存款的营业贡献合计值，限制条件为法人客户，且时间范围为2020年全年，对应物理位置为Sschema的A表。然后根据物理位置提取的营业贡献合计值与问题描述中的数值比对，由此重现问题，定位目标指标。

步骤二，采用深度优先遍历算法，从目标指标节点开始处理。从客户贡献知识图谱中的指标加工关系中得到目标指标的加工公式，并获得指标加工全链路的所有过程指标的加工公式。

步骤三，提取与目标指标存在加工关系的点和边获得该目标指标的计算公式。

示例性的，若目标指标为存款营业贡献，则提取的存款营业贡献的计算公式为存款营业贡献＝内部资金计价收入-利息支出。

步骤四，以目标指标为存款营业贡献为例，根据存款营业贡献生物计算公式，分别提取内部资金计价收入和利息支出的实际数值与核对依据指标数值中内部资金计价收入和利息支出对应的数据进行比对，假设发现内部资金计价收入与核对依据一致，而利息支出与核对依据不一致，则执行步骤五。

步骤五，内部资金计价收入分支流程结束，利息支出返回步骤二继续提取加工关系获得利息支出的计算公式，根据步骤三得到存款利息支出的计算公式为存款利息支出＝应付利息+应付未付利息+实付利息，参考步骤四分别提取三个指标因子应付利息、应付未付利息和实付利息的现有实际数据与核对依据指标数值进行比对。通过执行步骤五发现实付利息的实际值与核对依据指标数值中对应的参考值存在较大差异，则应付利息和应付未付利息分支流程结束，实付利息再次返回步骤二继续提取加工关系获得其计算公式，通过步骤三得到实付利息的计算公式为实付利息＝XX应用YY文件ZZ字段，通过步骤四发现现有知识图谱中缺少XX应用YY文件ZZ字段的核对依据，则回到实付利息分析节点，并确定存款实付利息指标为源头问题指标。

S204，根据业务系统的源头问题指标、常用分析路径和核对依据指标数值，确定业务系统的源头问题数据。

在一种可能的实现方式中，根据业务系统的常用分析路径提取源头问题指标的相关数据；将源头问题指标的相关数据与核对依据指标数值进行比对，得到目标数据，目标数据为源头问题指标的相关数据中与核对依据指标数值相差最大的数据；对目标数据进行分析，得到业务系统的源头问题数据。

作为一种示例，根据业务系统的源头问题指标、常用分析路径和核对依据指标数值确定业务系统的源头问题数据可以包括以下步骤：

步骤一，定位源头问题指标之后，已知以往问题记录得到的常用分析路径已经融合入现有业务系统的知识图谱模型中，针对类似机构维度数据问题，提取差异最大机构且差异最大月份的单客户明细数据进行分析。

示例性的，当业务系统的源头问题指标为存款实付利息时，常用分析路径包括客户营业贡献、利息支出和实收利息等。

步骤二，根据存款实付利息指标的常用分析路径，系统自动提取数据库中相关单客户X营业贡献、利息支出、实收利息实体数值，并将其与核对依据指标数值中的对应数值进行比对。

步骤三，对客户X存款实收利息开展业务合理性分析。

示例性的，通过族群发现算法，根据加工过程紧密度将不同产品不同指标的业务知识进行区分，由此得到存款业务的营业贡献在逻辑概念下主要存在如下公理：

exp:exists(存款业务，利息支出)

exp:exists(存款业务，内部资金计价收入)

利息支出exp:coexist内部资金计价收入

exp:calc(营业贡献，利息支出)

exp:calc(营业贡献，内部资金计价收入)

exp:calc(利息支出，应付利息)

exp:calc(利息支出，应付未付利息)

exp:calc(利息支出，实收利息)：季度末

比对客户X的实体情况，发现没有满足exp:calc(利息支出，实收利息)：季度末的数据，即6月份缺少实收利息，故问题原因是存款6月份缺少实收利息。

步骤四，根据提取的实收利息的加工过程，提取XX应用YY文件ZZ字段的实体数据，同样未满足exp:calc(利息支出，实收利息)：季度末公理，最终追溯到问题源头为XX应用YY文件ZZ字段丢失实收利息数据。

在一种可能的实现方式中，在确定了业务系统的源头问题指标和源头问题数据后，通过知识融合与知识推理将业务系统的源头问题指标和业务系统的源头问题数据更新至业务系统的知识图谱中。

在一种可能的实现方式中，接收用户输入的反馈信息；若该反馈信息指示业务系统的源头问题指标和/或业务系统的源头问题数据错误，则根据反馈信息重新对该业务系统进行分析。

作为一种示例，在确定业务系统的源头问题指标和源头问题数据后，向用户展示可视化分析分析过程，并展示分析结论，由用户确认分析结果是否正确，如不正确，则可以进行纠正，并对业务系统的数据问题进行重新分析，如果正确，则由用户进行后续跟踪处理，将该问题结论发送给XX应用YY文件的数据属主，确认该问题是否属实，进而跟进后续问题处理，问题处理完毕后，用户关闭该问题。

另外，还可以提供历史问题和查用分析路径查询服务，便于用户进行了解历史问题和学习常用分析方法，实现知识分享与传承。

本申请提供的技术方案，通过获取的业务系统的非结构化数据和结构化数据构建业务系统的知识图谱，并结合该业务系统的知识图谱、业务系统的问题描述、常用分析路径和指标加工规则等，确定业务系统的源头问题指标和源头问题数据，实现了业务系统的问题定位，提高了业务系统的问题定位的效率，节约了时间，节省了人力资源。

图3为本申请一个实施例的数据问题的分析装置的示意性结构图。如图3所示，装置300可以包括获取模块301、构建模块302和确定模块303。

本申请实施例中的获取模块、构建模块和确定模块中任意模块可以全部或部分通过软件和/硬件方式实现。其中，通过软件实现的部分可以在处理器上运行以实现相应的功能，通过硬件方式实现的部分可以是处理器的构成部分。

装置300可以用于实现图2所示的方法。

图4为本申请一个实施例提供的数据问题的分析装置的结构示意图。图4所示的装置400可以用于执行前述任意一个实施例所述的方法。

如图4所示，本实施例的装置400包括：存储器401、处理器402、通信接口403以及总线404。其中，存储器401、处理器402、通信接口403通过总线404实现彼此之间的通信连接。

存储器401可以是只读存储器(read only memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(random access memory，RAM)。存储器401可以存储程序，当存储器401中存储的程序被处理器402执行时，处理器402可以用于执行图2所示的方法的各个步骤。

处理器402可以采用通用的中央处理器(central processing unit，CPU)，微处理器，应用专用集成电路(application specific integrated circuit，ASIC)，或者一个或多个集成电路，用于执行相关程序，以实现本申请方法实施例的数据问题的分析方法。

处理器402还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本申请各个实施例的方法的各个步骤可以通过处理器402中的硬件的集成逻辑电路或者软件形式的指令完成。

上述处理器402还可以是通用处理器、数字信号处理器(digital signalprocessing，DSP)、专用集成电路(ASIC)、现成可编程门阵列(field programmable gatearray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器401，处理器402读取存储器401中的信息，结合其硬件完成本申请实施例中各个方法所需执行的功能，例如，可以执行图2所示实施例的各个步骤/功能。

通信接口403可以使用但不限于收发器一类的收发装置，来实现装置400与其他设备或通信网络之间的通信。

总线404可以包括在装置400各个部件(例如，存储器401、处理器402、通信接口403)之间传送信息的通路。

应理解，本申请实施例所示的装置400可以是电子设备，或者，也可以是配置于电子设备中的芯片。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A,B可以是单数或者复数。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系，但也可能表示的是一种“和/或”的关系，具体可参考前后文进行理解。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种数据问题的分析方法，其特征在于，所述方法包括：

获取业务系统中的非结构化数据和结构化数据，所述非结构化数据包括所述业务系统的需求文档、设计文档、数据核对依据和问题处理跟踪记录，所述结构化数据包括所述业务系统的业务数据，所述数据核对依据包括核对依据指标和核对依据指标数值，所述问题处理跟踪记录包括所述业务系统的常用分析路径和问题描述；

根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱，所述知识图谱的逻辑概念包括产品、指标、质量问题和所述核对依据指标，所述知识图谱包括所述业务系统的指标加工规则；

根据所述业务系统的问题描述、所述指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标；

根据所述业务系统的源头问题指标、所述常用分析路径和所述核对依据指标数值，确定所述业务系统的源头问题数据。

2.根据权利要求1所述的方法，其特征在于，在所述根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱之前，所述方法还包括：

通过自然语言处理技术NLP或关系数据库与资源描述框架的映射语言R2RML对所述非结构化数据和所述结构化数据进行转化，得到转化后的非结构数据和转化后的结构数据；

对所述转化后的非结构数据和所述转化后的结构数据进行标准化处理，得到所述标准化后的非结构数据和所述标准化后的结构数据；

相应地，所述根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱，包括：根据所述标准化后的非结构化数据和所述标准化后的结构化数据构建所述业务系统的知识图谱。

3.根据权利要求2所述的方法，其特征在于，所述业务系统的知识图谱的物理概念包括数据库对象集合、表、视图、字段。

4.根据权利要求3所述的方法，其特征在于，所述知识图谱中的关系包括所述产品间的上下级关系、所述产品与所述指标间的描述关系、所述质量问题与所述产品间的从属关系、所述质量问题与所述指标间的从属关系、所述表与所述产品间的映射关系、所述表与所述指标间的映射关系、所述表与所述字段间的属性关系、所述维度与所述指标间的属性关系、所述时间与所述指标间的属性关系、所述限制条件与所述指标间的属性关系、所述问题性质与所述质量问题间的描述关系。

5.根据权利要求4所述的方法，其特征在于，所述根据所述业务系统的问题描述、所述指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标，包括：

基于所述质量问题和所述知识图谱，推理补充所述质量问题的缺失信息，得到质量问题知识图谱，所述质量问题知识图谱包括目标指标的物理位置；

将根据所述物理位置提取的所述目标指标对应的数据与所述问题描述中的数据比对，对所述目标指标进行定位；

根据所述目标指标的指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标。

6.根据权利要求5所述的方法，其特征在于，所述根据所述业务系统的源头问题指标、所述常用分析路径和所述核对依据指标数值，确定所述业务系统的源头问题数据，包括：

根据所述业务系统的常用分析路径提取所述源头问题指标的相关数据；

将所述源头问题指标的相关数据与所述核对依据指标数值进行比对，得到目标数据，所述目标数据为所述源头问题指标的相关数据中与所述核对依据指标数值相差最大的数据；

对所述目标数据进行分析，得到所述业务系统的源头问题数据。

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

通过知识融合与知识推理将所述业务系统的源头问题指标和所述业务系统的源头问题数据更新至所述业务系统的知识图谱。

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

接收用户输入的反馈信息；

若所述反馈信息指示所述业务系统的源头问题指标和/或所述业务系统的源头问题数据错误，则根据所述反馈信息重新对所述业务系统进行分析。

9.一种数据问题的分析装置，其特征在于，所述装置包括：

获取模块，用于获取业务系统中的非结构化数据和结构化数据，所述非结构化数据包括所述业务系统的需求文档、设计文档、数据核对依据和问题处理跟踪记录，所述结构化数据包括所述业务系统的业务数据，所述数据核对依据包括核对依据指标和核对依据指标数值，所述问题处理跟踪记录包括所述业务系统的常用分析路径和问题描述；

构建模块，用于根据所述非结构化数据和所述结构化数据构建所述业务系统的知识图谱，所述知识图谱的逻辑概念包括产品、指标、质量问题和所述核对依据指标，所述知识图谱包括所述业务系统的指标加工规则；

确定模块，用于根据所述业务系统的问题描述、所述指标加工规则和所述核对依据指标数值，确定所述业务系统的源头问题指标；

所述确定模块，还用于根据所述业务系统的源头问题指标、所述常用分析路径和所述核对依据指标数值，确定所述业务系统的源头问题数据。

10.一种数据问题的分析装置，其特征在于，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如权利要求1至8中任一项所述的方法。

11.一种芯片，其特征在于，包括至少一个处理器和通信接口，所述通信接口和所述至少一个处理器通过线路互联，所述至少一个处理器用于运行计算机程序或指令，以执行如权利要求1至8中任一项所述的方法。

12.一种计算机可读介质，其特征在于，所述计算机可读介质存储用于计算机执行的程序代码，该程序代码包括用于执行如权利要求1至8中任一项所述的方法。

13.一种计算机程序产品，其特征在于，所述计算机程序产品包括指令，当所述指令被执行时，使得计算机执行权利要求1至8中任一项所述的方法。

Images