广告召回技术标准化进程

一 底层技术的分析与预判

1.1 广告召回概述

广告召回本质上是一种数据处理过程，可以使用常见的数据处理模型来分析其特性。

为了方便理解，本文仅选取读、写、性能要求来分析广告召回系统。

• 读场景
  • 广告召回多为大规模在线计算，需要处理较为复杂的数据查询逻辑，如多表join、表内聚合等计算，这与OLAP系统比较类似
  • 广告召回要求在高并发读的场景下保持低时延、高性能，这与OLTP系统的设计目标较为吻合
  • 广告召回的流程、逻辑相对固定，但每次pv的请求参数不同，与OLTP场景比较接近。
• 写场景
  • 广告数据大多要求具备“行粒度事务写”的能力，且数据变化较快，这一点与OLTP系统的设计目标较为吻合

综合来看，广告召回系统与OLTP系统的设计思路更为接近，可以在OLTP的基础上适当弱化“写事务”处理能力，仅支持行粒度事务写即可。但是，广告召回系统需要在OLTP的基础上优化复杂数据查询逻辑的处理能力。

1.2 数据接口

召回数据接口建设方向主要把握关键的两点：

• 标准化
  标准化指在特定的数据场景中兼容业界通用的标准语法，如再通用数据模型场景下支持SQL语法、在搜索特色场景支持ElasticSearch DSL语法等。SQL的优点是应用范围极广，语法图灵完备，缺点是对复杂逻辑的表达效率较低；DSL的优点是表达效率高，可以针对场景定制，缺点是只能在特定的领域内推广。
• 支持局部定制化
  对于复杂、复用度较高、性能敏感的局部逻辑，需要支持类似UDF的定制能力，用来弥补标准化数据语言的必然短板。

1.2.1 数据查询接口

广告召回过程本质上是一次检索过程。当前广告业务形态主要用到倒排检索、向量检索、数值计算、过滤/排序/截断等基本能力，其数据场景尚没有明显的“领域”特点，因此中期发展方向是逐步支持SQL查询语法。

1.2.2 数据写入接口

从标准化的角度出发，函谷数据写入语法应该与SQL的语法保持一致。同时，由于函谷定位与提供数据实时更新，函谷数据写入提供消息队列、HTTP接口等多种形式。

1.2.3 插件接口

为了方便用户开发UDF，需要提供C++语言的数据封装类。为了降低使用成本，封装类需要兼容任意表定义，并提供高效查询方法。

1.3 执行引擎

1.3.1 拆解数据查询过程

抽象来看，所有的计算都可以拆解为拓扑、算子/UDF、数据三个维度，如布尔表达式“（a == 1 || b == 2）&& c == 3”，可以将其拆结为下图：

图中的线段组合为拓扑，菱形为算子/UDF，圆形为数据。拓扑结构确定计算的依赖关系，进而确定计算的顺序；算子确定对数据的处理逻辑；数据即为一切数据处理的对象。数据又可以分为对象数据和参数两种。对象数据指的是数据处理的对象，是处理过程中的“变量”或是“占位符”，如表中的某个字段，即图中的a、b、c。参数指的是在某次请求中指定的具体数值，体现了某次查询的具体意图，如上图中的1、2、3。在实际应用场景中，多次查询的拓扑、算子/UDF、参数的特点都是不同的，可以按照下列几种方式分类：

在线数据服务的拓扑、算子/UDF大部分情况下是固定的，但其输入参数是持续变化的。例如，广告召回时，倒排检索->过滤->打分->排序->截断的拓扑是基本确定的，输入参数一般是用户特征标签、实验信息，每次查询的标签都是不一样的。广告召回服务符合大部分在线数据服务特点，设计时可以参考上述相关逻辑。

1.3.2 SQL解析与执行

针对不同的场景，可以选择不同的执行方式。对于固定部分，可以在离线完成优化和编译，在线直接执行，以此获得较高的性能；对于变化部分，需要在线解析，以获得灵活性，但是相应的性能会变差一些。

未来检索平台会提供SQL解析、拓扑优化、基础算子等能力，广告召回服务更适合在离线把SQL编译成拓扑和算子，交付给执行引擎。

1.4 部署&运维

当执行引擎对多个业务方提供服务的时候，就会出现“隔离”与“复用”之间的矛盾。
隔离的目标与对应的方式主要有如下几种：

结合上述分析，我们有三个层面的工作要做：

• 建设灵活的集群隔离能力：基于K8S的韵味体系
• 建设互不干扰的发布系统：全图化引擎、场景化发布
• 建设公共软件库，并做好维护和透出：公共组件库

1.5 数据模型&存储

在大数据存储检索场景，由于性能需求和存储成本不同，需要分级存储。分级存储的意义一是根据实际业务性能需要灵活调控存储成本，二是在成本一定的基础上，通过数据在不同介质上的智能迁移实现性能最优。分级存储的建设分为两个阶段。
第一阶段：支持静态配置不同数据的存储介质

第二阶段：自适应逐级缓存

1.6 检索

检索部分的重点是底层内核的设计，这部分内容在单独的一篇文章《广告检索内核设计》中介绍。