10000字詳解用戶畫像與實時數(shù)倉之架構(gòu)與實踐

• 應(yīng)用層：負責(zé)當(dāng)前我們的業(yè)務(wù)應(yīng)用，直接為業(yè)務(wù)提供工具或提供業(yè)務(wù)的某些模塊，與業(yè)務(wù)共擔(dān)目標，為業(yè)務(wù)賦能。

• 業(yè)務(wù)模型層：支持應(yīng)用層建設(shè)和一定的實時分析能力，同時也作為業(yè)務(wù)某一個流程的功能模塊接入使用，為外部業(yè)務(wù)和自身應(yīng)用層建設(shè)，與業(yè)務(wù)共擔(dān)目標，為業(yè)務(wù)賦能。

• 業(yè)務(wù)工具層：支持應(yīng)用層和業(yè)務(wù)模型層的開發(fā)，提供通用的工具，面向降低應(yīng)用層和業(yè)務(wù)模型層的建設(shè)成本，提升整體建設(shè)的工程效能，保證業(yè)務(wù)穩(wěn)定和數(shù)據(jù)質(zhì)量準確。

• 基礎(chǔ)設(shè)施：技術(shù)中臺提供的基礎(chǔ)設(shè)施和云服務(wù)，提供穩(wěn)定可用的基礎(chǔ)功能，保證上層建筑的穩(wěn)定性。
  
  

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

（1）實時業(yè)務(wù)數(shù)據(jù)。

• 通過提供實時的業(yè)務(wù)指標，解決業(yè)務(wù)對熱點、潛力的把控，助力生產(chǎn)、消費，提 升優(yōu)質(zhì)創(chuàng)作量及內(nèi)容消費能力。

• 提供實時的復(fù)雜計算的外顯指標，加強用戶體驗，解決業(yè)務(wù)側(cè)通過后端腳本計算的高維護成本和復(fù)雜性，節(jié)約成本，提升人效。

（2）實時算法特征。

• 以實時數(shù)據(jù)為基礎(chǔ)，提供多樣的實時算法特征，與推薦算法團隊共同提升 DAU、留存、用戶付費等核心指標。

02    面臨的困難

(1)    依賴數(shù)據(jù)源多，計算規(guī)則復(fù)雜。以我們的播放量計算為例：

• 行為有多條，需要針對行為進行去重。

• 過濾和加和規(guī)則很多，需要依賴多個數(shù)據(jù)源的不同數(shù)據(jù)結(jié)果進行計算。

  
  

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

• 需要調(diào)度系統(tǒng)中，同時能識別 kafka 流消費的進度和任務(wù)完成情況。

• 需要嚴格拉齊多個依賴的消費進度，當(dāng)達到統(tǒng)一進度后，集中進行后續(xù)任務(wù)計算。

• 數(shù)據(jù)倉庫：調(diào)度系統(tǒng)

• 通過建設(shè)實時數(shù)據(jù)集成和實時數(shù)據(jù)調(diào)度的能力，保障數(shù)據(jù)接入和數(shù)據(jù)模型建設(shè)的速度，降低接入時間，提升業(yè)務(wù)接入效率（具體見下方）

• 通過建設(shè)實時數(shù)據(jù)質(zhì)量中心，保障數(shù)據(jù)質(zhì)量，降低發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題的時間，提升發(fā)現(xiàn)效率，保證業(yè)務(wù)交付結(jié)果（具體見下方）
  
  

• 搭建寫入延遲、計算延遲等監(jiān)控，快速發(fā)現(xiàn)問題。
  

• Doris 集群進行參數(shù)變更，調(diào)整批量寫入的數(shù)據(jù)量、時間和頻率等進行優(yōu)化。
• 當(dāng)前我們的 Load 主要有 Broker Load 和 Routine Load。其中時效性要求高的是 Routine Load。我們針對性的進行了參數(shù)調(diào)整。
• Doris 增加了 Runtime Filter，通過 BloomFilter 提升 Join 性能。
• Doris 集群在 0.14 版本中加入了 Runtime Filter 的過濾，針對 Join 大量 key 被過濾的情況有明顯提升；
• 該變更針對我們當(dāng)前的幾個業(yè)務(wù)調(diào)度性能，有明顯提升。時間從 40+s 提升至 10s 左右；
  
  
  

（1）用戶檢索。
重點在于快速完成人群包圈選同時在圈選條件變更過程中，需要快速計算出預(yù)計能圈的用戶有哪些？

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

