摘要

使用者畫像與實時資料分析是網際網路企業的資料核心。知乎資料賦能組以百度智慧雲的資料倉庫Palo（基於Apache Doris的商業產品）為基礎，構建高響應、低成本、兼顧穩定性與靈活性的實時資料架構，同時支援實時業務分析、實時演算法特徵、使用者畫像三項核心業務流，顯著提升對於時效性熱點與潛力的感知力度與響應速度，大幅縮減運營、營銷等業務場景中的人群定向成本，並對實時演算法的準確率及業務核心指標（如活躍、留存、付費等）帶來明顯增益。

關鍵詞：資料倉庫，Palo，Apache Doris，使用者畫像，實時資料

一、前言

知乎業務中，隨著各業務線的發展，逐漸對使用者畫像和實時資料這兩部分的訴求越來越多。對使用者畫像方面，期望有更快、更準、更方便的人群篩選工具和方便的使用者群體分析能力。對於實時資料方面，期望擁有可以實時響應的使用者行為流，同時在演算法特徵、指標統計、業務外顯等業務場景有愈來愈多的資料實時化的訴求。

在 2021 年 8 月，知乎平臺團隊成立資料賦能組。針對歷史實時資料需求無承接方的現象，已有使用者畫像系統無法滿足多樣的人群定向的現狀，及業務方進一步人群分析的業務訴求。綜合考慮了查詢時效、運維簡易等方面因素，資料賦能組提出基礎設施層選用百度智慧雲的 Palo 作為實時資料倉庫，業務工具層建設實時資料整合、實時資料排程、實時資料質量中心等系統，應用層建設實時資料應用和使用者畫像應用的方案。該方案針對性地解決了業務痛點，滿足了業務訴求。

拆分當前業務主要在實時資料和使用者畫像兩大部分有難點，共包含如下的三個方向目標：

• 實時業務資料

1. 通過提供實時的業務指標，解決業務對熱點、潛力的把控，助力生產、消費，提 升優質創作量及內容消費能力。
2. 提供實時的複雜計算的外顯指標，加強使用者體驗，解決業務側通過後端指令碼計算的高維護成本和複雜性，節約成本，提升人效。

• 實時演算法特徵

1. 以實時資料為基礎，提供多樣的實時演算法特徵，與演算法團隊共同提升 DAU、留存、使用者付費等核心指標。

• 使用者畫像

1. 使用者篩選，做到多維、多型別的定向篩選，並接入營銷、廣告、 運營平臺等系統，提高業務效率，降低人員成本。
2. 使用者分析，做到多角度使用者分析，定向使用者分析報告 0 成本，助力業務部門快速把握核心客戶市場。

本文就知乎平臺的資料賦能團隊，基於上述三個方向的目標，將圍繞四個思考方向來介紹相關方面的技術實踐經驗和心得體會：

• 如何通過實時資料驅動業務發展？
• 如何從 0 -> 1 搭建實時資料中心？
• 如何搭建一套高效快速的使用者畫像系統來解決歷史系統的多種問題？
• 如何快速高效的開發業務功能和保證業務質量？

1.1 名詞解釋

1.2 實時資料與使用者畫像與各業務的結合

二、面臨的挑戰和痛點

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

1）有價值

• 如何通過實效性發現業務價值？

1. 搭建熱點、潛力等緊隨時間的指標和相關的排行榜，直接支援業務發展。

• 如何讓使用者畫像的篩選和分析能力最大化？

1. 要全面覆蓋多維度使用者篩選的多種需求。
2. 多角度、多方式覆蓋使用者分析。

   2）資料實效性

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

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

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

1. 通過實時資料系統與 Palo 配合共同建設，提升到 10 分鐘內更新（下面介紹）。

   3）介面實時性

• 熱點運營場景，期望使用者畫像服務能在秒級別快速篩選出大量人群，使用者後續的推送等運營場景，如何解決？

1. 通過使用者畫像系統與 Palo 配合共同建設，提升人群篩選的速度（下面介紹）。

   4）複雜性

• 實時資料幾乎沒有 count、sum 需求。幾乎都是複雜去重和多資料聯合計算的情況。

