作者丨石秀峰
今天我们来探讨一下关于数据治理的灵魂三问：
1、数据治理治什么，治的是数据吗？
2、数据治理在哪里治，中台还是后台？
3、数据治理到底怎么治？
一、数据治理 治的是“数据”吗？
数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。其实在我看来，数据可以分为两个部分，一是数字，二是文字。数字是没有意义的抽象符号，数据是有意义的数字。文字表意，数字表量，当两者结合起来，数据就产生了。
在我们的生活和工作当中，数据无处不在。对企业来讲，有很多数据是无关企业重大利益的数据，是没有治理的必要的。数据治理的对象必须是重要的数据资源，是关乎企业重大商业利益的数据资源，这样的数据资源可以称其为“数据资产”。正如北大教授王汉生先生所说：“数据治理不是对“数据”的治理，而是对“数据资产”的治理，是对数据资产所有相关方利益的协调与规范。”
我们需要分开来理解这句话：
①什么是数据资产？
②数据资产的相关利益方是谁？
③协调与规范什么？
先说一说什么是数据资产。我们说不是所有数据都是数据资产，那到底什么才是数据资产呢？
《企业会计准则-基本准则》第20条规定：“资产是指企业过去的交易或者事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。” 如果照猫画虎修改一下，不难获得一个关于数据资产的定义：“数据资产是指企业过去的交易或者事项形成的，由企业拥有或者控制的，预期会给企业带来经济利益的数据资源。”由此可见，数据要成为数据资产，至少要满足3个核心必要条件：
①数据资产应该是企业的交易或者事项形成的；
②企业拥有或者控制；
③预期会给企业带来经济利益。
数据资产的利益相关方是谁？
根据数据资产的定义，数据资产的利益相关方，包括：
①数据的生产者，即通过业务交易或事项产生数据的人或组织。
②数据的拥有或控制者，生产数据的人不一定是拥有数据，就像我们天天上网的各种数据都不归我们自己所有，而是落在了各个互联网公司的数据库中。
③数据价值和经济利益的收益者。数据治理就是对数据生产者、拥有或控制者，数据价值获益者的规范和协调。
都什么是需要协调和规范？
首先是数据的标准化，定义统一的数据标准，“写中国字、说普通话”让数据资产的相关利益方在同一个“频道”沟通。数据的标准化包含几个层面：①数据模型标准化。②核心数据实体的标准化（主数据的标准化）。③关键指标的标准化。
其次是数据的确权。数据一旦成为资产，就一定有拥有方，或者实际控制人，可以把他们统称产权人。与实物不同的是，实物的产权是比较明确的，数据则比较复杂。产品在生产制造过程中，并没有与消费者交易之前，制造商拥有完全产权。产品生产出来后，消费者通过购买支付相应的货币，便拥有了产品的产权。而数据的生产过程就不一样了，我们的各种上网行为每天都会产生大量的数据，例如：网上购物、浏览网页、使用地图、评论/评价……。这些数据到底归谁所有？控制权该如何治理？这是摆在面前的一个难题！我们看到近几年一些不良商家，利用我们的上网数据，导致安全隐私泄密的事件也层出不穷。希望随着技术和商业的进步，尽快能够找到解决方案！
第三是流程的优化。数据治理的两个目标：一个是提质量，一个是控安全。互联网数据的确权目前已经是一个世界级难题，做好企业业务流程的优化可能会对隐私保护起到一定的作用。通过业务流程优化，规范数据从产生、处理、使用到销毁的整个生命周期，使得数据在各阶段、各流程环节安全可控，合规使用。另外，通过一定的流程优化，通过对相关流程进行监管，按照数据的质量规则进行数据校验，符合“垃圾进、垃圾出”的数据采集、处理、存储原则，提升数据治理，赋能业务应用。
二、数据治理 到底在哪里治？
数据治理到底应该放在中台，还是后台，我个人的理解是：小数据标准化治理靠人工、大数据预测性分析靠智能，将两者结合起来：“人工 智能”形成了完整的数据治理技术体系。一个企业的数据治理既离不开小数据的标准化治理，也离不开大数据的预测性分析。
这里的小数据，是在承载事物实体的数据，例如：人、财、物等，是企业所有业务开展的载体。其实说白了就是主数据管理。对于主数据的治理笔者认为是一个后台行为，治理核心是“唯一数据源、统一数据标准”，而要达到这一目标是需要从数据的源头抓起的，并且需要大量的人为干预，比如：数据标准的制定和落实，数据质量的清洗，数据的申请审批，数据的分发和共享等。从这里也能够看出小数据的治理，追求的是标准化、精确化，应该是一个后台行为。
而在大数据时代，得益于大数据技术的突破，大量的结构化、非结构化、异构化的数据能够得到储存、处理、计算和分析，这一方面提升了我们从海量数据中获取知识和洞见的能力。对于大数据，传统的一味追求精确的思维受到了挑战。而对于大数据的治理，允许一定程度上的容错，反而可以在宏观层面拥有更好的知识和洞察力。对于大数据的治理更多的是采用AI技术，例如：知识图谱、语音识别等，对大数据的采集、处理、使用过程加以控制，使其能够合规使用。所以，大数据的治理放在中台似乎更为合适。
三、数据治理 到底应该怎么治？
1、找症状，明确目标
任何企业实施数据治理都不是为了治理数据而治理数据，其背后都是管理和业务目标的驱动。企业中普遍存在的数据质量问题有：数据不一致、数据重复、数据不准确、数据不完整、数据关系混乱、数据不及时等。
由于这些数据问题的存在对业务的开展和业务部门之间的沟通造成了较大的困扰，产生了很大的成本；各异构的系统中数据不一致，导致业务系统之间的应用集成无法开展；数据质量差无法支撑数据分析，分析结果与实际偏差较大。然而要实现数据驱动管理、数据驱动业务的目标，没有高质量的数据支撑是行不通的。
目标：企业实施数据治理的第一步，就是要明确数据治理的目标，理清数据治理的关键点。
技术工具：实地调研、高层访谈、组织架构图。
输入：企业数据战略规划，亟待解决的业务问题，经营发展需求，业务需求等；
输出：数据治理的初步沟通方案，项目任务书，工作计划表；
2、理数据，现状分析
针对企业数据治理所处的内外部环境，从组织、人员、流程、数据四个方面入手，进行数据治理现状的分析。
某企业数据治理痛点分析
组织方面：是否有专业的数据治理组织，是否明确岗位职责和分工。
人员方面：数据人才的资源配置情况，包括数据标准化人员、数据建模人员，数据分析人员，数据开发人员等，以及数据人才的占比情况。
流程方面：数据管理的现状，是否有归口管理部门，是否有数据管理的流程、流程各环节的数据控制情况等；
数据方面：梳理数据质量问题列表，例如：数据不一致问题，数据不完整，数据不准确、数据不真实、数据不及时、数据关系混乱，以及数据的隐私与安全问题等。
目标：分析企业数据管理和数据质量的现状，确定初步数据治理成熟度评估方案。
技术工具：实地访谈、调研表、数据质量问题评议表、关键数据识别方法论（例如：主数据特征识别法）；
输入：需求及现状调研表、访谈记录、数据样本、数据架构、数据管理制度和流程文件；
输出：数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估方案；
3、数据治理成熟度评估
数据治理成熟度反映了组织进行数据治理所具备的条件和水平，包括元数据管理、数据质量管理、业务流程整合、主数据管理和信息生命周期管理。
CMMI DMM数据管理能力成熟度评估模型
数据治理成熟度评估是利用标准的成熟度评估工具结合行业最佳实践，针对企业的数据治理现状进行的客观评价和打分，找到企业数据治理的短板，以便制定切实可行的行动方案。数据治理成熟度结束后形成初步的行动方案，一般包括数据治理战略，数据治理指标，数据治理规则，数据治理权责。数据治理愿景和使命是数据治理的整体目标；数据治理指标定义了数据治理目标的衡量方法；数据治理规则和定义包括与数据相关的政策、标准、合规要求、业务规则和数据定义等；权利和职责规定了由谁来负责制订数据相关的决策、何时实施、如何实施，以及组织和个人在数据治理策略中该做什么。
目标：结合业界标准的数据治理成熟度模型，根据企业管理和业务需求进行数据治理成熟的评估，形成初步的数据治理策略和行动路线。
技术工具：数据治理评估模型，例如：DCMM，CMMI DMM，IBM数据治理成熟度评估模型等；
输入：第2步的输入以及数据治理评估模型、数据治理评估工具（评估指标、打分表等）；
输出：数据治理评估结果，数据治理策略，初步的行动方案；
4、数据质量问题根因分析
数据治理的目的是解决数据质量问题提升数据质量，从而为数据驱动的数字化企业提供源动力，而提到数据质量问题，做过BI、数仓的同学一定知道，这是一个技术和业务“经常打架”相互推诿的问题。
某企业数据问题根因分析鱼骨图
产生数据质量问题的原因有很多，有业务方面的、有管理方面的、也有技术方面的，按照80/20法则，80%的问题是由20%的原因造成起的。所以，如果能够解决这20%的问题，就能得到80%的改进。
目标：分析并找到数据质量问题产生的根本原因，制定行之有效的解决方案；
技术工具：头脑风暴、5W1H、SWOT、因果（鱼刺）图、帕拉图等；
输入：数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估结果；
输出：数据质量评估结果、对业务的潜在影响和根本原因。
5、业务影响及实施优先级评估
通过数据治理成熟度评估，从组织、流程、制度、人员、技术等方面找到企业在数据治理的待提升的领域和环节，再通过数据质量根因分析找到数据质量问题发生的根本原因，进一步明确了数据治理的目标和内容。再接下来，就需要确定数据治理策略，定义数据治理的实施优先级。
某企业主数据治理实施优先级评估
不同的数据治理领域解决的是不同的问题，而数据治理的每个领域都有它的实施难点，对企业来说，需要从业务的影响程度，问题的紧急程度、实施的难易程度等多个维度进行分析和权衡，从而找到符合企业需求并满足企业发展的方案。
目标：确定数据治理核心领域和支撑体系的建设/实施优先级；
技术工具：四象限法则（分别从业务影响程度/实施难以程度，问题重要程度/问题紧急程度绘制优先级矩阵）、KANO模型
输入：数据治理成熟度能力评估结果、数据质量问题根因分析结果；
输出：数据治理实施优先级策略
6、制定数据治理行动路线和计划
路线图是使用特定技术方案帮助达到短期或者长期目标的计划，用于新产品、项目或技术领域的开发，是指应用简洁的图形、表格、文字等形式描述技术变化的步骤或技术相关环节之间的逻辑关系。路线图是一种目标计划，就是把未来计划要做的事列出来，直至达到某一个目标，就好像沿着地图路线一步一步找到终点一样，故称路线图。
某企业数据治理实施路线图
企业数据治理的实施路线图的制定是以企业数据战略——愿景和使命为纲领，以急用优先为原则，以分步实施为策略进行了整体设计和规划。实施路线图主要包含的内容：分几个阶段实施，每个阶段的目标、工作内容、时间节点要求、环境条件等。笔者观点：任何一个企业的数据治理都不是一蹴而就，一步到位的，需要循序渐进、持续优化！实施路线图就是基于此产生的，因此说数据治理实施路线图也是说服利益相关者支持的一个重要手段。
目标：确定数据治理的阶段以及每个阶段的目标；
技术工具：路线图法
输入：数据治理成熟度能力评估结果、业务影响及实施优先级评估结果；
输出：数据治理实施路线图或称阶段目标计划
7、制定数据治理详细实施方案
数据治理详细实施方案是用于指导主数据的各项实施工作，一般包括：数据治理核心领域、数据治理支撑体系、数据治理项目管理三个方面。
数据治理总体框架图
数据治理核心领域包括：数据架构、数据服务、元数据管理、数据质量管理、数据标准管理、主数据管理、数据安全管理、数据生命周期管理。
数据治理支撑体系包括：组织（组织架构、组织层次、岗位职责）、制度（管控模式、规章制度、考核机制）、流程（归口部门、管理流程、流程任务等）、技术（数据集成、数据清洗、数据开发、数据应用、数据运营、支撑平台、实施方案等）。
数据治理项目管理方案包括：项目组队、项目计划、质量保证计划、配置管理计划、培训和售后等。
关于数据治理的核心领域，详见笔者之前分享的数据治理框架解读系列文章。
关于数据治理的支撑体系，详见笔者之前分享的数据治理成功关键要素系列文章。
目标：基于数据质量根因分析、业务影响和实施优先级评估结果，制定详细实施方案；
输入：业务影响及实施优先级评估结果，行动路线和计划；
输出：数据治理详细实施方案。
8、数据治理实施过程控制
数据治理实施过程控制是对数据治理项目的范围控制、进度控制、质量控制和成本控制，通过对企业的各项资源的合理协调与利用，而达成的数据治理目标的各种措施。从项目管理的角度来讲也是项目管理的黄金三角：范围、时间、质量、成本。
任何项目的质量和进度是需要良好的项目管理来保证的，数据治理也一样。与传统的软件工程项目不同，数据治理项目有着范围边界模糊、影响范围广、短期难见效、实施周期长等特点：
①范围边界模糊，数据治理涉及到的关键领域如元数据管理、数据质量管理、数据标准管理、主数据管理等很多是存在交叉的，边界很难界定，例如：实施数据质量管理项目，会涉及元数据管理、数据标准管理等，同样一个元数据管理项目也会涉及数据标准和数据质量。
②影响范围广，数据治理的实施不是一个部门能够完成的，是需要从高级管理层、到各业务部门、信息部门通力协作，共同完成的；
③短期难见效，数据治理项目实施完成后，其数据治理的效果被每个业务点滴操作所“稀释”，并不像其他项目，例如BI，那样明显的体现出来，所以主导数据治理的部门会经常遭到质疑。
④实施周期长，在没有清晰的数据治理目标和范围约定的情况下，数据治理是一个“无底洞”。所以，在实施数据治理项目之前制定好实施路线图和详细的实施方案就显得格外重要（第6、7步）。
目标：通过对数据治理项目实施过程的进度控制、质量控制和成本控制以实现数据治理的目标；
技术工具：PP（项目计划）、PMC（项目控制）、IPM（集成项目管理）、RSKM（风险管理）——CMMI过程域；
输入：6-7步的输出：数据治理实施路线图，数据治理详细实施方案；
输出：各项项目控制措施，例如：项目计划、SOW、项目风险列表、项目报告、项目总结等；
9、监控评估数据治理实施效果
随着大数据技术的不断发展，应当从企业的全局数据治理环境的角度，明确数据治理关键技术运用及其标准规范，构建成效评估指标体系，进行治理效果评价；并运用数据治理能力成熟度模型再次评估，界定数据管理层次，从而使得跨系统、跨业务、跨部门的数据治理体系的建设与实施能够通过各方协作顺利进行，实现卓越数据治理，进而通过数据驱动业务、数据驱动管理和运营以实现企业的降本、增效、提质、创新。
某企业数据治理看板（数据已脱敏）
数据治理成效评估指标体系应根据企业及数据治理项目的实际情况制定，一般包括：时间性、数量性、完整性、准确性四个维度。
①时间性即数据的及时性。该维度主要通过源业务系统数据接入的上报及时性、接入及时性等方面进行核对。通过分析月指标、周指标、日指标的数据及时率，得出在规定时间和频度周期内接入系统的比例，以此反映数据接入及时性。
②数量性。该维度是从数据存量，数据增量，数据访问量，数据交换量、数据使用量等指标反映数据的使用情况，可以分为月度指标、周指标、日指标、时分指标等。
③准确性。这个维度主要由各类数据中逻辑的准确性、数据值的准确性、数据频段和字段之间的准确性以及数据的精度等内容组成。该准确率同样包括：月度、每周、每日等准确率指标。
④完整性。此维度主要以单元维度完整性、数据业务维度组合完整性、索引值完整性等不同方面进行核对，是验证数据质量完整性的主要组成部分，包括月度指标、周指标、日指标数据的完整性等内容。
目标：检验各项数据治理指标的落实情况，查漏补缺，夯实数据治理效果；
技术工具：数据治理效果的评价指标体系、各种数据图表工具；
输入：数据治理效果评估指标；
输出：数据治理评估的月报、周报、日报等；
10、数据治理持续改进
数据治理模式应业务化、常态化，不应是一个项目、“一阵风”的模式。
数据治理工作应向企业生产、销售业务一样作为一项重点的业务工作来开展，构建专业的数据治理组织，设置合适的岗位权责，建立相应的管理流程和制度，让数据标准贯彻到每个业务环节，形成一种常态的工作。在笔者看来，在数据源头加强企业数据的治理，让常态化治理成为日常业务，才能从根本上彻底解决企业数据质量的各种问题，让数据真正转化为企业资产，以实现数据驱动流程优化、数据驱动业务创新、数据驱动管理决策的目标。
目标：数据治理常态化，持续提升数据质量，驱动流程优化和管理创新。
输入：持续的、规范的、标准的各项业务操作；数据治理监控的各项指标和报告；
输出：持续输出的高质量的数据。
四、美团配送数据治理实战
从大的阶段来看，数据治理主要分为存量数据“由乱到治”的阶段，以及增量数据严格按照规章制度实施确保“行不逾矩”的运营阶段。在“由乱到治”的过程中，我们需要沉淀出规章制度、标准规范，以及辅以规章制度标准规范实施的工具和组织。在增量数据的运营阶段，我们主要靠对应的组织确保规章制度的落实，通过审计定期考察实施效果，并在长期的运营中不断完善规章制度。在实现存量数据“由乱到治”的阶段，我们主要采取了“两步走”策略，具体执行策略如下所示。
4.1 定标准，提质量
4.1.1 业务标准
业务标准主要是指标的管理和运营标准，我们主要解决三个问题：指标由谁来定义，指标该如何定义，指标该如何运营。基于这三个问题，我们同时提出了三条原则：
- 业务团队负责指标的定义。
- 产研商分负责给出指标定义标准和辅助工具，辅助业务团队完成指标的规范定义，达成指标认知一致性这一目标。
- 最后由指标管理委员会负责指标的管理与运营，保障指标从创建、审核、上线以及到最后消亡的整个生命周期的运营。
为统一指标的定义，我们将指标分为原子指标、衍生指标和派生指标，原子指标通过限定条件和时间的限定生成衍生指标。衍生指标间的“四则混合运算”构成了派生指标。我们不但制定了指标的标准定义，还对其做了准确的资产归属，一个指标出自一个具体的业务过程，一个业务过程归属于不同的数据域，多个数据域构成了美团配送业务线下的分析场景，如下图所示：
指标定义标准
4.1.2 技术标准
这里所说的技术标准，主要是针对数据RD提出的建模标准和数据生产规范，通过建模标准来明确数仓分层架构，并清晰定义每一层的边界与职责，采用维度建模的设计理念。我们的整个仓库架构分为四层：操作层、基础事实层、中间层和应用层，并在每一层同步制定对应的建模规范，如下图所示：
数仓架构以及建模标准
除了建模标准外，我们还制定了涵盖从生产到运维环节的生产规范以保障模型的质量，主要包括上线前的模型评审、生产过程中的完成元数据配置、DQC、SLA和生命周期设置以及上线后的日常运维机制等等。尤其针对元数据管理和生命周期管理，我们分别制定了仓库每一层元数据维护规范和生命周期管理规范，其中元数据管理规范，是依据数仓各层级中各种类型表的建模标准来制定，需要做到规范命名，明确数据归属，并打通业务元数据和技术元数据之间的关系。而生命周期管理规范，是依据配送业务特点和数仓各层级现状来制定的，如下表所示：
仓库各层元数据管理标准
仓库各层生命周期管理策略
4.1.3 安全标准
围绕数据安全标准，首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。
安全标准建设
4.1.4 资源管理标准
在资源管理方面，配送技术工程部已经对资源管理涉及的内容进行了合理抽象和准确定义，抽象出租户、资源和项目组等概念。不管是后续的资源预算还是资源管理，我们都需要基于租户和项目组来进行运营，因此，对于业务团队而言，我们只需要将租户和项目组特定职能划分清楚，然后根据不同的职能归属我们的资产，并分配生产该资产所需要的资源。为了方便后续的运营，我们对每个租户和项目组分配确定了责任人，由责任人对运营结果负责。
对业务部门来说，资源管理的关键是对数据资产做清晰的分类，基于数据的分类划分不同的租户和项目组，将数据和租户、项目组实现一一映射。由于租户和项目组都有特定的责任人对其负责，因此，我们通过这种映射关系，不仅实现了资产的隔离，还实现了资产确权（项目组负责人同时对资产负责和运营）。我们整体将数据分为两大类，一是原始数据，包括流到数据中心的数据和日志中心的数据，针对流入数据中心的数据，根据其产生的方式不同，又进一步分为业务数据和流量数据。二是加工数据，对应着数据团队的仓库建设和其他团队的集市建设。基于上述的描述，针对资源管理，我们做了如下划分和确权：
资源划分与管理
4.2 重实施，保落实
第二步，落实第一步的标准，完成数据治理第一阶段的目标，实现存量数据“由乱到治”，并完成相应组织和工具的建设，为实现第二阶段“行不逾矩”这一目标提供工具和组织能力。在此过程中，主要分成三个方面的治理工作：第一，架构模型“由乱到治”的治理，消除模型冗余、跨层引用和链路过长等问题，在架构上保证模型的稳定性和数据一致性；第二，元数据“由乱到治”的治理，实现指标的标准定义、技术元数据的完整采集并建立指标与表、字段的映射关系，彻底解决指标认知一致性，以及用户在使用数据过程中的“找数难”等问题；第三，围绕着隐私安全和共享安全加强数据的安全管控来实现数据走不脱、拿不走，以及隐私数据看不懂这一目标。
4.2.1 架构治理
总结起来，架构方面的治理主要是解决两个问题：第一，模型的灵活性，避免需求变更和业务迭代对核心模型带来的冲击，让RD深陷无休止的需求迭代中；第二，数据一致性，消除因模型冗余、跨层引用等问题带来的数据一致性问题。
模型灵活性
配送解决的是效率、成本和体验三者之间的平衡问题，即在满足一定用户体验的条件下，如何提升骑手配送效率，服务更多的商家，以及如何管控骑手，降低配送成本。抽象到数据层面，基本上反映为上游包裹来源的变化、配送对外提供服务的变化以及对内业务管控的变化。为屏蔽业务迭代给核心模型带来的冲击，我们通过对外封装包裹属性和对内封装运单属性，抽象出包裹来源、提供服务、业务架构等一致性维度，任何业务迭代在数据层面只涉及维度的调整，大大降低了对核心模型冲击和“烟囱式”数据建设问题（新来一个业务，就拉起一个分支进行建设）。
包裹事实分配到运单明细构造单一运单模型
配送指标体系建设的一个重点就是要输出各组织层级的规模、体验和效率指标，实现对运力的有效管控，运力所属组织的层级关系会随业务的迭代而不断变化。为了适应这种变化，避免仅仅因增加维度带来中间层数据的重复建设，我们将组织层级维表由固定层级建模方式调整为桥接表的方式来自适配组织层级变化，从而实现了中间层模型可以自动适配组织层级的变化，能自动产生新维度的指标。如下图所示：
桥接表自适配组织层级灵活变动
在精细化分析的场景下，业务会有分时段、分距离段以及分价格段的数据分析诉求。我们以分时段为例，有晚高峰、午高峰、下午茶等不同的分时段，不同的业务方对同一个时段的定义口径不同，即不同的业务方会有不同的分时段策略。为解决该场景下的分析诉求，我们在事实表中消除退化维度，将原来封装到事实表的时段逻辑迁移到维度表中，并将事实表中的时间进行按特定的间隔进行刻度化作为维表中的主键，将该主键作为事实表的外键。这样，针对业务不同的时间策略需要，我们就可以在维表中进行配置，避免了重复调整事实表和反复刷数的问题。即通过将时间、价格、距离事实刻度化，实现灵活维度分析。如下图所示：
通过将时间刻度化，实现灵活分析
数据一致性
数据一致性得不到保障的一个根本原因，是在建模的过程中没有实现业务口径标签化，并将业务口径下沉到主题层。很多同学在基于需求进行开发时，为实现方便，将新指标口径通过“Case When”的方式在应用层和中间层进行封装开发，主题层建设不能随着业务的迭代不断完善，RD在开发过程中会直接引用仓库的快照表在中间层或应用层完成需求开发。久而久之，就会造成数据复用性低下，相同指标的口径封装在不同的应用表来满足不同报表的需求，但随着应用的增多，很难保障相同指标在不用应用表封装逻辑的一致性，数据一致性难以得到保障，同时这种方式还带来两个严重后果：第一，跨层引用增多，数据复用性低下，造成计算和存储成本的浪费；第二，一旦指标口径发生变化，将是一个“灾难”，不仅影响评估是一个问题，而且涉及该指标的应用层逻辑调整对RD来说也是一个巨大的挑战。
治理前模型架构
因此，我们在“由乱到治”的治理过程中，以衍生事实的方式实现业务口径标签化，将业务逻辑下沉到主题层，消除跨层引用和模型冗余等问题，从技术层面保障数据一致性是该阶段架构治理的重点。我们在业务上，已经划分了严格的数据域和业务过程，在主题建设层面，将业务划分的数据域作为我们的主题，并基于业务过程进行维度建模，将属于该业务过程的指标口径封装在对应业务过程下的衍生事实中。
治理后模型架构
4.2.2 元数据治理
元数据治理主要解决三个问题：首先，通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；其次，基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；第三，通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。
首先，为保障业务标准的顺利实施，实现业务对指标认知一致性这一目标。我们协同产研、商分、业务部门推动成立了度量衡委员会，并建立起指标运营机制，通过组织保障来实现指标运营按照规范的标准和流程实施。如下图所示：
指标注册流程
其次，基于配送业务的现状和未来演进方式，我们进行了高度的业务抽象，完成了主题、业务过程和分析方向等元数据内容的建设。配送即物流，通过线上系统和线下运营，我们将用户的配送需求和美团的运力进行有效的资源配置，实现高服务体验、低成本的配送服务。对外，我们将配送服务通过平台化的方式，提供给用户、商户和电商平台，以满足不同用户在不同业务场景下的配送需求。对内，我们通过不同的调度模式将运单池中的运单调度给合适的骑手来完成履约，平衡规模、成本和体验之间的关系。如下图所示：
配送业务模式抽象
基于以上的业务模式，我们划分了运单主题（对履约数据域下的数据进行构建，支撑规模和体验的数据分析需求）、调度主题（调度数据域下产生的数据，用于支撑调度策略的分析）、结算、评价、投诉、取消主题（用于支撑体验、成本数据分析需求）和管控主题（用于支撑运力奖惩、违规和招募分析需求）等各种主题，并在每个主题下划分对应的业务过程，在应用层制定分析方向的分析标签，通过对元数据内容的建设完成对业务的抽象，为物理模型的刻画准备了基础数据。
第三，元数据服务建设，我们打通了元数据从采集到构建再到应用的整条链路，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”难题。在整个建设过程中，我们围绕着元数据采集、元模型构建、元数据服务以及最后的产品应用进行展开，整体架构如下图所示：
元数据建设架构图
元数据采集
元数据采集分为人工录入和自动抽取，通过人工录入的方式实现物理表的准确归属（包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等）以及指标的采集，从而完成技术元数据和业务元数据的采集，通过自动抽取的方式完成生产元数据的采集和使用元数据的采集，主要包括：物理模型的依赖关系、存储占用、热度、等信息。
元模型构建
分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，为其加上了物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。血缘元模型以血缘为中心，不仅构建了从上游业务表到仓库离线表的物理血缘，而且打通了仓库离线表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础。
元数据服务
统一元数据服务（OneService），主要提供两类元数据服务，提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。
元数据应用
主要孵化出了三个产品，以“找数、理解数、影响评估”为应用场景的数据地图（Wherehows），以“取数、数据可视化”为应用场景的数据可视化（QuickSight），以及以管理审计为目的的管理审计报表。
4.2.3 安全治理
安全治理主要加强了敏感数据的安全治理和数据共享环节的安全治理。通过对隐私数据的安全治理，不仅要保证其在存储环节的不可见性，而且还要保证在其使用环节对用户进行双重鉴权，字段的密级鉴权和解密的密钥鉴权；通过对数据共享环节的安全治理，我们在数据分级分类的基础上，使数据的权限控制从表级权限控制扩展到行级权限控制。
敏感数据安全治理
敏感数据的安全治理，主要是解决敏感数据的存储安全和使用安全。离线场景下，敏感数据存储安全要解决两大挑战：
- 确保仓库侧处理方案既要屏蔽上游业务系统变动带来的影响，又要屏蔽自身策略对下游BI系统的影响。
- 要避免敏感数据在整个加工链路中的扩散。
因此，为解决仓库处理方案与上游业务系统和下游BI系统的解耦问题，我们在上游敏感数据落到ODS环节，确保落到ODS层的敏感数据必须是明文，为保障其安全，对ODS层的所有数据进行文件加密，但是在使用层面，对下游链路透明保障下游链路的正常生产，并限制ODS层数据权限的开放。
ODS层数据只用于安全生产，通过此方案既屏蔽了上游处理方案对仓库的影响，又解决了敏感数据的安全问题。当数据从离开仓库时，在传输环节对敏感数据进行可逆操作，将敏感数据以明文的形式推入BI库，实现与下游BI系统的解耦。为解决敏感数据在整个生产链路的扩散，我们在快照层对敏感数据进行脱敏处理，从快照层开始消除敏感数据，为保障敏感数据的可逆性，将ODS层的敏感数据抽取到安全库中并进行加密存储，实现安全独立管理。具体执行如下图所示：
针对敏感数据的使用安全，我们通过对敏感字段的权限控制和对解密密钥的权限控制，来实现敏感数据使用安全这一目标。针对单独抽取的敏感数据，我们除了针对敏感数据设置其相应的密级确保敏感数据的权限管控外，还基于"暗语"的加密方式为每个项目组分配一个相同的密钥，并且将该密钥存放到与Hadoop集群集成的KMS进行管理（确保支撑离线计算的高并发），确保解密时实现密钥的权限管控。
共享环节安全治理
针对共享环节的安全治理，我们主要是在数据生产环节完成数据的分级分类和数据确权，在数据的使用环节完成数据的表级权限控制和行级权限控制。确保数据在使用环节规范的审批流转，权限开放以后的安全审计，保证数据走不脱。
首先，我们在生产环节B3、B2、B1层数据按照主题或实体C层数据按照应用方向进行逻辑划分，并设定资源的密级和权限负责人。特别地为实现B3层数据在查询环节可按照业务线进行权限管控这一目标（即行级鉴权），针对B3层数据，我们标记该数据需要在查询环节进行行级权限管控，标记使用行级鉴权所需的字段和该字段对应的枚举值。
其次，在使用环节，我们按照资产密级和使用人角色完成数据的审批流转，实现数据的安全共享。
第三，针对B3层数据，审计是否设置了行级权限管控。在数据开放时是否存在越权使用的情况，以及针对即将离职员工加强数据的使用审计，保证数据走不脱。
在数据“由乱到治”的治理过程中，我们不仅实现了存量数据的“由乱到治”，并且在此过程中沉淀出了一系列的建模方法论、工具，并建立了相应的安全小组和指标运营组织。同时，我们为后续增量数据治理确保数据建设“行不逾矩”，提供了强有力的组织保障、稳定的辅助工具和严格的执行标准。在数据治理的第二阶段实现增量数据的“行不逾矩”的过程中，我们主要围绕大数据架构审计、大数据安全与隐私管理审计、大数据质量管理审计和大数据生命周期管理审计这四方面的工作展开，保障治理工作的持续进行，不断提高了组织的治理水平。
5. 工具简介
5.1 数据地图（Wherehows）
数据地图作为元数据应用的一个产品，聚焦于数据使用者的“找数”场景，实现检索数据和理解数据的“找数”诉求。我们通过对离线数据集和在线数据集的元数据刻画，满足了用户找数和理解数的诉求，通过血缘图谱，完成物理表到产品的血缘建设，消除用户人肉评估的痛苦。
离线数据场景
1. 关键字检索和向导查询共同解决了“找数据”的问题：大部分的检索数据场景下，数据使用者都可以通过关键字检索来得到匹配结果。剩下的一小部分场景，例如，对于新人入职后如何了解整个数仓和指标的体系（数仓分几层，每层解决什么问题，都孵化出什么模型；整个指标、维度体系都是怎么分类，有哪些指标和维度），这部分场景可以使用向导查询功能。向导查询相当于分类查询，将表和指标按照业务过程进行分类，用户可以按照分类逐步找到想要的表或指标。
2. 我们打通了业务元数据和技术元数据之间的关系，提高了“找数据”的能力：通过“Wherehows”查找到指标后，不仅不可查看指标的业务定义，还能查看指标的技术实现逻辑，指标在哪些维度或维度组合中已经实现，并且能够在哪张表里找到这些维度，或维度组合的指标数据。反之，也可以知道在某个维度下已经实现了哪些指标，对应的指标在哪些表里。这些功能能让用户更加方便地找到想要的数据。
3. 我们提供了较为完善的数据信息，帮助用户更好理解数据：对于表的信息，“Wherehows”除了提供表和字段的中英文名称、描述信息等基础信息外，为了帮助用户更好地理解表的建设思路，我们还提供了表的星型模型（可以关联的一致性维度及对应的维度表）、表的血缘关系等信息。
4. 我们通过评论问答功能，帮助用户可以快速得到问题反馈：如果用户看了信息后还是感到有问题，“Wherehows”提供评论问答的功能，用户通过这个功能可以进行提问，会有相应的负责人进行回复。对于重复问反复问的问题，用户通过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里，不断地对元数据进行补充和完善。
业务数据场景
业务数据场景主要想解决的一个问题是，如何知道一个业务表（MySQL表）有没有同步到数仓。如果没有同步，能够找谁进行同步。因为已经打通“业务表 -> 数仓表 -> 产品”三者之间的血缘关系，我们能够轻松解决业务数据场景的问题。
生产评估场景
在日常数据生产工作中，我们经常需要对表进行影响评估、故障排查、链路分析等工作，这些工作如果靠纯人工去做，费时费力。但现在我们已经打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系，就能够在10分钟内完成评估工作。对于不同的场景，血缘链路提供了两个便捷的功能：过滤和剪枝。例如，某个表逻辑需要修改，需要看影响哪些下游表或产品？应该要通知哪些RD和PM？这种情况下，血缘工具直观地显示影响了哪些负责人和产品，以及这个表的下游链路。
有些表的链路很长，整个血缘关系图很大，这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能，对于没用的、不想看到的分支可以剪掉，从而让整个链路变得更加直观。
5.2 数据可视化（QuickSight）
聚焦于数据使用者“取数”场景，使用QuickSight，用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所得的方式，满足了用户对业务核心指标的二次加工、报表和取数诉求。首先，我们通过指标池、数据集等概念对离线生产的指标进行逻辑隔离，针对不同用户开发不同的数据集以达到权限控制的目的，如下图所示：
用户、指标池与数据集间的关系
其次，我们为用户提供一系列的组件，帮助用户基于为其开放的数据集实现指标的二次加工和数据可视化功能，满足其在不同业务场景下的取数和可视化应用。如下图所示：
指标加工组件
6. 总结与展望
经过三个阶段的治理工作，我们在各个方面都取得了较好的效果：
- 在数据标准方面，我们制定了业务标准、技术标准、安全标准、资源管理标准，从而保障了数据生产、管理、使用合规。
- 在数据架构方面，我们通过桥接表、时间刻度化、业务口径下沉等手段提升模型灵活性，并保障数据一致性，消除跨层引用和模型冗余等问题。
- 在数据安全方面，我们加强了对敏感数据和数据共享环节的安全治理，保证数据拿不走、走不脱，隐私数据看不懂。
- 在元数据建设方面，我们打通了从采集到构建再到应用的整条链路，并为数据使用人员提供数据地图、数据可视化等元数据应用产品，帮助他们解决了“找数”、“取数”、“影响评估”等难题。
未来，我们还会继续通过组织、规范、流程等手段持续对数据安全、资源利用、数据质量等各方面进行治理，并在数据易用性上下功夫，持续降低用户的数据使用成本。
- 在数据架构方面，随着数据库技术的飞速进步，现在已经有很多数据库能够支持千万级乃至亿级数据的现算先用，我们也在尝试使用这些数据库帮助提升数据开发效率，改善数仓分层管理和应用支撑效率。
- 在数据产品方面，我们将持续完善数据地图、数据可视化等数据应用产品，帮助用户快速探查、高效分析，真正发挥数据的业务价值。
