写点什么

没必要非得固守纯向量数据库!专访亚马逊云科技数据库和迁移副总裁 Jeff Carter

  • 2023-12-07
    北京
  • 本文字数:5351 字

    阅读完需:约 18 分钟

大小:2.64M时长:15:23
没必要非得固守纯向量数据库!专访亚马逊云科技数据库和迁移副总裁Jeff Carter

采访 | Kevin

编辑 |Tina、芳芳

 

生成式 AI 时代的到来催生了向量数据库日益增长的需求和应用。亚马逊云科技也在多种数据库服务上实现向量搜索功能,并且他们也认为这是任何数据库都应当具备的一项核心功能。那亚马逊云科技在数据库产品上有什么样的规划、他们如何看待纯向量数据库需求?针对上述问题,近期在 re:Invent 现场,InfoQ 采访了亚马逊云科技数据库和迁移副总裁 Jeff Carter。

 

Jeff Carter 主要负责亚马逊云科技的关系数据库、非关系数据库和迁移方面的十几种服务。在加入亚马逊云科技之前,任职于 Amazon.com 网站,曾将亚马逊的原有 Oracle 分析环境迁移至亚马逊云科技,并将所有事务处理引擎从遗留技术栈中迁移至亚马逊云科技。Jeff 还担任过几年首席信息安全官,在加入亚马逊之前,曾在 Tera Data 工作过 30 年。

 

以下为访谈实录,经过不改变原意的整理:

 

InfoQ:针对当前技术趋势,亚马逊科技在数据库技术方面的规划是什么样的,包含了什么样的架构和关键产品?

 

Jeff Carter:先从技术框架说起。在框架的最底层,我们拥有一套全面的数据库集合。在操作型数据库方面,我们之前提供 15 种不同服务,但到本周结束时服务数量会增加到 17 种。很多客户都问我为什么要有这么多服务。答案很简单,就是人确保客户在考虑使用亚马逊云科技时,能在商店中找到符合需求的充足数据库选项。

 

所以我们一直在努力推出更多方案。除此之外,客户对于未来两到三年的发展肯定也设有愿景。有些愿景可能需要现有技术,也有一些可能依赖于新的技术。因此我们也会尝试提供能支撑未来需求的新技术。总之,必须密切关注客户的期望,而且这种期望是当下与未来的综合体。如我所说,到本周末我们将拥有 17 种不同的数据库服务,有些是关系数据库、也有些是非关系数据库。

 

以非关系数据库为例,比如我们即将发布的新方案,我称之为操作型数据库。但实际上,它的应用更偏重于分析。还有 Neptune,我们的老牌图数据库。除了 Neptune 之外,我们的图数据库阵容还会进一步扩展。而对于现有数据库,特别是关注操作型用例时,我们也将更多强调分析方面的应用。比方说,图领域中的分析。以社交图谱为例,对社交图谱的操作能显示当前用户有哪些联系人,并列出前十位,如果需要也可以列出几千位。Facebook 就属于操作型案例。但有时候,大家可能希望查询谁在网络上的影响力最大,这往往就需要所谓全表扫描。不过毫无疑问,我们当然不希望把全表扫描当作操作型负载,事务数据库也不擅长执行这类操作。所以分析应该在内存内进行,这样速度会非常快。这是一种持久设计,而且可以基于我们已经在使用的相同技术,比如 DynamoDB 和 MemoryDB,只是分析会在内存内实现。

 

之后是核心层,本周之后我们将拥有 17 种不同的数据库。接下来最重要的就是如何集成数据,因为并不是每个人都想面对这么多不同的资产。所以我们希望在各种资产中建立起重要的共性,也就是零 ETL。作为一项基本目标,现在我们已经围绕它建立起诸多案例,而我们真正关心的就是如何让数据无缝、顺畅地从事务引擎转移至数据仓库或者数据湖。而零 ETL,就是实现这种无缝移动的关键。

 

在我们执行插入、更新、删除等标准数据库操作时,数据其实就开始了流通和变化。数据要么进入 RedShift,要么移动到使用端。接下来是把数据湖治理好。因此,我们最近才公布了 Data Zone 数据区。这样大家就能找到环境中的数据,我们也可以为数据创建权限组。用户可以为权限组指定成员,再把权限组分配给权限集。而且无论大家具体使用什么分析引擎,这些权限都能正确起效。 

 

