这是彭文华的第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、需要管理好，避免数据爆炸。
