知乎用戶畫像與實(shí)時(shí)數(shù)倉的架構(gòu)與實(shí)踐

知乎用戶畫像與實(shí)時(shí)數(shù)倉的架構(gòu)與實(shí)踐用戶畫像與實(shí)時(shí)數(shù)據(jù)分析是互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)核心。知乎數(shù)據(jù)賦能團(tuán)隊(duì)以ApacheDoris為基礎(chǔ)，基于云服務(wù)構(gòu)建高響應(yīng)、低成本、兼顧穩(wěn)定性與靈活性的實(shí)時(shí)數(shù)據(jù)架構(gòu)，同時(shí)支持實(shí)時(shí)業(yè)務(wù)分析、實(shí)時(shí)算法特征、用戶畫像三項(xiàng)核心業(yè)務(wù)流，顯著提升對(duì)于時(shí)效性熱點(diǎn)與潛力的感知力度與響應(yīng)速度，大幅縮減運(yùn)營(yíng)、營(yíng)銷等業(yè)務(wù)場(chǎng)景中的人群定向成本，并對(duì)實(shí)時(shí)算法的準(zhǔn)確率及業(yè)務(wù)核心指標(biāo)帶來明顯增益。關(guān)鍵詞：數(shù)據(jù)倉庫，Apache

Doris，用戶畫像，實(shí)時(shí)數(shù)據(jù)

01前言知乎業(yè)務(wù)中，隨著各業(yè)務(wù)線業(yè)務(wù)的發(fā)展，逐漸對(duì)用戶畫像和實(shí)時(shí)數(shù)據(jù)這兩部分的訴求越來越多。對(duì)用戶畫像方面，期望有更快、更準(zhǔn)、更方便的人群篩選工具和方便的用戶群體分析能力。對(duì)于實(shí)時(shí)數(shù)據(jù)方面，期望擁有可以實(shí)時(shí)響應(yīng)的用戶行為流，同時(shí)在算法特征、指標(biāo)統(tǒng)計(jì)、業(yè)務(wù)外顯等業(yè)務(wù)場(chǎng)景有愈來愈多的數(shù)據(jù)實(shí)時(shí)化的訴求。

在2021年8月，知乎平臺(tái)團(tuán)隊(duì)成立數(shù)據(jù)賦能團(tuán)隊(duì)。針對(duì)歷史實(shí)時(shí)數(shù)據(jù)需求無承接方的現(xiàn)象，已有用戶畫像系統(tǒng)無法滿足多樣的人群定向的現(xiàn)狀，及業(yè)務(wù)方進(jìn)一步人群分析的業(yè)務(wù)訴求，提出基礎(chǔ)設(shè)施層選用ApacheDoris作為實(shí)時(shí)數(shù)據(jù)倉庫技術(shù)選型，業(yè)務(wù)工具層建設(shè)實(shí)時(shí)數(shù)據(jù)集成、實(shí)時(shí)數(shù)據(jù)調(diào)度、實(shí)時(shí)數(shù)據(jù)質(zhì)量中心等系統(tǒng)，應(yīng)用層建設(shè)實(shí)時(shí)數(shù)據(jù)應(yīng)用和用戶畫像應(yīng)用的方案。該方案針對(duì)性地解決了業(yè)務(wù)痛點(diǎn)，滿足了業(yè)務(wù)訴求。

拆分當(dāng)前業(yè)務(wù)主要在實(shí)時(shí)數(shù)據(jù)和用戶畫像兩大部分有難點(diǎn)，共包含如下的三個(gè)方向目標(biāo)：1、實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)通過提供實(shí)時(shí)的業(yè)務(wù)指標(biāo)，解決業(yè)務(wù)對(duì)熱點(diǎn)、潛力的把控，助力生產(chǎn)、消費(fèi)，提升優(yōu)質(zhì)創(chuàng)作量及內(nèi)容消費(fèi)能力。提供實(shí)時(shí)的復(fù)雜計(jì)算的外顯指標(biāo)，加強(qiáng)用戶體驗(yàn)，解決業(yè)務(wù)側(cè)通過后端腳本計(jì)算的高維護(hù)成本和復(fù)雜性，節(jié)約成本，提升人效。

2、

實(shí)時(shí)算法特征以實(shí)時(shí)數(shù)據(jù)為基礎(chǔ)，提供多樣的實(shí)時(shí)算法特征，與算法團(tuán)隊(duì)共同提升DAU、留存、用戶付費(fèi)等核心指標(biāo)。

