创意电子

标题: AI驱动的实时决策系统，第四范式OpenMLDB数据库入选顶会VLDB [打印本页]

作者: 机器之心Pro 时间: 2021-8-27 17:17
标题: AI驱动的实时决策系统，第四范式OpenMLDB数据库入选顶会VLDB

机器之心专栏

机器之心编辑部

第四范式与新加坡国立大学及英特尔的最新联合研究成果——基于长期内存优化的 AI 实时决策系统数据库 OpenMLDB（Open Source Machine Learning Database）被国际数据库顶级集会 VLDB 2021 任命。

VLDB (Very Large Data Base) 是数据库研究人员、厂商、应用开辟者，以及用户广泛参与的年度国际集会，它与 SIGMOD、ICDE 被公以为数据管理与数据库领域的三大国际顶尖学术集会。

OpenMLDB（Open Source Machine Learning Database）是第四范式自研的开源机器学习数据库。此次被任命的论文由第四范式 AI 基础技术研发团队和新加坡国立大学及 Intel 合作发表，题为《Optimizing In-memory Database Engine For AI-powered On-line Decision Augmentation Using Persistent Memory》。

论文全文链接：http://vldb.org/pvldb/vol14/p799-chen.pdf

论文相关的开源项目：

机器学习数据库 OpenMLDB：https://github.com/4paradigm/openmldb
长期化跳表数据结构 pskiplist：https://github.com/4paradigm/pskiplist
整合了 pskiplist 的长期内存存储引擎：https://github.com/4paradigm/pmemstore

注：论文中的特性工程数据库 FEDB，目前已更名为机器学习数据库 OpenMLDB，并对外开源（https://github.com/4paradigm/OpenMLDB），下文将利用 OpenMLDB 作为描述名称。

人工智能驱动的实时决策系统

随着人工智能的蓬勃发展，越来越多的在线实时决策系统采用 AI 技术帮助决策。典型的应用包罗实时信用卡反欺诈、个性化保举等。一个典型的由 AI 驱动的实时决策系统包含两个子系统：线下训练和在线预估。如图 1 所示，我们把海量的汗青数据放入左侧的线下训练系统中，这套系统会帮我们从汗青数据中提取特性，并训练出超高维的 AI 模子。然后我们把训练好的模子部署到在线预估系统中。在线预估系统需要根据用户的实时行为（好比刷卡生意业务）提取出用户汗青行为信息，并导入 AI 模子进行实时打分，从而进行预测。整个在线预估系统对实时性有很高的要求，一样平常延迟要求为毫秒级。本文紧张关注在线预估系统的数据库存储引擎部门（图 1 中的 OpenMLDB）的性能优化，也是整个在线预估链路中的性能瓶颈。

图 1. 典型的由 AI 驱动的在线实时决策系统架构

特性和特性抽取

图 2. 信用卡反欺诈特性样例

如图 2 所示，我们以信用卡反欺诈应用为例。当刷卡行为产生时，POS 机会产生一条记录。单从这条记录是无法准确判断本次刷卡是一次正常的刷卡还是一次盗刷。在人工智能系统中，除了利用这条新的刷卡记录外，我们还需要根据新记录提取背后隐藏的信息用来做模子训练。所有这些信息一起就是我们的特性，而这个特性抽取的过程就是特性工程。

如图 2 所示，通过 Card ID，我们可以通过查询特性数据库了解这张卡的信息和与之关联的账户信息。还可以通过基于时间窗口的盘算，进一步了解这张卡的最近 10 秒、1 分钟、5 分钟、10 分钟的信用卡消费总额最多的三个店铺等信息。这些特性需要从用户近期的汗青数据中实时抽取。一样平常来说，特性抽取数量越多，模子预测约准确。

特性抽取是一个昂贵的操作。首先特性抽取涉及多个数据库查询操作。以反欺诈为例，一个用户的一次刷卡行为，会触发上千次的数据库查询哀求。与此同时，这些特性中很多的实时特性，好比盘算最近一条刷卡记录和最新刷卡记录的金额差，必须等新的用户刷卡数据产生并传输到后端系统后才能开始抽取，无法进行数据预盘算。与此同时，大部门的实时特性都会涉及在不同维度进行大量的时间窗口查询。这些特性抽取的工作负载特点和传统的 OLTP、OLAP 或 HTAP 负载有很多不同。

