您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
业务架构设计
4月18-19日 在线直播
基于UML和EA进行系统分析设计
4月25-26日 北京+在线
AI 智能化软件测试方法与实践
5月23-24日 上海+在线
     
   
 
 订阅
数据治理之数据目录:摸清家底,建立三大数据目录
 
作者:数据小吏
  258  次浏览      100 次
 2025-4-3
 
编辑推荐:
本文主要介绍了数据目录的分类,每种目录的用户、目的等相关内容。希望对你的学习有帮助。
本文来自于微信公众号数据小吏,由Linda编辑、推荐。

说到本章要介绍的数据目录,名字可以说五花八门“企业数据目录”、“元数据目录”、“数据资产目录”、“数据开放目录”、“数据资源目录”。各种目录,常常让人搞不清楚,每种目录都指代的什么?有什么区别?为什么会有这么多的数据目录?

(这也体现了一直说的那句话“数据领域是一个实践的学科”,并不追求各种概念的统一,各种名词、概念解释很多。只要在个人实践中能够适用即可。)

本章我们就梳理一下数据目录的分类,每种目录的用户、目的。通过建立数据目录,来摸清自己的数据家底。

1、数据目录,到底可以分为几类

个人理解数据目录,也可以称之为数据地图,两者其实是指一类的内容,就是展示有哪些表、字段信息的地方。让数据加工者,能够更加快速、便捷、没有重复的加工数据;能够让数据消费者快速的找到、了解,更好的消费使用数据。(数据加工者、数据消费者在【数据治理的边界在哪里】中提到的数据的三个参与方中有介绍。)

先说结论,在所有的数据目录分类方法中,目前个人倾向于分为三个目录:

数据资源目录

数据资产目录

数据开放目录

其中第三个,数据开放目录,也可以叫数据资产开放目录,这里简称数据开放目录,是在数据资产目录的基础上进一步进行开放说明。有时候,两者的区分不是特别明确,可能是一个目录,甚至大部分时候都会是同一个目录。这里为了做具体的定位区分,所有我们分两个目录介绍。

可以看到这三个目录,主要就是围绕着“数据资源”和“数据资产”的,这也是先在随想篇2中对相应概念做下介绍的目的。理解了数据资源、数据资产的概念能够更好的理解数据资源目录、数据资产目录及数据(资产)开放目录。

对于其他名字的数据目录,个人理解可以进行统一,如“元数据目录”、“技术数据目录”,均指“数据资源目录”。“企业数据目录”、“业务数据目录”均是指“数据资产目录”或者“数据开发目录”。

2、数据资源目录

数据资源目录,主要就是业务系统的元数据信息。目标是让数据加工者,更加快速、便捷、统一的了解企业的各个业务系统的元数据信息。这些业务系统的元数据,包括已经入湖的,也包括未入湖的。总之,是一个各个业务系统的数据资源全景。

在数据源模块【数据源的数据接入、业务属性梳理及监控】中,我们已经对公司所有业务系统的数据源进行了统一的梳理、统一的管理。而且,在数据源篇中也提到,良好的数据源信息梳理,能够为数据资源目录打下一个好基础。

原因就在于,数据源模块中对公司所有业务系统的数据源都进行了管理,形成了一个数据源的全景,那么通过这些数据源信息,就能够获取到所有业务系统的元数据信息,也就很容易将所有业务系统的数据资源获取到,形成所有业务系统的数据资源全景,进而将数据资源目录的主体给构建出来。(这里不考虑网络不联通情况,假设所有的网络都是和数据中台能够连通。)

这是一个很顺畅的过程,但是在从“数据源”到构建“数据资源目录”的过程中有两点需要特别关注一下:

第一:“两层皮”的问题

不管是在本节的“数据资源目录”还是下一节的“数据资产目录”,其实都会有这个问题,有的也俗称“两层皮“问题。也就是在获取元数据的时候,这个元数据的产生和管理是脱节的,我们只能在元数据已经产生,也就是已经在业务系统数据库中创建完、修改完之后,再进行获取,这个获取就一定是滞后的。那么,这个滞后性,就会造成,在元数据产生时,即业务系统中的元数据信息,同在元数据管理的位置,即数据资源目录中的元数据信息,这两个位置的元数据可能不一致,这就像是有两层皮的感觉了。

这个问题,是当前架构下的必然会出现的问题。我们能做的就是尽量去减少这种不一致,像在【数据源篇】介绍过的一样,使用“主动监控”、“被动监控“方式来尽量保证两者的数据是一致的。

这种二层皮问题,也受更新频率的影响。如果是周期性的更新,设置一个定时的调度,多长时间进行一次最新数据的更新。比如说5分钟、半小时、或者半天更新一次。那么,在这个更新频率周期内,可能就会出现不一致的情况。如果是监听数据库的变更日志信息,当监听到变化日志时,就进行实时更新,这种更新的时效性更高,相应的技术要求也会高。

在这个领域还有一个CWM规范,(也是第一次听说),许多工具都号称支持CWM规范,但很难做到。这个规范有兴趣的可以大模型一下,了解下细节,这里就不多说了。