最后是生成式 AI,这里我要讨论两种生成式 AI 的应用形式。第一,我们要采取哪些措施来改善客户体验?第二,我们要如何帮助客户构建他们自己的应用程序?而改善客户体验的案例,就是我们本周发布的公告之一:Q。在本届 re:Invent 大会之前,亚马逊也有名叫 Q 的产品,就是 QuickSight Q,主要通过自然语言处理建立仪表板和报告。这项功能现在仍然存在,但新的 Amazon Q 属于独立品牌,涵盖亚马逊云科技内部利用生成式 AI 增强客户体验的所有成果。我们这次着力宣传的一个例子就是:我们把所有用户文档同大语言模型相结合,这样用户就能随意用自然语言询问相关问题,Amazon Q 则会根据文档信息给出建议和相应的详尽操作步骤。

 

这样文档的交互性就更好了。不只是在搜索中使用生成式 AI,我们还用 Aurora 在 RDS 领域做过类似的尝试。我们还开发了 DevOps Guru for RDS,借此查看数据库中是否存在性能异常,并提前向客户发出提醒。我们还与负责 GuardDuty 的安全团队合作,随时监控那些指向您数据库的登录行为。

 

一旦它发现异常,就会主动发出提醒。具体可能是有人在反复尝试密码,也可能是来自安全部门已知暗网或恶意 IP 地址的一次登录操作。哪怕只发生一次,它也能牢记在心。这就是我们利用生成式 AI 服务帮助客户的三个简单案例。我们还投入大量资金,希望帮助客户们取得更大的成功,而这方面成果就是 Bedrock。在 Bedrock 之下,我们还推出了 PartyRock 等服务。如果大家还没试过,我强烈建议您马上体验。它非常简单也非常有趣,总的来说这就是一大堆不同大语言模型的集合。我们坚信至少就目前来看,还没有哪种单一模型能够证实世界,必须要借助多种不同的方法和模型,发挥它们各自擅长的专业知识。

 

比如说一种模型可能擅长编辑图片,而另一种模型可能擅长编排音乐,第三种模型则擅长修改文本或者文字润色。它们各有自己的关注取向。因此,我们希望保证客户能轻松找到、并选择最适合自身需求的模型。我们当然支持多种模型,但不同用户对模型有不同的要求,毕竟大家的业务也是独一无二的。你可能需要添加本地数据,这个过程被称为检索增强生成,简称 rag。

 

使用时,大家可以指定共享驱动器,指定要启用的大模型,指定支持 vss 向量相似性搜索的数据库。数据库可以是 Pincone 向量数据库,也可以是 Redis,或者我们支持的七种数据库中的任何一种。我们还在扩展,目前已经有七种不同数据库选项,包括 OpenSearch、RDS Postgres、Aurora Postgres、MemoryDB 等等,未来还会有更多。指定完成之后,点击开始,它就会读取文档,把文档拆分成块,用你选定的大语言模型将其转为向量、创建向量嵌入。之后则把它们放进支持 vss 的数据库,再把大模型和 vss 数据库组合起来,就能回答你提出的问题了。

 

现在我们的模型已经掌握了这些来自数据存储的特定业务知识。在交互过程中,所有的知识都圆融一体,可供你随时选择并交付给客户。现在我们就能把大语言模型跟向量存储这套组合一并交给客户了。如果愿意,也可以只提供给内部员工。总之,大家可以随意挑选用户,指定他们能跟文档中的哪些部分进行交互。文档可以是任何形式,比如说网页或者 PDF 等等。总之我们提交一个文档,把它转换成向量。之后大模型就能识别这些数据,避免手动对程序进行处理。单靠 Bedrock 就能实现全面自动化。

 

当然,本届 re:Invent 大会上还有很多其他案例。总之我们团队一直在与 Bedrock 团队密切合作,共同实现向量搜索功能,我们也认为这是任何数据库都应当具备的一项核心功能。

 

InfoQ:我们要怎么判断哪种数据库最具性价比呢?

 

Jeff Carter:我们可以在模型中设定多种参数,比如说召回率。整个所谓向量相似性搜索的过程,就是先提取数据、再立足多个维度创建数字,也就是说每个文档可能拥有 20、30 或者 40 个不同的维度。然后在这 40 个维度上,vss 的作用就是在不同的维度间寻找最近邻。这就是我们想要向核心数据库中添加的功能,即快速执行 vss 查找的能力。这就是召回率,它是个介于 0 和 1 之间的数字。召回率越高,得出的答案质量越好,但也会消耗更多算力。你可以选择 90%的召回率,也可以选择 99%的召回率。根据选择召回率的不同,各种数据库的性价比也有差异。

 

我觉得对于大多数用例,Aurora Postgres 都表现出色,另外 OpenSearch 也很不错。但如果想要极高的召回率,那么作为最佳配伍,我觉得 MemoryDB 的性能表现最为极致。因为它会把所有数据都存放在内存内,而不必多次访问磁盘。

 