1. 以播放量為例。在啟播、暫停、完播、心跳等多個條件下，會同時有多個點，要進行去重。同時基於視訊回答、視訊的關係和雙作者聯合創作的關係，需要疊加，同時保證在父子內容異常狀態的情況下過濾其中部分播放行為。

• 人群分析業務，期望多角度、各維度進行人群關聯計算，同時基於全部使用者特徵針對當前人群和對比人群進行 TGI 計算，篩選出顯著特徵，如何解決？

1. 通過使用者畫像系統與 Palo 配合共同建設，解決複雜的人群分析（下面介紹）。

• 業務資料中有增 / 刪 / 改邏輯，如何實時同步？

1. 實時資料整合系統與 Palo 配合共同建設，解決增 / 刪 / 改邏輯（下面介紹）。

• 明細資料異常發現滯後，異常發現後，需要針對性修正構建方式，及回溯資料修復，如何解決？

1. 通過選擇 Lambda 架構作為資料架構解決（下面介紹）。

   三、實踐及經驗分享

   3.1 整體業務架構

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

• 應用層：負責當前我們的業務應用，直接為業務提供工具或提供業務的某些模組，與業務共擔目標，為業務賦能。
• 業務模型層：支援應用層建設和一定的實時分析能力，同時也作為業務某一個流程的功能模組接入使用，為外部業務和自身應用層建設，與業務共擔目標，為業務賦能。
• 業務工具層：支援應用層和業務模型層的開發，提供通用的工具，面向降低應用層和業務模型層的建設成本，提升整體建設的工程效能，保證業務穩定和資料質量準確。
• 基礎設施：技術中臺提供的基礎設施和雲服務，提供穩定可用的基礎功能，保證上層建築的穩定性。
  

  3.2 實時資料的資料架構選型

  解決當前問題的資料架構，一般有 Lambda 架構和 Kappa 架構。針對當前業務特點，計算複雜、偶發的異常問題需要大資料量回溯等特性。當前實時資料的資料架構採用的是 Lambda 架構。由 Palo 承載分鐘級的批處理，Flink 來承載秒級別簡單邏輯的流處理。具體如下：
  

## 3.3 應用層建設經驗分享

3.3.2 實時資料系統

業務場景

實時資料系統主要有兩個大方向：實時業務資料和實時演算法特徵。

• 實時業務資料。

1. 通過提供實時的業務指標，解決業務對熱點、潛力的把控，助力生產、消費，提 升優質創作量及內容消費能力。
2. 提供實時的複雜計算的外顯指標，加強使用者體驗，解決業務側通過後端指令碼計算的高維護成本和複雜性，節約成本，提升人效。

• 實時演算法特徵。-

1. 以實時資料為基礎，提供多樣的實時演算法特徵，與推薦演算法團隊共同提升 DAU、留存、使用者付費等核心指標。

   面臨的困難

• 依賴資料來源多，計算規則複雜。以我們的播放量計算為例：

1. 行為有多條，需要針對行為進行去重。
2. 過濾和加和規則很多，需要依賴多個數據源的不同資料結果進行計算。
   
   

• 時間敏感性高

1. 以演算法特徵為例，使用者瀏覽某內容後，針對後續關聯的一系列計算後，需要在一定時間內產出計算結果（10min 未產出後續推薦效果會有波動，26min 該特徵的效果會降為 0）

• 排程過程中協調成本高

1. 需要排程系統中，同時能識別 kafka 流消費的進度和任務完成情況。
2. 需要嚴格拉齊多個依賴的消費進度，當達到統一進度後，集中進行後續任務計算。

   解決方案

   搭建實時資料基座，建設相應的資料模型，降低建設成本。
   

針對依賴資料眾多、計算規則複雜、質量難以保證等問題。通過建設工具降低解決問題的成本。

• 通過建設實時資料整合和實時資料排程的能力，保障資料接入和資料模型建設的速度，降低接入時間，提升業務接入效率（具體見下方）
• 通過建設實時資料質量中心，保障資料質量，降低發現數據質量問題的時間，提升發現效率，保證業務交付結果（具體見下方）
  時間敏感性高，加強監控、與 Palo 叢集共同提升吞吐效率和計算效率。
