如何用存储黑科技解决推荐系统的 “信息过载”?

文章来源:大数据文摘

  • 从大数据时代带来的数据量暴增、数据类型不断增多,以及数据处理并发度和速度不断提升这三个现状来看,要想破解推荐系统的信息过载难题,就得从内存上下功夫。

  • 但传统内存已难担重任,符合条件的新型内存不仅容量要大、性能要高,还要具备数据持久性,来保障推荐系统或搜索引擎的存储系统在断电后的数据和服务恢复能力。

  • 英特尔® 推出的傲腾™ 持久内存融合了内存和存储的优势,可满足上述要求。百度借助它改造了 Feed 流服务的核心内存数据库,在可接受的性能波动内实现了更优的 TCO,还用它打造了高效、低时延、低成本和易扩展的全新用户态单机存储引擎。

BUILT IN - ARTICLE INTRO SECOND COMPONENT

我们的数据集群目前规模过万,总数据量以 EB 计,日新增数据量则以 PB 计……

这些数字来自某移动互联网企业在一次技术交流活动上对自家数据处理能力的介绍。先不说 EB,就说说 1PB 是什么概念吧?大约是 2 亿张照片或 2 亿首 MP3 音乐,如果一个人不停地听这些音乐,能听上 1900 年。

大家可能会惊叹于这家企业强大的数据处理能力,但并非所有企业都具备同样的能力——激增的数据量如果超过了数据处理能力,就会导致 “信息过载” 问题,为此,人类发明了能够过滤信息的 “搜索引擎” 和 “推荐系统”,用以高效识别和应用那部分 “至关重要” 的数据。

然而,据国际数据公司 IDC 在报告《数据时代 2025》 中的预测,到 2025 年,属于数据分析的全球数据总量将增长至原来的 50 倍,达到 5.2ZB;认知系统 “触及” 的分析数据总量也将随之增长至原来的 100 倍,达到 1.4ZB!这意味着用来挑选、过滤数据的推荐系统和搜索引擎,也一样难逃 “信息过载”。

推荐系统本质上就是一个信息过滤系统,通常分为:召回、排序、重排序这三个环节,每个环节逐层过滤,最终从海量数据中筛选出几十个用户可能感兴趣的信息推荐给用户。更直接一些,要想实现推荐系统这三个关键环节,就需要四个模块化的层面,即数据、存储(内存&存储)、服务和应用

其中,存储层用于存储数据层的数据;服务层是对外提供接口的部分;应用层根据不同场景配置的召回策略来直接对接服务层,发起请求得到推荐反馈。显然,数据、存储是推荐系统的底层逻辑,能够决定引擎 “走多远”,而服务层和应用层则是上层建筑,对用户体验起到重要作用。

图注:推荐引擎的模块化层面架构图

因此,要想从根本上解决推荐系统的信息过载问题,就要从数据及存储层着手。


推荐、搜索背后的挑战:数据硬件瓶颈

从文字发明前,人类就一直在为 “合适” 的数据寻找 “合适” 的数据存储方式,例如书写工具作为一种原始存储技术,其让人类有了记录生活的能力;1890 年代,穿孔卡的出现为人类打开了另一个全新时代的大门,标志着现代信息程序化的初露锋芒。

穿孔卡所能处理的数据当然不能一劳永逸地满足人类经济生活的需求,1966 年,动态随机存取内存 (DRAM) 出现,开创性地用电容来存储信息,而所谓的 “动态” 并非是指内部的某个功能,而是指电容终究会丧失电荷,因此必须定期 “动态” 刷新。这意味着 DRAM 一旦断电就将面临数据丢失的风险。

内存专注于 “数据存储”,结合 “数据处理” 才能构成数据价值的闭环。1971 年英特尔® 推出全球首款 CPU 的创举则画全了这个闭环。此后,数据处理的硬件发明一直都在沿着内存与 CPU 并存的格局发展。

而今,从大数据时代带来数据量暴增,数据类型不断增多,数据处理并发度和速度不断提升这三个现状考虑,是时候对数据处理和存储的硬件技术来次大换代了。其实,将这三个特征纳入推荐系统,就不难发现,在内存上下功夫,会更有助于破解推荐系统的信息过载难题。

让我们来划一下重点吧:数据规模、高并发、实时推荐等这几点,就是所有基于大数据做推荐服务或产品的企业都会遇到的共同问题:

1.    数据量指数增长问题:越是精准,越是个性化的推荐,就越需要为每个用户都保存一份推荐数据,也就是说数据量会随着用户线性增长。

2.    数据稀疏性问题 :现在待处理的推荐系统规模越来越大,用户和信息 (譬如音乐、网页、文献……) 数目动辄百千万计,两个用户在选择上的重叠非常少。

