一种风控特征血缘关系的确定方法及装置

技术领域

本文涉及风控特征领域，尤其涉及一种风控特征血缘关系的确定方法及装置。

背景技术

随着业务不断推广创新，线上存在包括数据源，标准特征，衍生特征等多种形式的风控特征数据，数据源包括自有用户的采集数据，比如用户短信、通讯录、设备信息等，标准特征是指有且仅有一个依赖数据源计算得到的特征，而衍生特征则可以同时依赖多个数据源以及多个标准特征或衍生特征的输出结果进行计算得到。各种模型和策略可使用特征数据，鉴于特征数据种类以及数量繁多，各种模型和策略所用的特征数据关系混乱，难以维护。为了能够在大量的特征、数据源中追踪数据的流向，查看数据系统中风险数据的上游数据的来源和下游数据的去向，完成数据治理中至关重要的一个环节，血缘关系的建立是不可或缺的。

现有技术中，一种数据血缘关系的整理方法为：从含有SQL代码的脚本文件中提取规则化的SQL语句，完成对SQL语句的清洗；再对规则化的SQL语句进行词法分析，生成并遍历抽象语法树对SQL语句进行句法解析；然后根据抽象语法树对SQL语句进行血缘关系分析，得到血缘关系分析结果；最后根据血缘关系分析结果绘制SQL语句的数据血缘关系图，并进行可视化显示。该种数据血缘关系的整理方法存在如下缺陷：仅考虑了SQL，未对数据应用(例如风控事件步骤)的血缘关系进行梳理，无法满足发掘特征间依赖关系的场景。

现有技术中，另一种数据血缘关系的整理方法为：解析SQL语句形成语法树，将采集的节点数据关系存储于neo4j图形数据库，将采集的必要信息存储于HBase；将异构数据源的信息引入血缘关系系统，形成血缘关系。该种数据血缘关系的整理方法存在如下缺陷：仅考虑了SQL，未对数据应用的血缘关系进行梳理，不能及时发现未在使用的数据。

发明内容

本文用于解决现有技术中特征数据血缘关系确定存在依赖SQL，不适用于多数据来源及存在复杂血缘关系的数据场景的问题。

为了解决上述技术问题，本文第一方面提供一种风控特征血缘关系的确定方法，风控特征包括风控的数据源及衍生特征，所述方法包括：

对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，所述特征代码中反映风控特征间的引用关系；

利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系；

由所述第一依赖关系及第二依赖关系构成风控特征血缘关系。

作为本文进一步实施例中，对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系包括：

对特征代码进行信息提取，得到多条向量边，每条向量边上的节点为风控特征；

利用第二递归栈算法对向量边进行分析，得到风控特征之间的第一依赖关系。

作为本文进一步实施例中，利用第二栈递归算法，对向量边进行分析，得到风控特征之间的第一依赖关系包括：

从所有向量边的风控特征中，选择其中之一风控特征作为递归根节点；

根据所有向量边，确定递归根节点的父级节点，并将其存入第二父级栈；

根据所有向量边，确定递归根节点的子级节点，并将其存入第二子级栈；

执行第二父级递归流程：取出第二父级栈中的栈顶节点，判断取出节点是否为数据源，若是，则不作处理，若否，则从所有向量边中查询该取出节点的父级节点，并将其存入第二父级栈，重复上述过程，直至第二父级栈为空；

执行第二子级递归流程：取出第二子级栈中的栈顶节点，从所有向量边中查询取出节点的子级节点，并将其存入至第二子级栈，重复上述过程，直至第二子级栈为空；

第二父级递归流程及第二子级递归流程中记录父级节点与子级节点之间的依赖关系，该依赖关系即为风控特征值之间的第一依赖关系；

其中，第二父级递归流程及第二子级递归流程并行进行。

作为本文进一步实施例中，利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系包括：

对于每一目标事件，按照如下流程建立该目标事件下风控特征与对应目标事件步骤之间的第二依赖关系：

从第一依赖关系中，选择该目标事件中某个步骤的风控特征为递归根节点；

根据第一依赖关系，确定递归根节点的父级节点，并将其存入第一父级栈；

