CN113468199B - 索引更新方法及系统 - Google Patents

Abstract

本申请公开了一种索引更新方法，该方法包括：获取原始明细数据并进行轻度聚合，得到轻聚合数据；将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据；将所述宽表数据按业务进行拆分，得到不同的分流数据；将所述分流数据进行索引格式化，并写入对应的数据湖表，以增量化更新所述数据湖表中的索引数据。本申请还公开了一种索引更新系统、电子装置和计算机可读存储介质。由此，能够实现索引的增量化更新，提高时效。

Description

索引更新方法及系统

技术领域

本申请涉及数据传输与处理技术领域，尤其涉及一种索引更新方法、系统、电子装置及计算机可读存储介质。

背景技术

目前的搜索索引构建大多来自离线数据，通过t+1天/小时的数据构建全量索引，再结合少部分当天实时数据在线合并更新索引。这种方案得到的索引实效性较低，每个索引数据的属性字段少，并且难以扩展。

需要说明的是，上述内容并不用于限制申请保护范围。

发明内容

本申请的主要目的在于提出一种索引更新方法、系统、电子装置及计算机可读存储介质，旨在解决如何高效构建实时在线索引的问题。

为实现上述目的，本申请实施例提供了一种索引更新方法，所述方法包括：

获取原始明细数据并进行轻度聚合，包括按预设维度进行分组聚合和根据单调递增编号进行数据去重，得到轻聚合数据；

将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据；

将所述宽表数据按业务进行拆分，得到不同的分流数据；及

将所述分流数据进行索引格式化，并写入对应的数据湖表，以增量化更新所述数据湖表中的索引数据。

可选地，所述方法还包括：

根据所述数据湖表中的增量索引数据实时更新对应业务的在线索引。

可选地，所述方法还包括：

当所述业务的在线服务版本更新时，根据所述数据湖表中的全量索引数据提供所述业务的在线索引。

可选地，所述将所述轻聚合数据按照相同的维度进行拼接包括：

将所述轻聚合数据按照相同的维度进行实时流拼接，使多条实时流横向合并为一条；

对合并后的实时流进行外部维表拼接，补全每条数据的属性值，得到所述宽表数据。

可选地，所述聚合、拼接和拆分采用Flink进行处理。

可选地，所述原始明细数据、所述轻聚合数据、所述宽表数据、所述分流数据经由Kafka集群进行传输，以进行秒级数据拉取。

可选地，所述不同的分流数据分别经由不同的Kafka消息队列进行传输，写入不同的数据湖表。

可选地，所述索引为搜索索引，所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。

此外，为实现上述目的，本申请实施例还提供一种索引更新系统，所述系统包括：

聚合模块，用于获取原始明细数据并进行轻度聚合，包括按预设维度进行分组聚合和根据单调递增编号进行数据去重，得到轻聚合数据；

拼接模块，用于将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据；

拆分模块，用于将所述宽表数据按业务进行拆分，得到不同的分流数据；

写入模块，用于将所述分流数据进行索引格式化，并写入对应的数据湖表，以增量化更新所述数据湖表中的索引数据。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的索引更新程序，所述索引更新程序被所述处理器执行时实现如上述的索引更新方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有索引更新程序，所述索引更新程序被处理器执行时实现如上述的索引更新方法。

本申请实施例提出的索引更新方法、系统、电子装置及计算机可读存储介质，能够通过对原始明细数据的聚合、拼接、拆分等操作，将不同业务场景对应的索引数据增量化更新至数据湖表中，为所述业务的在线索引提供增量索引数据，提高索引推荐的实效性，且每个索引数据的属性可以通过拼接进行补全和扩展，提升了索引数据的完整性和实用性。

附图说明

图1为实现本申请各个实施例的一种应用环境架构图；

图2为本申请第一实施例提出的一种索引更新方法的流程图；

图3为本申请第二实施例提出的一种索引更新方法的流程图；

图4为本申请第三实施例提出的一种索引更新方法的流程图；

图5为本申请第四实施例提出的一种电子装置的硬件架构示意图；

图6为本申请第五实施例提出的一种索引更新系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

为了方便理解，以下提供了一些术语解释：

Flink集群(Flink Cluster)，是一个分布式系统，用于对无界和有界数据流进行有状态计算。Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。