3、用戶畫像用戶篩選，做到多維、多類型的定向篩選，并接入營(yíng)銷、廣告、運(yùn)營(yíng)平臺(tái)等系統(tǒng)，提高業(yè)務(wù)效率，降低人員成本。用戶分析，做到多角度用戶分析，定向用戶分析報(bào)告0成本，助力業(yè)務(wù)部門快速把握核心客戶市場(chǎng)。本文就知乎平臺(tái)的數(shù)據(jù)賦能團(tuán)隊(duì)，基于以上三個(gè)方向的目標(biāo)，就這四個(gè)問題，來逐一介紹這方面的技術(shù)實(shí)踐經(jīng)驗(yàn)和心得體會(huì)：如何通過實(shí)時(shí)數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)發(fā)展？如何從0->1搭建實(shí)時(shí)數(shù)據(jù)中心？如何搭建一套高效快速的用戶畫像系統(tǒng)來解決歷史系統(tǒng)的多種問題？如何快速高效的開發(fā)業(yè)務(wù)功能和保證業(yè)務(wù)質(zhì)量？1.1名詞解釋名詞/縮寫描述UBSUserBehaviorSystem。知乎的實(shí)時(shí)用戶行為系統(tǒng)。包含實(shí)時(shí)的用戶行為流及相關(guān)的快查存儲(chǔ)。DMPDataManagementPlatform。知乎的用戶畫像系統(tǒng)。包含人群篩選、人群分析等功能。1.2實(shí)時(shí)數(shù)據(jù)與用戶畫像與各業(yè)務(wù)的結(jié)合02面臨的挑戰(zhàn)和痛點(diǎn)針對(duì)當(dāng)前業(yè)務(wù)目標(biāo)，主要有以下幾個(gè)具體要求。1、有價(jià)值1）如何通過實(shí)效性發(fā)現(xiàn)業(yè)務(wù)價(jià)值？搭建熱點(diǎn)、潛力等緊隨時(shí)間的指標(biāo)和相關(guān)的排行榜，直接支持業(yè)務(wù)發(fā)展。

2）如何讓用戶畫像的篩選和分析能力最大化？要全面覆蓋多維度用戶篩選的多種需求。多角度、多方式覆蓋用戶分析。2、

數(shù)據(jù)實(shí)效性1）推薦頁首屏瀏覽6條內(nèi)容，如何在第二刷的時(shí)候就立即感知到最新的用戶行為？通過UBS建設(shè)提升實(shí)效性（下面介紹）

2）在推薦算法中，非常實(shí)時(shí)的特征推薦算法效果要比天級(jí)別更新特征的算法效果好很多，如何保證10分鐘內(nèi)算法受到特征變更？通過實(shí)時(shí)數(shù)據(jù)系統(tǒng)與ApacheDoris配合共同建設(shè)，提升到10分鐘內(nèi)更新（下面介紹）

3、接口實(shí)時(shí)性熱點(diǎn)運(yùn)營(yíng)場(chǎng)景，期望用戶畫像服務(wù)能在秒級(jí)別快速篩選出大量人群，用戶后續(xù)的推送等運(yùn)營(yíng)場(chǎng)景，如何解決？通過用戶畫像系統(tǒng)與ApacheDoris配合共同建設(shè)，提升人群篩選的速度（下面介紹）

4、復(fù)雜性1）實(shí)時(shí)數(shù)據(jù)幾乎沒有count、sum需求。幾乎都是復(fù)雜去重和多數(shù)據(jù)聯(lián)合計(jì)算的情況。以播放量為例。在啟播、暫停、完播、心跳等多個(gè)條件下，會(huì)同時(shí)有多個(gè)點(diǎn)，要進(jìn)行去重。同時(shí)基于視頻回答、視頻的關(guān)系和雙作者聯(lián)合創(chuàng)作的關(guān)系，需要疊加，同時(shí)保證在父子內(nèi)容異常狀態(tài)的情況下過濾其中部分播放行為。2）人群分析業(yè)務(wù)，期望多角度、各維度進(jìn)行人群關(guān)聯(lián)計(jì)算，同時(shí)基于全部用戶特征針對(duì)當(dāng)前人群和對(duì)比人群進(jìn)行TGI計(jì)算，篩選出顯著特征，如何解決？通過用戶畫像系統(tǒng)與ApacheDoris配合共同建設(shè)，解決復(fù)雜的人群分析（下面介紹）3）業(yè)務(wù)數(shù)據(jù)中有增/刪/改邏輯，如何實(shí)時(shí)同步？實(shí)時(shí)數(shù)據(jù)集成系統(tǒng)與ApacheDoris配合共同建設(shè)，解決增/刪/改邏輯（下面介紹）4）明細(xì)數(shù)據(jù)異常發(fā)現(xiàn)滯后，異常發(fā)現(xiàn)后，需要針對(duì)性修正構(gòu)建方式，及回溯數(shù)據(jù)修復(fù)，如何解決？通過選擇Lambda架構(gòu)作為數(shù)據(jù)架構(gòu)解決（下面介紹）03實(shí)踐及經(jīng)驗(yàn)分享3.1整體業(yè)務(wù)架構(gòu)基于當(dāng)前的業(yè)務(wù)，從頂層至底層進(jìn)行了拆分。主要分為應(yīng)用層、業(yè)務(wù)模型層、業(yè)務(wù)工具層、基礎(chǔ)設(shè)施層?；谖覀儺?dāng)前的業(yè)務(wù)形態(tài)，自上而下應(yīng)用層：負(fù)責(zé)當(dāng)前我們的業(yè)務(wù)應(yīng)用，直接為業(yè)務(wù)提供工具或提供業(yè)務(wù)的某些模塊，與業(yè)務(wù)共擔(dān)目標(biāo)，為業(yè)務(wù)賦能。業(yè)務(wù)模型層：支持應(yīng)用層建設(shè)和一定的實(shí)時(shí)分析能力，同時(shí)也作為業(yè)務(wù)某一個(gè)流程的功能模塊接入使用，為外部業(yè)務(wù)和自身應(yīng)用層建設(shè)，與業(yè)務(wù)共擔(dān)目標(biāo)，為業(yè)務(wù)賦能。業(yè)務(wù)工具層：支持應(yīng)用層和業(yè)務(wù)模型層的開發(fā)，提供通用的工具，面向降低應(yīng)用層和業(yè)務(wù)模型層的建設(shè)成本，提升整體建設(shè)的工程效能，保證業(yè)務(wù)穩(wěn)定和數(shù)據(jù)質(zhì)量準(zhǔn)確?；A(chǔ)設(shè)施：技術(shù)中臺(tái)提供的基礎(chǔ)設(shè)施和云服務(wù)，提供穩(wěn)定可用的基礎(chǔ)功能，保證上層建筑的穩(wěn)定性。3.2

