做數(shù)倉最重要的是什么？一是模型易用性，二是數(shù)據(jù)質(zhì)量。模型易用性我們可以通過建模規(guī)范、指標(biāo)管理等方式去實(shí)現(xiàn)。而對于數(shù)據(jù)質(zhì)量呢？本篇將以嚴(yán)選數(shù)倉為例，從建設(shè)目標(biāo)、保障措施、效果評價等幾方面探討數(shù)倉質(zhì)量建設(shè)。

網(wǎng)易嚴(yán)選離線數(shù)倉目前主要基于有數(shù)大數(shù)據(jù)平臺進(jìn)行調(diào)度及管理（Azkban），F(xiàn)LOW數(shù)量4000+，首先我們要做的事情就是從中識別出每個任務(wù)的重要程度，以此確定保障的策略。

具體做法是：基于CMDB的服務(wù)分級確定終端場景的重要性，再通過數(shù)據(jù)血緣上推依賴的FLOW，如果一個FLOW被多個服務(wù)依賴則取較高的服務(wù)等級作為該FLOW的分級。

這個就比較老生常談了：完整性、準(zhǔn)確性、一致性、及時性。

完整性

數(shù)據(jù)完整性包含兩方面：記錄完整性、字段信息完整性。即某張表數(shù)據(jù)記錄是否缺失，某些非null字段是否為null。

準(zhǔn)確性

準(zhǔn)確性指數(shù)據(jù)是否存在異常或者錯誤的信息，如明細(xì)數(shù)據(jù)相對原始數(shù)據(jù)是否失真，匯總數(shù)據(jù)是否符合指標(biāo)口徑定義等。

一致性

對于企業(yè)數(shù)據(jù)倉庫，一份數(shù)據(jù)在多個場景使用是很常見的，一致性即指對于同一個數(shù)據(jù)定義，可以是一個原始字段或一個加工后的指標(biāo)，任意使用場景所使用的數(shù)據(jù)都是一樣的。比如供應(yīng)鏈和商品開發(fā)都關(guān)注缺貨率指標(biāo)，他們可能分屬不同團(tuán)隊(duì)，對接不同的數(shù)據(jù)開發(fā)，但是用到的缺貨率指標(biāo)只能是同一份。

及時性

及時性指業(yè)務(wù)需要看數(shù)時，要有數(shù)可看，具體落實(shí)下來就是數(shù)倉的FLOW要能穩(wěn)定按時產(chǎn)出。

針對前面提到的建設(shè)目標(biāo)，目前主要有以下策略。

3.1 數(shù)據(jù)源質(zhì)量控制

要做好數(shù)據(jù)質(zhì)量首先我們要保證數(shù)據(jù)源是“干凈”的，且數(shù)據(jù)開發(fā)要能及時感知到上游系統(tǒng)的各種變更。這里主要有以下3點(diǎn)策略：

ODS層入倉監(jiān)控。嚴(yán)選數(shù)據(jù)入倉使用自研Datahub平臺，在數(shù)據(jù)入倉階段對binlog收集、日志收集、T+1快照生成等任務(wù)做了時效監(jiān)控，保障源數(shù)據(jù)的及時性。

上游變更感知。數(shù)倉的數(shù)據(jù)來自于上游業(yè)務(wù)系統(tǒng)，上游系統(tǒng)的邏輯變更必然對數(shù)倉造成影響。考慮到如果直接做發(fā)布審批卡點(diǎn)，流程會比較重，目前我們的做法是由數(shù)據(jù)開發(fā)自行跟對接的上游開發(fā)強(qiáng)調(diào)，有變更時需要把變更點(diǎn)告知數(shù)據(jù)開發(fā)，由數(shù)據(jù)開發(fā)評估影響。

上游DB運(yùn)維感知。這層更接近于是兜底邏輯，理論上變更及運(yùn)維操作都應(yīng)該在發(fā)生前同步到數(shù)據(jù)開發(fā)。嚴(yán)選CMDB支持對服務(wù)配置“數(shù)據(jù)負(fù)責(zé)人”角色，當(dāng)業(yè)務(wù)后端對服務(wù)相應(yīng)的DB發(fā)起DDL或者DML工單時，變更詳情會通過郵件及POPO同步到數(shù)據(jù)開發(fā)。

3.2 ETL質(zhì)量控制

ETL質(zhì)量控制這里指數(shù)據(jù)開發(fā)的在有數(shù)大數(shù)據(jù)平臺開發(fā)FLOW構(gòu)建數(shù)倉主題域模型的過程的質(zhì)量控制措施和能力。

任務(wù)測試卡點(diǎn)。這里主要指有數(shù)大數(shù)據(jù)平臺FLOW未在開發(fā)環(huán)境運(yùn)行通過的，無法提交上線。同時開發(fā)環(huán)境提供測試集群，依模型重要性可以選擇在測試集群進(jìn)行調(diào)試，從而不影響線上數(shù)據(jù)。

任務(wù)發(fā)布卡點(diǎn)。有數(shù)大數(shù)據(jù)平臺支持按規(guī)則圈選任務(wù)，對于選定的任務(wù)要求先審批后上線。借助這個能力可以實(shí)現(xiàn)對日常重點(diǎn)任務(wù)或者全局封板的發(fā)布卡點(diǎn)，要求CR和測試報(bào)告才能審批上線。（該機(jī)制目前暫未運(yùn)行）

表質(zhì)量監(jiān)控卡點(diǎn)。主要基于有數(shù)大數(shù)據(jù)平臺的數(shù)據(jù)稽核能力，以任務(wù)分級為基礎(chǔ)，圍繞完整性、準(zhǔn)確性、一致性對可能的數(shù)據(jù)質(zhì)量問題做出監(jiān)控卡點(diǎn)。目前已提“支持DQC結(jié)果訂閱”的需求給到有數(shù)。

