数仓建模方法简要总结

背景：

因近期境外银行业务全面提速，各种业务项目、建站项目并行推进，数据团队数据资产建设的需求也接踵而至，但我们一直跟随业务快速开发迭代，数据资产特别是中间层资产缺少统一的方法指导，造成各个项目负责同学被动建设，数据资产无法体系化，为后续使用和维护上带来很多困难，所以本次先从数仓建模方法方面为大家进行简单的总结介绍，希望帮助大家形成相对统一的数仓建模方法论。

常见的两种数仓建模理论：

【维度建模】

维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作；但是这种建模方法缺点很明显，随着业务复杂度的增加以及分析的不断深入，复杂的维度需求导致数据体系混乱，增大了使用和维护的成本；强制一致的维度也会造成信息上的丢失，更容易造成数据口径问题；

所以维度建模比较适合的是数据统计指标的计算场景，适合聚合统计指标而不是聚合属性信息。

【实体关系建模】

实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。

实体关系模型是业务系统数据建模经常采用的方法，所以数仓层面往往是采用基于主题域的实体关系建模方法，也是目前大多数数仓模型设计的基础，大家会在不同的数仓层次上基于实体对象进行模型的设计；

需要注意的是，业务系统往往从对象抽象层次对数据模型进行发散，形成了星型的或者雪花型的网络结构，如果数仓基于这种结构设计，信息会太过于分散，加工的链路太长，关系复杂度比较高，缺少了易用性。

各个层次适用的建模方法：

后期的迭代优化：

【一句老话：跑步前进，快速休整】

在当前数据计算与存储成本越来越小的情况下，数仓数据资产的完整性和易用性就成为最核心的关注点；前期的模型设计主要用于框架的搭建，解决一些核心的信息整合问题，更多考虑的是易用性，在后续过程中进行快速迭代，达到提升完整性的目的；

【保持中间层相关主体的结构稳定和业务层次的稳定】

关于迭代优化，在快速交付过程中，肯定会出现各种完整性问题导致的重复开发，这就需要维护人员进行定期的迭代优化，如何降低迭代优化的成本，需要的是保持中间层相关主体的结构稳定和业务层次的稳定性，所以大家要统一建模思想和目标，在实际工作开发过程中，减少对数仓模型稳定性的影响，降低迭代优化成本，从而保证数仓数据资产建设的质量和效率。