开发者学堂课程【DataWorks 一站式大数据开发治理平台精品课程：3.DataWorks 数据模型介绍及实践】与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/81/detail/1229
3.DataWorks 数据模型介绍及实践（一）
内容介绍：
一、为什么要数据建模?
二、DataWorks 数据建模介绍
三、DataWorks 开发、治理模式的演变
四、演示与实操
内容简介：
一揽子数据模型管理解决方案，DataWorks 数据建模。近期 DataWorks 完成对拥有国内自主知识产权的专业产品提供商，淑莹科技所提供的数据模型管理软件，集成。众所周知，在今天的商业环境下，正确的数据治理策略对于数据增值是非常重要的，据统计企业的数据一直都在以每年50%的速度增长，而换言之也就是每年增长1~2倍，因此企业对于数据进行治理与整合的难度就不断加大。DataWorks 一直以都致力于成为用户更方便更快捷进行数据开发与数据治理的好帮手。此次发布数据建模，正是对已有数据治理领域能力的武器，为用户带在数据开发前实施事前治理的能力。本次分享主要分为4个部分，首先会暴露传统数据建模模型管理的普遍痛点，以阐明数据模型管理存在的必要性。其次会介绍当前市面上常见的数据建模工具的普遍能力和 DataWorks 数据建模的核心能力特色能力，以及所能给用户带的价值所能解决的问题。再次会展示基于本次数据建模能力的发布，如何补齐DataWorks 本身一向所主张的规范化数据开发的流程，使其变得更加完善。最后会通过视频demo的演示，展示如何通过 DataWorks 实现从模型顶层设计到落地物理模型的过程，以便于理解事前治理的精髓。
一、为什么要数据建模?
1、如果把数据看作图书馆里的书，我们希望看到它们在书架上分门门别类地放置。
2、如果把数据看作城市的建筑，我们希望城市规划布局合理。
3、如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕棍乱的桌面，经常为找一个文件而不知所措。
引用阿里巴巴大数据记录中的几句话，从这几句话里得出结论。不管大到城市建筑，比如图书馆，亦或是小到个人桌面，那么规范合理的组织都是必不可少的，因为只有规范合理的组织，才能避免事物或者现象的交织出现，最终构成错综复杂的难题，而存储在计算引擎中的数据模型也就是表也不例外。
4、复杂建筑的建设,设计图是必须的,组件标准化是必须的。
从常见的数据中台数据治理实施项目规划看，一般在业务与需求梳理完成后，模型设计就是避不开的流程。而据经验看，常见的数据中台项目数仓治理项目中承载数据所需要的表有1000~5000张，当然也存在几十万或者上百万的极端案例，因此给上千张表画一张设计图或者关系网络图就十分重要，那么这张图应该怎么画？用什么工具画？大多数企业是通过excel画图的，在众多的数据类项目实施过程中，模型都是记录在excel上的，这样的方式不是不可行，如果只是在模型较小的情况下，确实是轻量化并且容易实施的选择。但是当企业的数据业务飞速发展达到成千上百的规模时，这样的模型管理方式就会让数据人员十分痛苦。这时企业的数据模型可能和业务一样增长变更都非常快，数据人员根本无暇顾及维护修改excel的内容，即便能腾出时间和精力做这件事情，可操作性价非常低，并且很可能出现人为性的错误。而当管理者需要从全局的视角能审视整个数据体系的全貌时，得到的将是一对没有时效性错误率极高的信息。
5、难以落地数据标准
标准制定,质量要求细则,校验脚本
标准制定
标准定义，甄别和标准化
发布标准
质量控制，推广应用
按照标准设计,按照质量要求核验
模型工具
拉取标准，落地标准
落标引标对标
引用标准，建立映射引用标准，建立映射
集成开发控制
入口控制
规则到程序，规则到数据库
数据层核验
事后校验
批量校验，复杂校验
企业落地数据标准非常难，大多数情况下是因为缺少比较强有力的可操作性强的数据标准工具，因为没有工具，在数据实际产出前的引标落标阶段就直接被跳过，大多数企业都会秉持着先开发后治理的思想去构建自己的数据体系，而直接导致后续的数据不可用问题。众所周知如果企业没有明确定义自己的数学标准，那么开发人员之间对业务实体的理解就会不一样，从而构建出不同定义不同口径的数据模型，直接引起数据产出后期的质量问题，导致许多预计的需求都实现不，而数据团队就需要花费更多的时间和精力修复这些脏数据。企业的数据质量问题，多数是因为缺乏标准，或者标准落地不彻底而造成的。
6、传统模型管理常见问题
（1）缺少统一视图管理模型
（2）数据项目无法有效落标
关于数据治理，特别是事前治理最为困扰的两个点，第一是缺乏统一的试图管理模型，企业的数据模型分散在各个不同的引擎里，每个引擎中的数据模型具体长什么样，业务人员是不可能实时感知到的。第二数据项目没有办法有效的落标，引起数据生产的质量问题，进而导致很多数据需求实施不了。解决这两个问题，企业的数据治理问题几乎解决一大部分。
二、DataWorks 数据建模介绍
1、数据模型:数据组织和存储的方法、特征的抽象
（1）生活中的模型:房屋平面图、地图等，用不同的符号向相关用户清晰的展示。
（2）数据模型:数据模型是数据组织和存储的方法,是数据特征的抽象,强调从业务、数据存取和使用角度合理存取数据。没有数据模型,利益相关者很难看到现有数据库的结构、理解关键的概念。数据模型包含概念模型、逻辑模型和物理模型三类模型，概念模型是通过树立企业业务流程得出的，用描述各个重要实体和实体间的关系，比如在企业有多个部门，每个部门上的有n个员工，每个员工能有各自不同的薪资，那概念模型就可以通过部门员工薪资这三个实体表示各个实体间的关系。
（3）逻辑模型是对概念模型的进一步细化，确定每个实体的属性和描述，比如员工模型则包含姓名、身份证号、性别、生日等多个属性，
（4）物理模型则是面向引擎的模型，是基于物理特性考虑各种具体技术实现因素的模型，是只能存放在引擎中的样子。
2、建模方法的选择与兼容
那么 DataWorks 数据建模支持哪种理论的建模模型？支持维度建模还是关系建模？答案是可以支持。哪种理论模型最好？答案是没有最好，只有最适合。
3、关系建模( ER、3NF )
（1）优势
支持多对多(N:N)关系，高度结构化，相对容易扩展，无冗余。
（2）劣势
不利于对接BI，不利于下钻，物理设计常与业务不匹配。
站在全企业的角度，而不是业务分析的角度，对企业内众多的实体进行抽象，设计一套复合三方式的模型，用实体加关系的形式描述企业的业务架构，这种方法论规范性虽然好，基本没有什么冗余，比较适用于大型企业的企业级战略级的规划，但缺点是不利于对接bi，不利于下钻，并且互利模型设计通常与业务所需的模型设计不匹配，因此后期项目实施的周期会拖非常长，成本也非常高，对建模人员的能力要求同样非常高，这种方法论就像一辆巨型卡车装货卸货都很有讲究，并且要求司机非常有经验才行。
4、维度建模(星型、雪花)
（1）优势
适合多维分析，面向主题，聚合场景。
（2）劣势
无法跨业务版块，大量辅助表和垃圾表，表爆炸问题。
5、数据模型生命周期
（1）首先无论是什么项目，在项目开始之前，都要进行业务调研和需求分析，业务调研是为理解公司各个业务领域业务线的业务有什么共同点和不同点，以及公司各个业务线可以细分为哪几个业务模块，每个业务模块的具体流程又是怎么样的，这些信息非常重要，将会直接决定数据仓库的建设成败。
（2）需求调研要从实际的工作场景入手，比如分析师运营人员，他们每天都要查看什么报表，公司正在构建中的推荐业务系统的KPI是怎么样的，推荐系统需要基于什么样的数据才能达到这样的KPI。
（3）概要设计阶段，这个阶段需要从高维度对企业业务过程中的各个实体关系进行梳理和描述，也就是对维表和实施表进行图形化的描述。
（4）需要确定每个维度的属性和每个实施表的度量，确定属性和维度应该怎么样进入上一步的概要模型中。
（5）编码阶段就是将物理模型转化为ddl语句的过程。
（6）需要将转换完成的ddl语句下发到开发环境，验证是否符合模型的实际规范，测试通过后就可以将模型发布上线，服务于整个企业的数据体系。
（7）运行维护阶段则是长久持续进行的，在这个阶段，模型已经发布上线，成为一张实实在在的表落到引擎中，但是为及时发现非预期的从其他渠道对引擎进行的修改，因此需要对模型库予以与引擎中的模型差异进行定期的检查以及定期的修复验证。
6、业内数据建模工具基本能力
目前市面上普遍的模型管理工具都提供下面的几个能力：
（1）模型设计能力
支持企业全生命周期的各阶段设计需求:需求图,数据模型，业务流程图,开发相关0OM和XML结构,企业架构图。
（2）版本、License
版本控制,分角色控制用户权限支持并发 license。
（3）模型导入导出
产品支持兼容主流建模工，具的模型格式的导入导出,且支持导出XML或PDM文件格式,或产品支持API接口。并支持多人协作。
（4）支持数据库脚本
模型工具产品支持导出数据库脚本。
（5）概念模型，
概念模型,逻辑模型涵盖业务实体关系及细化功能，逻辑模型对应数据库设计。
7、差异化能力
DataWorks 数据建模是如何帮助用户管理数据模型的生命周期的？
首先行业普遍的建模工具所提供的能力都已经覆盖了，在此之上还提供几个特色能力，首先是智能引标，在建模之前不仅支持企业管理者定义属于自己的数据标准，同时支持数据建模人员在构建模型时候引用这些标准，以解决不同建模人员对数据的理解不一致，而导致口径不清晰口径不一致的问题。对于可视化的建模，不仅提供专业化的本地的客户端，也提供在线轻量化的网页版客户端，方便用户在不同的工作场景下进行选择。对于模型的导入导出，提供的是立项提取以及真相提交模型到引擎的能力，不仅只是将工具中已经设计好的模型直接下发至引擎，而且将引擎中已经存在的模型提取至工具中进行再编辑，在下发，告别传统工具手工导入导出的繁琐操作。在模型落标监控方面，支持对已经落到引擎中的模型进行基线的检查，帮助用户其中发现表结构与物理模型结构的不一致，以便及时修正。最重要的一点据DataWorks开发体系的完美结合，目前只是将模型的发布与DataWorks已有的开发流程进行关联，实现更加规范化的从模型设计到模型发布上线的流程。
8、核心使用流程
（1）模型导入
- 模型导入-通过导入工具,将 PD、ERWin 等 工具的模型导入DDM中。
- 反向工程-通过直联数据库的方式,反向生成模型。
- 信息补全-补充模型中缺失的字段信息,例如字段中文名称。
对于线下已经存在模型的企业，可以通过模型文件，比如pd的文件或者erwin的文件直接导入到的客户端中，或者通过反向工程功能，将大数据引擎中的模型直接导入到的客户端中。
（2）设计阶段
- 模型设计-使用客户端设计器进行模块设计与维护。
- 影响分析-设计阶段能够显示模型的修改对下游系统的影响。
- 字段引标-设计工具中能够引用数据标准。
设计阶段，用户可以通过的客户端工具或者网页版客户端工具对模型进行进一步的规划与设计，通过标准引用的方式完成模型的建设。
（3）开发测试阶段
- 提交测试-模型先提交至开发环境测试。
- 分支管理-按照行内推荐的最佳实践进行分支管理,分支间按照任务进行内容合并。
模型设计完成后，将模型标志开发环境进行测试，同时用户也能对历史版本进行分支管理，以便随时回归到历史版本。
（4）投产阶段
- 模型评审-模型的变更必须经过线上评审
- 模型上线-评审通过的模型即可发布上线
- DDL校验-将投产DDL与模型工具导出DDL比对。对于不匹配的部分,近期可以人工确认,远期改为系统认定。
测试完毕的模型再次经过相关人员的评审，就可以发布到线上生产环境引擎开始服务于企业的数据业务。
