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

一、前言

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

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

拆分當前業(yè)務主要在實時數(shù)據(jù)和用戶畫像兩大部分有難點，共包含如下的三個方向目標：

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

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

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

2）實時算法特征

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

3）用戶畫像

• 用戶篩選，做到多維、多類型的定向篩選，并接入營銷、廣告、 運營平臺等系統(tǒng)，提高業(yè)務效率，降低人員成本。

• 用戶分析，做到多角度用戶分析，定向用戶分析報告 0 成本，助力業(yè)務部門快速把握核心客戶市場。

本文就知乎平臺的數(shù)據(jù)賦能團隊，基于以上三個方向的目標，就這四個問題，來逐一介紹這方面的技術實踐經(jīng)驗和心得體會：

• 如何通過實時數(shù)據(jù)驅動業(yè)務發(fā)展？

• 如何從 0 -> 1 搭建實時數(shù)據(jù)中心？

• 如何搭建一套高效快速的用戶畫像系統(tǒng)來解決歷史系統(tǒng)的多種問題？

• 如何快速高效的開發(fā)業(yè)務功能和保證業(yè)務質量？

?1、名詞解釋

?2、實時數(shù)據(jù)與用戶畫像與各業(yè)務的結合

二、面臨的挑戰(zhàn)和痛點

針對當前業(yè)務目標，主要有以下幾個具體要求。

?1、有價值

1）如何通過實效性發(fā)現(xiàn)業(yè)務價值？

• 搭建熱點、潛力等緊隨時間的指標和相關的排行榜，直接支持業(yè)務發(fā)展。

2）如何讓用戶畫像的篩選和分析能力最大化？

• 要全面覆蓋多維度用戶篩選的多種需求。
• 多角度、多方式覆蓋用戶分析。

?2、數(shù)據(jù)時效性

1）推薦頁首屏瀏覽 6 條內容，如何在第二刷的時候就立即感知到最新的用戶行為？

• 通過 UBS 建設提升實效性（下面介紹）

2）在推薦算法中，非常實時的特征推薦算法效果要比天級別更新特征的算法效果好很多，如何保證 10 分鐘內算法受到特征變更？

• 通過實時數(shù)據(jù)系統(tǒng)與 Apache Doris配合共同建設，提升到 10 分鐘內更新（下面介紹）

?3、接口實時性

熱點運營場景，期望用戶畫像服務能在秒級別快速篩選出大量人群，用戶后續(xù)的推送等運營場景，如何解決？

• 通過用戶畫像系統(tǒng)與 Apache Doris 配合共同建設，提升人群篩選的速度（下面介紹）

?4、復雜性

1）實時數(shù)據(jù)幾乎沒有 count、sum 需求。幾乎都是復雜去重和多數(shù)據(jù)聯(lián)合計算的情況。

• 以播放量為例。在啟播、暫停、完播、心跳等多個條件下，會同時有多個點，要進行去重。同時基于視頻回答、視頻的關系和雙作者聯(lián)合創(chuàng)作的關系，需要疊加，同時保證在父子內容異常狀態(tài)的情況下過濾其中部分播放行為。

2）人群分析業(yè)務，期望多角度、各維度進行人群關聯(lián)計算，同時基于全部用戶特征針對當前人群和對比人群進行 TGI 計算，篩選出顯著特征，如何解決？

• 通過用戶畫像系統(tǒng)與 Apache Doris 配合共同建設，解決復雜的人群分析（下面介紹）

3）業(yè)務數(shù)據(jù)中有增 / 刪 / 改邏輯，如何實時同步？

• 實時數(shù)據(jù)集成系統(tǒng)與 Apache Doris 配合共同建設，解決增 / 刪 / 改邏輯（下面介紹）

4）明細數(shù)據(jù)異常發(fā)現(xiàn)滯后，異常發(fā)現(xiàn)后，需要針對性修正構建方式，及回溯數(shù)據(jù)修復，如何解決？

• 通過選擇 Lambda 架構作為數(shù)據(jù)架構解決（下面介紹）

三、實踐及經(jīng)驗分享

?1、整體業(yè)務架構

基于當前的業(yè)務，從頂層至底層進行了拆分。主要分為應用層、業(yè)務模型層、業(yè)務工具層、基礎設施層。基于我們當前的業(yè)務形態(tài)，自上而下。

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

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

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

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

