网易严选离线数仓治理实践

网易严选离线数仓治理实践

背景

任何一个系统，为了保证其良好地运行下去，一定是需要持续的维护和治理，数仓也不

例外。本文主要分享下今年严选数仓团队从规范、计存、质量、安全几块入手对现有数

据资产进行的一些治理的思路和方案。

网易严选是个自营品牌电商，这意味着严选的业务会覆盖C端的用户营销，商品到B端

的供应链以及财务业务。业务和数据的整体复杂度会相对较高，各个不同业务域也呈现

出不同的特点和问题。所以我们需要结合现有的资产特点去设计治理方法论和效果评估

方法，然后围绕着治理方法论去建设我们的治理工具，

营销体系（销售）数据资产全景

(

产品体系（商品）粤治理方法论

疑

(

悔

悔衡量体系

供应链体系刑

刑

))

型

世

评价标准

1财务陶

粤

毅工具建设

治理开始前，光盘一下我们可用的资源，设计下整体的方向。从人力上来说，项目整体

设计与推动大概可投入1.5人力，治理实施可以拉上资产对应的数据开发配合，这个人

力方案决定了我们肯定是不会去设计开发个整体的治理系统来做这个事情，而是应该把

重点放在规范和治理方案设计上，依托现有基础能力，以最低程度的开发资源投入来推

动这个事情。

基础能力上来说，已经沉淀的能力有：

数据地图：由数据开发治理平分的数据地图及严选数据资产中心提供，大部分数据沉淀

在产品，未入仓；

全链路血缘：由严选数据资产中心提供，数据沉淀在产品，未入仓；

数据探查能力：由数据开发治理平台的测试中心提供；

影响评估能力：主要由严选数据资产中心提供，结合血缘和数据分级能力得出影响程度。

整体资产全景见下图:

方法与实施

资产地图

基础体系框架建设

历史我们也做过不少数据治理相关投入，但存在一些问题，比如缺乏体系化设计，导致

多个项目/团队交叉治理，重复治理等问题，同时.，治理效果也缺乏持续的追踪和效果

衡量。这些是本次治理项目需要解决的问题。

2

思路

整体思路上我们分4步走。

方法

标准制定能力建设

实施

(1)规范制定

数据建模规范，即数据开发在设计模型阶段需要遵循的规范，比如dwd不能加工指标

等。

数据开发SOP,为了系统能帮我们自动做一些规范校验和补全，我们可能制定一些流程

上的规范，比如建表必须走模型设计中心，dw层全部先评审后开发等。

（2）能力建设

即我们数据治理过程中需要用到的系统能力补全，包含元数据建设，数据平台的迭代及

治理工具的开发。

（3）治理实施

从治理目标上来说，我们围绕降本、提效、质量3个点去规划治理方案；

从实施方案上来说，主要落实在规范、计算存储、数据质量、数据安全4个方面。

（4）结果衡量

治理结果目标制定；

治理过程指标衡量。

3

实施

3.1规范治理

严选数仓建模规范主要基于Kimball维度建模理论，结合严选业务实际情况制定，大致

架构如下图：

有了规范定义，那我们首先需要的就是看下当前数仓的规范程度，这里我们基于元数据

ETL加工得到我们的监测指标，并基于有数BI进行的可视化呈现。

然后基于当前数仓规范的达成情况，我们制定了今年主要要解决的问题及规范治理的目

标，并同样对治理目标做了可视化。主要问题及解决方式如下：

（1）跨层依赖一一巡检及待办分发

DWS依赖ODS

DM依赖ODS

（2）反向依赖一一巡检及待办分发

DWD依赖DM

DWD依赖DWS

DWS依赖DM

（3）单一事实建模一一运动式治理

一张DWD只依赖一张ODS

3.2指标治理

严选的指标管理基于自研的指标管理系统，该系统会对指标的口径进行管理，并强制绑

定到数据网关，实现从数据网关输出的数据，都附带明确的口径定义。但该系统存在一

个问题，那就是定义和研发分离。指标口径基于该系统定义，但是指标的开发和该系统

并没关联，那么在开发过程中，口径定义和实际开发的口径可能就会出现偏差，并且在

dw,和ads的加「上，建模设计完全山数据开发把关，也就可能出现模型设计度量参差

