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

網易嚴選離線數倉目前主要基于有數大數據平臺進行調度及管理（Azkban），FLOW數量4000+，首先我們要做的事情就是從中識別出每個任務的重要程度，以此確定保障的策略。

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

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

完整性

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

準確性

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

一致性

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

及時性

及時性指業務需要看數時，要有數可看，具體落實下來就是數倉的FLOW要能穩定按時產出。

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

3.1 數據源質量控制

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

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

上游變更感知。數倉的數據來自于上游業務系統，上游系統的邏輯變更必然對數倉造成影響?？紤]到如果直接做發布審批卡點，流程會比較重，目前我們的做法是由數據開發自行跟對接的上游開發強調，有變更時需要把變更點告知數據開發，由數據開發評估影響。

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

3.2 ETL質量控制

ETL質量控制這里指數據開發的在有數大數據平臺開發FLOW構建數倉主題域模型的過程的質量控制措施和能力。

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

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

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

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

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

3.3 終端質量控制（出口控制）

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

3.4 橫向巡檢預警及復盤

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

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

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

檢查有DDL變更卻沒有關聯任務變更記錄；

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

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

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

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

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

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

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

效果大概長這樣：

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

關于數倉質量這塊可能繼續建設的方向包括以下幾塊：

DQC結果訂閱機制，這個需求已經提給了有數；

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

基線治理深化，通過優化單任務性能，任務拓撲，風險提早發現等方式繼續降低基線破線率和起夜率；

紅藍攻防演練，針對重點鏈路、重點場景開展質量攻防演練，檢驗風險發現能力、事故恢復能力、數據吞吐能力等。