實(shí)時(shí)數(shù)據(jù)的數(shù)據(jù)架構(gòu)選型解決當(dāng)前問題的數(shù)據(jù)架構(gòu)，一般有Lambda架構(gòu)和Kappa架構(gòu)。針對(duì)當(dāng)前業(yè)務(wù)特點(diǎn)，計(jì)算復(fù)雜、偶發(fā)的異常問題需要大數(shù)據(jù)量回溯等特性。當(dāng)前實(shí)時(shí)數(shù)據(jù)的數(shù)據(jù)架構(gòu)采用的是Lambda架構(gòu)。由Doris承載分鐘級(jí)的批處理，F(xiàn)link來承載秒級(jí)別簡(jiǎn)單邏輯的流處理。具體如下：3.3

應(yīng)用層建設(shè)經(jīng)驗(yàn)分享3.3.1

實(shí)時(shí)數(shù)據(jù)系統(tǒng)01業(yè)務(wù)場(chǎng)景實(shí)時(shí)數(shù)據(jù)系統(tǒng)主要有兩個(gè)大方向：實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)和實(shí)時(shí)算法特征。（1）實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)。通過提供實(shí)時(shí)的業(yè)務(wù)指標(biāo)，解決業(yè)務(wù)對(duì)熱點(diǎn)、潛力的把控，助力生產(chǎn)、消費(fèi)，提升優(yōu)質(zhì)創(chuàng)作量及內(nèi)容消費(fèi)能力。提供實(shí)時(shí)的復(fù)雜計(jì)算的外顯指標(biāo)，加強(qiáng)用戶體驗(yàn)，解決業(yè)務(wù)側(cè)通過后端腳本計(jì)算的高維護(hù)成本和復(fù)雜性，節(jié)約成本，提升人效。（2）實(shí)時(shí)算法特征。以實(shí)時(shí)數(shù)據(jù)為基礎(chǔ)，提供多樣的實(shí)時(shí)算法特征，與推薦算法團(tuán)隊(duì)共同提升DAU、留存、用戶付費(fèi)等核心指標(biāo)。02

面臨的困難(1)

依賴數(shù)據(jù)源多，計(jì)算規(guī)則復(fù)雜。以我們的播放量計(jì)算為例：行為有多條，需要針對(duì)行為進(jìn)行去重。過濾和加和規(guī)則很多，需要依賴多個(gè)數(shù)據(jù)源的不同數(shù)據(jù)結(jié)果進(jìn)行計(jì)算。(2)

時(shí)間敏感性高以算法特征為例，用戶瀏覽某內(nèi)容后，針對(duì)后續(xù)關(guān)聯(lián)的一系列計(jì)算后，需要在一定時(shí)間內(nèi)產(chǎn)出計(jì)算結(jié)果（10min未產(chǎn)出后續(xù)推薦效果會(huì)有波動(dòng)，26min該特征的效果會(huì)降為0）(3)