Kafka，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，也可以作为消息队列系统。Kafka可以用于Web/Nginx日志、访问日志，消息服务等。Kafka是按秒进行任务的计算和应用，用于实时推荐、实时计算等场景中。

MySQL，是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。

HUDI(Hadoop Updates and Incrementals，Hadoop更新与增量)，采用并管理通过DFS(HDFS或云存储)存储大型分析数据集，支持在当前数据表中进行更新操作。HUDI将表组织成HDFS上某个指定目录(basepath)下的目录结构，表被分成多个分区，分区是以目录的形式存在，每个目录下面会存在属于该分区的多个文件，类似Hive表，每个HUDI表分区通过一个分区路径(PartitionPath)来唯一标识。

请参阅图1，图1为实现本申请各个实施例的一种应用环境架构图。本申请可应用于包括，但不仅限于数据源端2、服务端4的应用环境中。

其中，所述数据源端2用于提供索引需要的原始明细数据。在本申请各个实施例中，所述索引主要是指搜索的索引，例如稿件搜索、视频搜索等，用于在用户进行搜索时向用户进行线上推荐服务。所述索引中主要存储了稿件或者视频的基本信息，例如标题、分类等，以及搜索排序时依赖的一些其他信息，例如播放量、点赞数等。所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。所述数据源端2可以是MySQL数据库，也可以是某个应用程序(APP)的服务端或客户端。

所述服务端4用于对所述原始明细数据进行聚合、拼接(join)、分流等操作后写入数据湖中，以实现索引增量化更新。所述服务端4可以为服务器。所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。

所述数据源端2和所述服务端4可以是独立的两个或两个以上电子装置，例如所述数据源端2为用户手机，所述服务端4为服务器。此时所述数据源端2和服务端4之间可以通过有线或无线网络通信连接，以进行数据传输和交互。另外，所述数据源端2也可以存在于所述服务端4中，例如数据源端2为所述服务端4中的MySQL数据库。

实施例一

如图2所示，为本申请第一实施例提出的一种索引更新方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述索引更新服务平台作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，获取原始明细数据并进行轻度聚合，得到轻聚合数据。

所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。在本实施例中，所述原始明细数据可以从MySQL数据库、APP的服务端和/或客户端中获取。

在本实施例中，所述原始明细数据可以经由消息系统进行传输。所述消息系统可以由一个或多个Kafka集群构成，用于将所述数据发布到相应的主题下。通过所述Kafka集群，可以实现秒级数据拉取，提高处理时效。当然，在其他实施例中，也可以采用其他方式进行数据传输，在此不再赘述。

然后，对所述原始明细数据在Flink中按照预设维度进行轻度聚合，得到轻聚合数据。这样可以减少数据量，降低后续步骤的处理压力。所述轻度聚合主要包括Group By(分组聚合)和数据去重。Group By用于结合聚合函数，根据一个或多个列对结果集进行分组。而数据去重可以通过对每条数据分配Seq_ID实现。所述Seq_ID为实例级单调递增ID，重启会重置。

为了提升聚合性能，需要开启Flink的Minibatch功能。MiniBatch主要要基于事件消息来触发微批处理，事件消息会按指定的时间间隔在源头插入。微批处理是增加延迟来换取高吞吐的策略，通常对于聚合的场景，微批处理可以显著的提升系统性能。当开启MiniBatch时，对于缓存下来的N条数据一起触发，同key(关键字)的数据只会读写状态一次。所以当数据的key的重复率越大，攒批的大小越大，那么对状态的访问会越少，得到的吞吐量越高。

S202，将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据。

当通过轻度聚合处理得到所述轻聚合数据后，也可以将所述轻聚合数据通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述轻聚合数据后，在Flink中按照相同的维度进行实时流join(拼接)，多条实时流横向合并成一条。再进行Flink外部维表(例如MySQL)join，补全每条数据的属性值，打宽整个数据，得到宽表数据。这样可以克服现有技术中每个索引数据的属性字段少的缺陷，使数据更加完整。

S204，将所述宽表数据按业务进行拆分，得到不同的分流数据。

所述宽表数据也可以通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述宽表数据后，使用Flink进行数据分流操作，对所述宽表数据按照不同的业务场景进行拆分，一条实时流按业务拆分成多个实时流，得到不同的分流数据。

不同的分流数据分别发布到不同的Kafka消息队列中。每种业务场景分别有对应分流数据和Kafka消息队列。

S206，将所述分流数据进行索引格式化，并写入对应的数据湖表。

