数据埋点方法、数据埋点系统和数据处理系统与流程

1.本发明涉及计算机技术领域，更具体地，设计一种数据埋点方法、数据埋点系统和数据处理系统。


背景技术：

2.目前，随着精细化作业的诉求越来越强，业务系统产出的数据质量和完整性要求也越来越高。因此，如何做好数据埋点是至关重要的课题。


技术实现要素：

3.有鉴于此，本发明实施例提供一种数据埋点方法、数据埋点系统和数据处理系统，以通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
4.第一方面，本发明实施例提供一种数据埋点方法，所述方法包括：
5.接收业务系统上报的业务事件；
6.响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；
7.将实体事件分发至数据应用系统。
8.第二方面，本发明实施例提供一种数据埋点系统，所述系统包括：
9.上报模块，被配置为接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；
10.分发模块，被配置为将实体事件分发至数据应用系统。
11.第三方面，本发明实施例提供一种数据处理系统，所述系统包括：
12.业务系统，被配置为上报业务事件；
13.数据埋点系统，被配置为接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统；
14.数据应用系统，被配置为接收所需的实体事件。
15.第四方面，本发明实施例提供一种数据埋点装置，所述装置包括：
16.接收单元，被配置为接收业务系统上报的业务事件；
17.处理单元，被配置为响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；
18.分发单元，被配置为将实体事件分发至数据应用系统。
19.第五方面，本发明实施例提供一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器
执行以实现如上所述的方法。
20.第六方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法。
21.第七方面，本发明实施例提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如上所述的方法。
22.本发明实施例通过接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统，以实现数据埋点。也就是说，本实施例通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
附图说明
23.通过以下参照附图对本发明实施例的描述，本发明的上述以及其它目的、特征和优点将更为清楚，在附图中：
24.图1是本发明实施例的数据数据系统的示意图；
25.图2是本发明实施例的数据处理系统的数据埋点过程的示意图；
26.图3是本发明实施例的数据埋点系统的示意图；
27.图4是本发明实施例的上报模块的配置信息的er图；
28.图5是本发明实施例的业务事件处理进度状态机的示意图；
29.图6是本发明实施例的业务事件上报的流程图；
30.图7是本发明实施例的业务事件上报流程时序图；
31.图8是本发明实施例的业务事件上报重试流程时序图；
32.图9是本发明实施例的分发模块的配置信息的er图；
33.图10是本发明实施例的实体事件分发进度状态机的示意图；
34.图11是本发明实施例的实体事件分发的流程图；
35.图12是本发明实施例的实体事件分发流程时序图；
36.图13是本发明实施例的数据埋点方法的流程图；
37.图14是本发明实施例的数据埋点装置的示意图；
38.图15是本发明实施例的电子装置的示意图。
具体实施方式
39.以下基于实施例对本发明进行描述，但是本发明并不仅仅限于这些实施例。在下文对本发明的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本发明。为了避免混淆本发明的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。
40.此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。
41.除非上下文明确要求，否则在说明书的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。
42.在本发明的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。
43.在相关技术中，通常采用日志采集与binlog采集相结合的方式实现数据埋点。其中，binlog采集用于输出业务系统中为了支撑业务系统运转而定义的底表的数据，日志采集则作为补充方案、对没有进入底表的数据进行补齐。
44.然而这种数据埋点方法在日益复杂的应用中具有一定的局限性：第一方面，从业务系统和数据应用系统的合作边界上看，业务系统直接输出binlog数据或日志数据给数据应用系统，这使得业务系统和数据应用系统耦合严重，并且在数据应用系统的数据需求调整时，需要业务系统同步修改，这导致数据需求与业务需求的迭代效率较低，同时，在业务需求调整时，又会受到数据需求的掣肘，数据质量和数据稳定性较低。第二方面，从具体方案上看，binlog采集受到数据库表设计的约束和限制，而日志采集常存在易延迟、易丢失等问题。
45.基于现有的相关技术的缺陷，本发明实施例提供了一种数据埋点方法、数据埋点系统和数据处理系统，以通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
46.在描述本发明的具体实施例之前，首先介绍一下本发明实施例所涉及的相关概念：
47.1、实体：实体是存在于现实世界中并且可以与其他物体区分开来的物体，可以用一系列属性对一个实体进行描述，以区别于其他实体。
48.2、事件：事件是可以被控件识别的操作，例如若一按钮被按下、或者选择某个选择框等都会触发一个事件。
49.3、埋点：埋点是一种采集系统中数据的数据采集方法。
50.4、业务系统：支撑业务正常运转的软件系统体系统称为业务系统。
51.5、业务事件：业务系统可以感知到的事件信息，称为业务事件。
52.6、准入：系统对接收到的事件根据约定格式/内容进行校验的过程即为准入。
53.7、实体事件：单一实体视角描述的事件，叫做实体事件。
54.8、翻译：将业务事件处理为实体事件的过程，叫做翻译。
55.9、数据应用系统：需要使用实体事件作为输入来支撑自身业务的系统，叫做数据应用系统。
56.图1是本发明实施例的数据数据系统的示意图。如图1所示，本实施例的数据处理系统1包括业务系统11、数据埋点系统(logbook)12和数据应用系统13。
57.数据的变更常常是系统中发生的事件引起，业务系统11能够感知到的数据和数据应用系统13所需数据的数据内容及形式往往不同。业务系统11能够感知系统中发生了哪些业务事件，这些业务事件对相关的m个实体数据造成了什么影响，m大于等于0。数据应用系
统13所需的数据是其关注的单一实体发生了哪些变化，这些变化是由什么事件引发的。由此可以得出：业务系统中发生的业务事件可能影响到m个实体，单一实体视角发生的实体事件只涉及到单个实体，其由一个或多个业务事件加工后得到。
58.在一种可选的实现方式中，业务事件规范如表(1)所示：
59.表(1)
[0060][0061]
在一种可选的实现方式中，实体事件规范如表(2)所示：
[0062]
表(2)
[0063][0064][0065]
基于此，本发明实施例可以基于业务事件规范和实体事件规范，对业务事件的格式和内容进行处理转换，得到对应的实体事件。
[0066]
由此，本发明实施例可以通过在业务系统11和数据应用系统13之间引入一个中间层，也即数据埋点系统12，以对业务逻辑和数据加工逻辑进行解耦，也即对业务系统11和数
据应用系统13进行解耦。由此，业务系统11不再面向数据应用系统13的数据需求来获取其所需的所有数据，而是仅将业务系统11中发生的业务事件进行上报，并且上报哪些业务事件取决于系统自身，无需感知数据应用系统13的数据需求，这使得业务系统11可以从复杂的数据加工工作中释放，提高了开发效率。
[0067]
进一步可选的，本实施例中的数据埋点系统可以基于对应的数据接口(例如api接口)获取实体事件的其他相关数据，以进行数据补充，以进一步保证数据的准确性和完整性，以向数据应用系统13提供稳定的、高质量的数据。
[0068]
具体地，在本实施例中，上游业务系统11产生业务事件，并通过对应的数据接口将业务事件上传至数据埋点系统12，数据埋点系统12接收业务系统11上报的业务事件，响应于各业务事件通过准入校验，对各业务事件进行翻译，获取对应的实体事件，并将各实体事件分发至数据应用系统13。数据应用系统13接收所需的实体事件，以执行相关任务。可选的，数据接口为api接口(application program interface，应用程序接口)。
[0069]
图2是本发明实施例的数据处理系统的数据埋点过程的示意图。如图2所示，在本实施例中，业务系统11向数据埋点系统12上报业务事件，数据埋点系统12对业务事件进行准入校验。可选的，数据埋点系统12判断业务事件的格式和内容是否符合要求。其中，该要求一般是业务系统11和数据埋点系统12预先约定的。在数据埋点系统12确定业务事件准入后，对该业务事件进行翻译，确定对应的实体事件。可选的，数据埋点系统12对业务事件的格式和内容进行转换处理后获取对应的实体事件。之后，数据埋点系统12将获取的实体事件分发至数据应用系统13。
[0070]
本发明实施例通过接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统，以实现数据埋点。也就是说，本实施例通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
[0071]
图3是本发明实施例的数据埋点系统的示意图。如图3所示，本实施例的数据埋点系统32包括上报模块321和分发模块322。其中，上报模块321被配置为接收业务系统31上报的业务事件，响应于该业务事件通过准入校验，对该业务事件进行翻译，获取对应的实体事件。分发模块322被配置为将实体事件分发至数据应用系统33。
[0072]
在一种可选的实现方式中，上报模块31提供上报接口，例如api接口(report api)和sdk接口(report sdk)，以支持业务系统31以不同形式上报业务事件。可选的，本实施例若采用api接口执行上报任务，api接口提供上报接口，其中，上报接口包括准入逻辑和翻译逻辑，以使得业务事件准入成功后执行翻译任务。进一步可选的，本实施例若采用sdk接口执行上报任务，sdk接口提供准入接口和翻译接口的逻辑代码来执行业务事件的准入和翻译任务，使得业务事件准入成功后执行翻译。
[0073]
在本实施例中，上述上报接口、准入接口和翻译接口的逻辑类似，以下以上报接口进行具体说明。
[0074]
可选的，在本实施例中，上报接口的说明如下：
[0075]
接口名：/api/biz_event/report
[0076]
接口说明：统一业务事件上报接口
[0077]
请求方法：post
[0078]
content-type：application/json
[0079]
参数说明如表(3)所示：
[0080]
表(3)
[0081][0082]
上报接口的返回值说明如表(4)所示：
[0083]
表(4)
[0084]
字段类型说明errnoint0:成功，非0:失败errmsgstring错误或者成功提示信息datajson object错误信息的详细描述
[0085]
上报接口的错误码说明如表(5)所示：
[0086]
表(5)
[0087]
errornoerrmsg具体含义4permit_fail准入未通过
3fail失败需重试1already_success已成功0success成功
[0088]
在一种可选的实现方式中，上报模块321包括准入处理单元321a和翻译处理单元321b。准入处理单元321a被配置为对业务系统31上报的业务事件进行准入校验。翻译处理单元321b被配置为对准入的业务事件的格式和内容进行转化处理，获取对应的实体事件，并根据实体事件的类型将各实体事件存储至对应的存储单元，例如图3中所示的存储单元a、存储单元b和存储单元c等，以便于后续的分发处理。也就是说，在本实施例中，假设存储单元a用于存储a类型的实体事件，存储单元b用于存储b类型的实体事件，存储单元c用于存储c类型的实体事件。若翻译处理单元321b获取的实体事件包括实体事件x1、实体事件x2和实体事件x3，其中，实体事件x1为a类型实体事件，实体事件x2为b类型实体事件，实体事件x3为c类型实体事件，则翻译处理单元321b将实体事件x1存储至存储单元a，将实体事件x2存储至存储单元b，将实体事件x3存储至存储单元c。
[0089]
应理解，本实施例并不对存储方式进行限制，可以采用例如kafka系统的存储方式，以便于数据应用系统进行消息订阅。进一步可选的，本实施例可以将采用预定的存储方式将不同实体事件类型的实体事件存储到不同的介质中，例如磁盘、服务、队列等介质中，本实施例并不对此进行限制。
[0090]
图4是本发明实施例的上报模块的配置信息的er图。在本实施例中，上报模块321的配置信息主要包括与业务系统31产生的业务事件相关的配置。可选的，本实施例的上报模块321的配置信息的er图(entity relationship diagram，实体-联系图)如图4所示。
[0091]
在本实施例中，上报模块321的配置信息主要包括业务系统(caller)的标识的配置、业务事件分类校验(biz_event_type)的配置、准入校验(permit_rule)的配置、翻译处理(translate_rule)的配置、实体类型(entity_type)的配置、实体事件类型(event_type)的配置、实体事件校验(validate_rule)的配置、以及实体事件存储(entity_store_config)的配置等。
[0092]
在一种可选的实现方式中，如图4所示，数据埋点系统32对每个新接入的业务系统单独申请一个单独的caller，其配置信息包括业务系统名称(caller_name)、业务系统的唯一标识(caller_id)以及对应的认证证明(credential)。进一步可选的，业务系统的标识配置信息在上报接口中按要求带入，用于简单的接口鉴权，也即确定该业务系统是否已经接入数据埋点系统32，若已接入，则可以通过上报接口向数据埋点系统32上报业务事件，若未接入，则不能通过上报接口向数据埋点系统32上报业务事件。
[0093]
业务事件类别校验(biz_event_type)的配置包括业务事件类别的标识(biz_event_type_id)和业务事件类别的名称(biz_event_type_name)。其中，biz_event_type与业务系统caller是多对多的关系(m-n)，也即一个业务系统可以在多个业务事件类别校验处备案上报某类业务事件，一个业务事件类别校验处也可以对多个业务系统上报的业务事件进行类别校验。举例来说，假设具有业务系统caller_a、业务系统caller_b、业务事件类别校验biz_event_type_x、业务事件类别校验biz_event_type_y、业务事件类别校验biz_event_type_z。其中，业务事件类别校验biz_event_type_x用于对x1类型的业务事件进行分类校验，业务事件类别校验biz_event_type_y用于对y1类型的业务事件进行分类校验，
业务事件类别校验biz_event_type_z用于对z1类型的业务事件进行分类校验。若业务系统caller_a预先向biz_event_type_x备案了需要上报x1类型的业务事件、向biz_event_type_y备案了需要上报y1类型的业务事件，业务系统caller_b预先向biz_event_type_y备案了需要上报y1类型的业务事件、向biz_event_type_z备案了需要上报z1类型的业务事件，则在biz_event_type_x处，业务系统caller_a与x1类型的业务事件具有关联关系，在biz_event_type_y处，业务系统caller_a与y1类型的业务事件具有关联关系，业务系统caller_b与y1类型的业务事件具有关联关系，在biz_event_type_z处，业务系统caller_b与z1类型的业务事件具有关联关系。由此，在biz_event_type_x接收到业务系统caller_a上报的x1类型的业务事件x1时，可以将业务事件x1进行上报，但若在biz_event_type_x接收到业务系统caller_b上报的x1类型的业务事件x2，则由于biz_event_type_x处业务系统caller_b与x1类型的业务事件并未备案关联关系，业务事件x2不能被上报。
[0094]
准入校验(permit_rule)的配置包括准入校验的方法(permit_type)和校验脚本(permit_script)，其可以采用不同的准入方法(permit_type)对不同类型的业务事件的内容及格式进行约束(permit_script)。可选的，本实施例可采用基于json schema准入控制器进行准入校验，应理解，本实施例并不对准入方法进行限制，不同的业务事件也可以采用不同的准入方法。
[0095]
翻译处理(translate_rule)的配置包括翻译方法(translate_type)和翻译脚本(translate_script)，其可以采用不同的翻译方法(translate_type)对业务事件进行格式及内容的转换处理(translate_script)，以确定对应的实体事件。可选的，本实施例可采用基于groovy来获取对业务事件的翻译脚本，以对业务事件进行翻译，确定对应的实体事件。应理解，本实施例并不对翻译方法进行限制。groovy是一种基于jvm(java虚拟机)的敏捷开发语言，它结合了python、ruby和smalltalk的许多强大的特性，groovy代码能够与java代码很好地结合，也能用于扩展现有代码。
[0096]
其中，业务事件类别校验(biz_event_type)与翻译处理(translate_rule)为一对多的关系(1-n)、业务事件类别校验(biz_event_type)与准入校验(permit_rule)为一对一的关系(1-1)。
[0097]
实体类型(entity_type)的配置包括实体类型的唯一标识entity_type_id和实体类型的名称(entity_type_name)。实体事件类型(event_type)的配置包括实体事件的唯一标识(event_type_id)和实体事件的名称(event_type_name)。其中，实体类型(entity_type)与实体事件类型(event_type)为一对多的关系(1-n)。
[0098]
实体事件校验(validate_rule)的配置包括实体事件校验的校验方法(validate_type)和实体事件校验的脚本(validate_script)，其可以采用不同的校验方法(validate_type，例如jsonschema等)对不同实体事件类型的实体事件内容及格式进行校验(validate_script)。应理解，本实施例并不对准入方法进行限制，不同的实体事件也可以采用不同的校验方法。
[0099]
实体事件存储(entity_store_config)的配置包括实体事件的存储方式(store_type)和存储相关的上下文信息(store_context)，以采用不同的存储方式(store_type，例如kafka等)将翻译得到的不同实体事件类型的实体事件存储到不同的存储介质(例如磁盘、服务、队列等)中。store_context用于存储相关的上下文信息。
[0100]
本实施例基于图4所示的er图对数据埋点系统32中的上报模块321进行配置，以实现对业务系统31上报的业务事件进行准入校验，并对准入的业务事件进行翻译，获取对应的实体事件存储至对应的介质中。
[0101]
在一种可选的实现方式中，考虑到业务事件上报后翻译任务完整前，可能会因为网络抖动、机器重启等原因造成流程中断，进而造成数据丢失需要补偿的情况、或者业务系统31在感知不到上报结果时需进行上报重试的情况，本实施例的上报模型采用幂等处理方法执行的上报任务，以对同一业务事件的上报，仅有一次被处理，避免了数据重复处理。并且，若业务事件未处理完成流程终端，通过上报重试进行补偿，由此，可以进一步保证数据的准确性和完整性。
[0102]
在一种可选的实现方式中，本实施例的幂等处理方法包括：对于业务系统31上报的不同的业务事件，生成全局唯一业务事件标识，在业务事件准入后，记录该业务事件，并使用状态机跟踪其处理进度，采用全局唯一业务事件标识做幂等处理，以避免数据重复处理。
[0103]
可选的，业务事件记录表(biz_event_record)中记载的业务事件信息如表(6)所示：
[0104]
表(6)
[0105][0106]
图5是本发明实施例的业务事件处理进度状态机的示意图。在一种可选的实现方式中，如图5所示，在本实施例的上报模块321执行上报翻译任务的过程中，业务事件的状态分别为：状态1表征业务事件处于未处理状态，状态2表征业务事件处于处理中状态，状态3表征业务事件处于已完成状态，状态4表征业务事件处于作废状态。
[0107]
在上报模块321接收到业务系统31上报的业务事件后，将该业务事件的状态更新为状态1，也即未处理状态。若该业务事件未被准入，也即该业务事件的格式或内容不符合标准，则将该业务事件的状态更新为状态4，也即作废状态。若该业务事件准入成功，将该业务事件的状态更新为2，也即处理中状态，在此状态下，对该业务事件进行翻译，获取对应的实体事件，在翻译成功完成后，将该业务事件的状态更新未状态3，也即已完成状态。其中，在业务事件处于处理中状态时，若翻译失败则重新翻译直至翻译成功。若在业务事件处于处理中状态超过预定时间或者系统故障导致翻译中断等情况时，将该业务事件的状态更新为状态4，也即作废状态。
[0108]
图6是本发明实施例的业务事件上报的流程图。如图6所示，本实施例的数据埋点系统32中的上报模块321执行业务事件上报过程包括以下步骤：
[0109]
步骤s110，接收业务系统上报的业务事件。可选的，通过上报接口，例如api接口等，接收业务系统31上报的业务事件。
[0110]
步骤s120，对该业务事件执行准入校验，确定该业务事件是否准入成功。可选的，在本实施例中，准入处理单元321a对业务事件的格式和内容进行校验，若其符合数据埋点系统32和业务系统31预先约定的规则，则准入，若不符合则不准入。其中，若业务事件准入成功，则执行步骤s130，若业务事件准入失败，则执行步骤s1e0，也即向业务系统31返回上报结果：errorno＝4，也即准入未通过(参见表(5))。
[0111]
步骤s130，在业务事件准入后，上报模块321生成该业务事件的全局唯一标识，并基于业务事件处理进度状态机根据该业务事件标识跟踪处理进度。
[0112]
步骤s140，将该业务事件插入至业务事件记录表中，此时，该业务事件的状态为：状态＝1未处理。其中，业务事件记录表记录有各业务事件的信息和当前所处的处理状态，具体可参照表(6)的内容，在此不再赘述。
[0113]
步骤s150，判断该业务事件是否成功插入至业务事件记录表。若插入成功，表征该业务事件为首次上报，执行步骤s180，若插入失败，则表征该业务事件非首次上报，执行步骤s160。
[0114]
步骤s160，响应于该业务事件插入业务事件记录表失败，根据业务事件的标识查询业务事件记录表，若业务事件记录表中记录有该业务事件，则表征该业务事件已上传，执行步骤s170，若业务事件记录表中未记录有该业务事件，则执行步骤s1d0，也即向业务系统31返回上报结果：errorno＝3，也即业务事件上报失败需重试(参见表(5))。
[0115]
步骤s170，响应于业务事件记录表中记录有该业务事件，查询业务事件记录表中记录的业务事件的状态是否为：状态＝1，也即是否为未处理状态。若业务事件为未处理状态，执行步骤s180，若业务事件并不处于未处理状态，则表征该业务事件已上报翻译成功，其为重复处理数据，执行步骤s1c0，也即向业务系统31返回上报结果：errorno＝1，也即业务事件已上报成功(参见表(5))。
[0116]
步骤s180，响应于业务事件成功插入业务事件记录表(也即该业务事件为首次上报)、或者业务事件记录表中记录的该业务事件的状态为未处理状态，将该业务事件的状态更新至：状态＝2处理中，以在此状态下对业务事件进行转换处理，获取对应的实体事件。
[0117]
步骤s190，执行翻译任务，也即对该业务事件进行翻译，获取对应的实体事件。可选的，在本实施例中，对业务事件的格式和内容进行转化处理，获取对应的实体事件数据，采用预定接口(例如api接口)获取相关联的补充数据对该实体事件数据进行补充，以获取对应的实体事件。由于一个实体事件可能由多个业务事件引发实体数据变更，因此基于实体事件的格式和内容转换获得的实体事件数据可能并不完整，由此本实施例通过预定接口从数据库中获取与该实体事件相关联的补充数据，以对业务事件转换的实体事件数据进行补充，保证了数据完整性。
[0118]
步骤s1a0，响应于翻译任务执行成功，将该业务事件的状态更新至：状态＝3已完成。
[0119]
步骤s1b0，向业务系统31返回上报结果：errorno＝0，也即该业务事件成功上报
(参见表(5))。
[0120]
由此，本发明实施例的数据埋点系统32的上报模块321通过执行上述步骤s110-s1e0，使得同一业务事件仅被处理一次，避免了数据重复处理。
[0121]
图7是本发明实施例的业务事件上报流程时序图。在一种可选的实现方式中，如图7所示，本实施例的业务事件上报流程包括以下步骤：
[0122]
步骤s71，业务系统31调用sdk上报接口上报业务事件。
[0123]
步骤s72，sdk上报接口向数据埋点系统32发起准入校验。
[0124]
步骤s73，数据埋点系统32中的准入处理单元321a对该业务事件进行准入校验。
[0125]
步骤s74，响应于该业务事件通过准入校验，将该业务事件插入业务事件记录表，若该业务事件成功插入业务事件记录表，在数据库中将该业务事件的状态确定为未处理状态。可选的，在本实施例中，业务事件记录表存储在对应的数据库中。
[0126]
步骤s75，数据埋点系统32向sdk上报接口反馈业务事件准入成功的消息。
[0127]
应理解，本实施例并不对上述步骤s74和步骤s75的执行顺序进行限制。
[0128]
步骤s76，sdk上报接口向数据埋点系统32发起翻译任务。
[0129]
步骤s77，数据埋点系统32响应于接收到翻译任务，控制更新数据库中的该业务事件的记录。其中，该业务事件的状态被更新为处理中状态。
[0130]
步骤s78，数据埋点系统32中的翻译处理单元321b执行翻译任务，也即对该业务事件进行格式和内容转化处理，获取对应的实体事件。
[0131]
步骤s79，响应于翻译处理单元321b的翻译任务执行完毕，控制更新数据库中的该业务事件的记录。其中，该业务事件的状态被更新为完成状态。
[0132]
步骤s7a0，数据埋点系统32向sdk上报接口反馈业务事件翻译成功的消息。
[0133]
步骤s7b0，sdk上报接口向业务系统反馈业务事件上报成功的消息。
[0134]
在本实施例的数据处理系统3中，业务事件上报流程包括准入流程(步骤s71-s75)和翻译流程(步骤s76-s7b)。其中，本实施例通过记录各业务事件的任务处理状态，并根据业务事件处理进度状态机监控各业务事件的处理进度，由此，可以避免数据重复处理，提高了数据处理效率，并保证的数据准确性和完整性。
[0135]
在一种可选的实现方式中，本实施例的数据埋点系统32还被配置为周期性扫描预定时间内的未完成的业务事件上报任务，并重新执行未完成的业务事件上报任务。可选的，数据埋点系统32还包括补偿模块，补偿模块被配置为启动定时任务，以控制数据埋点系统32重启未完成任务的上报任务，从而进行数据补偿。
[0136]
由于网络抖动、机器重启等原因造成流程中断而翻译失败或者一直处于处理中状态的业务事件，或者在预计上报完成时间内还未完成上报的业务事件(假设业务事件a一般可以在1min内完成上报，但5min后其仍处于处理中状态)，启动业务事件重新上报流程。应理解，本实施例并不对扫描周期和上述预定时间的具体值进行限定，其可以根据具体应用场景进行设置。
[0137]
可选的，上报重试接口说明如表(7)所示：
[0138]
表(7)
[0139][0140]
进一步可选的，上报重试的返回值说明如表(8)所示：
[0141]
表(8)
[0142]
字段类型说明errnoint0:成功，非0:失败errmsgstring错误或者成功提示信息datajson object错误信息的详细描述
[0143]
容易理解，业务事件上报重试的过程步骤与图6所示的实施例类似，在此不再赘述。
[0144]
图8是本发明实施例的业务事件上报重试流程时序图。在一种可选的实现方式中，如图8所示，本实施例的业务事件上报流程包括以下步骤：
[0145]
步骤s81，logbook补偿模块启动定时任务，也即启动扫描预定时间段内的未完成(未处理或长时间处于处理中)的业务事件上报任务。
[0146]
步骤s82，数据埋点系统32响应于定时任务启动消息，在数据库中查询过去预定时间内未完成的业务事件上报任务，也即查询过去预定时间内应该完成上报，但当前仍处于未处理或处理中状态的业务事件。
[0147]
步骤s83，数据库向数据埋点系统32返回过去预定时间内的未完成的业务事件上报任务。
[0148]
步骤s84，数据埋点系统32向logbook补偿模块返回过去预定时间内的未完成的业务事件上报任务。
[0149]
步骤s85，logbook补偿模块向数据埋点系统32发起重新翻译任务。
[0150]
步骤s86，数据埋点系统32响应于接收到重新翻译任务，控制更新数据库中的对应的业务事件的记录。其中，业务事件的状态被更新为处理中状态。
[0151]
步骤s87，数据埋点系统32中的翻译处理单元321b执行对应的业务事件的翻译任务，也即对上述对应的业务事件进行格式和内容转化处理，获取对应的实体事件。
[0152]
步骤s88，响应于翻译处理单元321b的翻译任务执行完毕，控制更新数据库中的对应的业务事件的记录。其中，业务事件的状态被更新为完成状态。
[0153]
步骤s89，数据埋点系统32向logbook补偿模块返回上报重试的任务处理结果。
[0154]
在本实施例的数据处理系统3中，由于数据库中存储的业务事件记录表中的业务事件均为已准入的业务事件，因此，与业务事件上报流程相比，业务事件上报重试流程无需准入流程，其通过数据埋点系统(logbook)的补偿模块周期性触发定时任务，以查询过去预定时间段内应完成但并未完成的业务事件上报任务，并发起重新翻译任务，使得翻译处理单元321b重新执行翻译任务，从而实现数据补偿。也即，本实施例通过记录各业务事件的任务处理状态，并根据业务事件处理进度状态机监控各业务事件的处理进度，由此实现查询过去预定时间段内应完成但并未完成的业务事件上报任务，对相关的业务事件重新翻译，实现了数据补偿，进一步保证了数据准确性和完整性。
[0155]
综上，本实施例可以通过监控具有唯一标识的业务事件的上报任务处理进度来避免重复处理数据，并进行数据补偿，确保了数据的准确性和完整性。
[0156]
本实施例中的数据埋点系统在执行业务系统上报流程中，通过对业务事件进行准入校验来保证数据准确性，并基于幂等处理方法避免了数据重复处理，同时通过启动定时任务执行业务上报重试流程以进行数据补偿，并且，在翻译过程中，通过api接口等对翻译获取的实体事件数据进行补充。由此，本实施例在通过数据埋点系统对业务系统和数据应用系统解耦后，仍能够保证数据的准确性和完整性。
[0157]
在本实施例中，如图3所示，分发模块322包括至少一个分发插件d1、d2等、以及分发处理单元322a。其中，分发插件被配置为从对应的存储单元中获取实体事件，并根据数据应用系统的需求对获取的实体事件进行分类。分发处理单元322a根据各数据应用系统33的需求对各实体事件的数据进行对应的处理，并将处理后的实体事件发送至对应的数据应用系统33。
[0158]
在一种可选的实现方式中，分发插件根据数据应用系统的需求对获取的实体事件进行分类，也即分发插件根据数据应用系统所需的实体事件的类型筛选出各数据应用系统分别所需的实体事件。例如，假设数据应用系统s1订阅有a类型实体事件和b类型实体事件，则分发插件在读取到a类型实体事件和b类型实体事件后，将a类型实体事件和b类型实体事件分为一类，也即数据应用系统s1所需的实体事件类。
[0159]
在本实施例中，数据埋点系统32具有对应的多个存储单元，例如存储单元a、存储单元b和存储单元c等，以用于存储不同类型的实体事件。可选的，存储单元与分发插件可以为多对多的关系，也即，同一个分发插件可以读取不同存储单元中的实体事件，多个分发插件也可以读取同一个存储单元中的实体事件。
[0160]
以下以采用基于kafka消费订阅系统的存储方式为例，其中，假设存储单元a用于存储a类型的实体事件，存储单元b用于存储b类型的实体事件，存储单元c用于存储c类型的实体事件。分发插件d1被配置为可以读取存储单元a和存储单元b中的实体事件，分发插件d2被配置为可以读取存储单元b和存储单元c中的实体事件。若数据应用系统33订阅了a类型的实体事件和c类型的实体事件，则分发插件d1根据数据应用系统33的订阅消息读取存储单元a中的a类型实体事件，并将读取的a类型实体事件发送至分发处理单元322a中进行处理后，经分发处理单元322a发送至对应的数据应用系统33，分发插件d2根据数据应用系
统33的订阅消息读取存储单元c中的c类型实体事件，并将读取的c类型实体事件发送至分发处理单元322a中进行处理后，经分发处理单元322a发送至对应的数据应用系统33。由此，本实施例通过采用存储单元与分发插件可以为多对多的关系，可以进一步提高数据分发效率。
[0161]
应理解，根据具体应用场景的需求，存储单元与分发插件也可以为一对多、一对一或多对一的关系，本实施例并不对此进行限制。
[0162]
在一种可选的实现方式中，由于各数据应用系统33对同一类实体事件中的实体事件数据的需求也不尽相同，而上报模块321存储至存储单元的实体事件基本为该实体事件完整的数据。因此，本实施例通过设置分发处理单元322a根据各数据应用系统33的数据需求，对其订阅的各实体事件的数据进行进一步数据筛选，从而将数据应用系统33所需的实体事件数据发送至数据应用系统33。
[0163]
例如，假设a类型的实体事件包括数据a1、数据a2、数据a3和数据a4。数据应用系统s1和数据应用系统s2均订阅了a类型的实体事件，但数据应用系统s1需要a类型实体事件中的数据a1、数据a3和数据a4，数据应用系统s2需要a类型实体事件中的数据a2和数据a4。分发处理单元322a在接收到分发插件发送的数据应用系统s1订阅的a类型的实体事件后，对a类型的实体事件数据进行筛选处理，也即筛除其中的数据a2，将获取的具有数据a1、数据a3和数据a4的实体事件发送至数据应用系统s1。分发处理单元322a在接收到分发插件发送的数据应用系统s2订阅的a类型的实体事件后，对a类型的实体事件数据进行筛选处理，也即筛除其中的数据a1和数据a3，将获取的具有数据a2和数据a4的实体事件发送至数据应用系统s2。
[0164]
本实施例的数据埋点系统可以通过设置分发插件来根据数据应用系统的实体事件类别需求对获取的实体事件进行分类，通过设置分发处理单元基于数据应用系统的数据需求对各实体事件进行对应的处理，将处理后的实体事件发送至对应的数据应用系统，由此，可以在确保数据准确性和完整性的同时，提高了数据处理效率，同时避免了数据应用系统在接收到实体事件数据后，需对数据进一步筛选的情况，进一步提高了数据应用系统的效率。
[0165]
图9是本发明实施例的分发模块的配置信息的er图。在本实施例中，分发模块322的配置信息主要包括与实体事件分发相关的配置。可选的，本实施例的分发模块322的配置信息的er图如图9所示。
[0166]
在本实施例中，分发模块322的配置信息主要包括分发插件(consumer_plugin)的配置信息、读取实体事件数据(store_config)的配置信息、实体事件处理方法(filter_rule)的配置信息、以及实体事件分发方法(dispatch_rule)的配置信息。
[0167]
分发插件(consumer_plugin)的配置信息包括分发插件的标识(consumer_plugin_id)和分发插件的名称(consumer_plugin_name)，用于描述一个分发插件，其可以对多个实体类型的实体事件队列(也即上述实体事件存储单元)中的实体事件进行一定处理后、按要求分发到对应的数据应用系统。
[0168]
读取实体事件数据(store_config)的配置信息包括所支持的存储介质的类型(store_type)和存储相关的上下文信息(store_context)，用于从存储有实体事件的存储介质(例如kafka的队列等)读取实体事件数据。其中，store_config支持从不同的存储介质
中读取实体事件，例如kafka的队列、磁盘等。
[0169]
实体事件处理方法(filter_rule)的配置信息包括数据处理方法的类型(filter_type)和处理脚本(filter_script)，用于采用不同的处理方法(filter_type)对读取到的实体事件进行不同的处理(filter_script)。可选的，处理方法(filter_type)可以为对实体事件数据进行筛选的方法。
[0170]
实体事件分发方法(dispatch_rule)的配置信息包括分发方法的类型(dispatch_type)和分发脚本(dispatch_script)，用于使用不同的分发方式(dispatch_type，如kafka/api等)对处理好的实体事件进行分发(dispatch_script)，以将实体事件分发到不同的数据应用系统。
[0171]
可选的，如图9所示，consumer_plugin分别与store_config、filter_rule和dispatch_rule均为一对一的关系。应理解，其对应关系根据具体应用场景进行调节，本实施例并不对此进行限制。
[0172]
本实施例基于图9所示的er图对数据埋点系统32中的分发模块322进行配置，以将存储介质中的实体事件分发至对应的数据应用系统33。
[0173]
在一种可选的实现方式中，为了在分发过程中避免数据重复，分发模块322需要对实体事件分发做去重处理。可选的，去重方式采用如下设计：
[0174]
(1)在分发插件维度，生成实体事件的全局唯一实体事件标识。
[0175]
(2)在实体事件分发前，将其记录至数据库中，并使用状态机跟踪实体事件分发进度。
[0176]
(3)采用实体事件的全局唯一实体事件标识进行去重处理。
[0177]
可选的，实体事件记录表(entity_event_dispatch_record)中记录的实体事件信息如表(9)所示：
[0178]
表(9)
[0179][0180]
图10是本发明实施例的实体事件分发进度状态机的示意图。在一种可选的实现方式中，如图10所示，在本实施例的分发模块322执行分发任务的过程中，实体事件的状态分别为：状态1表征实体事件处于未完成状态，状态3表征实体事件处于已完成状态，状态4表征实体事件处于作废状态。
[0181]
在分发模块322读取对应的存储单元中的实体事件后，将读取的实体事件的状态更新为状态1，也即未完成状态。分发模块322对读取的实体事件进行分发，分发成功后将该
实体事件的状态更新为状态3，也即已完成状态，若分发模块322判断读取的实体事件的格式或内容不符合预先约定的规则，则将该实体事件的状态更新为状态4，也即作废状态。
[0182]
图11是本发明实施例的实体事件分发的流程图。如图11所示，本实施例的数据埋点系统32中的分发模块322执行实体事件分发过程包括以下步骤：
[0183]
步骤s210，分发插件从对应的存储介质中读取实体事件。
[0184]
步骤s220，对该实体事件执行校验，确定该实体事件是否通过校验。可选的，在本实施例中，分发插件对实体事件的格式和内容进行校验，若其符合预先约定的规则，则校验通过，若不符合，则校验未通过。其中，若实体事件通过校验，则执行步骤s230，若实体事件未通过校验，则执行步骤s2a0，也即返回该实体事件分发失败，并不进行重试的消息，将其状态更新为已作废状态。
[0185]
步骤s230，在实体事件通过后，分发模块322生成该实体事件的全局唯一标识，并基于实体事件处理进度状态机根据该实体事件标识跟踪处理进度。
[0186]
步骤s240，将该实体事件插入至实体事件记录表中，此时，该实体事件的状态为：状态＝1未完成。其中，实体事件记录表记录有各实体事件的信息和当前所处的处理状态，具体可参照表(9)的内容，在此不再赘述。
[0187]
步骤s250，判断该实体事件是否成功插入至实体事件记录表。若插入成功，表征该实体事件为首次被分发，执行步骤s280，若插入失败，则表征该实体事件非首次被分发，执行步骤s260。
[0188]
步骤s260，响应于该实体事件插入实体事件记录表失败，根据该实体事件的标识查询实体事件记录表，若实体事件记录表中记录有该实体事件，则表征该实体事件已被读取，执行步骤s270，若实体事件记录表中未记录有该实体事件，则执行步骤s2d0，也即返回该实体事件分发失败，需进行重试的消息。
[0189]
步骤s270，响应于实体事件记录表中记录有该实体事件，查询实体事件记录表中记录的实体事件的状态是否为：状态＝1，也即是否为未完成状态。若实体事件为未完成状态，执行步骤s280，若实体事件并不处于未完成状态，则表征该实体事件已分发完成，其为重复数据，执行步骤s1c0，也即返回实体事件已分发成功的消息。
[0190]
步骤s280，执行过滤分发任务，也即对该实体事件进行过滤处理，以筛除对应的数据应用系统不需要的实体事件数据，将过滤处理后的实体事件发送至对应的数据应用系统。由此，可以在确保数据准确性和完整性的同时，提高了数据处理效率，同时避免了数据应用系统在接收到实体事件数据后，需对数据进一步筛选的情况，进一步提高了数据应用系统的效率。
[0191]
步骤s290，响应于分发任务执行成功，将该实体事件的状态更新至：状态＝3已完成。
[0192]
步骤s2b0，返回实体事件分发成功的消息。
[0193]
由此，本发明实施例的数据埋点系统32的分发模块322通过执行上述步骤s210-s1d0，使得对于同一实体事件，数据应用系统仅会接收到一次该实体事件的数据，避免了数据重复。
[0194]
本实施例的数据埋点系统可以通过设置分发插件来根据数据应用系统的实体事件类别需求对获取的实体事件进行分类，通过设置分发处理单元基于数据应用系统的数据
需求对各实体事件进行对应的处理，将处理后的实体事件发送至对应的数据应用系统，由此，可以在确保数据准确性和完整性的同时，提高了数据处理效率，同时避免了数据应用系统在接收到实体事件数据后，需对数据进一步筛选的情况，进一步提高了数据应用系统的效率。
[0195]
图12是本发明实施例的实体事件分发流程时序图。在一种可选的实现方式中，如图12所示，本实施例的实体事件分发流程包括以下步骤：
[0196]
步骤s121，在读取对应的存储介质中的实体事件后，分发模块生成该实体事件的全局唯一标识。
[0197]
步骤s122，将该实体事件插入至数据库中的实体事件记录表中，其中，该实体事件的状态为未完成状态。
[0198]
步骤s123：分发模块对该实体事件进行处理，并经分发插件将其分发至对应的数据应用系统。
[0199]
步骤s124，分发模块响应于该实体事件被成功分发，控制更新数据库中的实体事件记录表，以将该实体事件的状态更新为完成状态。
[0200]
本实施例的数据埋点系统可以通过设置分发插件来根据数据应用系统的实体事件类别需求对获取的实体事件进行分类，通过设置分发处理单元基于数据应用系统的数据需求对各实体事件进行对应的处理，将处理后的实体事件发送至对应的数据应用系统，由此，可以在确保数据准确性和完整性的同时，提高了数据处理效率，同时避免了数据应用系统在接收到实体事件数据后，需对数据进一步筛选的情况，进一步提高了数据应用系统的效率。
[0201]
图13是本发明实施例的数据埋点方法的流程图。如图13所示，本发明实施例的数据埋点方法包括以下步骤：
[0202]
步骤s310，接收业务系统上报的业务事件。在一种可选的实现方式中，根据预定的上报接口接收业务事件。也就是说，业务系统可以通过调用上报接口来上报业务事件。
[0203]
步骤s320，响应于该业务事件通过准入校验，对业务事件进行翻译，获取对应的实体事件。
[0204]
步骤s330，将实体事件分发至数据应用系统。
[0205]
在一种可选的实现方式中，本实施例的业务事件上报流程包括准入校验和翻译。可选的，对业务事件进行准入校验包括：确定业务系统与业务事件的类型是否具有关联关系，并对业务事件的内容和格式进行校验。也就是说，在准入校验过程中，首先确定该业务系统是否有上报该将该业务事件的事件类别的资格，也即在数据埋点系统中该业务系统与该类业务事件是否具有关联关系，之后校验该业务事件的内容和格式是否满足预先约定的规则。
[0206]
在一种可选的实现方式中，步骤s320具体可以包括：对所述业务事件的格式和内容进行转化处理，获取对应的实体事件。进一步可选的，由于实体事件的数据可能由于多个业务事件的产生而发生变化，因此由业务事件的内容转化处理得到的实体事件数据可能并不完整，由此，本实施例可以通过预定接口(例如api接口等)获取与实体事件相关联的补充数据，以对实体事件数据进行补充，从而保证实体事件的数据完整性。具体地，本实施例的翻译过程为：对业务事件的业务格式和内容进行转化处理，获取对应的实体事件数据，采用
预定接口获取相关联的补充数据对实体事件数据进行补充，以获取对应的实体事件，从而保证实体事件的数据完整性。
[0207]
在一种可选的实现方式中，在获取实体事件后，根据实体事件的类型存储实体事件。可选的，本实施例可以将不同类别的实体事件分别存储至对应的队列中。应理解，本实施例并不对存储实体事件的存储介质进行限制。
[0208]
在一种可选的实现方式中，为了避免同一个业务事件进行多次上报，也即为了实现同一个上报任务只能被处理一次，本实施例采用幂等处理方法来执行上报流程。
[0209]
进一步可选的，步骤s320包括：响应于业务事件通过准入校验，生成业务事件的标识，将业务事件插入至业务事件记录表中，并将业务事件的状态标记为未处理，响应于业务事件插入成功，将业务事件的状态更新为处理中，对业务事件进行翻译，获取对应的实体事件，响应于所述业务事件翻译完成，将所述业务事件的状态更新为已完成。
[0210]
进一步可选的，步骤s320包括：响应于业务事件插入失败，根据业务事件的标识查询业务事件记录表，响应于业务事件记录表中具有业务事件的标识且业务事件的状态为未处理，将业务事件的状态更新为处理中，对业务事件进行翻译，获取对应的实体事件，响应于业务事件翻译完成，将业务事件的状态更新为已完成。
[0211]
应理解，上述业务事件上报流程可具体参见图5-图7所示的实施例，在此不再赘述。
[0212]
在一种可选的实现方式中，由于网络抖动、机器重启等原因造成流程中断而翻译失败或者一直处于处理中状态的业务事件，或者在预计上报完成时间内还未完成上报的业务事件(假设业务事件a一般可以在1min内完成上报，但5min后其仍处于处理中状态)，启动业务事件重新上报流程。应理解，本实施例并不对扫描周期和上述预定时间的具体值进行限定，其可以根据具体应用场景进行设置。
[0213]
具体地，在本实施例中，上报重试流程包括：周期性扫描预定时间内的未完成的业务事件上报任务，重新执行未完成的业务事件上报任务。由此，本实施例可以通过跟踪各业务事件的任务处理状态，查询过去预定时间段内应完成但并未完成的业务事件上报任务，对相关的业务事件重新翻译，从而实现数据补偿，进一步保证了数据准确性和完整性。
[0214]
应理解，本实施例的上报重试流程可参考图8所示的时序图，在此不再赘述。
[0215]
在一种可选的实现方式中，步骤s330具体可以包括：根据各数据应用系统订阅的实体事件类型对各实体事件进行分类，根据各数据应用系统的需求对各实体事件的数据进行对应的处理，将处理后的实体事件发送至对应的数据应用系统。也就是说，本实施例根据数据应用系统所需的实体事件的类型筛选出各数据应用系统分别所需的实体事件，以基于数据应用系统维度对实体事件进行分类，并基于数据应用系统的数据需求对各实体事件进行对应的过滤处理，将处理后的实体事件发送至对应的数据应用系统。由此，可以在确保数据准确性和完整性的同时，提高了数据处理效率，同时避免了数据应用系统在接收到实体事件数据后，需对数据进一步筛选的情况，进一步提高了数据应用系统的效率。
[0216]
在一种可选的实现方式中，为了避免同一个实体事件被多次分发至同一数据应用系统，也即为了避免数据重复，本实施例采用去重处理方法来执行上报流程。
[0217]
进一步可选的，步骤s330包括：从对应的存储介质中读取实体事件，在实体事件校验通过后，生成实体事件的标识，将实体事件插入至实体事件记录表中，并将实体事件的状
态标记为未完成，响应于实体事件插入成功，执行实体事件分发任务，并将业务事件的状态标记为已完成。可选的，实体事件校验包括：基于预设的规则对读取的实体事件的格式和内容进行校验。
[0218]
进一步可选的，步骤s330包括：响应于实体事件插入失败，根据所述实体事件的标识查询所述实体事件记录表，响应于实体事件记录表中具有实体事件的标识且实体事件的状态为未完成，执行实体事件分发任务，并将所述业务事件的状态标记为已完成。
[0219]
应理解，上述业务事件上报流程可具体参见图10-图12所示的实施例，在此不再赘述。
[0220]
本发明实施例通过接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统，以实现数据埋点。也就是说，本实施例通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
[0221]
图14是本发明实施例的数据埋点装置的示意图。如图14所示，本发明实施例的是数据埋点装置14包括接收单元141、处理单元142和分发单元143。
[0222]
接收单元141被配置为接收业务系统上报的业务事件。处理单元142被配置为响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件。分发单元143被配置为将实体事件分发至数据应用系统。可选的，接收单元141进一步被配置为根据预定的上报接口接收所述业务事件。
[0223]
在一种可选的实现方式中，本实施例的数据埋点装置14还包括准入校验单元。准入校验单元被配置为对所述业务事件进行准入校验。进一步可选的，准入校验单元进一步被配置为确定所述业务系统与所述业务事件的类型是否具有关联关系，对所述业务事件的内容和格式进行校验。
[0224]
在一种可选的实现方式中，处理单元142进一步被配置为对所述业务事件的格式和内容进行转化处理，获取对应的实体事件。
[0225]
在一种可选的实现方式中，处理单元142包括转化子单元和补充子单元。转化子单元被配置为对所述业务格式和内容进行转化处理，获取对应的实体事件数据。补充子单元被配置为采用预定接口获取相关联的补充数据对所述实体事件数据进行补充，以获取所述对应的实体事件。
[0226]
在一种可选的实现方式中，本实施例的数据埋点装置14还包括数据存储单元。数据存储单元被配置为根据所述实体事件的类型存储所述实体事件。
[0227]
在一种可选的实现方式中，采用幂等处理方法执行本实施例的数据埋点方法。进一步可选的，处理单元142包括第一标识生成子单元、第一插入子单元、第一状态更新子单元、第一翻译子单元和第二状态更新子单元。
[0228]
第一标识生成子单元被配置为响应于所述业务事件通过准入校验，生成所述业务事件的标识。第一插入子单元被配置为将所述业务事件插入至业务事件记录表中，并将所述业务事件的状态标记为未处理。第一状态更新子单元被配置为响应于所述业务事件插入
成功，将所述业务事件的状态更新为处理中。第一翻译子单元被配置为对所述业务事件进行翻译，获取对应的实体事件。第二状态更新子单元被配置为响应于所述业务事件翻译完成，将所述业务事件的状态更新为已完成。
[0229]
进一步可选的，处理单元142包括第一查询子单元、第三状态更新子单元、第二翻译子单元和第四状态更新子单元。
[0230]
第一查询子单元被配置为响应于所述业务事件插入失败，根据所述业务事件的标识查询所述业务事件记录表。第三状态更新子单元被配置为响应于所述业务事件记录表中具有所述业务事件的标识且所述业务事件的状态为未处理，将所述业务事件的状态更新为处理中。第二翻译子单元被配置为对所述业务事件进行翻译，获取对应的实体事件。第四状态更新子单元被配置为响应于所述业务事件翻译完成，将所述业务事件的状态更新为已完成。
[0231]
在一种可选的实现方式中，本实施例的数据埋点装置14还包括扫描单元和上报重试单元。扫描单元被配置为周期性扫描预定时间内的未完成的业务事件上报任务。上报重试单元被配置为重新执行所述未完成的业务事件上报任务。
[0232]
在一种可选的实现方式中，分发单元143包括分类子单元、处理子单元和第一分发子单元。分类子单元被配置为根据各所述数据应用系统订阅的实体事件类型对各所述实体事件进行分类。处理子单元被配置为根据各所述数据应用系统的需求对各所述实体事件的数据进行对应的处理。第一分发子单元被配置为将处理后的实体事件发送至对应的数据应用系统。
[0233]
在一种可选的实现方式中，采用去重处理方法执行本实施例的数据埋点方法。
[0234]
进一步可选的，分发单元143包括第二标识生成子单元、第五状态更新子单元和第六状态更新子单元。第二标识生成子单元被配置为生成各所述实体事件的标识。第五状态更新子单元被配置为将所述实体事件插入至实体事件记录表中，并将所述实体事件的状态标记为未完成。第六状态更新子单元被配置为响应于所述实体事件插入成功，执行实体事件分发任务，并将所述实体事件的状态标记为已完成。
[0235]
进一步可选的，分发单元143包括第二插入子单元和第二分发子单元。第二插入子单元被配置为响应于所述实体事件插入失败，根据所述实体事件的标识查询所述实体事件记录表。第二分发子单元被配置为响应于所述实体事件记录表中具有所述实体事件的标识且所述实体事件的状态为未完成，执行实体事件分发任务，并将所述实体事件的状态标记为已完成。
[0236]
本发明实施例通过接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统，以实现数据埋点。也就是说，本实施例通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。
[0237]
图15是本发明实施例的电子装置的示意图。如图15所示，电子设备15为通用地址查询装置，其包括通用的计算机硬件结构，其至少包括处理器151和存储器152。处理器151
和存储器152通过总线153连接。存储器152适于存储处理器151可执行的指令或程序。处理器151可以是独立的微处理器，也可以是一个或者多个微处理器集合。由此，处理器151通过执行存储器152所存储的指令，从而执行如上所述的本发明实施例的方法流程实现对于数据的处理和对于其它装置的控制。总线153将上述多个组件连接在一起，同时将上述组件连接到显示控制器154和显示装置以及输入/输出(i/o)装置155。输入/输出(i/o)装置155可以是鼠标、键盘、调制解调器、网络接口、触控输入装置、体感输入装置、打印机以及本领域公知的其他装置。典型地，输入/输出装置155通过输入/输出(i/o)控制器156与系统相连。
[0238]
本领域的技术人员应明白，本技术的实施例可提供为方法、装置(设备)或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品。
[0239]
本技术是参照根据本技术实施例的方法、装置(设备)和计算机程序产品的流程图来描述的。应理解可由计算机程序指令实现流程图中的每一流程。
[0240]
这些计算机程序指令可以存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现流程图一个流程或多个流程中指定的功能。
[0241]
也可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程中指定的功能的装置。
[0242]
本发明的另一实施例涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。
[0243]
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指定相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0244]
以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