（1）數(shù)據(jù)規(guī)模大。
我們當(dāng)前是 200+ 個標簽，每個標簽均有不同的枚舉值，總計有 300+ 萬的 tag。tag 對用戶的打標量級在 900+ 億條記錄。由于標簽每日更新導(dǎo)入量級十分大。

（2）篩選響應(yīng)時間要求高。

（3）人群包除了 long 類型的用戶 id 外，還需要有多種不同的設(shè)備 id 和設(shè)備 id  md5 作為篩選結(jié)果。

（4）用戶分析場景下，針對 300+ 萬 tag 的多人群交叉 TGI 計算，需要在 10min 內(nèi)完成。

（2）DMP 業(yè)務(wù)流程：

（3）性能問題針對性解決；數(shù)據(jù)規(guī)模大，提升導(dǎo)入性能，分而治之。

• 數(shù)據(jù)模型變更，拆分文件。

• Doris 的存儲是按照 Tablet 分散在集群上的。通過調(diào)整數(shù)據(jù)模型，確保分布均勻及每個文件盡可能的小。

• 導(dǎo)入變更，拆分導(dǎo)入。

• 由于每個 Broker Load 導(dǎo)入都是有性能瓶頸的，將 900+ 億行數(shù)據(jù)，拆分為 1000+ 個 Broker Load 的導(dǎo)入任務(wù)，確保每個導(dǎo)入總量都足夠小。
  
  

（4）提升人群篩選和人群分析的計算速度，分而治之。

• 業(yè)務(wù)邏輯變更，拆分用戶。

• 將用戶每 0 ～ 100 萬拆分為一組。

• 針對全部用戶的交并差，等價于對所有組用戶交并差后的并集。

• 針對全部用戶的交并差的總數(shù)，等價于對分組用戶交并差后的總數(shù)進行 sum。

• 數(shù)據(jù)模型變更，拆分文件。

• 設(shè)置 bitmap 的分組參數(shù)，將分組設(shè)置為 colocate group。確保每個分組的交并差計算均在自己所在 BE 完成，無需 shuffle。

• 將 bitmap 表的分桶拆分更多，通過更多文件同時計算加速結(jié)果。

• 計算參數(shù)變更，提升并發(fā)。

• 由于計算過程通過分治的手段，拆分為多個小任務(wù)。通過提升并行度 parallel_fragment_exec_instance_num 再進一步優(yōu)化計算速度。

上線后，接入了知乎多個主要場景的業(yè)務(wù)，支持多業(yè)務(wù)方的人群定向和分析能力。為業(yè)務(wù)帶來曝光量、轉(zhuǎn)化率等直接指標的提升。

同時在工具性能上，有如下表現(xiàn)：

• 導(dǎo)入速度。當(dāng)前每日 900+ 億行數(shù)據(jù)，在 3 小時內(nèi)完成導(dǎo)入。

• 人群預(yù)估。人群預(yù)估基本可在 1s 內(nèi)完成，P95 985ms。

• 人群圈選。人群圈選過程在 5s 內(nèi)完成，整體圈人在 2min 左右。（待提升中介紹）

• 人群分析。人群分析過程在 5min 內(nèi)完成。

• 缺乏定制的人群擴散能力。多業(yè)務(wù)場景對已有人群進行擴散有復(fù)雜且多樣的需求。

• 缺乏用戶人群染色，無法再多個環(huán)節(jié)完成用戶效果的回收和進行后續(xù)的分析。
  
  

（2）性能提升

• 當(dāng)前 Doris 的行列轉(zhuǎn)換功能在建設(shè)中。在用戶畫像業(yè)務(wù)中，將用戶 id 更換為設(shè)備 id，人群縮減（將具體人群包縮減為一個比較小的人群包用于后續(xù)運營動作）過程是通過業(yè)務(wù)代碼實現(xiàn)的，降低了性能。
  
>>    后續(xù)結(jié)果由行列轉(zhuǎn)換后，用戶畫像結(jié)果處理流程中會將設(shè)備 id 獲取方式通過 join 維度表來實現(xiàn)，人群縮減通過 order by rand limit 來實現(xiàn)，會有比較明顯的性能提升。

• 當(dāng)前 Doris 的讀取 bitmap 功能在建設(shè)中。業(yè)務(wù)代碼無法讀取到 bitmap，只能先通過 bitmap_to_string 方法讀取到轉(zhuǎn)換為文本的 bitmap，加大了傳輸量，降低了圈選性能。
  