調(diào)度過程中協(xié)調(diào)成本高需要調(diào)度系統(tǒng)中，同時(shí)能識(shí)別kafka流消費(fèi)的進(jìn)度和任務(wù)完成情況。需要嚴(yán)格拉齊多個(gè)依賴的消費(fèi)進(jìn)度，當(dāng)達(dá)到統(tǒng)一進(jìn)度后，集中進(jìn)行后續(xù)任務(wù)計(jì)算。數(shù)據(jù)倉庫：調(diào)度系統(tǒng)03

解決方案(1)搭建實(shí)時(shí)數(shù)據(jù)基座，建設(shè)相應(yīng)的數(shù)據(jù)模型，降低建設(shè)成本。

（2）針對(duì)依賴數(shù)據(jù)眾多、計(jì)算規(guī)則復(fù)雜、質(zhì)量難以保證等問題。通過建設(shè)工具降低解決問題的成本。通過建設(shè)實(shí)時(shí)數(shù)據(jù)集成和實(shí)時(shí)數(shù)據(jù)調(diào)度的能力，保障數(shù)據(jù)接入和數(shù)據(jù)模型建設(shè)的速度，降低接入時(shí)間，提升業(yè)務(wù)接入效率（具體見下方）通過建設(shè)實(shí)時(shí)數(shù)據(jù)質(zhì)量中心，保障數(shù)據(jù)質(zhì)量，降低發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題的時(shí)間，提升發(fā)現(xiàn)效率，保證業(yè)務(wù)交付結(jié)果（具體見下方）

（3）時(shí)間敏感性高，加強(qiáng)監(jiān)控、與Doris集群共同提升吞吐效率和計(jì)算效率：搭建寫入延遲、計(jì)算延遲等監(jiān)控，快速發(fā)現(xiàn)問題。Doris集群進(jìn)行參數(shù)變更，調(diào)整批量寫入的數(shù)據(jù)量、時(shí)間和頻率等進(jìn)行優(yōu)化。當(dāng)前我們的Load主要有BrokerLoad和RoutineLoad。其中時(shí)效性要求高的是RoutineLoad。我們針對(duì)性的進(jìn)行了參數(shù)調(diào)整。Doris增加了RuntimeFilter，通過BloomFilter提升Join性能。Doris集群在0.14版本中加入了RuntimeFilter的過濾，針對(duì)Join大量key被過濾的情況有明顯提升；該變更針對(duì)我們當(dāng)前的幾個(gè)業(yè)務(wù)調(diào)度性能，有明顯提升。時(shí)間從40+s提升至10s左右；

3.3.2

用戶畫像系統(tǒng)DMP01

業(yè)務(wù)場(chǎng)景用戶畫像系統(tǒng)主要有兩大功能：用戶檢索和用戶分析。（1）用戶檢索。

重點(diǎn)在于快速完成人群包圈選同時(shí)在圈選條件變更過程中，需要快速計(jì)算出預(yù)計(jì)能圈的用戶有哪些？（2）用戶分析。

重點(diǎn)在于多人群包的各個(gè)維度對(duì)比分析，通過分析結(jié)論找到最明顯的用戶特征（通過TGI值判斷）

02

面臨的困難（1）數(shù)據(jù)規(guī)模大。

我們當(dāng)前是200+個(gè)標(biāo)簽，每個(gè)標(biāo)簽均有不同的枚舉值，總計(jì)有300+萬的tag。tag對(duì)用戶的打標(biāo)量級(jí)在900+億條記錄。由于標(biāo)簽每日更新導(dǎo)入量級(jí)十分大。（2）篩選響應(yīng)時(shí)間要求高。針對(duì)簡(jiǎn)單的篩選，要求在秒級(jí)別出結(jié)果，針對(duì)復(fù)雜的人群篩選，篩選后人群量大的情況，要求在20s內(nèi)完成人群包生成。（3）人群包除了long類型的用戶id外，還需要有多種不同的設(shè)備id和設(shè)備id

md5作為篩選結(jié)果。（4）用戶分析場(chǎng)景下，針對(duì)300+萬tag的多人群交叉TGI計(jì)算，需要在10min內(nèi)完成。03

解決方案（1）DMP業(yè)務(wù)架構(gòu)（2）DMP業(yè)務(wù)流程：

（3）性能問題針對(duì)性解決；數(shù)據(jù)規(guī)模大，提升導(dǎo)入性能，分而治之。數(shù)據(jù)模型變更，拆分文件。Doris的存儲(chǔ)是按照Tablet分散在集群上的。通過調(diào)整數(shù)據(jù)模型，確保分布均勻及每個(gè)文件盡可能的小。導(dǎo)入變更，拆分導(dǎo)入。?由于每個(gè)BrokerLoad導(dǎo)入都是有性能瓶頸的，將900+億行數(shù)據(jù)，拆分為1000+個(gè)BrokerLoad的導(dǎo)入任務(wù)，確保每個(gè)導(dǎo)入總量都足夠小。