?2、實時數(shù)據(jù)的數(shù)據(jù)架構選型

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

?3、應用層建設經(jīng)驗分享

1）實時數(shù)據(jù)系統(tǒng)?

①業(yè)務場景?

實時數(shù)據(jù)系統(tǒng)主要有兩個大方向：實時業(yè)務數(shù)據(jù)和實時算法特征。

• 實時業(yè)務數(shù)據(jù)

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

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

• 實時算法特征

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

②面臨的困難?

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

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

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

• 時間敏感性高

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

• 調度過程中協(xié)調成本高

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

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

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

③解決方案?

• 搭建實時數(shù)據(jù)基座，建設相應的數(shù)據(jù)模型，降低建設成本。

• 針對依賴數(shù)據(jù)眾多、計算規(guī)則復雜、質量難以保證等問題。通過建設工具降低解決問題的成本。

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

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

• 時間敏感性高，加強監(jiān)控、與 Doris 集群共同提升吞吐效率和計算效率：

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

• Doris 集群進行參數(shù)變更，調整批量寫入的數(shù)據(jù)量、時間和頻率等進行優(yōu)化。

當前我們的 Load 主要有 Broker Load 和 Routine Load。其中時效性要求高的是 Routine Load。我們針對性的進行了參數(shù)調整。

• Doris 增加了 Runtime Filter，通過 BloomFilter 提升 Join 性能。

Doris 集群在 0.14 版本中加入了 Runtime Filter 的過濾，針對 Join 大量 key 被過濾的情況有明顯提升；該變更針對我們當前的幾個業(yè)務調度性能，有明顯提升。時間從 40+s 提升至 10s 左右。

2）用戶畫像系統(tǒng) DMP

①業(yè)務場景?

用戶畫像系統(tǒng)主要有兩大功能：用戶檢索和用戶分析。

• 用戶檢索。

重點在于快速完成人群包圈選同時在圈選條件變更過程中，需要快速計算出預計能圈的用戶有哪些？

• 用戶分析。

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

②面臨的困難

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

• 篩選響應時間要求高。針對簡單的篩選，要求在秒級別出結果，針對復雜的人群篩選，篩選后人群量大的情況，要求在 20s 內完成人群包生成。

• 人群包除了 long 類型的用戶 id 外，還需要有多種不同的設備 id 和設備 id  md5 作為篩選結果。

• 用戶分析場景下，針對 300+ 萬 tag 的多人群交叉 TGI 計算，需要在 10min 內完成。

③解決方案?

• DMP 業(yè)務架構

• DMP 業(yè)務流程

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

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

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

• 導入變更，拆分導入。

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

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

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

1. 將用戶每 0 ～ 100 萬拆分為一組。
2. 針對全部用戶的交并差，等價于對所有組用戶交并差后的并集。
3. 針對全部用戶的交并差的總數(shù)，等價于對分組用戶交并差后的總數(shù)進行 sum。

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

1. 設置 bitmap 的分組參數(shù)，將分組設置為 colocate group。確保每個分組的交并差計算均在自己所在 BE 完成，無需 shuffle。
2. 將 bitmap 表的分桶拆分更多，通過更多文件同時計算加速結果。

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

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

④效果 ?

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

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

• 導入速度。當前每日 900+ 億行數(shù)據(jù)，在 3 小時內完成導入。

• 人群預估。人群預估基本可在 1s 內完成，P95 985ms。

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

• 人群分析。人群分析過程在 5min 內完成。

⑤待提升?

• 功能擴展

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

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

• 性能提升

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

• 當前 Doris 的讀取 bitmap 功能在建設中。業(yè)務代碼無法讀取到 bitmap，只能先通過 bitmap_to_string 方法讀取到轉換為文本的 bitmap，加大了傳輸量，降低了圈選性能。后續(xù)可以直接讀取 bitmap 后，業(yè)務邏輯中會替換為直接獲取 bitmap，會極大程度的減少數(shù)據(jù)傳輸量，同時業(yè)務邏輯可以針對性緩存。

• 針對人群預估邏輯，當前是通過例如 bitmap_count(bitmap_and) 兩個函數(shù)完成的，后續(xù) Doris 會提供 bitmap_and_count 合并為一個函數(shù)，替換后可提升計算效率。

