抖音依靠自身推薦系統(tǒng)為用戶推送可能感興趣的視頻內(nèi)容，其中興趣圈層是推薦的重要能力，通過(guò)理解核心用戶的偏好特征，判斷兩者偏好的相似性，從而構(gòu)建同類(lèi)用戶的興趣圈層，實(shí)現(xiàn)精準(zhǔn)推薦。

以往的興趣圈層往往依賴單一的維度或標(biāo)簽，比如內(nèi)容類(lèi)型、時(shí)長(zhǎng)、地理特征等，難以揭示用戶興趣的底層邏輯。例如，重慶美女小姐姐吃播視頻、二次元古風(fēng)舞蹈視頻，表面上標(biāo)簽類(lèi)型可能完全不一樣，但深度分析后發(fā)現(xiàn)喜歡兩個(gè)視頻的是同一個(gè)類(lèi)型的人，并把他們劃分在同一個(gè)興趣圈層中。

要搭建這樣一套興趣圈層平臺(tái)，不僅需要算法策略，對(duì)底層數(shù)據(jù)存儲(chǔ)架構(gòu)也是一大挑戰(zhàn)。抖音每日新增的數(shù)據(jù)量龐大、業(yè)務(wù)標(biāo)簽五花八門(mén)，更需要滿足業(yè)務(wù)人員對(duì)復(fù)雜查詢的實(shí)時(shí)性訴求。之前技術(shù)團(tuán)隊(duì)采用MySQL作為存儲(chǔ)架構(gòu)，作為一種行式存儲(chǔ)的數(shù)據(jù)庫(kù)，MySQL對(duì)于大量數(shù)據(jù)的處理效率較低。如果要在MySQL上查詢上億級(jí)別的數(shù)據(jù)，可能需要更高配置的硬件，甚至可能需要采用分片、讀寫(xiě)分離等策略來(lái)提升性能，這將導(dǎo)致硬件成本顯著提高。

因此，技術(shù)團(tuán)隊(duì)逐漸將興趣平臺(tái)基于ByteHouse進(jìn)行重構(gòu)。ByteHouse是一款OLAP引擎，具備查詢效率高的特點(diǎn)，在硬件需求上相對(duì)較低，且具有良好的水平擴(kuò)展性，如果數(shù)據(jù)量進(jìn)一步增長(zhǎng)，可以通過(guò)增加服務(wù)器數(shù)量來(lái)提升處理能力。本文將從興趣圈層建設(shè)難點(diǎn)及構(gòu)建方案等角度拆解如何基于OLAP引擎來(lái)搭建興趣圈層平臺(tái)。

興趣圈層平臺(tái)介紹

興趣圈層指興趣愛(ài)好相同的人組成的群體，興趣圈層可以從用戶視角更深入的理解短視頻作者和內(nèi)容，挖掘出該圈層作者核心用戶群體的共同興趣點(diǎn)和典型偏好特征，作為劃分作者的重要標(biāo)簽，應(yīng)用在內(nèi)容分發(fā)、垂類(lèi)運(yùn)營(yíng)、數(shù)據(jù)分析、戰(zhàn)略規(guī)劃等場(chǎng)景中輸出價(jià)值。興趣圈層以簇（cluster）的形式存在，通過(guò)機(jī)器模型聚類(lèi)而成，每個(gè)簇包含一位種子作者及多位與之關(guān)聯(lián)作者。

圈層生產(chǎn)流程：數(shù)倉(cāng)的天級(jí) Hive 表以定時(shí)任務(wù)的方式將 Hive 表內(nèi)數(shù)據(jù)按照分區(qū)導(dǎo)入 RDS（MySQL） 數(shù)據(jù)庫(kù)，同時(shí)預(yù)計(jì)算腳本每天會(huì)定時(shí)將 RDS 內(nèi)的數(shù)據(jù)按需寫(xiě)入緩存（如圈層信息等通用查詢）或?qū)懟豏DS（如圈層的父節(jié)點(diǎn)信息等核心數(shù)據(jù)），生產(chǎn)流程成功會(huì)標(biāo)記在緩存代表今日數(shù)據(jù)有效，反之報(bào)警通知相關(guān)負(fù)責(zé)人。

圈層查詢流程：用戶操作查詢，前端發(fā)送查詢場(chǎng)景數(shù)據(jù)請(qǐng)求，服務(wù)端接收到請(qǐng)求后讀取相應(yīng)的緩存、數(shù)據(jù)庫(kù)表及分區(qū)，對(duì)數(shù)據(jù)進(jìn)行組裝，最終返回給用戶。

主要問(wèn)題

數(shù)據(jù)膨脹

日更版本導(dǎo)致數(shù)據(jù)量級(jí)膨脹，圈層基礎(chǔ)信息表日增萬(wàn)級(jí)數(shù)據(jù)，圈層作者信息表日增百萬(wàn)數(shù)據(jù)，圈層用戶信息表日增千萬(wàn)條左右數(shù)據(jù)，已經(jīng)達(dá)到 MySQL 秒級(jí)千萬(wàn)級(jí)查詢的性能瓶頸。

