数据中台之数据研发规范

首页 > 快讯 > > 正文

日期:2021-04-13 21:44:00    来源:财讯网    

背景及目的

为数据开发人员提供规范性指导。

范围

本规范主要用于数据中台建设的数据研发与维护,所有参与数据中台建设的数据资产组成员都需要熟悉规范约定,并落实到位。应用层建设的开发团队,建议也参照本规范执行。

数据处理流程

离线数据处理流程

图(二)-1 离线数据处理流程

如图(二)-1所示,离线数据公共层模型层次分为4个层次,其中DWD、DWS属于中间层(CDM)。

项目管理

工作空间目录结构

(1)数据集成目录规范

按业务系统进行划分再加项目公共目录。目录命名采用业务系统英文简称。每个目录分为周期任务和手动任务两部分。

注:不允许把任务创建在根节点

(2)数据研发目录规范

研发目录

划分为:ODS,CDM,ADS,PUB(公共目录),个人任务等。

基础层(ODS)层项目目录规范

ODS层目录,又划分为DDL(建表语句), DATA_TRSF(数据加工逻辑),DATA_INIT(数据初始化)三个目录。每个目录按业务系统进行划分再加项目公共目录(PUB),目录命名采用业务系统英文简称。

中间层(CDM)项目目录规范

按照DWD(数据仓库明细层)、DWS(数据仓库汇总层)、DIM(数据仓库维表数据)进行划分。每个目录再划分为DDL(建表语句), DATA_TRSF(数据加工逻辑),DATA_INIT(数据初始化)三个目录。其中DWD和DWS按照数据域划分子目录,一个数据域一个子目录,如下:

应用层(ADS)项目目录规范

ADS目录划分为DDL(建表语句), DATA_TRSF(数据加工逻辑)。子目录按业务线进行划分再加项目公共目录,目录命名采用业务线英文简称。

项目公共目录

包含工具目录,虚拟任务等公共目录等

个人目录

所有个人查询均放到个人目录

工作流节点类型及命名

表(三)-1 工作流节点类型及说明

关于工作流起始节点

每个工作空间必须设立一个起始节点,命名为vt_{project_name}_start,表示该工作空间的任务起点。并且每个数据源的数据同步也必须设立一个起始节点,命名为vt_ods_{业务系统英文简称}_start

资源文件

项目中公用的资源文件建议放在RESOURCE目录中,资源名称需有后缀表示资源类型,如.jar、.py、.sh等。如果某个资源文件如java只是服务于某个表,请把这个资源文件放在表级目录下。

表与视图

表与视图规范

(1)基础层命名规范

增量数据表:ods_{业务系统英文简称}_{源表名}_di

全量数据表:ods_{业务系统英文简称}_{源表名}_df

小时/分钟增量表:ods_{业务系统英文简称}_{源表名}_hh/mm

实时表:ods_{业务系统英文简称}_{源表名}_rt

按15分钟表:ods_{源系统名}_{源系统表名}_{di}_15min

按30分钟表:ods_{源系统名}_{源系统表名}_{di}_30min

当不同源系统同步到同一个Project下的表命名冲突时,需要给同步较晚的表名加上源系统的schema以解决冲突。

如:ods_{源系统名}_{源schema名}_{源表名}_{自定义表命名标签缩写}_di/df

字段默认使用源系统的字段名。

字段名与系统关键字冲突时,在源字段名后加上col,即源字段名col。

(2)中间层规范

DIM规范

表:dim_{维度定义}_{自定义维度表名缩写}

例如:dim_goods_basic

字段命名规范:维度主键推荐使用:{维度简写}_id

一致性维度规范:公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致。

维度设计规范

将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如,商品基本属性和所属品牌。

行为维度是经过汇总计算的指标,在下游的应用使用时将其当维度处理。如果有需要,度量指标可以作为行为维度冗余到维度表中。

对于维度属性过多,涉及源较多的维度表(例如会员表),可以做适当拆分

1)拆分为核心表和扩展表。核心表相对字段较少,刷新产出时间较早,优先使用。扩展表字段较多,且可以冗余核心表部分字段,刷新产出时间较晚,适合数据分析人员使用。

2)根据维度属性的业务不相关性,将相关度不大的维度属性拆分为多个物理表存储。

数据记录数较大的维度表(例如商品表),可以适当冗余一些子集合,以减少下游扫描数据量

1)可以根据当天是否有行为,产出一个有活跃行为的相关维表,以减少应用的数据扫描量。