根据第一依赖关系，确定递归根节点的子级节点，并将其存入第一子级栈；

执行第一父级递归流程：取出第一父级栈中栈顶节点，对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点对应的目标事件步骤，将取出节点的父级节点存入第一父级栈，重复上述过程，直至第一父级栈为空；

执行第一子级递归流程：取出第一子级栈中栈顶节点，对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点是否存在目标事件步骤，若存在，则将取出节点的子级节点存入第一子级栈，重复上述过程，直至第一子级栈为空；

第一父级递归流程及第一子级递归流程中记录风控特征与对应目标事件步骤之间的第二依赖关系；

其中，第一父级递归流程及第一子级递归流程并行进行。

作为本文进一步实施例中，第一父级递归流程中对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点对应的目标事件步骤包括：

确定取出节点对应的每一线上步骤与确定出该取出节点的子级节点对应目标事件步骤的一致性；

根据取出节点对应的每一线上步骤与确定出该取出节点的子级节点对应目标事件步骤的一致性，对取出节点对应的每一线上步骤进行评分；

将得分最高的线上步骤作为取出节点对应的目标事件步骤。

作为本文进一步实施例中，第一子级递归流程中对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点是否存在目标事件步骤包括：

确定取出节点对应的每一线上步骤与确定出该取出节点的父级节点对应的目标事件步骤的一致性；

根据取出节点对应的每一线上步骤与确定出该取出节点的父级节点对应的目标事件步骤的一致性，对取出节点对应的每一线上事件步骤进行评分；

若取出节点对应的每一线上步骤的得分均为预定值，则确定取出节点不存在目标事件步骤；

若取出节点对应的线上步骤的得分中至少存在一个大于预定值，则将得分大于预定值的线上步骤作为取出节点对应的目标事件步骤。

作为本文进一步实施例中，节点间步骤的一致性包括：节点间第一依赖关系与节点间的步骤先后顺序的一致性，以及节点间步骤名称一致性。

作为本文进一步实施例中，还包括：

对于每一事件步骤下的风控特征，判断该风控特征是否具有衍生特征以及该事件步骤的策略文件中是否引用该风控特征，若判断结果为否，则在该事件步骤中对该风控特征做下线处理。

作为本文进一步实施例中，还包括：

获取线上所有在用策略文件，每一策略文件中至少包括一决策文件；

根据风控特征命名规则，确定的每一决策文件中的在用风控特征；

建立决策文件及其在用风控特征之间的第三依赖关系。

作为本文进一步实施例中，还包括：以树形图方式展示风控特征血缘关系，其中，树形图中节点为风控特征及风控特征对应事件步骤。

本文第二方面提供一种风控特征血缘关系的确定装置，风控特征包括风控的数据源及衍生特征，所述装置包括：

第一关系确定单元，用于对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，所述特征代码中反映风控特征间的引用关系；

第二关系确定单元，用于利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系；

组合单元，用于由所述第一依赖关系及第二依赖关系构成风控特征血缘关系。

本文第三方面提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现前述任意一项所述方法。

本文第四方面提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被计算机设备的处理器执行时实现前述任一实施例所述方法。

本文第五方面提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被计算机设备的处理器执行时实现前述任一实施例所述方法。

本文提供的风控特征血缘关系的确定方法及装置，除了通过对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，还利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系，由第一依赖关系及第二依赖关系构成风控特征血缘关系，本文适用于风控特征上线于多种事件步骤的复杂血缘关系梳理，能够提高血缘关系梳理的全面性。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1示出了本文实施例风控特征血缘关系的确定方法的第一流程图；

图2示出了本文实施例第一依赖关系确定过程的流程图；

图3示出了本文实施例第二递归栈算法执行过程的流程图；

图4示出了本文实施例第二依赖关系确定过程的流程图；

图5示出了本文实施例节点步骤评分过程的流程图；

图6示出了本文实施例节点目标事件步骤确定过程的流程图；

图7示出了本文实施例风控特征血缘关系的确定方法的第二流程图；

图8示出了本文实施例风控特征血缘关系的确定装置的第一结构图；

