模型背景问题2 问题分析3 治理方案4 未来规划
模型背景问题
1. 总体情况
首先介绍一下淘西的整体数据背景。
桃溪数据中心成立已有7年左右，一直没有数据管理。总体数据生成比例为：人工创建（22%）+机器生成78%。其中，活跃数据占比：9%，不规则数据占比：21%。
数据活跃度呈倒三角形分布，整体分布比例为ads:dws:dwd:dim=8:2:1:1，还是比较合理的。
上图的下半部分展示了模型的生命周期、增长和保留。桃溪的业务还在快速变化，模式变化也比较快。模型生命周期为25个月，模型年增长率为30%，模型留存率为44%。
2.公共层
公众层面的两个核心问题是：
首先，公共层表的复用性不高。 2014年，公共水平相对规范，但不可持续。随着时间的推移和业务的增长和变化，可重用性逐年下降。因为大部分数据是应用层产生的，他们会开发自己的公共层，降低了复用性，而且大部分都是无效表。另外，公共数据表在各个团队之间分布不合理。这是因为数据团队很多。为了满足业务开发效率，每个团队都有自己的公共表。很容易出现公共表复用率低、重复建设的场景。其中，淘宝数据团队负责的公共数据表数量最多。 3、应用层分析
应用层的主要问题包括：
一是公共层建设不足或公共层暴露不足。随着时间的推移，公共层的指标已经不能满足广告层的业务需求。广告重用指示器逻辑没有较低层。引用cdm层的ads表比例逐年下降，而引用广告的ads表比例逐年上升。其次，很多广告表格的共同逻辑还没有下沉。统计显示，超过17.63%的广告表被下游广告复用。三是跨市场依赖严重。统计显示，整体跨市场依赖度占比30%。特别是进口大数据和淘宝数据的跨市场依赖度达到40%，影响模型的稳定性和模型的降级。线路、修改。
问题分析
1.问题总结
上图是一个简化的数据模型。我们可以发现存在很多不规则之处影响模型的稳定性。随着业务的快速发展，为了快速响应业务需求，不可避免地产生模型问题。日常工作中，数据研发流程大致如下。收到业务需求后，直接参考ODS层表开发ADS数据。当数据需要重用时，逻辑就存放到公共层。同样，指标也会有类似的情况。主要问题可归纳为七点：
系统中有很多临时表，只增不删，对消费端影响很大，因为表量巨大，有效比例低，检索困难；命名不规范；公共层设计过度； ADS是重复构建的； ADS 具有跨市场依赖性； ADS的共同点是不会下沉； ADS 渗透率取决于ODS。 2.原因分析
从问题分类来看，主要有三类问题：规范问题、公共层可重用性问题和应用层可重用性问题。
从问题原因来看，主要有四类原因：架构规范、流程机制、产品工具、研发能力。
3. 模型治理的问题
模型治理挑战：
商业价值并不明显。治理带来长期价值，短期内对业务影响不大。治理协作复杂，治理需要ODS、CDM、ADS层多人、多团队协作。问题治理很难根治，新模型很容易依赖有问题的模型。平均模型生命周期不长（25个月）。综上所述，模型治理的投资回报率比较低，我们的问题是如何以最高效的方式进行模型治理？
治理方案
1.总体规划
基于上述问题原因分析，我们制定了以下治理方案。
核心策略有以下三点：
1：盘点，掌握数据整体情况
2：标准化增量，避免添加新模型时走老路，重复同样的问题。考虑到数据的生命周期，可以忽略历史数据。
3：日常治理保障健康，长期治理由数据驱动
2. 机构规格
架构分层标准
往年我们关注的是数据角度，今年我们关注的是业务角度。业务视角的核心诉求包括四大点：交付效率、输出及时性、质量可靠、成本可控。过去OneData定义了各层的角色，但各层的分工并不明确。因此，针对这些问题做出了明确的定义。
应用层的核心是聚焦支撑业务，需要考虑研发效率、交付数据口径的一致性和稳定性。
通过市场规范控制复杂度，通过轻聚合中间层保证口径统一，通过扁平化设计保证稳定性。
公共层的核心是抽象复用以提高效率，需要考虑易用性和稳定性。通过规范和冗余宽表提高可重用性，通过解耦确保稳定性。
ODS层的核心是合规和效率，需要考虑访问效率和性能稳定性。通过工具提高效率并优化治理，确保性能稳定。尤其是数据达到一定量后，应该考虑使用merge来访问数据。
市场划分规范
数据集市用于满足特定部门或用户的需求，并以多维度的方式存储。通过对相似数据业务场景进行聚合抽象和分类，可以降低ADS层和数据管理重复建设的复杂度，使应用研发更加专注和高效。
市场划分的原则如下：
原则一：以业务场景或服务对象为划分原则，对相似的数据业务场景进行衔接、抽象的分类。
原则二：市场划分需要规范并尽可能符合MECE原则。
公共层共建机制
在公共楼层的施工过程中，我们通常会遇到以下两个痛点：
应用开发痛点：公共层效率低。公共层面研发的痛点：如果统一进行开发工作，涉及的业务非常广泛，研发资源不足。为了解决以上两个痛点，我们通过以下核心原则来解决：
原则一：公众层面公开共建、审计后治理
应用开发组织需求，提供需要下沉到公共层面研发、公共发展需求评估的公共维度。
原则二：以应用需求为驱动，设计与开发共建。在需求驱动下，核心模型和非核心模型分离。公共研发负责核心模型，非核心模型则由业务发展共同开发，提高效率。
原则三：公共级研发统一运维保障
非核心模型上线并完成相关测试（准确性、确定性、治理）后，转移到公共层进行研发，并由公共层统一运营和维护。
3. 智能建模
数据治理仅仅有数据标准和共建机制还不够。还需要结合自动化工具来提高效率并确保标准。我们从以下四个方面入手（具体可以体验DataWorks产品）：
数据系统目录结构化模型设计，在线开放研发流程（自动生成短代码），对接地图数据相册数据目录系统结构
形成数据系统目录有利于理解和掌握数据，分类的方式降低了大家的使用成本。
首先，我们需要对表命名进行一些控制。我们制作了一个可视化表命名检测器以确保标准化。另外，套溪不是单空间的数据系统，因此需要解决跨多个空间的复杂数据系统的统一建模问题。
在线模型设计
改变模型设计方法，从离线设计转向在线，使用一些自动化工具来提高效率和保证标准。
简化研发流程（自动生成短代码）
模型迁移上线后，打通研发流程，自动生成简化代码、生成代码框架、创建表格语句，显着提升研发效率。
对接地图数据相册
形成相应的地图数据相册，方便其他用户使用数据。
4. 模型治理
评分模型
模型治理需要量化。如果没有量化，仅仅依靠专家经验将是非常低效的。我们使用模型指标来形成表格级别的模型分数。跨多个维度对模型进行评分。
评分机制
精细化的评分机制对团队、数据域、核心进行评分，形成相应的标签。
整体流程
在数据驱动下，上图左侧，以模型评估数据为出发点，通过各个维度对模型进行评估，得到各个领域、各个团队的得分，并形成相应的问题标签。
在产品驱动下，上图右侧通过专家经验判断，对线上新车型的搜索权限进行升级，对线下车型的权限进行降低，让业务能够快速感知数据变化，引导业务。
未来规划
应用层效率
整个数据系统中，应用层的数据量最大，投入了大量的人力。 OneData缺乏对应用层的数据建设指导，市场耦合度高，给运维效率带来诸多问题，如跨市场依赖、依赖深度等。过去是面向业务，为了保证研发效率，放弃了一些研发规范。未来将完善应用层的研发规范，利用工具来平衡研发效率和规范。
架构规范管理与控制
在实施分级标准的基础上，规范和完善研发流程，细化设计、开发、运维、变更、治理等规范。
目前核心是表命名规范，依赖规范、代码规范、运维规范等管控能力还不够。
产品工具提高效率
将继续与Dataworks 一起构建。
应用层的智能建模能力还不能满足研发效率的要求，所以我们会不断完善功能；集成数据测试功能；升级数据运维功能；建立流程内数据治理能力（开发助理）；提升事后治理能力（批量删除、主动推送优化等）；数据地图，查找数据，利用数据，提高效率。
问答环节
1：核心公共层的构建是自上而下还是自下而上？
使用两者的组合。由需求驱动，如果没有需求，就会导致过渡设计。应用层复用后，再下沉到公共层。这是自上而下的。公共层设计阶段是面向业务流程、自下而上的。
2：多BU公共层是否需要统一标准化？怎么做呢？如何量化价值？
需要统一规范，方便数据流通，体现数据价值。但具体的规定还需要详细考察。例如，电商和本地生活的业务和目标不同，因此很难实现统一监管。
3：如何判断指标是否需要下放到公共层？
公共层的开发是需要成本的。是否需要移至公共层核心，取决于是否需要复用。可以从两个方面入手。
专家经验判断：比如电商交易数据，这类数据是核心数据，必须构建到公共层。
事后判断：如果玩法等业务稳定性不强，没必要一开始就下沉到公共层，避免过度设计。稍后我们可以判断是否需要下沉。
4：关于表和字段的命名规范，开发前需要先定义词根吗？
需要单独来看。为公共层设计的业务流程是有限的，必须先定义公共部分，然后再开发。对于应用层来说，维度是使用整体架构的，所以需要先定义维度。指标很多，特别是派生指标，不建议在开发前先定义。
5：口径一致但命名不一致，或者口径不一致或命名不一致的场景如何解决。
模型不断发展。对于应用层来说，刚出现的时候80%是定制的、非标准的。这部分如果先定义再开发，效率会很低。只有下沉到公共层才能解决。能够控制。对于公共层，我们能做的就是保证90%的核心指标在规范和定义上是统一的，剩下的部分就无法保证了。
6：是否有必要降低对公共层的跨市场依赖？
短期内没有影响，新增效率高。
用户评论
我的黑色迷你裙
看了这篇文章，感觉淘宝在数据模型治理上真的下了不少功夫啊！特别是提到的最佳实践，对于我们电商从业者来说，真是太实用了。
有14位网友表示赞同！
杰克
淘宝数据模型治理，这可是电商行业的大难题，看到这样的最佳实践分享，真是解了我不少燃眉之急。
有9位网友表示赞同！
陌上花
感觉文章里提到的数据模型治理方法，挺有参考价值的。不过，具体实施起来，还得看企业的具体情况。
有12位网友表示赞同！
怀念·最初
淘宝的数据模型治理做得真好，如果不是专业人士，还真看不懂这些细节。希望更多商家能借鉴。
有11位网友表示赞同！
冷眼旁观i
这篇文章让我对数据模型治理有了更深入的了解，特别是那个案例分析，学到了不少东西。
有7位网友表示赞同！
致命伤
淘宝在数据模型治理上做得这么好，是不是他们的店铺运营也跟着水涨船高呢？期待看到更多相关内容。
有16位网友表示赞同！
微信名字
最佳实践是好事，但我觉得文章里提到的工具和技巧，对于中小卖家来说可能还是有点高不可攀。
有14位网友表示赞同！
孤岛晴空
淘宝的数据模型治理文章，写得挺详细的。不过，感觉实操性还是有点弱，希望后续能提供更多实战案例。
有8位网友表示赞同！
_心抽搐到严重畸形っ°
这篇文章让我对淘宝的数据模型治理有了新的认识，特别是数据安全方面，真的是不可忽视。
有9位网友表示赞同！
暖栀
感觉淘宝在数据模型治理上，真的是走在了行业的前沿。希望他们能继续保持这种创新精神。
有5位网友表示赞同！
嘲笑！
文章中提到的最佳实践，对于我们这些做数据分析的人来说，真是太有帮助了。感谢分享！
有14位网友表示赞同！
↘▂_倥絔
淘宝的数据模型治理，是不是意味着他们的商品推荐系统也会更精准呢？期待看到实际效果。
有7位网友表示赞同！
眉黛如画
看完这篇文章，我对淘宝的数据模型治理有了全新的认识。特别是提到的数据清洗和整合，对于提高数据质量很有帮助。
有5位网友表示赞同！
念初
这篇文章让我意识到，数据模型治理不仅仅是技术问题，更是一个系统性工程。希望淘宝能在这方面继续深耕。
有5位网友表示赞同！
终究会走-
淘宝的数据模型治理最佳实践，对于我们的电商运营来说，真的是一场及时雨。感谢分享！
有5位网友表示赞同！
爱情的过失
感觉淘宝在数据模型治理上投入了不少资源，这背后一定有很多故事。希望作者能分享更多幕后信息。
有16位网友表示赞同！
心脏偷懒
数据模型治理是电商发展的基石，淘宝在这方面做得很好。希望其他电商平台也能跟上脚步。
有7位网友表示赞同！
烬陌袅
文章中提到的数据模型治理方法，我打算尝试应用到自己的项目中，看看效果如何。
有8位网友表示赞同！
孤单*无名指
淘宝的数据模型治理最佳实践，对于我们来说，真的是一个很好的学习机会。希望作者能继续分享更多经验。
有20位网友表示赞同！