2)可根据所属业务扫描数据范围大小的不同,进行适当子集合冗余。

DWD命名规范

dwd_{数据域缩写}_{业务过程缩写}[_{自定义表命名缩写}]_{单分区增量全量标识}

全量数据:dwd_{数据域缩写}_{业务过程缩写}_{自定义表命名缩写}_df

增量数据:dwd_{数据域缩写}_{业务过程缩写}_{自定义表命名缩写}_di

小时全量:dwd_{数据域缩写}_{业务过程缩写}_{自定义表命名缩写}_df_hh

小时增量:dwd_{数据域缩写}_{业务过程缩写}_{自定义表命名缩写}_di_hh

字段命名规范:业务过程主键推荐使用:{业务过程简写}_id

例如:dwd_trd_ord_evt_di(XXX订单事务型事实表,日刷新增量)。

DWS命名规范:

dws_{核心数据域缩写}_{数据粒度缩写}_[{自定义表命名缩写}]_{统计时间周期范围缩写} _[刷新周期标识]。

全量数据:dws_{核心数据域缩写}_{数据粒度缩写}_{统计时间周期范围缩写}

增量数据:dws_{核心数据域缩写}_{数据粒度缩写}_{统计时间周期范围缩写}

关于统计实际周期范围缩写,缺省情况下,离线计算应该包括最近一天(_1d),最近N天(_nd)和历史截至当天(_td)三个表,如果出现_nd的表字段过多,需要拆分之时,只允许以一个统计周期单元作为原子拆分,也就是说一个统计周期拆分一个表,比如最近1周(_1w)拆分一个表;不允许拆分出来的一个表存储多个统计周期的。例如:

dws_trd_ord_shop_1d(XXX门店粒度交易一日汇总事实表)

dws_trd_ord_member_shop_7d(XXX门店XXX会员粒度交易七日汇总事实表)

dws_trd_ord_member_shop_30d(XXX门店XXX会员粒度交易30天汇总事实表)

dws_trd_ord_member_shop_city_province_180d(XXX省XXX市XXX门店XXX会员粒度交易180天汇总事实表)

注意:

1)dws表的数据域缩写以当前分析的核心数据域为主。如dws_trd_ord_shop_1d表中既有交易域的数据,也有门店域的数据,但是以交易数据为主要的分析方向,所以核心数据域缩写为trd。

2)对于统计维度,要全部都添加,添加顺序为同一类型的按从小到大的顺序填写,不同类型的按首字母顺序填写,如首字母相同,则按次字母顺序来进行添加,以此类推。

常用的时间周期修饰词列表如下:

表(四)-1 修饰词列表

(3)应用层(ADS)规范

1)表命名规范

ads_{业务线/pub}_{应用名称}[_数据粒度] [_{自定义表命名标签缩写}]_刷新周期标识。

例如:ads_sale_dashboard_shop_day(门店粒度销售看板日表)

2)视图命名规范

ads_{应用名称/pub}_{应用类型}_[数据粒度]_[{自定义视图命名标签缩写}]_v。

例如:ads_sale_dashboard_shop_day_v(门店粒度销售看板日表视图)

3)字段命名规范

ADS表指标字段统一使用派生指标名称,维度相关字段继承维表字段命名,当命名都不存在的时候或者业务上存在歧义的时候,按需求统一定义命名

表创建

创建表之前必须按照数据模型规范确定表和字段的命名。

以下是建表语句的样例:

注意:

使用Hive建表时,有TEXTFILE、SEQUENCEFILE、RCFILE、ORC等文件存储格式,实际使用中可根据需要自己选择,默认为TEXTFILE格式,目前统一采用ORC格式。

关于视图

视图的命名为{表名}_v。

视图应创建独立的刷新任务以产生视图,刷新任务脚本为视图创建脚本。

编码

编写原则

要求代码行清晰、整齐,具有一定的可观赏性;

代码编写要充分考虑执行速度最优的原则;

代码行整体层次分明、结构化强;

代码中应有必要的注释以增强代码的可读性;

代码要做到整个节点可以多次重跑,结果不变;

规范要求非强制性约束代码开发人员的代码编写行为,在实际应用中在不违反常规要求的前提下允许存在可理解的偏差;

本规范在对日常的代码开发工作起到指导作用的同时也将得到不断的完善和补充;

基本要求

代码段中应用到的所有SQL关键字、保留字都使用大写/小写,如 select、from、where、and、or、union、insert、delete、group、having、count等;不能使用大小写混合的方式,如Select或seLECT等方式;