?4、工具層建設經(jīng)驗分享

1）數(shù)據(jù)集成

①業(yè)務場景?

“巧婦難為無米之炊”，沒有數(shù)據(jù)也就沒有后面的一切，數(shù)據(jù)采集作為基礎至關重要。Doris 數(shù)據(jù)倉庫自帶的多種數(shù)據(jù)導入方式 對于數(shù)據(jù)入倉非常便利，但是在我們的使用過程中也遇到了一些問題。比如：

• 在從離線數(shù)倉進行 broker load 的時候數(shù)據(jù)依賴丟失，上游數(shù)據(jù)錯誤無法評估受影響的范圍；

• 需要編寫冗長的 etl 處理邏輯代碼，小的操作變更流程很長，需要全流程（至少 30 分鐘）的上線操作；
• 此外每次部署操作還有可能遇到各種初始化 MQ 消費者的問題；

• 缺少運行狀態(tài)監(jiān)控，出現(xiàn)異常問題無法在分鐘甚至小時級別的時間發(fā)現(xiàn)；

• 在線導入僅支持 kafka json，上游的 pulsar、protobuf 數(shù)據(jù)仍需要代碼開發(fā)進行轉發(fā)，導致每次接入數(shù)據(jù)都需要轉換函數(shù)的開發(fā)以及同樣全流程的上線操作；

• 業(yè)務邏輯中，期望業(yè)務是什么樣，Doris 中的數(shù)據(jù)就是什么樣，讓業(yè)務無感知。這種全增量同步期望被包住，而不是做很多配置或開發(fā)很多代碼來實現(xiàn)。

②解決方案

在建設實時數(shù)據(jù)模型的過程中。需要依賴眾多業(yè)務的數(shù)據(jù)，同時需要針對數(shù)據(jù)逐層建設數(shù)據(jù)模型。摸索并搭建了實時數(shù)據(jù)集成系統(tǒng)和實時調度系統(tǒng)，并下沉到工具層。

• 實時數(shù)據(jù)集成。建設快速且自定義的配置，針對不同的數(shù)據(jù)源建設導入能力。

• 與 Doris 的 Broker Load 和 Routine Load 進行配合，在此基礎上搭建針對業(yè)務的全增量同步。

• 封裝集成能力對內部暴露的接口，業(yè)務層無需理解中間過程，只選擇同步的數(shù)據(jù)庫和數(shù)據(jù)表即可進行實時同步。

③效果?

• 同步配置

• 同步任務

• 上線前

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

• 中間鏈路多，缺乏報警，針對重要的鏈路，建設打點和報警成本高，需要 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ù)導入及中間 ETL 的轉化和額外數(shù)據(jù)補充以及 Routine Load 全部建好。業(yè)務層無需感知數(shù)據(jù)中間鏈路，僅需要描述我期望那個表被同步。

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

2）數(shù)據(jù)調度?

①業(yè)務場景

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

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

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

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

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

②解決方案?

• 架構圖

• 流程圖

③效果?

• 同步任務

• 收益

• 建立任務依賴機制，通過 kafka 的 offset 和前置表是否完成計算，判斷當前計算任務能否執(zhí)行。后續(xù)再也沒有出現(xiàn)過數(shù)據(jù)還未導入就先開始進行數(shù)據(jù)計算的情況。

• 通過退讓策略，監(jiān)控當前 Doris 指標，在高負載情況下避免提交 SQL。避峰趨谷，完成資源最大利用。后續(xù)通過這種方案，一定程度的避免了瞬時跑高整體集群的問題。

• 全鏈路監(jiān)控任務執(zhí)行情況，和延遲情況，一旦延遲報警，及時溝通解決和恢復業(yè)務。一旦任務延遲，監(jiān)控可非?？焖俚陌l(fā)現(xiàn)相關問題，多數(shù)情況能在業(yè)務可接受范圍內完成恢復。

• 上線后，原先需要 1 天的工程能力開發(fā)時間降低至 0。只需要在 Doris 中有一個可查詢的 SQL，經(jīng)過簡單配置即可完成一定時間交付給業(yè)務相關數(shù)據(jù)、排行榜的需求。

3） 數(shù)據(jù)質量

①業(yè)務場景?

