物化视图占存储空间吗？ by彭文华

这是彭文华的第143篇原创

最近选题都选神经了，就像一只在玩耍毛线团的猫，到处找线头。终于在一个群里看到有人问一个合适的问题了，我这是久旱逢甘霖哪！

刚看到这个问题的时候我都楞了一下。说起来这个问题我还是在 10 多年前研究的。那时候玩的是 Oracle 。这个问题的回答当然是肯定的，物化视图占存储空间。但我还想多扯两句，把这件事情掰开揉碎了讲一遍。大概是这么个思路吧：

视图是啥？解决啥问题？

物化视图又是啥？又解决啥问题？

大数据场景下，物化视图怎么用？

什么是视图？

既然都问这个问题了，那你肯定是个 SQL Boy 了。我们在跑数据的时候，通常要关联很多表。当业务逐渐复杂，表的数量变多的时候，表和表之间的关联关系就会非常非常的繁复。

为了让事情变的更简单，我们通常会把相对比较常用，且关系比较固定的几个表关联的内容固化下来，以后我们每次都用这个 SQL 脚本就好了。

各个数据库开发团队也发现这个强需求，就推出了一个“View 视图”的功能，这个视图本质上就是一个 Select 语句。我们查询这个视图，实际上就是做了一个嵌套查询， view 的名称恒等于子查询中的内容。

因为 View 就是一段 Select  语句，所以 View 几乎不占存储空间。

我们现在总结一下：View，视图，又叫虚拟表、虚表，主要作用是降低SQL复杂性，让代码工作更简洁。同时因为视图做了表间关系的聚合和字段的重命名，视图也有一定的安全性，外界访问的时候根本无法知道数据库的真实结构是怎样的。

更重要的是，因为其聚合的特性，视图在数据架构中有非常重要的意义，它可以作为基础表和上层SQL逻辑的解耦工具，规避基础表机构变更带来的上层SQL代码调整的问题。

视图在传统数据库中大量使用。而在大数据环境中，有时候也会使用。

什么是物化视图？

成也萧何败萧何，视图的核心能力其实就是它的核心问题所在。因为视图本质上只是一个 Select 语句，我们查询这个视图的时候实质上还是查询视图中定义的各个基础表。一旦这些关联关系稍微复杂一些、限定条件多一些，那就效率就完蛋了。

而且因为视图只是一段 SQL ，常规的一些建索引、分区分表等各种优化手段也就彻底失效了。

那我们能不能既保留视图的降低SQL复杂性、增强安全性和解耦架构等特性，又能规避效率低下的问题呢？当然是有的！这时候就该物化视图出场了。

物化视图，顾名思义，就是把视图物理化，变成一张类似于物理表的存在。所以，视图是“虚拟”的表，物化视图是“实在”的表。

创建物化视图和创建普通视图的语句几乎一样，就是把 View 改成materialized view 。只不过物化视图可多一个“更新频率”的参数，就是多久重新物化一次。

View 只是一个 SQL ，所以不存在数据更新的问题；但是物化视图不一样，他都已经落地成表了，不更新的话，数据永远都那样。

物化视图既然已经是张表了，那么就拥有表的一切特性，可以加索引，可以分区等等，当然也会占用存储空间了。所以物化视图是一个用空间换取时间，牺牲实时性，换取使用效率的绝佳方案！

物化视图怎么用

其实很多技巧在传统数据库的时代就已经很成熟了，既然这些方法这么好用，为啥不在大数据环境中也用上呢？

所以不仅仅是Oracle 、MySQL 、Postgre 等关系型数据库能做，现在Doris 、ClickHouse 等等各种大数据环境下的分析性数据库也都具备物化视图的功能。Hive 3.0 也增加了这个功能。

用起来呢，基本上都是一样的。反正原理是一样的，在不同组件**据他们的要求写一下就好了。

大致的语法就是：

 CREATE MATERIALIZED VIEW IF NOT EXISTS 物化视图名称

ON CLUSTER 集群名称，就是放在哪里

ENGINE = 指定引擎

PARTITION BY 分区字段

ORDER BY (排序字段)

SETTINGS 各种参数

AS 

SELECT

字段1,字段2，字段1*字段2 as 字段3

FROM 表名称 ，可以关联多个表

GROUP BY 聚合字段;

想在哪里用，就把上面的语法按照那个环境的要求稍微修改一下就可了。在Doris 、Clickhouse 、甚至 Spark 也支持物化视图了。

你看，是不是跟建表是一样一样的？

不过物化视图千好万好，但还是有三个问题不好解决：

1、前面说过，物化视图是牺牲实时性，换取查询效率的思路，所以数据更新机制是绕不过去的坎。物化视图毕竟还是在做数据物理化，所以必然会遇到数据多久更新一次的问题，更新时间要根据逻辑的复杂程度和数据量来决定。如果你的实时性要求很高，建议不要用；

2、物化视图毕竟还是有视图的特性的。所以根本没法执行类似“insert into”的语句往里插入数据，他实质是是“快照”性质。当然，删除数据也是没用的。所以他只适合 OLAP 的场景；

3、物化视图同时还是空间换时间的典范，所以这个不能多用，要不就泛滥成灾了。数据会爆炸的！存储空间爆发式增长，到时候就一发不可收拾了。

总结

视图是数据架构中解耦神器，可以屏蔽复杂逻辑，隐藏原始表结构，具有简化、解耦、安全等特性。但是视图本质上是一段 SQL ，所以效率上有很大的影响。

物化视图是基于视图的思路，进一步把视图的查询结果物理化成为一张实表，这样既能拥有视图的特性，又能规避效率的问题，是 OLAP 场景中非常好用的手段。

但是物化视图也有三个问题：

1、实时性欠缺；

2、只能刷新，无法增删改数据

3、需要管理好，避免数据爆炸。

扩展阅读：数据仓库建设全套资料包，公众号“大数据架构师”后台回复“数据仓库”即可获得。

配合以下文章享受更佳

干货 | 一口气讲完数据仓库建模方法

干货 | 如何搭建一个数据仓库

【资料包】 实时数仓架构选型资料包

【实战】 手摸手搭建一个实时数据仓库

【干货】 数仓到底要分多少层？

我需要你的转发，小小的满足一下我的虚荣心