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

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

ByteHouse向量檢索能力

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

• 既有局限分析

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

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

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

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

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

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

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

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

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

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

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

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

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

對此，ByteHouse團隊進行了如下優(yōu)化。

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

計算下推優(yōu)化

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

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

在優(yōu)化標量與向量混合查詢場景上，主要圍繞以下三點進行優(yōu)化。

• 基于標量主鍵范圍查找

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

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

• 加速標量列剪枝

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

• 存儲層過濾

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

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

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

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

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

• Cache Preload & Auto GC

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

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

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

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

• 并發(fā)限制

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

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

為了減少資源使用開銷，ByteHouse團隊主要采取了以下措施。

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

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

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

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

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

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

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