不齐的情况。

对于以上问题，我们的解法是新设计一套指标管理系统，将指标定义和开发工作耦合起

来，实现定义即研发的效果。目前该系统已经在部分场景实现了落地，系统详细设计这

里就不展开了，感兴趣的同学可以线下交流。

3.3计算存储治理

计算存储资源的消耗直接关系数据的生产成本以及数据产出的稳定性和及时性，所以这

块也是比较重要的。

(1)计算治理

计算资源可优化的点主要在于因代码或参数的不合理导致的低效任务上，主要思路是识

别出这部分任务，然后通过by任务的优化去提高资源利用率。治理方法如下：

触发条件：

数据开发治理平台openAPI获取yarn资源消耗明细

内存空闲时间分布聚类取前20%阈值

RAM实际申请大于1TB

利用率小于10%

防治：

全局：整体消耗资源(RMB/RAM/CPU/TIME)分布监控

个人：触发条件发飞书push任务治理通知

过程记录(已治理/待治理)效果统计

优化方法：谓词下推/小文件合并/join优化/dataskew优化/提高任务并行度/SparkAQE

参数调整

首先我们起个数据开发治理平台的任务，按照触发条件去巡检，筛选出待治理列表。然

后发现这部分任务有着明显的长尾分布特性，极少数任务占用了大部分资源。所以我们

针对toplOO的任务由专人挨个进行的bycase的优化，剩余的任务则通过待办分发的形

式推送给任务的负责人进行优化跟进。同时，我们做了全局的和个人的计算资源监控大

盘，通过消息通知的形式，每天进行监控和公示。

口RMB阮）

分布10-2197.61%[2-14]:2.21%[15-50]：0.17%

CJTIME（邠）:37024

^：[0-18]：95.0%[18-89]：4.77%[93-291]：0.23%

今CPU（核★川）:899971

