网易严选离线数仓质量建设实践

做数仓最重要的是什么？一是模型易用性，二是数据质量。模型易用性我们可以通过建模规范、指标管理等方式去实现。而对于数据质量呢？本篇将以严选数仓为例，从建设目标、保障措施、效果评价等几方面探讨数仓质量建设。

网易严选离线数仓目前主要基于有数大数据平台进行调度及管理（Azkban），FLOW数量4000+，首先我们要做的事情就是从中识别出每个任务的重要程度，以此确定保障的策略。

具体做法是：基于CMDB的服务分级确定终端场景的重要性，再通过数据血缘上推依赖的FLOW，如果一个FLOW被多个服务依赖则取较高的服务等级作为该FLOW的分级。

这个就比较老生常谈了：完整性、准确性、一致性、及时性。

完整性

数据完整性包含两方面：记录完整性、字段信息完整性。即某张表数据记录是否缺失，某些非null字段是否为null。

准确性

准确性指数据是否存在异常或者错误的信息，如明细数据相对原始数据是否失真，汇总数据是否符合指标口径定义等。

一致性

对于企业数据仓库，一份数据在多个场景使用是很常见的，一致性即指对于同一个数据定义，可以是一个原始字段或一个加工后的指标，任意使用场景所使用的数据都是一样的。比如供应链和商品开发都关注缺货率指标，他们可能分属不同团队，对接不同的数据开发，但是用到的缺货率指标只能是同一份。

及时性

及时性指业务需要看数时，要有数可看，具体落实下来就是数仓的FLOW要能稳定按时产出。

针对前面提到的建设目标，目前主要有以下策略。

3.1 数据源质量控制

要做好数据质量首先我们要保证数据源是“干净”的，且数据开发要能及时感知到上游系统的各种变更。这里主要有以下3点策略：

1. ODS层入仓监控。严选数据入仓使用自研Datahub平台，在数据入仓阶段对binlog收集、日志收集、T+1快照生成等任务做了时效监控，保障源数据的及时性。

2. 上游变更感知。数仓的数据来自于上游业务系统，上游系统的逻辑变更必然对数仓造成影响。考虑到如果直接做发布审批卡点，流程会比较重，目前我们的做法是由数据开发自行跟对接的上游开发强调，有变更时需要把变更点告知数据开发，由数据开发评估影响。

3. 上游DB运维感知。这层更接近于是兜底逻辑，理论上变更及运维操作都应该在发生前同步到数据开发。严选CMDB支持对服务配置“数据负责人”角色，当业务后端对服务相应的DB发起DDL或者DML工单时，变更详情会通过邮件及POPO同步到数据开发。

3.2 ETL质量控制

ETL质量控制这里指数据开发的在有数大数据平台开发FLOW构建数仓主题域模型的过程的质量控制措施和能力。

1. 任务测试卡点。这里主要指有数大数据平台FLOW未在开发环境运行通过的，无法提交上线。同时开发环境提供测试集群，依模型重要性可以选择在测试集群进行调试，从而不影响线上数据。

2. 任务发布卡点。有数大数据平台支持按规则圈选任务，对于选定的任务要求先审批后上线。借助这个能力可以实现对日常重点任务或者全局封板的发布卡点，要求CR和测试报告才能审批上线。（该机制目前暂未运行）

3. 表质量监控卡点。主要基于有数大数据平台的数据稽核能力，以任务分级为基础，围绕完整性、准确性、一致性对可能的数据质量问题做出监控卡点。目前已提“支持DQC结果订阅”的需求给到有数。

4. SQLSCAN静态分析。代码静态分析这块调研了SonarQube的方案，在开源方案的基础上需要解决3个问题。（1）代码集成，可借助严选自己的“血缘插件”收集的执行记录实现。（2）代码检查规则，这块需要自行开发插件，SQL相关的检查插件目前开源的方案都是针对OLTP场景的。因暂时没开发资源能投入这块，所以暂无实施计划。

5. 产出基线控制。以任务分级为基础，将重点数仓任务划分到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静态分析，当前主要由于开发资源问题搁置，合适的时机可以重启；

• 基线治理深化，通过优化单任务性能，任务拓扑，风险提早发现等方式继续降低基线破线率和起夜率；

• 红蓝攻防演练，针对重点链路、重点场景开展质量攻防演练，检验风险发现能力、事故恢复能力、数据吞吐能力等。