缦图数据治理实践概述

路易吉缦图coder

2024年01月31日 06:00

点击关注上方蓝字，阅读更多干货~

1.背景介绍

1.1

数据治理是什么，为什么需要做？

数据已经成为现代企业非常依赖的新型重要资产。数据质量的好坏直接关系到信息的精准度，也影响到企业的生存和竞争力。数据治理目标是使企业的数据形成一个有机的整体和标准化的数据资产，且针对整个企业内部数据的商业应用和技术管理来制定和实施一系列政策，并提供相关赋能。

长期以来将数据治理工作放在一个阶段项目中（如图A方案），会导致时间和人力成本的增加。相对正确的做法应该是将数据治理贯彻在数据建设的各个阶段（如图B方案）。只是在不同阶段中，根据业务特点和技术特点来看，其覆盖的范围和关注的目标会有所不同，我们定位其为一个可持续工程。

图1 数据生产安全流程

1.2

治理的是哪些问题？

长期的数据治理是一项相对细致且复杂的工程，需要与时俱进，需要贴合企业的数据现状。一般来说是为了解决下面几个部分的问题：

图2 常见数据治理问题

规范问题：当公司的业务人员和开发人员逐渐变多时，人员的变动容易造成烟囱式开发，因此需要有至上而下的统一规范。
质量问题：这是核心问题也是根本问题，如果一个数据部门连数据质量这条生命线都无法保障的话，那么其他能力再多也只是空中楼阁。
成本问题：当今是数字化的时代，企业的数据资源的成本膨胀速度往往和业务增长一样快，其中可能就存在一些不合理的增长。
效率问题：开发过程中会有很多技术和业务性问题，为了可以快速解决这些问题，经常会采取堆人力的方式去达成。
安全问题：业务部门需要关注数据安全，比如营销部门的用户敏感数据一旦泄露，会造成难以预估的损失。

1.3

治理前的缦图现状数据如何？

缦图的数据开发平台主要是阿里云的DataWorks+Maxcompute，应用平台主要是帆软FineBI、神策分析等。其中1.0的数仓存在着历史的烟囱式开发，表冗余严重，ETL层级流向不明确的问题；2.0数仓存在推广和数据字典的缺失，无规范稽查等问题。

数据安全无保障：存在AccessKey账号使用粗放无管理，数据表无敏感等级区分，FineBI权限管理不规范，传输到第三方的数据无管控（如神策）等问题。
数据智能没有相关功能触达：存在数据消息缺少统一的内容交互和推送前台，策略无复用，缺少敏捷开发工具等问题。
数据质量现状没有明确认知和监控：存在着无FlineBI数据问题预警的情况，且maxcompute表数据质量监控覆盖率只有2%左右。
数据成本一直处于粗放的状态：根据账单统计，阿里云上的存储和计算成本在持续增加，且弹性资源的实际花费比固定资源高。
数据规范没有统一：缺少弱规则去稽查规范问题的场景，比如：表命名规范，数据层级流向规范等。

1.4

治理后的缦图数据目标是什么？

定位数据安全产生的风险漏洞，形成数据的护城河；管控安全权限，避免敏感数据泄露造成损失。
提升数据开发和运维的效率，减少沟通的人力成本，提高自动化程度。
提升数据质量和业务侧伙伴的数据使用体验，提高数据的准确性、及时性，降低负反馈。
沉淀治理过程中的相关知识库，将得到知识进行复用和推广。
降低不合理资源的消耗成本，形成长期的成本意识，使成本得到合理的控制。
制定稽查机制，提高开发的规范度和数据的可读性。统一标准，保持数据口径的一致性，减少数据冗余。

2.缦图是如何做数据治理的

2.1

缦图数据治理的逻辑架构

图3 缦图数据治理架构

用户：目标是从开发伙伴出发到覆盖全公司的伙伴，使治理的能力得到更加广泛的应用。
目标：首先使受众了解数据治理，可以通过一定自动化的能力快速定位数据问题。然后沉淀出可以解决一类问题的体系化方案，且对治理效果能够做到可评价可衡量。在这些治理活动中也要培养伙伴的规范化意识，因为如果可以在人治的阶段就做好的话，能够解决过程中的不少问题。再用闭环的思维进行循环，最终可以迭代出正确的治理方案。
功能模块：基于这个项目的低代码和资源成本考虑，主要采用了现有的触达方式（钉钉机器人，钉钉OA，数据看板和用户交互治理能力）。在有一定成果以及资源充足的基础上，我们后续再去考虑设计平台化。
治理的领域：主要聚焦在数据成本、数据质量、数据安全、数据规范、数据效率几大核心治理领域上。

2.2

数据安全