>>    后續(xù)可以直接讀取 bitmap 后，業(yè)務(wù)邏輯中會替換為直接獲取 bitmap，會極大程度的減少數(shù)據(jù)傳輸量，同時業(yè)務(wù)邏輯可以針對性緩存。
• 針對人群預(yù)估邏輯，當(dāng)前是通過例如 bitmap_count(bitmap_and) 兩個函數(shù)完成的，后續(xù) Doris 會提供 bitmap_and_count 合并為一個函數(shù)，替換后可提升計算效率。

    3.4 工具層建設(shè)經(jīng)驗分享

3.4.1 數(shù)據(jù)集成

01    業(yè)務(wù)場景

• 早期使用 Doris 開發(fā)實時數(shù)據(jù)業(yè)務(wù)過程中，由于需要某個數(shù)據(jù)全/增量同步，同時進行數(shù)據(jù)轉(zhuǎn)換。需要建 Doris 數(shù)據(jù)模型，完成全量數(shù)據(jù)導(dǎo)入，建設(shè)增量數(shù)據(jù) ETL 和 Routine Load 等開發(fā)，需要 1 名工程師 1 天才能將一張表接入到 Doris 中并進行全增量實時同步。

• 中間鏈路多，缺乏報警，針對重要的鏈路，建設(shè)打點和報警成本高，需要 0.5 天左右。

• 全量：原始數(shù)據(jù)庫 TiDB -> 中間部分（DataX）-> Doris

• 增量：原始數(shù)據(jù)庫 TiDB -> TiCDC -> Canal Binlog Kafka -> ETL（填充數(shù)據(jù)）-> Kafka -> Routine Load -> Doris

• 僅需要 10min 的配置，數(shù)據(jù)集成包含模型，數(shù)據(jù)導(dǎo)入及中間 ETL 的轉(zhuǎn)化和額外數(shù)據(jù)補充以及 Routine Load 全部建好。業(yè)務(wù)層無需感知數(shù)據(jù)中間鏈路，僅需要描述我期望那個表被同步。

• 上線后無需業(yè)務(wù)關(guān)心，完成第一步配置后，后續(xù)的監(jiān)控和報警以及一致性，集成全面解決。

我們在初期通過 Doris 建設(shè)實時數(shù)據(jù)的過程中，是通過 Routine Load 后的數(shù)據(jù)，再定時任務(wù)執(zhí)行后續(xù)計算邏輯，后再將計算結(jié)果導(dǎo)出到承載存儲，如 Redis、Zetta（知乎自研 HBase 協(xié)議） 中完成外部壓力承載。在這個過程中遇到了如下問題：

（1）依賴未就緒后續(xù)任務(wù)就執(zhí)行。如最近 24 小時的曝光，在 15:05 運行昨日 15:00至今日 15:00 的查詢。此時如果 Routine Load 僅導(dǎo)入到 14:50 的數(shù)據(jù)，這次執(zhí)行結(jié)果異常；

（2）Doris 資源有限，但很多任務(wù)都是某些整點整分鐘的，一次性大量的計算任務(wù)造成集群崩潰；

（3） 任務(wù)是否執(zhí)行成功，任務(wù)是否延遲，是否影響到業(yè)務(wù)，無報警無反饋；

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

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

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

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

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

（4）唯一性: 
用于識別和度量重復(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)系缺失或錯誤，例如：函數(shù)關(guān)系、相關(guān)系數(shù)、主外鍵關(guān)系、索引關(guān)系等。存在數(shù)據(jù)關(guān)聯(lián)性問題，會直接影響數(shù)據(jù)分析的結(jié)果，進而影響管理決策；

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

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

03    效果

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

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

• 早期無類似 DQC 系統(tǒng)保證的前提下，我們很多問題都是天級別甚至上線后，才發(fā)現(xiàn)存在數(shù)據(jù)異常，出現(xiàn)過 3 次問題，造成的返工和交付不靠譜的情況，對業(yè)務(wù)影響巨大。
• 早期開發(fā)中，在開發(fā)過程需要不斷針對各種細節(jié)規(guī)則進行比對，總會花費一定時間逐層校驗，成本巨大。
  

（2）上線后

• 在上線 1 個月內(nèi)，通過 DQC 系統(tǒng)規(guī)則，當(dāng)前已發(fā)現(xiàn)了 14 個錯異常，在 1 - 2h 左右發(fā)現(xiàn)，立即修復(fù)。對業(yè)務(wù)的影響降低到最小。

• 在系統(tǒng)上線后，在開發(fā)過程中，開發(fā)完相關(guān)數(shù)據(jù)，如有異常，就產(chǎn)生了異常報警，大幅節(jié)省了人工發(fā)現(xiàn)的成本，因為修復(fù)時間早，在后續(xù)開發(fā)啟動前，就已經(jīng)修復(fù)，極大程度降低開發(fā)過程中的返工成本。

  
  

