不同人對數(shù)據(jù)的需求是不一樣的，或者說，不同同學(xué)對同一份數(shù)據(jù)的不同指標(biāo)組有不同的價(jià)值認(rèn)可。
1.我們的交互同學(xué)更多地會參考大盤的“用戶習(xí)慣”，使用某個(gè)問卷題型的比例來作為設(shè)計(jì)方案的數(shù)據(jù)支撐；
2.開發(fā)同學(xué)更多地會關(guān)注這個(gè)數(shù)據(jù)引發(fā)地一些性能（問題），架構(gòu)指標(biāo)等；
3.產(chǎn)品同學(xué)會非常關(guān)心某個(gè)上線項(xiàng)目的入口流量，轉(zhuǎn)化率相關(guān)指標(biāo)；
4.運(yùn)營同學(xué)關(guān)注的方面更為通用，除了大家都關(guān)注的北極星和護(hù)欄指標(biāo)，他們更會關(guān)心用戶在使用上的一些點(diǎn)位問題，單個(gè)/單批用戶的運(yùn)營策略轉(zhuǎn)換問題。
雖然上面只提到4個(gè)籠統(tǒng)的數(shù)據(jù)場景，但是其實(shí)我們由此產(chǎn)生的數(shù)據(jù)圖表、SQL模板甚至是需求單已經(jīng)有很多，于是我們從規(guī)范和流程上看到了一些問題：
1.我們要如何快速找到我們指標(biāo)對應(yīng)的底層數(shù)據(jù)？當(dāng)時(shí)一個(gè)關(guān)于「活躍用戶」在團(tuán)隊(duì)版中的表現(xiàn)的下推分析，后面還加上了登錄渠道的多維分析，我們甚至開了一場會去校對口徑 ;
2.關(guān)于口徑，我們?nèi)绾未_定什么數(shù)據(jù)是對的呢？不同的數(shù)據(jù)開發(fā)同學(xué)開發(fā)的報(bào)表相差很大；
3.開發(fā)同學(xué)有非常美好的想象力，一句超凡脫俗的SQL不僅在當(dāng)前的架構(gòu)下得不出結(jié)果，甚至?xí)峡迤渌蕾嚨慕M件。
讓用戶簡單地找到正確的數(shù)據(jù)，需要把數(shù)據(jù)按照層級順序擺放在合適的位置并且登記在冊，在當(dāng)時(shí)的時(shí)間點(diǎn)下，開始構(gòu)建數(shù)據(jù)業(yè)務(wù)的數(shù)據(jù)倉庫當(dāng)然是最好的選擇；我們在數(shù)倉開始之初時(shí)反思，為什么口徑、數(shù)據(jù)、校對總是不能被一次敲定呢？后來我們發(fā)現(xiàn)，我們做這個(gè)需求的過程：從口徑的描述、SQL的開發(fā)執(zhí)行到出庫展示整個(gè)過程沒有一個(gè)地方是可以被review的。而對復(fù)雜數(shù)據(jù)量的支持，其實(shí)就是架構(gòu)該升級了，單點(diǎn)的ES無法支持多場景的adhoc。
二、數(shù)倉基建與維度建模
在做這個(gè)事之前，我問組里的同學(xué)：“我們有什么數(shù)據(jù)能夠支持我們做數(shù)據(jù)分析？”，清一色的回答：“ES里的后端Event日志，前端上報(bào)的Pageview和埋點(diǎn)，業(yè)務(wù)DB中的表”。確實(shí)我們早期就有比較統(tǒng)一的基于事件流的日志格式和較為完備的前端埋點(diǎn)組件，但是我們還是沒法回答我們擁有的數(shù)據(jù)如何支持我們完成某些需求的問題。只有我們把我們擁有的數(shù)據(jù)的具體能力和表現(xiàn)形式放出來，我們才能真正知道我們擁有的是什么，數(shù)據(jù)才能真正地從數(shù)據(jù)存儲變成數(shù)據(jù)資產(chǎn)。
1、明確數(shù)據(jù)表
上圖顯然就是我們數(shù)倉初期ODS到DWD的一層規(guī)劃，這里我們更希望引入產(chǎn)品同學(xué)來對齊我們現(xiàn)有的數(shù)據(jù)資產(chǎn)，以便在后續(xù)數(shù)據(jù)需求的溝通上能夠明確哪些數(shù)據(jù)能為我們所用，我們有哪些底層數(shù)據(jù)需要再去補(bǔ)齊。明細(xì)表一般存在于流式數(shù)據(jù)中，帶有時(shí)間屬性，一般用于一段時(shí)間內(nèi)的指標(biāo)計(jì)算。
同理，我們把存在業(yè)務(wù)DB中的數(shù)據(jù)平移到數(shù)倉中，這些數(shù)據(jù)表本身經(jīng)過了不錯(cuò)的數(shù)據(jù)建模，我們將我們擁有的表保留退化維度同步到數(shù)倉，我們就得到了DIM層(塊)。維度表一般不帶有時(shí)間屬性，用于關(guān)聯(lián)做維度分析。
2、業(yè)務(wù)總線矩陣構(gòu)建
把動態(tài)的明細(xì)數(shù)據(jù)和靜態(tài)的維度數(shù)據(jù)相互交叉，就得到了我我們數(shù)倉的底層應(yīng)用「業(yè)務(wù)總線矩陣」。在這個(gè)笛卡爾坐標(biāo)系里的每一個(gè)點(diǎn)或者一條線都有它的業(yè)務(wù)意義。比如我們通過交叉「登錄明細(xì)」 和「團(tuán)隊(duì)信息」，我們就能得到「團(tuán)隊(duì)登錄」的明細(xì)；通過交叉「登錄明細(xì)」、「團(tuán)隊(duì)信息」和「用戶登錄渠道」（2維度1明細(xì)），我們可以得到「分渠道的團(tuán)隊(duì)登錄」明細(xì)，這是一種維度細(xì)分統(tǒng)計(jì)的構(gòu)建；通過交叉「登錄明細(xì)」、「團(tuán)隊(duì)信息」和「提交答卷明細(xì)」（1維度2明細(xì)），我們可以得到「團(tuán)隊(duì)版登錄且答題」明細(xì)，這是行為組合（細(xì)分）。
至此，我們能夠清楚地認(rèn)知數(shù)據(jù)可能會在哪個(gè)位置發(fā)揮什么作用，下一步要解決的是我們該怎么找到我們的數(shù)據(jù)這個(gè)問題。
3、元數(shù)據(jù)管理
為了解決“我們有什么數(shù)據(jù)”這個(gè)問題，我們決定接管數(shù)據(jù)的入口，把開發(fā)過程中生成的數(shù)據(jù)表按照數(shù)據(jù)的生命周期命名打上標(biāo)簽。
問卷的業(yè)務(wù)數(shù)據(jù)庫里有百余張表，其中大約有近4成為維度表，需要拆分成明細(xì)的點(diǎn)位或者日志會隨著業(yè)務(wù)發(fā)展主鍵膨脹，業(yè)務(wù)總線矩陣也會主鍵變成一張大網(wǎng)，失去可檢索性。事實(shí)上，我們對數(shù)據(jù)的需求是有描述性的，比如想看“這周問卷的新增明細(xì)”，我們并非記住一串冰冷的文字，我們更希望能把「1周」，「問卷」轉(zhuǎn)換成描述條件作為我們元數(shù)據(jù)的檢索入口。 我們支持了Superset從表comment、字段comment中檢索的需求，把想要的關(guān)鍵字按照關(guān)鍵字檢索匹配到正確的數(shù)倉入口。
4、數(shù)據(jù)血緣
在我們接管了數(shù)據(jù)產(chǎn)生的入口后，我們把用戶調(diào)用數(shù)據(jù)資產(chǎn)的記錄同樣采集了起來。基于一套low code配置化調(diào)度任務(wù)，我們在為開發(fā)同學(xué)提供分區(qū)篩選、數(shù)據(jù)量評估、sql執(zhí)行、執(zhí)行結(jié)果質(zhì)量校驗(yàn)和下游寫入的能力的同時(shí)，我們更在配置化的Spark啟動入口處植入了血緣上報(bào)，當(dāng)一個(gè)任務(wù)被成功執(zhí)行計(jì)算后，我們采集了數(shù)據(jù)的流向和數(shù)據(jù)流動比例。
有了數(shù)據(jù)血緣后，在一份數(shù)據(jù)出現(xiàn)分歧時(shí)，他的數(shù)據(jù)量和執(zhí)行計(jì)劃都是可以被review的，從數(shù)據(jù)讀入和寫出的量級波動情況可以相對容易地追溯到原因，但是目前還沒有做成波動歸因。
到這里，我們的數(shù)據(jù)開發(fā)鏈路的不確定性只剩下了口徑確認(rèn)和變更。我們通過將指標(biāo)組（一般是單指標(biāo)多維度）命名，分配給數(shù)據(jù)開發(fā)同學(xué)，確定產(chǎn)品負(fù)責(zé)人和開發(fā)負(fù)責(zé)人。這個(gè)順便解決了我們之前無法追溯報(bào)表錯(cuò)誤不知道該找哪位同學(xué)來看的問題。開發(fā)完成后掛靠在某個(gè)具體的數(shù)倉表上，實(shí)現(xiàn)數(shù)據(jù)需求到數(shù)據(jù)開發(fā)到底層計(jì)算的全鏈路記錄，當(dāng)數(shù)據(jù)出現(xiàn)問題或需要修改時(shí)，則整個(gè)鏈條上的負(fù)責(zé)同學(xué)都會有感知，確保發(fā)起的修改能夠被所有相關(guān)的（特別是下游的）數(shù)據(jù)同學(xué)review到。
5、數(shù)據(jù)架構(gòu)
規(guī)范的事情暫時(shí)能跑了，在只有我一個(gè)人力的情況下繼續(xù)大力度地做進(jìn)一步數(shù)據(jù)治理可能并不是當(dāng)下最急需的，在場景分析中提到的問題，我們還有關(guān)于開發(fā)最重要的一個(gè)問題——當(dāng)下的數(shù)據(jù)架構(gòu)需要升級。為了回答這最后一個(gè)問題，我們希望把昂貴的ES儲存費(fèi)用轉(zhuǎn)投到能面向更大型分析場景的數(shù)據(jù)架構(gòu)上。
在之前，部門內(nèi)所有的分析都有ES或者ELK套件承擔(dān)，從20年開始性能和錢包都陸續(xù)見到了瓶頸。目前部門數(shù)據(jù)平臺內(nèi)走的是以流式分發(fā)為主的Lambda架構(gòu)，由下游需求決定數(shù)據(jù)是否從實(shí)時(shí)層沉降到離線層。維度數(shù)據(jù)會存在離線層，事實(shí)明細(xì)數(shù)據(jù)會廣泛地存在于實(shí)時(shí)層，這是基于下游有時(shí)延要求高，維度要求低的場景，只需要做簡單的指標(biāo)聚合，附帶退化維度寫出即可。
和Lambda架構(gòu)不同，我們的低時(shí)延分析需求更多地由近實(shí)時(shí)分析層承擔(dān)，針對不同需求，我們嘗試過很多不同的組件，根據(jù)不同的使用場景，比如全文查找、強(qiáng)聚合、上下文分析等等，我們會選擇不同的組件。基于不同的組件，我們在上層有去嘗試做不同的應(yīng)用實(shí)踐。
三、應(yīng)用實(shí)踐
1、機(jī)器學(xué)習(xí)
在機(jī)器學(xué)習(xí)方面，騰訊問卷有基于用戶答題的行為，構(gòu)建用戶答題的時(shí)間序列，得到一個(gè)評估用戶答題認(rèn)真度/可信度的評估模型，目前這個(gè)工具已經(jīng)上線到樣本庫填答的紅包發(fā)放鑒別能力中，提供給投放者對回答可信度和總體回答質(zhì)量做相應(yīng)參考。
在最早期我們通過ES去查找單份答卷用戶在答題過程中的所有用戶行為埋點(diǎn)數(shù)據(jù)來構(gòu)建序列數(shù)據(jù)進(jìn)行預(yù)測，將預(yù)測結(jié)果寫入DB；在近一年中，我們把查詢數(shù)據(jù)源經(jīng)過計(jì)算清洗后寫入按問卷和用戶為索引的ClickHouse數(shù)據(jù)源中，同時(shí)將服務(wù)與線上服務(wù)解耦，使用kafka來進(jìn)行通信；最后配置了消費(fèi)監(jiān)控和寫入監(jiān)控，使這個(gè)服務(wù)成為一個(gè)單獨(dú)維護(hù)的組件。以犧牲少許的實(shí)時(shí)性為代價(jià)大幅提升了預(yù)測速度和可用性。
2、實(shí)時(shí)風(fēng)控
基于實(shí)時(shí)層的數(shù)據(jù)聚合分發(fā)能力，我們在問卷系統(tǒng)中逐步搭建了一套對問卷維度進(jìn)行風(fēng)控的系統(tǒng)。在最早期的設(shè)計(jì)中，實(shí)時(shí)層基于小時(shí)間段窗口觸發(fā)計(jì)算，從明細(xì)數(shù)據(jù)流讀取計(jì)算到寫入下游系統(tǒng)之間的誤差能夠控制在秒級，支持了下游規(guī)則引擎的實(shí)時(shí)特征數(shù)據(jù)檢索。
在架構(gòu)上，風(fēng)控模型走的是全實(shí)時(shí)數(shù)倉鏈路，從Kafka明細(xì)中讀出前端上報(bào)信息和后端收集答卷的日志，在Flink中做實(shí)時(shí)的多窗口聚合寫入到下游的數(shù)據(jù)組件。在前期選型中，業(yè)務(wù)側(cè)希望能夠具有實(shí)時(shí)調(diào)用和短時(shí)間指標(biāo)回溯的能力，同時(shí)希望系統(tǒng)組件能夠相對輕，能從云上購買，最后我們選定了Kafka作為業(yè)務(wù)側(cè)實(shí)時(shí)接收窗口聚合結(jié)果的組件，PostgreSQL作為小時(shí)間段的回溯組件來構(gòu)建線上的風(fēng)控分析。
3、AB實(shí)驗(yàn)
目前，我們已經(jīng)在SaaS平臺內(nèi)對文案顯示、用戶邏輯等多方面做了很多次AB測試，通過pv上報(bào)的曝光和event埋點(diǎn)的轉(zhuǎn)化分析，能夠?qū)崟r(shí)構(gòu)建單個(gè)用戶的轉(zhuǎn)化行為；相同地，我們會對實(shí)驗(yàn)時(shí)間范圍內(nèi)的數(shù)據(jù)使用ClickHouse構(gòu)建用戶RBM，分析不同用戶在不同實(shí)驗(yàn)命中的表現(xiàn)情況。
總結(jié)
通過補(bǔ)齊一些基本的數(shù)據(jù)架構(gòu)和數(shù)據(jù)規(guī)范，目前我們在數(shù)據(jù)驅(qū)動的實(shí)踐上已經(jīng)走出了一條自己的路。隨著用戶調(diào)研類組件的發(fā)展、用戶分析需求的增加，其分析能力也會隨之增強(qiáng)，越來越多的數(shù)據(jù)能力正在沉淀成底層功能加入到SaaS服務(wù)側(cè)。
原文地址：騰訊CDC體驗(yàn)設(shè)計(jì)
作者：
轉(zhuǎn)載請注明：學(xué)UI網(wǎng)》數(shù)據(jù)工程在騰訊CDC的演進(jìn)
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責(zé)聲明：藍(lán)藍(lán)設(shè)計(jì)尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請及時(shí)與我們?nèi)〉寐?lián)系，我們立即更正或刪除。
藍(lán)藍(lán)設(shè)計(jì)( m.ocunn.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)、
UI設(shè)計(jì)公司、界面設(shè)計(jì)公司、UI設(shè)計(jì)服務(wù)公司、數(shù)據(jù)可視化設(shè)計(jì)公司、UI交互設(shè)計(jì)公司、高端網(wǎng)站設(shè)計(jì)公司、UI咨詢、用戶體驗(yàn)公司、軟件界面設(shè)計(jì)公司