InfoQ:亚马逊云科技今天公布了好几项关于零 ETL 的产品。我很好奇,这是不是代表随着越来越多的零 ETL 产品面世,不久的未来 ETL 就会彻底消失了?你怎么看这个问题?

 

Jeff Carter:根据个人经验,我还是更关注消费者的感受这部分。ETL 其实分为两层,其一就是从事务引擎中获取基础数据并放入数据环境,而零 ETL 其实实现的就是对这一层的自动化。而对基础数据进行业务层级转换以建立更高级别的业务组,即 T 的部分,则仍然要用到 Glue 或者第三方工具才能建立起更高级别的业务领域。从 Amazon.com 的角度来看,前一个级别的实例就是配送中心库存。核对我们配送中心里的每种产品还有多少库存,再把这些数据转移到数据湖中,这就是零 ETL 起效的部分。但要想把所有配送中心都整合起来,把全局数据显示在网站上,那就需要更多的 T 层,要用到 Glue 之类的工具。

 

ETL 通常是向数据仓库和数据湖读取和写入数据,但如果愿意,也可以使用 Glue 访问不同的数据库以获取信息。在亚马逊云科技中,当我们谈到数据仓库时,通常是指 RedShift。而 Glue 能跟 RedShift 无缝对接。至于说数据湖,我们主要是指 Lake Formation,还有 EMR 和 Athena 等其他几种项目。Redshift 是一种作为数据仓库的并行列式数据库。

 

那么未来,是不是人们会更多把数据传送到数据湖中?而不再大量使用列式数据库那样的数据仓库?我觉得这两种情况都会存在,具体取决于查询的大小、类型还有表的类型,不同的场景对应不同的方法。但我觉得从长远来看,我们目前正在研发、但还没有公布的很多技术应该能发挥创造性的作用,真正把这两种环境联系在一起。

 

InfoQ:大家都知道,向量数据库领域的竞争非常激烈。在来这里之前,我跟中国技术社区的人们进行过很多交流,包括跟向量数据库相关的线上讨论。有些专家认为,搭配大语言模型的长期记忆组件不应该是单纯的向量数据库。所以作为亚马逊云科技的数据库和迁移服务负责人,你如何看待向量数据库的发展方向?未来几年又可能出现哪些潜在的挑战和机遇?

 

Jeff Carter:首先,我们希望通过亚马逊云科技为客户提供更多选择。我之前用两家公司举了例子,当然还有很多其他案例。首先就是 Pincone,他们作为纯向量数据库的代表。另外 Redis Labs 也有能支持 vss 的版本。只要客户愿意,我们非常乐意支持这些产品以供免费使用。

 

他们对这些方案肯定都有自己的判断,而我们很高兴能支持他们的实际选择。但我一直觉得,没必要非得固守纯粹的向量数据库。正因为如此,我们才取其核心技术并融入其他方案,努力在不同技术之间做出权衡。这样客户就能做出最符合业务需求的明智选择。

 

现在形势一直在快速变化,当下我们给出的答案未来都可能变成错误答案,比如 6 个月之后情况可能会大为不同。甚至未来 3 个月都可能出现变化。我相信所有企业都希望能用自己的业务信息来扩展基础模型。相信也会有企业愿意花几个月时间自行训练吧,只是成本会高得多。

 

我觉得微调和检索增强生成(rag)的边界比较模糊,二者的适用范围也有交集。总之虽然大语言模型的表现令人惊叹,但还远称不上完美。

 

InfoQ:我们都知道数据库技术已经诞生半个世纪了,在这样的老古董上搞创新也变得越来越艰难。那亚马逊云科技是如何在数据库技术领域不断创新的?近年来,您认为亚马逊在数据库领域取得的最重大、最显著的技术进步是什么?

 

Jeff Carter:这是个好问题。首先,我们每年都会对所有产品进行创新,并投入大量时间跟客户和社区成员进行交流,了解客户在使用现有产品时遇到过哪些问题,并尝试做出改进。

 

但也有很多比较长远的问题,例如如何适应未来几年可能出现的趋势、提前做好准备。我们目前开发的项目可能要到一年、两年或者三年之后发布,当然希望它们在亮相时仍然具有变革性。请原谅我无法透露目前的工作内容,但我想强调的是,我们会同时考虑短期和长期问题,考虑怎么把事情做好。就以生成式 AI 为例,我们已经意识到这是一项变革性的技术,而这样的技术可能每十年都会出现一次。我们内部已经在努力转向,讨论之前的哪些成果能与之对接,并且公开表态将积极向着这条路线推进。我们会始终保持旺盛的创新动力,并真正把心力投入到有希望的特定领域当中。

 

