1 什么是数据模型
从百度百科上说，数据模型（Data Model）是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。
数仓模型，就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。
在 Dama2.0 中指出数据建模是发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传递这些数据需求。数据建模是数据管理的一个重要组成部分。
数仓建模，实际上就是构建一种数据存储模型，用于结构化的方式存储我们业务系统有价值的数据，目标让我们用更低的存储成本，更清晰的数据结构存储组织数据，更快更高效高质量的支撑业务分析满足客户需求。
2 为什么需要模型重构
- 数据重复建设：前期为快速响应业务需求，常常是烟囱式开发，任务跨层依赖耦合度高，未进行合理模型建设，造成集群存储和计算资源的浪费。
- 业务过程缺失：公司业务飞速发展，业务逻辑发生重大变革，数据模型未能跟随变更升级，导致不满足现在的分析需求。
- 数据标准不统一：由于不同人员参与建设，每个人按照自己的理解建设，造成相同的指标在不同的表里口径不一；相同的字段含义在不同表里命名不一致导致使用理解上偏差等。
- 数据不可追溯：重要的数据没有快照备份，数据使用方常常会发出“为啥今天看到的和昨天看到的数据不一样？”疑问，数仓都没有办法去比对，往往只能不了了之。然而真实应用中数据某些重要节点情况需要保留的。
3 数据仓库建模方法
数据仓库建模主流方法目前有2种分别是范式建模（关系建模）和维度建模。
范式建模
Inmon 提出自顶向下建模方法， 用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合 3NF，它与 OLTP 系统中的 3NF 的区别，在于数据仓库中的 3NF 上站在企业角度面向主题的抽象，它更多的是面向数据的整合和一致性治理。
维度建模
Kimball 提出的自底向上模型以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
范式建模需要全面了解企业业务和数据，实施周期非常长，对建模人员的能力要求也非常高。维度建模 是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能，针对性强。其次范式建模适合业务比较稳定的公司，而政采云的业务还在不断的迭代升级，故而我们采取维度建模。
4 模型重构实施
整体流程可以分为三个步骤，分别是信息调研（也叫业务梳理）、模型设计、模型实施，如图所示。
4.1 信息调研
- 新模型需要兼容现在的使用场景，所以梳理现有数据模型，另外在梳理的过程中会帮助我们收集用户数据需求，加深对业务的理解。
- 业务调研帮助我们更好的理解业务和数据，明确本阶段数据建设的需求、内容和边界。
- 收集业务和分析师需求才能了解模型当前和以后应用的场景，面对不同的使用场景，建模的方法论和设计是不同的。
- 数据嗅探主要的作用是对需要建设的数据源做整体摸排，把握业务数据的细节。这一步很重要，因为业务系统的复杂性和不断迭代升级的业务模型，常常会造成业务数据库数据异常。通过对数据的探查校验才能准确完整的把握业务。
4.2 模型设计
-
数仓分层
目前政采云的数据仓库主要分为 4 层，ODS (贴源层)、 DWD&DIM (模型层)、 DWS (汇总层)和 ADS （应用层）， DWD&DIM (模型层)是数据仓库的建模核心层，通过数据清理、公共逻辑处理、标准统一、退化维度等手段将数据有序的组织和存储起来，屏蔽底层业务变更对数仓上层应用带来的影响，以便数据仓库在性能、成本、效率、质量之间达到最优解。
-
数仓规范
数仓规范是数仓实施最重要要素，也是衡量数仓标准的重要条件；它是对数据管理的全流程进行约束，以保证数据管理工作的有序、高效、高质量的开展。
-
数仓命名规范：统一各种业务术语和命名规范，保证在数仓所有地方是相同的含义。
-
表命名规范
- ods 层：ods_ {源业务库名}_ {源表名}_[分区存储信息]
- dim 层：dim_{业务线} _{主题域} _{维度} _[分区存储信息]
- dwd 层：dwd_{业务线} _{主题域} _{业务过程} _[分区存储信息]
- dws 层：dws _{业务线} _{主题域} _{维度} _{业务过程} _[分区存储信息]
-
字段命名规范
- 英文字母小写
- 下划线分割
- 禁止使用 SQL 关键字
- 数量字段后缀 _cnt 、时间字段后缀 _time 等
- 常用缩略词等
-
任务命名规范：同表命名规范，保证任务和表是一体的，以便表血缘关系分析
-
-
模型设计规范：规范化设计能够减少冗余，避免数据不一致。
-
数据开发规范：明确规范避免多人协作过程中的理解的成本。
- NULL 字段处理
- 单位统一
- 枚举值映射统一
- 字段格式
- 数据存储规范
- 脚本开发规范等
-
-
建模流程
-
选择业务过程
在明确了业务需求后，需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程。在选择了业务过程后，相应的事实表类型也就随之确定了。
以政采云交易业务为例，一次订单交易行为、一次协议签署行为等都可以理解为一个业务过程。
-
-
声明粒度
粒度传递的是与事实表度量有关的细节层次，精确定义事实表的每一行所表示的业务含义（即主键的确定）， 明确的粒度能确保对事实表中行的意思理解不会产生混淆，保证所有的事实按照同样的细节层次记录。
以政采云交易业务为例，交易订单业务过程，一个订单为粒度；订单商品中一个订单中一个商品项也为粒度。
-
确认维度
完成了主键的确定，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。
以政采云交易业务为例，交易订单的采购区划、采购机构、交易时间、交易方式等都属于维度。
-
确认事实
事实是用来描述业务过程的度量。事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。
以政采云交易业务为例，交易订单事实表中包含订单支付金额、支付运费等同粒度。
-
冗余维度
在模型设计中，考虑更多的提高下游用户的使用效率，降低数据获取的复杂性，减少关联表的次数，通常会在事实表中冗余下游用户高频次使用的维度。
以政采云交易业务为例，为了减少关联表次数，交易订单事实表中冗余供应商的店铺、供应商单位名称、付款方式等，交易订单商品事实表会冗余商品品牌、商品评价状态等维度。
4.3 模型实施
- 模型开发阶段：将物理模型落地，过程中还需要考虑程序的性能和复杂度，发现原有模型设计的不足并及时反馈修正模型。总之整个模型重构过程是一个螺旋迭代模式，不断的修正更新。
- 任务部署阶段：严格按照任务依赖关系配置依赖，添加任务的数据质量监控保证模型输出数据质量的可靠性。
- 元数据维护阶段：确保业务人员快速上手，模型更快的推广出去。
- 替换老模型阶段：替换新老模型以后数据的⽐对，尽量确保数据的完全⼀致，若不一致也要排查出原因，然后确保下游没有使用，删除老的模型。
5 总结
通过采取维度建模和仓库分层理论进行模型重构建设，星型明细模型+多维指标汇总的方式使得数据仓库的数据越来越丰满，数据管理更加清晰明了，不但能满足公司用户快速取到想要数据的需求，而且能满足业务无法预期的个性化分析诉求，数据仓库发挥的价值也越来越高。 数据模型 没有唯一解，只有最优解，贴合公司分析场景才是最重要的。它也不是一成不变的，它是随着业务的升级变更而不断迭代变化的，所以模型升级是一个长期繁琐的工作。
推荐阅读
招贤纳士
政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com
微信公众号
文章同步发布，政采云技术团队公众号，欢迎关注