（4）提升人群篩選和人群分析的計(jì)算速度，分而治之。業(yè)務(wù)邏輯變更，拆分用戶。將用戶每0～100萬拆分為一組。針對(duì)全部用戶的交并差，等價(jià)于對(duì)所有組用戶交并差后的并集。針對(duì)全部用戶的交并差的總數(shù)，等價(jià)于對(duì)分組用戶交并差后的總數(shù)進(jìn)行sum。數(shù)據(jù)模型變更，拆分文件。設(shè)置bitmap的分組參數(shù)，將分組設(shè)置為colocategroup。確保每個(gè)分組的交并差計(jì)算均在自己所在BE完成，無需shuffle。將bitmap表的分桶拆分更多，通過更多文件同時(shí)計(jì)算加速結(jié)果。計(jì)算參數(shù)變更，提升并發(fā)。由于計(jì)算過程通過分治的手段，拆分為多個(gè)小任務(wù)。通過提升并行度parallel_fragment_exec_instance_num再進(jìn)一步優(yōu)化計(jì)算速度。04

效果

上線后，接入了知乎多個(gè)主要場(chǎng)景的業(yè)務(wù)，支持多業(yè)務(wù)方的人群定向和分析能力。為業(yè)務(wù)帶來曝光量、轉(zhuǎn)化率等直接指標(biāo)的提升。同時(shí)在工具性能上，有如下表現(xiàn)：導(dǎo)入速度。當(dāng)前每日900+億行數(shù)據(jù)，在3小時(shí)內(nèi)完成導(dǎo)入。人群預(yù)估。人群預(yù)估基本可在1s內(nèi)完成，P95985ms。人群圈選。人群圈選過程在5s內(nèi)完成，整體圈人在2min左右。（待提升中介紹）人群分析。人群分析過程在5min內(nèi)完成。05

待提升（1）功能擴(kuò)展缺乏定制的人群擴(kuò)散能力。多業(yè)務(wù)場(chǎng)景對(duì)已有人群進(jìn)行擴(kuò)散有復(fù)雜且多樣的需求。缺乏用戶人群染色，無法再多個(gè)環(huán)節(jié)完成用戶效果的回收和進(jìn)行后續(xù)的分析。

（2）性能提升當(dāng)前Doris的行列轉(zhuǎn)換功能在建設(shè)中。在用戶畫像業(yè)務(wù)中，將用戶id更換為設(shè)備id，人群縮減（將具體人群包縮減為一個(gè)比較小的人群包用于后續(xù)運(yùn)營(yíng)動(dòng)作）過程是通過業(yè)務(wù)代碼實(shí)現(xiàn)的，降低了性能。>>

后續(xù)結(jié)果由行列轉(zhuǎn)換后，用戶畫像結(jié)果處理流程中會(huì)將設(shè)備id獲取方式通過join維度表來實(shí)現(xiàn)，人群縮減通過orderbyrandlimit來實(shí)現(xiàn)，會(huì)有比較明顯的性能提升。當(dāng)前Doris的讀取bitmap功能在建設(shè)中。業(yè)務(wù)代碼無法讀取到bitmap，只能先通過bitmap_to_string方法讀取到轉(zhuǎn)換為文本的bitmap，加大了傳輸量，降低了圈選性能。>>

后續(xù)可以直接讀取bitmap后，業(yè)務(wù)邏輯中會(huì)替換為直接獲取bitmap，會(huì)極大程度的減少數(shù)據(jù)傳輸量，同時(shí)業(yè)務(wù)邏輯可以針對(duì)性緩存。針對(duì)人群預(yù)估邏輯，當(dāng)前是通過例如bitmap_count(bitmap_and)兩個(gè)函數(shù)完成的，后續(xù)Doris會(huì)提供bitmap_and_count合并為一個(gè)函數(shù)，替換后可提升計(jì)算效率。

3.4工具層建設(shè)經(jīng)驗(yàn)分享3.4.1數(shù)據(jù)集成01

