ByteHouse高性能向量檢索實(shí)踐——“以圖搜圖”

2024-08-20 16:00:00

作為火山引擎旗下的OLAP引擎，ByteHouse推出了高性能向量檢索能力。本篇聚焦ByteHouse對高性能向量檢索能力的建設(shè)思路，并以“以圖搜圖”為例，詳解OLAP的向量檢索能力如何在具體場景中落地。

隨著 LLM 技術(shù)的發(fā)展，向量檢索與向量數(shù)據(jù)庫也受到業(yè)界持續(xù)關(guān)注，它們能夠?yàn)長LM提供外置記憶單元，通過提供與問題及歷史答案相關(guān)聯(lián)的內(nèi)容，協(xié)助LLM返回更準(zhǔn)確的答案。不僅LLM，向量檢索在OLAP引擎中也早已得到應(yīng)用，旨在提升非結(jié)構(gòu)化數(shù)據(jù)的分析和檢索能力。

ByteHouse向量檢索能力

向量檢索，目標(biāo)是查找與給定向量最相似的k個(gè)結(jié)果，目前廣泛應(yīng)用于以圖搜圖、推薦系統(tǒng)等場景。在實(shí)際使用場景中，向量檢索針對的數(shù)據(jù)集大小通常會在 million 甚至 billion 級別，而查詢延遲通常會要求在數(shù)毫秒到百毫秒內(nèi)返回，通常會使用具有特殊結(jié)構(gòu)的向量檢索索引方式。

既有局限分析

目前比較流行的向量索引算法有 HNSW、Faiss IVF 等，這類基于向量索引的向量檢索負(fù)載，通常具有構(gòu)建時(shí)間長、資源消耗大等特點(diǎn)，且需要考慮如何高效管理索引構(gòu)建任務(wù)所需資源；如何支持內(nèi)存計(jì)算；如何與過濾語句結(jié)合以及資源消耗等一系列問題。

ByteHouse源自ClickHouse，但后者存在向量索引重復(fù)讀取，相似度計(jì)算冗余等問題，對于延遲要求低、并發(fā)需求高的向量檢索場景可用性較弱。

優(yōu)化整體架構(gòu)

基于上述分析，ByteHouse在向量檢索能力上進(jìn)行了全面創(chuàng)新，團(tuán)隊(duì)基于 vector-centric 的思路，重新構(gòu)建了高效的向量檢索執(zhí)行鏈路，結(jié)合索引緩存、存儲層過濾等機(jī)制，使ByteHouse性能實(shí)現(xiàn)進(jìn)一步突破。

ByteHouse 向量檢索功能整體架構(gòu)

下文將具體以“以圖搜圖”這一典型的向量搜索應(yīng)用場景為例，詳細(xì)解讀ByteHouse如何實(shí)現(xiàn)高性能檢索能力的落地與優(yōu)化。

向量檢索能力落地以圖搜圖場景

在輿情監(jiān)測領(lǐng)域，某頭部公司將ByteHouse向量檢索能力應(yīng)用在“以圖搜圖”場景中。

為了更好提供輿情監(jiān)測服務(wù)，該公司在全網(wǎng)不斷擴(kuò)大監(jiān)測范圍，整體數(shù)據(jù)規(guī)模達(dá)到12億，期望在 64 核、256GB內(nèi)存的資源下，達(dá)到秒級以下的搜索速度。

對比行業(yè)其他產(chǎn)品單query latency在幾秒或十秒級別的情況，ByteHouse在優(yōu)化前可達(dá)到700-800 毫秒，經(jīng)過一系列優(yōu)化后，最終可在約 150-200 毫秒的時(shí)間內(nèi)，能夠從大規(guī)模數(shù)據(jù)中查找出近似的 1000 張圖片及其相似度評分。

那么，ByteHouse是如何實(shí)現(xiàn)上述性能的？具體而言，ByteHouse主要在向量檢索計(jì)算下推、過濾操作優(yōu)化、數(shù)據(jù)冷讀問題優(yōu)化幾個(gè)方面采取了優(yōu)化措施。此外，由于資源有限，還進(jìn)行了索引構(gòu)建資源限制。

優(yōu)化一：計(jì)算下推優(yōu)化

在典型的OLAP場景中，數(shù)據(jù)進(jìn)入后，會生成多個(gè)Data Part，按批聚合。按照算子執(zhí)行，對每個(gè)Part進(jìn)行 Vector Search 和 Attributes Read，然后對每個(gè)Part做TopK。這在投影列較多的情況下，產(chǎn)生很大的資源消耗。

對此，ByteHouse團(tuán)隊(duì)進(jìn)行了如下優(yōu)化。

首先，對每個(gè) Part 進(jìn)行 Vector Search，相當(dāng)于將一個(gè)算子拆分成三個(gè)算子，先做Vector Search。
然后，對 Vector Search 的結(jié)果進(jìn)行全局排序，此時(shí)不讀取標(biāo)量信息列。
最后，在全局排序的結(jié)果上，執(zhí)行Read Task，得到最終結(jié)果。

計(jì)算下推優(yōu)化

通常而言，數(shù)據(jù)是分批寫入的，每一批都會有一個(gè)Part，Part一般大于 100。那么，在優(yōu)化后的實(shí)際場景測試中，延遲基本可以做到兩倍以上的速度提升。

優(yōu)化二：過濾操作優(yōu)化

在優(yōu)化標(biāo)量與向量混合查詢場景上，主要圍繞以下三點(diǎn)進(jìn)行優(yōu)化。

基于標(biāo)量主鍵范圍查找

標(biāo)量其實(shí)是一個(gè)排序鍵，類似于 MySQL 中的主鍵。通常，在進(jìn)行搜索時(shí)，會先進(jìn)行標(biāo)量過濾，從而獲取符合查詢條件的數(shù)據(jù)。如果按一般方法計(jì)算，就會有很大的消耗。

