数据治理实践与解决方案
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据治理实践与解决方案
本文主要介绍数据治理的历程和实践经验,以及业务发展各个阶段中数据体系遇到的问题和解决方案。最后,将探讨数据治理在现阶段的建设思路和发展方向。
一、背景介绍
数据治理这个话题这两年非常火热,很多公司尤其大型互联网公司都在做一些数据治理的规划和动作。为什么大家都要做数据治理?从数据产生、采集、生产、存储、应用到销毁的全过程中,可能在各环节中引入各种问题。初始发展阶段,这些数据问题对我们的影响不大,大家对问题的容忍度比较高。但是,随着业务发展数据质量和稳定性要求提升,并且数据积累得越来越多,我们对一些数据的精细化要求也越来越高,就会逐渐发现有很多问题需要治理。数据开发过程中会不断引入一些问题,而数据治理就是要不断消除引入的问题,以高质量、高可用、高安全的方式为业务提供数据。
1. 需要治理哪些问题
数据治理过程中哪些问题需要治理?总结了有五大类问题。
•质量问题,是最重要的问题,很多公司数据部门或者业务线组做数据治理的一个大背景就是数据质量存在很多问题,比如数仓的及时性、准确性、一致性、规范性和数据应用指标的逻辑一致性问题。
•成本问题,互联网行业数据膨胀速度非常快,大型互联网公司在大数据基础设施上的成本投入占比非常高,而且随着数据量的增加成本也将继续攀升。
•安全问题,尤其是业务特别关注的用户类数据,一旦泄露,对业务的影响非常大,甚至能影响整个业务的生死。
•标准化问题,当公司业务部门比较多的时候,各业务部门、开发团队的数据标准不一致,在数据打通和整合过程中会出现很多问题。
•效率问题,在数据开发和数据管理过程中都会遇到一些效率低的问题,很多时候是靠堆人力在做。
2. 数据现状
XXXX业务发展速度比较快,数据增长速度也非常快。如果不做治理,按指数级增长趋势,未来数据生产任务的复杂性还是成本负担都非常大。
针对当时面临的情况,总结了五大类问题:
•标准化的规范缺失,开始建设的时候业务发展非常快,但多个业务线之间的标准化和规范化建设都只是以规范文档的形式存在,每个人的理解不一致,导致多个研发同学开发出来的数据标准就很难达到一致。
•数据质量问题比较多,突出在几个方面,第一个是数据冗余很多,从数据任务增长的速度来看,新上线任务多,下线任务少,数据表的生命周期控制较少。第二个是在数据建设过程中很多应用层数据都是烟囱式建设,很多指标口径没有统一的管理规范,数据一致性无法保证。
•成本增长非常快,在某些业务线大数据存储和计算资源的机器费用占比已经超过了35%,如果不加以控制,大数据成本费用只会越来越高。
•数据安全的控制,各业务线之间可以共用的数据比较多,而且每个业务线没有统一的数据权限管理。
•数据管理和运维效率低,数据使用和咨询多,数据RD需要花费大量时间解答业务用户的问题。
二、治理实践
以前也做过数据治理,从数仓建模、指标管理和应用上做优化和流程规范,当时没有做体系化的数据治理规划。近期基于上面提到的五个问题,做了一个整体的数据治理策略。把数据治理的内容划分为几大部分:组织、标准规范、技术、衡量指标。整体数据治理的实现路径是以标准化的规范和组织保障为前提,通过做技术体系整体保证数据治理策略的实现。同时会做数据治理的衡量体系,随时观测和监控数据治理的效果,保障数据治理长期向好发展。
1. 标准化和组织保障
每个公司在做数据治理时都会提到标准化,我们总体思路也没有太大区别。数据标准化包括三个方面:第一是标准制定,第二是标准执行,第三是在标准制定和执行过程中的组织保障,比如怎么让标准能在数据技术部门、业务部门和相关商业分析部门统一。
从标准制定上,我们制定了一个全链路的数据标准方法,从数据采集、数仓开发、指标管理到数据生命周期管理建立了很多标准,在标准化建立过程中联合组建了一个业务部门的数据管理委员会。管理委员会是一个虚拟的组织,主要组成是技术部门和业务部门,技术部门是业务数据的开发团队,业务部门是业务数据的产品团队,这两个团队作为实现的负责人,各自对接技术团队和业务团队。
2. 技术体系
在执行过程中也不希望完全通过人力和组织来推动达成,总体希望以一些自动化的方式进行。下面介绍一下技术体系。
①数据质量,数据质量是数据质量中最重要的一个问题,现在数据治理的大部分问题都属于数据质量。这里有四大问题:
•数据仓库的综合性比较差,虽然有一些规范文档,但更依赖个人理解去执行。
•数据一致性问题多,主要表现在数据指标的管理上。指标管理以前在文档中定义指标,没有系统化的统一管理逻辑和查询逻辑。
•数据应用非常多,使用数据的方式包括数据表同步、接口消息推送、OLAP 引擎查询等,不能保证数据应用端的数据一致性。
•产品非常多,业务数据产品入口有十多个,没有统一的入口,也没有人对这些产品统一把关,导致数据应用和使用方式有很多分歧。
我们的技术实现方式是为了解决上面这四大类质量问题,首先在数据仓库规范性上进行统一,然后统一指标逻辑,在此之上统一数据服务接口,最后在产品上统一用户产品入口。从这四大方向将常见的数据质量问题管控起来,具体技术实现方式如下。
数仓建模规范
统一数仓建模规范分三大部分实现,以前只有事前的一些标准化规范,大家按自己的理解去建模实现。在这个基础上增加了事中和事后两个部分,针对事中开发了系统化工具,做数仓配置化开发。事后做规则化验证。事前会有标准化文档给大家提前理解、宣贯,事中很多标准化的事项会通过配置化自动约束规范,事后会有上线时的检验和上线后每周定期检验,检验数据仓库的建模规范是否符合标准,把不符合标准的及时提示出来、及时改进。
事前的标准化规范几个方向,第一是数据仓库的设计规范,在做一个新业务或模块之前,以文档形式做一些设计规范。第二是开发规范,包括一些开发流程、代码编写规范和注释信息。这些形成之后还想在事中以系统化的方式进行控