我们选取了两种目前最先进的主流商用内存数据库（DB-X 和 DB-Y），利用典型的实时特性抽取负载进行性能测试。如图 3 所示，随着时间窗口数的增加，DB-X 和 DB-Y 的查询延迟显著上升，且当窗口数大于 4 之后，两种数据库的查询性能均已经超过 100 毫秒，完全无法满足我们的性能需求。而且在真实业务场景下，时间窗口数远远大于 4。基于以上结果，需要我们设计一个新的专门针对人工智能特性抽取的数据库引擎。

图 3. 主流商用数据库在实时特性提取负载上的性能表现

针对人工智能负载优化的机器学习数据库

为了能高效的抽取实时特性，我们设计了机器学习数据库。如图 4 所示， OpenMLDB 包罗

图 4. 机器学习数据库 OpenMLDB 架构图

特性抽取执行引擎（FEQL）和存储引擎两部门。FEQL 利用 llvm 对查询语句进行编译优化，并对多窗口类型的查询进行了优化处置惩罚，从而使特性抽取的语句分析执行服从大大增加。FEQL 除了支持雷同 SQL 的语法，还针对特性抽取操作定义了特别的语法。

如图 5 所示，FEQL 允许在同条 SQL 语句中定义多个时间窗口，在语法分析和优化的过程中，FEQL 可以最洪流平的复用不同学口内提取的结果。好比当我们需要提取 10 秒、1 分钟、5 分钟、30 分钟、1 小时、5 小时内用户在各个时间段消费的总额度，我们可以在一个 FEQL 中定义 6 个时间窗口，执行器在运行 FEQL 的时候，可以只取最大窗口（5 小时）的全部数据再分别处置惩罚，而不是重复的提取 5 个窗口的数据，从而大大提升特性提取操作中多窗口 TopN 操作的服从。

图 5. OpenMLDB 进行多窗口特性抽取的例子

在存储引擎部门，如图 6 所示，OpenMLDB 采用了两层的内存跳表数据结构。在第一层跳表中存储了特性的主键，而在第二层中存储了主键对应的各个时间窗口。当我们在查询某个主键下多个时间窗口范围内的数据，只需要先在第一层跳表中定位到对应的主键，再继续在第二层中查询时间窗口即可。

图 6. OpenMLDB 存储引擎的两层跳表结构

图 7. DRAM 版本 OpenMLDB 和主流数据库的性能对比

如图 7 所示，图中 D-FEDB(即 D-OpenMLDB)表示 DRAM 版本的 OpenMLDB。我们在 DRAM 版本 OpenMLDB、商用内存数据库 DB-X 和 DB-Y 上变换时间窗口个数和特性主键数目，并运行典型的特性抽取查询对比性能。如图所示，DRAM 版本的 OpenMLDB 的性能远远高于传统商业数据库，最高可达 84x 的性能提升。

基于长期内存优化的 OpenMLDB

DRAM 内存版本 OpenMLDB 可以很好的满足特性抽取实时性的要求，但在现实的部署过程中，我们仍然发现以下痛点。

1.内存消耗巨大，硬件本钱高

为了保证线上服务性能，OpenMLDB 的索引和数据均存放在内存中。以信用卡反欺诈场景为例，我们的测试数据存储了最近 3 个月的 10 亿条刷卡记录信息用来做特性抽取。这部门数据已经占用了超过 3 TB 的内存空间。当我们考虑多副本的情况，数据规模超过 10 TB 。而当我们需要更多的汗青数据做特性抽取（好比一年甚至三年），其需要的硬件本钱是十分高昂的。

2.恢复时间

OpenMLDB 作为实时在线决策系统数据库，当节点离线时（好比系统故障或者例行维护），OpenMLDB 需要把海量数据从磁盘读入内存，再重构内存数据结构。整个过程需要耗费若干个小时，会严峻影响线上服务质量。