不同的业务服务分别消费对应的Kafka消息队列，得到对应的不同的分流数据。针对所述分流数据，在Flink中进行索引的格式化操作，将所述分流数据转换成最终的索引格式，然后将转换后的索引数据写入数据湖(HUDI)。每种业务场景均对应不同的HUDI表，该业务的索引数据可以增量化写入对应的HUDI表中。借助于HUDI的增量更新能力，可以实现增量化更新索引数据。

在上述各个步骤中，借助于Flink引擎，大大提高了实时索引数据的构建能力，在数据量和属性补全能力上有了很大的突破，基本能满足搜索各种场景的业务需要。

本实施例提出的索引更新方法，可以通过对原始明细数据的聚合、拼接、拆分等操作，将不同业务场景对应的索引数据增量化更新至数据湖表中，为所述业务的在线索引提供增量索引数据，提高索引推荐的实效性，且每个索引数据的属性可以通过拼接进行补全和扩展，提升了索引数据的完整性和实用性。

实施例二

如图3所示，为本申请第二实施例提出的一种索引更新方法的流程图。在第二实施例中，所述索引更新方法在上述第一实施例的基础上，还包括步骤S308。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S300，获取原始明细数据并进行轻度聚合，得到轻聚合数据。

所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。在本实施例中，所述原始明细数据可以从MySQL数据库、APP的服务端和/或客户端中获取。

在本实施例中，所述原始明细数据可以经由消息系统进行传输。所述消息系统可以由一个或多个Kafka集群构成，用于将所述数据发布到相应的主题下。通过所述Kafka集群，可以实现秒级数据拉取，提高处理时效。当然，在其他实施例中，也可以采用其他方式进行数据传输，在此不再赘述。

然后，对所述原始明细数据在Flink中按照预设维度进行轻度聚合，得到轻聚合数据。这样可以减少数据量，降低后续步骤的处理压力。所述轻度聚合主要包括Group By(分组聚合)和数据去重。Group By用于结合聚合函数，根据一个或多个列对结果集进行分组。而数据去重可以通过对每条数据分配Seq_ID实现。所述Seq_ID为实例级单调递增ID，重启会重置。

为了提升聚合性能，需要开启Flink的Minibatch功能。MiniBatch主要要基于事件消息来触发微批处理，事件消息会按指定的时间间隔在源头插入。微批处理是增加延迟来换取高吞吐的策略，通常对于聚合的场景，微批处理可以显著的提升系统性能。当开启MiniBatch时，对于缓存下来的N条数据一起触发，同key的数据只会读写状态一次。所以当数据的key的重复率越大，攒批的大小越大，那么对状态的访问会越少，得到的吞吐量越高。

S302，将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据。

当通过轻度聚合处理得到所述轻聚合数据后，也可以将所述轻聚合数据通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述轻聚合数据后，在Flink中按照相同的维度进行实时流join，多条实时流横向合并成一条。再进行Flink外部维表(例如MySQL)join，补全每条数据的属性值，打宽整个数据，得到宽表数据。这样可以克服现有技术中每个索引数据的属性字段少的缺陷，使数据更加完整。

S304，将所述宽表数据按业务进行拆分，得到不同的分流数据。

所述宽表数据也可以通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述宽表数据后，使用Flink进行数据分流操作，对所述宽表数据按照不同的业务场景进行拆分，一条实时流按业务拆分成多个实时流，得到不同的分流数据。

不同的分流数据分别发布到不同的Kafka消息队列中。每种业务场景分别有对应分流数据和Kafka消息队列。

S306，将所述分流数据进行索引格式化，并写入对应的数据湖表。

不同的业务服务分别消费对应的Kafka消息队列，得到对应的不同的分流数据。针对所述分流数据，在Flink中进行索引的格式化操作，将所述分流数据转换成最终的索引格式，然后将转换后的索引数据写入数据湖(HUDI)。每种业务场景均对应不同的HUDI表，该业务的索引数据可以增量化写入对应的HUDI表中。借助于HUDI的增量更新能力，可以实现增量化更新索引数据。

在上述各个步骤中，借助于Flink引擎，大大提高了实时索引数据的构建能力，在数据量和属性补全能力上有了很大的突破，基本能满足搜索各种场景的业务需要。

S308，根据所述数据湖表中的增量索引数据实时更新对应业务的在线索引。

