开发者学堂课程【智能数据建模训课程 ：客户案例：大淘系模型建设实践（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1223/detail/18315
客户案例：大淘系模型建设实践
内容介绍：
一、背景及问题
二、问题分析
三、治理方案
四、未来规划
本次课程主要分享过去一年淘气数据模型治理方面的事情，包括对产生的问题介绍、问题分析及其应对措施。
一、背景及问题
整个淘气项目空间内数据情况如下：78%由机器任务生成；22%由人工创建，但其中真正活跃的只有9%，在人工创建中不符合规范的有21%。再看各分层活跃表的分布情况：整体为倒三角模型， ads : dws : dwd : dim =8：2：1：1，整体分布较合理。最后看其时间周期情况。由于淘气是一个快速变化的业务，因此其整体增长比例为30%，因为变化的模型留存为44%，模型的平均生命周期为25个月。分析整体数据可以看出有两个核心问题：一方面是临时表较多，会影响数仓的体系和数据管理；另一方面是命名不规范，缺乏管控。
接下来分层研究。首先是公共层。公共层有两个核心问题：第一是其复用性不高，可持续性低，大部分的核心是应用层的研发，应用层完成后再构建对应的公共层，因此50%的表直接下游表数<=1，这其中包含无效的和没有依赖的表，大部分属于应用层研发；第二个问题是公共数据在各团队分布不合理。因为淘气的数据团队庞大，各个数据团队会建立相应的工程，虽然有统一的工程，其比例分布不合理。
接下来是应用层，时间周期。应用层引用公共层的比例持续下降，引用内部的比例逐渐上升，以此逻辑分析，可以得出，应用层可以内建公共层复用性的数据表。为了验证以上逻辑分析，取一次数据剖析：应用层下游复用节点很多，达到17.63%，这一部分复用节点很高。最后是横向跨团队协作的问题，可以看出应用层跨集市依赖的比例较高。
二、问题分析
首先对问题产生的流程进行简单介绍。在互联网研发过程中，接到一个需求后可直接在 ODS 里直出，等到有复用性时才会去做对应的公共层。当有复用性的指标时，才会做 DWS 层。为了快速支持业务会引用应用层，最后产生快捷式依赖。后面公共层被优化的情况下应用层研发的主导性提升，会主动构建 DWD 和 DWS ，规范性和体系性会出现问题。为了快速规避工程需要的要求会在应用层内自建。当然数仓未来要往智能化方式发展，机器产生的脚本会逐渐增加，会有一些导出、自动化报表的任务。还有一些不在规范体系中的脚本和任务。将以上问题汇总，主要的问题如下：1、系统临时报表多，只增不删。这对于研发没有影响，但对于数据地图有90%的表会检索不到，对消费者会有影响；2、命名不规范；3、 CDM 过度设计。为了快速支持业务，同时应用层满足公共层规范的要求，因此会硬性拆分公共层，这没有公共层复用性的要求；4、 ADS 重复建设；5、 ADS 跨集市依赖；6、 ADS 共性未下沉，有的引用没有做下沉；7、 ADS 穿透依赖 ODS ，直接引用 ODS ，因为复用性本身存在。
模型产生问题是不可避免的，在满足效率的情况下会弱化规范性和整体性从而产生问题。
问题可以分为三类：规范性的问题；公共层复用性的问题和应用层效率的问题。规范性有两个问题。阿里在2014年就提出了 onedata 的规范管控问题，但其对应的工具管控能力较弱，未能植入到整个开发流程中。再有新员工入职培训对于 onedata 认知也需要一定周期，因此整个研发周期对于 onedata 也要有一个认知过程。 CDM 过度设计的问题在于公共层和设计层研发分工协作不明确，下层工作效率低，因此有压力的情况下公共层会快速自建。由于公共层研发是为了未来扩展性设计，因此会出现过度设计。再者是重复建设的问题。应用层呈倒三角模型，在体系中表量较多导致复杂性增多。在量多时研发要对全量去重，对人来说是一个巨大挑战，因此其对于已有应用层没有提感。背后的问题是缺少一套应用层集市的架构部分， onedata 在2014年核心提出解决公共层规范性的问题，但这部分规范还是被弱化了的。跨集市依赖的问题是如果被依赖，那么应用层会变成公共层的属性，因此会带有公共层的规范性要求和效率，所以公共层缺少依赖管控。即使有分工沉淀， ADS 和 DWS 也会因为分工协作的问题导致下沉机制不清晰。 ADS 共性未下沉有两个逻辑：一是协作的问题；另外是边界的问题。 ADS 和 DWS 本质都为汇总表，但边界不清晰。 ADS 穿透到 ODS 部分分为研发快速相应业务和核心 ODM 模型未被感知。将以上原因归类，总体可分为四个方面：1、架构规范2、流程机制3、产品工具4、研发能力。
下面分析模型治理遇到的挑战。左边是问题，右边是改进后的。下沉到17节点依赖，把右方节点删除，将不规范的改成规范的。改完之后的流程对外消费的应用层节点没有任何变化，即其带来的业务价值不明显，带来的是长期的数据效率问题。其次是协助过程较复杂，需要 ODS 、 CDM 、 ADS 协作治理，至少在淘系的应用场景中有多团队，这种情况下存在跨团队协作的问题。再次是问题难以根治。将一个节点去除，会有其他人从节点引用。因为模型在互联网中的应用是有生命周期的，因此考虑在模型治理 ROI 较低的情况下，怎样治理更高效。根据以上原因分析制订一个方案。