• 搭建寫入延遲、計算延遲等監控，快速發現問題。
• Palo 叢集進行引數變更，調整批量寫入的資料量、時間和頻率等進行優化。

1. 當前我們的 Load 主要有 Broker Load 和 Routine Load。其中時效性要求高的是 Routine Load。我們針對性的進行了引數調整。

• Palo 增加了 Runtime Filter，通過 BloomFilter 提升 Join 效能。

1. Palo 叢集在 0.14 版本中加入了 Runtime Filter 的過濾，針對 Join 大量 key 被過濾的情況有明顯提升；
2. 該變更針對我們當前的幾個業務排程效能，有明顯提升。時間從 40+s 提升至 10s 左右；

   3.3.3 使用者畫像系統 DMP

   業務場景

使用者畫像系統主要有兩大功能：使用者檢索和使用者分析。

• 使用者檢索。重點在於快速完成人群包圈選同時在圈選條件變更過程中，需要快速計算出預計能圈的使用者有哪些？
• 使用者分析。重點在於多人群包的各個維度對比分析，通過分析結論找到最明顯的使用者特徵（通過 TGI 值判斷）

  面臨的困難

1. 資料規模大。我們當前是 200+ 個標籤，每個標籤均有不同的列舉值，總計有 300+ 萬的 tag。tag 對使用者的打標量級在 900+ 億條記錄。由於標籤每日更新匯入量級十分大。
2. 篩選響應時間要求高。針對簡單的篩選，要求在秒級別出結果，針對複雜的人群篩選，篩選後人群量大的情況，要求在 20s 內完成人群包生成。
3. 人群包除了 long 型別的使用者 id 外，還需要有多種不同的裝置 id 和裝置 id md5 作為篩選結果。
4. 使用者分析場景下，針對 300+ 萬 tag 的多人群交叉 TGI 計算，需要在 10min 內完成。

解決方案

DMP 業務架構

DMP 業務流程

效能問題針對性解決
資料規模大，提升匯入效能，分而治之。

• 資料模型變更，拆分檔案。

1. Palo 的儲存是按照 Tablet 分散在叢集上的。通過調整資料模型，確保分佈均勻及每個檔案儘可能的小。

• 匯入變更，拆分匯入。

1. 由於每個 Broker Load 匯入都是有效能瓶頸的，將 900+ 億行資料，拆分為 1000+ 個 Broker Load 的匯入任務，確保每個匯入總量都足夠小。

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

• 業務邏輯變更，拆分使用者。

1. 將使用者每 0 ～ 100 萬拆分為一組。
2. 針對全部使用者的交併差，等價於對所有組使用者交併差後的並集。
3. 針對全部使用者的交併差的總數，等價於對分組使用者交併差後的總數進行 sum。

• 資料模型變更，拆分檔案。

1. 設定 bitmap 的分組引數，將分組設定為 colocate group。確保每個分組的交併差計算均在自己所在 BE 完成，無需 shuffle。
2. 將 bitmap 表的分桶拆分更多，通過更多檔案同時計算加速結果。

• 計算引數變更，提升併發。

1. 由於計算過程通過分治的手段，拆分為多個小任務。通過提升並行度 parallel_fragment_exec_instance_num 再進一步優化計算速度。

效果

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

同時在工具效能上，有如下表現：

• 匯入速度。當前每日 900+ 億行資料，在 3 小時內完成匯入。
• 人群預估。人群預估基本可在 1s 內完成，P95 985ms。
• 人群圈選。人群圈選過程在 5s 內完成，整體圈人在 2min 左右。（待提升中介紹）
• 人群分析。人群分析過程在 5min 內完成。

待提升

功能擴充套件

• 缺乏定製的人群擴散能力。多業務場景對已有人群進行擴散有複雜且多樣的需求。
• 缺乏使用者人群染色，無法再多個環節完成使用者效果的回收和進行後續的分析。

效能提升

• 當前 Palo 的行列轉換功能在建設中。在使用者畫像業務中，將使用者 id 更換為裝置 id，人群縮減（將具體人群包縮減為一個比較小的人群包用於後續運營動作）過程是通過業務程式碼實現的，降低了效能。

