生成式 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,而且人们迫切需要更简单的实现方式。而要想实现二者,整合就是关键所在。