代码段中应用到的除关键字、保留字之外,都使用大写/小写

四个空格为一个缩进量,所有的缩进皆为一个缩进量的整数倍;

最外层禁止使用select *操作,所有操作必须明确指定列名;

对应的括号通常要求在同一列的位置上。

注意:

整个项目中的所有代码大小写保持一致,建议使用小写。

数据类型

(1)基本要求

对于下表中的数据类型,一般情况下,使用以下四种:

Bigint

String

Decimal

Datetime

Double

表(五)-1 数据类型基本要求

Hive数据类型详细参考:https://cwiki.apache.org/confluence/display/Hive/Tutorial

注意:

对于精确度要求高的数值类型分为两种情况:

(1)金额类字段,使用decimal(20,4)类型;(2)非金额类字段,根据实际情况确认。

(2)货币单位及精度

中间层的货币单位,中国货币单位统一为人民币元,国际货币单位统一为美元。

除非模型有特殊说明,否则中间层金额相关的数据不做任何四舍五入操作,以免出现在后续的汇总计算中造成不同口径的汇总结果不一致的情况。

编码规范

(1)代码头部

代码头部添加主题、功能描述、作者、日期等信息,并预留修改日志及标题栏,以便后续修改同学添加修改记录。注意每一行不超过80个字符。

(2)字段排列要求

SELECT语句选择的字段按每行一个字段方式编排;

SELECT单字后面一个缩进量后直接跟首个选择的字段,即字段离首起二个缩进量

其它字段前导二个缩进量再跟一‘,’点后放置字段名;

两个字段之间的‘,’点分割符紧跟在第二个字段的前面

‘AS’语句应与相应的字段在同一行;多个字段的‘AS’建议尽量对齐在同一列上。

(3)SELECT子句排列要求

SELECT 语句中所用到的FROM、WHERE、GROUP BY、HAVING、ORDER BY、JOIN、UNION等子句,需要遵循如下要求:

换行编写;

与相应的SELECT语句左对齐编排;

子句后续的代码离子句首字母二个缩进量起编写;

WHERE 子句下的逻辑判断符AND、OR等与WHERE左对齐编排;

超过两个缩进量长度的子句加一空格后编写后续代码,如:ORDER BY、GROUP BY等。

(4)运算符前后间隔要求

算术运算符、逻辑运算符(!=,<=,>=,<>,=,<,>)的前后要保留一个空格。

(5) CASE语句的编写

SELECT 语句中对字段值进行判断取值的操作将用到的CASE语句,正确的编排CASE语句的写法对加强代码行的可阅读性也是很关键的一部分。

对CASE语句编排作如下约定:

WHEN子语在CASE语句的同一行并缩进一个缩进量后开始编写;

每个WHEN子句一行编写,当然如果语句较长可换行编排;

CASE语句必须包含ELSE子语,ELSE子句与WHEN子句对齐。

(6)子查询嵌套编写规范

代码若存在多层子查询,每层子查询前后括号换行;子查询代码前后括号、查询关键字段标准对齐,层次分明,括号必须上下对齐一旦在SELECT语句中给操作表定义了别名,在整个语句中对此表的引用都必须以别名替代,所以需要给所有的表添加别名。

表别名采用简单字符命名,建议按a、b、c、d…的顺序进行命名,并避免使用关键字。

多层次的嵌套子查询别名之前要体现层次关系,SQL语句的别名需要分层命名,从第1层次至第4层次,分别用P(Part) 、S(Segment)、 U(Unit) 和D(Detail)表示。也可以用a、b、c、d来表示第1层次到第4层次。对于同一层次的多个子句,在字母后加1、2、3、4……区分,并根据情况对表别名添加注释。

(7)SQL注释

每条SQL语句均应添加注释说明;

每条SQL语句的注释单独成行、放在语句前面;

字段注释紧跟在字段后面;

应对不易理解的分支条件表达式加注释;

对重要的计算应说明其功能;

过长的函数实现,应将其语句按实现的功能分段加以概括性说明;

常量及变量注释时,应注释被保存值的含义(必须),合法取值的范围(可选);

SQL语句中出现where、case when等条件判断,必须进行注释说明条件判断逻辑;

(8)开发规范

初始化订单销售、支付类流、日志流水表,取ods所有分区,按照业务创建时间拆分,清洗标准化后动态分区写入 dwd目标表,根据业务需要将分区数据刷到相应分区中,暂定3年,将3年前(20180101日前)的历史数据写入‘00000000’ 分区,未来时间即大于当前时间,如2035年,这部分数据写入‘99999999’ 分区,其余3年(20180101)内按业务时间动态写入分区;

