在实际的工作生产中,我们一般会参照国家标准、地方标准、行业标准等来进行具体的活动,来确保我们生成过程符合监管要求、便于上下游协同等,于是我们会见到如下的标准指导文件:
同样,数据标准也会以文件的形式存在,在除了国标、行标定义的标准外,企业内部为了便于各部门采取同样的数据建设规范,通常会使用文件来定义数据标准,以供各部门达成统一的共识。
虽然文件是标准的一种体现形式,但文件是非结构化的,在实际应用中,我们只有理解、提取文件里的内容,将标准应用于产品设计及流程活动当中去,标准才能起到真正的规范约束作用。
根据信通院发布的《数据标准管理实践白皮书》定义:数据标准(Data Standards)是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。
毫无疑问,这是正确的。但我们还需要将标准践行,以建设数据中台为例,我们知道数据中台强调的是资源整合,在数据层面就是整合多源异构系统中分散在各个孤岛的数据,形成统一的数据服务能力,这是一项艰巨的任务, 很难通过互相约定以及默认信任相关方来保障数据的价值发掘,形成真正的数据资产。
于是,基于此点将数据标准进行扩充,一是对管理范围的扩充,从狭义的数据标准(指对基础数据本身的规范性约束,如数据格式、类型、值域等)扩充到整个数据中台层面的标准(包含治理各阶段的规范性约束);二是对管理手段的扩充,数据标准不再是指一系列的数据标准化文档,而是一套由规范要求、流程制度、技术工具共同组成的体系,通过这套体系完成标准的规划、制定、发布、执行、检查、维护等行为,来完成数据的标准化以及标准的沉淀。
在说价值之前,我们先聊聊让我们头疼的问题。人人都在谈论数据标准,但数据标准真的被应用起来了么,我们拿着一堆标准文件,期望企业内部宣贯大家要按照这个标准来,但执行的结果如何?
数据集成多源异构数据时,数仓开发人员真的能快速理解这些数据的实际业务含义么?如果理解成本很高,开发人员可能就会出现认识偏差。
终于数据集成进来了,可以开始进行数仓建设了,如何保证每一层的数据都是符合质量要求的,靠开发的个人素质么?比如我们一般在dwd层做数据标准化,那么不同主题域的由不同的负责人进行开发,怎么保证标准化的结果似乎满足规范的?dws的数据可信度还能保证么?还能被叫做公共模型层么?
再后,数仓开发完成后需要对外开放,我们其实开发的不光是其数据,还需要开发它的元数据信息,帮助数据使用方快速的找到需要的数据,如果只是把数据堆在一起,只有研发人员自己知道这个数据是什么、在哪、怎么使用,那是不能够被称为数据资产的。
还有很多问题,这里只列举了些典型。当然这些问题,是可以解决的,解决的方式就是数据标准。解决的的过程可能需要的时间比较长,因为标准从管理到落地执行推进并不是一件容易的事,需要从思想上进行转变,但我们总要正确的做事。
下面列举了一些价值,但在实际的应用过程能够发现更多的可能性。
价值一:建立统一的数据视图
建立通用的元模型规范,支持用户自定义扩展,对多源异构数据表进行信息抽象提取,形成统一的元数据层。所有的数据开发完成后发布到数据标准维护的统一的数据目录,通过不同维度的数据目录进行多维筛选,满足各类用户的检索需要,达到资产的可管、可用、可查的目标。
价值二:建立统一的数据认知
首先利用标准完成对多源异构数据的标准化描述,虽然数据在不同系统中的称呼千奇百怪,但只要进入我们的平台都将赋予统一的名姓,使得管理方、开发方、使用方建立统一认知。对于仓外表将数据标准与表字段进行关联,旨在统一含义以及告知未来数据处理的方向;对于仓内表,模型设计之初就需要引用标准,我们知道将数据项进行组合即可得到模型,数据元即为标准数据项池,模型设计时仅需从池子里选取需要的字段进行组合即可组装成想要的模型。
价值三:建立质量稽核体系
现有的质量稽核一般是由用户根据业务需求手动设置,不同人员的认知偏差将导致数据质量难以控制。数据标准通过数据元的表示类属性,根据其格式、类型等要求自动生成质量稽核规则,当某张表的字段绑定了数据元时,即可根据数据元的质量信息要求自动生成稽核任务,且保证了源头定义的一致性。
价值四:面向未来的数据治理
我们知道,工具的终极目的都是为了降本提效。效率提升是要靠流程规范的,流程足够规范,在某种程度上可实现流程自动流转。因此,未来的数据治理趋势应当侧重于流程自动化以及阶段智能化,而这两点都需要数据标准的支撑。
阶段智能化期望在流程各阶段提供智能识别能力,比如字段的真实含义(挂载数据标准)、资源所属分类、字段枚举值等,减少人工参与。从短期来看,用户从处理者变为审核者,从长期来看,用户干预的行为反哺识别模型,增加识别准确性,可降低人力成本;
流程自动化依赖阶段智能化以及人工干预的结果,将各阶段进行串联,上下游尽可能完美对接,当上游阶段达到下游准入条件时,可自动触发流程运作,当然该过程也需要统一上下游语言(即数据标准),在实际实践中,可通过试运行进行验证。
标准的价值还有很多,限于篇幅不过多赘述,大家可以不断发现标准的应用场景。说完标准的价值了,那么我们该如何建立数据标准呢?
在早期的业务发展过程中,企业为了解决当下的业务问题,各业务条线已建设自己个性化的业务系统,在建设的过程中为了保证内部通信,或多或少都已存在局部的数据标准。因此,建设统一的数据标准很大程度上是对局部标准进行收口,一般来说,可收集现行的国家标准或行业标准,将现有标准与国标或行标进行对标,此过程一是可以满足监管需要,二是可大大节省标准制定的人力;另一方面则是考虑所在行业的特点并结合企业的实际需要,逐步构建标准进行推行。
具体可参考数据标准的建立的6个步骤,分别是:数据标准规划、数据标准制定、数据标准发布、数据标准执行、数据标准检查、数据标准维护。
标准的规划首先需对企业业务和数据进行调研和分析,结合实际的数据标准需求,明确数据标准的范围。再根据实际情况的不同,逐步推进。
可从业务流程出发,圈定参与业务流程的业务实体,通用的业务实体如人,可收集对应现行的国家标准,如对于公民身份证号码应当遵循强制性标准GB 11643 ,对于性别的代码应当参考推荐性标准GB/T 2261.1的规定,行政区划应当参考GB/T 2260的规定等。具备行业属性的业务实体如商业银行担保物,可参考JR/T 0170.1以及JR/T 0170.2的规定等。
对于企业各业务条线(部门)已建立的局部标准且不适用于引用现行标准或不存在于现行标准的需要进行收集,对同一业务含义但不同标准描述的项进行评审,在企业内部达成一致,得到最终统一的数据标准。
此过程可包含基础类数据标准统一、参照类标准统一、指标类数据标准统一。
发现更多标准主要应用于以下情况,一是局部标准不明确也无现行标准适用时,二是企业各业务条线垂直系统较多,数据体量较大,缺乏足够的人力及技术手段,但从总体战略的角度期望制定标准时。应对这种情况可依赖数据标准管理平台(第3节将详细介绍)进行标准的识别及拾取。
标准的识别及拾取一般存在两种方式:
第一种有明确制定某项标准的需求,则通过定义数据元概念(第2.2节详细介绍 ),确定该项数据标准描述的对象类及特性,再通过关键词扫描及智能识别技术,扫描存量数据,识别与该数据元概念一致的数据项集合,对该集合进行探查获取字段类型分布、长度范围、值域分布等,从而构建数据元的表示描述,形成完整的数据标准。
第二种是暂无明确制定某项标准的需求,去探索是否需要对某些数据项制定标准。系统对存量数据进行扫描,遍历所选择的数据源类型中的所有字段名,提取达到重复阈值的字段名,对其制定数据标准。
元数据标准主要规范了平台对于各类元数据及资产的表示方式和组织方式。
3.2.1.1 元模型的制定
数据中台是企业数字化转型的基础和中枢系统,将企业全域海量、多源、异构的数据整合资产化,但多源异构数据差异化明显,如何保证数据管理者、使用者、开发者对数据具备统一的认知是亟待解决的问题。良好元模型设计,主旨在于屏蔽底层多源异构系统的复杂度,用统一的语言来描述来自不同应用系统、存储在不同种类数据库的各类数据。
我们知道元数据是描述数据的数据,而元模型则是关于模型的数据描述,根据OMG(对象管理组织)提出的四层元模型结构,可以清晰的表达出四层的关系:
可以看出,元数据是个相对的概念,元模型即为元数据的元数据,为了更方便大家理解,这里提供一个实例解释:
元模型不仅限于表元模型、字段元模型,还包含指标元模型、标签元模型等,虽然所描述的元数据种类不同,但管理方法上都是一致的,在实践的过程中,可全部纳入数据标准进行管理,也可在对应的子系统中各自维护。
3.2.1.2 命名及编码规则制定
命名规则主要用于规范表名、字段名、任务名称、指标名称、标签名称等,指定某个名称应当使用哪些命名要素组成以及以何种排列顺序组成。编码规则主要用户资产编码、数据元内部标识符、标签编码、指标编码等,指定某个编码应当使用何种编码方式。
因此需要指定命名及编码要素范围,一是选取平台已存在的枚举值,如数据分层、主题域或其他已存在的分类枚举;二是用户可自定义常量、自定义枚举值;三是平台提供的可变位序列。通过上述的命名要素,进行排序组合,形成命名及编码规则。
以数据元为例子:
第一种编码方式可以为“指定标识(常量)+7位自增序列”,可以编码为DE0000001;
第二种编码方式可以按照所在分类进行统一编码,类似于“一级分类编码+二级分类编码+三位自增序列”,比如公民身份号码数据元归属分了为”人员类(01)/信息标识类(001)“,那么可以编码为01001001,其他以此类推。
3.2.1.3 数据目录规范制定
数据目录提供灵活的数据组织方式,比如数仓开发人员使用数据分层、主题域来组织数据,对于数据管理者,可能更关注于资产盘点,希望能够按照来源系统、管理部门以及安全分类等多种方案进行管理。
我们在制定数据目录时,需要分析用户的需求场景,在不同场景下为用户提供更合适的数据视角,便于用户取数用数。一般来说,会先提供数据来源分类、数仓设计分类、数据安全分类,分类的描述信息至少要包含分类名称、英文名称、内部编码,以便于在平台其他模块的应用。且分类方案支持用户在后期的管理过程中进行自定义扩充。
3.2.2.1 词根的制定
词根是为了标准的命名更加规范统一,最终将被应用到字段命名或其他资产的命名上。
企业可根据自身积累,对词根进行收集,形成自己的词根库,在制定数据元及字典时,可根据输入的中文名称自动根据词根翻译英文名称。
一个完整的词根信息包含英文简称、英文全称、中文全称三个部分,其中文全称支持多个,保证用户在使用词根翻译时相同含义字段能够获取相同的英文简称。另外,为了便于统一管理,需对词根的编码及词根来源进行指定。
3.2.2.2 数据元的制定
数据元是基础类数据标准的具象化体现,也是数据标准管理的核心。根据数据标准规划,制定数据元第一种方式是对现行标准进行结构化提取,使用平台进行管理,第二种则是根据自身需要建立企业自己的专业数据元。
完整的数据元应当由三部分组成,对象类、特性及表示,如下图所示,只有当对象类及其特性绑定了表示时,才能由数据元概念转变为真正的数据元。
对象类:现实世界中的想法、抽象概念或事物的集合,有清楚的边界和含义,并且特性和其行为遵循同样的规则而能够加以标识;,如:车、人、订单等;
特性:对象类的所有个体所共有的某种性质,如颜色、性别、年龄、价格等;
表示:值域、数据类型的组合,必要时也包括度量单位或字符集,如:格式、值域、长度等;
其中,值域可通过名称或码值直接给出、也可通过参考资料给出、也可通过绑定数据字典给出。
因此完整的数据元名称应当为:“对象类词+特性词+表示词”,如人性别代码。
在理解了数据元的含义后,如何去制定数据元呢?我们可参考GB/T 18391标准的第1~6部分,有兴趣的朋友可以去了解下,这里结合我们的理解给出数据元的结构化描述。
在制定数据元时,我们通常会从6个方面描述数据元的基本属性:标识类属性、定义类属性、关系类属性、表示类属性、管理类属性、附加类属性,如下表,这是一个综合的较为通用的数据元描述模板,在应用过程中需要根据企业实际需要,进行删减补全。
3.2.2.3 数据字典的制定
数据字典是参照类数据标准的具象体现,一般分为原始字典及标准字典,原始字典指源系统或生产系统中某个原始项数据内容的枚举集合,标准数据字典一般用于作为数据元值域而存在,在数据处理过程中需要完成原始字典到标准字典的映射,完成字典标准化工作。
数据字典核心是其码值列表,码值列表至少要包含两项信息:代码、代码描述,必要时可增加说明字段进行补充。
获得码表的方式:
原始字典:数据库逆向采集、元数据注册时填写字段枚举值、数据探查时值域分布计算、手动录入;
标准字典:现行标准的结构化提取、标准识别结果分析、手动录入。
3.2.2.4 数据项分类规范制定
数据项分类与数据目录类似,也是为了满足在不同场景下,对不同对象的分类需求。数据项分类即是对字段级进行分类。
在制定数据目录时,需要分析用户的需求场景,在不同场景下为用户提供不同的分类方案。如从管理角度,可以按照描述对象、来源文件进行划分;从数据安全角度可以按照敏感级别、安全级别进行划分等,且分类方案支持用户在后期的管理过程中进行自定义扩充。
在实际应用的过程时,会将具体的分类值关联数据元,再由数据元关联字段,做到快速分类的目的。
3.2.3.1 数据类型映射关系
主要记录不同数据源间数据类型的映射关系,便于在数据传输、分发等场景下快速建表,提升数据传输任务的配置效率。
3.2.3.2 异构数据开发模板制定
主要管理不同数据源的DDL语句模板,包含新增、删除、更新等,协助数据开发人员选择对应数据库节点时快速根据模板生成语句。
一般数据标准建议遵循草案、试用、标准、废止的生命周期流转,但可根据实际情况进行简化。对于数据元、数据字典尽可能遵循此生命周期管理,对于词根、数据分类、元模型等可简化流程,可采取草案、上线、下线的生命周期管理。
数据标准发布是在标准制定完成进入开发完成态后,可提交发布审核,审核通过后将应用于整个系统,若后续需要进行修订,则需修订完成后重新发布最新版本。
另外,发布前需查看版本变化以及影响范围,评估影响后再进行发布生效,并通知相关方进行调整。
数据标准执行主要分两块,第一块是正在进行数据治理的各个阶段进行应用,第二块是新建系统和历史存在的业务系统的应用。
数据治理过程的应用主要在(涉及数据标准与各个模块的对接,将在第4节详细介绍):
元数据:需要从业务属性、技术属性、管理属性三个方面对元数据进行描述,需要定义具体的描述项。
数据资产:需要对各类资产进行盘点,需要定义资产编码及命名规范、定义分类依据、上线标准。
数据质量:需要建立稽核规则,需要构建质量检测体系。
数据安全:需要对数据进行分级分类,需要定义数据项分类依据、敏感信息的识别依据。
模型设计:需要定义数据模型、数据指标、维度度量等数据的标准。
数据传输:需要对接不同种数据源、来源系统,需要制定不同系统、数据源间的交换依据。
数据开发:需要定义数据处理依据,字段及字典映射逻辑、各类数据源SQL模板。
新建的业务系统
必须严格按照发布的标准进行设计,通过使用平台提供的模型设计产品进行管控
正在运行的系统
可以通过探查、智能识别的手段建立映射关系
数据标准执行后,需要进行落标检查,确认标准执行的情况以及效果。
可参考相关指标,从标准侧进行标准的引用统计、标准化率统计,从质量侧统计表及字段质量评分,多角度去判断指标执行情况及应用效果。
维护数据标准:
在实际执行的过程中,可能现行标准发生修订,企业自身业务规则发生变化,都需要对已发布的标准进行修订。
修订要严格按照生命周期流转要求,记录版本变化,评估变更影响,在进行重新发布生效。
沉淀数据标准:
随着标准的累计,我们需要沉淀所在行业的标准。
通过标准沉淀,建立标准资产,形成行业最佳实践,提升企业在所在行业的地位。
在了解了如何建立数据标准后,我们可以着手开始干了。但工欲善其事必先利其器,一个合适的数据标准管理工具可以帮助我们更方便、更高效的制定和管理数据标准。
因此我们基于数据标准管理流程、管理内容的分析,并充分考虑不同行业对标准管理需求的不一致性,对数据标准管理产品进行功能设计,本章将详细介绍产品的各个模块。
主要包含标准资产统计、标准化情况统计、标准流程统计,全方位评估标准建设及使用情况。
此模块用于管理当前平台参照的各类标准文件,并与已结构化的标准建立联系,保证标准来源的可信。另外,针对已经做过结构化标准提取的文件,将作为平台预置的标准模板,供用户使用。
4.2.2.1 数据元管理
数据元管理是标准管理核心内容,支持表单及批量导入的方式录入数据元,按照标准生命周期草案、试用、标准、废止对数据元进行管理,支持数据元的批量导出,满足不同场景下查看数据元的需求。定义时也将数据元与稽核规则进行绑定,为质量检测提供依据。
另外,支持数据元不同版本之间的比对,获取版本差异,评估标准变更存在的风险。
4.2.2.2 数据字典管理
数据字典管理内容包含原始字典及标准字典,可以认为原始字典是原始数据项的值域分布, 标准字典是标准数据项的值域分布。原始字典可主动录入,也可通过数据探查的值域分布进行生成;标准字典满足与数据元同样的生命周期管理,也支持批量导入导出操作。
在后续的实现中,将完成从平台已有数据库中存在的字典表进行拾取,同时维护原始字典与标准字典之间的关系,方便用户在进行数据处理时快速进行字典对标。
4.2.2.3 词根管理
词根管理旨在定义英文名称、英文简称、中文名称间的映射关系,为标准的命名提供规范的输入。用户在定义数据元、数据字典或模型字段时,将对输入的中文名称进行拆词,依据词根生成英文名称。
除了已支持的词根表单录入外,后续将支持词根的批量导入,帮助用户快速导入已制定好的词根列表。
4.2.2.4 数据项分类管理
数据项分类管理提供了三个层级目录类型,第一种管理的是分类目录,用户对分类方案进行归类;第二种管理的是分类方案,它是基于某种数据项分类依据(如描述对象)提供的一种分类方式;第三种是分类值,它归属于分类方案,在这一层将与真正的数据元进行挂载。
因此数据项分类支持分类的基本信息管理,也支持对数据元批量进行关联以及解除关联。
4.2.3.1 命名及编码规则管理
命名规则及编码管理要能够将平台中已有的可作为命名要素的枚举值进行收集管理,支持用户添加自定义元素,用户可通过点击或拖拽的方式将元素进行组合形成命名规则及编码规则。
4.2.3.2 数据目录管理
数据目录管理与数据项分类管理类似,但分类的对象不同,此处分类主要是对平台各类资产的编目,提供多种视角、多种方案对表、指标、标签等进行分类管理,应用于统一的资产目录进行展示,让资产可理解、可识别、易查找。
4.2.4.1 数据类型映射关系管理
主要管理不同数据源间数据类型的映射关系,如下表示例,随着数据源种类的增加,此模块支持多数据源类型交叉映射。
4.2.4.2 DDL模板管理
主要管理不同数据源的DDL语句模板,包含新增、删除、更新等,在模型设计时或离线开发时进行引用,根据选中的信息,替换模板中的参数。以mysql建表为例:
CREATE TABLE IF NOT EXISTS ${table_name}(
${filed_list}
PRIMARY KEY ( ${pk_filed_name} )
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
4.2.5.1 标准发现
根据标准制定流程,平台提供数据库拾取能力,对标准进行识别,根据识别结果来得出结论 ,即完整的数据元定义。下面是根据数据元概念进行识别的页面参考。
4.2.5.2 审核管理
审核管理主要是对标准生命周期流转的申请以及标准的发布申请进行操作,审核人员可根据实际情况评估,选择通过或拒绝。
4.2.5.3 标准发布
标准发布采取整包发布的方式,若将同一批次的数据元列表发布一个大版本,保证平台的标准参考基线。需要支持查看当前更新的内容,提交发布申请,比对版本差异,支持查看发布历史等。
标准配置主要是对数据元及数据字典的元模型进行配置管理,我们提供了较为全面的数据标准结构化表示方法,但根据不同行业对标准描述的需要,可能并不需要这么多描述项,因此提供数据标准的元模型配置,用户可根据实际情况进行启用、停用或新增标准的描述项。
4.2.6.1 数据元模板配置
4.2.6.2 数据字典模板配置
在具体实施过程中,我们期望按照“需求-设计-开发-交付”流程进行建设。在需求设计阶段,应对数据现状进行摸排,确定治理范围以及标准的制定范围。从而在后续的设计中能够规范指标及模型设计,从源头上开始控制元数据及数据的质量,指导开发过程的具体实施。
数据标准在治理流程中的位置以及跟各模块产生的交互。
数据传输承担着将多源异构数据集成到大数据平台以及将平台数据分发到其他库的能力,当目标库无对应表时,需要根据来源表进行建表,但不同数据源间的类型差异,需要人工进行匹配。随着数据源种类的不断增加,靠人的经验进行匹配处理已非常困难。
标准维护的是不同数据源间类型的映射关系,在建立传输任务时,可根据映射关系快速生成目标表结构,达到快速建表、一键建表的能力。
元模型的配置在我们的实践中主要包含对元模型分组管理、系统内置项管理、用户自定义项管理,目前已支持对表、字段、指标、标签的元模型设计。
5.2.1.1 分组管理
5.2.1.2 系统内置项管理
5.2.1.3 自定义项管理
除了系统内置的分层外,用户可添加自定义分层。
对于分层下的表,需要配置表名设计规范,将选取命名要素按照一定顺序排列,得到命名规则。
利用数据目录管理进行分类规划,在资源目录、资产侧按照场景对数据资源进行编目,满足各类用户查数用数需求。如:主题域划分、来源系统划分、安全分类等。
设计表结构时,一方面根据填写的中文描述,自动推荐对应的数据元(若标准存在),另一方面可直接选择数据元,平台将根据选择的数据元自动回填字段名、字段类型、字段描述以及关联的标准数据字典,如下图所示:
具体应用一般放在模型设计中心添加字段时进行关联:
SQL编辑时根据选择的输入输出表,通过表字段关联的数据元信息,将相同含义的字段自动进行映射,快速生成SQL,用户只需对生成的SQL进行确认即可。
在后续的规划中,标准将助力可视化ETL以及自动化ETL,协助用户进行字段映射,根据数据元关联的稽核规则、脱敏规则等,自动获取对应的处理函数,即可生成开发脚本。
数据标准是数据质量稽核规则的主要参考依据,通过将数据质量稽核规则与数据标准关联,一方面可以实现字段级的数据质量校验,另一方面也可以直接构建较为通用的数据质量稽核规则体系,确保规则的全面性和可用性。
数据标准可包含业务敏感数据对象和属性,从而实现对数据安全管理相关规则的定义。通过数据元关联,快速生成字段级加密或脱敏规则。
数据标准的建设及管理任重而道远,后续将逐步扩展标准的应用场景,满足各行业客户的需求。随着管理内容的不断丰富,管理流程的不断完善,标准将作为数据中台的基石,为各模块、各流程阶段提供规范性指导及监督。