業(yè)務(wù)場(chǎng)景“巧婦難為無米之炊”，沒有數(shù)據(jù)也就沒有后面的一切，數(shù)據(jù)采集作為基礎(chǔ)至關(guān)重要。Doris數(shù)據(jù)倉庫自帶的多種數(shù)據(jù)導(dǎo)入方式對(duì)于數(shù)據(jù)入倉非常便利，但是在我們的使用過程中也遇到了一些問題。比如：（1）在從離線數(shù)倉進(jìn)行brokerload的時(shí)候數(shù)據(jù)依賴丟失，上游數(shù)據(jù)錯(cuò)誤無法評(píng)估受影響的范圍。（2）需要編寫冗長(zhǎng)的etl處理邏輯代碼，小的操作變更流程很長(zhǎng)，需要全流程（至少30分鐘）的上線操作；此外每次部署操作還有可能遇到各種初始化MQ消費(fèi)者的問題（3）缺少運(yùn)行狀態(tài)監(jiān)控，出現(xiàn)異常問題無法在分鐘甚至小時(shí)級(jí)別的時(shí)間發(fā)現(xiàn)；（4）在線導(dǎo)入僅支持kafkajson，上游的pulsar、protobuf數(shù)據(jù)仍需要代碼開發(fā)進(jìn)行轉(zhuǎn)發(fā)，導(dǎo)致每次接入數(shù)據(jù)都需要轉(zhuǎn)換函數(shù)的開發(fā)以及同樣全流程的上線操作；（5）業(yè)務(wù)邏輯中，期望業(yè)務(wù)是什么樣，Doris中的數(shù)據(jù)就是什么樣，讓業(yè)務(wù)無感知。這種全增量同步期望被包住，而不是做很多配置或開發(fā)很多代碼來實(shí)現(xiàn)。02

解決方案在建設(shè)實(shí)時(shí)數(shù)據(jù)模型的過程中。需要依賴眾多業(yè)務(wù)的數(shù)據(jù)，同時(shí)需要針對(duì)數(shù)據(jù)逐層建設(shè)數(shù)據(jù)模型。摸索并搭建了實(shí)時(shí)數(shù)據(jù)集成系統(tǒng)和實(shí)時(shí)調(diào)度系統(tǒng)，并下沉到工具層。（1）實(shí)時(shí)數(shù)據(jù)集成。建設(shè)快速且自定義的配置，針對(duì)不同的數(shù)據(jù)源建設(shè)導(dǎo)入能力。（2）與Doris的BrokerLoad和RoutineLoad進(jìn)行配合，在此基礎(chǔ)上搭建針對(duì)業(yè)務(wù)的全增量同步。（3）封裝集成能力對(duì)內(nèi)部暴露的接口，業(yè)務(wù)層無需理解中間過程，只選擇同步的數(shù)據(jù)庫和數(shù)據(jù)表即可進(jìn)行實(shí)時(shí)同步。

03

效果（1）同步配置（2）同步任務(wù)

（3）上線前早期使用Doris開發(fā)實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)過程中，由于需要某個(gè)數(shù)據(jù)全/增量同步，同時(shí)進(jìn)行數(shù)據(jù)轉(zhuǎn)換。需要建Doris數(shù)據(jù)模型，完成全量數(shù)據(jù)導(dǎo)入，建設(shè)增量數(shù)據(jù)ETL和RoutineLoad等開發(fā)，需要1名工程師1天才能將一張表接入到Doris中并進(jìn)行全增量實(shí)時(shí)同步。中間鏈路多，缺乏報(bào)警，針對(duì)重要的鏈路，建設(shè)打點(diǎn)和報(bào)警成本高，需要0.5天左右。全量：原始數(shù)據(jù)庫TiDB->中間部分（DataX）->Doris增量：原始數(shù)據(jù)庫TiDB->TiCDC->CanalBinlogKafka->ETL（填充數(shù)據(jù)）->Kafka->RoutineLoad->Doris（4）上線后僅需要10min的配置，數(shù)據(jù)集成包含模型，數(shù)據(jù)導(dǎo)入及中間ETL的轉(zhuǎn)化和額外數(shù)據(jù)補(bǔ)充以及RoutineLoad全部建好。業(yè)務(wù)層無需感知數(shù)據(jù)中間鏈路，僅需要描述我期望那個(gè)表被同步。上線后無需業(yè)務(wù)關(guān)心，完成第一步配置后，后續(xù)的監(jiān)控和報(bào)警以及一致性，集成全面解決。

3.4.2數(shù)據(jù)調(diào)度01

業(yè)務(wù)場(chǎng)景我們?cè)诔跗谕ㄟ^Doris建設(shè)實(shí)時(shí)數(shù)據(jù)的過程中，是通過RoutineLoad后的數(shù)據(jù)，再定時(shí)任務(wù)執(zhí)行后續(xù)計(jì)算邏輯，后再將計(jì)算結(jié)果導(dǎo)出到承載存儲(chǔ)，如Redis、Zetta（知乎自研HBase協(xié)議）中完成外部壓力承載。在這個(gè)過程中遇到了如下問題：（1）依賴未就緒后續(xù)任務(wù)就執(zhí)行。如最近24小時(shí)的曝光，在15:05運(yùn)行昨日15:00至今日15:00的查詢。此時(shí)如果RoutineLoad僅導(dǎo)入到14:50的數(shù)據(jù)，這次執(zhí)行結(jié)果異常；（2）Doris資源有限，但很多任務(wù)都是某些整點(diǎn)整分鐘的，一次性大量的計(jì)算任務(wù)造成集群崩潰；（3）任務(wù)是否執(zhí)行成功，任務(wù)是否延遲，是否影響到業(yè)務(wù)，無報(bào)警無反饋；（4）