增量订单销售、支付类流水表,取ods增量分区(t-1)与历史分区合并,去重取最新的标准化之后记录,按照业务创建时间分区,动态写入到目标dwd表;

增量日志类流水表,每天对ods增量分区(t-1)进行清洗标准化后写入dwd目标表(t-1)分区;

dwd表生命周期,ODS每天有全量分区的表,dwd周期为7,其余表周期为永久

ODS每天有全量分区的表,取ods(t-1)全量分区进行清洗标准化之后写入dwd(t-1)分区;

cdm层表增加字段etl_loadtime(清洗加载时间)字段、取值为用hive的函数CURRENT_TIMESTAMP();

所有编码为小写,同时有注释的字段要带上注释在脚本中;

对于表中的编码字段需要增加编码的翻译字段,如性别 sex (1 、2 ),需要增加sex_desc字段描述( 男、女),视情况看是否统一增加相应的码表,通过关联进行转换;

对于字符串的信息字段,需要做特殊字符转换,如全角转半角、换行、空格等,除业务数据本身为全角的则不转;

对于度量类的指标,如金额、销售量等,如果有空值则补 0 ;维度属性值为空,填充-99(未知),在对应维表有一条-99(未知)的记录;

按照dwd设计文档进行开发,碰到问题,如果是设计问题找设计当事人,如果是业务数据问题,则记录问题列表;

所有开发的任务节点必须是原子独立的,例如一个任务里面产出多张目标结果表是不允许的,对于非常独立的业务逻辑,不产生下游关系的可以酌情放宽限制;

所有表清洗逻辑,首先要按照主键进行去重操作,这是第一步;

所有表需要增加rec_code字段,取值为根据业务主键字段生成的md5值,方便下游对数据的使用,特别是需要导出到rds或者ads时作为必备的主键;

对身份证号码要进行清洗,如15位转18位、特殊字符转换;

字段命名参照词根表,如:门店金额为store_amt。

使用"!=" 或"<>" 时,应注意其返回结果不包含为NULL的数据

相除的字段值要精确小数位数

金额相关字段保留两位小数

涉及四则运算要注意处理空值和0的情况

避免使用隐式转换进行数值大小比较(允许做字典比较)

禁止使用SELECT * 语句

禁止使用INSERT INTO 语句,替换成UNION ALL

使用"!=" 或"<>" 时,应注意其返回结果不包含为NULL的数据

统计行数时使用COUNT(*),禁止使用COUNT(1) 或COUNT(DISTINCT 字段),COUNT(*)为SQL92标准

提前在子查询中缩小查询范围,提升查询效率

字段之间间隔的逗号",",应在新的一行字段前

非情况下括号必须上下对齐(除短函数之外)

空值处理规范

1)汇总类指标的空值:空值处理,填充为零。

2)维度属性值为空:在汇总到对应维度上时,对于无法对应的统计事实,记录行会填充为-99(未知),对应维表会出现一条-99(未知)的记录。

节点配置规范

小时任务配置

时间参数: date=${yyyyMMdd} hour=${yyyyMMddHH}, '${date}','${hour}' 可在代码中直接作为变量使用。

例如: insert overwrite table temp_dwd_mt_ord_evt_hh partition (ds='${date}', hh='${hour}').

天任务配置

时间参数: '${bdp.system.bizdate}'可在代码中直接作为变量使用。

调度依赖

数据中台需要根据实际的上游依赖去调度配置中自己添加相应的上游任务。

测试及质量保证

测试项说明

(1)新增业务需求测试项

表(七)-1 新增业务需求测试项

(2)数据迁移/重构/修改

表(七)-2 数据迁移/重构/修改

维护及故障处理

1、数据重刷

如果任务运行失败,请直接重跑,如果是由于代码变更或上游数据变更导致输出数据发生变更,请预先评估给下游带来的影响而决定是否需要重跑。重跑之(前)后,一定要通知直接下游或重要的间接下游,让下游采取相关的措施。

2、补数据

补数据如果只是针对历史分区回刷(业务需要看到过去一到两年的历史数据或数据指标口径变化后重新计算指标),可以直接执行补数操作。如果补数据还会对现有分区数据造成影响,请预先评估给下游带来的影响而决定是否需要进行相关操作,补数据(前)后,一定要通知直接下游或重要的间接下游,让下游采取相关的措施。

