数据治理学习笔记(二):在数仓建模过程中,数据治理要怎么做

2024-09-02 21:36

本文主要是介绍数据治理学习笔记(二):在数仓建模过程中,数据治理要怎么做,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

之前写了点数据治理的大概定义,中间的工作中也接触到了一部分的数据治理(大概是)工作,最近在复习数仓建模的一些东西,正好结合做个整理备忘,按我自己理解的方式去看数据治理。

背景

数仓在大多数场景里都有运用到,这里按数仓分层的逻辑来讲点数据治理的东西。

叠甲

可能有些地方我理解有问题,不在数据治理工作中,就当是自己的工作总结吧,有人提出大的问题,我再改改。小问题就凑合看看,当一个参考。

1.ODS/DIM 层

原始数据层: 大部分做的是直接获取到各数据来源的基础数据,获取和存储也有很多方式,不做单独的说明。在大多数情况都是要求保持数据不变动,所以在治理这方面,主要在于数据提供方。后面数据价值的成功发掘必须依托于高质量的数据,所以保证ODS层的数据质量是很有必要的。
维度层: 两个层是最贴近数据来源的地方,就和ODS层放在一起讲,基本是用更符合业务逻辑的维度表去规范ODS层的数据质量。例如:偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是,优秀的数据质量模型的设计必须依赖于对业务的深刻理解。
实践中:平时经常遇到本来设计的要有数据,要和其他地方有联系的数据,结果不是缺就是和设计的有出入,这直接导致一个问题,要两方来适配。最有效的方式就是反馈给业务方,整体修改,保证数据提供有效,平时开发能严格按设计来做。理论上虽然是这样,但是在业务方来看“系统能正常跑就行” ==。
好吧,在大数据这边做处理的话,目前来说也只是做些缝缝补补,

  1. 做数据的拉取时,加一层判断,初步做一些数据量变化,和数据合理性的判断。
  2. 数据归集,做一定的逻辑分析,可以更明确的看到业务中的问题,反馈给业务方,保证数据的可用性,这个也算大数据这边的一个功能吧,只能看到啥数据有问题让他们改。
  3. 再有就是数据清洗的一些工作,实在无法修改的,不影响下游的数据,可以做一定的清洗,保证数据质量。

其实能做的还是反馈给上游,保证质量,在抽取之后做的处理都是被动的,也有失原有的数据特性。

2.DWD层

数据仓库明细层(事实层) 用于存储经过清洗和加工的明细数据。作用将ODS层数据根据业务主体要求,将ODS数据抽取到DW层,在保证和ods层颗粒度一致的情况,形成一份最详细的明细数据,同时此层还可以进行一定维度退化的方案。最终优化出数据质量更高的信息,形成一个既定的事实,不允许修改。

  1. 合理的表设计:在明细表以上都是可以按已有逻辑,自己设计的,在这里就可以做一些表层面的治理方法,覆盖最大化,有效数据利用明确化,还有后面的血缘也是要考虑进去。可以根据经验和实际业务来规范表设计方案,毕竟符合自己业务的才是好用的。
  2. 血缘追踪:数据被业务场景使用时,发现数据错误,数据治理团队需要快速定位数据来源,修复数据错误。那么数据治理需要知道业务团队的数据来自于哪个核心库,核心库的数据又来自于哪个数据源头。血缘在每一层都该做好设计,明细层的特性就是不可修改的事实,放在这层讲,其实是贯穿整个数仓层的。在元数据和数据资源清单之间建立关联关系,且团队使用的数据项由元数据组合配置而来,这样,就建立了数据使用场景与数据源头之间的血缘关系。 做好需要和数据资产的整理,在后期修改和使用方面就能省很多时间。

3.DWS层

轻度汇总层:对一些比较常用的数据进行一步汇总,统一粒度,比如数量,金额等,为上层的数据应用提供基础数据。
这里大多是做过度用,承上启下。做好数据清洗,血缘追踪能提高这里的可用性。

  1. 这里的数据治理要按主要业务来规范数据,保证数据可用,做好承上启下。
  2. 对数据敏感,聚合出更有效的数据出来,为业务分析师和决策者提供可直接使用的数据,生成报表和图表,以支持业务决策。

4.ADS层

应用层:单在数据库数仓里,主要是按具体业务逻辑来做的一些贴近接口的数据处理。之前做的数据,转化成可用于业务决策和数据分析的可用数据。然后从中抽离出各种“接口”,提供给不同的数据使用方,最终实现数据价值。

  1. 这层做的基本不算是数据治理,主要是按产品需求来做对应的开发,逻辑缜密感觉算一个吧。保证自己的代码,算法不背锅,前面的数据处理没问题,有啥都可以甩给业务数据提供方。
  2. 还有一个数据权限问题,保证哪些用户对特定数据的访问权。做好数据脱敏,管理规范等。

