3-侯容-數字娛樂論壇.pdf

《3-侯容-數字娛樂論壇.pdf》由會員分享，可在線閱讀，更多相關《3-侯容-數字娛樂論壇.pdf（39頁珍藏版）》請在三個皮匠報告上搜索。

1、D Da at ta aF Fu un nC Co on n#2 20 02 24 4知知乎乎 DMP/CDP 平平臺臺的的應應用用和和實實踐踐侯容-知乎-艦橋平臺研發LeaderD a t a F u n 上海站嘉賓專享講講師師介介紹紹侯侯容容知知乎乎-艦艦橋橋平平臺臺研研發發L Le ea ad de er r知乎艦橋平臺研發 Leader，18 年入職知乎，曾擔任社區、社交等業務高級研發和業務架構師，21 年加入平臺團隊擔任用戶理解&數據賦能組研發 Leader。帶領團隊從 0 到 1 從底層到業務層搭建實時數據基建和業務，同時整合資源完成用戶理解工程及 DMP 的建設。22 年從 0

2、到 1 搭建知乎艦橋平臺，知乎艦橋平臺是：面向內容運營、用戶運營、活動運營、創作者運營、場景運營（熱點&熱榜&話題&推送等）、生態分析等業務場景搭建的一站式平臺。其中包含內容&用戶管理和運營平臺、內部營銷平臺（活動引擎&搭建&分析&投放平臺）、內部投放和資源管理平臺、創作者管理平臺、DMP平臺、內容池平臺、經營分析平臺、場景運營平臺等等，全方位賦能業務運營和業務發展D a t a F u n 上海站嘉賓專享C Co on nt te en nt ts s目目錄錄背背景景介介紹紹架構和設計難點和挑戰未來及展望D a t a F u n 上海站嘉賓專享0 01 1 背背景景介介紹紹D a t a

3、F u n 上海站嘉賓專享01-01 業務背景知乎社區產品系統，歸根結底，是一個以推薦算法和搜索引擎相結合的方式來匹配用戶與內容的平臺。這樣的平臺經濟是在市場經濟模型上運作，具備靈活高效的優點，同時也存在一定的盲目性和滯后性。在這一系統中，推薦策略充當著市場調節器的角色。然而，單靠流通側的調整，往往難以迅速和有效地使平臺朝向我們期望的方向發展。因此，運營系統的加入至關重要。運營系統在產品系統之外工作，主要目標是構建和維護一個健康的內容生態。D a t a F u n 上海站嘉賓專享插曲-為什么叫艦橋？艦橋是軍艦的大腦，是操控艦艇和指揮作戰的地方D a t a F u n 上海站嘉賓專享01-0

4、2 艦橋平臺的能力地圖今天主要介紹CDPDMP社區CRM部分D a t a F u n 上海站嘉賓專享0 02 2 架架構構與與設設計計D a t a F u n 上海站嘉賓專享02-01 有哪些業務需求？D a t a F u n 上海站嘉賓專享02-01 業務架構設計業務解耦：提升對接效率，從 M*N-M+N資產共享：一方探索出來的資產，可以多方使用，提升利用效率信息廣播：新資產產出后，會在各平臺廣播，避免漏掉D a t a F u n 上海站嘉賓專享02-01 業務流程站內業務閉環內容扶持興趣探測活動策劃站外向站內投放閉環廣告業務站內向站外投放增長業務D a t a F u n 上海站嘉

5、賓專享02-02 有哪些功能和要求？D a t a F u n 上海站嘉賓專享02-02 架構設計不同模塊的架構目標前臺模塊:操作簡單，低使用成本 對外接口:高穩定性、高并發高吞吐 后臺模塊:開發和接入工作配置化，降低開發成本人群圈選:可擴展。新增標簽和通用人群包 0 成本，新增規則低成本 人群洞察:可擴展。新增洞察維度 0 成本，新增洞察方式低成本。人群泛化:可擴展。新增泛化方式低成本。特征生產:接入特征配置化，與后臺打通，0 成本接入ID Mapping:屏蔽 ID Map 打通邏輯，新類型 ID 低成本接入。計算任務運維:屏蔽機器資源和任務依賴存儲:可擴展可持續，不因業務量增長，導致成本

6、大幅增加 D a t a F u n 上海站嘉賓專享02-02 特征處理鏈路設計特征鏈路離線：Hive-特征抽取-離線標簽-實時：Kafka-特征抽取-實時標簽-存儲Doris用戶 x 標簽：用戶有哪些標簽（1100 億）id mapping：id 轉化寬表（8.5 億）ElasticSearch標簽枚舉表：標簽中文信息及搜索（300 萬）D a t a F u n 上海站嘉賓專享02-02 人群定向流程人群定向流程很多，以下說幾種典型的：1.普通標簽圈人：標簽加購物車-圈選。2.普通泛化：傳種子人群-泛化。3.歷史效果圈人：歷史效果人群-泛化-疊加本次運營特點-圈選。4.復雜一些的歷史效果圈

7、人：歷史效果人群-洞察-重新生成標簽關系-圈選-疊加歷史正向人群-泛化-限制分發條件-圈選。5.廣泛覆蓋定向加強：寬條件圈包-大規模投放-轉化效果好的-高轉投放-疊加轉化額外條件-高品質定向投放6.等等對標簽、歷史人群進行組合、泛化、再限制條件再圈選、洞察，最后再調整等等標簽搜索人群預估人群圈選人群泛化泛化結果生成人群、標簽D a t a F u n 上海站嘉賓專享0 03 3 難難題題與與解解決決方方案案D a t a F u n 上海站嘉賓專享03-01 人群定向性能優化D a t a F u n 上海站嘉賓專享03-01 改造點：BitMap 倒排partition_sign 分區標識（