3.长尾延时

传统的内存数据库为了保证数据的划一性，都会周期性的通过日记或者快照把数据从易失性的 DRAM 内存写到低速的磁盘或闪存中。当系统负载高时，这种同步操作很轻易造成一部门上层查询产生超长的延时，我们称之为长尾延时。

我们引入长期内存为解决以上痛点提供新思路。长期内存具有低本钱、大容量、数据长期化的特性。低本钱大容量的内存特性有助于解决 OpenMLDB 高硬件本钱的问题。数据长期化则带来了两个好处：1) 大幅缩短节点离线以后的恢复时间，保障线上服务质量；2) 由于内存数据长期化特性，因此数据库不再需要通过低速磁盘设备做日记和快照的长期化工作，因此可以有效解决长尾延迟的问题。

长期内存有两种工作模式：Memory Mode 和 App Direct Mode。在 Memory Mode 下，长期内存会被当做内存的一部门对用户透明。该模式的好处是用户步伐无需修改即可利用大内存容量，但是无法利用长期化特性以及做精致化的优化。在 App Direct Mode 下，长期内存会以独立块设备的情势被系统感知。步伐员通过英特尔提供的 PMDK 库来编程利用。此种模式下，应用可以享受大容量特性的同时，还可以利用内存数据长期化的特性。

图 8. 利用不同内存模式的 OpenMLDB

如图 8 所示，最左边的版本是原始的基于 DRAM 内存的 OpenMLDB，其查询数据的过程都在 DRAM 内存中完成，但是会通过写入外存（SSD/HDD）上的日记和快照进行长期化。如果利用 Memory Mode（图 8 中间图），则利用大容量的长期内存直接更换 DRAM 内存，但是无法受益于数据长期化特性。因此，如图 8 右图，我们用 App Direct Mode 重构了 OpenMLDB 下层的存储引擎，用 PMDK 实现了基于长期内存的双层链表结构，移除了传统的日记和快照机制。

开辟基于长期内存的存储引擎的紧张挑战是保证数据长期化的正确性和高效性。OpenMLDB 的底层数据结构双层链表运行在多线程情况中，存在大量的多线程并发读写操作，为了更高服从的并发读写，在 DRAM 情况下通常会利用 Compare-and-swap（CAS）技术。CAS 是一种通过硬件实现并发安全的常用技术，底层通过利用 CPU 的 CAS 指令对缓存或总线加锁来实现多处置惩罚器之间的原子操作。但是当我们应用 CAS 到长期内存上时，会带来数据划一性的问题。

图 9. Compare-and-swap (CAS) 操作在长期内存上的划一性问题

如图 9 所示，一个典型的场景是当一条新的信用卡刷卡记录 T1 在 Thread 1 上通过 CAS 插入 OpenMLDB，紧接着别的一个线程 Thread 2 基于新的记录 T1 抽取特性 F1。由于 CAS 和 CPU 的 flush 指令相互独立，传统的基于 DRAM 的 CAS 并没有长期化语义，如果系统按照图 9 的次序长期化 F1 和 T1（即图 9 中的 flush 指令），而在两个 flush 命令中间掉电，重启之后在系统上新的信用卡记录 T1 会丢失，但基于 T1 盘算出的特性 F1 却存在，这在划一性上显然是不正确的。

为了解决长期内存上数据划一性的问题，我们提出了 Persistent-Compare-And-Swap（PCAS）技术。首先我们利用 flush-on-read 的规则解决正确性问题。当每次读取一个内存数据时，我们先进行 flush 以保证读取的数据是长期化过的。但是过多的长期化 flush 操作会带来额外的性能损耗，特别是无须要的一连的 flush 那些本来没有修改过的「干净」数据。为了高效的判断数据是否「干净」，我们利用了一种特殊的指针，称为智能指针。在 x86 下 64 位 CPU 中支持 8 字节 CAS 原子操作的内存地址是必须保证 8 字节对齐的，由于内存访问的基本单元是一个字节，8 字节对齐意味着 CAS 地址的低 3 位始终为 0。如图 10 所示，智能指针巧妙的利用了利用 CAS 时内存地址始终为 0 的低 3 位来标记数据是否为 dirty。有了智能指针，我们只需要在每次修改数据后，对未 flush 的数据的指针标记 dirty 位。然后在后续的读取时，只有当 dirty 位被标记，则执行 flush 指令进行长期化，从而避免了不须要的长期化开销。

