数据仓库数据质量管理【转】 - CSDN博客

标签: | 发表时间:2018-07-08 19:46 | 作者:
出处:https://blog.csdn.net

 一个完善的数据仓库必须含有一个完整的 数据质量管理系统元数据管理系统,但是目前国内的数据仓库对数据质量管理这块都不是那么重视,我个人觉得这是一个很大的误区,一个数据仓库如果连数据质量都无法保证,还如何基于做出有效的分析来给决策者做决策的依据?
       从个人理解的角度看,数据质量管理系统应该包含 数据质量检测、脏数据的处理与修正这两块。对于数据质量检测这块,又分为 物理数据监控与逻辑数据监控。我个人理解的物理数据监控是指纯粹从技术上保证数据的有效性,与业务无关,而逻辑数据监控则是从业务逻辑上,对原始指标以及最终产出的业务指标之间的逻辑平衡性监控。通过这些监控,能让底层ETL技术人员第一时间发现数据问题并且解决问题,同时也能根据这些监控提前知道可能产生的结果,为后续产生的业务分析报告作出进一步的修正,从而保证数据仓库的数据的是有效的是能真正反应事实的。 对于脏数据的处理与修正这块则是与流程机制有关系,比如产生了某种类型的脏数据第一时间应该如何处理,是reject还是保存起来发给相应的业务人员来手工check然后再回写到数据仓库。
       在数据质量检测这块,对于 物理数据监测,通过包含有如下所述的几个方面。其一,数据格式的合法性。比如日期型数据在原系统是字符类型的,进入dw后就需要做日期格式的验证,验证是否是有效的日期格式;其二,数据值域的有效性。比如一些维度代码是否有出现维表以外的代码值;其三,空值或者空格的合理性。比如一些重要的不可为空的字段对应映射的源数据字段是否有空值或者空格;其四,主键的有效性。比如对源表业务上已经明确了是主键的字段是否真的唯一;其五,乱码检测。比如数据中是否含有乱码;其六,对于reject的记录的统计。比如是否有超长的数据、是否有不合乎格式的数据出现等;其七,记录数的平衡。比如从源系统抽取了n条记录,最终入库的是否也是n条,进入dw之后是否也是n条;
       对于逻辑数据的监控则与业务含义直接挂钩了,主要体现在 不同表按照不同的力度描述了相同的指标最终这些指标之间的均衡性的检测,比如网站中的session表含有每个session对应的pv,而path表则含有所有session在每一步的明细,那么逻辑上session表的pv的总和就应该与path表的总记录数是相等的,这就是一种业务指标上的均衡
       上述说了那么多,其实还有许多可以补充的地方,目前我只想到这些,后续再继续增加,总之,一个完备的数据质量管理系统是数据仓库必不可少的部分, 只有数据质量管理系统做好了,才能提高数据仓库数据的可用性,同时也提高数据仓库的数据产生的价值.

有些问题还请指点一二:
关于“记录数的平衡”,如果做了去重,关联,过滤这些操作,怎么保证进入仓库的记录数是否正确?

记录数的平衡,我们在项目中是这样做的,对于因为质量问题被丢弃的记录,在后台设置专门的的文件或者数据库表进行存放,在前台提供检索界面, 如果是来源业务系统的问题,反馈,促使来源业务系统进行修正,我们还据此发现业务系统的业务处理逻辑上有小BUG。 其实后线分析系统与业务系统应该是一个双向交互的关系,不仅仅反映在数据质量上,在信息上也是,这样的分析系统才是强大的。

 

源地址: http://bbs.dwway.com/thread-29340-1-1.html

相关 [数据仓库 数据 质量管理] 推荐:

数据仓库数据质量管理【转】 - CSDN博客

