共计 8768 个字符，预计需要花费 22 分钟才能阅读完成。
网易外部如严选、云音乐、传媒等数据团队对数据内容体系的治理思路都是将治理标准融入到开发过程中，将治理的动作提前，这其实就是“开发治理一体化”；预先依赖数据资产衰弱评估和治理工具进行数据的治理，建设事先加预先的数据治理体系。随着网易数帆商业化的倒退，遇到很多金融及大型国企客户，咱们发现互联网的这套数据治理的打法并不能全副适应传统行业客户的场景。咱们开始向客户和竞争对手学习，为此打磨出元数据管理，数据规范，数据资产目录等子产品，积淀出一套数据治理的产品体系。本文次要内容包含以下四个方面：“先设计后开发”“先净化后治理”基于元数据的数据治理体系基于逻辑数据湖的数据治理介绍 1“先设计后开发”在软件工程中良好的设计具备不可比较的意义，它胜于需要、编码、保护等环节，秉承设计优先的准则会让软件开发变得简略高效，能够尽量避免掉因设计失误而导致的缺点，一个强壮的程序必然有良好的设计。网易数帆无数数据中台产品的特色之一“先设计后开发”，其指标就是将数据规范定义、指标标准定义、模型设计和数据开发体系连贯在一起，实现“标准即设计，设计即开发”、以设计驱动开发，并通过流程管控卡点保障元数据的生成是依照标准落地的。在开发的过程中保障数据规范，数据品质，数据安全的落地，这就是将开发治理一体化，冀望能达到“事倍功半”的事先治理计划。
在没有“数据规范”产品之前咱们，咱们举荐客户的数据体系构建工作流蕴含业务和需要调研，数据架构设计，指标标准定义，数据模型设计，数据开发五个过程。数据架构设计指以维度建模为实践根底，基于业务和需要调研的后果，通过需要联动设计，对数仓进行整体规划，蕴含确定数据域，形象业务板块，定义数据域下的业务过程；指标标准定义，包含原子指标，业务限定如修饰词、工夫周期，派生指标则由原子指标和业务限定组合而成；也蕴含维度及属性的标准定义；数据模型设计是指基于原子指标，派生指标，维度属性组合的维表、明细事实表和汇总事实表的模型设计；数据开发：将逻辑模型变成物理模型，是设计与物理实现的对立。
再好的标准设计都须要工具来落地和束缚，否则就是一纸空文，咱们认为所有需要都能够拆解为指标和维度，指标和维度组合就是模型，所以用指标管理工具和模型设计核心去承载标准设计的落地：数据研发同学在指标治理中配置化定义维度、业务过程、原子指标、工夫周期的中英文名称；这个过程曾经实现维表和事实表的定义；分析师或者数据口径管理者负责定义派生指标的业务元数据，通过抉择原子指标和业务限定主动生成派生指标，派生指标全局惟一，这样就轻松的打消数据的二义性；在这个过程其实就曾经实现汇总表的定义。
通过后面两步根本实现指标和模型的定义，数据研发同学就能够联合以后模型的状况在模型设计核心实现模型的设计或者批改。以后市面有些公司也是基于这个逻辑将模型设计和指标治理合二为一造成半 AutoETL 产品，主动生成指标 / 模型 / 调度关系。附模型设计准则：dwd_{业务缩写 /pub}_{数据域缩写}_{业务过程缩写}_[{自定义表命名标签缩写}]_{刷新周期标识}{单分区增量全量标识}dws_{业务缩写 /pub}_{数据域缩写}_{数据主粒度缩写}_[{自定义表命名标签缩写}]_{统计工夫周期范畴缩写}/{刷新周期标识}{单分区增量全量标识} 复制代码在模型和指标的落地过程中，通过“庖丁解牛”式的产品配置将数据模型波及的技术元数据 / 业务元数据进行标准化，标准化的益处是“车同轨，书同文，大家都说普通话”。能够说咱们产品从一开始就实现了开发治理一体化。2“先净化后治理”“先净化后治理”是以后数据治理的支流计划，与其说支流不如说是无奈的抉择，因为“先设计再开发”意味着重构，重构尽管是最彻底的计划但也是最难实操执行的，毕竟很多数据团队最外围要交付的是短期业务价值，重构带来需要交付效率的降落且短期无显著价值增长，也有很多数据团队就会抉择边开发边进行治理的计划，咱们将网易的教训和过程也在这里做一个介绍。2.1 静止式治理随着业务的倒退，网易外部业务线的计算和存储达到瓶颈，但业务方很难判断，是应该持续扩容减少资源，还是对劣质数据进行治理来升高资源危机，但这个过程中，如何定义劣质数据，定义了劣质资源后，要怎么对其进行治理，都是亟待确定和解决的问题；另一方面，数据自身的加工链路长，数据的加工解决没有对立的规范，整个团队内到底有哪些数据，数据的负责人是谁，这些数据是通过哪些工作产出的，这些数据有没有被无效的应用，数据的存在是否有意义，这些都是管理者比较关心的问题，但数据团队都很难答复。通过静止式的专项治理咱们还是积淀出局部工具
2.2 度量体系的构建基于元数据的建设，咱们将底层的表信息、计算工作信息和工作 / 表之间的血统信息，汇总为计算、存储的元数据仓库，联合外部本人的账单体系对计算和存储均进行了定价，从而将调度工作、自助查问每次执行耗费的计算成本预估进去，对于存储老本，一方面蕴含数据表自身的存储老本，另一方面产出该表的计算工作也会摊派该数据表的老本，最终失去数据表总的存储老本。将计算和存储老本转化为费用，更加高深莫测的对治理成果进行量化评估。为了不便用户了解，咱们构建了对立的衰弱分度量体系
3 基于元数据的数据治理体系无论“先设计后开发”亦或是“先净化后治理”，都少不了过程元数据的积淀，这样才会让治理无论在任何阶段都变得轻松牢靠。在商业化实际的过程中咱们逐渐地排汇了传统行业一些长处，例如在 21 年底咱们上线了数据规范、元数据管理这两款产品，同时数据规范，元数据管理、数据品质、模型设计、指标治理、平安核心等产品做了买通能实现数据规范的校验，让数据规范不再是一纸空文。越来越多行业的实际让咱们开始思考咱们的数据治理体系须要降级，首先是站在数据内容体系须要明确治理的范畴。3.1 明确数据治理的范畴 3.1.1 仓内数据全生命周期数据管理能力成熟度评估模型给出了数据管理能力成熟度评估模型以及相应的成熟度等级，定义了数据策略、数据治理、数据架构、数据利用、数据安全、数据品质、数据规范和数据生存周期等 8 个能力域。咱们的数据治理的范畴参考了 DCMM 模型，同时也是围绕数据的全生命周期开展的，在数据生产阶段，须要对需要进行剖析，明确业务口径，对数据进行标准采集、工作开发和监控运维；在数据生产阶段，波及到疾速地查找数据，对数据的剖析和对数据品质的探查；在数据管理过程中，蕴含权限和老本治理等。整个流程波及到老本、规范、品质、平安和价值，各个阶段都会面临对数据的治理工作。
在具体的数据治理产品层面做了一些微调：DCMM 蕴含有数据规范，数据品质，数据安全，数据利用（咱们叫数据价值），咱们在这个规范的根底上一方面欠缺数据规范的内容，另一方面也将老本治理退出到治理的范畴内。造成五大模块：数据规范治理，减少指标标准，模型标准。其中元数据标准治理也在这个模块；数据价值，通过数据利用在业务的应用状况治理无用或低频数据；数据老本，蕴含存储老本和计算成本的治理；数据品质治理，蕴含数据的准确性，一致性，及时性，完整性，唯一性；数据安全治理，蕴含数据权限，性能权限，敏感数据辨认，脱敏加密治理。3.1.2 仓外元数据的治理过来很长一段时间咱们将数据治理的范畴定在仓内，很多公司经验了多年的建设，领有大量独立的数据利用体系，数据架构非常复杂，也是数据治理绕不开的一道墙。尤其是在构建数据资产大盘时就须要思考仓外元数据的治理以及一些手工元数据的治理。为此咱们研发了元数据管理模块，用于对立治理仓内和仓外元数据。它包含元数据注销、元数据注册采集、元数据存储、元数据分析等，涵盖了元数据的全链路生命周期治理。反对元数据的主动采集和调度治理，反对手工创立和变更元数据，并配合版本治理，便于用户跟踪元数据整个生命周期动静和变动。3.2 数据治理产品的优化 3.2.1 开发治理一体化 3.2.1.1 面临的问题从网易外部的实际来看，过重的设计不行（例如应用 ERwin、power designer 相似的工具交付设计 ER 图），无设计也不行。开发治理一体化现实很完满，大家也很认可“先设计后开发”的理念，但很多业务中也面临执行不到位。例如：业务探索期 / 高速发展期须要疾速获取经营数据，业务方能承受的排期不会超过 1 周，留给数据建设的周期并不长，很多报表间接从 ODS 源表进行加工，为了疾速上线就义设计，效率优先，且不足合作。从商业化的客户来看无数产品体系中的指标治理和模型治理还是停留在治理体系，与开发体系的元数据管理、数据传输、数据品质的联动性有余。设计、开发和治理体系短少一个连接点，能平滑地将三者交融；短少流程管控，或以就义开发效率的指标的“先设计后开发”是不残缺的研发治理一体化。3.2.1.2 更欠缺的“先设计后开发”很长时间内咱们在标准这块不足能平滑地将设计、开发和治理交融的产品，直到 2021 年推出了数据规范；同时为了更好的流程合作治理，咱们优化了流程合作与音讯核心，构建能自定义的流程引擎、企业组织架构和音讯告诉。“先设计后开发”外围是元数据的标准，在设计阶段就束缚元数据的定义，开发阶段则通过流程管控保障标准元数据的生成，这样就能保障逻辑与物理的对立。数据规范的指标就是实现元数据标准的定义，联合指标和模型两款产品，将数据标准规范定义、指标标准定义、模型设计和数据开发体系通过流程引擎连贯在一起，以实现“标准即设计，设计即开发，开发即治理”的开发治理一体化。
数据规范：通过制订数据的规范保障数据的内外部应用和替换的一致性和准确性的规范性束缚。对指标的元数据进行标准定义，从业务属性、技术属性、治理属性三个方面对元数据进行形容。在实际过程中将数据元与指标关联买通，并能够对指标在数据品质、数据安全、模型设计规范等方面的执行状况进行预先查看评估。指标治理：自动化生成指标，打消数据的二义性。指标的设计须要合乎数据规范的标准，欠缺指标的技术、业务、治理元数据。模型设计：负责数据模型的设计，也须要遵循数据规范的标准，将指标与模型挂钩，标准表和字段的元数据；数据开发体系：将数据开发的过程与数据标准联合实现业务规定的数字化落地。负责将设计的数据模型实现，将技术元数据（血统，品质，负责人，调度工作信息等）和标准规范联合，实现模型设计与数据开发的协同，真正意义的实现了元数据的标准化落地。标准束缚：数据规范负责定义“好数据”的规范，蕴含品质、平安等；指标工具负责设计好的指标和维度；每个指标须要与数据规范关联；模型设计核心负责设计好的数据模型，模型的每个字段必须来自指标治理的定义好的指标和维度能力实现物理建表；数据开发体系依照设计要求实现代码的开发，负责生产“好数据”和“好元数据”。指标、模型设计这块的落地计划，我在第一章已有具体的介绍，这里就不独自再介绍了。再强调一下再好的标准没有工具产品来匹配落地就是一纸空文。工具产品必须有所卡点能力保障设计和落地的一致性，须要通过流程引擎保障先设计后开发的流程、保障标准的落地。这些卡点蕴含：数据规范的标准在指标和模型的援用率，预先须要查看标准的执行状况指标零碎的指标须要主动生成，且保障唯一性，同时也须要测验指标的类似度。模型的设计时模型的分层，数据域，业务过程，工夫周期等变量的定义是选择题而非填空题，模型设计与建表一体化，倡议敞开其余通道 DDL 执行。同时模型的标准预先须要检测：如类似度，复用度，穿透率，覆盖率，闲置率等，如有必要保障模型建表惟一通道上线前数据模型、品质、平安等标准未落地不容许公布上线。将数据开发与数据治理联合起来既是对开发过程的管控，也是保障数据品质的无效办法。需要阶段次要对业务数据进行调研、拆解数据、确定词根、数据项以及业务指标。设计阶段基于调研的内容进行规范和指标的设计并利用于模型和品质，设计实现后进行元数据的注册并实现业务信息的录入。开发阶段依据设计阶段的标准进行数据开发、束缚开发流程，通过元数据扫描实现元数据技术信息的录入，最初将元数据进行审核并公布。在数据的全生命周期内各个模块协同的案例：数据规范与模型设计：在数据模型设计中关联数据规范，数据规范中字段命名能够间接利用在模型字段上。数据规范与数据品质：数据规范中的数据元对应的值阈束缚能够关联稽核规定。数据规范与数据安全：数据规范中的数据元能够关联数据安全的数据敏感等级和数据脱敏规定。数据品质与模型设计：数据模型关联的数据元所关联的数据品质稽核规定，能够间接利用到这个模型的稽核工作上。数据安全与模型设计：模型公布，主动利用平安核心的脱敏规定。
开发治理一体化对于很多公司意味着数据体系的重构。在重构的过程中用流程束缚元数据的生成，保障元数据的规范性。事先治理的计划对客户数据建设所处的机会要求就会比拟高，尽管也能够依照数据域逐个重构迁徙，整体建设周期较长，价值也不能空谷传声；然而数据体系的建设本就是数据“熵增”的过程，咱们在建设中对他做功，这样熵增加的比例是在可控的范畴内，事先做功对数据治理来说事“事倍功半”的抉择。对过程做功会带来效率的升高，将来如果搭配可视化 ETL 和 AutoETL 工具就能在效率和治理上实现双丰收。3.2.2 数据衰弱评估与优化工具 3.2.2.1 面临的问题数据治理的诉求在互联网公司晚期并不那么强烈，个别的关注点也只是在老本有余、数据产出不及时、指标口径对不上、数据品质呈现重大问题的时候会发动治理专项，而后等着再净化再治理。这个阶段次要呈现出的特点是：被动式（无抓手），静止式。一套基于数据建设的衰弱度评估体系加优化工具就应运而生。在网易的实际过程中咱们创造了一套基于 ROI 的数据资产积淀办法，咱们研发了基于 Hadoop 的元数据分析服务，能够精准计算出每个工作耗费了多少计算，存储资源，同时买通数据生产和生产的全链路的数据血统，依照工作援用进行上游摊派，最终可测算出每个利用（数据报表、数据 API）耗费了多少资源，同时还有数据利用的应用状况（PV/UV/ 重要水平），能够找到没有应用却耗费很大资源的利用，同时采纳“剥洋葱”式的数据下线形式，从下层数据利用开发逐层推动数据下线。依靠于这套办法咱们构建了基于老本、标准、品质、平安、价值的数据衰弱分体系。咱们心愿通过”评分赛马”的机制来驱动开发同学自助实现数据治理，也获得了很多功效，严选 / 音乐 / 传媒在这套治理体系外在老本 / 品质 / 标准规范上都有显著的晋升。那么这一套治理体系为什么不能在传统行业疾速利用起来呢，我的了解有两点：（1）传统行业的开发及治理方面其实更偏“治理”，以银行证券行业为例一方面业务层面被强监管，业务过程十分稳固，主管单位会下发国家标准，合规性十分重要；另一方面数据团队的形成上有大量的外包人员，由一个甲方领导几十个外包人员，平安和稳固是第一位的，所以治理流程是十分必要，而互联网更器重效率，所以咱们的产品在治理上很涣散的，也导致治理元数据的不足；（2）互联网公司很多时候其实依赖的是人治，依赖数据开发同学的集体业余能力去缩小前期治理的事件，就像阿里的 OneData 体系也只是给开发人员应用，咱们也举荐“先设计后开发”的开发治理一体化。传统行业有专职数据治理团队负责治理体系，而咱们的产品不足为这类角色服务，没有合乎他们应用场景的性能和流程。3.2.2.2 更欠缺的预先治理体系（1）构建数据治理的价值体系基于数据的全生命周期，蕴含了老本、品质、平安、规范和价值五个方面，针对每个方面，都要建设大家认同的可量化的指标，通过指标去掂量数据治理的价值，对立数据衰弱诊断的度量衡。
对于老本，包含计算和存储老本的费用量化，对无用数据的下线治理等；对于价值，须要可能评估每个数据模型、数据报告和 API 的利用价值；对于品质，会蕴含监控工作笼罩了多少稽核规定，涵盖了多少强弱规定；对于标准规范，须要对数据规范、指标和模型进行标准度和复用性的评估；对于平安，会蕴含数据安全等级和数据权限的治理等内容的评估。（2）体系化治理伎俩数据治理不是一个临时性要做的工作，从数据生命周期的全过程到治理体系的衰弱运行，须要一个长效的治理机制来保障，体系化的数据治理。最开始是发现问题，蕴含老本、规范、品质、平安和价值五个方面，明确须要进行治理的内容；而后基于须要治理的内容配套专题的治理工具，比方对无用数据的举荐下线，对表生命周期的治理，对计算工作的优化等；最初在治理工作过程中，继续有治理抓手，包含推送整个我的项目、集体的资产账单，数据治理的红黑榜，并将资产衰弱分和集体的工作优先级或资源申请等挂钩继续经营：例如举办数据治理大赛、业务线专项治理流动等来继续经营和打磨产品的能力。
整体通过发现问题 –> 解决问题 –> 继续经营和继续积淀造成资产治理的闭环。（3）强化治理属性对立数据治理控制台作为所有治理项的入口，一方面是零碎预置治理规定扫描的待治理项，蕴含老本、品质、平安、标准和价值五个方面；另一方面是通过工单模式指派给相干治理管理者的治理项；用户分层，从项目组、我的项目和用户角度出现待治理和已治理项，强化数据治理专员这个角色；自定义数据治理流程，例如待我治理 / 待处理工单，数据消费者、我的项目负责人、数据治理专员都能够发动资产的治理工单（比方字段形容缺失、数据品质分较低等）零碎会将治理工单下发给资产负责人，所有工单信息都会体现在“待我治理”模块；数据治理的流程定义与企业组织架构、音讯零碎如 IM 等进行买通，造成治理闭环。3.3 产品整体计划通过下面的介绍可知咱们的数据治理产品蕴含事先和预先两条路线。笼罩数据的全生命周期（从元数据的注册到数据利用生产），蕴含”先设计再开发“的事先治理、数据衰弱评估与优化（预先治理）这两条线，以实现建设“标准的元数据”和“好的数据”。同时在生产端将衰弱的资产通过业务分类和标签等形式来组织，便于普通用户在数据生产时能“找的到、读的懂、信的过”。数据消费者对数据资产有任何问题能够一键发动数据治理工单，资产责任人则须要实现响应。资产责任人须要实现零碎辨认的治理内容和数据消费者、负责人、治理负责人发动的治理内容。我的项目负责人，治理负责人能够发动数据治理工单。治理负责人蕴含数据治理专员及治理负责人，对企业数据资产品质负责。
3.4 元数据数据治理满足的场景元数据管理，蕴含仓内、仓外，手工元数据的整体纳管，数据资产一体化构建企业对立数据资产地图，让数据消费者找的到、读的懂、信的过；通过笼罩元数据注册 - 采集 - 扫描 - 审批 - 公布 - 应用 - 变更 - 废除的全生命周期，构建一条残缺的元数据治理链路；笼罩数据研发，数据治理，数据服务，到数据利用的全链路数据血统，从而构建基于 ROI 的数据资产积淀体系和”剥洋葱“式的从利用到底层的数据下线机制；制订和治理企业的数据规范，保障数据的内外部应用和替换的一致性和准确性的规范性构建对立指标库，打消数据的二义性；数仓模型优化，从规范性，复用性，利用价值上构建衰弱的数据体系；老本治理，蕴含存储，计算成本优化，降本增效；数据品质治理，通过数据开发前数据比对，状态探查，数据测试报告，数据工作运行中的强弱规定阻断上游工作避免数据净化，预先晋升数据品质监控覆盖率等形式全面晋升数据品质；数据安全治理，蕴含数据资产的分类分级，脱敏加密，平安扫描，平安审计，权限治理等。4 基于逻辑数据湖的数据治理介绍咱们在调研内部用户需要的过程中，常常会碰到的问题：每个企业用户的技术建设状况不同，业务复杂度也不一，很多传统企业已有的 IT 零碎已运行了很多年，只是无奈再反对日益增长的数据需要，他们在大数据技术体系的教训简直空白，当面对一个比方 lambda 架构的大数据解决方案时，往往会感觉过于简单和难以把握，对落地功效心存疑虑。还有局部用户的业务在现有技术框架上（比方 MPP）运行良好，出于对将来倒退的前瞻性思考，须要提前进行大数据的根底技术建设，这部分用户对于大数据将来的必要性是必定的，然而会特地关怀其实用的场景、业务覆盖度以及如何平滑地进行业务的迁徙。数据湖 &Hadoop 解决的是数据对立汇聚的问题，而对立元数据则是解决数据连贯、资产、治理的问题，对于相当局部的用户而言，以后最大的痛点不是海量数据的存储，而是如何将散落到各个子数据系统的数据孤岛对立管控起来。因而通过构建一个逻辑层面的数据湖，实现对立的元数据 + 扩散的物理存储，防止不必要的物理数据入仓（湖），从而将产品下层性能比方主题域构建、数据地图等等及早给用户应用才是解决问题的基本之道，逻辑数据湖计划，仍然能够应用物理湖 &Hadoop，同时提供通过虚构表直连数据源的计划将其余类型的数据源也纳入平台的管控中，用户能够依据理论的须要抉择适宜的存储计划。
咱们的构建方法论次要分为如下三个大的层面：数据源反对类型：除了 Hadoop（Hive）体系，MPP、RDMS、HTAP、KV、MQ 等都须要反对，并且厚此薄彼，都能够作为具体逻辑数据湖具体对象的物理存储。对立数据源 & 对立元数据：对立数据源要做的是标准每种数据源的登记注册，包含数据源 URL 格局、数据源 Owner、唯一性校验、账号映射、联通性校验、反对的版本、特定的参数等；对立元数据，则是将数据源的技术（物理）元信息和业务元信息进行关联，提供对立的查问批改接口。对立数据开发、治理和查问剖析：这三个属于构建在对立元数据 & 数据源根底之上的应用层。对立的数据开发，包含不同物理数据源之间的替换、离线 & 实时开发、同源 & 跨源查问；对立的数据治理，则包含数据主题建设、权限管控、数据生命周期、资产地图等；对立查问剖析，则是在实现数据主题建设、数据开发产出当前，提供同源 & 跨源的模型剖析能力。