图 10. 长期化 CAS（PCAS）和智能指针

如图 11 所示，我们利用 PCAS 技术对长期内存跳表的指针做了优化。为了进一步减少在长期内存上写的量，我们只把跳表最后一层和数据放在长期内存上。为此，我们也设计了一套新的重构流程，以保证在掉电后系统可以根据最后一层跳表信息重构出整个跳表。我们也在实行中会考察不同层级的长期化策略带来的性能影响。

图 11. 基于智能指针的长期化跳表结构

图 12. 实行所用的数据库缩写和系统设置

长期内存优化实行和结论

我们利用一个真实的反欺诈应用数据进行测试，该数据包含了 3 个月的 10 亿条刷卡记录信息，现实部署中大概需要 10 TB 的内存空间。我们对比了 DRAM 版本的 OpenMLDB 以及各种长期内存版本的 OpenMLDB 变种，图 12 给出了测试中各种数据库系统的设置。该实行得出以下结论。

1.长尾延迟 TP-9999 比较（图 13）：基于长期内存进行长期化数据结构设计的 OpenMLDB 舍弃了原有纯内存方案的基于外存储设备的长期化机制，实现了长尾延迟（TP-9999）靠近 20% 的改善。

图 13. OpenMLDB 基于 DRAM 和长期内存的性能比较

2.数据恢复时间比较（图 14）：在服务中断情况下实现数据快速恢复，服务恢复时间减少 99.7%，全面低落对线上服务质量的影响，在测试场景中，其数据恢复时间从原来的六个小时缩短至一分钟左右。

图 14. OpenMLDB 基于 DRAM 和长期内存的恢复时间比较

3.硬件本钱比较（图 15）：我们对比了 10 TB 信用卡反欺诈业务部署在不同集群上的对比，显示了在论文实行中利用的机器设置，在 10 TB 数据的业务场景中，基于长期内存的 OpenMLDB 的硬件本钱仅为基于纯内存版本的 41.6%。

图 15. OpenMLDB 基于 DRAM 和长期内存的硬件本钱比较

总结

本文分析了目前人工智能驱动的实时决策系统面临的挑战以及解决方案，偏重描述了：

总结了 AI 驱动的实时决策系统的架构和负载，我们发现现有的商用内存数据库并不能满足这类应用高实时性的要求。
设计了针对人工智能在线实时决策系统的机器学习数据库 OpenMLDB，在执行引擎和存储引擎上进行了针对性的优化以满足实时决策的性能需求。
为了解决在线预估系统内存消耗大、离线后恢复慢、长尾延迟的痛点，我们基于长期内存重新设计了 OpenMLDB 的存储引擎，并且提出了长期化 CAS (PCAS) 和智能指针的技术。
实行显示，相比较于基于 DRAM 的 OpenMLDB，基于长期内存的 OpenMLDB 可以减少 19.7% 的长尾时延，缩短 99.7% 的恢复时间，与此同时，低落 58.4% 的本钱。

作者: RPA实践者 时间: 2021-8-27 20:10
转发了

作者: 愿机器更好的协作 时间: 2021-8-27 21:30
转发了

作者: wntdssysou 时间: 2021-8-27 23:37
转发了

作者: 可能要北漂的热干面 时间: 2021-8-28 01:42
转发了

作者: 老鳄鱼先生 时间: 2021-8-28 09:10
转发

作者: Long龍少-LoLer 时间: 2021-8-28 10:13
[机智]给力

作者: 权律不二 时间: 2021-8-28 10:55
看这名字咋感觉像骂街呢[捂脸]

作者: King空城旧忆 时间: 2021-8-28 23:38
转发了

欢迎光临创意电子 (https://wxcydz.cc/)