一、背景及问题

　　模型建设的要求主要有三个方面：效率快、成本省、质量稳。

　　模型要能够快速地开发和使用，因为数据具有实效性，如果数据不能快速地产出和消费，它带来的价值就会受到影响；

　　模型设计要考虑数据成本带来的影响，近几年有很多企业在做成本治理，模型也有节省成本的诉求；

　　数据质量要有保障，包括数据的准确性和稳定性等。

　　结合多年的数据模型开发和管理经验，总结了四个“1”：

　　一套规范体系，要有一套方法论来支撑如何构建模型、如何使用模型。

　　一套评估体系，要衡量数据的价值是比较难的，但模型构建的好坏要有一套评估体系去支持我们了解模型的现状以及它构建的健康程度。

　　一个增量管控，在模型的开发和管理过程中要有管控措施保证模型能够健康、快速地上线。

　　一个存量治理能力，模型经过一段时间之后需要进行迭代，所以存量治理能力非常重要。

　　大淘宝为什么要做模型治理？有两个关键的时间点：

　　第一个节点是2020年，大淘宝做了很多数字化运营的工作，在工作过程中有很多角色参与进来，早期只有核心用数据的人员：数据开发和分析师，后来很多工程、算法、产品、运营等人员都参与到数据的开发和使用中，角色变多了；

　　另一个关键节点是2022年，我们在2020~2022年做了很多的成本治理工作，但是2022年大淘宝还是出现了几个问题：

　　数据规模始终在膨胀。

　　出现了一些稳定性问题，因为很多数据需要强保障，其稳定的产出和较高的质量是比较重要的。

　　我们发现随着数据量的增长，模型的消费效率在逐渐降低。

　　基于上述背景，我们启动了大淘宝模型治理。

　　模型具体出现的问题包括：

　　① 上图中可以看到大淘宝在2020-2022年数据规模的增长，有一个比较大的跳变。

　　② 很多数据是无效数据，线上使用过程中我们发现有很多数据90天都没有访问，另外一些线上节点也是没有消费的。如果其占比太高就会带来很多问题，例如成本、运维问题，另外规模过大的情况下找到高质量的数据也会存在很大挑战。

　　③ 很多模型在迭代过程中无人负责，未归属表占比高达16%，如果其中大部分都是无效表其实还好，但是我们发现这些未归属表中有12% 仍在使用。

　　④ 很多非数据研发角色的同学在数据模型的开发和使用过程中出现了不规范的问题。

　　集团内部数仓分为三层：

　　① 第一层是来源表即贴源层，数据从底层的MySQL、HBase等数据库直接同步到计算平台ODPS。

　　② 第二层是最核心的公共层，它承载的使命就是复用的数据，例如交易、会员等，它的维表、事实表、汇总表都会沉淀下来，以帮助下游更好地实现消费和口径的统一。

　　③ 第三层是应用层，偏向分析和使用场景，比如一些分析决策场景及产品数据，所以应用层是面向终端消费的。

　　其中的问题如下：

　　① 公共层的引用不足，应用层大量自建中间表。我们用两个核心指标去看：

　　公共层复用率存量不足40%，新增不足20%，也就是说模型对下游的复用是不够高的。

　　公共层覆盖率非常低，只有15%，覆盖率是把公共层作为一个整体单元来服务整个下游应用层及一些探查类数据的，所有服务的下游表的总量消费公共层表的占比，代表公共层对下游的服务能力。

　　再看应用层，它的开发应该依赖公共层的一些数据，但是我们发现重要的DWS，其覆盖率存量不足30%，新增不足10%，很多应用层的关键数据没有引用公共层开发的数据。

　　应用层引用底层来源表的占比是24%，比例非常高，而公共层只有15%，很多是直接基于最源头的数据开发的。

　　应用层自建中间表高达46%，它不直接被下游消费，只是中间过程表，意味着有很多重复的构建和一些该下沉的数据没有下沉。

　　② 来源表也有一些问题：

　　来源表在几百个空间里都有分布，其实应该收敛到一些可控的空间里；

　　来源表会被重复导入，理论上底层的这些数据只需要同步一份就好，但是我们发现因为工具的便捷性，导致大量重复同步。其实我们也设计了一个TBODS空间，目的是把整个淘宝的ODS数据收敛起来，但是我们发现只有9%的来源表，收敛比例是非常低的。

