大数据治理和数据治理的区别概述

大数据治理和数据治理的区别概述,第1张

1、什么是数据治理

数据治理(Data Governance)是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行,关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。

数据的质量直接影响着数据的价值,并且直接影响着数据分析的结果以及我们以此做出的决策的质量。我们常说,用数据说话,用数据支撑决策管理,但低质量的数据、甚至存在错误的数据,必然会"说假话"!!! 数据治理即提高数据的质量,发挥数据资产价值。

2、数据治理的目的

降低风险

建立数据使用内部规则

实施合规要求

改善内部和外部沟通

增加数据价值

方便数据管理

降低成本

通过风险管理和优化来帮助确保公司的持续生存

3、数据治理的方法

从技术实施角度看,数据治理包含“理”“采”“存”“管”“用”这五个步骤,即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。

数据资源梳理:数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单,包含组织机构、业务事项、信息系统,以及以数据库、网页、文件和 API 接口形式存在的数据项资源,本步骤的输出物为分门别类的数据资源清单。

数据采集清洗:通过可视化的 ETL 工具(例如阿里的 DataX,Pentaho Data Integration)将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程,目的是将散落和零乱的数据集中存储起来。

基础库主题库建设:一般情况下,可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据,或称主数据,例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据,例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据,例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上,基于易存储、易管理、易使用的原则抽像数据存储结构,说白了,就是基于一定的原则设计数据库表结构,然后再根据数据资源清单设计数据采集清洗流程,将整洁干净的数据存储到数据库或数据仓库中。

元数据管理:元数据管理是对基础库和主题库中的数据项属性的管理,同时,将数据项的业务含义与数据项进行了关联,便于业务人员也能够理解数据库中的数据字段含义,并且,元数据是后面提到的自动化数据共享、数据交换和商业智能(BI)的基础。需要注意的是,元数据管理一般是对基础库和主题库中(即核心数据资产)的数据项属性的管理,而数据资源清单是对各类数据来源的数据项的管理。

血缘追踪:数据被业务场景使用时,发现数据错误,数据治理团队需要快速定位数据来源,修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库,核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系,且业务团队使用的数据项由元数据组合配置而来,这样,就建立了数据使用场景与数据源头之间的血缘关系。 数据资源目录:数据资源目录一般应用于数据共享的场景,例如政府部门之间的数据共享,数据资源目录是基于业务场景和行业规范而创建,同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

质量管理:数据价值的成功发掘必须依托于高质量的数据,唯有准确、完整、一致的数据才有使用价值。因此,需要从多维度来分析数据的质量,例如:偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是,优秀的数据质量模型的设计必须依赖于对业务的深刻理解,在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响,例如 Hadoop,MapReduce,HBase 等。

商业智能(BI):数据治理的目的是使用,对于一个大型的数据仓库来说,数据使用的场景和需求是多变的,那么可以使用 BI 类的产品快速获取需要的数据,并分析形成报表,像派可数据就属于专业的BI厂商。

数据共享交换:数据共享包括组织内部和组织之间的数据共享,共享方式也分为库表、文件和 API 接口三种共享方式,库表共享比较直接粗暴,文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式,在这种方式下,能够让中心数据仓库保留数据所有权,把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现,常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

4、数据治理流程

基本流程:发现数据质量问题 >定义数据质量规则 >质量控制 >质量评估 >质量优化

苏宁八大产业,每个产业有自己的数据集市,每个数据集市有自己的维度表,没有统一的维度管理(包括管理规范和系统支撑)。业务痛点包含以下几个方面:

建立统一的维度管理系统,实现对维度信息的统一管控,并为集团的数据产品提供统一的维度数据服务,包含维度开发管理,维度信息管理及维度数据服务三个方面。

维度数据

如上图所示,ETL将采集的数据,进行数据清洗之后存储到维度数据仓库(磐石)中,维度系统再将维度数据仓库中的数据同步达到维度库系统。

维度数据存储方式:维度数据一般以一百万的数据量作为分割点,一百万以上数据量的维度采用的存储是HBASE,一百万以下的数据采用的存储是MYSQL。

维度数据同步方式:存储到HBASE的维度数据采用的是BULKLOAD导入,存储到MYSQL的维度数据采用的是SPARKSQL+RDD写入。针对数据同步都已经实现通过页面配置任务的方式一键同步,节省人工。

为什么采用这种存储方式?

1, 针对数据量的大小采用不同的存储引擎,节约存储资源,提高维度服务的稳定性。

2, 实时指标的计算:OALP需要关联维度表和事实表做指标数据加速(实时计算指标数据)。这种需要实时的查询维度表的所有维度属性,调用量非常庞大,所以采用了直接查询HBASE的方式。

