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

1.本技术涉及数据处理技术领域，尤其涉及一种埋点数据处理方法、系统、电子装置及计算机可读存储介质。


背景技术：

2.互联网公司经常会需要进行用户行为事件定义，经过埋点数据收集、上报入仓后进行分析使用，数据驱动、辅助指导业务发展。一般情况下，用户行为事件埋点上报都颇具规模，行为事件多，并且数据流量非常大。另外，公司各个业务方都在上报和使用埋点数据，存在大量的部门、业务线交叉使用需求，利用其他业务线上报的数据进行样本收集和训练。


技术实现要素：

3.本技术的主要目的在于提出一种埋点数据处理方法、系统、电子装置及计算机可读存储介质，旨在解决上述场景下的埋点数据处理问题。
4.为实现上述目的，本技术实施例提供了一种埋点数据处理方法，所述方法包括：
5.接收客户端上报的埋点数据，所述埋点数据根据预设规则进行分流上报；
6.针对每个数据流分别进行传输和清洗后，写入数据湖中与所述数据流对应的数据表；
7.在所述数据湖中对每个所述数据表的数据按预设主键进行排序和索引，以供下游任务读取。
8.可选地，所述方法还包括：
9.响应于下游任务的数据读取请求，以行为事件级别对用户进行权限校验。
10.可选地，所述根据预设规则进行分流上报包括：
11.按照每个业务所需要的埋点数据对应的行为事件标识进行分流上报，将所述埋点数据以业务粒度进行隔离。
12.可选地，所述写入数据湖中与所述数据流对应的数据表包括：
13.在所述数据湖中按照不同业务划分多个数据表，将清洗后的每个数据流分别写入对应业务的数据表中。
14.可选地，所述对每个所述数据表的数据按预设主键进行排序和索引包括：
15.将每个数据表中的埋点数据按照行为事件标识进行排序；
16.将每个行为事件标识对应的数据块在所述数据表中的位置索引记录在表头中。
17.可选地，所述响应于下游任务的数据读取请求，以行为事件级别对用户进行权限校验包括：
18.接收下游任务通过hive的视图发出的对所述数据湖的数据读取请求，所述视图中记录了所述下游任务的用户具有读取权限的第一行为事件标识；
19.获取所述数据读取请求中的第二行为事件标识，在所述第二行为事件标识未超过所述第一行为事件标识的范围时，校验通过。
20.可选地，所述方法还包括：
21.在校验通过后，根据所述数据读取请求中的业务标识从所述数据湖中找到对应的数据表；
22.根据所述数据读取请求中的行为事件标识和所述索引从所述数据表中直接读取对应数据块的埋点数据。
23.此外，为实现上述目的，本技术实施例还提供一种埋点数据处理系统，所述系统包括：
24.接收模块，用于接收客户端上报的埋点数据，所述埋点数据根据预设规则进行分流上报；
25.写入模块，用于针对每个数据流分别进行传输和清洗后，写入数据湖中与所述数据流对应的数据表；
26.聚合模块，用于在所述数据湖中对每个所述数据表的数据按预设主键进行排序和索引，以供下游任务读取。
27.为实现上述目的，本技术实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的埋点数据处理程序，所述埋点数据处理程序被所述处理器执行时实现如上述的埋点数据处理方法。
28.为实现上述目的，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有埋点数据处理程序，所述埋点数据处理程序被处理器执行时实现如上述的埋点数据处理方法。
29.本技术实施例提出的埋点数据处理方法、系统、电子装置及计算机可读存储介质，能够通过对埋点数据处理架构的调整，和hudi能力的结合，在上报、传输、清洗过程中对埋点数据按规则分流，进行业务隔离，提升隔离性，并且在埋点数据落入数据湖表后进行排序和索引，减少读取数据时的io开销。
附图说明
30.图1为实现本技术各个实施例的一种应用环境架构图；
31.图2为现有的一种埋点数据处理链路的示意图；
32.图3为本技术第一实施例提出的一种埋点数据处理方法的流程图；
33.图4为本技术第二实施例提出的一种埋点数据处理方法的流程图；
34.图5为本技术第二实施例中的一种埋点数据处理链路示意图；
35.图6为本技术第三实施例提出的一种电子装置的硬件架构示意图；
36.图7为本技术第四实施例提出的一种埋点数据处理系统的模块示意图；
37.图8为本技术第五实施例提出的一种埋点数据处理系统的模块示意图。
具体实施方式
38.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
39.需要说明的是，在本技术实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。
40.请参阅图1，图1为实现本技术各个实施例的一种应用环境架构图。本技术可应用于包括，但不仅限于客户端2、服务端4、网络6的应用环境中。
41.其中，所述客户端2用于向用户提供各种应用程序(app)，并从所述app中获取埋点数据，上报至服务端。所述客户端2可以为pc(personal computer，个人电脑)、手机、平板电脑、便携计算机、可穿戴设备等终端设备。
42.所述服务端4用于接收所述客户端2上报的埋点数据，进行传输、清洗后写入数据湖，以供下游业务方使用。所述服务端4可以包括多个服务器，分别用于所述上报、传输、清洗、写入等各个过程的数据处理。所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。
43.所述网络6可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(global system of mobile communication，gsm)、宽带码分多址(wideband code division multiple access，wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi-fi等无线或有线网络。所述服务端4和一个或多个所述客户端2之间通过所述网络6通信连接，以进行数据传输和交互。
44.如图2所示，为现有的一种埋点数据处理链路的示意图。在现有的埋点数据处理方案中，客户端上报的埋点数据一般是经过一个传输任务(job)、一个清洗任务，落入数据仓库预先划分好的表、分区中，供业务方开发使用。这种业务划分是根据业务、事件类型等业务信息粗粒度划分的。下游任务只要申请了权限，即可以使用自己业务对应的数据表，也可以使用其他业务对应的数据表。
45.但是，这种现有埋点数据处理方案存在诸多不足，例如：
46.(1)一条数据流产出，隔离性不足。大量埋点数据由同一个传输任务、同一个清洗任务处理后落表，未针对各个业务进行数据隔离。这样容易出现在活动期间，某一个行为事件猛增影响整体任务处理进度的状况。
47.(2)业务线使用时需要过滤大量无用数据。在下游业务任务中，可能仅用到了该业务对应的一个行为事件进行分析，但是此行为事件与其他行为事件混在一起。如果通过where条件过滤，引擎层只能进行分区级过滤，是将整个分区的文件都加载进来再进行过滤，有比较大的文件读取输入/输出(io)浪费。当大量任务有这种情况时，浪费的资源开销会很多。
48.(3)各个业务方交叉使用数据，权限管理难。当某个业务方需要使用其他业务方的一个行为事件时，需要申请噶其他业务方对应的整个数据表的权限。权限管理的粒度粗，在交叉使用时存在数据安全风险。
49.(4)无法满足下游业务的分钟级诉求。目前埋点数据的流式传输方式，一般是小时
级清洗，下游使用时效也是小时级别，不满足用户时效性诉求。
50.因此，本技术实施例提出了一种新的埋点数据处理方案，针对上述问题进行优化。下面结合各个实施例对所述埋点数据处理方案进行详细说明。
51.实施例一
52.如图3所示，为本技术第一实施例提出的一种埋点数据处理方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述服务端作为执行主体对该方法进行说明。
53.该方法包括以下步骤：
54.s200，接收客户端上报的埋点数据，所述埋点数据根据预设规则进行分流上报。
55.如果所有埋点数据都通过一条数据流上报、传输、清洗，隔离性不足，容易出现活动期间，某一个行为事件猛增影响整体任务处理进度。因此，在本实施例中，从客户端上报埋点数据开始，就将所述埋点数据按照业务(business)需求进行隔离(即边缘分流)。
56.具体地，首先将所述埋点数据根据预设规则进行分离上报。所述预设规则是指按照每个业务所需要的埋点数据所对应的行为事件标识(id)进行分流上报，或者直接按照业务id进行分流上报，也就是以业务为分流粒度。例如，某个业务需要行为事件a、b、c对应的埋点数据，因此根据这三种行为事件的id获取到对应的埋点数据，作为一个数据流上报至服务端。
57.在一种可选实施例中，所述分流的粒度除了业务外，还可以考虑数据时效性级别(level：low/high)。针对有秒级时效性要求的数据，可以通过高优kafka链路，直接提供给在线服务使用，一般情况下这种级别的数据需求比较少。所述kafka是一个分布式、分区的、多副本的、多订阅者，基于分布式应用程序协调服务软件zookeeper协调的分布式日志系统，也可以作为消息队列系统。kafka是按秒进行任务的计算和应用，用于实时推荐、实时计算等场景中。而其他时效性要求比较低的数据，例如分钟级时效性要求的数据，可以按照继续执行下面的步骤，写入数据湖中。
58.s202，针对每个数据流分别进行传输和清洗后，写入数据湖中与所述数据流对应的数据表。
59.服务端接收到客户端按业务分流的埋点数据后，针对每个数据流分别进行单独的传输和清洗，然后将清洗后的数据写入数据湖。所述数据湖中按照业务划分了多个数据表，每个数据流清洗后的数据分别写入所述数据流对应的数据表中。在本实施例中，每个数据流单独上报、传输、清洗、落表，具体是指通过单独的进程来处理不同的数据流。例如，针对每个数据流，使用一个单独的上报进程，一个或多个单独的传输进程、清洗进程，以及一个单独的写入进程，不与其他数据流混合在同一进程中处理。
60.hudi(hadoop updates and incrementals，hadoop更新与增量)是一种数据湖解决方案，支持记录级别的事务更新/删除等操作。hudi将表分成多个分区，分区是以目录的形式存在，每个目录下面会存在属于该分区的多个文件，类似hive表，每个hudi表分区通过一个分区路径(partitionpath)来唯一标识。本实施例可以采用hudi技术实现所述数据湖，每个所述数据流写入业务对应的hudi表中。
61.并且，所述数据流写入所述hudi表时都是增补(append)，不带更新。所述hudi表写入数据时采用无索引(no index)模式，去掉bucket assign(将数据记录分配到特定的文件
组)等过程，可以提升写入速度。
62.s204，在所述数据湖中对每个数据表的数据按预设主键进行排序和索引，以供下游任务读取。
63.除了按业务分表存储每个数据流外，在数据写入所述数据湖的数据表后，还要进行聚合过滤(clustering)，也就是在所述数据湖中对所述数据表中的数据按预设主键进行排序和索引，使其更加方便读取。在本实施例中，所述预设主键可以为行为事件id。首先将每个数据表中的埋点数据按照行为事件id进行排序，使同一行为事件id对应的埋点数据排在一起，相当于按行为事件id对所述数据表中的埋点数据进行分类，每个行为事件id对应的埋点数据为一个数据块。然后将每个行为事件id对应的埋点数据在所述数据表中的位置索引(例如从第m条记录到第n条记录)记录在表头(head)中。
64.值得注意的是，所述数据湖中可以增量clustering，而不是在分区数据全部准备好之后才进行clustering，因此下游etl(extract-transform-load，抽取-转换-加载，一种数据仓库技术)延迟无明显增加。
65.经过clustering后，数据是有序的，索引记录了行为事件分布情况，可以根据查询条件进行文件级别、数据块级别的过滤。而flink、spark等引擎支持了hudi表谓词下推查询，提升查询效率。也就是说，当下游业务任务需要查询所述数据表中的埋点数据时，通过引擎层谓词下推的能力，可以实现文件级别、数据块级别的跳数(dataskip)，减少实际读取数据量，减少读取io开销。所述dataskip用来控制在事务处理期间，是否跳过不可用的数据存储空间(dbspace)。例如，某个业务对应的数据表中保存了行为事件a、b、c对应的埋点数据，在经过所述排序和索引后，若只需要读取行为事件c对应的埋点数据，则可以跳过行为事件a、b对应的数据。
66.本实施例提出的埋点数据处理方法，可以在上报、传输、清洗过程中对埋点数据按规则分流，进行业务隔离，提升隔离性，并且在埋点数据落入数据湖表后进行排序和索引，减少读取数据时的io开销。
67.实施例二
68.如图4所示，为本技术第二实施例提出的一种埋点数据处理方法的流程图。在第二实施例中，所述埋点数据处理方法在上述第一实施例的基础上，还包括步骤s306。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。
69.该方法包括以下步骤：
70.s300，接收客户端上报的埋点数据，所述埋点数据根据预设规则进行分流上报。
71.在本实施例中，从客户端上报埋点数据开始，就将所述埋点数据按照业务需求进行隔离。具体地，首先将所述埋点数据根据预设规则进行分离上报。所述预设规则是指按照每个业务所需要的埋点数据所对应的行为事件id进行分流上报，也就是以业务为分流粒度。例如，某个业务需要行为事件a、b、c对应的埋点数据，因此根据这三种行为事件的id获取到对应的埋点数据，作为一个数据流上报至服务端。
72.在一种可选实施例中，所述分流的粒度除了业务外，还可以考虑数据时效性级别。针对有秒级时效性要求的数据，可以通过高优kafka链路，直接提供给在线服务使用。而其他时效性要求比较低的数据，例如分钟级时效性要求的数据，可以按照继续执行下面的步
骤，写入数据湖中。
73.s302，针对每个数据流分别进行传输和清洗后，写入数据湖中与所述数据流对应的数据表。
74.服务端接收到客户端按业务分流的埋点数据后，针对每个数据流分别进行单独的传输和清洗，然后将清洗后的数据写入数据湖。所述数据湖中按照业务划分了多个数据表，每个数据流清洗后的数据分别写入所述数据流对应的数据表中。在本实施例中，每个数据流单独上报、传输、清洗、落表，具体是指通过单独的进程来处理不同的数据流。例如，针对每个数据流，使用一个单独的上报进程，一个或多个单独的传输进程、清洗进程，以及一个单独的写入进程，不与其他数据流混合在同一进程中处理。
75.本实施例可以采用hudi技术实现所述数据湖，每个所述数据流写入业务对应的hudi表中。并且，所述数据流写入所述hudi表时都是append，不带更新。所述hudi表写入数据时采用no index模式，去掉bucket assign等过程，可以提升写入速度。
76.s304，在所述数据湖中对每个数据表的数据按预设主键进行排序和索引，以供下游任务读取。
77.除了按业务分表存储每个数据流外，在数据写入所述数据湖的数据表后，还要进行clustering，也就是在所述数据湖中对所述数据表中的数据按预设主键进行排序和索引，使其更加方便读取。在本实施例中，所述预设主键可以为行为事件id。首先将每个数据表中的埋点数据按照行为事件id进行排序，使同一行为事件id对应的埋点数据排在一起，相当于按行为事件id对所述数据表中的埋点数据进行分类，每个行为事件id对应的埋点数据为一个数据块。然后将每个行为事件id对应的埋点数据在所述数据表中的位置索引记录在表头(head)中。
78.值得注意的是，所述数据湖中可以增量clustering，而不是在分区数据全部准备好之后才进行clustering，因此下游etl延迟无明显增加。
79.经过clustering后，数据是有序的，索引记录了行为事件分布情况，可以根据查询条件进行文件级别、数据块级别的过滤。而flink、spark等引擎支持了hudi表谓词下推查询，提升查询效率。也就是说，当下游业务任务需要查询所述数据表中的埋点数据时，通过引擎层谓词下推的能力，可以实现文件级别、数据块级别的dataskip，减少实际读取数据量，减少读取io开销。所述dataskip用来控制在事务处理期间，是否跳过不可用的dbspace。
80.s306，响应于下游任务的数据读取请求，以行为事件级别对用户进行权限校验。
81.在本实施例中，通过hive的视图(view)向用户提供所述数据湖的数据读取功能，并在view中以行为事件级别对用户进行读取权限校验。所述hive为一种数据仓库工具，用来进行数据提取、转化、加载。下游业务的用户通过view读取所述数据湖中的埋点数据，所述服务端通过给用户的view增加有权限的行为事件，达到行为事件级别权限管理。例如，业务a的用户需要使用业务b中的某一个行为事件对应的埋点数据，则在view中加上该行为事件id即可。在提交结构化查询语言(structured query language，sql)检查权限时就可以实现行为事件级别的权限校验，而不再需要申请整个数据表的读取权限。
82.具体地，服务端接收下游任务通过view发出的对所述数据湖的数据读取请求，所述view中记录了所述下游任务的用户具有读取权限的第一行为事件id，所述第一行为事件id为该用户已经申请了读取权限的一个或多个行为事件id。然后，服务端获取所述数据读
取请求中的第二行为事件id，也就是所述下游任务需要读取哪些行为事件。根据所述第二行为事件id和所述第一行为事件id的范围，可以判断权限校验是否通过。在所述第二行为事件id未超过所述第一行为事件id的范围时，校验通过，否则，校验不通过。
83.假设业务b包括行为事件c和d，而业务a需要使用行为事件c对应的埋点数据，则只需申请行为事件c的读取权限，在view中加上行为事件c的id。服务端在进行读取权限校验时，若发现业务a的读取请求中包括行为事件d的id，而view中只有行为事件c的id，则校验不通过，业务a无法读取行为事件d对应的埋点数据。
84.当校验通过后，服务端根据所述数据读取请求中的业务id从所述数据湖中找到该业务对应的数据表。然后在所述数据表中根据所述数据读取请求中的行为事件id和所述索引中该行为事件id对应数据的位置，直接找到所需要的行为事件id对应的数据块，跳过其他不需要的行为事件id对应的数据块，读取相应埋点数据返回给下游业务任务。
85.如图5所示，为本实施例中的一种埋点数据处理链路示意图。客户端app在上报埋点数据时，首先就需要按业务分流，其中时效性特别高(秒级)的数据流通过kafka链路直接提供给在线服务使用。所有数据流，包括所述时效性高的数据流和时效性稍低(分钟级)的数据流，都可以单独传输、清洗后，写入数据湖中对应的数据表。在数据湖中增量对每个数据流的数据分别进行聚合过滤。下游业务任务通过view读取所述数据湖中的埋点数据，并且在view中通过行为事件id进行读取权限管理。下游业务的用户通过view来使用数据，可以用于离线etl、实时计算、行为识别(behavior identity，bi)报表分析等场景。
86.并且，本实施例还支持增量传输、清洗数据后写入所述数据湖，所述数据湖支持增量消费，可达分钟级时效性。下游实时任务可以接在view后来使用消费的数据，达到流批统一。
87.本实施例提出的埋点数据处理方法，可以通过对埋点数据处理架构的调整，和hudi能力的结合，从上报开始对埋点数据按规则分流，进行业务隔离，提升隔离性，并且在埋点数据落入数据湖表后进行排序和索引，减少读取数据时的io开销。下游业务通过view来读取所述数据湖中的埋点数据，以行为事件级别进行权限校验，不用申请整个数据表的权限，增强了权限管理能力，降低了数据交叉使用的安全风险。另外，本实施例还支持增量处理和消费所述埋点数据，提高了时效性，可以满足下游业务的分钟级时效诉求。
88.实施例三
89.如图6所示，为本技术第三实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图6仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述服务端。
90.所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能
存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如埋点数据处理系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。
91.所述处理器22在一些实施例中可以是中央处理器(central processing unit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述埋点数据处理系统60等。
92.所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。
93.实施例四
94.如图7所示，为本技术第四实施例提出一种埋点数据处理系统60的模块示意图。所述埋点数据处理系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。
95.在本实施例中，所述埋点数据处理系统60包括：
96.接收模块600，用于接收客户端上报的埋点数据，所述埋点数据根据预设规则进行分流上报。
97.在本实施例中，从客户端上报埋点数据开始，就将所述埋点数据按照业务需求进行隔离。具体地，首先将所述埋点数据根据预设规则进行分离上报。所述预设规则是指按照每个业务所需要的埋点数据所对应的行为事件id进行分流上报，也就是以业务为分流粒度。例如，某个业务需要行为事件a、b、c对应的埋点数据，因此根据这三种行为事件的id获取到对应的埋点数据，作为一个数据流上报至服务端。
98.在一种可选实施例中，所述分流的粒度除了业务外，还可以考虑数据时效性级别。针对有秒级时效性要求的数据，可以通过高优kafka链路，直接提供给在线服务使用。而其他时效性要求比较低的数据，例如分钟级时效性要求的数据，可以写入数据湖中。
99.写入模块602，用于针对每个数据流分别进行传输和清洗后，写入数据湖中与所述数据流对应的数据表。
100.接收到客户端按业务分流的埋点数据后，写入模块602针对每个数据流分别进行单独的传输和清洗，然后将清洗后的数据写入数据湖。所述数据湖中按照业务划分了多个数据表，每个数据流清洗后的数据分别写入所述数据流对应的数据表中。在本实施例中，每个数据流单独上报、传输、清洗、落表，具体是指通过单独的进程来处理不同的数据流。例如，针对每个数据流，使用一个单独的上报进程，一个或多个单独的传输进程、清洗进程，以及一个单独的写入进程，不与其他数据流混合在同一进程中处理。
101.本实施例可以采用hudi技术实现所述数据湖，每个所述数据流写入业务对应的hudi表中。
102.聚合模块604，用于在所述数据湖中对每个数据表的数据按预设主键进行排序和
索引，以供下游任务读取。
103.除了按业务分表存储每个数据流外，在数据写入所述数据湖的数据表后，还要进行clustering，也就是在所述数据湖中对所述数据表中的数据按预设主键进行排序和索引，使其更加方便读取。在本实施例中，所述预设主键可以为行为事件id。首先将每个数据表中的埋点数据按照行为事件id进行排序，使同一行为事件id对应的埋点数据排在一起，相当于按行为事件id对所述数据表中的埋点数据进行分类，每个行为事件id对应的埋点数据为一个数据块。然后将每个行为事件id对应的埋点数据在所述数据表中的位置索引记录在表头(head)中。
104.值得注意的是，所述数据湖中可以增量clustering，而不是在分区数据全部准备好之后才进行clustering，因此下游etl延迟无明显增加。
105.经过clustering后，数据是有序的，索引记录了行为事件分布情况，可以根据查询条件进行文件级别、数据块级别的过滤。而flink、spark等引擎支持了hudi表谓词下推查询，提升查询效率。也就是说，当下游业务任务需要查询所述数据表中的埋点数据时，通过引擎层谓词下推的能力，可以实现文件级别、数据块级别的dataskip，减少实际读取数据量，减少读取io开销。所述dataskip用来控制在事务处理期间，是否跳过不可用的dbspace。
106.本实施例提出的埋点数据处理系统，可以在上报、传输、清洗过程中对埋点数据按规则分流，进行业务隔离，提升隔离性，并且在埋点数据落入数据湖表后进行排序和索引，减少读取数据时的io开销。
107.实施例五
108.如图8所示，为本技术第五实施例提出一种埋点数据处理系统60的模块示意图。在本实施例中，所述埋点数据处理系统60除了包括第四实施例中的所述接收模块600、写入模块602、聚合模块604之外，还包括校验模块606。
109.所述校验模块608，用于响应于下游任务的数据读取请求，以行为事件级别对用户进行权限校验。
110.在本实施例中，通过hive的view向用户提供所述数据湖的数据读取功能，并在view中以行为事件级别对用户进行读取权限校验。下游业务的用户通过view读取所述数据湖中的埋点数据，所述校验模块608通过给用户的view增加有权限的行为事件，达到行为事件级别权限管理。例如，业务a的用户需要使用业务b中的某一个行为事件对应的埋点数据，则在view中加上该行为事件即可。在提交sql检查权限时就可以实现行为事件级别的权限校验，而不再需要申请整个数据表的读取权限。
111.下游业务的用户通过view来使用数据，可以用于离线etl、实时计算、bi报表分析等场景。
112.并且，本实施例还支持增量传输、清洗数据后写入所述数据湖，所述数据湖支持增量消费，可达分钟级时效性。下游实时任务可以接在view后来使用消费的数据，达到流批统一。
113.本实施例提出的埋点数据处理系统，可以通过对埋点数据处理架构的调整，和hudi能力的结合，从上报开始对埋点数据按规则分流，进行业务隔离，提升隔离性，并且在埋点数据落入数据湖表后进行排序和索引，减少读取数据时的io开销。下游业务通过view来读取所述数据湖中的埋点数据，以行为事件级别进行权限校验，不用申请整个数据表的
权限，增强了权限管理能力，降低了数据交叉使用的安全风险。另外，本实施例还支持增量处理和消费所述埋点数据，提高了时效性，可以满足下游业务的分钟级时效诉求。
114.实施例六
115.本技术还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有埋点数据处理程序，所述埋点数据处理程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的埋点数据处理方法的步骤。
116.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
117.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
118.显然，本领域的技术人员应该明白，上述的本技术实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术实施例不限制于任何特定的硬件和软件结合。
119.以上仅为本技术实施例的优选实施例，并非因此限制本技术实施例的专利范围，凡是利用本技术实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术实施例的专利保护范围内。