　　在决策看数、业务洞察、数据产品几大核心板块里，缺乏统一的数据架构规范，例如数据的分层占比、命名规范引用情况都不是很理想；公共层早期偏向于支持决策型数据，缺乏对业务分析型数据的建设，数据的消费效率不高。

　　二、解决方案

　　针对上述问题，要找到治理模型的解决方案，首先要分析一下问题原因。

　　一部分是因为规范的机制没有保障，例如数据交接应该做哪些流程管控，也没有对于非数研同学或者其他角色的规范。

　　在数据建设过程中也忽略了一个核心点就是我们建的数据到底好不好，一方面我们建的公共层运营不足，另一方面它偏向于稳定，所以迭代不够，导致下游消费时很多团队自己去建设。

　　另外，数据导入缺乏管控，无效表无人治理，缺乏有效的产品工具提效。

　　我们的解决方案的基础是前文提到的四个“1”的治理能力，包括数据体系规范、模型评估体系、模型管控，以及模型治理四大方面。

　　基于这四大能力，我们的核心治理策略为：

　　提高优质数据供给，包括规范培训推广，让大家更好地理解和使用；构建完数据后通过专辑的方式使其能够快速上架，让下游看到数据；专辑配备好说明和引导以帮助大家更好的理解。

　　消费提效方面，对核心数据做专辑的上下架和运营宣讲；检索数据时快速推荐高质量数据，同时做一些引导，比如在申请权限时，申请的是一张底层表，而公共层已经有比较高质量的表，就可以在权限审批时引导他去申请更好用的表；还可以启动一些专项治理，比如网格化的垂直专题治理。

　　优质供给和消费提效解决的是数据的生产关系问题，我们判断模型的复杂度有两个核心点，一个是规模，规模越大复杂度就越高，另外一个是数据消费关系，消费关系越复杂越趋于网状结构其复杂度越高，所以在规模控制上我们会做无效表下线、同源导入的管控。

　　基于这些治理策略，我们组合一些领域专题包括：

　　公共层的增厚，通过网格化的专项把模型做得更好。

　　应用层做提效操作，构建复用逻辑保证消费效率。

　　无效表下线、同源导入治理和数据交接等。

　　为了做这些治理，我们也需要更好的产品和工具来支持，我们和DataWorks团队深度合作，构建了基于数据开发的治理产品，比如：

　　智能建模，它解决的核心问题就是模型设计和模型开发问题，从设计环节保证它的高效性和规范性；开发环节即开发模型写代码的环节，会直接把我们的优化建议和发布管控在开发侧产品化。

　　数据地图，在展示数据的产品中我们开发了专辑功能，数据通过专辑上架的方式展示给下游；通过引导推荐让大家更好地发现高质量的数据。

　　构建数据治理中心的能力，比如优雅下线，快速将无效表下线；数据治理中心管控的配置化，使其快速分发至各个产品。

　　以上就是整体的解决方案。我们在统一规范、公共层的覆盖率提升、无效表的下线、产品的能力等方面制定了治理目标。

　　三、模型治理

　　接下来分享一下具体的模型治理实践。

　　1、无效表下线和ODS同源导入治理

　　首先看一下无效表下线和ODS同源导入，两者都是控制数据规模的。很多时候数据开发同学上数据是比较快的，但是很少去下数据，只要做完就很少主动去下线。我们要下线数据有两个方案，一个是用识别的方式通过平台或工具推送给表负责人，让他确认逐个手动下线，这个过程我们觉得没有太多意义，大家主动下线的意愿不高，给数据Owner 带来的价值也不明显，所以我们选择的方案是自动化下线，它有几个核心环节：

　　要提高元数据的识别准确度，即能够比较准确地识别哪些是无效表，准确度要提升到95%以上；

　　要保证自动化下线没有风险，可以快速恢复。我们对表执行rename的操作，如果没有问题就可以把它下线，如果有问题在观察期就可以快速恢复。对于节点的下线，先进行冻结，逻辑跟表重命名是一样的，有了这几个动作后，我们通过下线通知的方式可以快速的帮助大淘宝做一些自动化治理，减少大家的投入，这里我们的应用效果也比较明显，只花了近一人月的时间，下线了几十万张无效表和无效节点，无效表占比降到了5%以下，我们对大淘宝所有的空间覆盖部署了自动化下线能力，部署占比85%。

　　同源导入治理这块相对比较流程化：

　　我们能够快速识别出同源导入的数据，准确度可以达到99%以上；

　　我们会针对识别的数据做业务归属，因为很多时候同步的数据从底层库到下游的使用都有归属的业务团队，我们先确认清楚数据的归属；