3, 维度需要提供基于维度值ID查询维度值名称的服务(包括批量精确查询和模糊查询),HBASE在精确查询上性能较高。MYSQL由于数据量不大,可以再加一层分布式缓存,提高精确查询维度值的性能。

维度建模

1, 选择业务过程

根据业务场景以及可用数据源

2, 声明粒度

根据事实表及应用场景,确定汇总粒度,一般尽可能的用最细粒度

3, 确定维度

根据确定的粒度,定义对应的维度,最细粒度,也是最低层次的维度

4, 确定事实

确认将哪些事实放到事实表中,维度表只是做关联,不做维度数据的查询服务。

维度定义

1. 当增加新的维度时,编码号将在已用号码的基础上递增,四位十进制编码号不能满足需求时,可增加编码号长度为五位十进制数,以此类推。

2. 当删除已有的维度时,其编码号将不再利用。

3. 当修改已有的维度时,其编码号不变。

4. 当拆分已有的维度或合并两个及两个以上的维度时(数据应用场景需要),其编码号的使用原则按照删除原维度,并新增拆分/合并后的维度执行。

维度管理

维度:目前维度平台支持快速定义维度,通过设置维度的基本信息,选择维度映射的维度表,做好维度与维度表的映射,设定维度的一些特性(布尔维度,时间维度,杂项维度等),检测维度的定义结果。达到了让业务人员能够只是通过页面 *** 作就可以制定需要的维度。

维度表:数据开发人员可以通过维度库平台定义维度表,定义好之后可以集成数据仓库的同步任务一键将仓库的数据同步到维度表中,将维度表与维度做映射关系。

维度层级:维度库平台支持定义维度层级,只要是维度库平台上有的维度表并且做好维度与维度的映射关系之后,就可以定义需要的维度层级,根据维度层级提供维度值的上卷下钻查询服务。

维度血缘:提供了维度,指标,报表的血缘关系,以及还准备做的维度数据的血缘,维度,指标,报表调用次数的血缘等等。

维度服务

1. 维度服务调用申请:

调用维度服务,需要在维度库管理系统中申请调用权限。等维度管理系统授权之后,生成维度服务调用授权码,在调用维度服务的时候带上维度服务调用授权码,维度服务会根据授权码判定是否有访问权限。

2. 维度系统提供的服务:

1,对存储在HBASE的维度表,我们又加了一层存储到ELASTICSEARCH(提供维度值的模糊查询服务)

2,针对负载较高的HBASE表,加了一层本地缓存,解决热点问题。

3,对存储在MYSQL的维度表,我们又加了一层存储到分布式缓存ZEDIS(提供维度值精确查询服务)。提供了定时或者手动刷新缓存数据的功能,以及缓存数据的监控机制。

监控分析

由于维度服务的调用量是亿万级别的,系统的监控统计,采用的是Log4j+kafka+druid的架构,如下图所示,应用将调用日志采用log4j- KafkaLog4jAppender写入kafka中,再将kafka与druid集成,准实时的输入druid中,业务基于druid做统计分析,查看维度服务调用成功或失败的情况。

除了维度服务的调用监控,平台还有针对维度值的数据量监控(主要监控暴增或者突然没有维度数据的情况),维度值数据质量的监控(根据维度表和事实表做数据比对,分析维度值数据的差异情况)。维度数据同步任务的监控(每个维度表的数据同步情况监控,异常告警到具体的任务负责人)。通过各种有效的监控手段,来提升维度服务的稳定性和准确性。

1. 未来平台会更加的完善,会有越来越多的维度在平台上建设,提供更加稳定和高效的维度查询服务。

2. 能够支持更多个性化的维度,能够支持维度的数据版本(例如过去一段时间的维度值),支撑全集团所有数据产品的维度调用服务,将平台打造成苏宁主数据服务的航空母舰。

3. 通过维度数据资产体系的建立,实现集团一切业务数据化,连接打通数据孤岛,驱动一切数据业务化,助力企业数字化转型,让数据做到真正意义上的产生价值。

4. 通过提供各种维度数据支持数据产品及各类应用产品,帮助各岗位用户在日常经营决策中做出正确决策。

目前平台的现状及以后的规划

1, 完善系统监控功能点:缓存任务较多,没有有效的监控,告警机制。

2, 完善业务监控功能点:数据量监控,数据异常监控,告警功能

3, 落地维度新增、变更、下线全流程审核管理功能.

4, 完善应用层的维度、指标、报表数据链路的血缘分析图谱,全方位透析资产,

5, 打通全链路维度变更通知的消息机制,降低数据链路变更带来的风险,