图9示出了本文实施例风控特征血缘关系的确定装置的第二结构图；

图10A示出了本文实施例风控特征依赖关系的示意图；

图10B示出了本文实施例风控特征间的事件步骤的依赖关系的示意图；

图11示出了本文实施例计算机设备的结构图。

附图符号说明：

801、第一关系确定单元；

802、第二关系确定单元；

803、组合单元；

804、第三关系确定单元；

805、第四关系确定单元；

1102、计算机设备；

1104、处理器；

1106、存储器；

1108、驱动机构；

1110、输入/输出模块；

1112、输入设备；

1114、输出设备；

1116、呈现设备；

1118、图形用户接口；

1120、网络接口；

1122、通信链路；

1124、通信总线。

具体实施方式

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

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

需要说明的是，本文的风控特征血缘关系的确定方法及装置可用于金融领域，例如银行系统，也可用于除金融领域之外的任意领域，本文的风控特征血缘关系的确定方法及装置的应用领域不做限定。

需要说明的是，本申请所涉及的风控特征数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的数据。

本文一实施例中，提供一种风控特征血缘关系的确定方法，用于解决现有特征血缘关系的确定方法存在血缘关系确定不全面，不适用于将风控特征上线于多个事件步骤中的场景。具体的，如图1所示，风控特征血缘关系的确定方法包括：

步骤101，对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，所述特征代码反映风控特征间的引用关系。

详细的说，本文所述的风控特征包括风控的数据源及衍生特征，还可划分为数据源、标准特征及衍生特征，标准特征为一种特殊的衍生特征。数据源为风控接入的所有用于模型训练和决策的数据，包括自有数据(用户数据)以及三方数据等。标准特征包括依赖一个数据源得到的特征(例如以sd结尾的特征)。衍生特征依赖多个数据源或已有衍生特征生成的新的衍生特征(例如以dr结尾的特征)。

每个衍生特征对应一特征代码，特征代码通过引用其它风控特征生成一些特征输出项，特征输出项用于供策略文件作出决策，策略文件可根据业务场景而定，本文对其内部逻辑不做限定。例如衍生特征A的特征代码A，引用了另一衍生特征B的输出项，则衍生特征A依赖衍生特征B。又例如，特征sms_report_sd的特征代码引用短信数据源SmsReportService，可生成特征输出项，例如用户是否预期、工资等等，则sms_report_sd依赖SmsReportService。

第一依赖关系即数据源->特征及特征->特征之间的依赖关系，可以以树状图的形式展示，树状图中的节点为风控特征，树状图中的有向连接边表示节点间的依赖关系，由父级节点指向子级节点。

步骤102，利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系。

详细的说，第二依赖关系即数据源->事件步骤及特征->事件步骤之间的依赖关系，以树状图的形式展示，本文中的风控特征上线于事件步骤中，以根据策略文件决定事件步骤的运转。具体的，事件步骤指的是风控的事件步骤，可由各种业务触发或者风控自身触发的各种事件，例如用户借款、给用户放款、用户还款、进件等。事件以流程图的形式运转，其中运行的节点命名类似A、B、C称之为事件步骤。每个事件步骤当中又包含数据节点(主要负责获取数据源)、特征节点(根据数据源获取的数据计算得到特征)、策略节点(根据特征计算策略结果，以便决定后续流程的运转)。

步骤103，由第一依赖关系及第二依赖关系构成风控特征血缘关系。

本步骤实施时，可将第一依赖关系及第二依赖关系进行整合，将第二依赖关系中的事件步骤作为风控特征的属性添加至第一依赖关系的树状图中。由最后得到的树状图构成风控特征血缘关系。通过第二依赖关系能够避免风险特征事件步骤血缘关系的误判。

具体实施时，第一依赖关系及第二依赖关系以json的形式存入缓存，保证所有的上层查询应用只与缓存交互，并且通过mysql binlog监听的方式对缓存数据进行实时更新。

缓存中的数据模型如下：