实践简述：在数据安全上，我们的目标是可以通过多重能力形成一个缦图独特的“数据安全护城河”，将安全风险降低到一个可控的范围内。

图4 缦图数据安全防护

1. 构建缦图数据的敏感词库和分级：采用定制化的权重算法对表和每个字段进行计算，得出不同分段的敏感等级，并将相关等级数据进行落地。

2. 动态设置数据敏感等级：利用Maxcompute底层可以实现的安全能力，加上已计算出的敏感等级，以动态的形式对表和字段来设置敏感等级label，最终形成Maxcompute中的安全强化数据。

3. 设置人员角色的权限：对项目的所有者和具有权限的用户，进行权限的合理管控。我们根据人员角色设置了不同的初始敏感等级和可访问范围，以及对应的ak账号我们也进行了同步限制。并且，我们对访客角色的用户进行了严格的权限管控（如：无初始权限，需要填写单表申请等）。

图5 数仓监控和行为统计

有了对表及其字段级数据的安全等级设置后，我们的开发伙伴在特定场景下还是存在需要申请使用数据的情形，因此对于安全的授权需要有合格的审批能力。

4. 建立权限审批：我们结合钉钉现有的申请审批流OA所具备的功能，用最少的开发人力资源，完成了授权流程关键人和选项标准化的审批功能。

5. 扩展审批能力：不仅在上述的OA功能上进行了复用，也在账号权限、数据流出、BI查数权限等场景上进行了标准化的审批流设计。

图6 权限审批设计

治理前后对比:

治理前	治理后
无敏感等级，无授权等	覆盖2000+表，细化安全敏感等级，安全授权、统一审批

2.3

数据效率

实践简述：我们了解到伙伴在开发中存在一些效率问题，比如：权限获取慢，数据获取需要问询，治理项无复用等问题。因此我们基于钉钉机器人有一定接口开放能力的情况下，设计并开发了数据专属的api，赋予了其一定的交互功能，使治理能力完成模块化。

图7 数据机器人治理能力设计

例如：

a. 快速审核能力：