小结

上面说的很多数据治理都是贯穿整个数仓的,哪一步没有做好,后面回头排查都得再捋一遍,很多时候的开发过程就是一次次试错,没法保证绝对的准确。所以重点还是细心吧,代码一定要逻辑缜密,注释该写就写的详细,第二天就忘的很常见。找资料时还看到一些“合规性管理”,“数据生命周期管理”,“人员治理意识提升”之类的,这些暂时没怎么接触到,感兴趣的可以按这些去搜搜看。

这篇关于数据治理学习笔记(二):在数仓建模过程中,数据治理要怎么做的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1131132

相关文章

SpringBoot分段处理List集合多线程批量插入数据方式

《SpringBoot分段处理List集合多线程批量插入数据方式》文章介绍如何处理大数据量List批量插入数据库的优化方案:通过拆分List并分配独立线程处理,结合Spring线程池与异步方法提升效率... 目录项目场景解决方案1.实体类2.Mapper3.spring容器注入线程池bejsan对象4.创建

PHP轻松处理千万行数据的方法详解

《PHP轻松处理千万行数据的方法详解》说到处理大数据集,PHP通常不是第一个想到的语言,但如果你曾经需要处理数百万行数据而不让服务器崩溃或内存耗尽,你就会知道PHP用对了工具有多强大,下面小编就... 目录问题的本质php 中的数据流处理:为什么必不可少生成器:内存高效的迭代方式流量控制:避免系统过载一次性

C#实现千万数据秒级导入的代码

《C#实现千万数据秒级导入的代码》在实际开发中excel导入很常见,现代社会中很容易遇到大数据处理业务,所以本文我就给大家分享一下千万数据秒级导入怎么实现,文中有详细的代码示例供大家参考,需要的朋友可... 目录前言一、数据存储二、处理逻辑优化前代码处理逻辑优化后的代码总结前言在实际开发中excel导入很

oracle 11g导入\导出(expdp impdp)之导入过程

《oracle11g导入导出(expdpimpdp)之导入过程》导出需使用SEC.DMP格式,无分号;建立expdir目录(E:/exp)并确保存在;导入在cmd下执行,需sys用户权限;若需修... 目录准备文件导入(impdp)1、建立directory2、导入语句 3、更改密码总结上一个环节,我们讲了

ShardingProxy读写分离之原理、配置与实践过程

《ShardingProxy读写分离之原理、配置与实践过程》ShardingProxy是ApacheShardingSphere的数据库中间件,通过三层架构实现读写分离,解决高并发场景下数据库性能瓶... 目录一、ShardingProxy技术定位与读写分离核心价值1.1 技术定位1.2 读写分离核心价值二

MyBatis-plus处理存储json数据过程

《MyBatis-plus处理存储json数据过程》文章介绍MyBatis-Plus3.4.21处理对象与集合的差异:对象可用内置Handler配合autoResultMap,集合需自定义处理器继承F... 目录1、如果是对象2、如果需要转换的是List集合总结对象和集合分两种情况处理,目前我用的MP的版本

GSON框架下将百度天气JSON数据转JavaBean

《GSON框架下将百度天气JSON数据转JavaBean》这篇文章主要为大家详细介绍了如何在GSON框架下实现将百度天气JSON数据转JavaBean,文中的示例代码讲解详细,感兴趣的小伙伴可以了解下... 目录前言一、百度天气jsON1、请求参数2、返回参数3、属性映射二、GSON属性映射实战1、类对象映

Java Kafka消费者实现过程

《JavaKafka消费者实现过程》Kafka消费者通过KafkaConsumer类实现,核心机制包括偏移量管理、消费者组协调、批量拉取消息及多线程处理,手动提交offset确保数据可靠性,自动提交... 目录基础KafkaConsumer类分析关键代码与核心算法2.1 订阅与分区分配2.2 拉取消息2.3

C# LiteDB处理时间序列数据的高性能解决方案

《C#LiteDB处理时间序列数据的高性能解决方案》LiteDB作为.NET生态下的轻量级嵌入式NoSQL数据库,一直是时间序列处理的优选方案,本文将为大家大家简单介绍一下LiteDB处理时间序列数... 目录为什么选择LiteDB处理时间序列数据第一章:LiteDB时间序列数据模型设计1.1 核心设计原则

Java+AI驱动实现PDF文件数据提取与解析

《Java+AI驱动实现PDF文件数据提取与解析》本文将和大家分享一套基于AI的体检报告智能评估方案,详细介绍从PDF上传、内容提取到AI分析、数据存储的全流程自动化实现方法,感兴趣的可以了解下... 目录一、核心流程:从上传到评估的完整链路二、第一步:解析 PDF,提取体检报告内容1. 引入依赖2. 封装