HA3 SQL样本实验：一种混合计算查询的全新样本解决方案

原创

于 2023-08-09 14:07:24 发布 · 3k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#sql #数据库

作者：陆唯一(芜霜)

HA3（对外开源代号：Havenask ）是阿里智能引擎团队自研的大规模分布式检索系统，广泛应用于阿里内部的搜索业务，是十多年来阿里在电商领域积累下来的核心竞争力产品。Ha3 SQL 是在原有Ha3引擎基础上，新增的SQL查询功能，引擎内置了SQL形式的的查询语法，允许用户通过写SQL语句来构造引擎查询。

一、概述

在搜推广这个业务场景内，样本构建是特征数据链路的一个重要环节，而且从工作流程上来看，做样本也通常是算法同学开始一个新实验的第一步。在这个环节的技术选型上，考虑到功能性、稳定性和上游数据的所在，大部分团队最终的选择都是MaxCompute。MaxCompute是一流的离线数据处理平台，但是在和算法同学的沟通交流中，我们频繁听到这些使用上的困扰：

样本存储占用了太多的MaxCompute空间；
样本构建任务会消耗非常多的计算资源，集群常年被样本任务耗尽资源；
新增特征、调整样本分布等实验的构建样本周期很长，时间成本高。

我们分析了这些困扰背后的本质原因，针对这里的关键点提供了一套新的样本解决方案：HA3 SQL样本实验功能。

通过在『构建样本-训练』这个流程中插入一个由HA3 SQL提供的查询层，非常精准地解决了上面列举的几个主要困扰点。目前已有多个算法团队接入这套样本解决方案并从中获得数据链路的全方面优化。

在本文中，我们会给出关于样本构建问题的分析与思考，介绍HA3 SQL样本实验的方案架构和里面值得和大家分享的一些技术细节，同时还会给出一些已经接入场景的性能报告和接入前后的成本对比。最后是我们在这个功能研发过程中的一些经验教训和未来工作展望。

二、样本场景问题介绍与分析

2.1 样本的现状

先简单介绍一下，在搜推广这个场景，样本通常长什么样，是怎么构建出来的。以最常见的CTR样本（曝光-点击样本）为例，参考谷歌WDL论文中的例子，一条典型的样本记录是这个样子的：

pv_id	app_id	user_id	click	app_title	app_cate	app_download_count	user_age	user_sex
xxx_xx	1234	4321	1	twitter	social	3000	20	0

pv_id是某次请求对应的uuid，这条样本表达的含义就是：某次请求返回的app被用户在手机上点击了，在点击发生的当时，这个app的名字、下载量等属性是某某某，这个用户的年龄、性别等属性是某某某。一份样本就由上亿条这样的记录构成，这个数据会被训练时的机器学习模型消费，用于学习点击这个行为和各个特征之间的相关性。

这种样本常见的构建方式是这样的：pv_id app_id user_id click这些属性来源于用户行为埋点日志，记录了用户的行为发生时的一些关键id，算法同学会建立一系列上下游任务把这部分数据导入到MaxCompute上变成一张表示用户行为的分区表，同时还会准备若干以pv_id/app_id/user_id之类的字段为主键的属性表，通常称之为维表，最后以用户行为这张表作为起始，用上面的各个id把这些属性表join起来，最后再按训练平台的要求做一些格式上的处理，就生成了最终的样本表。

以SQL伪代码表示，关键步骤基本就是这样一段逻辑：

select pv_id, app_id, user_id, timestamp, click, download
from clean_behaviour_table
left outer join app_profile_table
on clean_behaviour_table.app_id = app_profile_table.app_id
left outer join user_profile_table
on clean_behaviour_table.user_id = user_profile_table.user_id

目前大部分的训练平台对于MaxCompute样本的支持基本都局限于单个MaxCompute表的遍历读取，所以算法同学需要把上面的这段sql在MaxCompute上执行一边，把结果写入到另外一张结果表里作为最终的样本。

与此同时，算法同学平时在样本方面的实验迭代主要是在行列两个维度进行的：