^：[0-1178]：97.76%[1185-6247]：2.07%[7228-167921：0.17<=

□RAM（G&分钟）:4885121

分利0-12287]:99.03%[1278766948]：0.95%[127655-12765

我的明细:dm.dm_my_daily_cost_hive_view

<KxJfJ^：dm.dm_datawarehousejnefficiencyjob

①O1。点KPI队列自动调度且运行成功的任务

②:资源分扇超过1TB利用率小于10%为低效任务

（2）存储治理

历史对于冷表冷任务这块我们没有系统关注和清理过，所以随着业务的不断发展积累的

大量的冷表冷任务。对于这块儿的治理主要借助数据开发治理平台的数据资产中心的存

储优化功能。但因为数据资产中心对于特殊存储比如kudu、iceberg,以及仓外血缘没

有做逻辑判断。所以拿到数据资产中心的推荐下线数据后，我们结合严选维护的全链路

血缘做了交叉校验，得到最终的待下线任务集-任务集的判断条件如下：

触发条件：

强推荐：30天打开次数十近30天引用次数+近30天访问次数+近30天写入次数=0

弱推荐：近30天打开次数+近30天引用次数+近30天访问次数=0

不存在于调度任务

得到任务集后，先大致分析了下待下线表的分布，发现有几个占比较大且风险较低的库,

比如kylincubebuild的临时数据，库存中心的流水日志等，我们判断风险较小，旦数量

较大，就让数据开发治理平台的同学帮忙批量下线掉，对于是dw,dm等db的表，因

为谁也没办法保证血缘100%的准确性，且摊分到每个人头上后量不算大，所以就采取

待办分发的形式push表负责人去进行治理。然后我们再通过。penAPI去监控集群整休，

和每个数据开发的冷表治理情况，针对需要改进的点再单独push。

防治：

全局：整体情况及占比变化效果群消息

个人：单独push需要治理的表

数据开发治理平台的数据资产存储模块操作

API获取处理结果统计

严选内网机器人对接严选内部权限中心，并且作为消息提醒通道11:0

2022-09・28推荐下线表统计：

百69张—存储:135GB_文件数37327_周环比T：43%

18张—存储:17GB_文件数：5549_周环比-20%

26张—存储:25GB_文。68894_周环比~8%

口：17日存储：1397GB_文件数:175567—周环比二6%

〜21张—存储:99GB_文件数：115856_周环比J。:4%

百张—存储:19GB_文件数:154903」圄环比汇2%

71张—存储:44GB_文件数:94022_周环比f：1%

张—存储:20GB_文件数：95759_周环比10%

长—存储：1GB_文件数:237_周环比10%

5张—存储：0GB_文件数128_周环比10%

--------64张—存储:251GB_文件数888478_周环比一:0%

■P：18张—存储：95GB_文佛共883_周环比一：0%

：17张—存储:73GB_文件数:10386_周环比i：0%

：3张—存储：2GB_文件数:5142_周女比10%

7张一存储1GB_文件数23455_周环比10%

3张—存储0GB_文件数1872_周环比10%

：25张—存储:27GB_文。:2298—周环比一：0%

处的表:dm.dmmyofflinedtableshiveview

待处理的表:dm.dm_my_suggest_offline_tables_hive_view

统计范围：一一一一一-

①:基于猛狗推荐减掉存在于调度任务

②:属于数仓核心库或者数据开发

3.4数据安全治理

这个事情大的背景是目前数仓关于数据加密脱敏，数据权限管理等工作族本靠共识，比

如大家都知道用户手机号是敏感数据，有人要这份数据时也会多走个流程审批一下。但

是到底哪些表里面有存用户手机号，这些手机号有没有被妥善地加密或脱敏.表授权时

有没有去判断里面是否有敏感数据，这些我们都是不知道的。所以我们考虑基于实体识

别的方法，把数据资产的敏感程度给分级打标出来。

分级打标的依据是集团下发的《网易数据分类分级管理制度》，根据这个文件，我们手

工把数仓的各项涉敏数据项给盘点出来，整理成结构化的数据。再用一个SparkJob的

形式去批量对所有数仓表进行采样和字段打标。大致实现如下4

目前这个系统做了基本的实现，后续需要继续扩展识别项覆盖率和准确率，具体技术细

节我们就不在这里讨论了，后面单开一篇文章分享。

得到分级结果后，我们就可以拿这份数据去重新盘点和治理我们的数据加密和权限管理

情况了。

3.5数据质量治理

质量这块儿我们分事前、事中、事后三块去实施。

（1）事前

事前我们主要是规范数据需求流程，明确各个参与方职责，进行风险评估和保障定义:

业务：需求提出

BI/PM：1、需求拆解2、确定口径

数据开发：需求评审

数据系分评审、链路评估

验证方案、回滚方案

链路风险巡检/治理

SLA定义、保障方式定义

QA：测试评审

测试测分及评审

自测标准、验收标准

测试报告、验收反馈

事故报告、事故复盘

(2)事中

事中我们遵循数据开发。研发自测・>QA自测。数据发布，产品发布。用户险收的流程，

保证研发过程的质量合格。

(3)事后

事后指的是需求交付后的运维保障及应急恢复，这里的策略包括：基线值班、DQC、变

更感知、大促时的压测和发生故障后的复盘。

终端场景分级

数据任务分级

•服务分级

•BI报表分级•PO、Pl、P2、未分级

数据血缘动态基2

•PO、Plfl

线/09:30；

•P2任务：

基线值班会有数据基线该怎么挂的问题，任务A到底要保障到7点产出还是9点产出，

值班的资源是有限的，都保障就意味着保障力度都降低，同理DQC的配置也是。这里

我们的做法是，先从数据的使用场景出发，看看线上服务和有数报表的重要性分级是什

么样的。再根据血缘往上追踪，对整个上游链路的数据任务挨个打标，高优覆盖低优,

以此来确认任务的保障等级。

获得任务分级后，我们把PO,P1的任务挂载到了7:30/9:30两条基线，P2任务挂载到

了10:00基线，由数据值班来保障他们的按时产出，并对破线及任务失败进行记录和复

盘，便于确认后续优化方向。同时，P0、P1的任务也强制要求大家配上了基本的数据

稽核。

然后是变更感知这块儿，包含数据源变更感知和ETL变更感知。数仓不生产数据，我们

在只是数据的搬运工，所以感知数据源的变更和“搬运程序〃的变更对数据质量的保障特

别重要。

实

数据源变更工单自

时

动

数

影

据

任务修改记录响

镜

评

像

估

表修改记录

元数据猛玛尼

这里