導(dǎo)出存儲(chǔ)過程通用，重復(fù)代碼開發(fā)，每次都需要0.5-1人天的時(shí)間開發(fā)寫入和業(yè)務(wù)接口。

02

解決方案（1）架構(gòu)圖

（2）流程圖

03

效果（1）同步任務(wù)（2）收益建立任務(wù)依賴機(jī)制，通過kafka的offset和前置表是否完成計(jì)算，判斷當(dāng)前計(jì)算任務(wù)能否執(zhí)行。后續(xù)再也沒有出現(xiàn)過數(shù)據(jù)還未導(dǎo)入就先開始進(jìn)行數(shù)據(jù)計(jì)算的情況。通過退讓策略，監(jiān)控當(dāng)前Doris指標(biāo)，在高負(fù)載情況下避免提交SQL。避峰趨谷，完成資源最大利用。后續(xù)通過這種方案，一定程度的避免了瞬時(shí)跑高整體集群的問題。全鏈路監(jiān)控任務(wù)執(zhí)行情況，和延遲情況，一旦延遲報(bào)警，及時(shí)溝通解決和恢復(fù)業(yè)務(wù)。一旦任務(wù)延遲，監(jiān)控可非常快速的發(fā)現(xiàn)相關(guān)問題，多數(shù)情況能在業(yè)務(wù)可接受范圍內(nèi)完成恢復(fù)。上線后，原先需要1天的工程能力開發(fā)時(shí)間降低至0。只需要在Doris中有一個(gè)可查詢的SQL，經(jīng)過簡(jiǎn)單配置即可完成一定時(shí)間交付給業(yè)務(wù)相關(guān)數(shù)據(jù)、排行榜的需求。3.4.3數(shù)據(jù)質(zhì)量01

業(yè)務(wù)場(chǎng)景數(shù)據(jù)，已經(jīng)成為互聯(lián)網(wǎng)企業(yè)非常依賴的重要資產(chǎn)。數(shù)據(jù)質(zhì)量的好壞直接關(guān)系到信息的精準(zhǔn)度，也影響到企業(yè)的生存和競(jìng)爭(zhēng)力。MichaelHammer（《ReengineeringtheCorporation》一書的作者）曾說過，看起來不起眼的數(shù)據(jù)質(zhì)量問題，實(shí)際上是拆散業(yè)務(wù)流程的重要標(biāo)志。數(shù)據(jù)質(zhì)量管理是測(cè)度、提高和驗(yàn)證質(zhì)量，以及整合組織數(shù)據(jù)的方法等一套處理準(zhǔn)則，而體量大、速度快和多樣性的特點(diǎn)，決定了大數(shù)據(jù)質(zhì)量所需的處理，有別于傳統(tǒng)信息治理計(jì)劃的質(zhì)量管理方式。具體到針對(duì)知乎的各個(gè)業(yè)務(wù)：AI平臺(tái)、增長(zhǎng)團(tuán)隊(duì)、內(nèi)容平臺(tái)等已經(jīng)將部分或全部業(yè)務(wù)漸漸遷移到實(shí)時(shí)計(jì)算平臺(tái)，在接入數(shù)據(jù)更實(shí)時(shí)，更迅速的接入帶來的所享受的收益外，數(shù)據(jù)質(zhì)量更加變得重要。

（1）完整性:

數(shù)據(jù)完整性問題包括：模型設(shè)計(jì)不完整，例如：唯一性約束不完整、參照不完整；數(shù)據(jù)條目不完整，例如：數(shù)據(jù)記錄丟失或不可用；數(shù)據(jù)屬性不完整，例如：數(shù)據(jù)屬性空值。不完整的數(shù)據(jù)所能借鑒的價(jià)值就會(huì)大大降低，也是數(shù)據(jù)質(zhì)量問題最為基礎(chǔ)和常見的一類問題；（2）一致性:

多源數(shù)據(jù)的數(shù)據(jù)模型不一致，例如：命名不一致、數(shù)據(jù)結(jié)構(gòu)不一致、約束規(guī)則不一致。數(shù)據(jù)實(shí)體不一致，例如：數(shù)據(jù)編碼不一致、命名及含義不一致、分類層次不一致、生命周期不一致……相同的數(shù)據(jù)有多個(gè)副本的情況下的數(shù)據(jù)不一致、數(shù)據(jù)內(nèi)容沖突的問題；（3）準(zhǔn)確性:

準(zhǔn)確性也叫可靠性，是用于分析和識(shí)別哪些是不準(zhǔn)確的或無效的數(shù)據(jù)，不可靠的數(shù)據(jù)可能會(huì)導(dǎo)致嚴(yán)重的問題，會(huì)造成有缺陷的方法和糟糕的決策；（4）唯一性:

