採訪 ｜ 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，而且人們迫切需要更簡單的實現方式。而要想實現二者，整合就是關鍵所在。
軟體開發「食物鏈」：運維竟高於開發，最頂端該是用戶還是管理層？
滴滴 P0 事故，K8s 背鍋？拼多多正式登頂中國電商巨頭，馬雲阿里內網罕見發言；學霸女兒創業AI項目火了，老爸公司漲停｜Q資訊
ChatGPT 一周年：生成式 AI 出現後，我決定以後砸鍋賣鐵都不讓後代當程式設計師了
亞馬遜 CTO 20 年架構經驗之道：儉約架構師的七大黃金法則！