• 提供了基于時效性的熱點、潛力的把控。加速業(yè)務(wù)在生產(chǎn)、消費方面的使用，進而提升優(yōu)質(zhì)創(chuàng)作量及用戶對內(nèi)容消費能力。
• 同時提供了提供實時的復(fù)雜計算的外顯指標，加強用戶體驗，下線了業(yè)務(wù)后端通過腳本計算指標的方法，降低了業(yè)務(wù)的復(fù)雜性，節(jié)約了成本，提升人效。

• 提供了基于創(chuàng)作者、內(nèi)容、消費者的實時算法特征，與算法團隊共同在多個項目中，針對 DAU、留存、用戶付費等核心指標有了明顯的提升。
  
  

• 完善和升級用戶篩選，做到多維、多類型的定向篩選，并接入了運營平臺、營銷平臺等系統(tǒng)，提高了業(yè)務(wù)效率，降低了業(yè)務(wù)人員進行人群定向的成本。
• 搭建和完善用戶分析，做到多角度用戶分析，定向用戶分析報告 0 成本，助力業(yè)務(wù)部門快速把握核心客戶市場。

4.1.2 工具建設(shè)方面

• 完成了實時數(shù)據(jù)領(lǐng)域和用戶領(lǐng)域的布局，建設(shè)了相關(guān)的開發(fā)和維護工具，解決了先前在此方面無基礎(chǔ)設(shè)施，無業(yè)務(wù)工具，開發(fā)成本高的問題。

• 搭建了集成、調(diào)度、質(zhì)量系統(tǒng)。通過工具的方式降低了業(yè)務(wù)發(fā)展和迭代的成本，讓業(yè)務(wù)快速發(fā)展，同時也保證了交付質(zhì)量提高了業(yè)務(wù)基線。
  
  

4.1.3 人員組織方面

• 自上而下的拆分了實時數(shù)據(jù)和用戶畫像的能力，分為應(yīng)用層、業(yè)務(wù)模型層、業(yè)務(wù)工具層和基礎(chǔ)設(shè)施層。通過組織劃分，明確了不同層次的邊界和加速了業(yè)務(wù)目標的達成。

• 搭建并完善了多層次團隊人員梯隊。根據(jù)針對不同方向的同學(xué)，給予不同的 OKR 目標，做到跨層次方向隔離，同層次方向一致，同模塊目標一致。共同為整體實時數(shù)據(jù)與用戶畫像服務(wù)建設(shè)而努力。

• 強化基礎(chǔ)能力工具層的建設(shè)，持續(xù)降低基于實時數(shù)據(jù)方面的建設(shè)、交付成本。

• 提升數(shù)據(jù)質(zhì)量工具覆蓋能力，為業(yè)務(wù)模型提供質(zhì)量保障，并提供基于實時數(shù)據(jù)的畫像質(zhì)量保障能力。

• 基于當(dāng)前業(yè)務(wù)訴求，部分場景針對 5 分鐘級實時無法滿足，進一步探索秒級別復(fù)雜情況實時能力，并提供能力支持。
  
  

• 加強并針對用戶畫像、用戶理解、用戶洞察 & 模型等進一步建設(shè)。通過與具體業(yè)務(wù)結(jié)合，建設(shè)貼合業(yè)務(wù)場景的用戶理解成果和相應(yīng)的分析能力，找到業(yè)務(wù)的留存點。

• 進一步加強新的工具能力的建設(shè)，通過建設(shè)用戶理解工具、用戶分析工具，降低產(chǎn)生理解及對業(yè)務(wù)分析的成本，提升業(yè)務(wù)效率，快速發(fā)現(xiàn)業(yè)務(wù)價值。

推薦閱讀：

世界的真實格局分析，地球人類社會底層運行原理

不是你需要中臺，而是一名合格的架構(gòu)師（附各大廠中臺建設(shè)PPT）

企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案

論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么，如何轉(zhuǎn)？

華為干部與人才發(fā)展手冊（附PPT）

企業(yè)10大管理流程圖，數(shù)字化轉(zhuǎn)型從業(yè)者必備！

【中臺實踐】華為大數(shù)據(jù)中臺架構(gòu)分享.pdf

華為的數(shù)字化轉(zhuǎn)型方法論

華為如何實施數(shù)字化轉(zhuǎn)型（附PPT）

超詳細280頁Docker實戰(zhàn)文檔！開放下載

華為大數(shù)據(jù)解決方案（PPT）