3.    需要快速及时响应用户请求(运算):随着新闻、短视频等消费用户碎片化时间的应用层出不穷,推荐系统更倚重实时推荐策略。

就如前文所说,要解决这些问题,就要从 “数据” 和 “存储” 这两个底层逻辑找答案。

第一个问题的解决,需要大容量存储设备;第二个问题需要 “借力” 算法,例如通过扩散的算法,从原来的一阶关联到二阶甚至更高阶的关联,甚至通过迭代寻优的方法,考虑全局信息导致的关联,其中 “全局” 一词背后需要高性能处理器的助力;而应对第三个问题则需要更高性能的存储来支持,例如用户在使用 APP 时,留给推荐系统的处理时长往往是毫秒级的,这就对推荐系统的存储部分的吞吐量、响应速度、稳定性和意外中断后的恢复能力提出了更高的要求。

从上面这个三个方案不难看出,存储既要更大容量,也需要更优性能,换言之推荐系统的 IT 基础架构既要满足对海量数据存储的承载能力,还需要在大数据量下保证计算分析的时效性。换句话说,上面这三个问题环环相扣,必须要找到一个 “三管齐下” 的解决方案。


“数据硬件” 新趋势:颠覆内存与存储的边界

三管齐下说来容易,但又该如何实现呢?其实,只要一步活,就可以步步活。

这一步就是要把更多数据 “存放” 在更接近 CPU 的位置进行处理。

传统上业界存放数据的主流产品包括 DRAM,基于 NAND 技术的固态盘 (SSD) 以及传统机械硬盘 (HDD)。这些技术各有优缺点,例如 DRAM 虽然性能好、时延低,但容量受限、价格昂贵且有数据易失性;与 DRAM 相比,固态盘 (SSD) 可提供更大容量和更低成本,但无法提供相同的性能水平;传统硬盘 (HDD) 就更别提了,胜在容量和成本更优,但有旋转的盘片,很难避免与可靠性、物理空间要求、散热等因素有关的总体拥有成本问题。

总结一下,上述这些产品的不足,概括起来就是:离 CPU 近的,性能虽好但很难满足承载大体量数据和数据持久性的需求,而距离远的产品容量虽大,即在性能上与 DRAM 差距较大。

图注:传统内存-存储架构在性能和容量上都存在缺口

如何解决?当前业界有一个解决方案是开辟全新的产品技术路线:打破内存和存储的特性,将两者的优势融合起来。

这一技术路线的提出者和重要实践者,就是大家熟悉的英特尔®,而它将内存和存储特性融合的产品,名为英特尔® 傲腾™ 持久内存(Optane Persistent Memory, 简称 Optane PMem)。这种产品采用的傲腾™ 存储介质正是实现这种融合的基石,已被很多专家和用户视为存储 “黑科技”。

采用了这种存储 “黑科技” 的傲腾™ 持久内存,一句话就可以概括其特点,那就是拥有接近 DRAM,远超 NAND SSD 的性能,容量又比 DRAM 大(单条容量可达 128GiB,256GiB 和 512GiB),价格或单位容量的成本更实惠,且具备数据非易失能力(断电后数据不会丢失)。

图注:增添了傲腾™ 持久内存和傲腾™ 固态盘的全新内存-存储架构

对内存和存储优势的融合让傲腾™ 持久内存得以提供两种工作模式:

一是 App Direct 模式,让应用能通过 load/store 字节访问方式直接访问持久内存,保存到持久内存的数据断电后不丢失。访问持久内存的时延和 DRAM 接近。

二是内存模式,傲腾™ 持久内存在这种模式下可用作 DRAM 之外进行容量扩展的易失性内存。

图注:傲腾™ 持久内存的两种工作模式

说到这里,结果已经要呼之欲出了:在 App Direct 模式下工作的傲腾™ 持久内存正是我们寻求的、能兼顾推荐系统两个底层逻辑——数据和存储的答案,它既能把更多数据放在靠近 CPU 的位置,同时又能满足推荐系统高速数据处理过程中的性能和可靠性要求。


打通内存与存储,让数据从负担变为 “富矿”

目前,已有数家在推荐技术上处于行业领先地位的企业认识到,并开始借重傲腾™ 持久内存的上述优势,百度就是尝鲜者之一。

人们对于百度的传统观感就是搜索引擎服务,其实百度的搜索引擎早就利用公司在大数据和 AI 方面的技术优势和积累,增添了基于信息聚合,能向用户投送个性化内容的 Feed 流服务。在这项服务背后担纲数据层和存储层关键角色的,就是它的核心内存数据库 Feed-Cube。

