数据入湖是数据消费的基础,需要严格满足入湖的6项标准,包括明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。通过这6项标准保证入湖的数据都有明确的业务责任人,各项数据都可理解,同时都能在相应的信息安全保障下进行消费。 
 
 (1)明确数据Owner 
 
数据Owner由数据产生对应的流程Owner担任,是所辖数据端到端管理的责任人,负责对入湖的数据定义数据标准和密级,承接数据消费中的数据质量问题,并制定数据管理工作路标,持续提升数据质量。 
 
 (2)发布数据标准 
 
入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的“属性层”数据的含义和业务规则,是公司层面对某个数据的共同理解,这些理解一旦明确并发布,就需要作为标准在企业内被共同遵守。 
 
|  数据标准内容  |  说明  | |
| 数据资产目录  | 主题域分组  | 公司顶层数据分类,通过数据视角体现最高层面关注的业务领域  | 
| 主题域  | 互不重叠数据的高层面分类,用于管理下一级的业务对象  | |
| 业务对象  | 业务领域的重要人、事、物,承载了业务运作和管理涉及的重要信息  | |
| 逻辑数据实体  | 具有一定的逻辑关系的业务属性集合  | |
| 业务属性  | 描述所属业务对象的性质和特征,反映信息管理的最小粒度  | |
| 定义及规则  | 引用的数据标准  | 说明该业务属性是否引用已定义的数据标准  | 
| 业务定义  | 对业务属性的定义,解释业务属性是什么,对业务的作用  | |
| 业务规则  | 业务属性的业务规则,包括但不限于业务属性在各场景下的变化规则和编码含义等  | |
| 数据类型  | 业务定义的数据类型,例如文本、日期、数字等  | |
| 数据长度  | 业务定义的数据长度  | |
| 允许值  | 业务属性对应的允许值清单  | |
| 数据示例  | 属性实例化的样例,用以帮助其他人员理解此业务属性  | |
| 同义词  | 业务对于同一属性可能有不同的称呼,在此列出业务对此属性的其他称呼  | |
| 标准应用范围  | 业务数据标准在全公司范围,领域或区域范围内容遵从  | |
| 责任主体  | 业务规则责任主体  | 业务规则制定的责任部门  | 
| 数据维护责任主体  | 数据维护的责任部门  | |
| 数据治理监控责任主体  | 数据治理监控责任部门  | |
 (3)认证数据源 
 
通过认证数据源,能够确保数据从正确的数据源头入湖。认证数据源应遵循公司数据源管理的要求,一般数据源是指业务上首次正式发布某项数据的应用系统,并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出现合并、分拆、下线情况时,应及时对数据源进行失效处理,并启动新数据源认证。 
 
 (4)定义数据密级 
 
定义数据密级是数据入湖的必要条件,为了确保数据湖中的数据能充分地共享,同时又不发生信息安全问题,入湖的数据必须要定密。数据定密的责任主体是数据Owner,数据管家有责任审视入湖数据密级的完整性,并推动、协调数据定密工作。数据定级密度在属性层级,根据资产的重要程度,定义不同等级。不同密级的数据有相应的数据消费要求,为了促进公司数据的消费,数据湖中的数据有相应的降密机制,到降密期或满足降密条件的数据应及时降密,并刷新密级信息。 
 
 (5)数据质量评估 
 
数据质量是数据消费结果的保证,数据入湖不需要对数据进行清洗,但需要对数据质量进行评估,让数据的消费人员了解数据的质量情况,并了解消费该数据的质量风险。同时数据Owner和数据管家可以根据数据质量评估的情况,推动源头数据质量的提升,满足数据质量的消费要求。 
 
 (6)元数据注册 
 
元数据注册是指将入湖数据的业务元数据和技术元数据进行关联,包括逻辑实体与物理表的对应关系,以及业务属性和表字段的对应关系。通过联接业务元数据和技术元数据的关系,能够支撑数据消费人员通过业务语义快速地搜索到数据湖中的数据,降低数据湖中数据消费的门槛,能让更多的业务分析人员理解和消费数据。