1. 後續結果由行列轉換後，使用者畫像結果處理流程中會將裝置 id 獲取方式通過 join 維度表來實現，人群縮減通過 order by rand limit 來實現，會有比較明顯的效能提升。

• 當前 Palo 的讀取 bitmap 功能在建設中。業務程式碼無法讀取到 bitmap，只能先通過 bitmap_to_string 方法讀取到轉換為文字的 bitmap，加大了傳輸量，降低了圈選效能。

1. 後續可以直接讀取 bitmap 後，業務邏輯中會替換為直接獲取 bitmap，會極大程度的減少資料傳輸量，同時業務邏輯可以針對性快取，。

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

3.4 工具層建設經驗分享

3.4.1 資料整合

業務場景

“巧婦難為無米之炊”，沒有資料也就沒有後面的一切，資料採集作為基礎至關重要。Palo 資料倉庫自帶的多種資料匯入方式對於資料入倉非常便利，但是在我們的使用過程中也遇到了一些挑戰，比如：

• 在從離線數倉進行 broker load 的時候資料依賴丟失，上游資料錯誤無法評估受影響的範圍。
• 需要編寫冗長的 etl 處理邏輯程式碼，小的操作變更流程很長，需要全流程（至少 30 分鐘）的上線操作；此外每次部署操作還有可能遇到各種初始化 MQ 消費者的問題
• 缺少執行狀態監控，出現異常問題無法在分鐘甚至小時級別的時間發現；
• 線上匯入僅支援 kafka json，上游的 pulsar、protobuf 資料仍需要程式碼開發進行轉發，導致每次接入資料都需要轉換函式的開發以及同樣全流程的上線操作；
• 業務邏輯中，期望業務是什麼樣，Palo 中的資料就是什麼樣，讓業務無感知。這種全增量同步期望被包住，而不是做很多配置或開發很多程式碼來實現。

  解決方案

針對上述問題，知乎資料賦能組啟動建設實時資料模型，在百度智慧雲Palo團隊的協同配合下，將對眾多業務資料的依賴，以及對資料逐層建設的資料模型搭建出實時資料整合系統和實時排程系統，並下沉到工具層。

• 實時資料整合。建設快速且自定義的配置，針對不同的資料來源建設匯入能力。
• 與 Palo 的 Broker Load 和 Routine Load 進行配合，在此基礎上搭建針對業務的全增量同步。
• 封裝整合能力對內部暴露的介面，業務層無需理解中間過程，只選擇同步的資料庫和資料表即可進行實時同步。
  

效果

同步配置

同步任務

上線前

• 早期使用 Palo 開發實時資料業務過程中，由於需要某個資料全/增量同步，同時進行資料轉換。需要建 Palo 資料模型，完成全量資料匯入，建設增量資料 ETL 和 Routine Load 等開發，需要 1 名工程師 1 天才能將一張表接入到 Palo 中並進行全增量實時同步。
• 中間鏈路多，缺乏報警，針對重要的鏈路，建設打點和報警成本高，需要 0.5 天左右。

1. 全量：原始資料庫 TiDB -> 中間部分（DataX）-> Palo
2. 增量：原始資料庫 TiDB -> TiCDC -> Canal Binlog Kafka -> ETL（填充資料）-> Kafka -> Routine Load -> Palo
   上線後

• 僅需要 10min 的配置，資料整合包含模型，資料匯入及中間 ETL 的轉化和額外資料補充以及 Routine Load 全部建好。業務層無需感知資料中間鏈路，僅需要描述我期望那個表被同步。
• 上線後無需業務關心，完成第一步配置後，後續的監控和報警以及一致性，整合全面解決。

3.4.2 資料排程

業務場景

我們在初期通過 Palo 建設實時資料的過程中，是通過 Routine Load 後的資料，再定時任務執行後續計算邏輯，後再將計算結果匯出到承載儲存，如 Redis、Zetta（知乎自研 HBase 協議） 中完成外部壓力承載。在這個過程中遇到了如下問題：