6, 多系统用户资源隔离、限流,保障多个部门在使用和体验上的一致性,

7, 支持用户自定义维度、完善个人工作台,基于通用维度进行维度的衍生,

8, 维度门户的建设,将业务端和管理端进行隔离,提升用户体验

企业数据分析系统的数据来源是各个业务系统或手工数据,这些数据的格式、内容等都有可能不同。如果不进行数据治理,数据的价值难以发挥。只有对数据标准进行规范,管理元数据、数据监控等,才能得到高质量的数据。得到规范的数据后,才可在此基础上进行主题化的数据建模、数据挖掘、数据分析等。

2013年被众多的IT人定义为中国的大数据元年,这一年国内的大数据项目开始在交通、电信、金融部门被广泛推动。各大银行对Hadoop的规划、POC尤其风生水起,带动了一波大数据应用的热潮,这个热潮和当初数据仓库进入中国时的2000年左右很相似:应用还没有想好,先归集一下数据,提供一些查询和报表,以技术建设为主,业务推动为辅。这就导致了这股Hadoop热潮起来的时候,传统企业都是以数据归集为主的,而BAT这样的企业则天生以数据为生,早早进入了数据驱动技术和业务创新的阶段。

随着Hadoop技术的提升,数据如何进来,如何整合,开展什么样的应用都已经有了成熟的案例,可是,同传统数仓时代一样,垃圾进垃圾出,如何破?相比传统数仓时代,进入Hadoop集群的数据更加的多样、更加的复杂、量更足,这个数仓时代都没有处理好的事情,如何能够在大数据时代处理好,这是所有大数据应用者最最期盼的改变,也是大数据平台建设者最有挑战的难题:数据治理难的不是技术,而是流程,是协同,是管理。 睿治数据治理平台平台架构

元数据:采集汇总企业系统数据属性的信息,帮助各行各业用户获得更好的数据洞察力,通过元数据之间的关系和影响挖掘隐藏在资源中的价值。

数据标准:对分散在各系统中的数据提供一套统一的数据命名、数据定义、数据类型、赋值规则等的定义基准,并通过标准评估确保数据在复杂数据环境中维持企业数据模型的一致性、规范性,从源头确保数据的正确性及质量,并可以提升开发和数据管理的一贯性和效率性。

数据质量:有效识别各类数据质量问题,建立数据监管,形成数据质量管理体系,监控并揭示数据质量问题,提供问题明细查询和质量改进建议,全面提升数据的完整性、准确性、及时性,一致性以及合法性,降低数据管理成本,减少因数据不可靠导致的决策偏差和损失。

数据集成:可对数据进行清洗、转换、整合、模型管理等处理工作。既可以用于问题数据的修正,也可以用于为数据应用提供可靠的数据模型。

主数据:帮助企业创建并维护内部共享数据的单一视图,从而提高数据质量,统一商业实体定义,简化改进商业流程并提高业务的响应速度。

数据资产:汇集企业所有能够产生价值的数据资源,为用户提供资产视图,快速了解企业资产,发现不良资产,为管理员提供决策依据,提升数据资产的价值。

数据交换:用于实现不同机构不同系统之间进行数据或者文件的传输和共享,提高信息资源的利用率,保证了分布在异构系统之间的信息的互联互通,完成数据的收集、集中、处理、分发、加载、传输,构造统一的数据及文件的传输交换。

生命周期:管理数据生老病死,建立数据自动归档和销毁,全面监控展现数据的生命过程。

数据安全:提供数据加密、脱敏、模糊化处理、账号监控等各种数据安全策略,确保数据在使用过程中有恰当的认证、授权、访问和审计等措施。

建立完整的、科学的、安全的、高质量的数据管控技术体系,是首要的任务。作为数据管控的基石,为了更好支撑后续工作的开展,技术体系必须一步到位,是功能完备、高质量、高扩展性的,而不是仅实现部分功能,或者功能不完善的“半成品”。

叠加更多业务数据、细化数据业务属性与管理属性、优化与调整数据管控流程,尤其是适应未来的现代企业数据管控制度的建立完善,是逐步积累推广、不断磨合改进的长期过程。这些工作应及早启动,并成为后续大数据平台建设工作的重点。

谈大数据时代的数据治理 当前要做的是功能框架的完善,而完善的着力点则是“数据资产目录”:用资产化的视角来管理一个企业的数据,只有把数据作为资产来认识和管理,大数据项目才能达成预期,也能够治理好。大数据时代带来的价值,个人认为主要有两个,一个是技术架构,主要是架构理念的进步,另外一个更重要的则是对数据的重视。大数据时代是数据的时代,IT向DT转型,不单单是BAT,所有的IT公司,未来都在数据这两个字上。

