一、實時 OLAP 的興起

1. 數(shù)據(jù)價值隨時間的變化

如上圖所示，可以看出，對于單個事件來說，數(shù)據(jù)價值會隨著時間逐漸降低，比如，用戶對小紅書上某個帖子或淘寶上的產(chǎn)品發(fā)生了點擊行為，之后就會有相關的產(chǎn)品或廣告的推薦，以及進行步更多的鏈接、視頻等各式各類的推薦，推薦的效果在點擊發(fā)生當時最有用，之后效果會遞減。同時，由于有很多人有類似的數(shù)據(jù)，我們可以在這些數(shù)據(jù)上做一些聚合分析，這類聚合分析的價值會隨著時間和數(shù)據(jù)量的增加而增加。之前我們會把大部分的時間和精力都聚焦在這類批式的后處理的分析上，而對實時數(shù)據(jù)分析的關注較少。

隨著實時機器學習以及數(shù)據(jù)分析應用的發(fā)展，實時數(shù)據(jù)的價值越來越多地被挖掘出來。

過去，數(shù)據(jù)分析更多是面向公司內部的分析，比如運營數(shù)據(jù)分析等；未來，數(shù)據(jù)分析將更多用來服務最終用戶。比如，推薦算法，本身就是用戶自己的數(shù)據(jù)來訓練模型，通過把用戶的數(shù)據(jù)變?yōu)楫a(chǎn)品又給用戶使用，完成整個數(shù)據(jù)的生命周期，并且能給用戶更好的體驗。

2. 實時數(shù)據(jù)分析邊界拓展

實時數(shù)據(jù)分析的邊界也在不停地拓展。比如：

• 在應用上，由面向內部的數(shù)據(jù)分析變成面向用戶、面向對象的數(shù)據(jù)分析；
• 在數(shù)據(jù)的結構上，從結構化數(shù)據(jù)（如 SQL 表，定義好行列的數(shù)據(jù)類型）變成半結構化數(shù)據(jù)或非結構化的數(shù)據(jù)（如文本數(shù)據(jù)、Json 數(shù)據(jù)），甚至對于音頻、視頻的數(shù)據(jù)，可以把它們做成 embedding，存入數(shù)據(jù)庫以進行更多的分析和查找；
• 在數(shù)據(jù)準確性上，對查詢的準確一致性支持也更強；
• 在分析的復雜度上，原來只能做一些特點維度或切片的分析，未來可以支持復雜的 Full-SQL 語義的實時分析；
• 在數(shù)據(jù)量級上，從 TB 級增加到 PB 級；
• 在使用場景上，從特定的應用場景，到用戶可探索的場景，包括機器學習和 AI 相關的各類應用場景。

3. 典型的數(shù)據(jù)分析技術棧

上圖是一個典型的數(shù)據(jù)分析技術棧。左邊是數(shù)據(jù)的生成端，在各種設備上，生成各種原始數(shù)據(jù)；中間是基于用戶或產(chǎn)品特性的數(shù)據(jù)，比如，電商的訂單數(shù)據(jù)，廣告的事件數(shù)據(jù)，這些數(shù)據(jù)存到 OLTP，如 MySQL 數(shù)據(jù)庫中，或 Kafka 的消息隊列；接下來，OLAP 分析端，離線分析端一般會將 ETL 來的數(shù)據(jù)，存入數(shù)倉或數(shù)據(jù)湖里，實時分析端一般從 Kafka 直接消費進入實時數(shù)據(jù)庫中。這里的目標是低數(shù)據(jù)查詢延時、高數(shù)據(jù)查詢精度，并支持更大的查詢量。

二、Apache Pinot 體系結構

1. Apache Pinot 簡介

Apache Pinot 是一個支持高可用、高并發(fā)、低延時的快速實時分布式 OLAP。為了方便處理互聯(lián)網(wǎng)上的用戶數(shù)據(jù)，Apache Pinot 是采用列式存儲的 OLAP，并且可以與 Kafka 集成起來，進行實時數(shù)據(jù)處理。

Apache Pinot 已在一些大公司里被使用。在 LinkedIn 支持每秒上百萬事件，20 萬 QPS 的毫秒級查詢；在 stripe 上，支持單表 1 千億行，數(shù)據(jù)量超 PB，2 萬 QPS，25 毫秒查詢延時；Uber 也是對實時性要求很高的應用，用 Pinot 來實現(xiàn)地理信息的查詢。