SQLSCAN靜態(tài)分析。代碼靜態(tài)分析這塊調(diào)研了SonarQube的方案，在開源方案的基礎(chǔ)上需要解決3個問題。（1）代碼集成，可借助嚴(yán)選自己的“血緣插件”收集的執(zhí)行記錄實(shí)現(xiàn)。（2）代碼檢查規(guī)則，這塊需要自行開發(fā)插件，SQL相關(guān)的檢查插件目前開源的方案都是針對OLTP場景的。因暫時沒開發(fā)資源能投入這塊，所以暫無實(shí)施計(jì)劃。

產(chǎn)出基線控制。以任務(wù)分級為基礎(chǔ)，將重點(diǎn)數(shù)倉任務(wù)劃分到2:30、4:30、5:30、7:30、9:30五條基線上，基線DDL30分鐘前未產(chǎn)出即開始預(yù)警，由值班介入處理，保障及時性。

3.3 終端質(zhì)量控制（出口控制）

終端質(zhì)量控制目前主要針對數(shù)據(jù)產(chǎn)品，QA參與建設(shè)的“指標(biāo)測試平臺”提供了對指標(biāo)產(chǎn)出及時性、指標(biāo)波動、不合理數(shù)值、null值等的預(yù)警能力，且由QA直接跟進(jìn)異常處理。

3.4 橫向巡檢預(yù)警及復(fù)盤

前文提到的數(shù)據(jù)源質(zhì)量控制、ETL質(zhì)量控制、終端質(zhì)量控制更多是分散到各個數(shù)據(jù)開發(fā)及各個任務(wù)的by case處理，除此之外我們還建設(shè)了橫向的巡檢及復(fù)盤機(jī)制。

事前異常變更巡檢。每天下班前抓取當(dāng)天的數(shù)倉變更點(diǎn)，進(jìn)行以下篩查并通知到部門群里。

（1）檢查基線任務(wù)當(dāng)天有修改的記錄

檢查有DDL變更卻沒有關(guān)聯(lián)任務(wù)變更記錄；

事后打標(biāo)分析。每天早上抓取近期基線破線記錄，通知值班填報(bào)標(biāo)記破線原因，用于事后復(fù)盤及破線責(zé)任歸因。

（2）稽核質(zhì)量巡檢。因?yàn)槿趸耸〔蛔枞蝿?wù)，可能負(fù)責(zé)人沒有及時處理，針對連續(xù)失敗未處理的任務(wù)進(jìn)行抓取并通知到部門群里。

（3）次日基線預(yù)警。如果當(dāng)日的任務(wù)修改可能導(dǎo)致第二天的基線破線，則也定位到具體的可疑任務(wù)并通知到群里。

（4）質(zhì)量懲罰措施。針對有明顯違反質(zhì)量規(guī)范的行為執(zhí)行“罰一天值班”的懲罰，比如表稽核連續(xù)失敗3天及以上未處理。

可以看到這部分涉及了很多需要通知到人/通知到群的場景，那以一個數(shù)據(jù)開發(fā)的角色，我們怎么低成本地實(shí)現(xiàn)這一機(jī)制呢？

巡檢這塊一開始建設(shè)的時候做的比較簡單粗暴，直接用Python腳本獲取需要的基礎(chǔ)數(shù)據(jù)，進(jìn)行處理后對接飛書open api，借助飛書機(jī)器人把需要的消息通知出來。Python腳本丟服務(wù)器上用crontab調(diào)度。

場景比較少時這么做沒什么問題，但是場景一多顯然會導(dǎo)致總開發(fā)成本比較高且腳本管理混亂。這里一開始考慮的方案是把分散的巡檢腳本工程化整合重構(gòu)一下，規(guī)范下開發(fā)及部署流程。但其實(shí)還是比較重，最終想到一種比較巧妙的方案，通過Hive/Spark的UDF對嚴(yán)選消息中心的接口做一層包裝，這樣簡單寫幾行SQL就能發(fā)送消息通知，且調(diào)度可以直接在有數(shù)大數(shù)據(jù)平臺上完成，大大降低了巡檢消息的開發(fā)成本。

效果大概長這樣：

前面提到這么多措施，具體實(shí)施得怎么樣，效果又怎么樣呢？這里是數(shù)倉的傳統(tǒng)技能了，收集各類元數(shù)據(jù)，計(jì)算DQC配置率，基線破線率等指標(biāo)，并通過有數(shù)報(bào)表進(jìn)行呈現(xiàn)。一方面直觀呈現(xiàn)數(shù)倉現(xiàn)在的質(zhì)量情況；另一方面指標(biāo)拆解到個人，配合消息通知工具發(fā)送待辦作為推進(jìn)改進(jìn)的抓手。

關(guān)于數(shù)倉質(zhì)量這塊可能繼續(xù)建設(shè)的方向包括以下幾塊：

DQC結(jié)果訂閱機(jī)制，這個需求已經(jīng)提給了有數(shù)；

SQLSCAN靜態(tài)分析，當(dāng)前主要由于開發(fā)資源問題擱置，合適的時機(jī)可以重啟；

基線治理深化，通過優(yōu)化單任務(wù)性能，任務(wù)拓?fù)洌L(fēng)險(xiǎn)提早發(fā)現(xiàn)等方式繼續(xù)降低基線破線率和起夜率；

紅藍(lán)攻防演練，針對重點(diǎn)鏈路、重點(diǎn)場景開展質(zhì)量攻防演練，檢驗(yàn)風(fēng)險(xiǎn)發(fā)現(xiàn)能力、事故恢復(fù)能力、數(shù)據(jù)吞吐能力等。