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

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

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

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

興趣圈層平臺介紹

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

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

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

主要問題

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

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

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

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

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

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

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

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

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

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

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

查詢場景

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

查詢性能

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

詳細場景測試

重構(gòu)前后存儲對比

具體場景對比

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

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

總結(jié)

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