开发者学堂课程【智能数据建模训课程 ：客户案例：大淘系模型建设实践（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1223/detail/18315
客户案例：大淘系模型建设实践
三、治理规范
针对原因会有架构规范和流程机制。架构规范和流程机制要背靠产品工具、工具平台做，用数字化驱动治理。既然有生命周期，那么核心是进行存量盘点，对于新增采取管控的方式，对于核心问题进行长期、日常的数字化驱动治理，以解决三个模型问题。
下面是规范和产品工具相关的问题。首先是规范问题。去年核心强调了数据视角，今年则是业务视角。业务对于数据核心有四个要求：一是对研发有交付效率，二是要有产出时效，三是质量要可靠，四是成本要可控，对于小业务成本可控，但对于淘气来说成本要求较高。在 onedata 存在的问题是虽然定了每个层次的作用，但是每个层次的分工和定位不清晰。因此针对这部分问题做了一个清晰的分工。第一是应用层，其核心在于专注于支撑业务，关注效率、交付时满足口径一致性要求、机器资源和产出时效要求需要的稳定性保障。核心的三个策略分别为用集市规范控制复杂度、构建一个轻度的中间层确保单集市口径统一、扁平化设计确保稳定。
在公共层部分，其核心是在其中产生数据效率。由于公共层有复用性，主要关注应用性和稳定性两部分。在应用性层面首先要规范 因为以活动建模为主，活动建模中核心应用的逻辑是宽表式的设计；另外是工程要有一定通用性的逻辑，核心要有适当节偶以确保核心内容的稳定。 ODS 是所有的入口，核心是保证整个数据的合规高效。这部分有两个核心，一是效率和稳定的问题，主要是工具化；另一个是性能稳定，主要是达到一定程度后，戳水性能要转化成提地莫卷的方式。右侧是架构的标准和规范。
下面是应用层的划分原则，着重讲解一个。整个集市的核心是满足特定部门或特定用户的需求，这部分需求有特征性，组织协同分工有对应的协同抓手，看到对应的平台侧，其核心是控商、控品和用户运营。对于行业、商家、消费者的核心内容进行调控。供应端是商家、品牌及品牌方对应的集团，做分析和控制，且也会往核心的抓口机型相应的组织分工，在主视角的逻辑下对集市进行构建。整个集市的划分原则核心是以业务场景或者服务对象作为划分原则，需要统一标准，最好符合 MECE 原则。
下面是机制流程，核心是公共层和应用层之间的共建机制。应用层研发的痛点在于公共层响应效率低；公共层研发痛点在于如果统一承接开发工作，研发资源不足。核心原则是公共层开放共建，事后审计治理；应用需求驱动，设计开发共建，公共层研发统一运维保障。左侧整个流程有需求驱动，判断哪些进入公共层研发主导，核心应用和核心工程是由公共层研发主导。临时增加字段或非核心工程的建设由应用层研发和主导。建设后当有复用性的情况下再交还给公共层研发进行统一用维，因为用应用层研发进行统一运维时对于其他场景无感，从而影响应用层的研发效率。
已有流程规范机制后，下面研究怎样保证工程规范。首先 onedata 部分公共层已有数据规范，应用层去年做了集市主题域的规范，因此已有数据体系的结构。核心有两部分，核心是和 dataworse 做工件，首先要对表命名管控以确保规范性，其次淘系是多空间数据体系的构建，因此需要统一的设计空间。
第二明细表有中英文的命名规范，左侧是建模空间，
在有目录和建模空间情况下，
下图左侧圈起来的部分还有目录结构和数据域的规范，有利于数据体系的规范管理和后续找数，这部分核心是提升规范性要求。
下面讲解设计方面。设计流程的研发核心是首先有一个研发 ODS 表，这部分表到公共层后做冗余。因此公共层首先要将 ODS 表导入，再将需要冗余的属性冗余进来，基于核心流程来看，首先去做表定义，接着对针对性场景做对应的冗余。例如下图中有对应的表，需对其做对应的冗余。对于 ODS 字段做标准化命名可得出对应的表结构。原本设计纯手工效率低，需在线下 Excel 表格中设计，经过大量手工操作，建表还需人工编写 DDL ；但现在已使用线上化工具，可以自动导入字段，一键自动建表，也可自动生成质量规则。之前有直接引用的 ODS 表，因此可直接找到对应字段的来源，从而生成对应的代码，可使整个流程十分流畅，将和 dataworse 合作在规范架构中与设计开发及后续用维保障流程打通，这样可提升公共层的研发效率。整个过程效率较高，可直接引用。上面提到核心工程怎样被用户感知，我们已有归还的目录结构，将目录结构的信息在数据地图中传给消费者，这是生产者与消费者双向的第二层联通。联通相当于将目录结构拓传出去，使消费者快速找到自己所需表，方便用户使用大淘系。
下面分析治理方面。治理必须数字化量化，否则会出现问题。基于此部分评分标准，构建出表集合模型，分为整体评分、各个团队的评分及对应数据域的评分。
跨团队协作后每个域都有核心负责人，这些负责人看待问题并对问题分类并标签，由此标签可以集成到各个环节，下面是整个核心的机制图。首先是评估，再用数据看板评估问题，这些问题会形成标签，标签会在第一个环节，例如是一个核心的公共层模型，会在搜索里加权，若专家经验判断节点或表要下线，会在搜索里降权，同时对于权限会管控，将数据透传到专辑中去，在搜索中减少推荐。在事前是将核心模型被快速感知，有问题的模型要提醒消费者不要引用。过程部分目前还未开始，但会持续构建，此部分核心是开发互层，由于 IOS 效率较低，在下一次应用节点会提醒不要引用 ODS ，切换层对应 DWD ；如果是更理想的状态会自断血缘，提醒此串代码如何修改，即在下一次迭代时做开发助手推荐。另一方面是做规范和治理项管控，在命名规范和治理项中对其进行改造，对于核心应用会做针对性的推动治理。
四、未来规划
未来规划分为三部分，首先是应用层效率。从数据体系来看应用层体量最大，大部分研发工作都投到应用层。问题以是应用层缺少指导规范， onedata 核心侧重于公共层，包括事实表的构建；二是运维效率；三是因为要以效率为主，应用层在内部都没有很强的应用规范，今年要争取效率和规范的平衡。另一部分是架构规范。分成标准已定，但对于研发流程来说没有明细的规范，这部分会继续向下拆解和细化。基于此部分设计、运用、开发、运维、变更和治理，这部分细化后会产生规范管控能力。最后一部分是产品工具提效，这部分要与 dataworse 共建。虽然应用层有一定的自动建模能力，但相比传统的应用层设计开发效率有所降低，因此今年会尽量将此功能抹平；测试是在线下测试，如有缺失会补齐；因为企业有运维能力，会将智能化运维能力提高；事中数据治理能力构建，即开发助手能力；再次是事后治理能力， dataworse 在团队中只是其中一个平台，还有其他的售后治理平台；最后是数据地图，会把血缘的数据贯穿到研发流程的工具平台中以提升整体效率。
问题回答：
1、核心公共层建设应该是从上到下还是从下到上？
答：这是一个相结合的问题，从上到下和从下到上的逻辑，应从需求出发，避免对工程过度设计。首先从应用层出发，有复用性后再做公共层，但公共层的设计面向业务过程，从而是从下到上的过程。因此需求是从上到下的过程，设计是从下到上的过程，两者相结合。
2、数据标准到数据模型的过程中如何管理数据约束？
答：数据标准在传统企业中有强诉求，但阿里内部相对较弱一些。因为阿里2014做了双中台，在业务中台部分已做了很好的集成，传统产业在原系统没有很好集成的情况下才会有很强的数据标准要求，这种情况下要基于内容层面的管控。 DQC 是一个简单的功能，但要集成数据标准的要求、做一层集成幻化才能提升此功能。
3、多 BU 公共层模型建设规范是否需要统一的组织审核及如何量化评估其价值？
答：要有规范统一的大前提，因为数据规范是为了易于流通，进而产生价值，这种情况下必然要做统一规范，但并不意味着全部要做统一规范，不同行业例如电商、出行及本地生活目标业务过程、目标体系都不相同，因此在这种情况下统一规范会影响效率，所以应分开分析。
4、怎样判断应用层的数据要做到公共层？
答：这里会有一个 DWS 标准，从专家经验来看，电商业务交易环节可能会有，在下游直接构建一个场景；但如果是新建玩法类，业务连线不强的情况下构建工程会导致过度设计。因此有些需要事后下沉，有些是由专家经验判断进行下沉，核心基础标准在于复用性，若无复用性下沉都属于过度设计，因为公共层的设计成本寓于其中。
5、命名规范具体怎样实施？数据开发在建模前要先定义词根和字段名吗？
答：需要拆开分析。 DWD 层面向业务过程，在数仓规范内有统一的模型设计，因为每个业务过程的新增都是有限性的，因此这部分会先定义，定义后直接引用。自定义的词根千变万化，便于开放。 DWS 层分为两个逻辑，首先是维度，维度建模时一个整线架构的逻辑，具有一定相对确定性，一个业务新增实体十分有限，此部分业务可被枚举，但其中的派生指标在设计过程中让 dataworse 自动定义，因为派生指标变化量很大，因此不能全部枚举做先定义后开发，会区分开原子指标修饰词、业务过程，核心维度会先定义后开发，对于派生修饰词会在设计过程中自动定义。
6、在应用层如何保障字段同名但口径不一致或口径一致但字段不一致的问题？
答：应用层实际很难管控，命名和定义不可能全部统一，除非所有指标都是先定义后开发的。应用层有80%指标是个性化的，20%是共性的。这种情况下如果全是先定义后开发，没有复用性的场景，会导致整体效率下降。另一个逻辑是既然整个过程是演变过程，模型首次产生的标准命名不规范，下沉到公共层才会形成标准，因此只能保证核心指标90%规范和定义是统一的，但另一部分无法全部管控。
7、跨集市依赖下沉到公共层的必要性如何？
答：跨集市依赖有业务效率，短期内没问题；但从长期来看，当集市内部已不再使用应用，但下游集市仍有人使用时，应用无法下架，这会导致成本浪费，变更过程中产生关联影响，下游出现的故障需要自己负责，下次迭代时又会考虑下游。在新增环节效率高，但后期变更、运维和治理效率低，因此从长远来看应规避跨集市依赖。
