據(jù)中臺(tái)實(shí)戰(zhàn)指南：從架構(gòu)規(guī)劃到性能調(diào)優(yōu)全解析)
1. 數(shù)據(jù)中臺(tái)不是什么神秘架構(gòu)而是一場(chǎng)數(shù)據(jù)治理戰(zhàn)役這兩年“數(shù)據(jù)中臺(tái)”這個(gè)詞被炒得厲害有人把它當(dāng)成數(shù)據(jù)團(tuán)隊(duì)的萬(wàn)能解藥有人覺得它就是一套平臺(tái)軟件買回來就能用。我在多個(gè)項(xiàng)目里做過中臺(tái)相關(guān)建設(shè)從最開始跟著喊口號(hào)到后來自己動(dòng)手梳理指標(biāo)、搭數(shù)倉(cāng)、調(diào)集群、壓測(cè)大屏渲染最大的感受是數(shù)據(jù)中臺(tái)本質(zhì)上不是一套系統(tǒng)而是把企業(yè)散落的“數(shù)據(jù)資產(chǎn)”重新組織、治理、服務(wù)化的一套方法論加工程體系。這次就以一個(gè)零售業(yè)務(wù)的真實(shí)案例為線索把這個(gè)過程完整拆開講包括架構(gòu)選型、集群規(guī)劃、數(shù)據(jù)接入、指標(biāo)治理以及最后落到數(shù)據(jù)大屏上的渲染優(yōu)化。先說清楚這個(gè)案例的背景。一家連鎖零售企業(yè)有線下門店、線上小程序、第三方外賣平臺(tái)三個(gè)業(yè)務(wù)入口每天產(chǎn)生的訂單、庫(kù)存、會(huì)員、商品、日志數(shù)據(jù)量不小。在建設(shè)數(shù)據(jù)中臺(tái)之前他們的數(shù)據(jù)使用方式是很典型的煙囪式運(yùn)營(yíng)部門讓開發(fā)從訂單庫(kù)里拉數(shù)據(jù)做報(bào)表財(cái)務(wù)部門又按自己的口徑統(tǒng)計(jì)銷售額市場(chǎng)部要投廣告效果分析再寫一套腳本去抽數(shù)據(jù)。結(jié)果就是大量重復(fù)開發(fā)指標(biāo)口徑對(duì)不上一套報(bào)表系統(tǒng)改了需求另外三套還要跟著改。數(shù)據(jù)中臺(tái)要解決的就是這類“重復(fù)建設(shè)、口徑混亂、響應(yīng)慢”的問題而不是單純地把 Hadoop 裝上、把 Kafaka 搭起來。這次建設(shè)我不只負(fù)責(zé)其中某一塊而是把從數(shù)據(jù)接入到服務(wù)出口的整條鏈路都走了一遍。文章會(huì)分成幾個(gè)大塊先講整體設(shè)計(jì)與架構(gòu)思路再說數(shù)據(jù)接入和標(biāo)準(zhǔn)化的細(xì)節(jié)接著是集群部署與計(jì)算資源規(guī)劃的實(shí)操方法然后重點(diǎn)聊一下數(shù)據(jù)服務(wù)層和可視化大屏的性能問題尤其是很多人都會(huì)遇到的“Qt 表格加載大數(shù)據(jù)卡頓”這個(gè)坑最后是這些年整理出來的常見問題和排查經(jīng)驗(yàn)。適合看這篇文章的人我默認(rèn)你是已經(jīng)被分配了“我們也要搞數(shù)據(jù)中臺(tái)”任務(wù)、但還沒想清楚從哪下手的工程師或架構(gòu)師或者你在做指標(biāo)管理、數(shù)據(jù)大屏、報(bào)表平臺(tái)想看看別人是怎么一步步把鏈路串起來的。文章里不會(huì)只給概念會(huì)盡量落到可執(zhí)行的參數(shù)、步驟和踩坑經(jīng)驗(yàn)上方便你對(duì)照著自己項(xiàng)目去套。2. 整體設(shè)計(jì)先用業(yè)務(wù)的尺子量完再考慮技術(shù)選型2.1 中臺(tái)要解決的三個(gè)真問題口徑、復(fù)用、響應(yīng)很多團(tuán)隊(duì)第一步就錯(cuò)了上來就選組件、搭集群結(jié)果搭完不知道跑什么業(yè)務(wù)。我做這個(gè)項(xiàng)目時(shí)第一件事不是寫代碼而是跟著業(yè)務(wù)方把現(xiàn)有的報(bào)表、看板、分析需求全翻了一遍。翻完之后發(fā)現(xiàn)他們真正痛的是三點(diǎn)。第一口徑不統(tǒng)一。同樣是“銷售額”財(cái)務(wù)算的是實(shí)收金額運(yùn)營(yíng)算的是訂單金額不含退款市場(chǎng)部算的是支付成功且剔除刷單的金額三套口徑對(duì)不上開會(huì)對(duì)數(shù)能吵半天。第二重復(fù)開發(fā)嚴(yán)重。每個(gè)部門都養(yǎng)著自己的“表哥表姐”腳本互相復(fù)制粘貼數(shù)據(jù)來源還不一樣。第三報(bào)表和臨時(shí)取數(shù)響應(yīng)太慢。遇到大促運(yùn)營(yíng)臨時(shí)要一個(gè)“按小時(shí)、按門店、按品類”的銷售分析數(shù)據(jù)團(tuán)隊(duì)要跑一兩天才能給出來等跑完活動(dòng)也快結(jié)束了。數(shù)據(jù)中臺(tái)的架構(gòu)設(shè)計(jì)本質(zhì)上是沖著這三個(gè)問題去的。它不止要建數(shù)倉(cāng)還要建一套“指標(biāo)標(biāo)準(zhǔn)”和“數(shù)據(jù)服務(wù)”體系。先統(tǒng)一口徑再把數(shù)據(jù)按統(tǒng)一標(biāo)準(zhǔn)接入、分層加工最后以 API 的方式對(duì)外輸出。業(yè)務(wù)方不需要關(guān)心底層數(shù)據(jù)從哪來、怎么算只要按約定好的指標(biāo)名和服務(wù)接口去取數(shù)這就解決了復(fù)用和響應(yīng)問題。2.2 中臺(tái)整體架構(gòu)分層這套架構(gòu)不是憑空設(shè)計(jì)的業(yè)界主流的中臺(tái)架構(gòu)基本都長(zhǎng)這樣我們只是結(jié)合業(yè)務(wù)做了裁剪?？偟姆謱邮菙?shù)據(jù)源層 → 數(shù)據(jù)接入層 → 數(shù)倉(cāng)加工層 → 數(shù)據(jù)服務(wù)層 → 應(yīng)用層。每個(gè)層次解決不同問題盡量不讓各層職責(zé)互相滲透。數(shù)據(jù)源層對(duì)應(yīng)三個(gè)業(yè)務(wù)入口的數(shù)據(jù)庫(kù)、日志、第三方平臺(tái)報(bào)表文件。接入層統(tǒng)一用 Canal 監(jiān)聽 MySQL binlog 進(jìn) Kafka日志用 Flume 采集離線批量同步用 DataX 或 Sqoop。數(shù)倉(cāng)層按 ODS、DWD、DWS、ADS 的標(biāo)準(zhǔn)四層模型做加工ODS 把原始數(shù)據(jù)原樣落地DWD 做清洗、去重、標(biāo)準(zhǔn)化DWS 按業(yè)務(wù)主題做匯總ADS 再面向具體應(yīng)用場(chǎng)景加工。服務(wù)層把 DWS 和 ADS 的結(jié)果封裝成指標(biāo) API統(tǒng)一暴露給上層。應(yīng)用層就是數(shù)據(jù)大屏、BI 報(bào)表、自助分析、對(duì)外數(shù)據(jù)接口這些。在這個(gè)架構(gòu)里我最想強(qiáng)調(diào)的一點(diǎn)是數(shù)據(jù)服務(wù)層不能省。很多團(tuán)隊(duì)建完數(shù)倉(cāng)就結(jié)束了應(yīng)用方還是直接連 Hive 或 ClickHouse 查表這是中臺(tái)失敗的常見伏筆。一旦應(yīng)用方繞過服務(wù)層直接觸達(dá)底表口徑控制就失效了中臺(tái)會(huì)慢慢退化成原來的煙囪式開發(fā)。對(duì)比維度傳統(tǒng)煙囪式數(shù)據(jù)中臺(tái)式指標(biāo)口徑各業(yè)務(wù)各自定義經(jīng)常沖突中臺(tái)統(tǒng)一注冊(cè)、統(tǒng)一發(fā)布數(shù)據(jù)加工每個(gè)報(bào)表一套腳本分層加工一次建設(shè)多處復(fù)用服務(wù)方式直接連庫(kù)/提數(shù)標(biāo)準(zhǔn)化API屏蔽底層表結(jié)構(gòu)需求響應(yīng)新需求重新開發(fā)通過已有主題數(shù)據(jù)快速組裝數(shù)據(jù)質(zhì)量無人統(tǒng)一負(fù)責(zé)監(jiān)控、告警、質(zhì)量評(píng)估體系2.3 建設(shè)路徑先治理再架構(gòu)后平臺(tái)我見過不少項(xiàng)目把順序搞反了。正確的路徑應(yīng)該是“業(yè)務(wù)梳理 → 指標(biāo)梳理 → 數(shù)據(jù)模型設(shè)計(jì) → 平臺(tái)搭建 → 任務(wù)開發(fā) → 服務(wù)化”。順序不能亂原因很簡(jiǎn)單如果指標(biāo)口徑?jīng)]定好數(shù)倉(cāng)模型設(shè)計(jì)就是空中樓閣模型沒定好集群和任務(wù)調(diào)度再牛也白搭。在業(yè)務(wù)梳理階段我們把所有業(yè)務(wù)過程的指標(biāo)按“原子指標(biāo) 修飾詞 時(shí)間周期”的方式拆。比如“昨日華東區(qū)門店線下訂單實(shí)收金額”這個(gè)指標(biāo)原子指標(biāo)是“實(shí)收金額”修飾詞是“華東區(qū)、門店、線下訂單”時(shí)間周期是“昨日”。這樣拆完你就能發(fā)現(xiàn)很多指標(biāo)其實(shí)共用同一個(gè)原子指標(biāo)只是修飾詞不同。原子指標(biāo)在數(shù)倉(cāng)里就對(duì)應(yīng)一張唯一的 DWS 匯總表后續(xù)不管哪里要用都是在這張表上組合查詢復(fù)用性一下子就出來了。平臺(tái)搭建階段我們選了 CDH 發(fā)行版作為 Hadoop 底座計(jì)算用 Spark 和 Flink調(diào)度用 DolphinScheduler查詢服務(wù)用 ClickHouse 和 Kafka元數(shù)據(jù)管理掛了一個(gè)自研的元數(shù)據(jù)中心。選型邏輯后面會(huì)詳細(xì)說這里不展開。3. 數(shù)據(jù)接入與標(biāo)準(zhǔn)化ODS 不是垃圾桶DWD 才是清洗主戰(zhàn)場(chǎng)3.1 多源異構(gòu)數(shù)據(jù)怎么統(tǒng)一接進(jìn)來這個(gè)項(xiàng)目的接入層分三類業(yè)務(wù)庫(kù)實(shí)時(shí)變更、日志數(shù)據(jù)、離線批量數(shù)據(jù)。業(yè)務(wù)庫(kù)主要是 MySQL我們用的方案是 Canal 監(jiān)聽主庫(kù) binlog解析成統(tǒng)一的 JSON 消息寫入 Kafka。注意這里有個(gè)細(xì)節(jié)binlog 監(jiān)聽只適合變更數(shù)據(jù)同步如果是線上大表做全量初始化我們還是會(huì)臨時(shí)用 DataX 先拉一次全量再切到 Canal 增量否則 binlog 積壓會(huì)把集群打掛。日志數(shù)據(jù)主要來自小程序前端埋點(diǎn)和后端訪問日志統(tǒng)一走 Flume 采集格式是規(guī)范后的 JSON 行包含 timestamp、event_id、user_id、page_id 等字段。第三方外賣平臺(tái)不提供數(shù)據(jù)庫(kù)權(quán)限只給 CSV 報(bào)表文件我們每天早上定時(shí)用 DataX 拉取到 HDFS。所有接入的數(shù)據(jù)第一道統(tǒng)一處理是補(bǔ)充技術(shù)字段如 source_system、biz_date、etl_time、敏感字段脫敏、統(tǒng)一編碼和時(shí)間格式。這一步在 ODS 層就要做掉一部分。我踩過的坑是一開始把清洗邏輯全部放到 DWD 才做導(dǎo)致 ODS 層接進(jìn)來的原始數(shù)據(jù)“臟亂差”下游開發(fā)還要重復(fù)清洗任務(wù)之間耦合很重。后來改成 ODS 只做最基礎(chǔ)的格式統(tǒng)一和簡(jiǎn)單過濾DWD 做真正意義上的業(yè)務(wù)清洗兩條邊界的職責(zé)才清晰。3.2 Kafka Topic 與數(shù)倉(cāng)分層設(shè)計(jì)的最佳實(shí)踐Kafka 的 topic 設(shè)計(jì)上我們一開始按數(shù)據(jù)源分比如 ordermysql、log_flume、report_csv。后來發(fā)現(xiàn)一個(gè)問題同一個(gè)訂單既要從 MySQL 同步狀態(tài)變更也要對(duì)應(yīng)用戶行為日志分開訂閱容易造成下游 join 時(shí)數(shù)據(jù)時(shí)序錯(cuò)亂。后續(xù)調(diào)整為按業(yè)務(wù)域分訂單域dwd_order、會(huì)員域dwd_member、商品域dwd_product、日志域dwd_log。同一個(gè)域下的實(shí)時(shí)與離線數(shù)據(jù)在這個(gè) topic 正則下統(tǒng)一管理Flink 消費(fèi)時(shí)也能更自然地對(duì)齊時(shí)間窗口。數(shù)倉(cāng)三層模型的建設(shè)我更愿意用“寬化”和“復(fù)用”兩個(gè)詞來概括。DWD 層做的最重要的事是把明細(xì)數(shù)據(jù)盡量寬表化把訂單、訂單明細(xì)、支付流水、門店信息、商品信息等關(guān)聯(lián)成一張大寬表這樣下游 DWS 去聚合時(shí)不需要反復(fù) join。DWS 層按主題域建匯總表比如訂單域日匯總、會(huì)員域日活躍表、商品域銷售排行表。ADS 層再根據(jù)大屏和報(bào)表需求做最終封裝粒度非常靈活。分層主要職責(zé)數(shù)據(jù)形態(tài)典型表ODS原樣接入格式統(tǒng)一全量/增量原始數(shù)據(jù)ods_order_infoDWD清洗、標(biāo)準(zhǔn)化、寬表化明細(xì)寬表dwd_order_detail_wideDWS按主題匯總、指標(biāo)沉淀輕度匯總dws_order_day_summaryADS按應(yīng)用場(chǎng)景定制高度匯總/預(yù)統(tǒng)計(jì)ads_screen_sales_hour3.3 指標(biāo)口徑統(tǒng)一從“吵不完的架”到“一張字典表”指標(biāo)口徑統(tǒng)一是整個(gè)中臺(tái)建設(shè)成敗的分水嶺。我們的做法是建了指標(biāo)字典把每個(gè)指標(biāo)對(duì)應(yīng)到唯一的原子指標(biāo)、修飾詞、數(shù)倉(cāng)表、計(jì)算邏輯、更新頻率。比如“銷售額”只能有一個(gè)定義來自 DWS 訂單日匯總表的實(shí)收金額字段包含已完成和已收貨訂單剔除退款和刷單訂單。任何業(yè)務(wù)方要取數(shù)必須引用字典里已登記的指標(biāo)不能自己另起爐灶。這里有個(gè)很現(xiàn)實(shí)的問題業(yè)務(wù)方已經(jīng)用舊口徑跑了好幾年報(bào)表你說改就改會(huì)有人不服。我們的處理方式是做“新舊口徑并行期”定義一個(gè)舊口徑的表保留三個(gè)月同時(shí)新口徑報(bào)表上線等業(yè)務(wù)確認(rèn)新口徑?jīng)]問題后再下掉舊表。這三個(gè)月里為了對(duì)齊我們做了很多數(shù)據(jù)校驗(yàn)工作隨機(jī)抽 10 天歷史數(shù)據(jù)舊口徑結(jié)果和新中臺(tái)結(jié)果逐一比對(duì)差異超過萬(wàn)分之五就回去查原因。等跑完這輪驗(yàn)證業(yè)務(wù)方心里的石頭才落了地。4. 計(jì)算與集群部署把每一臺(tái)機(jī)器的資源都算明白再動(dòng)手4.1 集群規(guī)模怎么估以數(shù)據(jù)量為起點(diǎn)反推這個(gè)項(xiàng)目的數(shù)據(jù)量日增量大概在 5TB 左右業(yè)務(wù)高峰期大促日能到 20TB總的 HDFS 存儲(chǔ)約半年內(nèi) 1PB。我們當(dāng)時(shí)規(guī)劃集群沒有拍腦袋而是先做了一輪計(jì)算。存儲(chǔ)方面HDFS 默認(rèn)三副本所以 1PB 邏輯數(shù)據(jù)需要 3PB 物理容量。加上數(shù)據(jù)保留策略、中間結(jié)果、臨時(shí)文件我們預(yù)留 20% 冗余物理存儲(chǔ)按 3.6PB 規(guī)劃。單臺(tái)機(jī)器如果配 8 塊 8TB 盤可用容量約 50TB還要扣掉系統(tǒng)盤、元數(shù)據(jù)開銷這樣數(shù)據(jù)節(jié)點(diǎn)大概需要 75-80 臺(tái)。為了應(yīng)對(duì)大促擴(kuò)容我們沒一次買夠而是按“日常 60 臺(tái) 彈性擴(kuò)容到 90 臺(tái)”的方式部署。計(jì)算資源方面Spark 離線任務(wù)主體跑在 YARN 上。當(dāng)時(shí)線上資源基線是 3 萬(wàn)核、200TB 內(nèi)存按每節(jié)點(diǎn) 64 核、512GB 內(nèi)存、50 節(jié)點(diǎn)計(jì)算。我們把任務(wù)分成實(shí)時(shí)、離線、adhoc 三類通過 YARN 隊(duì)列劃分實(shí)時(shí)隊(duì)列 20% 資源離線隊(duì)列 60%adhoc 查詢隊(duì)列 20%。這樣設(shè)計(jì)是為了避免臨時(shí)跑一個(gè) adhoc 查詢把離線核心任務(wù)擠掉。4.2 部署細(xì)節(jié)HA 別省壓縮別亂用批次別貪多集群部署時(shí)的幾個(gè)關(guān)鍵細(xì)節(jié)我直接列出來每一項(xiàng)都是踩過坑換來的經(jīng)驗(yàn)Namenode 和 ResourceManager 一定要做 HA心跳自動(dòng)切換。我們前期圖省事沒配后來一次機(jī)房維護(hù)導(dǎo)致 Nomenode 單點(diǎn)故障整個(gè)集群停了大半天。數(shù)據(jù)壓縮格式我們統(tǒng)一選 ORC Snappy。ORC 列式存儲(chǔ)對(duì)分析查詢友好Snappy 壓縮和解壓速度快壓縮比雖然不是最高但綜合性能最好。不要混用多種壓縮格式否則下游讀文件時(shí)一會(huì)兒解壓這個(gè)一會(huì)兒解壓那個(gè)效率極低。Spark 任務(wù)提交參數(shù)不要亂調(diào)。我們一開始盲目加大 executor memory導(dǎo)致集群內(nèi)存碎片化嚴(yán)重。最終經(jīng)驗(yàn)是單 executor 3-5GB 內(nèi)存、2-4 核比較平穩(wěn)大量大批次任務(wù)比小批次任務(wù)更容易導(dǎo)致資源競(jìng)爭(zhēng)和 task 長(zhǎng)尾。Flink 的 Checkpoint 間隔默認(rèn) 5 分鐘但我們實(shí)時(shí)大屏對(duì)準(zhǔn)確性要求很高就改成了 60 秒一次使用 RocksDB 增量 Checkpoint并且開啟自動(dòng)無鎖恢復(fù)。這樣才能在節(jié)點(diǎn)故障后更快恢復(fù)狀態(tài)。配置項(xiàng)我們的取值說明HDFS 副本數(shù)3常規(guī)數(shù)據(jù) 3 副本臨時(shí)數(shù)據(jù) 1 副本HDFS 塊大小128MB大文件多128MB 均衡了元數(shù)據(jù)和 IOSpark executor 內(nèi)存4GB避免資源碎片和頻繁 GCSpark executor 核數(shù)2提升單節(jié)點(diǎn)并行度避免大任務(wù)獨(dú)占Flink Checkpoint 間隔60s實(shí)時(shí)指標(biāo)恢復(fù)時(shí)間要求高壓縮格式ORC Snappy讀寫性能和壓縮比平衡4.3 調(diào)度與血緣讓任務(wù)“跑得動(dòng)還看得清”調(diào)度我們選的是 DolphinScheduler。選它的原因很簡(jiǎn)單支持中文界面、可視化 DAG 編排、帶告警機(jī)制能直接對(duì)接 Hive 和 Spark部署也輕量。離線任務(wù)每天凌晨跑一個(gè)全量管道白天每小時(shí)跑一次增量管道調(diào)度依賴用時(shí)間窗控制避免任務(wù)之間因?yàn)樯嫌瓮睃c(diǎn)而產(chǎn)生連環(huán)延遲。光有調(diào)度還不夠中臺(tái)的可治理性很大程度依賴數(shù)據(jù)血緣。我們自研了元數(shù)據(jù)中心它會(huì)從 Spark、Hive、Flink 的執(zhí)行日志和 Catalog 中解析出“表 → 表、任務(wù) → 表”的血緣關(guān)系。這樣當(dāng)某張 DWS 表的字段口徑需要調(diào)整時(shí)能快速找到所有下游任務(wù)提前評(píng)估影響面而不是改完再被業(yè)務(wù)方投訴“報(bào)表數(shù)據(jù)怎么突然不對(duì)了”。5. 數(shù)據(jù)服務(wù)與可視化大屏別讓一塊大屏暴露整個(gè)中臺(tái)的性能短板5.1 數(shù)據(jù)服務(wù)層輸出標(biāo)準(zhǔn)化指標(biāo)而不是裸表數(shù)據(jù)服務(wù)層是整個(gè)中臺(tái)對(duì)外輸出的窗口也是最容易被“省掉”的一層。它做的事情是把 DWS/ADS 的結(jié)果封裝成 API提供兩類接口指標(biāo)查詢接口例如按門店、品類、小時(shí)查銷售額和明細(xì)查詢接口例如查某訂單詳情。指標(biāo)查詢的核心是預(yù)聚合。大屏上展示的“今日實(shí)時(shí)銷售額”“本小時(shí)訂單量”這類指標(biāo)我們不可能實(shí)時(shí)去查明細(xì)而是在 DWS 層做分鐘級(jí)預(yù)聚合結(jié)果放到 Redis 緩存接口直接讀緩存響應(yīng)時(shí)間能壓在 200ms 以內(nèi)。明細(xì)查詢則落到 ClickHouseClickHouse 的列式存儲(chǔ)和向量化執(zhí)行在這種場(chǎng)景下特別給力億萬(wàn)級(jí)明細(xì)表按條件過濾也能秒出結(jié)果。我個(gè)人強(qiáng)烈建議數(shù)據(jù)服務(wù)層盡量用統(tǒng)一網(wǎng)關(guān)包一層不要直接把 ClickHouse 或 Doris 的連接信息發(fā)給應(yīng)用方。連接信息一旦擴(kuò)散應(yīng)用的臨時(shí)查詢和報(bào)表直連都會(huì)不受控中臺(tái)的口徑治理就形同虛設(shè)。5.2 數(shù)據(jù)大屏常見卡頓QTableWidget 是怎么一步一步拖垮你的講到可視化數(shù)據(jù)大屏是這個(gè)案例里非常典型的一個(gè)場(chǎng)景。大屏一部分是指標(biāo)卡片和圖表另一部分是實(shí)時(shí)滾動(dòng)的明細(xì)表格展示最近 1000 條訂單記錄。我們用 Qt 做桌面端大屏的客戶端一開始圖省事表格控件直接用了 QTableWidget結(jié)果數(shù)據(jù)一多就卡得不能自理。這個(gè)問題我相信不只我一個(gè)人遇到所以專門拉出來講講。QTableWidget 卡的根本原因是它默認(rèn)使用 QStandardItemModel每一條數(shù)據(jù)都要新建一個(gè) QTableWidgetItem 對(duì)象并塞進(jìn)表格。如果你要顯示 1 萬(wàn)行、每行 10 列意味著你要?jiǎng)?chuàng)建 10 萬(wàn)個(gè) QTableWidgetItem 對(duì)象。10 萬(wàn)個(gè)小對(duì)象的內(nèi)存開銷和創(chuàng)建耗時(shí)不說QTableWidget 還會(huì)為每個(gè)格子準(zhǔn)備畫刷、編輯代理等額外資源內(nèi)存爆炸是必然的。更要命的是QTableWidget 的視圖在沒有優(yōu)化的情況下會(huì)對(duì)可見區(qū)域外的單元格做大量刷新和判空處理尤其是設(shè)置了 alternatingRowColors、豎向滾動(dòng)的時(shí)候CPU 消耗非常大。很多人問“為什么我只看到幾十行也會(huì)卡”那是因?yàn)?Qt 的表格視圖并不是只畫屏幕上那幾十行它內(nèi)部要處理所有“可能的單元格”的取數(shù)邏輯。你的瓶頸其實(shí)出在 Model 承載了太多數(shù)據(jù)而不是 View 畫了多少。對(duì)比維度QTableWidgetQTableView 自定義 Model數(shù)據(jù)存儲(chǔ)內(nèi)部 Item 對(duì)象每條數(shù)據(jù)都要建對(duì)象外部數(shù)據(jù)源Model 按需提供數(shù)據(jù)滾動(dòng)性能全量 Item 參與計(jì)算容易卡頓只渲染可見區(qū)原生支持虛擬滾動(dòng)內(nèi)存占用大小數(shù)據(jù)仍存在業(yè)務(wù)側(cè)不復(fù)制靈活性低高可自定義排序、代理、懶加載5.3 從 QTableWidget 換到 QTableView 自定義 QAbstractTableModel把 QTableWidget 換成 QTableView 自定義 QAbstractTableModel這算是 Qt 表格大數(shù)據(jù)的標(biāo)準(zhǔn)解法。原理很簡(jiǎn)單QTableView 只負(fù)責(zé)繪制可見區(qū)域的單元格通過 model 的 rowCount、columnCount、data 三個(gè)方法按需獲取數(shù)據(jù)而不是預(yù)先創(chuàng)建所有 item。換句話說你的原始數(shù)據(jù)放在自己的容器里Model 只做“取數(shù)映射”視圖滾動(dòng)時(shí)它會(huì)反復(fù)調(diào)用 data 方法讀取需要的那幾十行數(shù)據(jù)。下面給一段可以直接參考的 model 實(shí)現(xiàn)框架。我先定義一個(gè) DataModel構(gòu)造函數(shù)接收外部數(shù)據(jù)源的引用data 方法里按 role 返回?cái)?shù)據(jù)行數(shù)和列數(shù)直接從外部數(shù)據(jù)源獲取。關(guān)鍵點(diǎn)在于不要讓 model 持有超大數(shù)據(jù)副本只持引用即可。class DataModel : public QAbstractTableModel { Q_OBJECT public: explicit DataModel(QVectorQVectorQVariant* dataPtr, QObject* parent nullptr) : QAbstractTableModel(parent), m_dataPtr(dataPtr) {} int rowCount(const QModelIndex parent QModelIndex()) const override { if (parent.isValid()) return 0; return m_dataPtr ? m_dataPtr-size() : 0; } int columnCount(const QModelIndex parent QModelIndex()) const override { if (parent.isValid()) return 0; return 10; // 固定列數(shù)具體按業(yè)務(wù)來 } QVariant data(const QModelIndex index, int role) const override { if (!index.isValid() || !m_dataPtr) return QVariant(); if (role Qt::DisplayRole || role Qt::EditRole) { return m_dataPtr-at(index.row()).at(index.column()); } return QVariant(); } QVariant headerData(int section, Qt::Orientation orientation, int role) const override { if (role ! Qt::DisplayRole) return QVariant(); if (orientation Qt::Horizontal) { // 返回列名例order_idstore_nameamountstatus... return m_header[section]; } return QString::number(section 1); } private: QVectorQVectorQVariant* m_dataPtr; QStringList m_header {訂單號(hào), 門店, 金額, 狀態(tài)}; };換成這個(gè) model 之后你會(huì)立刻感受到滾動(dòng)的順暢。因?yàn)?QTableView 只請(qǐng)求當(dāng)前可見區(qū)域約幾十行的 data即使底層有幾十萬(wàn)、上百萬(wàn)條記錄性能也能保持在很穩(wěn)定水平。視圖一次只顯示幾十行這恰恰是它高效的原因并不是 bug是虛擬化機(jī)制的正常表現(xiàn)。換用 QTableView 之后還有幾步優(yōu)化建議調(diào)用 setUniformRowHeights(true)它假設(shè)所有行高一致可以大幅減少滾動(dòng)時(shí)的布局計(jì)算setVerticalScrollMode(QAbstractItemView::ScrollPerPixel) 讓滾動(dòng)更平滑避免在高頻滾動(dòng)時(shí) setAlternatingRowColors(true)這個(gè)選項(xiàng)在數(shù)據(jù)量大時(shí)反而會(huì)增加繪制次數(shù)。如果還需要更極致的性能可以考慮用 QSortFilterProxyModel 做排序過濾或者把分頁(yè)數(shù)據(jù)源換成真正懶加載每次只加載當(dāng)前窗口范圍內(nèi)的數(shù)據(jù)。5.4 大屏背后還有數(shù)據(jù)鏈路的緩存與降級(jí)方案表格控件優(yōu)化只是大屏體驗(yàn)的一部分更重要的還是保證數(shù)據(jù)接口穩(wěn)定。我們?cè)诖笃练?wù)端做了三層保障Redis 做指標(biāo)緩存接口命中緩存直接返回緩存失效時(shí)才回源查詢 ClickHouseClickHouse 如果也扛不住再走一層降級(jí)策略比如大屏自動(dòng)切換到 DWS 預(yù)匯總的小表而不是讓用戶看到白屏或報(bào)錯(cuò)。這里有一個(gè)小技巧值得提一下大屏接口的響應(yīng)時(shí)間標(biāo)準(zhǔn)是“P95 必須小于 300msP99 必須小于 1s”為了達(dá)到這個(gè)目標(biāo)我們?cè)?DWS 層專門建了幾張“秒級(jí)聚合表”每 15 秒用 Flink 做一次滾動(dòng)聚合把最新 1 小時(shí)的數(shù)據(jù)一次性算出結(jié)果寫入 ClickHouse。這樣大屏反復(fù)刷新的數(shù)據(jù)不會(huì)直接打到明細(xì)層而是打在這張聚合表上查詢壓力小很多。6. 常見問題與排查技巧實(shí)錄中臺(tái)建設(shè)中最容易翻車的地方6.1 離線任務(wù)延遲導(dǎo)致大屏數(shù)據(jù)斷層大屏上“今日銷售額”是一個(gè)小時(shí)級(jí)別的實(shí)時(shí)指標(biāo)和離線報(bào)表的日終結(jié)果偶爾對(duì)不上業(yè)務(wù)方會(huì)質(zhì)疑“你們數(shù)據(jù)是不是壞了”。這個(gè)問題本質(zhì)是實(shí)時(shí)和離線兩套鏈路計(jì)算的邏輯不完全一致。比如實(shí)時(shí)鏈路統(tǒng)計(jì)的訂單狀態(tài)是“支付完成即計(jì)入”離線鏈路要求“訂單完成且退款剔除”兩邊本來就存在時(shí)間差窗口。處理辦法是分場(chǎng)景說明口徑大屏標(biāo)注“實(shí)時(shí)口徑最終以日終報(bào)表為準(zhǔn)”同時(shí)跑一個(gè)每日對(duì)賬任務(wù)把實(shí)時(shí)鏈路前一天的結(jié)果和離線日終結(jié)果做比對(duì)差額超過閾值自動(dòng)告警。這樣數(shù)據(jù)鏈路是否可靠業(yè)務(wù)方可以用對(duì)賬結(jié)果判斷而不是聽我們拍胸脯保證。6.2 集群資源被臨時(shí)查詢打爆中臺(tái)開放了自助分析能力之后總會(huì)有業(yè)務(wù)同學(xué)寫“三表大 join、全表掃描”的查詢把集群資源吃光影響正式調(diào)度任務(wù)。我們解決方法是三管齊下YARN 隊(duì)列做了嚴(yán)格配額adhoc 查詢只分到 20% 資源池超過就排隊(duì)DQC 數(shù)據(jù)質(zhì)量中心對(duì)慢查詢做規(guī)則攔截掃描行數(shù)超過一定量就自動(dòng)熔斷再給每個(gè)賬號(hào)設(shè)定單次查詢最大掃描量避免“一次性全表掃”這種操作。常見問題根因排查思路處理辦法大屏接口慢ClickHouse 查詢掃全表或緩存過期頻繁看慢查詢?nèi)罩尽⒖疵新始?DWS 預(yù)聚合、Redis 緩存、限流降級(jí)實(shí)時(shí)與離線數(shù)據(jù)對(duì)不上兩條鏈路統(tǒng)計(jì)口徑不同抽樣對(duì)賬比對(duì)差異數(shù)據(jù)范圍統(tǒng)一口徑文檔每日定時(shí)對(duì)賬告警Kafka 消費(fèi)延遲分區(qū)數(shù)少、消費(fèi)者并行度低查看消費(fèi)組 lag檢查 Flink 并行度增加 topic 分區(qū)、調(diào)大 Flink 并行度Spark 任務(wù)數(shù)據(jù)傾斜熱點(diǎn) key 導(dǎo)致單 task 處理量大看 task 耗時(shí)分布確認(rèn) task 數(shù)據(jù)量加鹽分桶、廣播小表、改 join 策略Qt 表格滾動(dòng)卡頓使用了 QTableWidget 或 model 不虛擬化檢查 item 數(shù)量和 data 調(diào)用次數(shù)換 QTableView 自定義 QAbstractTableModel6.3 數(shù)據(jù)質(zhì)量監(jiān)控一定要前置不要等報(bào)表錯(cuò)了再救火關(guān)于數(shù)據(jù)中臺(tái)我最后想聊的是“治理”兩個(gè)字。平臺(tái)搭好、任務(wù)跑通只是開始真正決定中臺(tái)能不能長(zhǎng)期活下去的是數(shù)據(jù)質(zhì)量監(jiān)控和治理機(jī)制。我們監(jiān)控體系每個(gè)月能發(fā)現(xiàn)上百個(gè)潛在問題源系統(tǒng)字段枚舉值變化、上游任務(wù)延遲、指標(biāo)翻倍異常等等這些問題大部分都是靠規(guī)則提前擋住的。每個(gè)核心任務(wù)都要配置“主鍵唯一性校驗(yàn)、表行數(shù)波動(dòng)監(jiān)控、字段空值率監(jiān)控”。這些規(guī)則在任務(wù)完成后自動(dòng)觸發(fā)如果異常會(huì)阻塞下游任務(wù)執(zhí)行并告警到責(zé)任人。可以說沒有數(shù)據(jù)質(zhì)量監(jiān)控的中臺(tái)早晚會(huì)退化成“數(shù)據(jù)沼澤”。7. 這個(gè)內(nèi)容后續(xù)還可以這樣擴(kuò)展如果你正在規(guī)劃數(shù)據(jù)中臺(tái)我建議不要把全部精力放在組件選型和集群參數(shù)上。中臺(tái)本質(zhì)是治理工程把指標(biāo)口徑、數(shù)據(jù)模型、質(zhì)量監(jiān)控這三件事做扎實(shí)比堆多少組件都重要。再分享一個(gè)最后才踩到的經(jīng)驗(yàn)第一次建設(shè)數(shù)據(jù)中臺(tái)范圍不要鋪太大。先挑一個(gè)業(yè)務(wù)域比如訂單域做端到端打通從數(shù)據(jù)接入到指標(biāo)展示全部跑通再橫向擴(kuò)展到其他域。不要一上來就規(guī)劃 20 個(gè)業(yè)務(wù)域、50 個(gè)主題那樣項(xiàng)目周期會(huì)被拖到半年以上團(tuán)隊(duì)熱情也會(huì)被消磨掉。一個(gè)小而完整的成功樣板比一個(gè)宏大到不了了之的規(guī)劃有效得多。 數(shù)據(jù)中臺(tái)實(shí)戰(zhàn)指南：從架構(gòu)規(guī)劃到性能調(diào)優(yōu)全解析
1. 數(shù)據(jù)中臺(tái)不是什么神秘架構(gòu)而是一場(chǎng)數(shù)據(jù)治理戰(zhàn)役這兩年“數(shù)據(jù)中臺(tái)”這個(gè)詞被炒得厲害有人把它當(dāng)成數(shù)據(jù)團(tuán)隊(duì)的萬(wàn)能解藥有人覺得它就是一套平臺(tái)軟件買回來就能用。我在多個(gè)項(xiàng)目里做過中臺(tái)相關(guān)建設(shè)從最開始跟著喊口號(hào)到后來自己動(dòng)手梳理指標(biāo)、搭數(shù)倉(cāng)、調(diào)集群、壓測(cè)大屏渲染最大的感受是數(shù)據(jù)中臺(tái)本質(zhì)上不是一套系統(tǒng)而是把企業(yè)散落的“數(shù)據(jù)資產(chǎn)”重新組織、治理、服務(wù)化的一套方法論加工程體系。這次就以一個(gè)零售業(yè)務(wù)的真實(shí)案例為線索把這個(gè)過程完整拆開講包括架構(gòu)選型、集群規(guī)劃、數(shù)據(jù)接入、指標(biāo)治理以及最后落到數(shù)據(jù)大屏上的渲染優(yōu)化。先說清楚這個(gè)案例的背景。一家連鎖零售企業(yè)有線下門店、線上小程序、第三方外賣平臺(tái)三個(gè)業(yè)務(wù)入口每天產(chǎn)生的訂單、庫(kù)存、會(huì)員、商品、日志數(shù)據(jù)量不小。在建設(shè)數(shù)據(jù)中臺(tái)之前他們的數(shù)據(jù)使用方式是很典型的煙囪式運(yùn)營(yíng)部門讓開發(fā)從訂單庫(kù)里拉數(shù)據(jù)做報(bào)表財(cái)務(wù)部門又按自己的口徑統(tǒng)計(jì)銷售額市場(chǎng)部要投廣告效果分析再寫一套腳本去抽數(shù)據(jù)。結(jié)果就是大量重復(fù)開發(fā)指標(biāo)口徑對(duì)不上一套報(bào)表系統(tǒng)改了需求另外三套還要跟著改。數(shù)據(jù)中臺(tái)要解決的就是這類“重復(fù)建設(shè)、口徑混亂、響應(yīng)慢”的問題而不是單純地把 Hadoop 裝上、把 Kafaka 搭起來。這次建設(shè)我不只負(fù)責(zé)其中某一塊而是把從數(shù)據(jù)接入到服務(wù)出口的整條鏈路都走了一遍。文章會(huì)分成幾個(gè)大塊先講整體設(shè)計(jì)與架構(gòu)思路再說數(shù)據(jù)接入和標(biāo)準(zhǔn)化的細(xì)節(jié)接著是集群部署與計(jì)算資源規(guī)劃的實(shí)操方法然后重點(diǎn)聊一下數(shù)據(jù)服務(wù)層和可視化大屏的性能問題尤其是很多人都會(huì)遇到的“Qt 表格加載大數(shù)據(jù)卡頓”這個(gè)坑最后是這些年整理出來的常見問題和排查經(jīng)驗(yàn)。適合看這篇文章的人我默認(rèn)你是已經(jīng)被分配了“我們也要搞數(shù)據(jù)中臺(tái)”任務(wù)、但還沒想清楚從哪下手的工程師或架構(gòu)師或者你在做指標(biāo)管理、數(shù)據(jù)大屏、報(bào)表平臺(tái)想看看別人是怎么一步步把鏈路串起來的。文章里不會(huì)只給概念會(huì)盡量落到可執(zhí)行的參數(shù)、步驟和踩坑經(jīng)驗(yàn)上方便你對(duì)照著自己項(xiàng)目去套。2. 整體設(shè)計(jì)先用業(yè)務(wù)的尺子量完再考慮技術(shù)選型2.1 中臺(tái)要解決的三個(gè)真問題口徑、復(fù)用、響應(yīng)很多團(tuán)隊(duì)第一步就錯(cuò)了上來就選組件、搭集群結(jié)果搭完不知道跑什么業(yè)務(wù)。我做這個(gè)項(xiàng)目時(shí)第一件事不是寫代碼而是跟著業(yè)務(wù)方把現(xiàn)有的報(bào)表、看板、分析需求全翻了一遍。翻完之后發(fā)現(xiàn)他們真正痛的是三點(diǎn)。第一口徑不統(tǒng)一。同樣是“銷售額”財(cái)務(wù)算的是實(shí)收金額運(yùn)營(yíng)算的是訂單金額不含退款市場(chǎng)部算的是支付成功且剔除刷單的金額三套口徑對(duì)不上開會(huì)對(duì)數(shù)能吵半天。第二重復(fù)開發(fā)嚴(yán)重。每個(gè)部門都養(yǎng)著自己的“表哥表姐”腳本互相復(fù)制粘貼數(shù)據(jù)來源還不一樣。第三報(bào)表和臨時(shí)取數(shù)響應(yīng)太慢。遇到大促運(yùn)營(yíng)臨時(shí)要一個(gè)“按小時(shí)、按門店、按品類”的銷售分析數(shù)據(jù)團(tuán)隊(duì)要跑一兩天才能給出來等跑完活動(dòng)也快結(jié)束了。數(shù)據(jù)中臺(tái)的架構(gòu)設(shè)計(jì)本質(zhì)上是沖著這三個(gè)問題去的。它不止要建數(shù)倉(cāng)還要建一套“指標(biāo)標(biāo)準(zhǔn)”和“數(shù)據(jù)服務(wù)”體系。先統(tǒng)一口徑再把數(shù)據(jù)按統(tǒng)一標(biāo)準(zhǔn)接入、分層加工最后以 API 的方式對(duì)外輸出。業(yè)務(wù)方不需要關(guān)心底層數(shù)據(jù)從哪來、怎么算只要按約定好的指標(biāo)名和服務(wù)接口去取數(shù)這就解決了復(fù)用和響應(yīng)問題。2.2 中臺(tái)整體架構(gòu)分層這套架構(gòu)不是憑空設(shè)計(jì)的業(yè)界主流的中臺(tái)架構(gòu)基本都長(zhǎng)這樣我們只是結(jié)合業(yè)務(wù)做了裁剪?？偟姆謱邮菙?shù)據(jù)源層 → 數(shù)據(jù)接入層 → 數(shù)倉(cāng)加工層 → 數(shù)據(jù)服務(wù)層 → 應(yīng)用層。每個(gè)層次解決不同問題盡量不讓各層職責(zé)互相滲透。數(shù)據(jù)源層對(duì)應(yīng)三個(gè)業(yè)務(wù)入口的數(shù)據(jù)庫(kù)、日志、第三方平臺(tái)報(bào)表文件。接入層統(tǒng)一用 Canal 監(jiān)聽 MySQL binlog 進(jìn) Kafka日志用 Flume 采集離線批量同步用 DataX 或 Sqoop。數(shù)倉(cāng)層按 ODS、DWD、DWS、ADS 的標(biāo)準(zhǔn)四層模型做加工ODS 把原始數(shù)據(jù)原樣落地DWD 做清洗、去重、標(biāo)準(zhǔn)化DWS 按業(yè)務(wù)主題做匯總ADS 再面向具體應(yīng)用場(chǎng)景加工。服務(wù)層把 DWS 和 ADS 的結(jié)果封裝成指標(biāo) API統(tǒng)一暴露給上層。應(yīng)用層就是數(shù)據(jù)大屏、BI 報(bào)表、自助分析、對(duì)外數(shù)據(jù)接口這些。在這個(gè)架構(gòu)里我最想強(qiáng)調(diào)的一點(diǎn)是數(shù)據(jù)服務(wù)層不能省。很多團(tuán)隊(duì)建完數(shù)倉(cāng)就結(jié)束了應(yīng)用方還是直接連 Hive 或 ClickHouse 查表這是中臺(tái)失敗的常見伏筆。一旦應(yīng)用方繞過服務(wù)層直接觸達(dá)底表口徑控制就失效了中臺(tái)會(huì)慢慢退化成原來的煙囪式開發(fā)。對(duì)比維度傳統(tǒng)煙囪式數(shù)據(jù)中臺(tái)式指標(biāo)口徑各業(yè)務(wù)各自定義經(jīng)常沖突中臺(tái)統(tǒng)一注冊(cè)、統(tǒng)一發(fā)布數(shù)據(jù)加工每個(gè)報(bào)表一套腳本分層加工一次建設(shè)多處復(fù)用服務(wù)方式直接連庫(kù)/提數(shù)標(biāo)準(zhǔn)化API屏蔽底層表結(jié)構(gòu)需求響應(yīng)新需求重新開發(fā)通過已有主題數(shù)據(jù)快速組裝數(shù)據(jù)質(zhì)量無人統(tǒng)一負(fù)責(zé)監(jiān)控、告警、質(zhì)量評(píng)估體系2.3 建設(shè)路徑先治理再架構(gòu)后平臺(tái)我見過不少項(xiàng)目把順序搞反了。正確的路徑應(yīng)該是“業(yè)務(wù)梳理 → 指標(biāo)梳理 → 數(shù)據(jù)模型設(shè)計(jì) → 平臺(tái)搭建 → 任務(wù)開發(fā) → 服務(wù)化”。順序不能亂原因很簡(jiǎn)單如果指標(biāo)口徑?jīng)]定好數(shù)倉(cāng)模型設(shè)計(jì)就是空中樓閣模型沒定好集群和任務(wù)調(diào)度再牛也白搭。在業(yè)務(wù)梳理階段我們把所有業(yè)務(wù)過程的指標(biāo)按“原子指標(biāo) 修飾詞 時(shí)間周期”的方式拆。比如“昨日華東區(qū)門店線下訂單實(shí)收金額”這個(gè)指標(biāo)原子指標(biāo)是“實(shí)收金額”修飾詞是“華東區(qū)、門店、線下訂單”時(shí)間周期是“昨日”。這樣拆完你就能發(fā)現(xiàn)很多指標(biāo)其實(shí)共用同一個(gè)原子指標(biāo)只是修飾詞不同。原子指標(biāo)在數(shù)倉(cāng)里就對(duì)應(yīng)一張唯一的 DWS 匯總表后續(xù)不管哪里要用都是在這張表上組合查詢復(fù)用性一下子就出來了。平臺(tái)搭建階段我們選了 CDH 發(fā)行版作為 Hadoop 底座計(jì)算用 Spark 和 Flink調(diào)度用 DolphinScheduler查詢服務(wù)用 ClickHouse 和 Kafka元數(shù)據(jù)管理掛了一個(gè)自研的元數(shù)據(jù)中心。選型邏輯后面會(huì)詳細(xì)說這里不展開。3. 數(shù)據(jù)接入與標(biāo)準(zhǔn)化ODS 不是垃圾桶DWD 才是清洗主戰(zhàn)場(chǎng)3.1 多源異構(gòu)數(shù)據(jù)怎么統(tǒng)一接進(jìn)來這個(gè)項(xiàng)目的接入層分三類業(yè)務(wù)庫(kù)實(shí)時(shí)變更、日志數(shù)據(jù)、離線批量數(shù)據(jù)。業(yè)務(wù)庫(kù)主要是 MySQL我們用的方案是 Canal 監(jiān)聽主庫(kù) binlog解析成統(tǒng)一的 JSON 消息寫入 Kafka。注意這里有個(gè)細(xì)節(jié)binlog 監(jiān)聽只適合變更數(shù)據(jù)同步如果是線上大表做全量初始化我們還是會(huì)臨時(shí)用 DataX 先拉一次全量再切到 Canal 增量否則 binlog 積壓會(huì)把集群打掛。日志數(shù)據(jù)主要來自小程序前端埋點(diǎn)和后端訪問日志統(tǒng)一走 Flume 采集格式是規(guī)范后的 JSON 行包含 timestamp、event_id、user_id、page_id 等字段。第三方外賣平臺(tái)不提供數(shù)據(jù)庫(kù)權(quán)限只給 CSV 報(bào)表文件我們每天早上定時(shí)用 DataX 拉取到 HDFS。所有接入的數(shù)據(jù)第一道統(tǒng)一處理是補(bǔ)充技術(shù)字段如 source_system、biz_date、etl_time、敏感字段脫敏、統(tǒng)一編碼和時(shí)間格式。這一步在 ODS 層就要做掉一部分。我踩過的坑是一開始把清洗邏輯全部放到 DWD 才做導(dǎo)致 ODS 層接進(jìn)來的原始數(shù)據(jù)“臟亂差”下游開發(fā)還要重復(fù)清洗任務(wù)之間耦合很重。后來改成 ODS 只做最基礎(chǔ)的格式統(tǒng)一和簡(jiǎn)單過濾DWD 做真正意義上的業(yè)務(wù)清洗兩條邊界的職責(zé)才清晰。3.2 Kafka Topic 與數(shù)倉(cāng)分層設(shè)計(jì)的最佳實(shí)踐Kafka 的 topic 設(shè)計(jì)上我們一開始按數(shù)據(jù)源分比如 ordermysql、log_flume、report_csv。后來發(fā)現(xiàn)一個(gè)問題同一個(gè)訂單既要從 MySQL 同步狀態(tài)變更也要對(duì)應(yīng)用戶行為日志分開訂閱容易造成下游 join 時(shí)數(shù)據(jù)時(shí)序錯(cuò)亂。后續(xù)調(diào)整為按業(yè)務(wù)域分訂單域dwd_order、會(huì)員域dwd_member、商品域dwd_product、日志域dwd_log。同一個(gè)域下的實(shí)時(shí)與離線數(shù)據(jù)在這個(gè) topic 正則下統(tǒng)一管理Flink 消費(fèi)時(shí)也能更自然地對(duì)齊時(shí)間窗口。數(shù)倉(cāng)三層模型的建設(shè)我更愿意用“寬化”和“復(fù)用”兩個(gè)詞來概括。DWD 層做的最重要的事是把明細(xì)數(shù)據(jù)盡量寬表化把訂單、訂單明細(xì)、支付流水、門店信息、商品信息等關(guān)聯(lián)成一張大寬表這樣下游 DWS 去聚合時(shí)不需要反復(fù) join。DWS 層按主題域建匯總表比如訂單域日匯總、會(huì)員域日活躍表、商品域銷售排行表。ADS 層再根據(jù)大屏和報(bào)表需求做最終封裝粒度非常靈活。分層主要職責(zé)數(shù)據(jù)形態(tài)典型表ODS原樣接入格式統(tǒng)一全量/增量原始數(shù)據(jù)ods_order_infoDWD清洗、標(biāo)準(zhǔn)化、寬表化明細(xì)寬表dwd_order_detail_wideDWS按主題匯總、指標(biāo)沉淀輕度匯總dws_order_day_summaryADS按應(yīng)用場(chǎng)景定制高度匯總/預(yù)統(tǒng)計(jì)ads_screen_sales_hour3.3 指標(biāo)口徑統(tǒng)一從“吵不完的架”到“一張字典表”指標(biāo)口徑統(tǒng)一是整個(gè)中臺(tái)建設(shè)成敗的分水嶺。我們的做法是建了指標(biāo)字典把每個(gè)指標(biāo)對(duì)應(yīng)到唯一的原子指標(biāo)、修飾詞、數(shù)倉(cāng)表、計(jì)算邏輯、更新頻率。比如“銷售額”只能有一個(gè)定義來自 DWS 訂單日匯總表的實(shí)收金額字段包含已完成和已收貨訂單剔除退款和刷單訂單。任何業(yè)務(wù)方要取數(shù)必須引用字典里已登記的指標(biāo)不能自己另起爐灶。這里有個(gè)很現(xiàn)實(shí)的問題業(yè)務(wù)方已經(jīng)用舊口徑跑了好幾年報(bào)表你說改就改會(huì)有人不服。我們的處理方式是做“新舊口徑并行期”定義一個(gè)舊口徑的表保留三個(gè)月同時(shí)新口徑報(bào)表上線等業(yè)務(wù)確認(rèn)新口徑?jīng)]問題后再下掉舊表。這三個(gè)月里為了對(duì)齊我們做了很多數(shù)據(jù)校驗(yàn)工作隨機(jī)抽 10 天歷史數(shù)據(jù)舊口徑結(jié)果和新中臺(tái)結(jié)果逐一比對(duì)差異超過萬(wàn)分之五就回去查原因。等跑完這輪驗(yàn)證業(yè)務(wù)方心里的石頭才落了地。4. 計(jì)算與集群部署把每一臺(tái)機(jī)器的資源都算明白再動(dòng)手4.1 集群規(guī)模怎么估以數(shù)據(jù)量為起點(diǎn)反推這個(gè)項(xiàng)目的數(shù)據(jù)量日增量大概在 5TB 左右業(yè)務(wù)高峰期大促日能到 20TB總的 HDFS 存儲(chǔ)約半年內(nèi) 1PB。我們當(dāng)時(shí)規(guī)劃集群沒有拍腦袋而是先做了一輪計(jì)算。存儲(chǔ)方面HDFS 默認(rèn)三副本所以 1PB 邏輯數(shù)據(jù)需要 3PB 物理容量。加上數(shù)據(jù)保留策略、中間結(jié)果、臨時(shí)文件我們預(yù)留 20% 冗余物理存儲(chǔ)按 3.6PB 規(guī)劃。單臺(tái)機(jī)器如果配 8 塊 8TB 盤可用容量約 50TB還要扣掉系統(tǒng)盤、元數(shù)據(jù)開銷這樣數(shù)據(jù)節(jié)點(diǎn)大概需要 75-80 臺(tái)。為了應(yīng)對(duì)大促擴(kuò)容我們沒一次買夠而是按“日常 60 臺(tái) 彈性擴(kuò)容到 90 臺(tái)”的方式部署。計(jì)算資源方面Spark 離線任務(wù)主體跑在 YARN 上。當(dāng)時(shí)線上資源基線是 3 萬(wàn)核、200TB 內(nèi)存按每節(jié)點(diǎn) 64 核、512GB 內(nèi)存、50 節(jié)點(diǎn)計(jì)算。我們把任務(wù)分成實(shí)時(shí)、離線、adhoc 三類通過 YARN 隊(duì)列劃分實(shí)時(shí)隊(duì)列 20% 資源離線隊(duì)列 60%adhoc 查詢隊(duì)列 20%。這樣設(shè)計(jì)是為了避免臨時(shí)跑一個(gè) adhoc 查詢把離線核心任務(wù)擠掉。4.2 部署細(xì)節(jié)HA 別省壓縮別亂用批次別貪多集群部署時(shí)的幾個(gè)關(guān)鍵細(xì)節(jié)我直接列出來每一項(xiàng)都是踩過坑換來的經(jīng)驗(yàn)Namenode 和 ResourceManager 一定要做 HA心跳自動(dòng)切換。我們前期圖省事沒配后來一次機(jī)房維護(hù)導(dǎo)致 Nomenode 單點(diǎn)故障整個(gè)集群停了大半天。數(shù)據(jù)壓縮格式我們統(tǒng)一選 ORC Snappy。ORC 列式存儲(chǔ)對(duì)分析查詢友好Snappy 壓縮和解壓速度快壓縮比雖然不是最高但綜合性能最好。不要混用多種壓縮格式否則下游讀文件時(shí)一會(huì)兒解壓這個(gè)一會(huì)兒解壓那個(gè)效率極低。Spark 任務(wù)提交參數(shù)不要亂調(diào)。我們一開始盲目加大 executor memory導(dǎo)致集群內(nèi)存碎片化嚴(yán)重。最終經(jīng)驗(yàn)是單 executor 3-5GB 內(nèi)存、2-4 核比較平穩(wěn)大量大批次任務(wù)比小批次任務(wù)更容易導(dǎo)致資源競(jìng)爭(zhēng)和 task 長(zhǎng)尾。Flink 的 Checkpoint 間隔默認(rèn) 5 分鐘但我們實(shí)時(shí)大屏對(duì)準(zhǔn)確性要求很高就改成了 60 秒一次使用 RocksDB 增量 Checkpoint并且開啟自動(dòng)無鎖恢復(fù)。這樣才能在節(jié)點(diǎn)故障后更快恢復(fù)狀態(tài)。配置項(xiàng)我們的取值說明HDFS 副本數(shù)3常規(guī)數(shù)據(jù) 3 副本臨時(shí)數(shù)據(jù) 1 副本HDFS 塊大小128MB大文件多128MB 均衡了元數(shù)據(jù)和 IOSpark executor 內(nèi)存4GB避免資源碎片和頻繁 GCSpark executor 核數(shù)2提升單節(jié)點(diǎn)并行度避免大任務(wù)獨(dú)占Flink Checkpoint 間隔60s實(shí)時(shí)指標(biāo)恢復(fù)時(shí)間要求高壓縮格式ORC Snappy讀寫性能和壓縮比平衡4.3 調(diào)度與血緣讓任務(wù)“跑得動(dòng)還看得清”調(diào)度我們選的是 DolphinScheduler。選它的原因很簡(jiǎn)單支持中文界面、可視化 DAG 編排、帶告警機(jī)制能直接對(duì)接 Hive 和 Spark部署也輕量。離線任務(wù)每天凌晨跑一個(gè)全量管道白天每小時(shí)跑一次增量管道調(diào)度依賴用時(shí)間窗控制避免任務(wù)之間因?yàn)樯嫌瓮睃c(diǎn)而產(chǎn)生連環(huán)延遲。光有調(diào)度還不夠中臺(tái)的可治理性很大程度依賴數(shù)據(jù)血緣。我們自研了元數(shù)據(jù)中心它會(huì)從 Spark、Hive、Flink 的執(zhí)行日志和 Catalog 中解析出“表 → 表、任務(wù) → 表”的血緣關(guān)系。這樣當(dāng)某張 DWS 表的字段口徑需要調(diào)整時(shí)能快速找到所有下游任務(wù)提前評(píng)估影響面而不是改完再被業(yè)務(wù)方投訴“報(bào)表數(shù)據(jù)怎么突然不對(duì)了”。5. 數(shù)據(jù)服務(wù)與可視化大屏別讓一塊大屏暴露整個(gè)中臺(tái)的性能短板5.1 數(shù)據(jù)服務(wù)層輸出標(biāo)準(zhǔn)化指標(biāo)而不是裸表數(shù)據(jù)服務(wù)層是整個(gè)中臺(tái)對(duì)外輸出的窗口也是最容易被“省掉”的一層。它做的事情是把 DWS/ADS 的結(jié)果封裝成 API提供兩類接口指標(biāo)查詢接口例如按門店、品類、小時(shí)查銷售額和明細(xì)查詢接口例如查某訂單詳情。指標(biāo)查詢的核心是預(yù)聚合。大屏上展示的“今日實(shí)時(shí)銷售額”“本小時(shí)訂單量”這類指標(biāo)我們不可能實(shí)時(shí)去查明細(xì)而是在 DWS 層做分鐘級(jí)預(yù)聚合結(jié)果放到 Redis 緩存接口直接讀緩存響應(yīng)時(shí)間能壓在 200ms 以內(nèi)。明細(xì)查詢則落到 ClickHouseClickHouse 的列式存儲(chǔ)和向量化執(zhí)行在這種場(chǎng)景下特別給力億萬(wàn)級(jí)明細(xì)表按條件過濾也能秒出結(jié)果。我個(gè)人強(qiáng)烈建議數(shù)據(jù)服務(wù)層盡量用統(tǒng)一網(wǎng)關(guān)包一層不要直接把 ClickHouse 或 Doris 的連接信息發(fā)給應(yīng)用方。連接信息一旦擴(kuò)散應(yīng)用的臨時(shí)查詢和報(bào)表直連都會(huì)不受控中臺(tái)的口徑治理就形同虛設(shè)。5.2 數(shù)據(jù)大屏常見卡頓QTableWidget 是怎么一步一步拖垮你的講到可視化數(shù)據(jù)大屏是這個(gè)案例里非常典型的一個(gè)場(chǎng)景。大屏一部分是指標(biāo)卡片和圖表另一部分是實(shí)時(shí)滾動(dòng)的明細(xì)表格展示最近 1000 條訂單記錄。我們用 Qt 做桌面端大屏的客戶端一開始圖省事表格控件直接用了 QTableWidget結(jié)果數(shù)據(jù)一多就卡得不能自理。這個(gè)問題我相信不只我一個(gè)人遇到所以專門拉出來講講。QTableWidget 卡的根本原因是它默認(rèn)使用 QStandardItemModel每一條數(shù)據(jù)都要新建一個(gè) QTableWidgetItem 對(duì)象并塞進(jìn)表格。如果你要顯示 1 萬(wàn)行、每行 10 列意味著你要?jiǎng)?chuàng)建 10 萬(wàn)個(gè) QTableWidgetItem 對(duì)象。10 萬(wàn)個(gè)小對(duì)象的內(nèi)存開銷和創(chuàng)建耗時(shí)不說QTableWidget 還會(huì)為每個(gè)格子準(zhǔn)備畫刷、編輯代理等額外資源內(nèi)存爆炸是必然的。更要命的是QTableWidget 的視圖在沒有優(yōu)化的情況下會(huì)對(duì)可見區(qū)域外的單元格做大量刷新和判空處理尤其是設(shè)置了 alternatingRowColors、豎向滾動(dòng)的時(shí)候CPU 消耗非常大。很多人問“為什么我只看到幾十行也會(huì)卡”那是因?yàn)?Qt 的表格視圖并不是只畫屏幕上那幾十行它內(nèi)部要處理所有“可能的單元格”的取數(shù)邏輯。你的瓶頸其實(shí)出在 Model 承載了太多數(shù)據(jù)而不是 View 畫了多少。對(duì)比維度QTableWidgetQTableView 自定義 Model數(shù)據(jù)存儲(chǔ)內(nèi)部 Item 對(duì)象每條數(shù)據(jù)都要建對(duì)象外部數(shù)據(jù)源Model 按需提供數(shù)據(jù)滾動(dòng)性能全量 Item 參與計(jì)算容易卡頓只渲染可見區(qū)原生支持虛擬滾動(dòng)內(nèi)存占用大小數(shù)據(jù)仍存在業(yè)務(wù)側(cè)不復(fù)制靈活性低高可自定義排序、代理、懶加載5.3 從 QTableWidget 換到 QTableView 自定義 QAbstractTableModel把 QTableWidget 換成 QTableView 自定義 QAbstractTableModel這算是 Qt 表格大數(shù)據(jù)的標(biāo)準(zhǔn)解法。原理很簡(jiǎn)單QTableView 只負(fù)責(zé)繪制可見區(qū)域的單元格通過 model 的 rowCount、columnCount、data 三個(gè)方法按需獲取數(shù)據(jù)而不是預(yù)先創(chuàng)建所有 item。換句話說你的原始數(shù)據(jù)放在自己的容器里Model 只做“取數(shù)映射”視圖滾動(dòng)時(shí)它會(huì)反復(fù)調(diào)用 data 方法讀取需要的那幾十行數(shù)據(jù)。下面給一段可以直接參考的 model 實(shí)現(xiàn)框架。我先定義一個(gè) DataModel構(gòu)造函數(shù)接收外部數(shù)據(jù)源的引用data 方法里按 role 返回?cái)?shù)據(jù)行數(shù)和列數(shù)直接從外部數(shù)據(jù)源獲取。關(guān)鍵點(diǎn)在于不要讓 model 持有超大數(shù)據(jù)副本只持引用即可。class DataModel : public QAbstractTableModel { Q_OBJECT public: explicit DataModel(QVectorQVectorQVariant* dataPtr, QObject* parent nullptr) : QAbstractTableModel(parent), m_dataPtr(dataPtr) {} int rowCount(const QModelIndex parent QModelIndex()) const override { if (parent.isValid()) return 0; return m_dataPtr ? m_dataPtr-size() : 0; } int columnCount(const QModelIndex parent QModelIndex()) const override { if (parent.isValid()) return 0; return 10; // 固定列數(shù)具體按業(yè)務(wù)來 } QVariant data(const QModelIndex index, int role) const override { if (!index.isValid() || !m_dataPtr) return QVariant(); if (role Qt::DisplayRole || role Qt::EditRole) { return m_dataPtr-at(index.row()).at(index.column()); } return QVariant(); } QVariant headerData(int section, Qt::Orientation orientation, int role) const override { if (role ! Qt::DisplayRole) return QVariant(); if (orientation Qt::Horizontal) { // 返回列名例order_idstore_nameamountstatus... return m_header[section]; } return QString::number(section 1); } private: QVectorQVectorQVariant* m_dataPtr; QStringList m_header {訂單號(hào), 門店, 金額, 狀態(tài)}; };換成這個(gè) model 之后你會(huì)立刻感受到滾動(dòng)的順暢。因?yàn)?QTableView 只請(qǐng)求當(dāng)前可見區(qū)域約幾十行的 data即使底層有幾十萬(wàn)、上百萬(wàn)條記錄性能也能保持在很穩(wěn)定水平。視圖一次只顯示幾十行這恰恰是它高效的原因并不是 bug是虛擬化機(jī)制的正常表現(xiàn)。換用 QTableView 之后還有幾步優(yōu)化建議調(diào)用 setUniformRowHeights(true)它假設(shè)所有行高一致可以大幅減少滾動(dòng)時(shí)的布局計(jì)算setVerticalScrollMode(QAbstractItemView::ScrollPerPixel) 讓滾動(dòng)更平滑避免在高頻滾動(dòng)時(shí) setAlternatingRowColors(true)這個(gè)選項(xiàng)在數(shù)據(jù)量大時(shí)反而會(huì)增加繪制次數(shù)。如果還需要更極致的性能可以考慮用 QSortFilterProxyModel 做排序過濾或者把分頁(yè)數(shù)據(jù)源換成真正懶加載每次只加載當(dāng)前窗口范圍內(nèi)的數(shù)據(jù)。5.4 大屏背后還有數(shù)據(jù)鏈路的緩存與降級(jí)方案表格控件優(yōu)化只是大屏體驗(yàn)的一部分更重要的還是保證數(shù)據(jù)接口穩(wěn)定。我們?cè)诖笃练?wù)端做了三層保障Redis 做指標(biāo)緩存接口命中緩存直接返回緩存失效時(shí)才回源查詢 ClickHouseClickHouse 如果也扛不住再走一層降級(jí)策略比如大屏自動(dòng)切換到 DWS 預(yù)匯總的小表而不是讓用戶看到白屏或報(bào)錯(cuò)。這里有一個(gè)小技巧值得提一下大屏接口的響應(yīng)時(shí)間標(biāo)準(zhǔn)是“P95 必須小于 300msP99 必須小于 1s”為了達(dá)到這個(gè)目標(biāo)我們?cè)?DWS 層專門建了幾張“秒級(jí)聚合表”每 15 秒用 Flink 做一次滾動(dòng)聚合把最新 1 小時(shí)的數(shù)據(jù)一次性算出結(jié)果寫入 ClickHouse。這樣大屏反復(fù)刷新的數(shù)據(jù)不會(huì)直接打到明細(xì)層而是打在這張聚合表上查詢壓力小很多。6. 常見問題與排查技巧實(shí)錄中臺(tái)建設(shè)中最容易翻車的地方6.1 離線任務(wù)延遲導(dǎo)致大屏數(shù)據(jù)斷層大屏上“今日銷售額”是一個(gè)小時(shí)級(jí)別的實(shí)時(shí)指標(biāo)和離線報(bào)表的日終結(jié)果偶爾對(duì)不上業(yè)務(wù)方會(huì)質(zhì)疑“你們數(shù)據(jù)是不是壞了”。這個(gè)問題本質(zhì)是實(shí)時(shí)和離線兩套鏈路計(jì)算的邏輯不完全一致。比如實(shí)時(shí)鏈路統(tǒng)計(jì)的訂單狀態(tài)是“支付完成即計(jì)入”離線鏈路要求“訂單完成且退款剔除”兩邊本來就存在時(shí)間差窗口。處理辦法是分場(chǎng)景說明口徑大屏標(biāo)注“實(shí)時(shí)口徑最終以日終報(bào)表為準(zhǔn)”同時(shí)跑一個(gè)每日對(duì)賬任務(wù)把實(shí)時(shí)鏈路前一天的結(jié)果和離線日終結(jié)果做比對(duì)差額超過閾值自動(dòng)告警。這樣數(shù)據(jù)鏈路是否可靠業(yè)務(wù)方可以用對(duì)賬結(jié)果判斷而不是聽我們拍胸脯保證。6.2 集群資源被臨時(shí)查詢打爆中臺(tái)開放了自助分析能力之后總會(huì)有業(yè)務(wù)同學(xué)寫“三表大 join、全表掃描”的查詢把集群資源吃光影響正式調(diào)度任務(wù)。我們解決方法是三管齊下YARN 隊(duì)列做了嚴(yán)格配額adhoc 查詢只分到 20% 資源池超過就排隊(duì)DQC 數(shù)據(jù)質(zhì)量中心對(duì)慢查詢做規(guī)則攔截掃描行數(shù)超過一定量就自動(dòng)熔斷再給每個(gè)賬號(hào)設(shè)定單次查詢最大掃描量避免“一次性全表掃”這種操作。常見問題根因排查思路處理辦法大屏接口慢ClickHouse 查詢掃全表或緩存過期頻繁看慢查詢?nèi)罩尽⒖疵新始?DWS 預(yù)聚合、Redis 緩存、限流降級(jí)實(shí)時(shí)與離線數(shù)據(jù)對(duì)不上兩條鏈路統(tǒng)計(jì)口徑不同抽樣對(duì)賬比對(duì)差異數(shù)據(jù)范圍統(tǒng)一口徑文檔每日定時(shí)對(duì)賬告警Kafka 消費(fèi)延遲分區(qū)數(shù)少、消費(fèi)者并行度低查看消費(fèi)組 lag檢查 Flink 并行度增加 topic 分區(qū)、調(diào)大 Flink 并行度Spark 任務(wù)數(shù)據(jù)傾斜熱點(diǎn) key 導(dǎo)致單 task 處理量大看 task 耗時(shí)分布確認(rèn) task 數(shù)據(jù)量加鹽分桶、廣播小表、改 join 策略Qt 表格滾動(dòng)卡頓使用了 QTableWidget 或 model 不虛擬化檢查 item 數(shù)量和 data 調(diào)用次數(shù)換 QTableView 自定義 QAbstractTableModel6.3 數(shù)據(jù)質(zhì)量監(jiān)控一定要前置不要等報(bào)表錯(cuò)了再救火關(guān)于數(shù)據(jù)中臺(tái)我最后想聊的是“治理”兩個(gè)字。平臺(tái)搭好、任務(wù)跑通只是開始真正決定中臺(tái)能不能長(zhǎng)期活下去的是數(shù)據(jù)質(zhì)量監(jiān)控和治理機(jī)制。我們監(jiān)控體系每個(gè)月能發(fā)現(xiàn)上百個(gè)潛在問題源系統(tǒng)字段枚舉值變化、上游任務(wù)延遲、指標(biāo)翻倍異常等等這些問題大部分都是靠規(guī)則提前擋住的。每個(gè)核心任務(wù)都要配置“主鍵唯一性校驗(yàn)、表行數(shù)波動(dòng)監(jiān)控、字段空值率監(jiān)控”。這些規(guī)則在任務(wù)完成后自動(dòng)觸發(fā)如果異常會(huì)阻塞下游任務(wù)執(zhí)行并告警到責(zé)任人。可以說沒有數(shù)據(jù)質(zhì)量監(jiān)控的中臺(tái)早晚會(huì)退化成“數(shù)據(jù)沼澤”。7. 這個(gè)內(nèi)容后續(xù)還可以這樣擴(kuò)展如果你正在規(guī)劃數(shù)據(jù)中臺(tái)我建議不要把全部精力放在組件選型和集群參數(shù)上。中臺(tái)本質(zhì)是治理工程把指標(biāo)口徑、數(shù)據(jù)模型、質(zhì)量監(jiān)控這三件事做扎實(shí)比堆多少組件都重要。再分享一個(gè)最后才踩到的經(jīng)驗(yàn)第一次建設(shè)數(shù)據(jù)中臺(tái)范圍不要鋪太大。先挑一個(gè)業(yè)務(wù)域比如訂單域做端到端打通從數(shù)據(jù)接入到指標(biāo)展示全部跑通再橫向擴(kuò)展到其他域。不要一上來就規(guī)劃 20 個(gè)業(yè)務(wù)域、50 個(gè)主題那樣項(xiàng)目周期會(huì)被拖到半年以上團(tuán)隊(duì)熱情也會(huì)被消磨掉。一個(gè)小而完整的成功樣板比一個(gè)宏大到不了了之的規(guī)劃有效得多。