隨著 LLM 技術的發展，向量檢索與向量數據庫也受到業界持續關注，它們能夠為LLM提供外置記憶單元，通過提供與問題及歷史答案相關聯的內容，協助LLM返回更準確的答案。不僅LLM，向量檢索在OLAP引擎中也早已得到應用，旨在提升非結構化數據的分析和檢索能力。

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

ByteHouse向量檢索能力

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

• 既有局限分析

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

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

• 優化整體架構

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

ByteHouse 向量檢索 功能整體架構

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

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

在輿情監測領域，某頭部公司將ByteHouse向量檢索能力應用在“以圖搜圖”場景中。

為了更好提供輿情監測服務，該公司在全網不斷擴大監測范圍，整體數據規模達到12億，期望在 64 核、256GB內存的資源下，達到秒級以下的搜索速度。

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

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

優化一：計算下推優化

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

對此，ByteHouse團隊進行了如下優化。

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

計算下推優化

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

優化二：過濾操作優化

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

• 基于標量主鍵范圍查找

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

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

• 加速標量列剪枝

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

• 存儲層過濾

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

優化三：向量數據冷讀問題優化

• 使用索引需要index結構全載入內存

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

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

• Cache Preload & Auto GC

在構建到內存的過程中，可能存在一些問題，例如：數據庫重啟，或導入新數據時，這些數據仍然是冷的。在OLAP存儲時，使用的是 LSM 存儲格式，進行數據Merge和自動 GC 流程。在數據庫運行過程中的服務啟動、數據寫入等場景中，ByteHouse 可以自動將新的索引加載到內存中，并確保Cache中的過期數據能夠自動回收。

優化四：索引構建資源限制

• 向量數據庫workload特征

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

• 并發限制

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

• 內存優化

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

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

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

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

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

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

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

未來，它還將持續為企業數據分析能力提供支持，助推數智化轉型升級。