• 依賴未就緒後續任務就執行。如最近 24 小時的曝光，在 15:05 執行昨日 15:00 - 今日 15:00 的查詢。此時如果 Routine Load 僅匯入到 14:50 的資料，這次執行結果異常；
• Palo 資源有限，但很多工都是某些整點整分鐘的，一次性大量的計算任務造成叢集崩潰；
• 任務是否執行成功，任務是否延遲，是否影響到業務，無報警無反饋；
• 匯出儲存過程通用，重複程式碼開發，每次都需要 0.5 - 1 人天的時間開發寫入和業務介面。

  解決方案

  基於上述問題，我們與百度智慧雲Palo團隊合作，梳理出重要的資料流與監控項，並建立起知乎實時資料的資料排程與監控架構。
  架構圖
  

流程圖

效果

同步任務

收益

• 建立任務依賴機制，通過 kafka 的 offset 和前置表是否完成計算，判斷當前計算任務能否執行。後續再也沒有出現過資料還未匯入就先開始進行資料計算的情況。
• 通過退讓策略，監控當前 Palo 指標，在高負載情況下避擴音交 SQL。避峰趨谷，完成資源最大利用。後續通過這種方案，一定程度的避免了瞬時跑高整體叢集的問題。
• 全鏈路監控任務執行情況，和延遲情況，一旦延遲報警，及時溝通解決和恢復業務。一旦任務延遲，監控可非常快速的發現相關問題，多數情況能在業務可接受範圍內完成恢復。
• 上線後，原先需要 1 天的工程能力開發時間降低至 0。只需要在 Palo 中有一個可查詢的 SQL，經過簡單配置即可完成一定時間交付給業務相關資料、排行榜的需求。

3.4.3 資料質量

業務場景

資料，已經成為網際網路企業非常依賴的重要資產。資料質量的好壞直接關係到資訊的精準度，也影響到企業的生存和競爭力。Michael Hammer（《Reengineering the Corporation》一書的作者）曾說過，看起來不起眼的資料質量問題，實際上是拆散業務流程的重要標誌。 資料質量管理是測度、提高和驗證質量，以及整合組織資料的方法等一套處理準則，而體量大、速度快和多樣性的特點，決定了大資料質量所需的處理，有別於傳統資訊治理計劃的質量管理方式。
具體到針對知乎的各個業務：
AI平臺、增長團隊、內容平臺等已經將部分或全部業務漸漸遷移到實時計算平臺，在接入資料更實時，更迅速的接入帶來的所享受的收益外，資料質量更加變得重要。

• 完整性: 資料完整性問題包括：模型設計不完整，例如：唯一性約束不完整、參照不完整；資料條目不完整，例如：資料記錄丟失或不可用；資料屬性不完整，例如：資料屬性空值。不完整的資料所能借鑑的價值就會大大降低，也是資料質量問題最為基礎和常見的一類問題；
• 一致性: 多源資料的資料模型不一致，例如：命名不一致、資料結構不一致、約束規則不一致。資料實體不一致，例如：資料編碼不一致、命名及含義不一致、分類層次不一致、生命週期不一致……相同的資料有多個副本的情況下的資料不一致、資料內容衝突的問題；
• 準確性: 準確性也叫可靠性，是用於分析和識別哪些是不準確的或無效的資料，不可靠的資料可能會導致嚴重的問題，會造成有缺陷的方法和糟糕的決策；
• 唯一性: 用於識別和度量重複資料、冗餘資料。重複資料是導致業務無法協同、流程無法追溯的重要因素，也是資料治理需要解決的最基本的資料問題；
• 關聯性: 資料關聯性問題是指存在資料關聯的資料關係缺失或錯誤，例如：函式關係、相關係數、主外來鍵關係、索引關係等。存在資料關聯性問題，會直接影響資料分析的結果，進而影響管理決策；
• 真實性: 資料必須真實準確的反映客觀的實體存在或真實的業務，真實可靠的原始統計資料是企業統計工作的靈魂，是一切管理工作的基礎，是經營者進行正確經營決策必不可少的第一手資料；
• 及時性: 資料的及時性是指能否在需要的時候獲到資料，資料的及時性與企業的資料處理速度及效率有直接的關係，是影響業務處理和管理效率的關鍵指標。

  解決方案

  全流程的資料鏈路和各級質量保證方法
  

