数据仓库模型设计开发流程与规范.pdfVIP

版本：V1.1 最后修改日期：2021/03/23 微信公众号：码上观世界 1. 数据模型设计目标 为使下游数据使用方低成本获取一致性的可靠数据服务，数据模型设计方需要达 到如下目标： 成本：模型设计者要平衡性能和成本要素对数据模型的影响，现有海 量大数据情况下，以保障业务和性能为前提，合理使用数据模型方案和存 储策略，尽量消除不必要的数据复制与冗余。 性能：模型设计者需要兼顾模型刷新性能开销、产出时间和访问性 能。 数据一致性及数据互通：各个数据模型或者数据表之间必须保障数据 输出的一致性，相同粒度的相同数据项 （指标、维度）应具有相同的字段 名称和业务描述，不同算法的业务指标应显性化区分。 数据质量：数据公共层模型需要屏蔽上游垃圾数据源，一方面要保障 数据本身的高质量，减少数据缺失、错误、异常等情况的发生；另一方面 要保障其对应的业务元数据的高质量，数据有明确的业务含义，为数据提 使用者供正确的指引。 易用：在保障以上目标的前提下，数据用户能从业务角度出发快速找 到所需数据；能较快的掌握模型的适用场景和使用方法；能相对便捷获取 数据。 2. 数据模型设计指导思想 数据模型设计以ER模型、维度模型和宽表模型理论为指导以及阿里巴巴数据仓 库建设实践为经验参考。 2.1 ER模型 数据仓库之父Bill lnmon 提出的建模方法是从全企业的高度设计一个3NF 模 型，用实体关系 （ Entity Relationship, ER ）模型描述企业业务，在范式理论 上符合3NF 。数据仓库中的3NF 与OLTP 系统中的3NF的区别在于，它是站在 企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽 象。其具有以下几个特点： 需要全面了解企业业务和数据。 实施周期非常长。 对建模人员的能力要求非常高。 2.2 维度模型 数据仓库领域的Ralph Kimball 大师所倡导的，维度建模从分析决策的需求出发 构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析， 同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在 一些特殊场景下使用的雪花模型。维度模型的维度退化即是宽表模型。 ER模型是一种范式模型，ER模型和维度模型虽然建模工具类似，比如都使用实 体关系来表示，主要区别在于： 1. 着眼点不同：维度建模着眼点在产生事实的业务过程，ER模型着眼点在实体 和实体的关系，ER模型的关系更为一般化。 2. ER模型的实体通常是具有业务价值的业务对象，比如商品，客户等，维度模 型的维度更着重业务检索需求，如日期、地域、商品等，如下图示例。 3. 数据模型设计基本原则 高内聚和低耦合：软件设计方法论中的高内聚和低耦合原则同样适用 于数据建模，这主要从数据业务特性和访问特性两个角度来考虑：将业务 相近或者相关的数据、粒度相同数据设计为一个逻辑或者模型；将高概率 同时访问的数据放一起，将低概率同时访问的数据分开存储。 核心模型与扩展模型分离：建立核心模型与扩 展模型体系，核心模型 包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少 量应用的需要，必要时让核心模型与扩展模型做关联，不能让扩展字段过 度侵入核心模型，破坏了核心模型的架构简洁性与可维护性。 公共处理逻辑下沉及单一：越是底层公用的处理逻辑更应该在数据调 度依赖的底层进行封装与实现，不要让公共的处理逻辑暴露给应用层实 现，不要让公共逻辑在多处同时存在。 成本与性能平衡：适当的数据冗余换取查询和刷新性能，不宜过度冗 余与数据复制。 数据可回滚 （数据生成支持幂等性）：处理逻辑不变，在不同时间多 次运行数据结果确定不变。 一致性：相同的字段在不同表字段名相同，字段值相同。 命名清晰可理解：表命名规范需清晰、一致，表名需易于下游理解和 使用。 4. 数据模型设计步骤总览 4.1 数据模型设计总体步骤 业务建模：生成业务模型，主要解决业务层面的分解和程序化，常用