隨著閑魚業(yè)務(wù)的發(fā)展，用戶規(guī)模達(dá)到數(shù)億級，用戶維度的數(shù)據(jù)指標(biāo)，達(dá)到上百個(gè)之多。

[[252595]]

如何從億級別的數(shù)據(jù)中，快速篩選出符合期望的用戶人群，進(jìn)行精細(xì)化人群運(yùn)營，是技術(shù)需要解決的問題。業(yè)界的很多方案常常需要分鐘級甚至小時(shí)級才能生成查詢結(jié)果。

本文提供了一種解決大數(shù)據(jù)場景下的高效數(shù)據(jù)篩選、統(tǒng)計(jì)和分析方法，從億級別數(shù)據(jù)中，任意組合查詢條件，篩選需要的數(shù)據(jù)，做到毫秒級返回。

技術(shù)選型分析

從技術(shù)角度分析，我們這個(gè)業(yè)務(wù)場景有如下特點(diǎn)：

• 需要支持任意維度的組合(and/or)嵌套查詢，且要求低延遲。
• 數(shù)據(jù)規(guī)模大，至少億級別，且需要支持不斷擴(kuò)展。
• 單條數(shù)據(jù)指標(biāo)維度多，至少上百，且需要支持不斷增加。

綜合分析，這是一個(gè)典型的 OLAP 場景。

OLTP 與 OLAP

下面簡單對比下 OLTP 和 OLAP：

最常見的數(shù)據(jù)庫，如 MySQL、Oracle 等，都采用行式存儲(chǔ)，比較適合 OLTP。

如果用 MySQL 等行數(shù)據(jù)庫來實(shí)現(xiàn) OLAP，一般都會(huì)碰到兩個(gè)瓶頸：

• 數(shù)據(jù)量瓶頸：MySQL 比較適合的數(shù)據(jù)量級是百萬級，再多的話，查詢和寫入性能會(huì)明顯下降。因此，一般會(huì)采用分庫分表的方式，把數(shù)據(jù)規(guī)?？刂圃诎偃f級。
• 查詢效率瓶頸：MySQL 對于常用的條件查詢，需要單獨(dú)建立索引或組合索引。非索引字段的查詢需要掃描全表，性能下降明顯。

綜上分析，我們的應(yīng)用場景，并不適合采用行存儲(chǔ)數(shù)據(jù)庫，因此我們重點(diǎn)考慮列存數(shù)據(jù)庫。

行式存儲(chǔ)與列式存儲(chǔ)

下面簡單對比一下行式存儲(chǔ)與列式存儲(chǔ)的特點(diǎn)：

行存適合近線數(shù)據(jù)分析，比如要求查詢表中某幾條符合條件的記錄的所有字段的場景。

列存適合用于數(shù)據(jù)的統(tǒng)計(jì)分析?？紤]如下場景：一個(gè)用于存放用戶的表中有 20 個(gè)字段，而我們要統(tǒng)計(jì)用戶年齡的平均值，如果是行存，則要全表掃描，遍歷所有行。

但如果是列存，數(shù)據(jù)庫只要定位到年齡這一列，然后只掃描這一列的數(shù)據(jù)就可以得到所有的年齡，計(jì)算平均值，性能上相比行存理論上就會(huì)快 20 倍。

而在列存數(shù)據(jù)庫中，比較常見的是 HBase。HBase 應(yīng)用的核心設(shè)計(jì)重點(diǎn)是 rowkey 的設(shè)計(jì)，一般要把常用的篩選條件，組合設(shè)計(jì)到 rowkey 中，通過 rowkey 的 get(單條記錄) 或者 scan(范圍) 查詢。

因此 HBase 比較適合有限查詢條件下的非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。而我們的場景，由于所有字段都需要作為篩選條件，所以本質(zhì)上還是需要結(jié)構(gòu)化存儲(chǔ)，且要求查詢低延遲，因此也無法使用 HBase。

我們綜合考慮集團(tuán)內(nèi)多款列式存儲(chǔ)的 DB 產(chǎn)品(ADS/PostgreSQL/HBase/HybridDB)。

綜合評估讀寫性能、穩(wěn)定性、語法完備程度及開發(fā)和部署成本，最終選擇了 HybridDB for MySQL 計(jì)算規(guī)格來構(gòu)建人群圈選引擎。