業務架構

業務流程

效果

某業務健康情況監控
以通過 DQC 監控的某一個業務的健康情況，該業務由多個匯出任務和中間計算任務及部分資料來源組成，當前情況是一切正常。期間如果出現某節點任意異常後，都可及時發現。

某任務中間邏輯監控

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

收益
上線前

• 早期無類似 DQC 系統保證的前提下，我們很多問題都是天級別甚至上線後，才發現存在資料異常，出現過 3 次問題，造成的返工和交付不靠譜的情況，對業務影響巨大。
• 早期開發中，在開發過程需要不斷針對各種細節規則進行比對，總會花費一定時間逐層校驗，成本巨大。
  上線後
• 在上線 1 個月內，通過 DQC 系統規則，當前已發現了 14 個錯異常，在 1 - 2h 左右發現，立即修復。對業務的影響降低到最小。

• 在系統上線後，在開發過程中，開發完相關資料，如有異常，就產生了異常報警，大幅節省了人工發現的成本，因為修復時間早，在後續開發啟動前，就已經修復，極大程度降低開發過程中的返工成本。

  四、總結與展望

  4.1 收益總結

  4.1.1 業務發展方面

• 針對實時業務資料

1. 提供了基於時效性的熱點、潛力的把控。加速業務在生產、消費方面的使用，進而提升優質創作量及使用者對內容消費能力。
2. 同時提供了提供實時的複雜計算的外顯指標，加強使用者體驗，下線了業務後端通過指令碼計算指標的方法，降低了業務的複雜性，節約了成本，提升人效。

• 針對實時演算法特徵

1. 提供了基於創作者、內容、消費者的實時演算法特徵，與演算法團隊共同在多個專案中，針對 DAU、留存、使用者付費等核心指標有了明顯的提升。

• 針對使用者畫像

1. 完善和升級使用者篩選，做到多維、多型別的定向篩選，並接入了運營平臺、營銷平臺等系統，提高了業務效率，降低了業務人員進行人群定向的成本。
2. 搭建和完善使用者分析，做到多角度使用者分析，定向使用者分析報告 0 成本，助力業務部門快速把握核心客戶市場。

4.1.2 工具建設方面

• 完成了實時資料領域和使用者領域的佈局，建設了相關的開發和維護工具，解決了先前在此方面無基礎設施，無業務工具，開發成本高的問題。

• 搭建了整合、排程、質量系統。通過工具的方式降低了業務發展和迭代的成本，讓業務快速發展，同時也保證了交付質量提高了業務基線。

  4.1.3 人員組織方面

• 自上而下的拆分了實時資料和使用者畫像的能力，分為應用層、業務模型層、業務工具層和基礎設施層。通過組織劃分，明確了不同層次的邊界和加速了業務目標的達成。

• 搭建並完善了多層次團隊人員梯隊。根據針對不同方向的同學，給予不同的 OKR 目標，做到跨層次方向隔離，同層次方向一致，同模組目標一致。共同為整體實時資料與使用者畫像服務建設而努力。

4.2 未來展望

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

• 基於實時資料

1. 強化基礎能力工具層的建設，持續降低基於實時資料方面的建設、交付成本。
2. 提升資料質量工具覆蓋能力，為業務模型提供質量保障，並提供基於實時資料的畫像質量保障能力。
3. 基於當前業務訴求，部分場景針對 5 分鐘級實時無法滿足，進一步探索秒級別複雜情況實時能力，並提供能力支援。

• 基於使用者畫像

1. 加強並針對使用者畫像、使用者理解、使用者洞察 & 模型等進一步建設。通過與具體業務結合，建設貼合業務場景的使用者理解成果和相應的分析能力，找到業務的留存點。
2. 進一步加強新的工具能力的建設，通過建設使用者理解工具、使用者分析工具，降低產生理解及對業務分析的成本，提升業務效率，快速發現業務價值。

作者簡介
侯容。知乎資料賦能組 Leader，主要負責實時資料、使用者理解方向。