Pinot 是 Apache 基金會的項目，所有內容都完全開源，很多公司都在使用，如上圖所示。大家如果有興趣，也歡迎試用，并在社區(qū)中交流。

2. Apache Pinot 架構

Pinot 采用 Lambda 架構，架構圖所示，包括：

• Pinot Controller。作為集群和數(shù)據(jù)管理。使用 Zookeeper、Helix 來進行集群和數(shù)據(jù)的管理，使用 Restful API 來進行溝通。
• Pinot Broker。作為 Pinot 的查詢層，所有請求先到 Broker，再通過它分配給具體的離線和在線服務，分別查詢，之后再將結果合并起來。
• Pinot Server。分為在線和離線數(shù)據(jù)服務器，在線部分直接從 Kafka 消費數(shù)據(jù)，離線部分可以從離線和遠端存儲層讀取數(shù)據(jù)；
• 離線數(shù)據(jù)存儲（Segment Store）。離線部分的數(shù)據(jù)存儲在遠程 HDFS、Amazon S3 等比較便宜的存儲上，作為備份和分層查詢使用；
• 實時數(shù)據(jù)導入(Real-time Ingestion)。從各種實時的數(shù)據(jù)源（如 Kafka、Kinesis）把數(shù)據(jù)消費進來，實時消費的數(shù)據(jù)會被寫到本地數(shù)據(jù)服務器并且上傳到離線數(shù)據(jù)存儲用于備份。
• 離線數(shù)據(jù)導入(batch ingestion)。離線數(shù)據(jù)可以通過微批任務，把原始數(shù)據(jù)讀出后，再寫到離線存儲中，然后就可以通知集群，將離線數(shù)據(jù)下載供查詢使用。

3. 索引

為了支持低延時、高并發(fā)的查詢，Pinot 的工程優(yōu)化目標是盡量減少單次查詢需要掃描的數(shù)據(jù)量。

為此 Pinot 實現(xiàn)了很多索引來幫助縮小查詢范圍，包括常見的反向索引、排序索引，以及對于特殊數(shù)據(jù)格式和類型的索引，如區(qū)間范圍的索引、半結構化 Json 數(shù)據(jù)的索引、地理信息的索引等。

同時，對于聚合查詢，相比于對于全維度的預聚合，Pinot 內部可以根據(jù)維度的，動態(tài)的聚合結果，使得查詢效率更高。

4. 可插拔架構

Pinot 采用可插拔架構，查詢層、索引層、存儲層都支持 SPI 接口，用戶可以方便地在 Pinot 上進行二次擴展開發(fā)。

上圖展示了 Pinot 的可插拔架構?；?Pinot SPI 包，開發(fā)者可以配置開發(fā)自己的數(shù)據(jù)存儲、輸入格式、流式引擎、索引、查詢等。開發(fā)者只需要寫一些簡單的實現(xiàn)，就可以構建、打包然后應用，非常方便。比如，作者僅花一周左右時間，就實現(xiàn)了向量索引功能。

三、Apache Pinot 對 AI 的支持

下面將介紹在 AI 時代，Pinot 如何支持 AI 應用。

1. Pinot 作為向量數(shù)據(jù)庫

Pinot 可以作為一個向量數(shù)據(jù)庫為 AI 提供 Embedding 數(shù)據(jù)存儲以及向量檢索。

Embedding 可以看成一個浮點數(shù)的數(shù)組，存到數(shù)據(jù)庫中。有了 Embedding 向量后，當一個向量進來，需要查詢和這個向量最相似的 K 個結果。

這類應用場景有很多，如常見的搜索場景和推薦場景。

例如二手車搜索場景。用戶可能會去二手車網(wǎng)站，搜索想要的車。在搜索過程中，用戶會有很多偏好，比如喜好品牌、年份區(qū)間、價格區(qū)間、顏色、天窗等。直接使用篩選的話，結果可能過多或過少。我們可以把用戶搜索的偏好描述，作為一個 Embedding，存入數(shù)據(jù)庫。然后根據(jù)用戶偏好描述，返回一個與描述相似的 topK 排序，展示給用戶。

