毫秒級從百億大表任意維度篩選資料，是怎麼做到的...

1   業務背景

隨著閒魚業務的發展，使用者規模達到數億級，使用者維度的資料指標，達到上百個之多。如何從億級別的資料中，快速篩選出符合期望的使用者人群，進行精細化人群運營，是技術需要解決的問題。業界的很多方案往往需要分鐘級甚至小時級才能生成查詢結果。本文提供了一種解決大資料場景下的高效資料篩選、統計和分析方法，從億級別資料中，任意組合查詢條件，篩選需要的資料，做到毫秒級返回。

從技術角度分析，我們這個業務場景有如下特點：

• 需要支援任意維度的組合(and/or)巢狀查詢，且要求低延遲；

• 資料規模大，至少億級別，且需要支援不斷擴充套件；

• 單條資料指標維度多，至少上百，且需要支援不斷增加； 綜合分析，這是一個典型的OLAP場景。

下面簡單對比下OLTP和OLAP：

• 資料量瓶頸：mysql比較適合的資料量級是百萬級，再多的話，查詢和寫入效能會明顯下降。因此，一般會採用分庫分表的方式，把資料規模控制在百萬級。

• 查詢效率瓶頸：mysql對於常用的條件查詢，需要單獨建立索引或組合索引。非索引欄位的查詢需要掃描全表，效能下降明顯。

綜上分析，我們的應用場景，並不適合採用行儲存資料庫，因此我們重點考慮列存資料庫。

下面簡單對比一下行式儲存與列式儲存的特點：

HybridDB for MySQL計算規格介紹

• 任意維度智慧組合索引(使用方無需單獨自建索引)

• 百億大表查詢毫秒級響應

• MySql BI生態相容，完備SQL支援

• 空間檢索、全文檢索、複雜資料型別(多值列、JSON)支援

那麼，HybridDB for MySQL計算規格是如何做到大資料場景下的任意維度組合查詢的毫秒級響應的呢？

• 首先是HybridDB的高效能列式儲存引擎，內建於儲存的謂詞計算能力，可以利用各種統計資訊快速跳過資料塊實現快速篩選；

• 第二是HybridDB的智慧索引技術，在大寬表上一鍵自動全索引並根據列索引智慧組合出各種謂詞條件進行過濾；

• 第三是高效能MPP+DAG的融合計算引擎，兼顧高併發和高吞吐兩種模式實現了基於pipeline的高效能向量計算，並且計算引擎和儲存緊密配合，讓計算更快；

• 第四是HybridDB支援各種資料建模技術例如星型模型、雪花模型、聚集排序等，業務適度資料建模可以實現更好的效能指標。

綜合來說，HybridDB for MySQL計算規格是以SQL為中心的多功能線上實時倉庫系統，很適合我們的業務場景，因此我們在此之上構建了我們的人群圈選底層引擎。

3  業務落地

在搭建了人群圈選引擎之後，我們重點改造了我們的訊息推送系統，作為人群精細化運營的一個重要落地點。

離線資料層：使用者維度資料，分散在各個業務系統的離線表中。我們透過離線T+1定時任務，把資料彙總匯入到實時計算層的使用者大寬表中。

實時計算層：根據人群的篩選條件，從使用者大寬表中，查詢符合的使用者數量和使用者ID列表，為應用系統提供服務。

人群圈選前臺系統：提供視覺化的操作介面。運營同學選擇篩選條件，儲存為人群，用於分析或者傳送PUSH。每一個人群，對應一個SQL儲存。類似於： select count(*) from userbigtable where column1> 1 and column2 in ('a','b') and ( column31=1 or column32=2) 同時，SQL可以支援任意欄位的多層and/or巢狀組合。 用SQL儲存人群的方式，當使用者表中的資料變更時，可以隨時執行SQL，獲取最新的人群使用者，來更新人群。

閒魚PUSH系統：從人群圈選前臺系統中獲取人群對應的where條件，再從實時計算層，分頁獲取使用者列表，給使用者傳送PUSH。在實現過程中，我們重點解決了分頁查詢的效能問題。

分頁查詢效能最佳化方案： 在分頁時，當人群的規模很大(千萬級別)時，頁碼越往後，查詢的效能會有明顯下降。因此，我們採用把人群資料增加行號、匯出到MySql的方式，來提升效能。表結構如下：

• 批次號：人群每匯出一次，就新加一個批次號，批次號為時間戳，遞增。

• 行號：從1開始遞增，每一個批次號對應的行號都是從1到N。

我們為"人群ID"+"批次號"+"行號"建組合索引，分頁查詢時，用索引查詢的方式替換分頁的方式，從而保證大頁碼時的查詢效率。

另外，為此額外付出的匯出資料的開銷，得益於HybridDB強大的資料匯出能力，資料量在萬級別至百萬級別，耗時在秒級至幾十秒級別。綜合權衡之後，採用了本方案。

人群圈選系統為閒魚精細化使用者運營提供了強有力的底層能力支撐。同時，圈選人群，也可以應用到其他的業務場景，比如首頁焦點圖定投等需要分層使用者運營的場景，為閒魚業務提供了很大的最佳化空間。

本文實現了海量多維度資料中組合查詢的秒級返回結果，是一種OLAP場景下的通用技術實現方案。同時介紹了用該技術方案改造原有業務系統的一個應用案例，取得了很好的業務結果，可供類似需求或場景的參考。

人群圈選引擎中的使用者資料，我們目前是T+1匯入的。這是考慮到人群相關的指標，變化頻率不是很快，且很多指標(比如使用者標籤)都是離線T+1計算的，因此T+1的資料更新頻度是可以接受的。後續我們又基於HybridDB構建了更為強大的商品圈選引擎。閒魚商品資料相比使用者資料，變化更快。一方面使用者隨時會更新自己的商品，另一方面，由於閒魚商品單庫存(售出即下架)的特性，以及其他原因，商品狀態會隨時變更。因此我們的選品引擎，應該儘快感知到這些資料的變化，並在投放層面做出實時調整。我們基於HybridDB(儲存)和實時計算引擎，構建了更為強大的“馬赫”實時選品系統。已推出“馬赫”的系列文章，有興趣的同學可以關注。另外如果對本文中的具體技術實現(細節)有任何問題，請聯絡我們。謝謝。

參考資料： HybridDB for MySQL介紹：