技术特征：
1.一种数据埋点方法，其特征在于，所述方法包括：接收业务系统上报的业务事件；响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；将实体事件分发至数据应用系统。2.根据权利要求1所述的方法，其特征在于，对所述业务事件进行准入校验包括：确定所述业务系统与所述业务事件的类型是否具有关联关系；对所述业务事件的内容和格式进行校验。3.根据权利要求1所述的方法，其特征在于，对所述业务事件进行翻译，获取对应的实体事件包括：对所述业务事件的格式和内容进行转化处理，获取对应的实体事件。4.根据权利要求3所述的方法，其特征在于，对所述业务事件的格式和内容进行转化处理，获取对应的实体事件包括：对所述业务格式和内容进行转化处理，获取对应的实体事件数据；采用预定接口获取相关联的补充数据对所述实体事件数据进行补充，以获取所述对应的实体事件。5.根据权利要求1所述的方法，其特征在于，所述方法还包括：根据所述实体事件的类型存储所述实体事件。6.根据权利要求1所述的方法，其特征在于，接收业务系统上报的业务事件包括：根据预定的上报接口接收所述业务事件。7.根据权利要求1所述的方法，其特征在于，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件包括：响应于所述业务事件通过准入校验，生成所述业务事件的标识；将所述业务事件插入至业务事件记录表中，并将所述业务事件的状态标记为未处理；响应于所述业务事件插入成功，将所述业务事件的状态更新为处理中；对所述业务事件进行翻译，获取对应的实体事件；响应于所述业务事件翻译完成，将所述业务事件的状态更新为已完成。8.根据权利要求7所述的方法，其特征在于，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件还包括：响应于所述业务事件插入失败，根据所述业务事件的标识查询所述业务事件记录表；响应于所述业务事件记录表中具有所述业务事件的标识且所述业务事件的状态为未处理，将所述业务事件的状态更新为处理中；对所述业务事件进行翻译，获取对应的实体事件；响应于所述业务事件翻译完成，将所述业务事件的状态更新为已完成。9.根据权利要求1所述的方法，其特征在于，所述方法还包括：周期性扫描预定时间内的未完成的业务事件上报任务；重新执行所述未完成的业务事件上报任务。10.根据权利要求1所述的方法，其特征在于，将实体事件分发至数据应用系统包括：根据各所述数据应用系统订阅的实体事件类型对各所述实体事件进行分类；根据各所述数据应用系统的需求对各所述实体事件的数据进行对应的处理；
将处理后的实体事件发送至对应的数据应用系统。11.根据权利要求1所述的方法，其特征在于，将实体事件分发至数据应用系统包括：生成各所述实体事件的标识；将所述实体事件插入至实体事件记录表中，并将所述实体事件的状态标记为未完成；响应于所述实体事件插入成功，执行实体事件分发任务，并将所述业务事件的状态标记为已完成。12.根据权利要求11所述的方法，其特征在于，将实体事件分发至数据应用系统还包括：响应于所述实体事件插入失败，根据所述实体事件的标识查询所述实体事件记录表；响应于所述实体事件记录表中具有所述实体事件的标识且所述实体事件的状态为未完成，执行实体事件分发任务，并将所述业务事件的状态标记为已完成。13.一种数据埋点系统，其特征在于，所述系统包括：上报模块，被配置为接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；分发模块，被配置为将实体事件分发至数据应用系统。14.根据权利要求13所述的系统，其特征在于，所述上报模块包括：准入处理单元，被配置为对所述业务事件进行准入校验；翻译处理单元，被配置为对所述业务事件的格式和内容进行转化处理，获取对应的实体事件，并根据所述实体事件的类型将所述实体事件存储至对应的存储单元。15.根据权利要求14所述的系统，其特征在于，所述分发模块包括：分发插件，被配置为从对应的存储单元中获取实体事件，根据各所述数据应用系统订阅的实体事件类型对各所述实体事件进行分类；分发处理单元，根据各所述数据应用系统的需求对各所述实体事件的数据进行对应的处理，并将处理后的实体事件发送至对应的数据应用系统。16.一种数据处理系统，其特征在于，所述系统包括：业务系统，被配置为上报业务事件；数据埋点系统，被配置为接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统；数据应用系统，被配置为接收所需的实体事件。17.一种数据埋点装置，其特征在于，所述装置包括：接收单元，被配置为接收业务系统上报的业务事件；处理单元，被配置为响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件；分发单元，被配置为将实体事件分发至数据应用系统。18.一种电子设备，包括存储器和处理器，其特征在于，所述存储器用于存储一条或多条计算机程序指令，其中，所述一条或多条计算机程序指令被所述处理器执行以实现如权利要求1-12中任一项所述的方法。19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机
程序，所述计算机程序被处理器执行时实现如权利要求1-12任一项所述的方法。20.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-12中任一项所述的方法。

技术总结
本发明实施例公开了一种数据埋点方法、数据埋点系统和数据处理系统。其中，本发明实施例通过接收业务系统上报的业务事件，响应于所述业务事件通过准入校验，对所述业务事件进行翻译，获取对应的实体事件，将实体事件分发至数据应用系统，以实现数据埋点。也就是说，本实施例通过数据埋点系统将业务事件翻译为实体事件，并基于数据应用系统的需求进行分发，使得业务系统仅需上报其感知的业务事件，而数据应用系统仅需订阅其所需要的实体事件，在保证数据完整和准确的同时，实现了业务系统和数据应用系统之间的解耦，使得业务系统从复杂的数据加工工作中释放，提高了数据处理效率。提高了数据处理效率。提高了数据处理效率。


技术研发人员：李颜翎 马英东 王长历
受保护的技术使用者：北京嘀嘀无限科技发展有限公司
技术研发日：2021.12.31
技术公布日：2023/7/13