由于標(biāo)量本身是有序的，所以可簡單理解為：只需讀取首尾部分?jǐn)?shù)據(jù)，進(jìn)行過濾，構(gòu)建符合條件的row id bitmap。比如在計(jì)算timestamp大于某個(gè)值的情況時(shí)，只需計(jì)算開始和結(jié)束位置所對應(yīng)的行，因?yàn)橹虚g結(jié)果都是符合的。

加速標(biāo)量列剪枝

數(shù)據(jù)剪枝，主要是根據(jù)實(shí)際情況對物理上的鍵排列分區(qū)，包括對主鍵和輔助索引的分區(qū)，以此來加速查詢。

存儲層過濾

在存儲層面進(jìn)行優(yōu)化，將過濾條件下推到存儲中，盡量減少 IO 操作。對類似OLAP和OLTP的數(shù)據(jù)庫而言，查詢動(dòng)作的底層會有很高的計(jì)算開銷。因此ByteHouse針對典型場景，會在底層進(jìn)行更多過濾，以此減少 CPU 和內(nèi)存資源的使用。此外，對于熱數(shù)據(jù)行做了Cache加速。

優(yōu)化三：向量數(shù)據(jù)冷讀問題優(yōu)化

使用索引需要index結(jié)構(gòu)全載入內(nèi)存

向量索引方面，ByteHouse接入了 hnswlib、faiss 兩個(gè)比較流行的檢索算法庫，支持HNSW、IVF_PQ、IVF_PQ_FS等多種常用索引。此外，考慮到向量檢索需要在內(nèi)存中執(zhí)行，還加入了向量索引緩存機(jī)制，確保查詢涉及的Data Part的索引能夠常駐內(nèi)存，以實(shí)現(xiàn)低延遲的向量檢索。

在向量檢索需要較高QPS的情況下，冷讀可能就會成為性能瓶頸。當(dāng)前支持的向量索引需要加載到內(nèi)存中以后，才能進(jìn)行高性能的向量檢索計(jì)算，該層面的優(yōu)化方法主要是將不同資源index結(jié)構(gòu)載入內(nèi)存。

Cache Preload & Auto GC

在構(gòu)建到內(nèi)存的過程中，可能存在一些問題，例如：數(shù)據(jù)庫重啟，或?qū)胄聰?shù)據(jù)時(shí)，這些數(shù)據(jù)仍然是冷的。在OLAP存儲時(shí)，使用的是 LSM 存儲格式，進(jìn)行數(shù)據(jù)Merge和自動(dòng) GC 流程。在數(shù)據(jù)庫運(yùn)行過程中的服務(wù)啟動(dòng)、數(shù)據(jù)寫入等場景中，ByteHouse 可以自動(dòng)將新的索引加載到內(nèi)存中，并確保Cache中的過期數(shù)據(jù)能夠自動(dòng)回收。

優(yōu)化四：索引構(gòu)建資源限制

向量數(shù)據(jù)庫workload特征

向量檢索方面存在普遍關(guān)心的資源問題，使用向量檢索會消耗較多的 CPU 和內(nèi)存資源。為了避免資源開銷過大，ByteHouse團(tuán)隊(duì)在資源使用層面進(jìn)行了限制。

并發(fā)限制

在資源不足的情況下，限制 index 構(gòu)建的線程級別以及后臺的merge任務(wù)。不過，對資源進(jìn)行限制，也會在保證資源使用的同時(shí)解決導(dǎo)致檢索速度變慢的問題。

內(nèi)存優(yōu)化

為了減少資源使用開銷，ByteHouse團(tuán)隊(duì)主要采取了以下措施。

使用 PQ、SQ 壓縮，將向量的存儲空間降低到原來的 1/4 或 1/3。例如，在精度要求不太高的情況下，將 float32 類型的數(shù)據(jù)壓縮為 INT8 類型，從而將 4 字節(jié)的數(shù)據(jù)壓縮為 1 字節(jié)，減少存儲空間。
在訓(xùn)練過程中，需要支持增量訓(xùn)練。對于IVF系列，在構(gòu)建索引時(shí)，不需要常駐內(nèi)存，可以將其落盤。

優(yōu)化后，ByteHouse在資源使用上取得了顯著效果，在類似前述“以圖搜圖”的場景中，以很少的資源就能支撐大規(guī)模數(shù)據(jù)。

不僅僅向量檢索引擎，ByteHouse具備全場景引擎能力

目前，ByteHouse已通過Vector引擎支持多種向量檢索算法以及高效的執(zhí)行鏈路，并且能夠支撐大規(guī)模向量檢索場景，達(dá)到毫秒級的查詢延遲。

在“一元化數(shù)據(jù)、多元化引擎”的理念下，ByteHouse 致力于實(shí)現(xiàn)全場景引擎覆蓋，以確保實(shí)現(xiàn)整體數(shù)據(jù)效能的最大化產(chǎn)出。除了支持向量檢索能力的Vector引擎，ByteHouse還具有全文檢索引擎、GIS引擎在內(nèi)的全場景引擎，為用戶提供一體化數(shù)據(jù)分析服務(wù)。

作為一款以提供高性能、極致分析能力的云數(shù)倉產(chǎn)品，早在2022年2月，ByteHouse在字節(jié)跳動(dòng)的部署規(guī)模就已超1萬8000臺，單集群超2400臺。

未來，它還將持續(xù)為企業(yè)數(shù)據(jù)分析能力提供支持，助推數(shù)智化轉(zhuǎn)型升級。

責(zé)任編輯：龐桂玉來源：字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)

ByteHouse