{

"type":"节点类型serviceNode数据节点featureNode风险特征节点",

"id":"树形图中唯一id",

"name":"节点名称，包括1.数据源2.标准特征3.衍生特征",

"step":"风险特征对应事件步骤",

"state":"当前节点相较于上级节点的位置，left表示父级节点，right表示子级节点",

"level":节点对应层级,

"children":Array[]"下一级节点，字段与当前节点类似",

}

本实施例除了通过对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，还利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系，由第一依赖关系及第二依赖关系构成风控特征血缘关系，本文适用于风控特征上线于多种事件步骤的复杂血缘关系梳理，能够提高血缘关系梳理的全面性。

本文一实施例中，如图2所示，上述步骤101对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系包括：

步骤201，对特征代码进行信息提取，得到多条向量边，每条向量边上的节点为风控特征。

详细的说，特征代码中包含引用到的风控特征，且引用到的风控特征以预设规则表示，例如以单引号或双引号包围，通过该预设规则即可提取表示引用关系的多条向量边，每条向量边为风控特征之间的依赖关系。

步骤202，利用第二递归栈算法对向量边进行分析，得到风控特征之间的第一依赖关系。

本步骤实施时，为了提高第一依赖关系的确定效率，第二递归栈算法利用父级栈及子级栈并行执行的方式确定风控特征之间的第一依赖关系。

具体的。如图3所示，步骤202的具体执行过程包括：

步骤301，从所有向量边的风控特征中，选择其中之一风控特征作为递归根节点。

本步骤实施时，可随机选定其中之一风控特征作为递归根节点，本文对递归根节点具体为何不做限定。

步骤302，根据所有向量边，确定递归根节点的父级节点，并将其存入第二父级栈。

本步骤实施时，首先确定指向递归根节点的向量边，这些向量边中的非递归根节点即为父级节点。第二父级栈中的节点数据采用先进先出的规则进行获取。

步骤303，根据所有向量边，确定递归根节点的子级节点，并将其存入第二子级栈。

本步骤实施时，首先确定包括递归根节点指向其他节点的向量边，这些向量边中的非递归根节点即为子级节点。同样，第二子级栈中的节点数据也采用先进先出的规则进行获取。

步骤304，执行第二父级递归流程：取出第二父级栈中的栈顶节点，判断取出节点是否为数据源，若是，则不作处理，若否，则从所有向量边中查询该取出节点的父级节点，并将其存入第二父级栈，重复上述过程，直至第二父级栈为空。

当取出节点为数据源时，说明取出节点不再存在叶子节点，若否，则在树形图中记录取出节点及确定出该取出节点之间的边。

步骤305，执行第二子级递归流程：取出第二子级栈中的栈顶节点，从所有向量边中查询取出节点的子级节点，并将其存入至第二子级栈，重复上述过程，直至第二子级栈为空。

第二子级栈中的节点只会是特征，不会是数据源，因此第二子级递归流程中不许判断数据源。

步骤306，第二父级递归流程及第二子级递归流程中记录父级节点与子级节点之间的依赖关系，该依赖关系即为风控特征值之间的第一依赖关系。

其中，第二父级递归流程及第二子级递归流程并行进行。

本文一实施例中，如图4所示，上述步骤102利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系包括：

对于每一目标事件，按照如下流程建立该目标事件下风控特征与对应目标事件步骤之间的第二依赖关系。

本文所述的目标事件可以由用户根据需求进行设定，还可以为线上已有事件中的每一事件。若线上已有事件为100个，则会得到100个第二依赖关系。

步骤401，从第一依赖关系中，选择该目标事件中某个步骤的风控特征为递归根节点。

本步骤实施时，某个步骤可随机确定或由用户指定，本文对此不作限定。

步骤402，根据第一依赖关系，确定递归根节点的父级节点，并将其存入第一父级栈。

本步骤实施时，将第一依赖关系中指向递归根节点的节点作为递归根节点的父级节点。第一父级栈采用先进先出的方式获取数据。

步骤403，根据第一依赖关系，确定递归根节点的子级节点，并将其存入第一子级栈。

本步骤实施时，将第一依赖关系中递归根节点执行的节点作为递归根节点的子节点，同行，第一子级栈采用先进先出的方式获取数据。

