缦图数据治理实践概述

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

 图1 数据生产安全流程

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

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

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

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

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

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

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

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

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

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

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

 

• 消耗异常高的任务优化

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

• 无效孤立节点下线

• 降低存储成本

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