　　之后我们就可以把导入的映射关系构建起来，有了映射关系我们的管控规则就可以在产品里快速配置上线，这样下一次导入的时候，如果出现重复导入，就会提示数据已经导入过。另外归属的核心业务团队空间可以只执行这些业务数据的导入，就可以保持业务数据跟管理空间是一致的，数据同步的过程中会有比较好的引导和拦截；

　　另外我们也在做多空间合并，暂时还没有完全实行，在开发过程中为了方便申请了新的空间，但这些空间可能是没有必要的或者是重复的，我们想把这些空间做自动化合并，后续会把它完全实施下来。

　　2、数据交接

　　第二块是数据交接的治理实践。基于元数据和治理流程，有一些关键动作：首先我们有一个自动化评估的策略，就是数据会主动触发一个交接流程，比如转岗或离职，触发后会对他名下的数据或者要交接的数据自动做一些评估，包括模型质量、稳定性等多方面的诊断，给出一个评估报告以及一些治理建议。如果数据存在问题，需要治理后才能进行交接，治理后会评估治理的效果，在得到被交接人认可或者是团队认可后，这个流程才可以完成。

　　这里面不仅是数据的治理，还包括业务的描述和一些文档的描述，通过这个过程我们就可以保证数据有很好的继承和交接，避免只交接数据，不交接业务和文档，同时可以把治理在交接过程中也直接处理掉。治理之后我们实现了交接评估的自动化，比如现在只要有任一个交接流程发起，就可以快速、自动地完成评估。另外我们后续考虑把交接的流程嵌入到工作流里，比如在发起转岗或者离职流程时，直接嵌入进去。

　　3、公共层专项运营及治理

　　第三块是公共层专项运营和治理，这是我们的一个重要的提效手段。因为我们经过评估体系的诊断分析之后发现，大淘宝有三块场景在重复度或消费侧有很大的提升空间，它包括用户分析、商家分析和匹配分析三部分。因为匹配分析相对比较离散，所以我们针对用户和商家两个专题做了专项治理。

　　我们把专题数据比拟成商品，快速圈选出这些数据形成一个体系，即用户体系，快速在数据地图的官方专辑里上架，成为体系化的数据。然后我们就可以评估其复用率和覆盖率，评估后，因为有了这些数据的展示门户，我们就可以做用户的专项运营，因为这些数据有下游的服务团队和消费团队，可以看到他们使用数据的状况。对使用率比较低但确实有真实诉求的情况，会做一些专项的运营，告诉他们我们有哪些数据，这些数据有哪些核心的保障，这些数据应该怎么用，并且更新其使用的知识文档，这些知识文档可能是基于前人经验做的沉淀，也可能是基于问答生成的自动化知识。然后就可以让下游快速的知道我们这些数据，同时我们的诊断体系也可以基于下游的消费状况识别出哪些数据可以沉淀到这个体系里去，因为很多模型构建是基于前置经验和后验经验去做的，这个专题就可以把消费侧的经验快速识别出来，哪些数据是高频度的数据，我们可以快速把它沉淀到我们的体系里去，从而实现增厚的效果。

　　专辑运营也是迭代的。以前在做数据的时候很少去关注数据的消费和运营，在做专题的过程中发现很多时候不是下游不愿意用我们的数据，而是他们不知道我们有哪些数据，即使找到数据后也不知道如何使用。我们在运营过程中达到了非常好的效果。在商家专项里，增量覆盖率从6%提升到了56%，用户专项从18%提升到了63%，治理之后数据使用率直线上升。我们基于两个很成功的经验，启动了其他的专题，这些专题有直播、短视频、用户决策，后续还有更多专题去启动。因为我们认识到很多时候我们构建的模型，通过垂直化领域的推广和治理效果会更好，比一体化运作的效果更直观更明显。

　　4、增量管控

　　再来看一下增量管控，我们会把基于评估体系和模型治理的规则先沉淀出来，比如前文提到的同源导入、发布管控和交接管控的规则都配置出来，再通过数据治理中心把规则作为检查项分发到各个链路里去。比如同源导入，我们会把规则分发到我们的数据集成产品里去，当有同源导入时就会触发检查和引导。在开发数据的时候，比如引用了一些表，可以通过推荐数据把它直接分发到开发页面里，告知有些字段存储比较大，是不是可以不选择，或者有一个更好的表，是不是可以换成另外一张表去开发。