第二个:入湖标志的标识

数据源中管理了所有业务的数据库信息,理论上也是能够将所有业务系统的所有表信息都获取到数据资源目录中。但是这个数量可想而知一定是巨大的。那么这个数据资源目录怎么做到不冗余那?其中一个重要的区分点,就是是否已经入湖。即我们只将已经入湖的业务库表作为我们数据资源目录的内容。

当然,我们也可以识别出来一些内容,标识出来,这些是潜在有价值的,但是未入湖的,这些潜在有价值的就是【数据治理作用的数据分类是什么】中提到的主数据、参考数据、事务数据的数据表。这就涉及到一个数据资源价值判断的问题了。

这里也多说一句数据入湖,在【数据源】篇中,结尾我们也提到,一个好的数据源能够帮助进行业务的自主入湖。其实也体现在这里,有了统一的数据源,知道有些表有潜在价值,那么把这些有潜在价值的表,让业务人员去进行简单配置,即可完成数据入湖,其实是一个很方便自然的过程。这种入湖形式是以业务系统为视角,而传统的数据入湖更多的是以数据加工视角或者工具视角。当然,这种自主入湖也是很需要工具支持的,各种增量形式,调度设置,下游触发,都是工具需要具备的能力。

我们再进一步说,这种数据源管理--业务自主入湖--数据资源目录,甚至能够为后续的数据血缘链路补上到业务端血缘信息打下基础,打造真正端到端的全链路血缘,从业务中来到业务中去。

以上,就是对于数据资源目录的一些想法,就像上一篇随想篇介绍的,现在这些数据资源还仍旧处于成本阶段,是未加工的,业务原生的数据,需要经过“炼金术”将“数据资源“转化为”数据资产“。

3、数据资产目录

从“数据资源”转化为“数据资产”产生最本质变化的原因是随想篇 294664 提到的”第一步:数据加工,从无序到规范“。这些加工好的表,在特定的场景下有价值,那么这些加工好表就可以被称之为数据资产。而将这些加工好的表的元数据进行收集,就形成了数据资产目录。

有时,可能有“加工好的表也不一定有价值,那还能称之为资产吗?”这样的疑问。这里个人的想法是:如果是数据中台加工出来的表,一定会在特定场景下有价值。如果没有价值,则不会被加工出来。

除了部分中间表,所有被加工出来的表都应该是有价值的,可能是当前马上就有价值,也可以能预期会有价值。(这个又涉及到建模的一个过程,是先有需求再建模,还是按照预期的业务逻辑进行完整建模,能够预期产生价值。)

当然,当前有价值也并不意味着会长久的一直有价值,所以会有一个生命周期管理,这个又是后话了。

这个数据加工的过程,在表层面也是一个数据建模的过程。现在通用的建模横向划分基本上都是“ODS-DWD-DWS-ADS”这样的几层架构。

ODS是贴源层,是业务系统数据的同构同步,不过有的会进行轻度清洗,将明显错误的修正,有的就完全拷贝,即使有错误也添加进来。 DWD是基础模型层,是单个业务域内规范化后的内数据。 DWS是融合模型层,是跨业务域整合后的数据。 ADS是面向应用层,可以是通过建模获取的一些知识,如标签。可以是面向应用场景的数据。

这几层只是简单说下,详细的各层信息,这了不过多介绍。

数据资源目录主要是业务系统的数据表信息,是为数据加工者使用的。数据资产目录展示的已经加工好的表信息,主要是为数据加工者使用还是数据消费者使用?

如果说,数据资产目录主要给数据加工者使用多少有点说不过去,都已经是资产了,应该更多的为数据消费者使用了才是。但是,如果数据资产目录,主要给数据消费者使用了,数据开放目录谁使用?

在上节也提到“数据资产目录和数据开放目录,两者的区分不是特别明确,可能是一个目录,甚至大部分时候都会是同一个目录”。所以,最终我们可以再细化一步的理解为,在展示形态和使用流程上更加偏向开发,称为数据资产目录,主要数据加工者使用。在展示形态和使用流程上更加偏向运营,称为数据开放平台,主要数据消费者使用。如果,在展示形态和使用流程,没有特殊的区别,那么这两个目录,就可以是一个目录。大部分时候只有一个目录的话,那也谈不上区分了,就是数据加工者和数据消费者共同使用了。

4、数据开放目录

数据开放目录,全称可以叫做数据资产开放目录,我们就简称数据开放目录。这个目录是数据中台的价值集中体现的一个地方。

还是像上节中提到的,如果,在展示形态和使用流程,没有特殊的区别,那么数据开放目录和数据资产目录,就可以是一个目录。但是个人倾向于有一个单独的数据开放目录,或者说能够在已经加工好的数据资产之上,有另一种展示形态的说明。

一方面是因为,单独的面向数据消费者的数据开放目录,是可以作为数据运营平台的一个重要组成部分。

