最常提到的有这五种，范式，维度，E-R，DataVault，Anchor。关系数据库中范式很流行，大数据中维度模型很普遍，E-R模型在金融圈很常见，另外两种“只闻其名，不见其人”了。
如果讨论这五种方法在设计思路的好坏，那么肯定各有千秋。但如果问，数仓建模哪种模型最成熟，恐怕范式和维度就胜出了，而在大数据领域似乎只能选择维度建模，因为实践经验最多，也最成熟。
这就有点像软件或者框架的比较，Hadoop就一定完美吗？java性能就一定由于python吗？并不是。但是Hadoop市场普及率最高，java岗招聘人数最多。因为生态建立起来了，用的人多了，方法论成熟了，就好用了。
数据架构，严格意义上，也是一个系统，只不过是“数据系统”。因此，能用在系统上的标准，如响应速度、可复用性、稳定性、健壮性等，也可以用在数据架构的评价上。但与应用类系统不同的是，数据系统面向的是决策，而不是需求，因此响应速度、可复用性就强调的更多一点。
响应速度：数据架构的主要场景包括：业务开发、数据产品、运营分析三大类，不论是那种场景，数据架构均应该在尽可能短的时间内响应需求；可复用性：只有复用能力上来了，响应速度才能提上来，体现在下游依赖、调用次数、核心字段覆盖率等指标上；稳定性：除了日常任务不出问题以外，一旦发现了问题，能在多短的时间内定位和恢复问题，就非常重要；健壮性：除了电商等已经耕耘多年的领域外，绝大多数业务模型，都会快速的变化，如何适应这种变化，就非常考验架构功底。
数据模型建设的怎么样，极度依赖规范，如果设计风格是“千人前面”，那么恐怕半年下来，业务系统就没法看了。没有什么比“数据系统”更看重“法制”了，规范体系不仅能保障数据建设的一致性，也能够应对业务交接的情况，更能够为自动化奠定基础。
业务过程清晰：ODS就是原始信息，不修改；DWD面向基础业务过程；DIM描述维度信息；DWS针对最小场景做指标计算；ADS也要分层，面向跨域的建设，和面向应用的建设；指标可理解：按照一定业务事务过程进行业务划分，明细层粒度明确、历史数据可获取，汇总层维度和指标同名同义，能客观反映业务不同角度下的量化程度；核心模型相对稳定：如果业务过程运行的比较久，过程相对固定，就要尽快下沉到公共层，形成可复用的核心模型；高内聚低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。
即便是维度模型，在业务高速发展的今天，也难以适应所有的引用场景。例如面向物流、面向财务、面向企业，数据解决方案的争论，一直没有停息过。维度模型虽然在过去是先进性的代表，拥有大量成熟的实践方法论和响应的工具，但是其核心思想：数据域，业务过程，粒度，维度，度量，事实等，随着业务复杂度的进一步提高，实际的模型设计过程已经在逐渐淡化这些数仓概念，大宽表、冗余所代表的的好用思想，也逐渐成为主要的设计思路。
所以不光要有方法论的支撑，由先进技术体系支撑的系统产品，也应该被逐步的建立起来，甚至是在云计算普遍成熟之后，下一代的核心产品。