关于人工智能:国内AI领域首次第四范式OpenMLDB优化创新论文被国际数据库顶会VLDB录用

0次阅读

共计 6122 个字符,预计需要花费 16 分钟才能阅读完成。

第四范式 OpenMLDB 优化翻新论文被国内数据库顶会 VLDB 录用,为国内 AI 畛域首次

第四范式与新加坡国立大学及英特尔的最新联结研究成果——基于长久内存优化的 AI 实时决策零碎数据库 OpenMLDB(Open Source Machine Learning Database)被国内数据库顶级会议 VLDB 2021 录用。

VLDB (Very Large Data Base) 是数据库钻研人员、厂商、利用开发者,以及用户宽泛参加的年度国内会议,它与 SIGMOD、ICDE 被公认为数据管理与数据库畛域的三大国内顶尖学术会议。

这是国内 AI 厂商第一次在 VLDB Research Track 上发表机器学习数据库方面的翻新论文。OpenMLDB(Open Source Machine Learning Database)是第四范式自研的开源机器学习数据库,也是国内首个开源机器学习数据库。此次被录用的论文由第四范式 AI 根底技术研发团队和新加坡国立大学及 Intel 单干发表,题为 ” Optimizing In-memory Database Engine For AI-powered On-line Decision Augmentation Using Persistent Memory “。

注:论文中的特色工程数据库 FEDB,目前已更名为机器学习数据库 OpenMLDB,并对外开源(https://github.com/4paradigm/…),下文将应用 OpenMLDB 作为形容名称。

本周,VLDB 2021 正在漂亮的小美人鱼之乡 – 丹麦,热火朝天的举办之中。明天小编就带你深度解析该论文,并介绍基于长久内存优化的 AI 实时决策零碎数据库引擎 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 和长久内存的性能比拟

  1. 数据恢复工夫比拟(图 14):在服务中断状况下实现数据疾速复原,服务复原工夫缩小 99.7%,全面升高对线上服务质量的影响,在测试场景中,其数据恢复工夫从原来的六个小时缩短至一分钟左右。

    图 14. OpenMLDB 基于 DRAM 和长久内存的复原工夫比拟
  2. 硬件老本比拟(图 15):咱们比照了 10 TB 信用卡反欺诈业务部署在不同集群上的比照,显示了在论文试验中应用的机器配置,在 10 TB 数据的业务场景中,基于长久内存的 OpenMLDB 的硬件老本仅为基于纯内存版本的 41.6%。

    图 15. OpenMLDB 基于 DRAM 和长久内存的硬件老本比拟
    总结
    本文剖析了目前人工智能驱动的实时决策零碎面临的挑战以及解决方案,着重形容了:
  3. 总结了 AI 驱动的实时决策零碎的架构和负载,咱们发现现有的商用内存数据库并不能满足这类利用高实时性的要求。
  4. 设计了针对人工智能在线实时决策零碎的机器学习数据库 OpenMLDB,在执行引擎和存储引擎上进行了针对性的优化以满足实时决策的性能需求。
  5. 为了解决在线预估零碎内存耗费大、离线后复原慢、长尾提早的痛点,咱们基于长久内存从新设计了 OpenMLDB 的存储引擎,并且提出了长久化 CAS (PCAS) 和智能指针的技术。
  6. 试验显示,相比拟于基于 DRAM 的 OpenMLDB,基于长久内存的 OpenMLDB 能够缩小 19.7% 的长尾时延,缩短 99.7% 的复原工夫,与此同时,升高 58.4% 的老本。
    理解更多
     论文全文链接:http://vldb.org/pvldb/vol14/p…
     论文演讲视频:https://www.zhihu.com/zvideo/…
     论文相干的开源我的项目:
  7. 机器学习数据库 OpenMLDB:https://github.com/4paradigm/…
  8. 长久化跳表数据结构 pskiplist:https://github.com/4paradigm/…
  9. 整合了 pskiplist 的长久内存存储引擎:https://github.com/4paradigm/…
     该论文我的项目是由专一于现代化存储架构技术的第四范式 MemArk 技术社区主导:https://memark.io/
     第四范式开发者社区的更多开源我的项目
  10. 基于长久内存优化的音讯队列零碎 Pafka:https://github.com/4paradigm/…
  11. 无缝反对云上虚拟化显存的计划:https://github.com/4paradigm/…
正文完
 0