对于一个企业来说,把数据作为资产,才是建设大数据的最终目的,而不是仅仅是因为Hadoop架构带来性价比和未来的扩展性。当一个企业把数据作为资产,他就像管理自己名下存折、xyk一样,定期梳理,无时无刻不关心资产的变化情况,关注资产的质量。

而资产目录就是管理资产的形式和手段,他像菜单一样对企业的资产进行梳理、分门别类,提供给使用者;使用者通过菜单,点选自己需要的数据,认可菜单对应的后端处理价值,后厨通过适当的加工,推出相应的数据服务;这是一个标准的流程,而这些流程之上,附着一整套数据管理目标和流程。

大数据平台以数据资产目录为核心,将元数据、数据标准、主数据、数据质量、数据生命周期、数据轮廓等信息在逻辑层面关联起来,在管理层面上整合成统一的整体,构建起数据管理体系,全面的支持数据服务等具体应用。

大数据平台实现了数据存储、清洗和应用。在数据汇入和汇出的过程中,需要对数据的元数据进行统一记录和管理,以利于后续的数据应用和数据血缘分析。数据质量一直是数据集成系统的基础工作,对数据的各个环节设置数据质量检查点,对数据质量进行剖析、评估,以保证后续应用的可信度。

在数据收集的过程中,随着数据维度、指标的聚集,如何找到所需的业务指标及属性,并且评估相关属性的业务及技术细节,需要对收集的所有数据进行业务属性,并进行分类,建立完善的数据资产目录。

数据资产目录是整个大数据平台的数据管理基础,而数据资产目录由于数据的多样性,在使用的过程中,必然涉及数据权限的申请、审批管控流程,而管控流程的建立依赖于相应岗位的设立和对应职责的建立。

大数据平台的数据管理架构规划,通过数据物理集中和数据逻辑整合,彻底摆脱企业“数据竖井”的困境。大数据平台数据管理架构分为功能架构、流向规划和数据架构三个层面。

数据管理功能架构:借鉴DAMA数据管理和DMM数据成熟度理论,着眼于数据管理技术和数据管理流程融合,组织数据管理功能。

数据流向规划架构:规划整个大数据平台的数据流向,并在数据流入、数据整合、数据服务的具体环节实现精细化管理。

数据管理的数据架构:以数据资产目录为核心,数据项为最小管理单元,将技术元数据(实体、属性和关系)、业务元数据和管理元数据(数据标准、主数据、数据质量、数据安全)融合为彼此紧密联系、密不可分的整体,共同构成精细化管理的数据基础。

数据管理在整个大数据平台不仅仅是一个主要功能模块,它还是整个企业层面数据治理的重要组成部分,它是技术和管理流程的融合,也需要合理管控流程框架下组织机构之前的协调合作。如何利用统一的数据管理模块对企业所有进入到数据湖的数据进行有效管控,不单单取决于数据管理模块本身,也取决于元数据的合理采集、维护,组织结构及制度的强力支持保证。

谈大数据时代的数据治理 大数据平台数据管理参照了DAMA对于数据管理的九个管理目标,并进行裁剪,并对部分管理目标进行了合并,并参照了CMMI制定DMM数据成熟度目标,采用循序渐进,逐步完善的策略对管理目标进行分阶段完成,制定完整的管控流程和数据治理规范,以便持续的对数据进行管理,递进实现DMM定义的成熟度目标。

亿信睿治数据治理管理平台和DAMA的对应关系如下:

谈大数据时代的数据治理 大数据平台数据管理的核心内容是数据资产目录,围绕数据资产目录的数据流入、数据整合、数据服务都是数据管理的核心。数据管理主要管理数据的流动,以及管理流动带来的数据变化,并对数据底层的数据结构、数据定义、业务逻辑进行采集和管理,以利于当前和未来的数据使用。为了更好的对数据进行管理和使用,制度层面的建设、流程的设立必不可少,同时也兼顾到数据在流动过程中产生的安全风险和数据隐私风险。

因此数据管理介入到完整的数据流转,并在每个节点都有相应的管理目标对应,整个数据流框架如下图所示:

谈大数据时代的数据治理 企业在建制大数据平台的同时,对进入数据湖的数据进行梳理,并按照数据资产目录的形式对外发布。在发布数据资产之后,则对进出数据湖的数据进行严格的出入库管理,保证数据可信度,并定期进行数据质量剖析检查,确保数据资产完善、安全、可信,避免“不治理便破产”的谶言。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/6618498.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-03-25
下一篇2023-03-25

发表评论

登录后才能评论

评论列表(0条)

    保存