HybridDB for MySQL 介紹

HybridDB for MySQL 計(jì)算規(guī)格對我們的這個(gè)場景而言，核心能力主要有：

• 任意維度智能組合索引(使用方無需單獨(dú)自建索引)。
• 百億大表查詢毫秒級響應(yīng)。
• MySQL BI 生態(tài)兼容，完備 SQL 支持。
• 空間檢索、全文檢索、復(fù)雜數(shù)據(jù)類型(多值列、JSON)支持。

那么，HybridDB for MySQL 計(jì)算規(guī)格是如何做到大數(shù)據(jù)場景下的任意維度組合查詢的毫秒級響應(yīng)的呢？

步驟如下：

• 首先是 HybridDB 的高性能列式存儲(chǔ)引擎，內(nèi)置于存儲(chǔ)的謂詞計(jì)算能力，可以利用各種統(tǒng)計(jì)信息快速跳過數(shù)據(jù)塊實(shí)現(xiàn)快速篩選。
• 第二是 HybridDB 的智能索引技術(shù)，在大寬表上一鍵自動(dòng)全索引并根據(jù)列索引智能組合出各種謂詞條件進(jìn)行過濾。
• 第三是高性能 MPP+DAG 的融合計(jì)算引擎，兼顧高并發(fā)和高吞吐兩種模式實(shí)現(xiàn)了基于 pipeline 的高性能向量計(jì)算，并且計(jì)算引擎和存儲(chǔ)緊密配合，讓計(jì)算更快。
• 第四是 HybridDB 支持各種數(shù)據(jù)建模技術(shù)例如星型模型、雪花模型、聚集排序等，業(yè)務(wù)適度數(shù)據(jù)建?？梢詫?shí)現(xiàn)更好的性能指標(biāo)。

綜合來說，HybridDB for MySQL 計(jì)算規(guī)格是以 SQL 為中心的多功能在線實(shí)時(shí)倉庫系統(tǒng)，很適合我們的業(yè)務(wù)場景，因此我們在此之上構(gòu)建了我們的人群圈選底層引擎。

業(yè)務(wù)實(shí)現(xiàn)

在搭建了人群圈選引擎之后，我們重點(diǎn)改造了我們的消息推送系統(tǒng)，作為人群精細(xì)化運(yùn)營的一個(gè)重要落地點(diǎn)。

閑魚消息推送簡介

消息推送(PUSH)是信息觸達(dá)用戶最快捷的手段。閑魚比較常用的 PUSH 方式，是先離線計(jì)算好 PUSH 人群、準(zhǔn)備好對應(yīng) PUSH 文案，然后在第二天指定的時(shí)間推送。

一般都是周期性的 PUSH 任務(wù)。但是臨時(shí)性的、需要立刻發(fā)送、緊急的 PUSH 任務(wù)，就需要 BI 同學(xué)介入，每個(gè) PUSH 任務(wù)平均約需要占用 BI 同學(xué)半天的開發(fā)時(shí)間，且操作上也比較麻煩。

本次我們把人群圈選系統(tǒng)與原有的 PUSH 系統(tǒng)打通，極大地改善了此類 PUSH 的準(zhǔn)備數(shù)據(jù)以及發(fā)送的效率，解放了開發(fā)資源。

系統(tǒng)架構(gòu)

離線數(shù)據(jù)層：用戶維度數(shù)據(jù)，分散在各個(gè)業(yè)務(wù)系統(tǒng)的離線表中。我們通過離線 T+1 定時(shí)任務(wù)，把數(shù)據(jù)匯總導(dǎo)入到實(shí)時(shí)計(jì)算層的用戶大寬表中。

實(shí)時(shí)計(jì)算層：根據(jù)人群的篩選條件，從用戶大寬表中，查詢符合的用戶數(shù)量和用戶 ID 列表，為應(yīng)用系統(tǒng)提供服務(wù)。

人群圈選前臺(tái)系統(tǒng)：提供可視化的操作界面。運(yùn)營同學(xué)選擇篩選條件，保存為人群，用于分析或者發(fā)送 PUSH。

每一個(gè)人群，對應(yīng)一個(gè) SQL 存儲(chǔ)，類似于：

