VLDB 2023奖项公布，清华、第四范式、NUS联合论文获最佳工业界论文奖

大家好，我们又见面了啊~本文《VLDB 2023奖项公布，清华、第四范式、NUS联合论文获最佳工业界论文奖》的内容中将会涉及到等等。如果你正在学习科技周边相关知识，欢迎关注我，以后会给大家带来更多科技周边相关文章，希望我们能一起进步！下面就开始本文的正式内容~

VLDB 2023国际会议已经在加拿大温哥华成功举办。VLDB会议是数据库领域历史悠久的三大顶级会议之一，其全称为国际大型数据库会议。每届会议都集中展示了当前数据库研究的前沿方向、工业界的最新技术以及各国的研发水平，吸引了全球顶级研究机构的投稿

该会议对系统创新性、完整性、实验设计等方面都有极高的要求。VLDB 的论文接受率总体较低，约为18%，只有贡献很大的论文才有可能被录用。今年的竞争更加激烈。根据官方数据显示，今年 VLDB 共有9篇论文获得了最佳论文奖项，其中包括斯坦福大学、卡内基梅隆大学、微软研究院、VMware 研究院、Meta 等全球知名高校、研究机构和科技巨头的身影

其中由第四范式、清华大学以及新加坡国立大学联合完成的 "FEBench: A Benchmark for Real-Time Relational Data Feature Extraction" 论文，获得了最佳工业界论文 Runner Up 奖项。

这篇论文是由第四范式、清华大学和新加坡国立大学合作完成的。论文提出了一个基于工业界真实场景积累的实时特征计算测试基准，用于评估基于机器学习的实时决策系统

• 请点击以下链接查看论文：https://github.com/decis-bench/febench/blob/main/report/febench.pdf

• 项目地址：https://github.com/decis-bench/febench 需要进行重写的内容是：项目地址为https://github.com/decis-bench/febench

项目背景

基于人工智能的决策系统在许多行业场景中得到广泛应用。其中，许多场景涉及基于实时数据的计算，例如金融行业的反欺诈和零售行业的实时线上推荐。机器学习驱动的实时决策系统通常包括两个主要计算环节：特征和模型。由于业务逻辑的多样性以及线上低延迟和高并发的需求，特征计算往往成为整个决策系统的瓶颈。因此，需要进行大量的工程实践来构建一个可用、稳定和高效的实时特征计算平台。下图1展示了一个常见的反欺诈应用的实时特征计算场景。通过基于原始的刷卡流水记录表格进行特征计算，生成新的特征（例如最近10秒内的最大/最小/平均刷卡金额等特征），然后将其输入到下游模型进行实时推理

重写后的内容：图 1. 实时特征计算在反欺诈应用中的应用

一般而言，实时特征计算平台需要满足以下两个基本要求：

• 线上线下一致性：由于机器学习应用一般会分为线上和线上两个流程，即基于历史数据的训练和基于实时数据的推理。因此确保线上线下的特征计算逻辑一致性，对于保证线上线下最终业务效果一致至关重要。

• 线上服务的高效性：线上服务针对实时数据和计算，满足低延迟、高并发、高可用等需求。

图 2. 实时特征计算平台架构及工作流程

如上图 2 列举了一个常见的实时特征计算平台的架构。简单来说主要包含了离线计算引擎和在线计算引擎，其中的关键点是保证离线和在线计算引擎的计算逻辑一致性。目前市面上有许多特征平台可以满足上述要求，构成一个完整的实时特征计算平台，包括通用系统如 Flink，或者专用系统如 OpenMLDB、Tecton、Feast 等。但是，目前工业界缺少一个面向实时特征的专用基准来对这类系统的性能进行严谨科学的评估。针对该需求，本篇论文作者构建了 FEBench，一个实时特征计算基准测试，用于评估特征计算平台的性能，分析系统的整体延迟、长尾延迟和并发性能等。

技术原理

FEBench 的基准构建主要包括三个方面的工作：数据集收集、查询生成的内容需要进行改写和重写内容时，需要选择适当的模板

数据集搜集

研究团队总共收集了 118 个可以用于实时特征计算场景的数据集，这些数据集来自 Kaggle，Tianchi，UCI ML，KiltHub 等公开数据网站以及第四范式内部可公开数据，覆盖了工业界的典型使用场景，如金融、零售、医疗、制造、交通等行业场景。研究小组进一步按照表格数量及数据集大小将收集到的数据集进行了归类，如下图 3 所示。

重写内容：FEBench中数据集的表格数量和数据集大小的图表如下：

查询生成的内容需要进行改写

由于数据集数量较大，为每一个数据集人工生成特征抽取的计算逻辑工作量十分巨大，因此研究人员利用了如 AutoCross（参考论文：AutoCross: Automatic Feature Crossing for Tabular Data in Real-World Applications） 等自动机器学习技术，来为收集到的数据集自动化生成查询。FEBench 的特征选择和查询生成的内容需要进行改写过程包括以下四个步骤（如下图 4 所示）：

• 通过识别数据集中的主表（存储流式数据）和辅助表（例如静态 / 可追加 / 快照表），进行初始化。随后，分析主表和辅助表中具有相似名称或键关系的列，并枚举列之间的一对一 / 一对多关系，这些关系对应不同的特征操作模式。

• 将列关系映射到特征操作符。

• 在提取所有候选特征后，利用 Beam 搜索算法迭代生成有效的特征集。

• 选择的特征被转换为语义上等效的 SQL 查询。

