数仓设计要点：反三范式
提到数仓，一般做技术的首先会想到是大数据，ETL，Hadoop，Hive，HBase等之类的技术名词。之前一些RD问我海浪数仓是怎么设计的时候，我一般也是这么简单回答的。但是，仔细思考一下，这些只能算是数仓设计之形，而非魂之所在。只要设计得要点，MySQL，Excel，甚至文本文件皆可为数仓所用。那数仓设计的核心到底是什么呢？在讨论这个问题之前，我们先把数仓设计放一边，回过头来看一下数据库设计或者更准确一点，关系型数据库设计的核心要点。因为大部分程序猿都是做事务型（OLTP）系统开发的，而数据库设计是其底层模块。关系型数据库的核心的设计原则是遵循三范式设计。有些RD虽然已经忘记了三范式的概念，但在设计数据库时依然会遵循。因为这些已经转化为我们的肌肉记忆。先简单回顾下三范式的概念：1NF：数据库表的每一列都是不可分割的原子数据项；2NF：在1NF的基础上，非码属性必须完全依赖于候选码；3NF：在1NF基础上，任何非主属性不依赖于其它非主属性。说的简单一点，1NF：列不可分；2NF：行必须有主键；3NF：避免字段冗余。
回头看一下我们之前设计的数据表，是不是大部都满足三范式要求的（即使我们设计时可能压根不去考虑什么三范式）。没错，经验越丰富的程序猿，这些基础的方法论会越深刻的烙印在我们的思维系统中。这是优势，但是当转到另一个领域面对另一个设计问题时，它就变成了劣势。比如数仓。
数仓，并不服务于OLTP（On-Line Transaction Processing，联机事务处理）领域，而是OLAP（On-LineAnalytical Processing，联机分析处理）领域。
OLTP领域系统的核心是事务处理，它决定了其底层数据方案必须满足三范式设计。一个用户在用户表中只能有一条记录，并且有一个ID来唯一标识一个用户；性别字段就只记录男或女，而不会再记录年龄等其他信息；并且性别字段只会存在于用户表中，其他表可以通过用户ID关联用户表获取用户性别。
OLAP领域系统的核心则是分析处理。分析是面向主题的（比如用户分析，订单分析），主题是分析的基本单元，数据会向主题汇集，并且它是有时间轴的，数据会在时间轴上固化，因此不需要事务机制来保证数据更新的一致性。OLAP领域的特点决定了数仓设计不需要满足三范式要求，甚至是反三范式的。数据是可以冗余的，且会有意引入冗余。
最后简单总结下数据库设计和数仓设计的区别：1. 数据库是面向事务的设计；数据仓库是面向主题的设计。2. 数据库设计是尽量避免冗余，遵循三范式设计规则；数据仓库在设计时会有意引入冗余，采用反三范式的方式来设计。3. 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。4. 数据库中的数据会实时变化，通过事务机制保证数据更新的一致性；数据仓库中的数据相对稳定，以查询为主。
页:
[1]