查詢效率已無(wú)法滿足需求，即使有緩存加速減少聯(lián)表查詢，單表查詢的效率在到10s以上，其中圈層理解（圈層用戶信息表）進(jìn)入頁(yè)面的時(shí)間超過(guò)15s，一定程度影響業(yè)務(wù)使用體驗(yàn)。之前做了很多包括索引優(yōu)化、查詢優(yōu)化、緩存優(yōu)化、表結(jié)構(gòu)優(yōu)化，但是單次對(duì)表更新列/新增修改索引的時(shí)間已經(jīng)超過(guò)2天，優(yōu)化成本也逐漸升高。

歷史架構(gòu)過(guò)薄，難以承接較復(fù)雜圈選能力

從現(xiàn)狀來(lái)看，當(dāng)前圈層架構(gòu)簡(jiǎn)單且為區(qū)分查詢場(chǎng)景，與數(shù)據(jù)庫(kù)直接交互且僅支持簡(jiǎn)單的同步查詢，當(dāng)業(yè)務(wù)需要較復(fù)雜的泛化圈選條件時(shí)，需要用戶在平臺(tái)等待超過(guò)15s。

從未來(lái)規(guī)劃，目前以 RDS 為存儲(chǔ)的同步查詢架構(gòu)已無(wú)法支持需要關(guān)聯(lián)多個(gè)表和特征的復(fù)雜條件查詢的業(yè)務(wù)場(chǎng)景。

業(yè)務(wù)特征膨脹

標(biāo)簽特征膨脹，當(dāng)前圈層有越來(lái)越多的標(biāo)簽描述，由于不同業(yè)務(wù)方會(huì)通過(guò)不同視角理解圈層，如垂類(lèi)標(biāo)簽/圈層關(guān)鍵詞描述/圈層質(zhì)量分類(lèi)/圈層畫(huà)風(fēng)等，目前圈層信息實(shí)體特征達(dá)到幾十種，預(yù)計(jì)圈層屬性標(biāo)簽仍會(huì)膨脹。

一站式圈選泛化目標(biāo)作者訴求增多，當(dāng)前作者只包含基礎(chǔ)信息，業(yè)務(wù)方希望基于圈層和其他基礎(chǔ)作者特征，如粉絲數(shù)，作者質(zhì)量，活躍度等以滿足對(duì)作者的流量定向策略等需求，以滿足復(fù)雜條件多維度的篩選排序功能。

基于 ByteHouse 重構(gòu)興趣圈層平臺(tái)

RDS 作為行式數(shù)據(jù)庫(kù)更適合單點(diǎn)事務(wù)分析工作顯然不符合當(dāng)前平臺(tái)訴求，我們分別從查詢場(chǎng)景、查詢性能、存儲(chǔ)成本、遷移成本對(duì)存儲(chǔ)選型。

查詢場(chǎng)景

1. 圈層信息由模型生產(chǎn)，按時(shí)間分區(qū)批量導(dǎo)入，不存在臨時(shí)導(dǎo)入，為 append only 場(chǎng)景。
2. 圈層特征多，業(yè)務(wù)方按照訴求對(duì)和自身業(yè)務(wù)相關(guān)的特征進(jìn)行篩選，列式存儲(chǔ)比行式存儲(chǔ)更合適。
3. 圈層主要以分析統(tǒng)計(jì)為主，不強(qiáng)需求事務(wù)處理，面向 OLAP 業(yè)務(wù)。

查詢性能

1. MySQL 對(duì)于多列復(fù)雜的條件查詢時(shí)，查詢性能很難優(yōu)化，需要通過(guò)強(qiáng)依賴 redis 緩存加速，否則平臺(tái)功能不可用。
2. 圈層場(chǎng)景通常限制在局部數(shù)據(jù)中聚合分析，如計(jì)算圈層id位于集合內(nèi)的關(guān)鍵詞頻率統(tǒng)計(jì)，若該集合范圍過(guò)大索引失效會(huì)被劣化為全表掃描。

詳細(xì)場(chǎng)景測(cè)試

重構(gòu)前后存儲(chǔ)對(duì)比

具體場(chǎng)景對(duì)比

數(shù)據(jù)管理信息查詢場(chǎng)景：

應(yīng)用工具分析場(chǎng)景：

總結(jié)

綜上可以看到，基于 ByteHouse 替換 MySQL 重構(gòu)抖音興趣圈層平臺(tái)后，不同幾個(gè)典型場(chǎng)景的查詢效率平均提升了 100 倍左右，大大提升了用戶體驗(yàn)。由于 ByteHouse 出色的查詢性能和良好的數(shù)據(jù)壓縮比，中等資源的服務(wù)器就能很好的滿足需求，這也降低了綜合硬件成本。此外，ByteHouse 具有良好的水平擴(kuò)展能力，如果數(shù)據(jù)量進(jìn)一步增長(zhǎng)，也可以便捷的通過(guò)增加服務(wù)器數(shù)量來(lái)提升分析能力。