步骤404，执行第一父级递归流程：取出第一父级栈中栈顶节点，对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点对应的目标事件步骤，将取出节点的父级节点存入第一父级栈，重复上述过程，直至第一父级栈为空。

本步骤实施时，可根据步骤中上线特征的配置信息，确定取出节点对应的各线上步骤。

步骤405，执行第一子级递归流程：取出第一子级栈中栈顶节点，对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点是否存在目标事件步骤，若存在，则将取出节点的子级节点存入第一子级栈，重复上述过程，直至第一子级栈为空。

步骤406，第一父级递归流程及第一子级递归流程中记录风控特征与对应目标事件步骤之间的第二依赖关系。

其中，第一父级递归流程及第一子级递归流程并行进行。

本实施例通过第一父级栈及第二子级栈并行执行，能够提高第二依赖关系的确定效率。

本文一实施例中，如图5所示，上述步骤404对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点对应的目标事件步骤包括：

步骤501，确定取出节点对应的每一线上步骤与确定出该取出节点的子级节点对应目标事件步骤的一致性。

节点间步骤一致性的评价参数包括：节点间第一依赖关系与节点间的步骤先后顺序的一致性，以及节点间步骤名称一致性。

步骤502，根据取出节点对应的每一线上步骤与确定出该取出节点的子级节点对应目标事件步骤的一致性，对取出节点对应的每一线上步骤进行评分。

具体的，节点间步骤一致性的评价参数结果为一致，则评分增加第一预定值(例如1)，评价结果为不一致，则评分为第二预定值(例如为0)。

一具体实施方式中，某一特征sms_dr在放款事件步骤Lend_B上，它所依赖的特征sms_sd在线上所有的事件步骤为：进件A步，放款Lend_A步。

特征sms_sd为父级节点且为从父级栈中取出的节点，对应的，取出节点sms_sd的子级节点即为特征sms_dr，步骤501确定一致性即确定特征sms_sd的进件事件步骤A与特征sms_dr的放款事件步骤Lend_B的一致性，以及确定特征sms_sd的进件事件步骤A与特征sms_dr的放款事件步骤Lend_A的一致性。

步骤502对特征sms_sd的进件事件步骤A评分时，因为特征sms_sd属于事件步骤Lend_B与事件步骤A不存在依赖关系且步骤名称不一致，因此，特征sms_sd的进件事件步骤A评分为零。

步骤502对特征sms_sd的事件步骤Lend_A评分时，因为特征sms_sd属于事件步骤Lend_B与事件步骤Lend_A存在依赖关系(根据A、B的先后顺序确定)属于同一事件，且事件步骤Lend_B与事件步骤Lend_A的步骤名称一致，因此，特征sms_sd的事件步骤Lend_A评分为二(每次参数一致增加一)。

步骤503，将得分最高的线上步骤作为取出节点对应的目标事件步骤。

继续上一实施例，最终确定特征sms_sd的目标事件步骤为Lend_A。从而得到如下依赖关系sms_sd-Lend_A<-sms_dr-Lend_B。

本文一实施例中，如图6所示，步骤405对取出节点对应的各线上步骤进行评分，根据评分结果确定取出节点是否存在目标事件步骤包括：

步骤601，确定取出节点对应的每一线上步骤与确定出该取出节点的父级节点对应的事件步骤的一致性。

节点间步骤一致性的评价参数包括：节点间第一依赖关系与节点间的步骤先后顺序的一致性，以及节点间步骤名称一致性。

步骤602，根据取出节点对应的每一线上步骤与确定出该取出节点的父级节点对应的事件步骤的一致性，对取出节点对应的每一线上事件步骤进行评分。

本步骤实施时，当节点间第一依赖关系与节点间的步骤先后顺序一致时，则评分增加第一预定值，若不一致，则评分为第二预定值。当节点间步骤名称一致性时，则评分增加第一预定值，若不一致，则评分为第二预定值。

步骤603，若取出节点对应的每一线上步骤的得分均为预定值，则确定取出节点不存在目标事件步骤。

步骤604，若取出节点对应的线上步骤的得分中至少存在一个大于预定值，则将得分大于预定值的线上步骤作为取出节点对应的目标事件步骤。

