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