8、日期、群組等）tag_group、tag_value_id 標簽組和標簽值 idcondidence 置信度區間 50 55、55 60 members 該特征用戶 bitmap 1.特征提取，生成標簽2.通過用戶、設備等基礎設施新增、獲取一個統一用戶 id3.通過統一 id 和其他信息的關聯結果生成 id_mapping 表BitMap 倒排 ID MappingD a t a F u n 上海站嘉賓專享03-01 改造點：查詢邏輯改造過濾條件從 where 條件中的 and、or、not 替換為查詢聚合函數的 bitmap_and 等。取用戶方式從 id 列表轉化為 id bitmap 結

9、果D a t a F u n 上海站嘉賓專享03-01 改造點：分而治之將連續一塊的用戶 id 的不同 tag 的數據，都增加統一的 group 字段進行分組。在 group 內完成交并差后，最后進行數據匯總。同時開啟多線程模式，提升每組的計算效率。D a t a F u n 上海站嘉賓專享03-01 改造點：分而治之 效果優化前優化后Colocate 原理D a t a F u n 上海站嘉賓專享03-01 改造點：算子合并D a t a F u n 上海站嘉賓專享03-02 標簽和人群導入性能優化隨著業務標簽和通用人群包的不斷擴展，數據量越來越大，到了 1100 億行后，Load 速度達到

10、了 8 小時多，進而導致業務使用延遲，逐漸不能接受D a t a F u n 上海站嘉賓專享03-02 BrokerLoad VS SparkLoadD a t a F u n 上海站嘉賓專享03-02 期間的踩坑和解決方法D a t a F u n 上海站嘉賓專享03-02 最終效果D a t a F u n 上海站嘉賓專享03-03 在線接口性能優化方案一方案二方案選型：目前是方案一原因：新增人群和人群失效頻繁，同步成本高于緩存成本人群包多，方案二維護 Doris 和 Redis 數據一直一定成本方案二需要和使用協同使用和停用的生命周期，同步進行同步和刪除，而方案一只需要根據調用情況回源。

11、方案二多走一次網絡，速度慢D a t a F u n 上海站嘉賓專享03-03 問題起因隨著業務的擴展，出現了同時判斷某個人是否在 1000+個人群包中的情況從火焰圖可以看出反序列化函數 msgpack.Unmarshal 占用了 17.77%的 CPU D a t a F u n 上海站嘉賓專享03-03 LocalCache 改造LocalCache 代碼重寫的 LocalCache看起來為了兼容不同類型做的轉換，但由于bitmap.toBytes()已經是序列化后的結果，因此決定重寫一個localBytesCache類型來規避這次的問題。D a t a F u n 上海站嘉賓專享03-0

12、3 LocalCache 改造寫邏輯改造前后對比改造效果850 batch的情況，上線后延時基本降低一半D a t a F u n 上海站嘉賓專享03-03 bitmap.ReadFrom 改造左側圖中 bitmap 的 readFrom 很高。主要原因是bigcache為了避免 gc 做了很多底層優化，數據必須以二進制進行存儲。我們對本地緩存進行了簡單的改造。改造后只有程序初次啟動讀取 redis 二進制數據會使用 到 bitmap.ReadFrom，后續取本地緩存中的數據則不需要了。缺點是會看到很明顯的gcD a t a F u n 上海站嘉賓專享03-03 bitmap.ReadFrom

13、 改造改造位置改造位置優化后readFrom基本消失后續頁增加了一些常見優化1.將rand改為fastrand，rand持有全局globalrand對象，多線程使用存在鎖沖突，改為fastrand2.將sprint全部改為stringbuilder實現3.將sync.Map改為cocurrentMap實現D a t a F u n 上海站嘉賓專享03-03 最終效果3k+QPS，單次請求 1 個人是否在 3000+個人群包，P95 411ms調用方換包 id 變更量，每秒平均 40 左右，峰值每秒 800D a t a F u n 上海站嘉賓專享03-03 圖片破容量上限的換包率問題針對目前架

14、構是通過容器內存來緩存請求中用到的頻率最高的人群包。速度快的同時也會引入單節點容量最大值，也就是一臺機器緩存了最熱的所有人群包后，內存到達了最大值。當業務有更多的人群包判斷需求后，就會引入左側架構解決。首先 proxy 只是分流邏輯，處理流量成本低。承壓集群都是緩存架構，調整分流策略后可以快速緩存人群包并開始承壓。所以到達瓶頸后只需水平庫容承壓容器，并調整分流策略即可快速承載更多的量。D a t a F u n 上海站嘉賓專享0 04 4 未未來來及及展展望望D a t a F u n 上海站嘉賓專享D Do or ri is s +E ES S -D Do or ri is s 2 2.0 0 D a t a F u n 上海站嘉賓專享生成式大模型生成人群條件結果描述輸入：自然語言輸出：對應的圈人條件業務效果降低了使用成本，用戶使用量提升，提高了整體的工作效率。新手友好，很多新同學通過自然語言轉篩選開始學會使用這一功能，降低推廣成本。未來展望模糊語言：一個母嬰用品的高轉化人群。提升效果：目前幻覺和錯誤還是較多，需要跟隨模型升級不斷解決。D a t a F u n 上海站嘉賓專享基于大模型的運營自動化OpenAI 提到的 Assistants API具體的執行過程期望自動化的場景D a t a F u n 上海站嘉賓專享感感謝謝D a t a F u n 上海站嘉賓專享