本发明属于互联网
技术领域：
：，具体涉及一种用户画像标签数据质量的监控方法。
背景技术：
：：用户画像是企业为用户提供精准营销服务的基础之一，通过对用户信息进行标签化处理来刻画用户的商业全貌，其质量直接影响了企业对用户的服务水平。伴随各项业务的开展，数据不断积累，用户画像标签也在不断的丰富和完善，在标签开发过程中，如何管控标签数据的质量是相关开发测试人员必须面对的问题，例如用户标签上线下线规范、标签数据质量监控等。由于数据质量的监控是一个持续又繁琐的过程，因而通常会引入一些自动化规则化的手段来实现，常见的数据质量监控方式包括对结果表行数监控、主键是否重复监控、字段空值率监控等，这些监控方式嵌入在数据的每个流转节点中，虽然监控的方式很多，但仍然不能完全避免标签数据质量问题的产生，直接影响了上层应用使用。业务在快速发展过程中往往包含了较多的不确定性，为了紧跟业务节奏，快速响应灵活多变的业务诉求，相应的标签数据也需要经历快速更新和迭代，例如标签的增减、标签加工逻辑的变更等，标签数据一般以宽表的形式被导入到下游应用系统消费，在标签数量不多的情况下通过人工cr可以确保字段的插入顺序以及每个字段的加工逻辑都能符合预期，然而当标签的数量增加到几百个甚至更多时，难免会遇到表字段插入顺序与表结构声明不一致的情况，依靠人工去逐个字段的cr数据清洗脚本，一方面不能保证经过人工cr后的结果一定是正确的，另一方面人工核对的工作量会随标签数量的丰富而增大，并且频繁的迭代和标签加工逻辑调整变更也会加重这种繁琐的重复劳动。现有的数据质量自动化监控手段对标签字段插入顺序错乱的问题很难有效的去发现并规避，因为字段出现插入顺序错乱不一定会触发质量监控规则告警，例如字段插入顺序错乱不会引起表行数出现大的波动，顺序发生错乱的字段类型之间能够进行相互转换也不会报数据插入异常错误等。如果有多段逻辑在往同一个用户标签宽表中插入数据时，还可能出现中间某一段逻辑的字段插入顺序是不对的，但当对全表抽样cr标签数据内容时不一定能抽到字段顺序发生错乱的部分，直到数据透出到前端页面展示或者应用到具体业务场景中时问题才被暴露。在此背景下，需要一种手段或系统对用户画像标签宽表的生成结果进行校验，监测目标宽表生成过程中字段插入顺序异常的问题，同时能够快速定位出顺序出现错乱的字段位置，避免异常数据流到业务端，一则提升了用户画像标签数据的可用性和可靠性，另外也弥补了现有监控方式的不足。技术实现要素：基于以上问题，本发明提供一种用户画像标签数据质量的监控方法，可以减少代码脚本迭代和逻辑更新带来的字段顺序插入错乱的问题。为解决技术问题，本发明所采用的技术方案是：一种用户画像标签数据质量的监控方法，其特征在于，包括如下：(1)获取目标用户的画像标签宽表以及生成画像标签宽表需要依赖的上游表；(2)根据画像标签宽表创建第一画像标签宽表影子表，根据上游表创建上游表影子表；(3)为上游表影子表构造数据；(4)为第一画像标签宽表影子表构造数据，并在第一画像标签宽表影子表中增加校验字段；(5)获取线上运行的生成画像标签宽表所使用的脚本，并将脚本的上游表替换成上游表影子表，同时根据画像标签宽表创建第二画像标签宽表影子表并为第二画像标签宽表影子表增加校验字段；然后将脚本的画像标签宽表替换成第二画像标签宽表影子表，再在替换后的脚本中补充校验字段的生成逻辑，执行替换后的脚本，然后将脚本执行后的结果插入到第二画像标签宽表影子表中；(6)比较第一画像标签宽表影子表和第二画像标签宽表影子表中的校验字段，如果不存在字段顺序错乱，则直接退出校验过程；若出现字段顺序错乱，则继续进行较验过程直至得到所有顺序错乱的字段再退出校验。优选的，在第一画像标签宽表影子表和第二画像标签宽表影子表中增加校验字段的规则如下：(1)先使用函数将所有标签字段拼接成一个字符串，其中标签字段中为null的字段按字符段类型分别进行处理；(2)对拼接后的字符串进行压缩。优选的，使用concat()函数将所有标签字段拼接成一个字符串。优选的，在比较第一画像标签宽表影子表和第二画像标签宽表影子表中的校验字段时，通过画像标签宽表的主键将第一画像标签宽表影子表和第二画像标签宽表影子表进行关联。优选的，若出现字段顺利错乱，则继续进行较验过程直至得到所有顺序错乱的字段再退出校验，然后将结果返回，根据返回结果对数据清洗逻辑进行检查修改。优选的，第二画像标签宽表影子表中校验字段的生成逻辑和压缩逻辑与第一画像标签宽表影子表中校验字段的生成逻辑和压缩逻辑相同。与现有技术相比，本发明具有以下有益效果：本发明的用户画像标签数据质量的监控方法，上游表影子表和第一画像标签宽表的数据都只在首次配置的时候需要构造，只要预期需要覆盖的业务场景和目标结果表结构不发生改变，都不需要进行调整；而第二画像标签宽表影子表的数据则需要每次根据线上运行的脚本执行后重新生成。与其他数据质量校验方法所不同的，其他方式都是后置校验过程，也就是在本节点数据清洗脚本执行完生成结果数据后运行，本发明中提到的方法属于前置校验，当调度执行到本节点任务脚本时，先触发核验任务，获取最新的线上代码，往第二画像标签影子表中插入数据，如果校验不通过，直接阻塞后续流程的进行并报警，避免了无意义的下游计算过程。本发明可以减少代码脚本迭代和逻辑更新带来的字段顺序插入错乱的问题，尤其是对于字段个数特别多的宽表以及存在多段insert语句往同一个目标表中插入数据的场景，核验脚本逻辑以及数据结果质量的效率可以得到明显提升，同时能够快速的根据返回结果定位出问题发生的位置。附图说明参考以下详细描述可以获得对本发明的特征和优点的更好理解，其中阐述了利用了本发明的原理的说明性实施例以及附图，其中：图1为本发明流程示意图；图2为本发明实施例1中的目标宽表(即画像标签宽表)的加工逻辑示意图；图3为本发明实施例1中的目标宽表(即画像标签宽表)的表结构示意图。具体实施方式下面结合实施例对本发明作进一步的描述，所描述的实施例仅仅是本发明一部分实施例，并不是全部的实施例。基于本发明中的实施例，本领域的普通技术人员在没有做出创造性劳动前提下所获得的其他所用实施例，都属于本发明的保护范围。为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。结合附图，本发明的用户画像标签数据质量的监控方法，包括如下：(1)获取目标用户的画像标签宽表以及生成画像标签宽表需要依赖的上游表；其中画像标签宽表和上游表从元数据系统中直接获取；(2)根据画像标签宽表创建第一画像标签宽表影子表，根据上游表创建上游表影子表；(3)为上游表影子表构造数据；其中在为上游表影子表构造数据时，构造的数据需要覆盖生成最终用户画像宽表将会涉及的每一种业务场景，如果依赖了多张表的话，需要为每张表构造相应的数据。(4)为第一画像标签宽表影子表构造数据，并在第一画像标签宽表影子表中增加校验字段；基于已经构造的上游影子表数据，同时结合目标标签宽表的业务生成逻辑，为第一画像标签宽表影子表构造预期的结果数据。由于目标用户的画像标签宽表包含的表字段可能会很多，为避免后续校验过程中去逐个字段比较，在第一画像标签宽表影子表中还会增加一个额外的字段(即校验字段)用于后续校验使用。校验字段的生成规则如下，先使用concat()函数将所有标签字段拼接成一个字符串，其中为null的字段需要根据字段类型分别处理，字符型处理为空字符串”，数字型处理成0，日期类型处理为’0001-01-01’，再对拼接后的字符串进行压缩，压缩方式可以是通过md5函数对字符串进行处理，也可以是crc32函数对字符串进行处理等，具体不做限制。(5)获取线上运行的生成画像标签宽表所使用的脚本，并将脚本的上游表替换成上游表影子表，同时根据画像标签宽表创建第二画像标签宽表影子表并为第二画像标签宽表影子表增加校验字段；然后将脚本的画像标签宽表替换成第二画像标签宽表影子表，再在替换后的脚本中补充校验字段的生成逻辑，执行替换后的脚本，然后将脚本执行后的结果插入到第二画像标签宽表影子表中，即是说将替换后的脚本执行后的结果插入到第二画像标签宽表影子表中；其中，第二画像标签宽表影子表的表结构与第一画像标签宽边影子表的表结构相同，第二画像标签标影子表的校验字段的生成逻辑和压缩逻辑与第一画像标签影子表的生成逻辑和压缩逻辑相同。(6)比较第一画像标签宽表影子表和第二画像标签宽表影子表中的校验字段，如果不存在字段顺序错乱，则直接退出校验过程；若出现字段顺利错乱，则继续进行较验过程直至得到所有顺序错乱的字段再退出校验。其中，在比较第一画像标签宽表影子表和第二画像标签宽表影子表中的校验字段时，通过画像标签宽表的主键将第一画像标签宽表影子表和第二画像标签宽表影子表进行关联；再count校验字段值不一致的行数，如果等于0则说明用户画像宽表的生成脚本逻辑中不存在字段顺序错乱的问题，直接退出校验过程。反之，如果不一致的数据行数大于0行，则需要继续执行判断，全文字段比较第一画像标签宽表影子表和第二画像标签宽表影子表的结果，得到所有顺序存在不一致的字段后再退出校验过程，同时返回校验结果和存在顺序错乱的字段名称。根据返回结果对数据清洗逻辑进行检查修改。本发明的用户画像标签数据质量的监控方法，上游表影子表和第一画像标签宽表的数据都只在首次配置的时候需要构造，只要预期需要覆盖的业务场景和目标结果表结构不发生改变，都不需要进行调整；而第二画像标签宽表影子表的数据则需要每次根据线上运行的脚本执行后重新生成。与其他数据质量校验方法所不同的，其他方式都是后置校验过程，也就是在本节点数据清洗脚本执行完生成结果数据后运行，本发明中提到的方法属于前置校验，当调度执行到本节点任务脚本时，先触发核验任务，获取最新的线上代码，往第二画像标签影子表中插入数据，如果校验不通过，直接阻塞后续流程的进行并报警，避免了无意义的下游计算过程。本发明可以减少代码脚本迭代和逻辑更新带来的字段顺序插入错乱的问题，尤其是对于字段个数特别多的宽表以及存在多段insert语句往同一个目标表中插入数据的场景，核验脚本逻辑以及数据结果质量的效率可以得到明显提升，同时能够快速的根据返回结果定位出问题发生的位置。实施例1假设需要配置质量监控规则的目标宽表(即画像标签宽表)为result_table，目标宽表(即画像标签宽表)的加工逻辑如图2所示，目标宽表(即画像标签宽表)所依赖的直接上游表包括table_a、table_b、table_c三张表。首先获取表之间的上下游依赖关系以及table_a、table_b、table_c、result_table的元数据信息，同时创建与它们结构完全一致的上游表影子表s_table_a、s_table_b、s_table_c以及只比画像标签宽表多了校验字段的标签宽表影子表s_result_table、s_result_table_cmp，此时所有的影子表(即上游表影子表和第一画像标签宽表影子表)中都还没有包含任何数据。接着向几张上游表影子表中插入数据，插入数据可以直接来源于真实的数据，也可以通过手工构造几条，但都需要尽可能去覆盖下游清洗逻辑中会涉及的各种场景，例如目标宽表(即画像标签宽表)中某个字段会根据table_a的字段column1值的不同来赋予不同的目标值，那么在造数时column1的值需要尽可能将几种情况都考虑到。再者为目标宽表的影子表(即第一画像标签宽表)s_result_table构造数据，构造的数据需要结合已经构造的上游表影子表数据以及业务逻辑构造出符合业务预期的结果，因为s_result_table中的结果将作为判断目标宽表加工过程中字段插入顺序是否正确的依据。假设s_result_table的结构如图3所示，col0,、col1、col2、…、coln插入的值为基于上游构造数据生成的预期结果，其中col0为用户id主键，col1为字符型，col2为数字型，coln为日期型，检验字段col是额外增加的校验字段，它的生成方式如下：selectmds(concat(cul0，nvl(col1，″)，nvl(col2，0)，...，nvl(coln，′0001-01-01′)))ascolfromsystem.dual；在有前台配置页面的情况下，向s_result_table中构造数据的方式可以直接在前台页面录入，后台再通过执行insert语句将目标结果数据插入到表中，而校验字段的值则自动根据上述规则填充生成。接下来从生产服务器上获取线上运行的生成目标宽表(即画像标签宽表)result_table所使用的脚本，假设result_table的生成逻辑如下：将table_a、table_b、table_c替换为它们分别对应的影子表(即上游表影子表)s_table_a、s_table_b、s_table_c，目标表(画像标签宽表)也替换为第一画像标签宽表影子表s_result_table_cmp，考虑还需要生成校验字段，替换后的脚本如下：执行替换后的脚本，比较s_result_table(即第一画像标签宽表影子表)与s_result_table_cmp(第二画像标签宽表影子表)表的校验字段，两张表通过主键字段col0关联。如果不存在s_result_table.col<>s_result_table_cmp.col的情形，则退出校验，继续执行后续生成宽表的清洗流程；反之，表明数据清洗脚本中存在字段顺序与预期不一致，需要继续排查发生顺序错乱的位置，比较方式如下：由此可以得到所有字段顺序与预期不符的字段名称，将上述结果返回，根据返回结果对数据清洗逻辑进行检查修改，避免了人工逐个字段去核对的过程，并且在每次修改完后，还可以反复触发校验过程，检查效率更高，适用于脚本上线前的测试、迭代修改后的验证、上线后每次执行前的校验等。如果有多段插入数据的脚本，通过本发明中的方法，可以做到更高效的对每一段插入数据脚本进行校验，并且是在数据插入到目标表前进行的校验，任何一段脚本存在异常，都可以阻塞后续流程的执行，减少了无意义的下游计算过程。作为一种对用户画像标签数据质量的监控方法，本发明很好的对以往标签数据质量监控方法进行了补充，解决了过往方法不能监控数据顺序错乱的问题，并且更高效，对字段内容越是丰富的场景、数据清洗逻辑脚本中插入逻辑越多的场景本发明所给出的方法优势体现更为明显。上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。当前第1页12当前第1页12