由于业务飞速拓展,百度 Feed 流服务需要 Feed-Cube 部署更大容量的内存来承载规模激增的数据,可 DRAM 高昂的成本和有限的容量规格使得内存扩展带来的 TCO 压力不断抬升,在这种情况下,百度在初代英特尔® 傲腾™ 持久内存(100 系列)刚刚发布不久,就盯上了它。

于是 2019 年时,百度就围绕如何在 Feed-Cube 上利用傲腾™ 持久内存的优势开展了一系列尝试。它先后对比测试了仅使用 DRAM,DRAM+ 持久内存和仅使用持久内存支持 Feed-Cube 的状况。结果表明,在第二代至强® 可扩展处理器与傲腾™ 持久内存组合上,如果使用 DRAM 和持久内存的混合配置,Feed-Cube 在 2,000 万大并发访问压力下的平均访问耗时仅上升约 30 微秒 (约 24%),CPU 的整机消耗占比上升 7%,性能波动完全可接受,由于换来的单服务器上的 DRAM 使用量可以减半,从成本角度而言则是个大好消息。

百度还发现,即使只基于傲腾™ 持久内存来构建 Feed-Cube,在每秒 50 万次查询(QPS)的访问压力下,其平均时延与只配置 DRAM 的方案对比上升约 9.66%,性能波动也可接受。

图注:百度 Feed-Cube 内存配置的变化路径,和不同路径或配置下的处理时延对比

对傲腾™ 存储 “黑科技” 优势的初步认可,让百度开始了在更多关键应用场景中发掘其应用价值的探索之路。包括在关键业务中考查其持久性对数据恢复的加速,还有优化 BigSQL 数据处理平台(基于 SPARK SQL)的交互式查询性能和成本等。

这些成功的尝试,最终促使百度决定基于傲腾™ 持久内存,从存储引擎层面开启了更大的创新或者说是改造,即推出使用持久内存和 PMDK(英特尔® 开源的持久内存开发工具包)优化的新一代用户态单机存储引擎,为百度离线与部分在线业务提供高效稳定、低时延、低成本和易扩展的存储服务。

该引擎可用于块、文件和对象存储等多种应用场景,将傲腾™ 持久内存(APP Direct 模式)用作引擎缓存层的存储介质,来存储元数据、缓存和索引。并通过 PMDK 进行内存调度,加速这些数据的读写,最大程度减少资源损耗。

图注:SNIA 编程模型和 PMDK 工作示意图。傲腾™ 持久内存遵循 SNIA 编程模型, PMDK 可帮助应用直接访问持久内存设备,而不需要经过文件系统的页高速缓存系统、系统调用和驱动,避免了数据 IO 产出的开销,可大大降低数据时延。

经测试,这个全新的存储引擎写入一个4K数据的整体时间消耗大约为 4.5 微秒,而将其中的持久内存换成 DRAM,全程用时大约是 3 微秒,在时延上相差不大。但使用 DRAM 和使用持久内存的成本却相差很大,相同的成本投入下,持久内存的空间是 DRAM 的三倍之多,这意味着可以缓存更多数据,也能以更合理的方式进行数据存盘,有效提高后端存储设备的 IO 效率。

百度将傲腾™ 持久内存导入包括 Feed 流服务在内各种产品和服务进行尝试,以及采用它开发新一代用户态单机存储引擎的意义,并不在于它使用这种存储 “黑科技” 解决了自身的业务需求,更多的,是为傲腾™ 持久内存在搜索、推荐系统和更多大数据场景中的应用进行了重要的探索,能为遇到或即将面临同样信息过载问题的企业和用户提供值得借鉴的宝贵经验。

或许很快,就会有更多倚重搜索、推荐技术或服务的企业导入傲腾™ 持久内存,尤其是英特尔® 在今年四月刚刚发布了与傲腾™ 持久内存搭配的全新算力干将——面向单路和双路服务器的第三代至强® 可扩展处理器。它在内存通道的支持上从上一代产品的 6 通道升级到了 8 通道,速度也从上一代的 2666MT/s 提升到了高达 3200MT/s,在与 DRAM 和傲腾™ 持久内存 200 系列配合使用时,每路内存容量可达 6TB 之多。这款全新处理器还支持了 PCI-E 4.0 技术,并新添了支持 PCI-E 4.0 的傲腾™ 固态盘 P5800X(也是基于傲腾™ 存储介质构建),这表明傲腾™ 固态盘与傲腾™ 持久内存的数据交互也将进一步提速。

图注:存储 “黑科技” 两款新品——傲腾™ 持久内存 200 系列和傲腾™ 固态盘 P5800X

由此不难看出,英特尔® 对这项存储 “黑科技” 的改进、优化、升级和普及的步伐一直在持续,也许还会越来越快,现在已有消息称,下一代傲腾™ 持久内存单条容量就会达到 1TB……这样一来,也许大家担心存储系统 “信息过载” 的日子,离我们就越来越远了。