一、背景及问题
模型建设的要求主要有三个方面：效率快、成本省、质量稳。
- 模型要能够快速地开发和使用，因为数据具有实效性，如果数据不能快速地产出和消费，它带来的价值就会受到影响；
- 模型设计要考虑数据成本带来的影响，近几年有很多企业在做成本治理，模型也有节省成本的诉求；
- 数据质量要有保障，包括数据的准确性和稳定性等。
结合多年的数据模型开发和管理经验，总结了四个“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去做治理，第一效率不高，第二本身我们的评估如果足够准确足够高效，可以直接和产品打通，这是我们后续的一个努力方向。
另外我们要结合一些新的技术，比如主动元数据、大模型等，还有自动代码生成、自动血缘切换等能力，实现治理的简单化、自动化。
五、Q&A
Q1：消费关系是什么？
A：我们的数据开发完之后要被下游使用，比如表是不是被配置到看板里，是不是被配置到产品里，这些都是数据消费。消费关系就是在使用这些数据时，引用的是哪些数据，是公共层的数据，还是最原始层的数据，又或是应用层的数据。消费关系决定了模型的复杂度，消费关系越复杂，网状结构越深，就代表我们要想去理解或者追溯的难度就越大，治理的难度也就越大。
Q2：模型优雅下线的优雅体现在哪里？如何实现？
A：优雅指的是不需要投入很多人工去确认，可以直接自动化下线，它体现在几个方面，第一就是能够精准识别出无效数据，比如没有下游访问的，没有下游的依赖关系，或者一直重复同步相同的数据。第二是识别出无效数据、无效节点之后，可以快速下线，不需要人工再去确认，也不需要写下线语句，从而避免下游的人为成本和治理成本。
Q3：同源导入的识别率，准确度高是因为元数据完整还是在一处配置的，还是有其他的方法？
A：同源导入的识别率高是因为我们的元数据做的比较好，因为同源导入需要配置，比如要配置映射关系，它的原始库是什么，目标库是什么，这些数据在整个同步过程中都会被记录下来，有了这些记录，我们可以非常精准地识别出是不是同一个库的同一张表被导入了两次，其依赖就是血缘解析，所以它的精准度提升是元数据本身的一个保障。
Q4：模型的管理与治理与业务的敏捷查数用数是怎样平衡的？
A：这是一个好问题，我们刚才也提到在治理的过程中更应该关注的是增量，先保障增量，不要投入太多精力去治理历史数据，因为数据是有生命周期的，几个月后可能它就变得不那么重要了，只有一些核心模型才需要做存量的治理。但是增量在业务使用过程中，它消费的是不是比较高质量的数据，它开发的数据是不是能够很好的被下游理解，能够很好地分发到下游去，这是我们最关注的。所以首先要帮助业务快速满足其自身需求，另外把存量治理的动作通过产品和自动化的方式去解决，这样就可以平衡性能。因为业务团队是非常忙碌的，做需求的时候再去推动很多治理动作是不合适的，所以一方面可以通过产品快速进行存量治理，另一方面通过提供优质的数据供给，提高需求的开发效率。
Q5：可视化建模是指ER图吗? 只是用来查看的视图还是有别的能力？
A：我们在开发一个表的时候，想做一张明细表或维表，逻辑是先设计原始数据是哪几张表，业务过程有哪些，字段有哪些，把它放到哪个主题域里。这个设计以前是线下的操作，但是智能建模可视化是把模型设计体现出来，它不只是一个可视化的ER关系，还包含设计逻辑、归属逻辑，以及属于哪些数据域，粒度是什么，业务过程是什么等等。这些是可以在智能建模里快速导入和录入的，设计完后我们也会做模型评审，因为每个集市或主题都会有对应的模型师，他可以快速的看到有哪些人提交了模型，可以快速的做评审。另外模型设计完之后，因为有底层表和关联关系，可以快速的生成代码，也就是说我们不仅可以做模型设计，还可以快速生成代码，例如简单的主键关联、汇总或group by，这些代码会自动生成，生成后可以快速进行调整，快速上架。所以智能建模不仅包括设计ER关系或者模型关系，还包含模型的归属以及快速的代码生成。
Q6：考虑到用chatgpt结合模型管理吗？有什么场景可以用到？
A：这个是有考虑的，我了解到产品团队也在使用大模型去做一些训练，第一个是我们选择大模型或者了解这些主动元数据，而不是跟风，因为我们发现有很多以前模型的问题解决不了，比如实现逻辑复用的识别，相似表、相似字段，我们以前的识别率是比较低的，低到无法投入使用，比如我们要做血缘追溯或者重复数据的迁移，我们不知道哪些表相似，就没法做这些工作，所以需要利用比如底层代码的分析和识别去真正准确的识别出相似的数据。另外我们的口径，比如指标加工的口径是统一的，但是下游消费的时候，因为命名导致可能重复命名的指标，我们也识别不出来这些数据是不是重复加工的，如果我们用大模型的方法，比如把我们集群里的所有代码全部学习一遍，看哪些逻辑是相似的，就可以快速把那些指标用相同的口径去实现。
还有我们现在开发数据还是相对比较低效的。我们先了解需求和业务，然后去做模型设计，开发。将来是不是有一种方式，只要通过结构化的表达把数据描述清楚，代码或者指标就可以快速计算出来，如果能够实现，那么后续的治理就不需要了。只需要从底层的机器层面就可以实现代码统一和逻辑最优，不再需要投入很多人力成本或设计去做下线和口径调整迁移。但是因为大模型本身需要时间迭代，所以我们也要看它的效果。
Q7：一键迁移是怎么实现的？是用来做什么的？
A：我们在模型治理过程中有一个很大的痛点，就是发现下游消费的数据不准或者使用的表没有保障，我们有一张更好的表可以替代它，但是因为下游消费已经形成了消费关系，所以切换需要投入很多的成本，比如要改成新表，还要去改依赖关系，改基线保障，同时要做数据测试来和之前对比是不是符合预期，这个动作从前期的通知告诉大家要迁移到改造，到上线涉及到很多环节。
所以我们提出一键迁移。比如有两张表，我们会告诉它要切换的新表和老表的字段的关联关系，通过这个关联关系自动把下游所有依赖这个表的代码全部改掉，改完后把血缘依赖也改掉，之后我们可以启动数据测试，把迁移后的代码跑一遍，从性能到数据准确性的对比都可以产生出来，提交给Owner看切换的对比是否符合预期。如果点击确认，代码就直接发布上线，这就是一键迁移的原理和我们想实现的目标，因为只有实现快速的迁移，下游治理才可能流畅。
Q8：阿里或其他公司内部有很多的数据产品，比如大淘宝业务部门和阿里云的数据部门 都会做很多数据产品，如何协调重复建设？
A：从底层讲我们的计算存储用的都是阿里云的基础设施，所以核心差异点就在指标系统、治理平台或者运维平台等等是不是一样的，我们关注和考虑是不是有重复开发这一块，我理解各个业务团的本身做数据管理或治理，是有个性化的诉求的，比如我们这次模型治理，评估指标虽然通用，但是和原来治理中心的评估是不太一样的，它有很多我们经验性的东西在里面，需要慢慢转化，所以我理解在不同阶段各个业务团队自己去建是没有任何问题的，当各个团队构建的时候，比如说阿里云的产品同学发现大家用的都是同样的方式或者用的都是我的通用能力，他就可以快速把这个能力通过治理产品统一，一旦统一各个团队发现产品是很高效很有用的，他就不愿意再投入很多人力去做重复开发和建设，毕竟各个团队需要考虑成本和效率，如果下沉的产品做的好，后续就可以实现统一，这是我的理解。
Q9：您做模型治理的技术难点和亮点有哪些？
A：技术难点，模型这块刚才也提到了一些点，第一个就是我们的识别准确度，比如我们的元数据准不准，我们在做自动化下线的时候遇到很多阻力，很多下游同学有顾虑的，直接帮他把表下线，带来问题怎么办？这些难点可以通过元数据的方式解决。另外我们发现评估体系也是一个技术难点，大家可能会觉得这些不属于技术，但是对模型的理解和评估本身就是很高门槛，需要很完善的经验在里面，同时有很多一线的实践在里面才能做到。还有比如刚才提到一键迁移本身的技术难度是非常高的，它涉及到精准的数据识别、自动代码生成、数据测试，所以这些环节里难点都是有的。我理解模型治理的亮点是什么？第一个我们在实践过程中发现数据要做为一个产品去运作，早期我们很少关注我们的数据，上线之后大家用的好不好，顶多感觉到别人说这个团队建设的数据不好， 这是一个认知。另外我们通过运营的方式去发现运营动作是非常高效的，以前用了很多技术手段去推动，但发现效果并不明显，但我们把数据用来运营的时候，它的效果是非常明显的，大家接受度也比较高，所以我觉得这是一个亮点。还有我们很多动作管控的自动化，把数据做运营这个思路同时结合比如数据网格数据编织技术，转化为治理手段，我理解这是我们做的比较好的点。