在本实施例中，通过HUDI提高增量读取能力，在线业务可以实时获取HUDI的增量索引数据，更新在线索引，为用户进行线上推荐服务。例如，用户在业务A的在线服务中进行视频搜索，业务A对应的HUDI表A中新增了索引数据B和C，则业务A的在线推荐服务可以根据索引数据B和C向用户推荐索引数据B和C对应的视频D和视频E。

也就是说，在本实施例中，不同的业务场景的在线推荐服务分别使用不同的Kafka和HUDI表，根据所述HUDI表中的增量索引数据实时更新对应业务的在线索引。

在Flink加上HUDI的增量化更新能力上，做到了实时离线索引的一体化，大大提高了在线服务的索引实时更新能力。

另外，本实施例可以作为机器学习的一部分，将索引数据作为机器学习算法的基本物料，通过机器学习算法完成用户搜索时的索引推荐排序等操作。

本实施例提出的索引更新方法，可以通过对原始明细数据的聚合、拼接、拆分等操作，将不同业务场景对应的索引数据增量化更新至数据湖表中，并根据所述数据表中的增量索引数据实时更新对应业务的在线索引，实现了实时离线索引的一体化，大大提高了在线服务的索引实时更新能力，使得索引推荐的实效性有效提升，且每个索引数据的属性可以通过拼接进行补全和扩展，提升了索引数据的完整性和实用性。

实施例三

如图4所示，为本申请第三实施例提出的一种索引更新方法的流程图。在第三实施例中，所述索引更新方法在上述第二实施例的基础上，还包括步骤S410。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S400，获取原始明细数据并进行轻度聚合，得到轻聚合数据。

所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。在本实施例中，所述原始明细数据可以从MySQL数据库、APP的服务端和/或客户端中获取。

在本实施例中，所述原始明细数据可以经由消息系统进行传输。所述消息系统可以由一个或多个Kafka集群构成，用于将所述数据发布到相应的主题下。通过所述Kafka集群，可以实现秒级数据拉取，提高处理时效。当然，在其他实施例中，也可以采用其他方式进行数据传输，在此不再赘述。

然后，对所述原始明细数据在Flink中按照预设维度进行轻度聚合，得到轻聚合数据。这样可以减少数据量，降低后续步骤的处理压力。所述轻度聚合主要包括Group By(分组聚合)和数据去重。Group By用于结合聚合函数，根据一个或多个列对结果集进行分组。而数据去重可以通过对每条数据分配Seq_ID实现。所述Seq_ID为实例级单调递增ID，重启会重置。

为了提升聚合性能，需要开启Flink的Minibatch功能。MiniBatch主要要基于事件消息来触发微批处理，事件消息会按指定的时间间隔在源头插入。微批处理是增加延迟来换取高吞吐的策略，通常对于聚合的场景，微批处理可以显著的提升系统性能。当开启MiniBatch时，对于缓存下来的N条数据一起触发，同key的数据只会读写状态一次。所以当数据的key的重复率越大，攒批的大小越大，那么对状态的访问会越少，得到的吞吐量越高。

S402，将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据。

当通过轻度聚合处理得到所述轻聚合数据后，也可以将所述轻聚合数据通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述轻聚合数据后，在Flink中按照相同的维度进行实时流join，多条实时流横向合并成一条。再进行Flink外部维表(例如MySQL)join，补全每条数据的属性值，打宽整个数据，得到宽表数据。这样可以克服现有技术中每个索引数据的属性字段少的缺陷，使数据更加完整。

S404，将所述宽表数据按业务进行拆分，得到不同的分流数据。

所述宽表数据也可以通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述宽表数据后，使用Flink进行数据分流操作，对所述宽表数据按照不同的业务场景进行拆分，一条实时流按业务拆分成多个实时流，得到不同的分流数据。

不同的分流数据分别发布到不同的Kafka消息队列中。每种业务场景分别有对应分流数据和Kafka消息队列。

S406，将所述分流数据进行索引格式化，并写入对应的数据湖表。

不同的业务服务分别消费对应的Kafka消息队列，得到对应的不同的分流数据。针对所述分流数据，在Flink中进行索引的格式化操作，将所述分流数据转换成最终的索引格式，然后将转换后的索引数据写入数据湖(HUDI)。每种业务场景均对应不同的HUDI表，该业务的索引数据可以增量化写入对应的HUDI表中。借助于HUDI的增量更新能力，可以实现增量化更新索引数据。