图 4. FEBench 中查询的生成流程

重写内容时，需要选择适当的模板

在生成每个数据集的查询后，研究人员进一步使用聚类算法来选择代表性的查询作为查询模板，以减少对相似任务的重复测试。针对收集到的118个数据集和特征查询，使用DBSCAN算法对这些查询进行聚类，具体步骤如下：

• 将每个查询的特征划分为五个部分：输出列数、查询操作符总数、复杂运算符的出现频率、嵌套子查询层数以及时间窗口中最大元组的数量。由于特征工程查询通常涉及时间窗口，查询复杂性不受批处理数据规模的影响，因此数据集大小没有作为聚类特征之一。

• 使用逻辑回归模型来评估查询特征与查询执行特性之间的关系，将特征作为模型的输入，将特征查询的执行时间作为模型的输出。通过使用每个特征的回归权重作为其聚类权重，来考虑不同特征对聚类结果的重要性

• 基于加权查询特征，使用 DBSCAN 算法将特征查询划分为多个聚类。

以下图表展示了118个数据集在各个考量指标下的分布情况。图（a）显示了统计性质的指标，包括输出列数、查询操作符总数和嵌套子查询层数；图（b）显示了与查询执行时间相关性最高的指标，包括聚合操作个数、嵌套子查询层数和时间窗口个数

图 5. 118 个特征查询通过聚类分析得到 6 个集群，生成查询模板（Q0-5）

最终，根据聚类结果，将 118 个特征查询分为 6 个集群。对于每个集群，选择质心附近的查询作为候选模板。此外，考虑到不同应用场景下的人工智能应用可能有不同的特征工程需求，围绕每个集群的质心，尝试选择来自不同场景的查询，以更好地覆盖不同的特征工程场景。最终，从 118 个特征查询中选择了 6 个查询模板，适用于不同场景，包括交通、医疗保健、能源、销售，以及金融交易。这 6 个查询模板最终构成了 FEBench 最为核心的数据集和查询，用于进行实时特征计算平台的性能测试。

需要重写的内容是：基准评测（OpenMLDB与Flink）

在研究中，研究人员使用了FEBench来测试两个典型的工业界系统，分别是Flink和OpenMLDB。Flink是一个通用的批处理和流处理一致性计算平台，而OpenMLDB则是一个专用的实时特征计算平台。通过测试和分析，研究人员发现了这两个系统各自的优缺点以及背后的原因。实验结果显示，由于架构设计的不同，Flink和OpenMLDB在性能上存在差异。同时，这也说明了FEBench在分析目标系统能力方面的重要性。总结来说，研究的主要结论如下

• Flink 比 OpenMLDB 在延迟上慢两个数量级（图 6）。研究人员分析，其造成差距的主要原因在于两者系统架构的不同实现方式，其中 OpenMLDB 作为实时特征计算的专用系统，包含了基于内存的双层跳表等专门针对时序数据优化的数据结构，最终相比较于 Flink，在特征计算场景上有明显的性能优势。当然 Flink 作为通用系统，在可适用场景上比 OpenMLDB 更为广泛。

图 6. OpenMLDB 与 Flink 的 TP-50 延迟对比

• OpenMLDB 表现出明显的长尾延迟问题，而 Flink 的尾延迟更稳定（图 7）。注意，以下数字显示均为归一化到 OpenMLDB 和 Flink 各自的 TP-50 下的延迟性能，并不代表绝对性能的比较。 重新写为：OpenMLDB 在尾延迟方面存在明显的问题，而 Flink 的尾延迟更加稳定（见图7）。需要注意的是，下面的数字是将延迟性能归一化到 OpenMLDB 和 Flink 分别在 TP-50 下的性能，而不是绝对性能的比较

图 7. OpenMLDB 与 Flink 的尾延迟对比（归一化到各自的 TP-50 延迟）

研究人员对上述性能结果进行了更深入的分析：

• 根据执行时间进行拆解分析，微架构指标包括指令完成、错误分支预测、后端依赖和前端依赖等。不同查询模板在微观结构层面上的性能瓶颈有所不同。如图8所示，Q0-Q2的性能瓶颈主要在前端依赖，占整个运行时间的45%以上。在这种情况下，执行的操作相对简单，大部分时间花在处理用户请求和特征提取指令的切换上。而对于Q3-Q5，后端依赖（如缓存失效）和指令运行（包含更多复杂指令）成为更主要的因素。OpenMLDB通过针对性优化使其在性能上更加出色

图8展示了OpenMLDB与Flink的微架构指标分析

• 执行计划分析：以 Q0 为例，下图 9 比较了 Flink 和 OpenMLDB 的执行计划差异。Flink 中的计算运算符花费最多的时间，而 OpenMLDB 通过优化窗口处理和使用自定义聚合函数等优化技术减少了执行延迟。

第九张图展示了OpenMLDB和Flink在执行计划（Q0）方面的对比

如果用户期望复现以上实验结果，或者在本地系统上进行基准测试（论文作者也鼓励将测试结果在社区提交共享），可以访问 FEBench 的项目主页，获得更多信息。

• FEBench 项目：https://github.com/decis-bench/febench

• Flink 项目：https://github.com/apache/flink

• OpenMLDB 项目：https://github.com/4paradigm/OpenMLDB

文中关于工程的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《VLDB 2023奖项公布，清华、第四范式、NUS联合论文获最佳工业界论文奖》文章吧，也可关注golang学习网公众号了解相关技术文章。