一具体实施例中，假设特征sms_dr的子级节点sms_dr2及sms_dr3，当前取出节点为子级节点sms_dr2，对应的特征sms_dr为取出节点sms_dr2的父级节点。下一取出节点为sms_dr3，对应的特征sms_dr为取出节点sms_dr3的父级节点。步骤602即根据特征sms_dr的事件步骤对特征sms_dr2/sms_dr3的事件步骤的一致性。

假设特征sms_dr2线上所有的事件步骤为还款Repay_A，进件A。特征sms_dr3线上所有步骤:放款Lend_C。特征sms_dr的事件步骤为Lend_B。

通过步骤602，处理sms_dr2,查询出所有步骤，RepayA和A的事件都跟sms_dr的放款事件不一致，所以得分都为零，通过步骤603判断sms_dr2不存在目标事件步骤。处理sms_dr3,线上的步骤Lend_C和Lend_B属于同一个事件，得分1，通过步骤604判断，sms_dr3存在目标事件步骤，建立sms_dr事件步骤Lend_B与sms_dr3事件步骤Lend_C的依赖关系。

本文所述实施例实施时，可在得到第一依赖关系的基础上确定第二依赖关系，具体的，初始化时，将第一依赖关系看做第二依赖关系，按照步骤401至步骤406确定该各特征的事件步骤，步骤401至步骤406执行时，将当前特征对应的节点替换为特征的事件步骤，当该特征的子级节点不存在与该节点事件步骤关联的事件步骤时(即评分为第二预定值)，则在第二依赖关系中删除相关边。

本实施例能够通过第一依赖关系确定第二依赖关系，并达到减枝的效果。

本文一实施例中，对于每一事件步骤下的风控特征，判断该风控特征是否具有衍生特征以及该事件步骤的策略文件中是否引用该风控特征，若判断结果为否，则确定该风控特征为无用特征，在该事件步骤中对该风控特征做下线处理。

本步骤能够及时发现无用特征并及时做下线处理，避免线上空跑消耗有限的计算资源。

本文一实施例中，如图7所示，风控特征血缘关系的确定方法还包括：

步骤701，获取线上所有在用策略文件，每一策略文件中至少包括一决策文件。

具体的，决策文件以代码的形式存储于策略文件中，包括决策流、决策脚本、规则集及决策表等近十种类型文件。决策文件步进包括python代码，还有json格式的规则集。

步骤702，根据风控特征命名规则，确定的每一决策文件中的在用风控特征。

一些实施方式中以风控特征命名的结尾例如_sd或_dr来区分风控特征，以及根据决策文件中风控特征的引用规则识别决策文件中的风控特征，例如单引号或是双引号包围风控特征。具体实施时，可根据风控特征命名规则自定义一套抽取特征的规则，利用该规则挖掘决策文件中的在用风控特征。

步骤703，建立决策文件及其在用风控特征之间的第三依赖关系。

详细的说，第三依赖关系即特征->决策文件之间的依赖关系。依照倒排索引的方式建立第三依赖关系。

本实施例实施时，将索引存入缓存，保证所有上层查询应用只与缓存交互。

缓存的数据模型例如为：

{

"code":"特征名称",

"strategyName":"策略名",

"projectName":"项目名",

"blockType":"决策文件类型",

"fileName":"决策文件名",

"comment":"策略中文名",

"lines":"特征所处位置"

}。

步骤704，将第三依赖关系加入至风控特征的血缘关系中。

进一步的，还包括：对确定数据源的元数据，建立元数据与数据源之间的依赖关系，将该依赖关系添加至风控特征的血缘关系中。

本文所述的元数据为数据源存储的数据表，包括各种线上数据表，例如hive、hbase、mysql以及mongo表。

本实施例能够实现血缘关系的进一步升级，为后续查询数据以供全量数据基础。

基于同一发明构思，本文还提供一种风控特征血缘关系的确定装置，如下面的实施例所述。由于风控特征血缘关系的确定装置解决问题的原理与风控特征血缘关系的确定方法相似，因此风控特征血缘关系的确定装置的实施可以参见风控特征血缘关系的确定方法，重复之处不再赘述。

