广告增量实时索引构建实践

本期作者

1.前言

在广告检索系统中，增量索引（实时索引）是一类常见的技术，用于使广告信息的变更及时生效。其中一种主要的思路即由检索系统消费广告更新数据流，实时更新内存索引，对此行业中已有很多优秀方案实现。然而，对与如何构建出“广告更新数据”，却鲜有提及。

本文将针对如何构建出完整、可靠、可维护的“广告更新数据流”进行展开叙述。

2.业务背景

在线广告是实现流量变现重要业务模式。广告检索系统是其中的核心系统之一，其一种常见的架构是由“索引构建服务”构建出广告物料索引数据，再由“检索引擎”加载数据，用于在线广告检索。

相比于搜索或推荐业务，广告的物料数据量不算最大，但构建逻辑极其复杂。以下图为例，构建广告物料索引以单元（unit）表为核心，查询相关的账号（account）、计划（plan）、创意（creative），进而再通过创意id查找图片（image），视频（video），up主（up）等。

相关数据查询完后，提取各表数据并组装，形成一个个“广告文档(doc)"。单个doc的文本的形式如下：

由于单元数据量较大，相关数据库表多（超过100张表），这些单元还分属不同的业务线、不同类型、不同样式，所关联的构建逻辑也不尽相同，形成了复杂的查找链路。

并且，随着业务量越来越大，整体的延迟越来越长，广告的物料数据更新不及时，影响了广告的时效性，最终降低了广告的投放体验和效率。

3.方案演进

广告索引的构建和下发经历了漫长的优化迭代，包括本文主要介绍的增量索引在内，主要分为如下三个阶段：

阶段一：全量串行——所有数据串行查询，串行构建

阶段二：分批间并行，批次内并行——将全量的单元id分为多个批次，多批次间并行执行，批次内按照数据依赖的拓扑关系并行查询组装

阶段三：增量构建+全量构建——定时构建的广告索引，有数据发生变更则构建发生数据变化的这部分广告物料索引

	阶段一：全量串行	阶段二：分批并行	阶段三：增量+全量
流程
特点	数据库负载：一般 构建耗时：长 数据传输负载：很高	数据库负载：很高 构建耗时：较短 数据传输负载：很高	数据库负载：很低 构建耗时：全量耗时长，增量耗时很短 数据传输负载：很低

从阶段一到阶段二，在时效性上有一定提升，但是给数据库带来了很大的压力，且网络传输负载很高。

在查询全量数据的前提下，无论做何种并行化优化，该查的数据还是得查，数据库负载会随着业务扩张不断增加，数据量也会一直膨胀，更新时效性也越来越差，优化的边际递减效应明显。

因此阶段三中引入了增量索引技术，采用全量索引+增量索引的构建模式。

4.增量索引

增量索引的广告物料分为两类：

• 全量广告索引——定时（1小时或者更长）全量构建所有广告单元数据，产出一份包含全量单元的索引数据

• 增量广告索引——只构建数据发生了变化的广告单元，单独产出一份增量单元索引数据

两者的触发机制不同，产出的数据结构类似，但是包含的内容范围不同。

如上图，紫色模块是全量索引构建的流程，蓝色部分是增量索引构建的流程，绿色部分是公共的部分。全量增量的主要差异在于：全量索引任务的unit_id是所有单元的unit_id，增量索引任务的unit_id是广告数据发生变化的单元的unit_id。

下游检索引擎加载这两类索引，将其合并成一个整体，作为广告物料库使用。

相比起之前的全量方案，增量索引的方案里的全量索引构建频率降低到小时级别，增量只构建和下发发生变化的广告单元，大大降低了数据库负载和数据传输的带宽，提高了更新时效性。

变化的unit_id —— 反查库表？

上图中，接收到DB的原始变更消息后，还需要将其转译为相关变化的unit_id。那么，当单元关联的上百个实体（表）中，部分的数据发生了变化时，如何确认其对应的哪个unit_id发