3、口径修改

如果表的取数口径或者字段口径算法发生变更,必须提前通知下游并与下游达成一致后,方可进行后续操作,采用补数据的方式回刷历史数据。

4、故障处理

遇到任务报错、上游问题、平台问题及时通知相关业务方,并按故障处理流程进行升级和处理。

随着数据类型、数据来源的不断丰富以及数据量的飞速增长,企业面临的数据质量问题亦显著增加。然而,数据质量问题是一个复杂问题,往往是多种因素综合作用的结果,问题的解决需从机制、制度、流程、工具、管理等多个方面入手。

第三章 数据质量管理规范

数据质量概述

数据质量管理是指对数据从计划、获取、存储、共享、维护、应用、消亡全生命周期的每个阶段里可能引发的各类数据质量问题,进行识别、度量、监控、预警等一系列管理活动,并通过改善和提高组织的管理水平使得数据质量获得进一步提高。数据质量管理不是一时的数据治理手段,而是循环的管理过程。其终极目标是通过可靠的数据,提升数据在使用中的价值,并最终为企业赢得经济效益。

数据质量评估

数据质量问题来源

数据质量问题的来源可能产生于从数据源头到数据存储介质的各个环节。在数据采集阶段,数据的真实性、准确性、完整性、时效性都会影响数据质量。数据的加工、存储过程都有可能涉及对原始数据的修改,从而引发数据的质量问题。所以,技术、流程、管理等多方面的因素都有可能会影响到数据质量。

数据质量评估维度

数据质量指“数据满足应用的可信程度”,通过以下六个维度识别:

完整性:指数据在创建、传递过程中无缺失和遗漏,包括实体完整、属性完整、记录完整和字段值完整四个方面。完整性是数据质量最基础的一项,例如,员工工号不可为空;

一致性:多源数据的数据模型不一致,例如:命名不一致、数据结构不一致、约束规则不一致。例如:数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致等;

准确性:指真实、准确地记录原始数据,无虚假数据、信息。数据要准确反映其建模的“真实世界”实体。例如,员工的身份信息必须与身份证件上的信息保持一致;

及时性:指及时记录和传递相关数据,满足业务对信息获取的时间(In-time)要求,包括数据交付及时、抽取及时及展现及时;

唯一性:用于识别和度量重复数据、冗余数据。重复数据是导致业务无法协同、流程无法追溯的重要因素,也是数据治理需要解决的最基本的数据问题;

规范性:指数据的值、格式和展现形式符合数据定义和业务定义的要求。例如,员工的国籍必须是国家基础数据中定义的允许值。

数据质量管理过程

数据质量管理分为事前(定义规则)、事中(稽核数据质量)、事后(分析原因改进质量)三个阶段。

事前

事前我们需要定义监控的规则,主要工作如下:

(1)梳理稽核指标:确定稽核对象(多表、单表、字段);

(2)制定稽核规则:通过数据标准、数据资产等级制定监控对象质稽核规则;

(3)制定监控告警级别。设置高、中、低三个级别,低级别告警使用邮件通知;中级别告警使用邮件+短信的方式进行通知;最高级别告警使用邮件+短信+电话三种方式进行通知,确保告警的及时响应。

事中

定义好监控规则后,开展规则监控、评估影响、运营用户预期。

(1)配置质量集合规则

从完整性、准确性、及时性等维度,借助数据中台配置质量稽核规则。

完整性

ODS层数据与数据源做逐行对比

字段的空值率:定位是否是开发过程中的bug造成还是源头系统造成,对于字段值为空的时候,需要确认是否使用缺省值填充。

唯一性

数据唯一性,一般指对数据模型表进行主键唯一性校验,即count(1),count(distinct id)不相等的话,则需要告警。

一致性

同一属性名字不一致、数据类型不一致;

同一实体生命周期不一致;

准确性

数据指标的波动稽核,需要设置阈值;

相关的几个字段或者几张表之间,是不是存在逻辑冲突的情况。

及时性

一般指的是a任务一般运行30分钟,并且2点左右就能跑完,但是通过稽核程序发现,3点该任务还没开始跑,或者已经跑了1个小时还没结束,可能会造成下游任务延迟,需要及时电话告警通过相关值班人员进行处理。

规范性

枚举值、值域范围、数据格式等检测;

非空判断、空值判断、空串判断,通过设置空值率、空串率的阈值进行检测。

(2)处理告警

对非常重要的任务进行电话告警,对影响面不大的质量问题进行短信、邮件通知,事后处理。