数据运营平台是希望将数据中台加工好的数据资产、数据服务API、甚至于一些BI报表,都作为可以通用的可运营的内容项。这样就可以集中的进行数据中台产出体现。这样一个能够很好说明数据中台产出的平台,对数据中台团队还是比较重要的。

另一方面,在面向数据加工者和面向数据消费者的时候,对于数据资产的展示形态和使用流程还是多少有些区别的。面向数据加工者时,可以使用树状结构,当时面向数据消费者时,需要更加友好的卡片形式。

而且,在进行数据授权时,数据加工者和数据消费者的授权形式是否相同,授权范围是否一致。这些都决定了这两个目录是否可以何为一个的前提。

不管是一个还是两个目录,有一点是重要的就是作为数据开放目录功能时,是需要尽可能让数据流程起来的,数据流通起来还要保证数据安全,就需要针对不同的数据识别出来不同的数据敏感程度,做到:快捷开放、可控开放、严控开放,不同的开放级别。不同的敏感程度,就需要有不同的审批节点流程。

上面说的这三个目录,到底怎么建设,是建设两个目录,还是比较彻底的建设三个目录,是需要根据不同的情况进行实际分析的。会和当前目标、团队已有产品、组织构成、团队意向等等都有分不开的关系。这里介绍了概念定位,具体怎么和实际结合,就看各自理解了。

5、目录的其他信息构成

上面在进行目录构建的时候,更多的提到的是从系统重获取元数据信息。不管是从业务系统数据库,获取的元数据,还是从数据仓库中获取的元数据,这些可以自动获取到的信息,可以称之为技术信息。

除了技术信息外,在数据目录构成时,还需要业务信息和管理信息。具体业务信息和管理信息,都有哪些,这里不过多列举,在不同的实践中会有不同。

5、数据的申请与使用

数据目录的制定最终的目标还是希望数据加工者或者数据消费者,能够找到数据后,进行权限的申请。

在数据权限的申请时,在【数据权限是个大问题】和【数据运营中的权限问题】有部分说明,可以参考一下,这里也不过多做赘述。

6、数据目录的更新

数据目录的创建是一回事,数据目录的长期更新是另一回事了。

数据目录的更新,需要有更新的负责人,更新的流程,更新的工具支持等等。整个过程是一个长期的工作。

但是,只有不断更新的数据目录,才是有生命力的数据目录。才会能够真正用的起来的目录。

7、五大维度说明

组织:

在组织上需要重点关注的是,需要有专人来负责三个数据目录。虽然可以通过定时设置进行周期性更新,或者监控数据库日志进行实时更新。但是,更新的内容也仅仅是偏技术的数据表、字段信息。对于其他的信息还是需要有人来负责的。不管是负责填写,还是负责监督。

这个负责人,在组织层级上是第三层:执行层,的数据管家(也叫数据BP)。因为不管是数据资源目录还是数据资产目录,都已经进行了领域划分了。不同的领域的数据管家,就负责对应领域的数据目录。

政策:

在政策上需要重点关注的就是,在规范层面制定三大目录的要求。让公司内部达成,通过三大目录,就能够理清数据家底的共识,为了这个共识而努力。

其次,就是在不同数据目录的基础上,制定对应的流通策略:明确不同数据目录的流通形式,审批人等。

制定不同目录的安全等级策略,这个和后续的数据安全模块是一致的,到数据安全会再说明。

工具:

在工具上,数据资源目录需要能够和数据源模块中的工具进行很好的结合,甚至还会在此基础上增加业务自主入湖的能力。

在数据资产目录上,能够满足将加工好的数据进行更加灵活的展示,如果是面向数据加工者,能够树状展示,如果是数据消费者,能够卡片展示。

在数据开放目录上,能够有一个数据运营平台,将所有对外开放的内容,统一为数据消费者进行展示。

业务:在业务上在数据目录进行标签划分的时候,需要能够合理的进行标签划分,这是一个数据目录能不能快速找到需要的数据的一个重点,决定了数据目录好不好用。

数据:在数据目录阶段,仍然不涉及到具体的数据细节的了解。如果说有一点和数据相关的话,那么在数据目录信息中添加一些数据分布的描述,增加对于数据目录的了解。

8、总结

在数据治理十大模块中没有元数据这个模块,多多少少在数据目录部分替代了。通过三个目录的建立,基本上能够理清楚一个公司现在的数据家底了。

现在数据作为一种生产要素,越来越受到重视,数据入表的呼声也越来越高,这时候能够清除的知道自己的数据家底就显的尤为重要了。

不管想干什么,知道手里有什么是第一步。希望能够通过这个数据家底,迈出数据治理坚实的一步。

   
258 次浏览       100
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训

最新活动计划
DeepSeek软件测试应用实践 4-12[在线]
DeepSeek大模型开发实践 4-19[在线]
UAF架构体系与实践 4-11[北京]
AI智能化软件测试方法与实践 5-23[上海]
基于 UML 和EA进行分析设计 4-26[北京]
业务架构设计与建模 4-18[北京]
 
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...