select count(*) from user_big_table where column1> 1 and column2 in ('a','b') and ( column31=1 or column32=2) 

同時(shí)，SQL 可以支持任意字段的多層 and/or 嵌套組合。用 SQL 保存人群的方式，當(dāng)用戶表中的數(shù)據(jù)變更時(shí)，可以隨時(shí)執(zhí)行 SQL，獲取最新的人群用戶，來更新人群。

閑魚 PUSH 系統(tǒng)：從人群圈選前臺(tái)系統(tǒng)中獲取人群對應(yīng)的 where 條件，再從實(shí)時(shí)計(jì)算層，分頁獲取用戶列表，給用戶發(fā)送 PUSH。在實(shí)現(xiàn)過程中，我們重點(diǎn)解決了分頁查詢的性能問題。

分頁查詢性能優(yōu)化方案：在分頁時(shí)，當(dāng)人群的規(guī)模很大(千萬級別)時(shí)，頁碼越往后，查詢的性能會(huì)有明顯下降。

因此，我們采用把人群數(shù)據(jù)增加行號(hào)、導(dǎo)出到 MySQL 的方式，來提升性能。

表結(jié)構(gòu)如下：

• 批次號(hào)：人群每導(dǎo)出一次，就新加一個(gè)批次號(hào)，批次號(hào)為時(shí)間戳，遞增。
• 行號(hào)：從 1 開始遞增，每一個(gè)批次號(hào)對應(yīng)的行號(hào)都是從 1 到 N。

我們?yōu)?quot;人群 ID"+"批次號(hào)"+"行號(hào)"建組合索引，分頁查詢時(shí)，用索引查詢的方式替換分頁的方式，從而保證大頁碼時(shí)的查詢效率。

另外，為此額外付出的導(dǎo)出數(shù)據(jù)的開銷，得益于 HybridDB 強(qiáng)大的數(shù)據(jù)導(dǎo)出能力，數(shù)據(jù)量在萬級別至百萬級別，耗時(shí)在秒級至幾十秒級別。綜合權(quán)衡之后，采用了本方案。

PUSH 系統(tǒng)改造收益

人群圈選系統(tǒng)為閑魚精細(xì)化用戶運(yùn)營提供了強(qiáng)有力的底層能力支撐。同時(shí)，圈選人群，也可以應(yīng)用到其他的業(yè)務(wù)場景，比如首頁焦點(diǎn)圖定投等需要分層用戶運(yùn)營的場景，為閑魚業(yè)務(wù)提供了很大的優(yōu)化空間。

本文實(shí)現(xiàn)了海量多維度數(shù)據(jù)中組合查詢的秒級返回結(jié)果，是一種 OLAP 場景下的通用技術(shù)實(shí)現(xiàn)方案。

同時(shí)介紹了用該技術(shù)方案改造原有業(yè)務(wù)系統(tǒng)的一個(gè)應(yīng)用案例，取得了很好的業(yè)務(wù)結(jié)果，可供類似需求或場景的參考。

未來

人群圈選引擎中的用戶數(shù)據(jù)，我們目前是 T+1 導(dǎo)入的。這是考慮到人群相關(guān)的指標(biāo)，變化頻率不是很快，且很多指標(biāo)(比如用戶標(biāo)簽)都是離線 T+1 計(jì)算的，因此 T+1 的數(shù)據(jù)更新頻度是可以接受的。

后續(xù)我們又基于 HybridDB 構(gòu)建了更為強(qiáng)大的商品圈選引擎。閑魚商品數(shù)據(jù)相比用戶數(shù)據(jù)，變化更快。

一方面用戶隨時(shí)會(huì)更新自己的商品；另一方面，由于閑魚商品單庫存(售出即下架)的特性，以及其他原因，商品狀態(tài)會(huì)隨時(shí)變更。

因此我們的選品引擎，應(yīng)該盡快感知到這些數(shù)據(jù)的變化，并在投放層面做出實(shí)時(shí)調(diào)整。

我們基于 HybridDB(存儲(chǔ))和實(shí)時(shí)計(jì)算引擎，構(gòu)建了更為強(qiáng)大的“馬赫”實(shí)時(shí)選品系統(tǒng)。

參考資料：

HybridDB for MySQL 介紹：http://click.aliyun.com/m/1000027814/