- -
 一个完善的数据仓库必须含有一个完整的. 元数据管理系统,但是目前国内的数据仓库对数据质量管理这块都不是那么重视,我个人觉得这是一个很大的误区,一个数据仓库如果连数据质量都无法保证,还如何基于做出有效的分析来给决策者做决策的依据.        从个人理解的角度看,数据质量管理系统应该包含. 数据质量检测、脏数据的处理与修正这两块.

数据仓库系列之数据质量管理 - 黄昏前黎明后 - 博客园

- -
数据质量一直是数据仓库领域一个比较令人头疼的问题,因为数据仓库上层对接很多业务系统,业务系统的脏数据,业务系统变更,都会直接影响数据仓库的数据质量. 因此数据仓库的数据质量建设是一些公司的重点工作.   数据质量的高低代表了该数据满足数据消费者期望的程度,这种程度基于他们对数据的使用预期. 数据质量必须是可测量的,把测量的结果转化为可以理解的和可重复的数字,使我们能够在不同对象之间和跨越不同时间进行比较.

数据仓库

- Ran - Linux@SOHU
翻译:马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高,以及服务器价格的降低,让人们能够负担起大量的服务器,但是商业软件应用和监控工具快速的增加,还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者,以及初级数据库管理员发现,他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语,概念或工具.

数据仓库概念

- - 互联网 - ITeye博客
数据仓库:是一个数据库环境,它提供用户用于决策支持的当前和历史数据,这些数据在传统的数据库中不方便得到. 特点:面向主题,集成的,相对稳定的,反应历史变化的. 组成:数据仓库的数据库,数据抽取工具,元数据,访问工具,数据集市,数据仓库管理,信息发布系统. 数据挖掘:就是从大量数据中获取有效的,新颖的,潜在有用的,最终可理解的模式的过程.

大数据仓库-kudu

- - 数据库 - ITeye博客
数据仓库里面存储引擎是非常重要的,存储引擎的好坏,基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法,kudu的出现是为了解决,hbase,parquet不能兼顾分析和更新的需求,所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.

[原]数据仓库元数据管理

- - oycn2010的专栏
元数据管理, 简单的做就是EXCEL结合版本管理等传统工具管理, 专业点就用专门的元数据管理工具;. 数据字典--> 数据知识库. 业务元数据,技术元数据,管理元数据. 参照:SAP元数据管理平台:按业务(角色)分类,按技术类型分类(特征,关键值,DSO,InfoCube),数据流程图. 按照传统的定义,元数据(Metadata)是关于数据的数据.

数据仓库的设计与开发

- - 数据库 - ITeye博客
     数据仓库系统的设计与开发. 1)       收集和分析业务需求.   用户需求,管理人员需求. 2)       建立数据模型和数据仓库的物理设计.   概念模型,逻辑模型,物理模型. 3)       定义数据源. 数据源面向应用,不是面向主题,而且数据源之间存在多个不一致的情况,所以必须在已有的系统中定义记录系统(内容正确,在多个数据源间起决定作用的操作型数据源).

oracle数据仓库设计指南

- - 数据库 - ITeye博客
ODS(Operational Data Store)是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据.     一般在带有ODS的系统体系结构中,ODS都设计为如下几个作用:. 1 )    在业务系统和数据仓库之间形成一个隔离层.

[原]数据仓库构建步骤

- - oycn2010的专栏
 即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况). 主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑..  确定主题后,需要考虑分析的技术指标(例:年销售额等等). 它们一般为数据值型数据,其中有些度量值不可以汇总;些可以汇总起来,以便为分析者提供有用的信息.

数据仓库事实表分类

- - 行业应用 - ITeye博客
1)在数据仓库领域有一个概念叫Transaction fact table,中文一般翻译为“事务事实表”. 事务事实表是维度建模的数据仓库中三种基本类型事实表中的一种,另外两种分别是周期快照事实表和累积快照事实表. 事务事实表与周期快照事实表、累积快照事实表使用相同的一致性维度,但是它们在描述业务事实方面是有着非常大的差异的.