电话告警

对于非常重要的异常稽核任务需要电话告警并且终止任务,比如完整性,唯一性,准确性,及时性等。

邮件&短信告警

不需要晚上及时处理的稽核任务,只需要邮件和短信告警,如枚举值校验,数据非空性校验等。

事后

质量时间发生后需要分析原因、修复数据并该井问题生成质量事件报告。

综合分析、质量报告

以报表形式,从数据资产的不同层级、负责人、来源业务等角度对质量进行挖掘分析,形成概览、表打分、同比、环比、排名等一系列结果。

业务反推

对于数据源头问题,反推业务部门进行数据质量整改。

数据质量打分

由数据资产组根据数据模型设计规范与数据开发管理规范,制定检查脚本,并对数据库中数据进行检查,根据检查结果进行整改。

第四章 元数据管理规范

无论结构化数据,还是非结构化数据,或者外部数据,最终都会通过元数据治理落地。企业将元数据治理贯穿整个数据价值流,覆盖从数据产生、汇聚、加工到消费的全生命周期。

元数据治理面临的挑战

企业在进行元数据治理以前,遇到的元数据问题主要表现为数据 找不到、读不懂、不可信,数据分析师们往往会陷入数据沼泽中,例如以下常见的场景。

· 某子公司需要从发货数据里对设备保修和维保进行区分,用来不 对过保设备进行服务场景分析。为此,数据分析师需面对几十个 IT系统,不知道该从哪里拿到合适的数据。

· 因盘点内部要货的研发领料情况,需要从IT系统中获取研发内部 的要货数据,面对复杂的数据存储结构(涉及超过40个物理表和 超过1000个字段)、物理层和业务层脱离的情况,业务部门的数 据分析师无法读懂物理层数据,只能提出需求向IT系统求助。

· 某子公司存货和收入管理需要做繁重的数据收集与获取工作,运 行一次计划耗时超过20个小时。同时,由于销售、供应、交付各 领域计划的语言不通,还需要数据分析师进行大量人工转换与人工校验。

以上场景频繁出现在公司日常运营的各个环节,极大地阻碍了公司数字化转型的进行,其根本原因就在于业务元数据与技术元数据未 打通,导致业务读不懂IT系统中的数据。并且缺乏面向普通业务人员 的准确、高效的数据搜索工具,业务人员无法快速获取可信数据。元数据管理的痛点如图4-1所示。

图4-1 元数据管理痛点

为解决以上痛点,企业必须建立公司级的元数据管理机制。制定统一的元数据管理方法、机制和平台,拉通业务语言和机器语言。 确保数据“入湖有依据,出湖可检索”成为企业元数据管理的使命与目标。 基于高质量的元数据,通过数据地图就能在企业内部实现方便的数据搜索。

元数据是描述数据的数据,用于打破业务和IT之间的语言障碍, 帮助业务更好地理解数据。元数据通常分为业务、技术和操作三类。

· 业务元数据: 用户访问数据时了解业务含义的途径,包括资产目 录、Owner、数据密级等。

技术元数据: 实施人员开发系统时使用的数据,包括物理模型的 表与字段、ETL规则、集成关系等。

操作元数据: 数据处理日志及运营情况数据,包括调度频度、访 问记录等。

在企业的数字化运营中,元数据作用于整个价值流,在从数据源 到数据消费的五个环节中都能充分体现元数据管理的价值。

· 数据消费侧: 元数据能支持企业指标、报表的动态构建。

· 数据服务侧: 元数据支持数据服务的统一管理和运营,并实现利 用元数据驱动IT敏捷开发。

· 数据主题侧: 元数据统一管理分析模型,敏捷响应井喷式增长的 数据分析需求,支持数据增值、数据变现。

· 数据湖侧: 元数据能实现暗数据的透明化,增强数据活性,并能 解决数据治理与IT落地脱节的问题。

· 数据源侧: 元数据支撑业务管理规则有效落地,保障数据内容合格、合规。

元数据管理架构及策略

元数据管理架构包括产生元数据、采集元数据、注册元数据和运 维元数据。

· 产生元数据: 制定元数据管理相关流程与规范的落地方案,在IT 产品开发过程中实现业务元数据与技术元数据的连接。

· 采集元数据: 通过统一的元模型从各类IT系统中自动采集元数 据。

注册元数据: 基于增量与存量两种场景,制定元数据注册方法, 完成底座元数据注册工作。

运维元数据: 打造公司元数据中心,管理元数据产生、采集、注册的全过程,实现元数据运维。

