数据仓库到底需不需要主键？

        本人也是刚开始从事数仓工作不到半年，在做数仓的时候发现一个问题，就是从来没有人和我添加主键，即使数据量庞大，也没有人说添加主键、索引等。这也引发了我的思考，因为在编写SQL的时候我们习惯就是在查询时间过长的时候给SQL添加主键索引，缩短查询时间，那数仓为什么不需要呢？

         数据仓库的主键问题，经过查找资料与业内同事讨论，结果发现这份资料比较正确，这里整理出来给大家分享。    

---

1. 什么是主键，需要提及一个基本的数据库概念，那就是范式。设计数据库的关系模型时，一定要满足某些规则，来降低数据库中的数据冗余，而这些规则就称之为范式。范式共有五级范式，级别越高，数据冗余越小。一般来说，数据库设计满足第三范式是最普遍的要求。  其中，第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。  在数据库中，为了实现第二范式的要求，主键就诞生了。  可以看得出来，主键的作用是为了降低数据冗余存储，并对数据模型进行约束，防止破坏数据模型操作的执行。比如级联数据的更新删除操作时拒绝执行的。另外，通常我们为了加速检索过程，在主键上建立各种索引，如B-TREE或Hash，加快了数据库操作的效率，且保持了实体的完整性。  可以看出在传统关系数据库系统中，主键的作用非常重要，即保证了实体完整性，提高了主键检索效率。

 

2. 主键给数据仓库带来的问题  数据仓库的系统，与传统系统的区别还是很大的。传统系统是面向交易的在线数据，需要进行频繁的事务型操作，而数据仓库存储的一般是历史数据。  由于一些开发人员的习惯，以及数据库使用惯性等原因，在一些数据仓库的系统中频繁使用主键。实际上在大数据时代的数据仓库场景下，主键有些用法值得我们重新考量。  

 如果我们在数据仓库建设中，向传统数据库中的一样去使用主键，会出现什么效果呢？以下从几点上给出分析：

• 管理成本  主键在数据库内部需要有数据库引擎自己维护，这在数据量较小的交易类系统中，问题不大。但是在大数据量的数据仓库中，维护主键会给引擎带来很大的管理压力。  
• 存储空间  为了加快数据库的检索效率，数据库引擎通常会在建立表的过程中，将主键自动建立索引。一般索引，像是B-TREE、Hash等索引类型，膨胀率都会在1.5~2倍左右。这给系统磁盘空间带来巨大的存储压力，从而降低磁盘的存储和计算（I/O）效率。由其在大数据环境下，这个问题尤为突出。  
• 查询效率  数据仓库多为分析类的查询场景，因此，很多数据库引擎都会选择列存来面对数据仓库的查询请求。而主键的设计是面向对象（行存）的，因此主键会降低列存本身的查询优势。且在数据操作时，主键会对唯一性进行校验，校验需要逐条进行，虽然有索引进行优化，但是这在大表（几十亿至上百亿）中进行操作的话，会造成严重的性能问题。这实际上不是主键的问题，而是索引的问题。数据量越大，索引结构越复杂，性能问题越明显。而如果不要索引，性能更会无法接受了。  
• ORACLE数据库，主键一般设置CODE这种，查询维度表一般取文本描述或者其他属性，加主键执行计划一般就走UNIQUE索引了，数据量大的情况，回表代价大下不如全表扫描，可以多块读，我觉得这个也是OLAP事实表不加主键的原因之一，所以维度表也根据数据量判断就好了，少你就加，多就不加

3. 需求如何满足  从上面来看，主键似乎在数据仓库系统中，有些水土不服。那么什么情况下数据仓库需要用主键呢？是否有其他可选方案？  实际上，数据仓库中使用主键，无非是以下几种情况：

• 保持唯一性  对于一些维度表，需要保持维度属性的唯一性。

这种情况下，对于维度表的更新操作，可以在确定唯一字段上，建立精确查询索引（通常是Hash），以保证效率。操作前先查询，如果存在就update，如果不存在就insert。

• 数据重复加的问题  数据仓库存储的是各种历史数据，数据来源是不同的业务数据系统。

为了避免重复加数据的问题，可以在数据入库前，对不同来源的数据进行清洗、合并，提高数据质量，之后再统一入库。

• 进行事务性操作

 这个貌似不是数据仓库该干的事，还是建议读写分离，事务型的场景还是选用传统数据库比较靠谱，数据仓库专门做专题分析。  

•  业务设计就是需要

那就没办法了。。。。