在上述各个步骤中，借助于Flink引擎，大大提高了实时索引数据的构建能力，在数据量和属性补全能力上有了很大的突破，基本能满足搜索各种场景的业务需要。

S408，根据所述数据湖表中的增量索引数据实时更新对应业务的在线索引。

在本实施例中，通过HUDI提高增量读取能力，在线业务可以实时获取HUDI的增量索引数据，更新在线索引，为用户进行线上推荐服务。例如，用户在业务A的在线服务中进行视频搜索，业务A对应的HUDI表A中新增了索引数据B和C，则业务A的在线推荐服务可以根据索引数据B和C向用户推荐索引数据B和C对应的视频D和视频E。

也就是说，在本实施例中，不同的业务场景的在线推荐服务分别使用不同的Kafka和HUDI表，根据所述HUDI表中的增量索引数据实时更新对应业务的在线索引。

在Flink加上HUDI的增量化更新能力上，做到了实时离线索引的一体化，大大提高了在线服务的索引实时更新能力。

另外，本实施例可以作为机器学习的一部分，将索引数据作为机器学习算法的基本物料，通过机器学习算法完成用户搜索时的索引推荐排序等操作。

S410，当所述业务的在线服务版本更新时，根据所述数据湖表中的全量索引数据提供所述业务的在线索引。

所述HUDI表在为不同的业务场景的在线推荐服务提供增量索引数据的同时，HUDI本身的更新能力也能保持所述HUDI表最终的全量数据能够与在线保持一致。当所述HUDU表对应业务的在线服务进行版本更新时，可以提供给在线服务一个时效性比较接近的全量索引数据版本，方便在线服务进行reload(重新加载)。

本实施例提出的索引更新方法，不仅可以根据所述数据表中的增量索引数据实时更新对应业务的在线索引，实现了实时离线索引的一体化，大大提高了在线服务的索引实时更新能力，使得索引推荐的实效性有效提升，而且可以提供给在线服务一个时效性比较接近的全量索引数据版本，方便在线服务版本更新时重新加载所述业务的在线索引。

实施例四

如图5所示，为本申请第四实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图5仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述服务端4。

所述存储器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还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述索引更新系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例五

如图6所示，为本申请第五实施例提出一种索引更新系统60的模块示意图。所述索引更新系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述索引更新系统60包括：

聚合模块600，用于获取原始明细数据并进行轻度聚合，得到轻聚合数据。

所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。在本实施例中，所述原始明细数据可以从MySQL数据库、APP的服务端和/或客户端中获取。

在本实施例中，所述原始明细数据可以经由消息系统进行传输。所述消息系统可以由一个或多个Kafka集群构成，用于将所述数据发布到相应的主题下。通过所述Kafka集群，可以实现秒级数据拉取，提高处理时效。当然，在其他实施例中，也可以采用其他方式进行数据传输，在此不再赘述。

然后，对所述原始明细数据在Flink中按照预设维度进行轻度聚合，得到轻聚合数据。这样可以减少数据量，降低后续步骤的处理压力。所述轻度聚合主要包括Group By(分组聚合)和数据去重。Group By用于结合聚合函数，根据一个或多个列对结果集进行分组。而数据去重可以通过对每条数据分配Seq_ID实现。所述Seq_ID为实例级单调递增ID，重启会重置。

为了提升聚合性能，需要开启Flink的Minibatch功能。MiniBatch主要要基于事件消息来触发微批处理，事件消息会按指定的时间间隔在源头插入。微批处理是增加延迟来换取高吞吐的策略，通常对于聚合的场景，微批处理可以显著的提升系统性能。当开启MiniBatch时，对于缓存下来的N条数据一起触发，同key的数据只会读写状态一次。所以当数据的key的重复率越大，攒批的大小越大，那么对状态的访问会越少，得到的吞吐量越高。

拼接模块602，用于将所述轻聚合数据按照相同的维度进行拼接，得到宽表数据。

当通过轻度聚合处理得到所述轻聚合数据后，也可以将所述轻聚合数据通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述轻聚合数据后，在Flink中按照相同的维度进行实时流join，多条实时流横向合并成一条。再进行Flink外部维表(例如MySQL)join，补全每条数据的属性值，打宽整个数据，得到宽表数据。这样可以克服现有技术中每个索引数据的属性字段少的缺陷，使数据更加完整。