· 元数据管理方案: 通过制定元数据标准、规范、平台与管控机制,建立企业级元数据管理体系,并推动其在公司各领域落地, 支撑数据底座建设与数字化运营。

元数据管理整体方案如图4-2所示。

图4-2 元数据管理整体方案

元数据管理

产生元数据

(1)明确业务元数据、技术元数据和操作元数据之间的关系,定义元数据模型,如图4-3所示。

图4-3 元数据模型

(2)针对找数据及获取数据难的痛点,明确业务元数据、技术元 数据、操作元数据的设计原则。

1)业务元数据设计原则

· 一个主题域分组下有多个主题域, 一个主题域下有多个业务对象, 一个业务对象下有多个逻辑实体, 一个逻辑实体下有多个属性, 一个属性有一个数据标准。

· 每个数据标准可被一个或多个属性引用,每个属性归属于一个逻 辑实体,每个逻辑实体归属于一个业务对象,每个业务对象归属于一个主题域,每个主题域归属于一个主题域分组。

2)技术元数据设计原则

· 物理表设计须满足三范式,如为了降低系统的总体资源消耗,提 高查询效率,可反范式设计。

· 物理表、视图和字段的设计须基于用途进行分类。

· 承载业务用途的物理表、虚拟表、视图必须与逻辑实体一一对 应,承载业务用途的字段必须与属性一一对应。

· 系统间的数据传递须优先采用数据服务。

3)操作元数据设计原则

日志目的不同的进行分类设计,日志目的相同的进行相同设计 (非自研场景按软件包适配)。

(3)规范数据资产管理,设计数据资产编码规范

1)数据资产编码规范

数据资产编码的主要包括业务元数据和技术元数据两大类, 其中业务元数据包含主题域分组、主题域、业务对象、逻辑实体、属 性、数据标准;技术元数据包含物理数据库、Schema、表、字段。具体的定义与描述如表4-1所示。

表4-1 数据资产编码规范

2)数据资产编码原则

数据资产编码(DAN)是通过一组数字、符号等组成的字符串去唯一标识公司内部每一个数据资产,基于此唯一标识,保证各业务领域对同一数据资产的理解和使用一致,它的设计遵循以下原则。

· 统一性原则: 公司内部只能使用一套数据资产编码,以方便不同业务部门之间的沟通和IT应用之间的数据交换。

· 唯一性原则: 每一个数据资产只能用唯一的数据资产编码进行标 识,不同数据资产的编码不允许重复,同一个编码也只能对应到一个数据资产上。

· 可读性原则: 数据资产编码作为数据资产分类、检索的关键词和 索引,需要具备一定的可读性,让用户通过编码就能初步判断其 对应的数据资产类型。

· 扩展性原则: 数据资产的编码要从数据管理角度适当考虑未来几年的业务发展趋势,其编码长度要能适当扩展,同时不影响整个编码体系。

3)业务元数据资产编码规则

业务元数据资产编码规则主要包含三个部分:第一部分为主题域分组的编码规则,主题域分组的编码由公司统一分配;第二部分为主题域、业务对象、逻辑实体、属性的编码规则,这部分主要由数据治理平台按照编码规则自动生成;第三部分主要为业务元数据包含的子类对应的数据资产类型代码。

2. 采集元数据

元数据采集是指从生产系统、IT设计平台等数据源获取元数据, 对元数据进行转换,然后写入元数据中心的过程。元数据的来源可分为如表4-2所示的六类。

表4-2 元数据来源

1)选择适配器

适配器是指针对不同的元数据来源,采用相应的采集方式获取元 数据的程序,元数据的来源种类繁多,因而须选择相对应的适配器及元模型。

2)配置数据源

配置数据源是采集元数据的关键,在确定数据源所选择的适配器类型、适配器版本、元模型的基础上,配置数据源的名称、连接参数和描述。

3)配置采集任务

采集任务为自动调度的工作单元,为元数据的采集提供自动化 的、周期性的、定时的触发机制。

3. 注册元数据

大多数企业的数字化建设都存在增量和存量两种场景,如何同时 有效地管理这两种场景下的元数据就成了问题的关键。公司通过标准的元数据注册规范和统一的元数据注册方法,实现了两种场景下业务元数据和技术元数据的高效连接,使业务人员能看懂数据、理解数 据,并通过数据底座实现数据的共享与消费。

(1)元数据注册原则

元数据注册的原则包括如下三点:

