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