所以像 Bedrock、Titan 还有 PartyRock,这些都是我们能在相对较短的时间里拿出的现实成果。我们是一家专注于机器学习和 AI 的公司,我随随便便就能举出十几个在消费级业务领域应用机器学习的例子,比如利用机器学习改造搜索功能,借此在所有配送中心内建立起智能化的补货系统。这样的案例可以说数不胜数。

 

现在,我们又把目光投向了生成式 AI,希望大家都能感受到我们严肃的态度。至于生成式 AI 方面的用例,我觉得不同的人可能会有不同的看法。生成式 AI 最神奇的能力就在于处理自然语言。是的,就像前面提到,它能阅读文档,再根据读取过的内容正确回答问题,相当于将语言承载的完整历史都纳入了模型自身。这真的太酷了。我相信肯定会有很多有趣的应用出现。

 

InfoQ:2023 年即将过去,如果用 3 个关键词来描述这一年来的数据库领域,你会选择哪 3 个?

 

Jeff Carter:第一个词很简单,降本。第二个是生成式 AI。第三个是集成或者说整合。过去 18 个月以来,人们一直在努力寻求能够降本增效的方法,亚马逊云科技只是其中之一。这也代表着这段时间以来的一大趋势。每一次交流,对方都会强调降本和 AI,而且人们迫切需要更简单的实现方式。而要想实现二者,整合就是关键所在。

 

2023-12-07 09:596603

评论

发布
暂无评论
发现更多内容

【Spring注解驱动开发】未来教育二级java激活码,Java基础项目实战

Java 程序员 后端

【大牛疯狂教学】,java教程网站免费,成功入职腾讯月薪45K

Java 程序员 后端

【大牛系列教学】,数据库系统原理及mysql应用教程第二版,面试心得体会

Java 程序员 后端

Spring是怎样巧用三级缓存解决循环依赖的,nginx实战百度网盘,面试必问!

Java 程序员 后端

【工作经验分享】kafka视频教程下载,Java开发者跳槽面试

Java 程序员 后端

【面试必会】极客时间吾爱破解,和腾讯大牛的技术面谈

Java 程序员 后端

【面试总结】尚硅谷2021百度云,Java技术基础知识总结

Java 程序员 后端

一个Java程序员的腾讯面试心得,这次被它搞惨了

Java 程序员 后端

tomcat服务器面试题,java项目开发实训教程,Java编程教程视频下载

Java 程序员 后端

一名毕业三年的女程序媛面试头条经验,Java项目视频百度

Java 程序员 后端

一招教你看懂Netty!硅谷一至五季百度网盘,springmvc源码分析图

Java 程序员 后端

一文了解OOM及解决方案,尚硅谷java课程表,Java编程入门教材

Java 程序员 后端

spring教程,java大学实用教程第四版作业题,中高级Java开发面试题

Java 程序员 后端

一年后斩获腾讯T3,headfirstjavapdf百度云,带你碾压面试官!

Java 程序员 后端

【干货,马士兵的java教程,这个JVM虚拟机内存模型你必须知道

Java 程序员 后端

“金三银四”春招指南!linux高级编程教程,和阿里大佬的技术面谈

Java 程序员 后端

【Spring注解驱动开发】java基础全套视频教程,被逼无奈开始狂啃底层技术

Java 程序员 后端

【金九银十】,java程序设计精编教程第三版,Redis有几种数据类型

Java 程序员 后端

一个三非渣本的Java校招秋招之路,mysql使用教程,Java程序员全套

Java 程序员 后端

一年后斩获腾讯T3,一次违反常规的Java大厂面试经历

Java 程序员 后端

spring教程下载,linux入门基础教程,2021Java者未来的出路在哪里

Java 程序员 后端

tomcat面试题汇总,java设计模式菜鸟教程,linux内核教程

Java 程序员 后端

一个月成功收割腾讯、阿里、字节offer,springmvc面试题常问2020

Java 程序员 后端

spring教程,java程序设计基础教程,OMG

Java 程序员 后端

spring源码视频教程,java尚学堂,Java项目视频

Java 程序员 后端

【工作感悟】牛客java面试宝典pdf,助你面试一臂之力

Java 程序员 后端

【微信小程序】,java程序开发范例宝典百度云,Java零基础自学书籍

Java 程序员 后端

spring教程,spring框架菜鸟教程,Java重点知识点

Java 程序员 后端

【一篇文章搞懂】,java程序设计案例教程许敏,费时6个月成功入职阿里

Java 程序员 后端

一个三非渣本的Java校招秋招之路,2021高级Java笔试总结

Java 程序员 后端

tomcat面试题,传智播客java就业班视频教程,Spring的XML解析原理

Java 程序员 后端

没必要非得固守纯向量数据库!专访亚马逊云科技数据库和迁移副总裁Jeff Carter_数据湖仓_Tina_InfoQ精选文章