数据标准在数据治理中的落地实践

现实生活中，标准与我们息息相关，食物需要满足国家标准才能食用，汽车排放达标才能上路行驶，电脑接口得满足统一的标准才能够与外设对接等等。 在数据世界，数据的标准也同等重要。我们期望将数据标准真正应用到实践中去，帮助客户解决资产化不足、数据质量难以提升、数据开发效率低等问题，于是网易数帆开始了数据标准的建设。 在本手册中，我们将基于对数据标准的理解，阐述标准的建立并依据标准的建立内容和流程来设计的标准管理产品的介绍以及标准在数据治理过程中的具体实践，希望与大家碰撞出新的认识。 三、如何建立数据标准？04 3.1 数据标准规划 04 3.1.1 收集现行标准043.1.2 从局部标准到全局标准043.1.3 发现更多数据标准04 3.2 数据标准制定 3.2.1 元数据标准053.2.2 基础数据标准073.2.3 技术标准制定11 3.6 数据标准维护12 四、数据标准产品介绍13 4.1 产品总体架构13 4.2 产品功能模块14 4.2.1 数据标准统计首页144.2.2 数据标准文件管理144.2.3 数据项标准管理154.2.4 元数据标准管理184.2.5 技术标准管理194.2.6 标准流程管理194.2.7 标准配置22 五、数据标准和数据中台的结合实践 5.1 数据传输 5.2 元数据 5.2.1 表元模型设计245.2.2 字段元模型设计265.2.3 指标元模型设计265.2.4 标签元模型设计27 5.3 模型设计 5.3.1 分层规划275.3.2 分类规划275.3.3 表结构及数据项标准设计28 六、总结 一.数据标准是什么？ 在实际工作生产中，一般会参照国家标准、地方标准、行业标准等来进行具体的活动，来确保生成过程符合监管要求、便于上下游协同等，于是会常见到如下的标准指导文件： 同样的，数据标准也会以文件的形式存在。除了国标、行标定义的标准外，企业内部为了便于各部门采取同样的数据建设规范，通常会使用文件来定义数据标准，以供各部门达成统一的共识。 文件固然是标准的一种体现形式，但文件是非结构化的，在实际应用中，只有理解、提取文件里的内容，将标准应用于产品设计及流程活动当中去，标准才能起到真正的规范约束作用。 根据信通院发布的《数据标准管理实践白皮书》定义：数据标准（Data Standards）是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。 毫无疑问，这是正确的。但还需要将标准践行，以建设数据中台为例，我们知道数据中台强调的是资源整合，在数据层面就是整合多源异构系统中分散在各个孤岛的数据，形成统一的数据服务能力，这是一项艰巨的任务， 很难通过互相约定以及默认信任相关方来保障数据的价值发掘，形成真正的数据资产。 于是，基于此点我们将数据标准进行扩充U 对管理范围的扩充：从狭义的数据标准（指对基础数据本身的规范性约束，如数据格式、类型、值域等）扩充到整个数据中台层面的标准（包含治理各阶段的规范性约束）对管理手段的扩充：数据标准不再是指一系列的数据标准化文档，而是一套由规范要求、流程制度、技术工具共同组成的体系，通过这套体系完成标准的规划、制定、发布、执行、检查、维护等行为，来完成数据的标准化以及标准的沉淀。 二.数据标准的价值 在说价值之前，先聊聊让我们头疼的问题。 人人都在谈论数据标准，但数据标准真的被应用起来了么，我们拿着一堆标准文件，期望企业内部宣贯大家要按照这个标准来，但执行的结果如何？ 数据集成多源异构数据时，数仓开发人员真的能快速理解这些数据的实际业务含义么？如果理解成本很高，开发人员可能就会出现认识偏差。 终于数据集成进来了，可以开始进行数仓建设了，如何保证每一层的数据都是符合质量要求的，靠开发的个人素质么？比如我们一般在dwd层做数据标准化，那么不同主题域的由不同的负责人进行开发，怎么保证标准化的结果似乎满足规范的？dws的数据可信度还能保证么？还能被叫做公共模型层么？ 再后，数仓开发完成后需要对外开放，我们其实开发的不光是其数据，还需要开发它的元数据信息，帮助数据使用方快速的找到需要的数据，如果只是把数据堆在一起，只有研发人员自己知道这个数据是什么、在哪、怎么使用，那是不能够被称为数据资产的。 还有很多问题，这里只列举了些典型。当然这些问题，是可以解决的，解决的方式就是数据标准。 解决的过程可能需要的时间比较长，因为标准从管理到落地执行推进并不是一件容易的事，需要从思想上进行转变，但我们总要正确的做事。 下面列举了一些价值，但在实际的应用过程能够发现更多的可能性： 价值一：建立统一的数据视图 建立通用的元模型规范，支持用户自定义扩展，对多源异构数据表进行信息抽象提取，形成统一的元数据层。 所有的数据开发完成后发布到数据标准维护的统一的数据目录，通过不同维度的数据目录进行多维筛选，满足各类用户的检索需要，达到资产的可管、可用、可查的目标。 价值二：建立统一的数据认知 首先利用标准完成对多源异构数据的标准化描述，虽然数据在不同系统中的称呼千奇百怪，但只要进入我们的平台都将赋予统一的名姓，使得管理方、开发方、使用方建立统一认知。 对于仓外表将数据标准与表字段进行关联，旨在统一含义以及告知未来数据处理的方向；对于仓内表，模型设计之初就需要引用标准，我们知道将数据项进行组合即可得到模型，数据元即为标准数据项池，模型设计时仅需从池子里选取需要的字段进行组合即可组装成想要的模型。 价值三：建立质量稽核体系 现有的质量稽核一般是由用户根据业务需求手动设置，不同人员的认知偏差将导致数据质量难以控制。 数据标准通过数据元的表示类属性，根据其格式、类型等要求自动生成质量稽核规则，当某张表的字段绑定了数据元时，即可根据数据元的质量信息要求自动生成稽核任务，且保证了源头定义的一致性。 价值二：建立统一的数据认知 工具的终极目的都是为了降本提效。效率提升是要靠流程规范的，流程足够规范，在某种程度上可实现流程自动流转。因此，未来的数据治理趋势应当侧重于流程自动化以及阶段智能化，而这两点都需要数据标准的支撑。 阶段智能化期望在流程各阶段提供智能识别能力，比如字段的真实含义（挂载数据标准）、资源所属分类、字段枚举值等，减少人工参与。从短期来看，用户从处理者变为审核者，从长期来看，用户干预的行为反哺识别模型，增加识别准确性，可降低人力成本； 流程自动化依赖阶段智能化以及人工干预的结果，将各阶段进行串联，上下游尽可能完美对接，当上游阶段达到下游准入条件时，可自动触发流程运作，当然该过程也需要统一上下游语言（即数据标准），在实际实践中，可通过试运行进行验证。 标准的价值还有很多，限于篇幅不过多赘述，大家可以不断发现标准的应用场景。说完标准的价值了，那么我们该如何建立数据标准呢？ 三.如何建立数据标准？ 在早期的业务发展过程中，企业为了解决当下的业务问题，各业务条线已建设自己个性化的业务系统，在建设的过程中为了保证内部通信，或多或少都已存在局部的数据标准。 因此，建设统一的数据标准很大程度上是对局部标准进行收口，一般来说，可收集现行的国家标准或行业标准，将现有标准与国标或行标进行对标，此过程一是可以满足监管需要，二是可大大节省标准制定的人力；另一方面则是考虑所在行业的特点并结合企业的实际需要，逐步构建标准进行推行。 具体可参考数据标准的建立的6个步骤： 3.1 数据标准规划 标准的规划首先需对企业业务和数据进行调研和分析，结合实际的数据标准需求，明确数据标准的范围。再根据实际情况的不同，逐步推进。 3.1.1 收集现行标准 可从业务流程出发，圈定参与业务流程的业务实体，通用的业务实体如人，可收集对应现行的国家标准，如对于公民身份证号码应当遵循强制性标准GB 11643 ,对于性别的代码应当参考推荐性标准GB/T 2261.1的规定，行政区划应当参考GB/T 2260的规定等。具备行业属性的业务实体如商业银行担保物，可参考JR/T 0170.1以及JR/T 0170.2的规定等。 3.1.2 从局部标准到全局标准 对于企业各业务条线（部门）已建立的局部标准且不适用于引用现行标准或不存在于现行标准的需要进行收集，对同一业务含义但不同标准描述的项进行评审，在企业内部达成一致，得到最终统一的数据标准。 此过程可包含基础类数据标准统一、参照类标准统一、指标类数据标准统一。 3.1.3发现更多数据标准 发现更多标准主要应用于以下情况 二是企业各业务条线垂直系统较多，数据体量较大，缺乏足够的人力及技术手段，但从总体战略的角度期望制定标准时。应对这种情况可依赖数据标准管理平台（第3节将详细介绍）进行标准的识别及拾取。 标准的识别及拾取一般存在两种方式œ <第一种有明确制定某项标准的需求，则通过定义数据元概念（第2.2节详细介绍 ），确定该项数据标准描述的对象类及特性，再通过关键词扫描及智能识别技术，扫描存量数据，识别与该数据元概念一致的数据项集合，对该集合进行探查获取字段类型分布、长度范围、值域分布等，从而构建数据元的表示描述，形成完整的数据标准r<第二种是暂无明确制定某项标准的需求，去探索是否需要对某些数据项制定标准。系统对存量数据进行扫描，遍历所选择的数据源类型中的所有字段名，提取达到重复阈值的字段名，对其制定数据标准。 3.2 数据标准制定 3.2.1 元数据标准 元数据标准主要规范了平台对于各类元数据及资产的表示方式和组织方式。 3.2.1.1 元模型的制定 数据中台是企业数字化转型的基础和中枢系统，将企业全域海量、多源、异构的数据整合资产化，但多源异构数据差异化明显，如何保证数据管理者、使用者、开发者对数据具备统一的认知是亟需解决的问题。良好元模型设计，主旨在于屏蔽底层多源异构系统的复杂度，用统一的语言来描述来自不同应用系统、存储在不同种类数据库的各类数据。 我们知道元数据是描述数据的数据，而元模型则是关于模型的数据描述，根据OMG（对象管理组织）提出的四层元模型结构，可以清晰的表达出四层的关系： 可以看出，元数据是个相对的概念，元模型即为元数据的元数据，为了更方便大家理解，这里提供一个实例解释： 元模型不仅限于表元模型、字段元模型，还包含指标元模型、标签元模型等，虽然所描述的元数据种类不同，但管理方法上都是一致的，在实践的过程中，可全部纳入数据标准进行管理，也可在对应的子系统中各自维护。 3.2.1.1 元模型的制定 命名规则主要用于规范表名、字段名、任务名称、指标名称、标签名称等，指定某个名称应当使用哪些命名要素组成以及以何种排列顺序组成。编码规则主要用户资产编码、数据元内部标识符、标签编码、指标编码等，指定某个编码应当使用何种编码方式。 因此需要指定命名及编码要素范围，一是选取平台已存在的枚举值，如数据分层、主题域或其他已存在的分类枚举；二是用户可自定义常量、自定义枚举值；三是平台提供的可变位序列。通过上述的命名要素，进行排序组合，形成命名及编码规则。 以数据元为例子¸ ¨第一种编码方式可以为“指定标识（常量）+7位自增序列”，可以编码为DE0000001™¨第二种编码方式可以按照所在分类进行统一编码，类似于“一级分类编码+二级分类编码+三位自增序列”，比如公民身份号码数据元归属分了为”人员类（01）/信息标识类（001）“，那么可以编码为01001001，其他以此类推。 3.2.1.3 数据目录规范制定 数据目录提供灵活的数据组织方式，比如数仓开发人员使用数据分层、主题域来组织数据，对于数据管理者，可能更关注于资产盘点，希望能够按照来源系统、管理部门以及安全分类等多种方案进行管理。 我们在制定数据目录时，需要分析用户的需求场景，在不同场景下为用户提供更合适的数据视角，便于用户取数用数。一般来说，会先提供数据来源分类、数仓设计分类、数据安全分类，分类的描述信息至少要包含分类名称