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

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

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

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

完整性

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

準確性

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

一致性

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

及時性

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

針對前面提到的建設目標，目前主要有以下策略。

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

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

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

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

上游DB運維感知。這層更接近于是兜底邏輯，理論上變更及運維操作都應該在發(fā)生前同步到數(shù)據(jù)開發(fā)。嚴選CMDB支持對服務配置“數(shù)據(jù)負責人”角色，當業(yè)務后端對服務相應的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ì)量控制措施和能力。

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

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

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

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

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

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

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

3.4 橫向巡檢預警及復盤

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

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

（1）檢查基線任務當天有修改的記錄

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

事后打標分析。每天早上抓取近期基線破線記錄，通知值班填報標記破線原因，用于事后復盤及破線責任歸因。

（2）稽核質(zhì)量巡檢。因為弱稽核失敗不阻塞任務，可能負責人沒有及時處理，針對連續(xù)失敗未處理的任務進行抓取并通知到部門群里。

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

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

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

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

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

效果大概長這樣：

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

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

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

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

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

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