　　这样我们可以实现更加精准的管控，同时因为我们使用的数据治理中心和DataWorks各个产品是联动的，可以根据管控规则所涉及的产品环节快速实现全面漏斗分发。

　　5、产品化

　　接下来看一下模型治理产品化的几个产品。

　　第一个是用于模型设计的智能建模，我们早期的规范标准其实设计是没有问题的，但是在实施过程中很多模型设计和开发没有一个很好的工具去承接，很多时候是做离线的模型设计，然后做线下评审，评审完再去手写代码提交到线上。这个过程很难管控设计规范，另外也比较低效。

　　智能建模的作用包括：第一是可以把设计规划直接沉淀下来，比如数据划分、维度定义等；第二，数据标准也可以快速呈现出来，比如省市区划分可以很快展示出来；第三是维度建模，支持可视化维度建模；第四是指标管理，可以通过画板或自动的智能化识别快速生成。

　　刚才也提到数据治理中心有传统的健康评估和治理，但是我们的模型治理要利用到一些很新的能力，比如无效表下线就需要数据治理中心去承接。另外我们在数据治理和运维过程中有一个很大的痛点，就是一些老的数据要迁移，下游很难去变更和迁移，我们需要一键迁移的能力，降低迁移的成本。

　　第三个产品是数据地图，它是供给和消费侧数据展示和检索的门户。重点是构建数据专辑，把数据通过专辑的形式展示给大家，提供一个专门看数据的门户。门户也会有运营动作，针对对应主题的专辑做对应的运营，同时把我们的经验知识和结构化数据运营起来，通过机器人的方式快速答疑完成找数据的工作。

　　6、能力沉淀

　　我们对前文中提到的四个“1“的能力也进行了沉淀。

　　首先是一个规范体系。早期我们的模型规范涉及的环节比较少，只有一个比较粗的方法论，我们需要把实践过程中的经验也体现在这里。

　　另外一个是我们的评估体系。以前我们在评估方面也做了很多工作，包括早期的血缘分析，以及后面提出的模型分，但这些评估都是一些散点，所以我们升级的评估体系核心包括几个环节，第一是通过一些指标评估出模型的质量，第二是做一些诊断，不仅发现数据不好，也会告诉你为什么不好，以及应该做哪些动作，最后治理效果也可以展示出来。升级后的评估体系不仅包括指标，还包括诊断和治理策略，同时也可以展示治理效果。

　　7、总结

　　我们在多年的模型治理中积累了许多经验，可以总结为以下几方面：

　　首先，我们需要决策层支持，因为模型治理是数据提效、架构升级和数据消费的重要手段，我们看模型不能看单点的一些数据，应该把它理解为本质上是提高数据开发和消费效率的，要帮助业务快速产生价值的事情，所以决策支持非常重要。我们在模型治理的过程中的数据一号位也提供了很多的支持，这是很重要的。

　　第二，模型治理是长期的事情，我们的模型架构会迭代升级，业务也会变化，治理策略也会随之变化。做计存治理可能相对比较简单，通过TOP计存分析，做一些压缩、删表就可以快速拿到很好的结果，但模型治理是长期的，也需要有匠心精神，因为要理解模型往往会涉及到各个环节，包括数据研发、下游消费、质量保障等等。

　　第三，数据即产品，我们要把数据当作产品去看，不能认为数据开发完之后就可以了，要把它作为一个产品去交付，去看下游的消费，是不是有人愿意用你的数据。

　　最后是持续的演进。以前我们每过1-2年都会做一次大规模的人工投入治理，我们发现效率很低，成本很高，我们的业务支撑是比较慢的，所以我们应该以业务增量价值去推动，一边支持好业务，一边做治理。另外我们要结合一些新的方法论和技术手段不断去演进治理手段。

　　四、未来规划

　　最后介绍一下后续的一些规划。

　　1、供给消费提效

　　从供给侧提升模型设计、开发和上架的效率，能够快速把优质内容开发出来；另外在消费侧也要做提效，包括数据的运营推荐。

　　2、架构规范管控

　　提升规范管控能力，将更多管控规则通过产品化分发到各个研发环节。

　　3、评治一体

　　模型治理从评估到治理有一个流程，但是很多企业或团队，偏向于评估之后让各个Owner去做治理，第一效率不高，第二本身我们的评估如果足够准确足够高效，可以直接和产品打通，这是我们后续的一个努力方向。

　　另外我们要结合一些新的技术，比如主动元数据、大模型等，还有自动代码生成、自动血缘切换等能力，实现治理的简单化、自动化。