原因：OA审批流过长，且开发人员访问数据的频率较高，需要一个既安全又有效率的方式。
实现：开发api模块来调用maxcompute提供的ak访问项目接口，并封装成回调接口，将审核逻辑进行智能化迭代，使一些重复的非重点表的固定化申请能够自动审批（且具有失效时间），再通过群公示的通知方式，告知到审核人和申请人(使安全风险可知晓）。
图8 权限自动审批

b. 数据资产查询：

原因：在使用DataWorks自带的数据地图时，发现检索出的表较多，而且不能够精确的拿到取数人想要的表。
实现：我们针对该场景的痛点进行了设计，将更多的表数据、元数据和规则数据放入库中，利用匹配算法，再把功能进行api封装到机器人中的一个模块中。这样伙伴在@机器人查询之后，能将匹配度最高的表推荐给使用者，并具有自迭代提升精确度的扩展能力。
图9 数据检索

c. 治理SOP查询：

原因：在过去一个治理动作完成之后，往往只是解决了一个阶段的问题，因此解决方案的复用度很低。
实现: 我们将治理的动作和方案沉淀分成多类型的sop，并提供查询入口，让伙伴们可以重复使用，提升问题的解决效率。

图10 Sop指南

治理前后对比：

治理前	治理后
存在预警需要二次开发，无法自助规范稽查，资产检索慢等问题	快速配置监控达20+，自助稽查规范能力2+，治理sop复用沉淀 10+，资产快速获取等

2.4

数据质量

实践简述：在数据质量上，长期存在没有相关质量把控的情况。往往在交付业务方一段时间后，产生了数据问题，业务方再将问题反馈到开发，进行一个数据的修复。因此，我们对数据质量的情况分了四个大类去进行整理。

完整性：在保障数据的完整性上，我们对数据中台全表覆盖了表数据去记录数的异常波动，并且对核心表的字段进行了空值率预警，特殊逻辑校验等。
准确性：我们进行了枚举值的监控，并为了防止异常的脏数据侵入，进行了清洗层(pdw)的规范处理。
一致性：目前指标口径的统一还在持续建设中，我们对部分指标的定义说明提供了方便的查询方式，让伙伴们可以保证指标定义的一致性。
及时性：基于数据运维的能力，我们设置了任务基线，保障核心链路的产出。（设定了核心表在每日7:30前产出，系统就会自动优化调度，使其优先级提前）

我们定义和配置了相关表的基础指标，并对核心表进行了强化监控和跟进处理。针对将产生的质量问题，自研了数据质量预警和通知模块（阿里提供的DQC梯度收费会增加额外成本）。该模块使其能够在低成本的情况下，自定义监控规则发送到个人或者群组，最终通过钉钉消息，邮件等方式推送给相关人员的OR群组去提前发现和解决问题。

图11 通知图例

治理前后对比：

治理前	治理后
数据质量无感知，问题后知后觉低效修复	数据质量覆盖核心表，基础质量指标覆盖2000+，先觉快速定位问题，持续迭代等

2.5

数据规范

实践简述：我们针对目前缦图数据空间存在的问题，利用标准化的定制，对整体的数据开发阶段进行了相应的规范建设，提升伙伴规范意识，避免了不规范的操作和后续维护的人工成本。

a. 标准化规范

数仓模型开发规范
数据应用开发规范
报表开发规范
代码开发规范
任务上线规范

b. 针对开发的3大场景强化规范

数据开发前：制定业务数据仓库的标准规范并完成配置（包括架构分层、表命名规范、字段管理、词根管理、公共维度等），让伙伴具有一个前期的标准化的知识输入，之后再推动伙伴去执行。
数据开发中：在开发过程中，有时候伙伴并不会意识到自己的规范问题。如果在开发后再回头修改费时又费力，对此我们提供相关快速的检测能力，例如：进行表名检测，可以让大家能够快速的发现建表合规性的问题等。

图12 表名检测

数据开发后：因为目前治理能力受制于系统层面，所以在开发之后还需要一个稽查模块去兜底检测规范。这样就可以做到在上线之前能有个自动化的稽查，减少上线之后出现的错误情况，减少事故发生的概率，例如：层级流向异常通告，表命名异常通报等。

图13 表名异常通报

治理前后对比:

治理前	治理后
存在烟囱式开发，代码规范、层级规范、模型规范未打通	统一规范，建立标准，监控异常数据链路

2.6

数据成本

实践简述：为了降低不合理的资源消耗成本，我们需要形成长期的成本意识，使成本得到有效的控制。

a. 形成成本意识：

为了让大家意识到成本的管理是一个共建的过程，治理小组对成本进行了相关的指标推送，这样大家就可以对成本的使用情况有所感知。

b. 降低计算成本：

消耗异常高的任务优化

通过查看任务的计算资源使用数据可以发现，某些任务占用了大部分的计算资源，导致其他任务资源不足；也存在占用配置外的弹性计算资源，导致计算成本增加的情形。针对此情况，我们写了脚本对执行的任务进行监控并报出，发现执行时间长或者占用资源多的任务会及时进行人工优化，降低了20%左右的低效消耗。

经调研发现弹性资源的整体费用会高于固定资源费用

我们对弹性资源迁移到固定资源的所需消耗进行了计算，并对整体的资源做了一个动态管控（其中计算消耗还和企业的业务开展热点月有关系，因此做了按月动态调整资源），目前整体降本50%。

无效孤立节点下线

无效的任务节点占用计算消耗，并且产出的数据也没有使用场景。针对此情况，我们在通过对元数据信息的检索后找出了存在的孤立节点，并通知相关负责人进行确认，对其做下线操作。

图14 实例消耗情况

降低存储成本

各空间在长期的建设过程中，只有增量过程，没有表清理的操作，导致存储成本长期增加。因此我们对于元数据进行了统计，定义了一些指标（如超3月未更新的表，孤立节点等），并对相关的表进行了清理操作，使其存储量瞬时降低了10%，并且形成了周期性的下线任务。

治理前后对比:

治理前	治理后
存在数据存储和带宽成本，计算成本持续增加	降低了10%的存储成本，50%的计算成本

2.7

数据治理大盘

最后为了衡量治理效果，我们加入了相关治理指标的评价，可以从层级流向异常数、不合规表数、权限申请数、权限申请TopN表、异常消耗TopN、各层级表数、数据质量覆盖率等指标来对治理相关的实施进行评价，并且评价结果将作为迭代项实施的指导依据。

图15 缦图数据治理大盘

3.总结展望

在经过一段时间的数据治理后，我们利用体系化和标准化的手段，使长期存在的一些痛点情况（如数据规范、安全、质量、效率、成本等问题）得到了预期的改变。也在和小伙伴的沟通中，对一些治理过程中不合理的设计进行了相应的改进，获得了伙伴的肯定。

但数据治理是一个长期的过程，我们距离最终期望达成的“全自动化”治理和智能数据资产化还有很长的路要走。其中不只需要数据治理小队的努力，更需要相关伙伴的认可和共建，需要一些主观能动性的遵守，也需要一些与时俱进的治理调整能力。下一步，我们将深入数据资产化，通过治理的智能化能力，释放数据资产的价值。

本文作者

路易吉，来自缦图互联网中心数据团队。

-----END-----

继续滑动看下一个