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