· 数据Owner负责,是谁的数据就由谁负责业务元数据和技术元数据 连接关系的建设和注册发布;

· 按需注册,各领域数据管理部根据数据搜索、共享的需求,推进 元数据注册;

· 注册的元数据的信息安全密级为内部公开。

(2)元数据注册规范

通过“元数据注册三步法”完成元数据注册,如图4-4所示。

图4-4 元数据注册方法

1)准备度评估项包括如下检查要点:

· IT系统名称必须是公司标准名称;

· 数据资产目录是否经过评审并正式发布;

· 数据Owner是否确定数据密级;

· 物理表/虚拟表/视图名。

2)元数据连接需遵从以下规范。

· 逻辑实体和物理表/虚拟表/视图一对一连接规范:在业务元数据 与技术元数据连接的过程中,必须遵从逻辑实体和物理表/虚拟表/视图一对一的连接原则,如果出现一对多、多对一或多对多的 情况,各领域需根据实际场景,参照元数据连接的设计模式进行调整。

· 业务属性与字段一对一连接规范:除了逻辑实体与物理表/虚拟表/视图要求一一对应外,属性和非系统字段(具备业务含义)也 要求遵从一对一的连接原则,如出现属性与字段匹配不上的情况,可参考元数据关联的设计模式进行调整。

完成元数据注册后,通过元数据中心自动发布。

(3)元数据注册方法

元数据注册分为增量元数据注册和存量元数据注册两种场景。

增量场景相对容易,在IT系统的设计与开发过程中,落实元数据 的相关规范,确保系统上线时即完成业务元数据与技术元数据连接, 通过元数据采集器实现元数据自动注册。

针对存量场景,企业应该设计元数据注册的四大模式。在符合元数据设计规范的前提下,进行业务元数据与技术元数据的连接及注册。

模式一:一对一模式

适用场景

适用于数据已发布信息架构和数据标准且物理落地,架构、标准与物理落地能一一对应的场景。

解决方案

· 将逻辑实体和物理表一对一连接。

· 逻辑实体属性和物理表字段一对一连接。

应用实例

具体的应用实例如图4-5所示。

图4-5 元数据注册一对一模式样例

模式二:主从模式

适用场景

适用于主表和从表结构一致,但数据内容基于某种维度分别存储 在不同物理表中的场景。例如,按时间或项目归档,或按区域进行分布式存储。

解决方案

· 识别主物理表和从属物理表。

· 以主物理表为核心,纵向UNION所有从属物理表,并固化为视图。

· 将视图、逻辑实体、字段和业务属性一对一连接。

应用实例

具体的应用实例如图4-5所示。

图4-5 元数据注册主从模式样例

模式三:主扩模式

适用场景

适用于逻辑实体的大部分业务属性在主物理表,少数属性在其他 物理表中的场景。

解决方案

· 识别主物理表和扩展物理表。

· 以主物理表为核心,横向JOIN所有扩展物理表,完成扩展属性与 主表的映射,并固化为视图。

· 将视图、逻辑实体、字段和业务属性一对一连接。

应用实例

具体应用实例如图4-6所示。

图4-6 元数据注册主扩模式样例

模式四:父子模式

适用场景

适用于多个逻辑实体业务属性完全相同,按不同场景区分逻辑实 体名称,但落地在同一张物理表的场景。

解决方案

· 识别一张物理表和对应的多个逻辑实体。

· 将物理表按场景拆分和多个逻辑实体一对一连接。

· 将物理表字段和多个逻辑实体属性一对一连接。

应用实例

具体应用实例如图4-7所示。

图4-7 元数据注册父子模式样例

4. 运维元数据

运维元数据是为了通过对元数据进行分析,发现数据注册、设计、使用的现状及问题,确保元数据的完整、准确。通过数据资产分析,了解各区域/领域的数据注册情况,进而发现数据在各信息系统使用过程中存在的问题。通过业务元数据与技术元数据的关联分析,反向校验架构设计与落地的实施情况,检查公司数据管理政策的执行情况。

主要分为如下四个场景。

场景一:基于数据更新发现,数据源上游创建,下游更新;

场景二:通过数据调用次数发现,某数据源上游调用次数<下游调 用次数;

场景三:虽制定了架构标准,但不知落地情况,比如某个属性建 立了数据标准,但是却找不到对应落地的物理表字段;

场景四:通过物理表的字段分析,发现很多字段缺少数据标准。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。

关键词:

下一篇:从今日起,全市外卖购药可刷医保了!
上一篇:最后一页