用于識(shí)別和度量重復(fù)數(shù)據(jù)、冗余數(shù)據(jù)。重復(fù)數(shù)據(jù)是導(dǎo)致業(yè)務(wù)無法協(xié)同、流程無法追溯的重要因素，也是數(shù)據(jù)治理需要解決的最基本的數(shù)據(jù)問題；（5）關(guān)聯(lián)性:

數(shù)據(jù)關(guān)聯(lián)性問題是指存在數(shù)據(jù)關(guān)聯(lián)的數(shù)據(jù)關(guān)系缺失或錯(cuò)誤，例如：函數(shù)關(guān)系、相關(guān)系數(shù)、主外鍵關(guān)系、索引關(guān)系等。存在數(shù)據(jù)關(guān)聯(lián)性問題，會(huì)直接影響數(shù)據(jù)分析的結(jié)果，進(jìn)而影響管理決策；（6）真實(shí)性:

數(shù)據(jù)必須真實(shí)準(zhǔn)確的反映客觀的實(shí)體存在或真實(shí)的業(yè)務(wù)，真實(shí)可靠的原始統(tǒng)計(jì)數(shù)據(jù)是企業(yè)統(tǒng)計(jì)工作的靈魂，是一切管理工作的基礎(chǔ)，是經(jīng)營(yíng)者進(jìn)行正確經(jīng)營(yíng)決策必不可少的第一手資料；（7）及時(shí)性:

數(shù)據(jù)的及時(shí)性是指能否在需要的時(shí)候獲到數(shù)據(jù)，數(shù)據(jù)的及時(shí)性與企業(yè)的數(shù)據(jù)處理速度及效率有直接的關(guān)系，是影響業(yè)務(wù)處理和管理效率的關(guān)鍵指標(biāo)。02

解決方案（1）全流程的數(shù)據(jù)鏈路和各級(jí)質(zhì)量保證方法

（2）業(yè)務(wù)架構(gòu)

（3）業(yè)務(wù)流程

03效果（1）某業(yè)務(wù)健康情況監(jiān)控以通過DQC監(jiān)控的某一個(gè)業(yè)務(wù)的健康情況，該業(yè)務(wù)由多個(gè)導(dǎo)出任務(wù)和中間計(jì)算任務(wù)及部分?jǐn)?shù)據(jù)源組成，當(dāng)前情況是一切正常。期間如果出現(xiàn)某節(jié)點(diǎn)任意異常后，都可及時(shí)發(fā)現(xiàn)。

（2）某任務(wù)中間邏輯監(jiān)控

該任務(wù)中間計(jì)算中其中部分規(guī)則未達(dá)標(biāo)，導(dǎo)致該任務(wù)未通過。04

收益（1）上線前早期無類似DQC系統(tǒng)保證的前提下，我們很多問題都是天級(jí)別甚至上線后，才發(fā)現(xiàn)存在數(shù)據(jù)異常，出現(xiàn)過3次問題，造成的返工和交付不靠譜的情況，對(duì)業(yè)務(wù)影響巨大。早期開發(fā)中，在開發(fā)過程需要不斷針對(duì)各種細(xì)節(jié)規(guī)則進(jìn)行比對(duì)，總會(huì)花費(fèi)一定時(shí)間逐層校驗(yàn)，成本巨大。（2）上線后在上線1個(gè)月內(nèi)，通過DQC系統(tǒng)規(guī)則，當(dāng)前已發(fā)現(xiàn)了14個(gè)錯(cuò)異常，在1-2h左右發(fā)現(xiàn)，立即修復(fù)。對(duì)業(yè)務(wù)的影響降低到最小。在系統(tǒng)上線后，在開發(fā)過程中，開發(fā)完相關(guān)數(shù)據(jù)，如有異常，就產(chǎn)生了異常報(bào)警，大幅節(jié)省了人工發(fā)現(xiàn)的成本，因?yàn)樾迯?fù)時(shí)間早，在后續(xù)開發(fā)啟動(dòng)前，就已經(jīng)修復(fù)，極大程度降低開發(fā)過程中的返工成本。04總結(jié)和展望4.1收益總結(jié)4.1.1業(yè)務(wù)發(fā)展方面

01

針對(duì)實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)提供了基于時(shí)效性的熱點(diǎn)、潛力的把控。加速業(yè)務(wù)在生產(chǎn)、消費(fèi)方面的使用，進(jìn)而提升優(yōu)質(zhì)創(chuàng)作量及用戶對(duì)內(nèi)容消費(fèi)能力。同時(shí)提供了提供實(shí)時(shí)的復(fù)雜計(jì)算的外顯指標(biāo)，加強(qiáng)用戶體驗(yàn)，下線了業(yè)務(wù)后端通過腳