数据模型如何论好坏

|0x00 数据模型的选择

最常见提到的有四种：范式、维度、DataVault、Anchor。在传统行业中，范式很流行，在互联网行业中，维度很流行，另外两种就“只闻其名,不见其人”了。

如果论这四种方法，在设计思路上的好坏，那么各有千秋。但如果问，那种模型最为成熟，那么恐怕范式和维度就胜出了，而互联网行业几乎只能选择维度建模，因为它的实践经验是最多的。

这就有点像软件或者框架的比较，Hadoop就一定好吗？Java就一定优于Python吗？并不是。但Hadoop一定最成熟，Java岗招聘人数最多。因为生态建立了起来，用的人多了，方法论就成熟了，用起来就顺手了。

但是，谈数据模型前，先要看数据架构的好坏。

|0x01 数据架构的评价标准

数据架构，严格意义上，也是一个系统，只不过是“数据系统”。因此，能用在系统上的标准，如响应速度、可复用性、稳定性、健壮性等，也可以用在数据架构的评价上。但与应用类系统不同的是，数据系统面向的是决策，而不是需求，因此响应速度、可复用性就强调的更多一点。

• 响应速度：数据架构的主要场景包括：业务开发、数据产品、运营分析三大类，不论是那种场景，数据架构均应该在尽可能短的时间内响应需求；
• 可复用性：只有复用能力上来了，响应速度才能提上来，体现在下游依赖、调用次数、核心字段覆盖率等指标上；
• 稳定性：除了日常任务不出问题以外，一旦发现了问题，能在多短的时间内定位和恢复问题，就非常重要；
• 健壮性：除了电商等已经耕耘多年的领域外，绝大多数业务模型，都会快速的变化，如何适应这种变化，就非常考验架构功底。

|0x02 数据模型的评价标准

数据模型建设的怎么样，极度依赖规范，如果代码风格是“千人前面”，那么恐怕半年下来，业务系统就没法看了。没有什么比“数据系统”更看重“法制”了，规范体系不仅能保障数据建设的一致性，也能够应对业务交接的情况，更能够为自动化奠定基础。

• 业务过程清晰：ODS就是原始信息，不修改；DWD面向基础业务过程；DIM描述维度信息；DWS针对最小场景做指标计算；ADS也要分层，面向跨域的建设，和面向应用的建设；
• 指标可理解：按照一定业务事务过程进行业务划分，明细层粒度明确、历史数据可获取，汇总层维度和指标同名同义，能客观反映业务不同角度下的量化程度；
• 核心模型相对稳定：如果业务过程运行的比较久，过程相对固定，就要尽快下沉到公共层，形成可复用的核心模型；
• 高内聚低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。

| 0xFF 持续建设的先进性

即便是维度模型，在业务高速发展的今天，也难以适应所有的引用场景。例如面向物流、面向财务、面向企业，数据解决方案的争论，一直没有停息过。维度模型虽然在过去是先进性的代表，拥有大量成熟的实践方法论和响应的工具，但是其核心思想：数据域，业务过程，粒度，维度，度量，事实等，随着业务复杂度的进一步提高，实际的模型设计过程已经在逐渐淡化这些数仓概念，大宽表、冗余所代表的的好用思想，也逐渐成为主要的设计思路。

所以不光要有方法论的支撑，由先进技术体系支撑的系统产品，也应该被逐步的建立起来，甚至是在云计算普遍成熟之后，下一代的核心产品。

这么看来，数据开发，未来也可能被自动化的工具所替代，好可怕... ...