拆分模块604，用于将所述宽表数据按业务进行拆分，得到不同的分流数据。

所述宽表数据也可以通过所述Kafka集群进行传输，即发布到Kafka消息队列中。从所述Kafka消息队列消费所述宽表数据后，使用Flink进行数据分流操作，对所述宽表数据按照不同的业务场景进行拆分，一条实时流按业务拆分成多个实时流，得到不同的分流数据。

不同的分流数据分别发布到不同的Kafka消息队列中。每种业务场景分别有对应分流数据和Kafka消息队列。

写入模块606，用于将所述分流数据进行索引格式化，并写入对应的数据湖表。

不同的业务服务分别消费对应的Kafka消息队列，得到对应的不同的分流数据。针对所述分流数据，在Flink中进行索引的格式化操作，将所述分流数据转换成最终的索引格式，然后将转换后的索引数据写入数据湖(HUDI)。每种业务场景均对应不同的HUDI表，该业务的索引数据可以增量化写入对应的HUDI表中。借助于HUDI的增量更新能力，可以实现增量化更新索引数据。

在上述过程中，借助于Flink引擎，大大提高了实时索引数据的构建能力，在数据量和属性补全能力上有了很大的突破，基本能满足搜索各种场景的业务需要。

本实施例提出的索引更新系统，可以通过对原始明细数据的聚合、拼接、拆分等操作，将不同业务场景对应的索引数据增量化更新至数据湖表中，为所述业务的在线索引提供增量索引数据，提高索引推荐的实效性，且每个索引数据的属性可以通过拼接进行补全和扩展，提升了索引数据的完整性和实用性。

实施例六

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有索引更新程序，所述索引更新程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的索引更新方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (10)

1.一种索引更新方法，其特征在于，所述方法包括：

获取原始明细数据进行轻度聚合，包括按预设维度进行分组聚合和根据单调递增编号进行数据去重，得到轻聚合数据；

将所述轻聚合数据按照相同的维度进行实时流拼接，使多条实时流横向合并为一条，对合并后的实时流进行外部维表拼接，补全每条数据的属性值，得到宽表数据；

将所述宽表数据按业务进行拆分，得到不同的分流数据；及

将所述分流数据进行索引格式化，并写入对应的数据湖表，以增量化更新所述数据湖表中的索引数据。

2.根据权利要求1所述的索引更新方法，其特征在于，所述方法还包括：

根据所述数据湖表中的增量索引数据实时更新对应业务的在线索引。

3.根据权利要求1所述的索引更新方法，其特征在于，所述方法还包括：

当所述业务的在线服务版本更新时，根据所述数据湖表中的全量索引数据提供所述业务的在线索引。

4.根据权利要求1-3任一项所述的索引更新方法，其特征在于，所述聚合、拼接和拆分采用Flink进行处理。

5.根据权利要求1-3任一项所述的索引更新方法，其特征在于，所述原始明细数据、所述轻聚合数据、所述宽表数据、所述分流数据经由Kafka集群进行传输，以进行秒级数据拉取。

6.根据权利要求5所述的索引更新方法，其特征在于，所述不同的分流数据分别经由不同的Kafka消息队列进行传输，写入不同的数据湖表。

7.根据权利要求1所述的索引更新方法，其特征在于，所述索引为搜索索引，所述原始明细数据为所记录的用户历史搜索行为相关的明细数据。

8.一种索引更新系统，其特征在于，所述系统包括：

聚合模块，用于获取原始明细数据并进行轻度聚合，包括按预设维度进行分组聚合和根据单调递增编号进行数据去重，得到轻聚合数据；

拼接模块，用于将所述轻聚合数据按照相同的维度进行实时流拼接，使多条实时流横向合并为一条，对合并后的实时流进行外部维表拼接，补全每条数据的属性值，得到宽表数据；

拆分模块，用于将所述宽表数据按业务进行拆分，得到不同的分流数据；

写入模块，用于将所述分流数据进行索引格式化，并写入对应的数据湖表，以增量化更新所述数据湖表中的索引数据。

9.一种电子装置，其特征在于，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的索引更新程序，所述索引更新程序被所述处理器执行时实现如权利要求1至7中任一项所述的索引更新方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有索引更新程序，所述索引更新程序被处理器执行时实现如权利要求1至7中任一项所述的索引更新方法。

Images