數(shù)據(jù)，已經(jīng)成為互聯(lián)網(wǎng)企業(yè)非常依賴的重要資產。數(shù)據(jù)質量的好壞直接關系到信息的精準度，也影響到企業(yè)的生存和競爭力。Michael Hammer（《Reengineering the Corporation》一書的作者）曾說過，看起來不起眼的數(shù)據(jù)質量問題，實際上是拆散業(yè)務流程的重要標志。數(shù)據(jù)質量管理是測度、提高和驗證質量，以及整合組織數(shù)據(jù)的方法等一套處理準則，而體量大、速度快和多樣性的特點，決定了大數(shù)據(jù)質量所需的處理，有別于傳統(tǒng)信息治理計劃的質量管理方式。

具體到針對知乎的各個業(yè)務：

AI平臺、增長團隊、內容平臺等已經(jīng)將部分或全部業(yè)務漸漸遷移到實時計算平臺，在接入數(shù)據(jù)更實時，更迅速的接入帶來的所享受的收益外，數(shù)據(jù)質量更加變得重要。

• 完整性

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

• 一致性

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

• 準確性

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

• 唯一性

用于識別和度量重復數(shù)據(jù)、冗余數(shù)據(jù)。重復數(shù)據(jù)是導致業(yè)務無法協(xié)同、流程無法追溯的重要因素，也是數(shù)據(jù)治理需要解決的最基本的數(shù)據(jù)問題；

• 關聯(lián)性

數(shù)據(jù)關聯(lián)性問題是指存在數(shù)據(jù)關聯(lián)的數(shù)據(jù)關系缺失或錯誤，例如：函數(shù)關系、相關系數(shù)、主外鍵關系、索引關系等。存在數(shù)據(jù)關聯(lián)性問題，會直接影響數(shù)據(jù)分析的結果，進而影響管理決策；

• 真實性

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

• 及時性

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

②解決方案?

• 全流程的數(shù)據(jù)鏈路和各級質量保證方法

• 業(yè)務架構

• 業(yè)務流程

③效果?

• 某業(yè)務健康情況監(jiān)控

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

• 某任務中間邏輯監(jiān)控

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

④收益?

• 上線前

• 早期無類似 DQC 系統(tǒng)保證的前提下，我們很多問題都是天級別甚至上線后，才發(fā)現(xiàn)存在數(shù)據(jù)異常，出現(xiàn)過 3 次問題，造成的返工和交付不靠譜的情況，對業(yè)務影響巨大。

• 早期開發(fā)中，在開發(fā)過程需要不斷針對各種細節(jié)規(guī)則進行比對，總會花費一定時間逐層校驗，成本巨大。

• 上線后

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

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

四、總結和展望

?1、收益總結

1）業(yè)務發(fā)展方面

①針對實時業(yè)務數(shù)據(jù)

• 提供了基于時效性的熱點、潛力的把控。加速業(yè)務在生產、消費方面的使用，進而提升優(yōu)質創(chuàng)作量及用戶對內容消費能力。

• 同時提供了提供實時的復雜計算的外顯指標，加強用戶體驗，下線了業(yè)務后端通過腳本計算指標的方法，降低了業(yè)務的復雜性，節(jié)約了成本，提升人效。

②針對實時算法特征

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

③針對用戶畫像

• 完善和升級用戶篩選，做到多維、多類型的定向篩選，并接入了運營平臺、營銷平臺等系統(tǒng)，提高了業(yè)務效率，降低了業(yè)務人員進行人群定向的成本。

• 搭建和完善用戶分析，做到多角度用戶分析，定向用戶分析報告 0 成本，助力業(yè)務部門快速把握核心客戶市場。

2）工具建設方面

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

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

3）人員組織方面

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

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

2、未來展望

從 2021 年 8 月成立至今，我們一直思考如何提供更好的實時數(shù)據(jù)服務？實時數(shù)據(jù)能建設什么方面的應用，為業(yè)務創(chuàng)造價值？如何將用戶畫像服務做好？用戶畫像服務的篩選、分析能力如何為業(yè)務創(chuàng)造更大價值？摸著石頭過河的同時，我們也在不斷摸索和建設相關的業(yè)務能力和基礎建設。在明年的發(fā)展中，我們還會針對以下方面進一步發(fā)展：

1）基于實時數(shù)據(jù)

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

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

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

2）基于用戶畫像

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

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