数仓治理-数据表合规治理
本文参考[数据治理实践 | 数据表合规治理]这一主题，在本次将从数据表治理角度出发的基础上深入阐述数据表合规治理的最佳实践与应对策略等相关内容。
探讨数据规范化管理与表格规范化的实践路径 | 在数据治理中践行规范性要求
目录
前言
一、数据表合规治理的背景
二、数据表合规治理前的思考
三、数据表合规治理的过程
3.1 数据标准重制定
3.2 无用/临时数据表下线
3.3 应用指标公共逻辑下沉
3.4 解决ODS穿透问题
3.5 烟囱表重构/下线
3.6 非合规数据表的元数据重构/修改
3.7 数据表合规后续维护
四、数据表合规治理的结果
五、数据表合规治理中遇到的难点
六、数据表合规治理思考
前言
我们经常收到下游反馈。如以下问题所示：数据表使用不便、难以确定查询指标的来源、命名缺乏统一规范等。此类问题的存在使得合规治理的重要性日益凸显。
一、数据表合规治理的背景
在业务快速迭代的背景下，在发展初期就需要满足多场景应用的需求。由于现有许多数仓在初步搭建阶段缺乏统一的数据标准和模型设计规范，并且团队成员的技术和业务水平参差不齐。为了迅速支持业务需求而导致分层混乱，并生成大量"烟囱式"数据表。无规范或无元数据维护的数据表难以有效使用且复用性较差。举例而言，在当前业务线中存在数据表混乱的情况；查询某指标时发现线上有超过5个数据表进行了重复加工（因缺乏统一的指标中心而导致）。历史字段名或表名的命名也较为随意且未遵循规范化管理。线上系统的依赖关系错综复杂导致生成时间延迟；通过血缘分析法发现ODS穿透率为23%。
该指标表示为ODS跨层引用率的一种衡量标准。它主要涉及ODS层至ADS层之间的引用关系。具体而言，在计算层面时采用以下指标：即被跨层引用的ODS表数量与整个ODS层面存在的表数量之比。
二、数据表合规治理前的思考
由于因各数据表间相互依赖关系过重而导致链条过长且复杂，在安排相关工作时需先与团队沟通并确定治理优先级。按照以下顺序开展工作：首先重新制定核心数据标准；随后移除无用或临时的数据表；接着公共逻辑下沉复用以提升模型覆盖范围；之后优化ODS穿透管理机制以确保业务连续性；再进行烟囱式数据表重构并移除它们；最后针对非合规场景下的元数据重新构建以确保完整性。
烟囱数据表重构及下线--> 非合规数据表的元数据重构
烟囱数据表重构及下线--> 非合规数据表的元数据重构
可以利用平台完成当前数仓模型的质量评估工作，并据此制定后续治理策略。通过使用网易的数据治理系列平台中的easy data和数据治理360功能来实现模型质量的全面评估。
（网易easy data-模型设计中心Demo图）
（网易easy data-数据治理360 Demo图）
三、数据表合规治理的过程
3.1 数据标准重制定
根据业务流程对现有数据区域进行优化调整，并对元数据规范进行详细梳理（包括表名、字段名称以及字段的数据类型等）。
（1）数据域 vs 主题域
从业务角度自上而下进行分析研究，在整体业务流程中进行提炼和总结的基础上形成的专项分析模块，在更高的层次上对各环节进行关联性考察与深入剖析
基于数据视角自上而下的分析方法能够提取出业务流程或维度中的关键特征。这些特征构成了一个由核心要素构成的集合体，在构建dwd层的过程中需要注意以下几点：一方面要确保所有当前业务需求都能得到充分覆盖；另一方面要保证新接入的业务不会对现有dwd层架构产生任何干扰，并支持其自然延伸至新的dwd层级结构。
（2）元数据规范
除此之外还有具体操作规范、存储规范、由负责人进行标注以及确保字段类型的一致性
一、数据表命名规范
（1）ODS层（接入层）：
ods__{业务数据库名}_{业务数据表名}（可以在结尾补充增量或全量情况，或者在元数据侧补充）
（2）DWD层（明细层）：
dwd_{一级数据域}_{二级数据域}_{三级数据域}_{业务过程（不清楚或没有写detail）}_存储策略（df/di，df为全量数据，di为增量数据)）
（3）DWS层（汇总层）：
dws_{一级数据域}_{二级数据域}_{三级数据域}_{颗粒度}（例如员工/部门）_{业务过程}_{周期粒度}（例如近30天写30d、90天写3m）
（4）ADS层（应用层）：
ads_{应用主题/应用场景}_{颗粒度}（例如买家/卖家）_{业务过程}_{调度周期}（例如1天调度一次写1d）
（5）DIM表（维度表）：
dim_{维度定义}_{更新周期（可不添加）}（例如日期写date）
（6）TMP表（临时表）：
tmp_{表名}_{临时表编号}
（7）VIEW（视图）：
{表名}_view
（8）备份表：
{表名}_bak
二、数据表命名词根
（1）存储策略
df：日全量
di：日增量
hf：小时全量
hi：小时增量
mf：月全量
mi：月增量
wf：周全量
wi：周增量
（2）数据粒度
buyer：买家
seller：卖家
user：用户
emp：员工
order：订单
（3）统计周期
1d：近一天指标统计
1m：近一月指标统计
1y：近一年指标统计
3m：近三个月指标统计
6m：近六个月指标统计
nd：近n天指标统计（无法确定具体天可用nd替代）
td：历史累计
（4）调度周期
1d：天调度
1m：月调度
1y：小时调度
三、字段命名规范
（1）是否某某类型用户，字段命名规范：is_{内容}
（2）枚举值类型字段命名规范：xxx_type
（3）时间戳类型字段命名规范：xxx_date,xxx_time
（4）周期指标命名：{内容}_{时间描述}（如最近一次lst1，最近两次lst2，历史his，最近第二次last2nd_date）
（5）百分比命名：{内容}_rate
（6）数值类型（整型）命名：{内容}_cnt_{周期}（周期看情况添加）
（7）数值类型（小数）金额命名：{内容}_amt_{周期}（周期看情况添加）
四、字段类型规范
文本：String
日期：String
整数：Bigint
小数：高精度用Decimal、正常使用Double
枚举值：单枚举-'Y'/'N'用String、多枚举用String
各类：IDString
五、数据表中其他元数据规范
数据表负责人（owner）；
数据表中文名及使用说明；
每个开发字段中文名（中文名需要包含该字段内容，例如是否为某某类型用户，需要写出包含内容(Y/N)）；
数据表的颗粒度；
数据表的主键或联合主键；
六、数据表中存储周期规范
ODS层：1年
DWD层：3-5年
DWS层：10年（部分可永久）
ADS层：10年（部分可永久）
DIM层：3-5年（部分可永久）
数据表分区建议最多2级分区，超过2级分区会造成数据长周期存储问题。通常1级分区为业务日期，2级根据业务场景设置。3.2 无用/临时数据表下线
基于明确依据，在数仓侧规划开发血缘数据表，并有条件地扩展至可视化侧（便于了解涉及的基表信息），其将被下游xx类数据服务所使用）的前提下（或建议）对线上长期无用表、下游无血缘且空跑数据表、临时表展开扫描排查并予以关闭处理（以减少存储资源和计算资源的浪费）。
注
A Metadata System for the Modern Data Stack | DataHub serves as a tool for discovering and managing metadata within a flexible framework designed to handle modern data ecosystems.
元数据生态系统 https://datahubproject.io/](https://datahubproject.io/ "现代数据堆叠 | DataHub")
3.3 应用指标公共逻辑下沉
在业务扩张期时，数仓为了迅速满足需求而采用烟囱式开发策略。由于缺乏一套完善的指标建设中心，在长期下去后会出现指标冗余以及复用效果不佳等问题逐渐显现。针对这一问题，数仓团队的解决方案包括首先检查应用层的指标口径是否一致。如果发现不一致，则需与下游部门沟通并进行相应调整；确认了应用层的模型指标口径一致之后，则会按照数据域和周期划分（如1天、30天、60天以及历史时间范围等）对各项指标进行拆解。接着，在确保数据粒度和逻辑一致性的同时进行去重处理，并将这些标准化后的指标统一汇总至公共逻辑轻度汇总层进行复用。
3.4 解决ODS穿透问题
基于血缘关系识别跨层级引用的数据库，并将其按照模型五要素——即包括数据域、事实表、粒度划分以及维度与度量指标——构建CDM框架中的DWD与DWS层次结构。随后评估ADS层次中的指标体系对新增DWS数据库的质量表现，并最终实现所有DWD与DWS层次的数据库上架，并同步更新ADS层次的引用关系。
3.5 烟囱表重构/下线
针对线上历史数据源中反复开发的烟囱数据表进行优化调整或彻底终止处理。具体而言，在粒度一致且场景相似的数据源中整合字段内容并去除冗余项后重新构建数据模型。烟囱表重构/下线可能会影响下游报表等应用功能，请确保提前与 downstream团队协调一致并顺利过渡到新架构。
3.6 非合规数据表的元数据重构/修改
基于非合规数据表的元数据信息按照标准规范进行重构。建议首先重构ODS、DWD及DWS的数据表，在确保其准确性后再逐步推进至 reconstructing ADS table. 由于大多数 downstream application services（如报表和 BI dashboard）主要依赖于 ADS 层获取原始数据，在此过程中需同步更新 table name 以及代码中的相关字段引用. 因此，在对 ADS 表进行元数据修改时，请确保与 downstream 团队保持协调一致.
3.7 数据表合规后续维护
不仅能够从数据分析的角度全面考量数据价值（如参考频率、访问量以及收藏数量等指标），还需结合元数据规范建立数据库合规性评价体系，并分别设立红旗榜与黑名单，并配套相应的激励与处罚机制。随后可以通过Python等工具实现对不符合规范的数据表格进行提醒功能（如每日提醒与每周提醒）。随后可以通过邮件或群聊形式向相关负责人发送通知：若负责人未采取行动，则应收回相应数仓中的相关数据表格权限。此外还可以构建专门的数据设计中心，在新系统上线前必须完成严格的数据模型审查工作；对于新建立的数据表格，在通过严格的审核流程后才能投入使用。
ps: 3.1~ 3.4 在数仓内部进行治理， 3.5~ 3.7 数仓需要跟下游一起配合推进。
四、数据表合规治理的结果
数据表合规治理的量化指标可以有以下几个方面：
（1）下线各层无用/临时数据表总计xx+张，释放存储资源xxT；
（2）完成xx+个应用层烟囱数据表整合，及xx+公共指标下沉；
（3）ODS穿透率由原来xx%下降至x%；
（4）推出治理红黑榜，维持数仓整体的资产健康分在80分以上；
（5）数据产出平均时间由原来每日最晚8:30产出降低至7:10（任务链路缩短）；
（6）与团队协作经讨论最终达成并实施了关于业务线数仓数据表命名统一标准、字段命名统一标准、字段类型统一规范以及数据表分区生命周期管理规范等多个方向的规范化工作；
（7）模型覆盖率提升至xx%；
（8）下游找数仓临时取数的需求少了，下游查找表及指标的效率提高了；
五、数据表合规治理中遇到的难点
在治理阶段的后期阶段，通常会遇到烟囱数据表重构的问题。然而尽管如此，在迁移过程中必须与下游单位配合修改报表格式会导致工作量倍增进而难以推进整体治理进度。即使尝试制定合理解决方案也可能会因下游遇到各种突发状况而使治理进程一再延后随后仍需反复进行调整才能完成数据表的更换工作，在协调上也面临着诸多挑战
六、数据表合规治理思考
持续性的工作是数据表合规治理的本质特征。在数仓侧的工作体系中，并非所有数据表都能达到合规且易用的标准。因此，在部门内部需要通过持续的改进机制将数据表治理工作常态化、规范化，并建立和完善相应的治理方案以避免类似问题反复出现。
在数据表合规治理的实践中，在与下游部门协作时面临的主要障碍之一便是跨部门协调效率不高。通过回顾经验教训后发现，在推动组织内部流程优化方面需要特别注意以下几点：
为了促进下游合作的关键在于激发他们的积极性。
由于数据表治理对下游而言并非不可或缺。
即使数仓未实施数据表治理措施，在线任务仍能正常运行。
这些downstream依然能够获取所需的数据。
虽然数仓更新了data table内容 从而提升了内部易用性 但从downstream角度来看 并未产生任何感知上的变化。
在优先支持 downstream业务的前提下 我们可以通过分析其在使用过程中遇到的问题 来提升表格的整体易用性 进而提高他们在检索时的效率 同时降低对num仓表格依赖的程度。
（2）设立一些奖惩机制，激励下游认识到配合的价值。例如采用红黑榜的方式定期向他们发送邮件或信息，并结合简单的培训来增强他们的管理意识，在他们自主进行治理后给予适当的奖励。
（3）若周边部门治理取得了一定成效，则需进一步推动工作开展。例如，在与下游部门协同治理并取得了显著成效后，请将治效成果以月度报告/周度报告的形式发送至全体部门，并使其他部门也能及时感知到相关情况。同时建议定期总结治效经验并分享给相关部门，并积极与各业务线协调沟通以推动数仓内部信息共享机制优化。