最近很多人关心网易严选仓库「网易严选产品怎么样」这个话题,卢子百科整理了网易严选仓库「网易严选产品怎么样」相关内容,希望对大家有用。

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


1


‍保障等级确认


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


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


2


数据质量建设目标


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


完整性

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


准确性

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


一致性

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


及时性

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


3


数据质量实施策略


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


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就能发送消息通知,且调度可以直接在有数大数据平台上完成,大大降低了巡检消息的开发成本。

效果大概长这样:


4


质量衡量


前面提到这么多措施,具体实施得怎么样,效果又怎么样呢?这里是数仓的传统技能了,收集各类元数据,计算DQC配置率,基线破线率等指标,并通过有数报表进行呈现。一方面直观呈现数仓现在的质量情况;另一方面指标拆解到个人,配合消息通知工具发送待办作为推进改进的抓手。


5


未来展望


关于数仓质量这块可能继续建设的方向包括以下几块:

DQC结果订阅机制,这个需求已经提给了有数;SQLSCAN静态分析,当前主要由于开发资源问题搁置,合适的时机可以重启;基线治理深化,通过优化单任务性能,任务拓扑,风险提早发现等方式继续降低基线破线率和起夜率;红蓝攻防演练,针对重点链路、重点场景开展质量攻防演练,检验风险发现能力、事故恢复能力、数据吞吐能力等。