更多技術交流、求職機會，歡迎關注位元組跳動資料平臺微信公眾號，回覆【1】進入官方交流群
隨著 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臺。未來，它還將持續為企業資料分析能力提供支援，助推數智化轉型升級。
點選跳轉 火山引擎ByteHouse 瞭解更多