具体的，如图8所示，风控特征血缘关系的确定装置包括：

第一关系确定单元801，用于对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，所述特征代码中反映风控特征间的引用关系。

第二关系确定单元802，用于利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系。

组合单元803，用于由所述第一依赖关系及第二依赖关系构成风控特征血缘关系。

本实施例通过对特征代码进行挖掘和清洗处理，得到风控特征之间的第一依赖关系，还利用第一递归栈算法确定第一依赖关系中风控特征对应的事件步骤，建立风控特征与对应事件步骤之间的第二依赖关系，由第一依赖关系及第二依赖关系构成风控特征血缘关系，本文适用于风控特征上线于多种事件步骤的复杂血缘关系梳理，能够提高血缘关系梳理的全面性。

进一步的，如图9所示，风控特征血缘关系的确定装置还包括：

第三关系确定单元804，用于从策略文件的决策文件中确定在用风控特征，并建立决策文件与在用风控特征之间的依赖关系。

第四关系确定单元805，用于建立数据源与元数据之间的依赖关系。

组合单元803还用于将第三关系确定单元804及第四关系确定单元805添加至血缘关系中。

通过上述实施例确定出血缘关系之后，可供用户查询风控特征间的依赖关系，风控特征间的事件步骤的依赖关系，风控特征间的策略文件之间的依赖关系。查询条件包括：指定风控特征及查询内容，查询内容包括：风控特征间的依赖关系、风控特征间的事件步骤的依赖关系以及风控特征间的策略文件之间的依赖关系。下面以三个实施例说明查询结果。

案例一：查询风控特征间的依赖关系

查询条件为数据源，例如为A，具体查询时，以A为起点，逐个查询依赖该数据源的风控特征(即标准特征及衍生特征)，通过树形图的方式展示出来。如图10A所示，灰色圆圈为数据源，白色圆圈为依赖该数据源的风控特征，图中向左表示父级节点，向右表示子集节点。

案例二：查询风控特征间的事件步骤的依赖关系

查询条件为用户指定的风控特征B及事件步骤HH_tfix_tag_A，如图10B中灰色圆圈所示，以风控特征B为查询节点，向左表示该风控特征依赖的数据眼，向右表示该风控特征在HH_tfix_tag_A步骤下的衍生特征(子级节点)及其事件步骤。

以用户指定的风控特征为查询起点，向上溯源至该风控特征来源的数据源，向下则寻找所有依赖该风控特征的事件步骤下的衍生特征。

案例三：查询风控特征间的策略文件之间的依赖关系

查询条件为用户指定风控特征，查询该风控特征在所有线上策略文件中决策文件中风控特征的使用情况，并将查询结果以表格的形式进行展示。

本文提供的风控特征血缘关系的确定方法及装置，能够确定出数据源-衍生特征-决策文件及元数据整个链路的血缘关系，通过可视化图表展示用户查询的数据流转，达到风控特征可溯源，数据价值易评估的目的，并且能够及时发现未被使用的风控特性及时下线处理，达到节约计算资源的目的。

本文一实施例中，还提供一种计算机设备，如图11所示，计算机设备1102可以包括一个或多个处理器1104，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备1102还可以包括任何存储器1106，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器1106可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备1102的固定或可移除部件。在一种情况下，当处理器1104执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备1102可以执行相关联指令的任一操作。计算机设备1102还包括用于与任何存储器交互的一个或多个驱动机构1108，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备1102还可以包括输入/输出模块1110(I/O)，其用于接收各种输入(经由输入设备1112)和用于提供各种输出(经由输出设备1114)。一个具体输出机构可以包括呈现设备1116和相关联的图形用户接口1118(GUI)。在其他实施例中，还可以不包括输入/输出模块1110(I/O)、输入设备1112以及输出设备1114，仅作为网络中的一台计算机设备。计算机设备1102还可以包括一个或多个网络接口1120，其用于经由一个或多个通信链路1122与其他设备交换数据。一个或多个通信总线1124将上文所描述的部件耦合在一起。

通信链路1122可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路1122可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行前述实施例所述的方法。

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

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。