VLDB 2021 最新论文介绍：基于持久内存的 AI 在线决策引擎
Paper:
本文解析了发表于VLDB 2021第四范式与英特尔联合实验室以及新加坡国立大学最新研究成果：基于英特尔® 傲腾™ 持久内存的特征工程内存数据库。
随着人工智能（AI）的蓬勃发展，越来越多的在线决策系统采用AI技术帮助完成实时的在线决策。我们统称这类应用为“在线增强决策” （On-line decision augmentation （OLDA））。典型的OLDA应用包括实时信用卡反欺诈，个性化推荐等等。
一个OLDA系统包含两个子系统：线下训练系统和在线预估系统。如图1所示，我们把海量的历史数据放入左侧的线下训练系统中， 这套系统会帮我们从历史数据中提取对提高识别度有用的特征，并训练出超高纬度复杂的AI模型。在此之后，我们会把训练好的模型部署到在线预估系统中。在线预估系统需要根据用户的刷卡行为实时提取出用户历史行为信息，并导入AI模型进行实时打分，从而进行预测。整个在线预估系统对实时性有很高的要求（~毫秒级），本文主要关注在线预估系统部分的性能优化。
图1：OLDA系统
我们以反欺诈系统为例，为了能成功预测一次刷卡行为是否是欺诈刷卡，在线预估系统必须包含了几个步骤。当用户刷卡产生了新的刷卡行为数据，我们会先从内存特征数据库中提取出定义好的特征，再把这些提取好的特征传入之前训练好的机器学习模型中进行实时预测，并输出结果。
什么是特征？
图2：信用卡反欺诈特征样例
当刷卡行为产生时，POS机会产生一条记录，并传到服务端。如图2所示，单从这条新产生的记录是无法判断本次刷卡是一次正常的刷卡还是一次盗刷。想要判断一次刷卡是否为盗刷，除了利用这条新的刷卡记录外，我们还需要根据新记录提取背后隐藏的海量信息。如图2所示，通过Card ID， 我们可以通过查询特征数据库了解这张卡的级别，近期消费记录，以及这张卡的主人最近3笔/5笔/7笔信用卡消费总额信息等。以上这些隐藏信息我们称为特征。通过提取这些隐藏特征，我们的模型可以为用户画像，并最终判断新产生的刷卡行为是不是欺诈。这些特征需要从用户近期的数据中实时提取，特征提取越多，模型预测约准确。以反欺诈为例，从用户刷卡行为产生，到最后的模型给出预测结果往往需要在几个或十几个毫秒内完成。这就对我们的实时特征数据库的查询性能要求极高。
提取特征是非常费时的。首先特征提取设计多个数据库查询操作。以反欺诈为例，一个用户的一次刷卡行为，会触发上千次的数据库查询请求。与此同时，这些特征中很多的实时特征，比如计算最近一条刷卡记录和最新刷卡记录的金额差，必须等新的用户刷卡数据产生并传输到后端系统后才能开始提取。与此同时，大部分的实时特征都会涉及在不同维度进行海量的时间窗口查询。这些特征提取的工作负载特点和传统的OLTP、OLAP或HTAP负载有很多不同。我们选取了两种目前最先进的主流商用内存数据库针对实时特征提取负载进行了性能测试。因为NDA原因，我们称他们DB-X和DB-Y。如图3所示，随着时间窗口数的增加，DB-X和DB-Y的查询延迟直线上升，且当窗口数大于4之后，两种数据库的查询性能已不能满足OLDA在线预估系统的性能要求。而真实业务场景下，时间窗口数远远大于4。
图3：实时特征提取性能
特征工程数据库
图4：FEDB架构图
为了能更快的抽取实时特征，我们设计了特征工程数据库（FEDB）。如图4所示， FEDB包括特征抽取执行引擎（FEQL）和存储引擎两部分。FEQL使用llvm对查询语句进行编译优化，并对多窗口类型的查询进行了优化处理，从而使特征抽取的语句解析执行效率大大增加。在存储引擎部分，FEDB采用了两层的跳表结构。在第一层跳表中存储了特征的主键，而在第二层中存储了主键对应的各个时间窗口。当我们在查询某个主键下多个时间窗口范围内的数据，只需要先在第一层跳表中定位到对应的主键，再继续在第二层中查询时间窗口即可。
图5：两层跳表结构
图6：DRAM版本FEDB性能对比
如图6所示，图中D-FEDB表示DRAM版本的FEDB。我们在DRAM版本FEDB、商用内存数据库DB-X和DB-Y上变换时间窗口个数和特征主键数目，并运行特征抽取查询对比性能。如图所示，DRAM版本的FEDB可以取得最高17.63倍和11.05倍的性能提升。具体的实验环境设置和负载介绍可以查询我们的VLDB文章。
DRAM内存版本的FEDB还有什么痛点？
DRAM内存版本FEDB可以很好的满足特征抽取实时性的要求，但在实际的部署过程中，我们仍然发现以下两个痛点。
- 内存消耗巨大
实时特征抽取所需存储的原始数据量巨大。如图7所示，以信用卡反欺诈为例，FEDB存储了7亿用户，10亿左右信用卡的相关信息。因为内存大小限制，我们只存储了最近3个月超过10亿条刷卡记录信息。这部分数据已经占用了超过3 terabyte（TB）的空间。当我们考虑多副本的情况，数据规模超过10 TB 。
图7：反欺诈负载数据规模
2.恢复时间
由于FEDB在DRAM内存中存储着海量的实时数据，当系统由于故障或升级而不得不重启节点时，FEDB需要把海量数据从磁盘读入内存，整个过程需要很长的时间才能恢复。
英特尔® 傲腾™ 持久内存（PMEM）
图8：英特尔® 傲腾™ 持久内存两种工作模式
英特尔® 傲腾™ 持久内存（PMEM）给我们提供了解决以上两个痛点的新思路。PMEM有两种工作模式：Memory Mode和 App Direct Mode. 如图8左侧所示，当PMEM以Memory Mode方式运行，PMEM会被当做内存的一部分对用户透明。Memory Mode的好处是应用无需做任何修改便可以直接在Memory Mode的PMEM上运行。运行在Memory Mode上的应用只会看到一块超大的内存。但与此同时，Memory Mode在系统重启后，PMEM上的数据都会被重置丢失，Memory Mode并不能享受PMEM 持久性的优势。当PMEM运行在App Direct Mode下， PMEM会以独立块设备的形式被系统感知。系统通过英特尔提供的编程库PMDK使用PMEM。当PMEM运行在App Direct Mode下，应用可以享受PMEM的大容量特性的同时，数据在系统重启后依然存在。但现有程序需要通过PMDK重新编写。
图9：使用不同PMEM模式的FEDB
我们在PMEM上做了什么？
如图9所示，我们利用PMEM的两种模式，分别实现了两个版本的FEDB。最左边的版本是原始的基于DRAM内存的FEDB。和传统的内存数据库相同，FEDB查询数据的过程都在DRAM内存中完成。所有新的数据都会通过写入SSD上的日志和Snapshots进行持久化。为了更快的验证PMEM的性能，我们先用Memory Mode用DRAM + PMEM的大内存直接替换DRAM内存（图9中部分）。于此同时，我们用App Direct Mode重构了FEDB下层的存储引擎，用PMDK实现了基于PMEM的双层链表结构，移除了传统的日志和Snapshot机制。（图9右半部分）。图10给出了测试中各种数据库系统的配置。
图10 数据库缩写系统配置
测试对比结论：
我们对比了DRAM版本的FEDB以及各种PMEM版本的FEDB变种，分别运行真实的工业级信用卡反欺诈应用，得出以下结论。
- DRAM版本的FEDB平均时延比传统内存数据库快37到610倍。
图11 信用卡反欺诈应用在不同数据库的性能对比
2. 长尾延迟 TP-9999 比较（持久内存（PA-FEDB）vs. 纯内存（D-FEDB））
基于英特尔® 傲腾™ 持久内存进行持久化数据结构设计的 FEDB 舍弃了原有纯内存方案以及基于外存储设备的备份机制，实现了长尾延迟（TP-9999）接近 20% 的改善（见下图，PA-FEDB 为基于持久内存优化的 FEDB，D-FEDB 为内存版本的 FEDB ）
图12：DRAM FEDB vs PMEM FEDB系统性能
3. 数据恢复时间比较
如图13 所示，在服务中断情况下实现数据快速恢复，服务恢复时间减少 99.7%，全面降低对线上服务质量的影响。如在论文中描述的结果（见下图，PA-FEDB 为基于持久内存优化的 FEDB，D-FEDB 为内存版本的 FEDB），在实际业务场景中，其数据恢复时间从原来的六个小时缩短至一分钟左右。
图13：恢复时间对比
4. 硬件成本比较（10TB 业务数据）
我们对比了10 TB 信用卡反欺诈业务部署在不同集群上的对比，如图14所示，英特尔® 傲腾™ 持久内存的加持满足特征工程数据库对大内存的需求。下图显示了在论文实验中使用的机器配置，在 10TB 数据的业务场景中，基于持久内存的 FEDB 的硬件成本仅为基于纯内存版本的 41.6%。
图14：硬件成本对比
总结：
本文分析了目前工业级OLDA在线预估系统面临挑战，并着重描述了：
- 本文以第四范式实施的某大型银行信用卡反欺诈系统为例，分析并总结了工业级OLDA在线预估工作负载的特点。我们在现有的商用内存数据库上测试了OLDA在线预估负载。我们发现因为OLDA在线预估负载的独特性，现有的商用内存数据库并不能很好的满足这类应用高实时性的要求。
- 我们设计了新的特征工程数据库FEDB。FEDB在执行引擎和存储引擎上针对OLDA工作负载特点进行了针对性的优化，FEDB特征提取性能在信用卡反欺诈场景下比传统商用内存数据库快37至610倍。
- 为了解决在线预估系统内存消耗大，恢复慢的痛点，我们基于英特尔® 傲腾™ 持久内存（PMEM）重新设计了FEDB的存储引擎。
- 我们在真实的反欺诈负载下测试对比了FEDB不同PMEM用法下的性能。基于持久内存的FEDB可以减少19.7%的长尾时延，缩短99.7%的恢复时间，与此同时，降低58.4%的成本。