|
本文将基于我们对数据标准的理解，阐述标准的建立并依据标准的建立内容和流程来设计的标准管理产品的介绍以及标准在数据治理过程中的具体实践，希望与大家碰撞出新的认识。 数据标准的是什么？ 在实际的工作生产中，我们一般会参照国家标准、地方标准、行业标准等来进行具体的活动，来确保我们生成过程符合监管要求、便于上下游协同等，于是我们会见到如下的标准指导文件：
同样，数据标准也会以文件的形式存在，在除了国标、行标定义的标准外，企业内部为了便于各部门采取同样的数据建设规范，通常会使用文件来定义数据标准，以供各部门达成统一的共识。 虽然文件是标准的一种体现形式，但文件是非结构化的，在实际应用中，我们只有理解、提取文件里的内容，将标准应用于产品设计及流程活动当中去，标准才能起到真正的规范约束作用。 根据信通院发布的《数据标准管理实践白皮书》定义：数据标准（Data Standards）是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。 毫无疑问，这是正确的。但我们还需要将标准践行，以建设数据中台为例，我们知道数据中台强调的是资源整合，在数据层面就是整合多源异构系统中分散在各个孤岛的数据，形成统一的数据服务能力，这是一项艰巨的任务， 很难通过互相约定以及默认信任相关方来保障数据的价值发掘，形成真正的数据资产。 于是，基于此点将数据标准进行扩充，一是对管理范围的扩充，从狭义的数据标准（指对基础数据本身的规范性约束，如数据格式、类型、值域等）扩充到整个数据中台层面的标准（包含治理各阶段的规范性约束）；二是对管理手段的扩充，数据标准不再是指一系列的数据标准化文档，而是一套由规范要求、流程制度、技术工具共同组成的体系，通过这套体系完成标准的规划、制定、发布、执行、检查、维护等行为，来完成数据的标准化以及标准的沉淀。 数据标准的价值 在说价值之前，我们先聊聊让我们头疼的问题。人人都在谈论数据标准，但数据标准真的被应用起来了么，我们拿着一堆标准文件，期望企业内部宣贯大家要按照这个标准来，但执行的结果如何？ 数据集成多源异构数据时，数仓开发人员真的能快速理解这些数据的实际业务含义么？如果理解成本很高，开发人员可能就会出现认识偏差。 终于数据集成进来了，可以开始进行数仓建设了，如何保证每一层的数据都是符合质量要求的，靠开发的个人素质么？比如我们一般在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节详细介绍 ），确定该项数据标准描述的对象类及特性，再通过关键词扫描及智能识别技术，扫描存量数据，识别与该数据元概念一致的数据项集合，对该集合进行探查获取字段类型分布、长度范围、值域分布等，从而构建数据元的表示描述，形成完整的数据标准。 第二种是暂无明确制定某项标准的需求，去探索是否需要对某些数据项制定标准。系统对存量数据进行扫描，遍历所选择的数据源类型中的所有字段名，提取达到重复阈值的字段名，对其制定数据标准。 3.2 数据标准制定 3.2.1 元数据标准 元数据标准主要规范了平台对于各类元数据及资产的表示方式和组织方式。 3.2.1.1 元模型的制定 数据中台是企业数字化转型的基础和中枢系统，将企业全域海量、多源、异构的数据整合资产化，但多源异构数据差异化明显，如何保证数据管理者、使用者、开发者对数据具备统一的认知是亟待解决的问题。良好元模型设计，主旨在于屏蔽底层多源异构系统的复杂度，用统一的语言来描述来自不同应用系统、存储在不同种类数据库的各类数据。
元模型不仅限于表元模型、字段元模型，还包含指标元模型、标签元模型等，虽然所描述的元数据种类不同，但管理方法上都是一致的，在实践的过程中，可全部纳入数据标准进行管理，也可在对应的子系统中各自维护。 3.2.1.2 命名及编码规则制定 命名规则主要用于规范表名、字段名、任务名称、指标名称、标签名称等，指定某个名称应当使用哪些命名要素组成以及以何种排列顺序组成。编码规则主要用户资产编码、数据元内部标识符、标签编码、指标编码等，指定某个编码应当使用何种编码方式。 因此需要指定命名及编码要素范围，一是选取平台已存在的枚举值，如数据分层、主题域或其他已存在的分类枚举；二是用户可自定义常量、自定义枚举值；三是平台提供的可变位序列。通过上述的命名要素，进行排序组合，形成命名及编码规则。 以数据元为例子： 第一种编码方式可以为“指定标识（常量）+7位自增序列”，可以编码为DE0000001; 第二种编码方式可以按照所在分类进行统一编码，类似于“一级分类编码+二级分类编码+三位自增序列”，比如公民身份号码数据元归属分了为”人员类（01）/信息标识类（001）“，那么可以编码为01001001，其他以此类推。 3.2.1.3 数据目录规范制定 数据目录提供灵活的数据组织方式，比如数仓开发人员使用数据分层、主题域来组织数据，对于数据管理者，可能更关注于资产盘点，希望能够按照来源系统、管理部门以及安全分类等多种方案进行管理。 我们在制定数据目录时，需要分析用户的需求场景，在不同场景下为用户提供更合适的数据视角，便于用户取数用数。一般来说，会先提供数据来源分类、数仓设计分类、数据安全分类，分类的描述信息至少要包含分类名称、英文名称、内部编码，以便于在平台其他模块的应用。且分类方案支持用户在后期的管理过程中进行自定义扩充。 3.2.2 基础数据标准 3.2.2.1 词根的制定 词根是为了标准的命名更加规范统一，最终将被应用到字段命名或其他资产的命名上。 企业可根据自身积累，对词根进行收集，形成自己的词根库，在制定数据元及字典时，可根据输入的中文名称自动根据词根翻译英文名称。 一个完整的词根信息包含英文简称、英文全称、中文全称三个部分，其中文全称支持多个，保证用户在使用词根翻译时相同含义字段能够获取相同的英文简称。另外，为了便于统一管理，需对词根的编码及词根来源进行指定。 3.2.2.2 数据元的制定 数据元是基础类数据标准的具象化体现，也是数据标准管理的核心。根据数据标准规划，制定数据元第一种方式是对现行标准进行结构化提取，使用平台进行管理，第二种则是根据自身需要建立企业自己的专业数据元。 完整的数据元应当由三部分组成，对象类、特性及表示，如下图所示，只有当对象类及其特性绑定了表示时，才能由数据元概念转变为真正的数据元。 对象类：现实世界中的想法、抽象概念或事物的集合，有清楚的边界和含义，并且特性和其行为遵循同样的规则而能够加以标识;，如：车、人、订单等； 特性：对象类的所有个体所共有的某种性质，如颜色、性别、年龄、价格等； 表示：值域、数据类型的组合，必要时也包括度量单位或字符集，如：格式、值域、长度等；
在理解了数据元的含义后，如何去制定数据元呢？我们可参考GB/T 18391标准的第1~6部分，有兴趣的朋友可以去了解下，这里结合我们的理解给出数据元的结构化描述。
3.2.2.3 数据字典的制定 数据字典是参照类数据标准的具象体现，一般分为原始字典及标准字典，原始字典指源系统或生产系统中某个原始项数据内容的枚举集合，标准数据字典一般用于作为数据元值域而存在，在数据处理过程中需要完成原始字典到标准字典的映射，完成字典标准化工作。
获得码表的方式：
3.2.2.4 数据项分类规范制定 数据项分类与数据目录类似，也是为了满足在不同场景下，对不同对象的分类需求。数据项分类即是对字段级进行分类。 在制定数据目录时，需要分析用户的需求场景，在不同场景下为用户提供不同的分类方案。如从管理角度，可以按照描述对象、来源文件进行划分；从数据安全角度可以按照敏感级别、安全级别进行划分等，且分类方案支持用户在后期的管理过程中进行自定义扩充。 在实际应用的过程时，会将具体的分类值关联数据元，再由数据元关联字段，做到快速分类的目的。 3.2.3 技术标准制定 3.2.3.1 数据类型映射关系 主要记录不同数据源间数据类型的映射关系，便于在数据传输、分发等场景下快速建表，提升数据传输任务的配置效率。 3.2.3.2 异构数据开发模板制定 主要管理不同数据源的DDL语句模板，包含新增、删除、更新等，协助数据开发人员选择对应数据库节点时快速根据模板生成语句。 3.3 数据标准发布 一般数据标准建议遵循草案、试用、标准、废止的生命周期流转，但可根据实际情况进行简化。对于数据元、数据字典尽可能遵循此生命周期管理，对于词根、数据分类、元模型等可简化流程，可采取草案、上线、下线的生命周期管理。 数据标准发布是在标准制定完成进入开发完成态后，可提交发布审核，审核通过后将应用于整个系统，若后续需要进行修订，则需修订完成后重新发布最新版本。 另外，发布前需查看版本变化以及影响范围，评估影响后再进行发布生效，并通知相关方进行调整。 3.4 数据标准执行 数据标准执行主要分两块，第一块是正在进行数据治理的各个阶段进行应用，第二块是新建系统和历史存在的业务系统的应用。 数据治理过程的应用主要在（涉及数据标准与各个模块的对接，将在第4节详细介绍）：
新建的业务系统
正在运行的系统
3.5 数据标准检查 数据标准执行后，需要进行落标检查，确认标准执行的情况以及效果。 可参考相关指标，从标准侧进行标准的引用统计、标准化率统计，从质量侧统计表及字段质量评分，多角度去判断指标执行情况及应用效果。 3.6 数据标准维护 维护数据标准
沉淀数据标准
数据标准产品介绍 在了解了如何建立数据标准后，我们可以着手开始干了。但工欲善其事必先利其器，一个合适的数据标准管理工具可以帮助我们更方便、更高效的制定和管理数据标准。 因此我们基于数据标准管理流程、管理内容的分析，并充分考虑不同行业对标准管理需求的不一致性，对数据标准管理产品进行功能设计，本章将详细介绍产品的各个模块。
4.2 产品功能模块 4.2.1 数据标准统计首页
4.2.2 数据标准文件管理
4.2.2.1 数据元管理 数据元管理是标准管理核心内容，支持表单及批量导入的方式录入数据元，按照标准生命周期草案、试用、标准、废止对数据元进行管理，支持数据元的批量导出，满足不同场景下查看数据元的需求。定义时也将数据元与稽核规则进行绑定，为质量检测提供依据。
4.2.2.2 数据字典管理 数据字典管理内容包含原始字典及标准字典，可以认为原始字典是原始数据项的值域分布， 标准字典是标准数据项的值域分布。原始字典可主动录入，也可通过数据探查的值域分布进行生成；标准字典满足与数据元同样的生命周期管理，也支持批量导入导出操作。
4.2.2.3 词根管理 词根管理旨在定义英文名称、英文简称、中文名称间的映射关系，为标准的命名提供规范的输入。用户在定义数据元、数据字典或模型字段时，将对输入的中文名称进行拆词，依据词根生成英文名称。
4.2.2.4 数据项分类管理 数据项分类管理提供了三个层级目录类型，第一种管理的是分类目录，用户对分类方案进行归类；第二种管理的是分类方案，它是基于某种数据项分类依据（如描述对象）提供的一种分类方式；第三种是分类值，它归属于分类方案，在这一层将与真正的数据元进行挂载。
4.2.3 元数据标准管理 4.2.3.1 命名及编码规则管理
4.2.3.2 数据目录管理
4.2.4 技术标准管理 4.2.4.1 数据类型映射关系管理
4.2.4.2 DDL模板管理 主要管理不同数据源的DDL语句模板，包含新增、删除、更新等，在模型设计时或离线开发时进行引用，根据选中的信息，替换模板中的参数。以mysql建表为例： CREATE TABLE IF NOT EXISTS ${table_name}( 4.2.5 标准流程管理 4.2.5.1 标准发现
4.2.5.2 审核管理
4.2.5.3 标准发布
4.2.6 标准配置 标准配置主要是对数据元及数据字典的元模型进行配置管理，我们提供了较为全面的数据标准结构化表示方法，但根据不同行业对标准描述的需要，可能并不需要这么多描述项，因此提供数据标准的元模型配置，用户可根据实际情况进行启用、停用或新增标准的描述项。
数据标准和数据中台的结合实践 在具体实施过程中，我们期望按照“需求-设计-开发-交付”流程进行建设。在需求设计阶段，应对数据现状进行摸排，确定治理范围以及标准的制定范围。从而在后续的设计中能够规范指标及模型设计，从源头上开始控制元数据及数据的质量，指导开发过程的具体实施。
5.1 数据传输 数据传输承担着将多源异构数据集成到大数据平台以及将平台数据分发到其他库的能力，当目标库无对应表时，需要根据来源表进行建表，但不同数据源间的类型差异，需要人工进行匹配，随着数据源种类的不断增加，靠人的经验进行匹配处理已非常困难。
5.2 元数据 5.2.1 表元模型设计
5.2.1.2 系统内置项管理
5.2.1.3 自定义项管理
5.3 模型设计 5.3.1 分层规划
对于分层下的表，需要配置表名设计规范，将选取命名要素按照一定顺序排列，得到命名规则
5.3.2 分类规划 利用数据目录管理进行分类规划，在资源目录、资产侧按照场景对数据资源进行编目，满足各类用户查数用数需求。如：主题域划分、来源系统划分、安全分类等。 5.3.3 表结构及数据项标准设计
5.4 数据开发 SQL编辑时根据选择的输入输出表，通过表字段关联的数据元信息，将相同含义的字段自动进行映射，快速生成SQL，用户只需对生成的SQL进行确认即可。 在后续的规划中，标准将助力可视化ETL以及自动化ETL，协助用户进行字段映射，根据数据元关联的稽核规则、脱敏规则等，自动获取对应的处理函数，即可生成开发脚本。 5.5 数据质量
5.6 数据安全
总结 数据标准的建设及管理任重而道远，后续将逐步扩展标准的应用场景，满足各行业客户的需求。随着管理内容的不断丰富，管理流程的不断完善，标准将作为数据中台的基石，为各模块、各流程阶段提供规范性指导及监督。 - EOF - |
|
|
来自： 520jefferson > 《大数据》