用戶推薦餐廳場景?？梢愿鶕?jù)用戶歷史喜歡吃的東西，同時結合用戶當前的描述，生成一個 Embedding，存儲起來。然后根據(jù) Embedding，給用戶推薦和他偏好相近的產(chǎn)品，這可以得到更好的用戶產(chǎn)品體驗。

2. 實時檢索增強生成 RAG

為什么需要實時呢？比如問 ChatGPT，“在足球界，藥廠是什么梗？”，回答“勒沃庫森”“但至今未能獲得聯(lián)賽冠軍”，而熟悉足球的小伙伴會知道，“勒沃庫森”在 2024 年第一次獲得德甲聯(lián)賽冠軍。

因此，可以看出 LLM 模型和數(shù)據(jù)都是有時效性的，如果沒有最準確最實時的數(shù)據(jù)，可能獲取不到準確的結果。通過 RAG 和實時向量數(shù)據(jù)庫的幫助，模型可以提供更實時和準確的結果。

3. 用 Pinot 實現(xiàn)實時 RAG

為了實現(xiàn)實時 RAG，在向量數(shù)據(jù)方面，我們需要通過將原始數(shù)據(jù)變成 Embedding，存到向量數(shù)據(jù)庫中，從而提供給用戶查詢。

上圖是一個一般的流程，用來實現(xiàn)用戶回復中對于實時數(shù)據(jù)的要求。

將原始文本文件、音頻或照片根據(jù) Embedding 模型，得到他們的 Embedding 表示，寫入 Kafka 并存入 Pinot，這樣實時的數(shù)據(jù)流就變成向量進入了向量庫。

對于一個用戶，將他的問題，也轉換成對應的 Embedding，然后通過向量相似性搜索，就可以找到一堆類似的數(shù)據(jù)；這些數(shù)據(jù)稱為加強上下文（Enhance Context），也就是把相關的文本和用戶本身的問題合在一起，交給 Prompt，再通過 LLM，生成給用戶的回答。

通過這樣的數(shù)據(jù)處理，可以將實時數(shù)據(jù)流與 RAG 結合起來，達到更好的準確性。

Pinot 提供了很多向量計算的支持，比如距離計算函數(shù)，支持 L1、L2、余弦、點積等距離。可以根據(jù)不同的用戶場景，選擇不同的距離計算方法，達到不同的效果。

Pinot 通過向量索引可以提高查詢效率。采用 HNSW 算法，來建立向量索引，然后通過多層迭代的方式，幫助用戶輸入的向量，找到離它最近的 n 個向量。這樣相對于全表掃描對每個向量都計算一個距離的方法，計算復雜度大幅降低。

而對于開發(fā)者來說，這個查詢也很簡單。如上圖右邊代碼所示，定義了算法使用的距離，以及向量相似度查詢的語句，返回 10 條最近的結果。

算法在不同數(shù)據(jù)集上的性能表現(xiàn)如上圖所示。我們使用了 Lucene Benchmark，采用 Lucene 的 HNSW 算法的實現(xiàn)。大家也可以點擊鏈接去看看不同算法的實現(xiàn)和性能，因 Lucene 也是開源的，我們會跟社區(qū)一起進行性能優(yōu)化。

通過混合負載，可以將 OLAP 和向量數(shù)據(jù)庫結合起來，以實現(xiàn)維度數(shù)據(jù)的過濾，并結合其它數(shù)據(jù)，提高 prompt 的準確度。

比如，用戶可以有產(chǎn)品評價數(shù)據(jù)的 Embedding，也有產(chǎn)品本身的特征，比如 SKU_ID，類別等。在做向量查詢時，需要根據(jù)類別等維度特征過濾，再做相似性查詢，查完的結果合起來，輸出給 Prompt，進行后面的反饋生成。

四、總結

最后，對本次分享的主要內容進行一下總結。

• 通過實時 RAG 可以幫助用戶獲得更好的用戶體驗；同時，用戶也可以使用他們自己的數(shù)據(jù)來輔助結果生成。
• Pinot 作為一個實時向量數(shù)據(jù)庫，可以提供更加實時準確的查詢。
• Pinot 通過結構化數(shù)據(jù)和半結構化或非結構化數(shù)據(jù)的混合負載，一起為用戶提供數(shù)據(jù)分析與應用服務。