• 视图

作为一篇科普文章，我们先从基本概念视图讲起。

数据库中，表是存储数据的实体，视图是表的一种展现形式。创建语句类似这样：

create view view_x as      // view_x是视图名称select col_a,col_b,col_d   // col_a是列名from table_x;              // table_x是基表

视图下面的表也被称为基表(base table)。对于视图与基表的关系，可以打个比方，如果你拍个短视频，可能会打开滤镜美化一下自己。那么，视图就是滤镜下的你，基表就是素颜的你。视图包含了一段SQL语句进行各种逻辑处理，就像磨皮、大眼、瘦脸等各种滤镜特效。如果删除基表的数据，那视图中也就看不到对应的数据了。

视图的优势有以下三点

1. 控制权限

2. 封装逻辑

3. 提升效率

通过视图查询与直接执行SQL查询相比，效率更高，因为在创建视图时，数据库内部通常有个类似预编译的动作，降低了SQL解析的开销。当然，某些数据库还有其他提升SQL加载效率的方式，这里不逐一展开。

虽然我们列举了上述优点，但视图并不是数据库的刚需。比如，在MySQL的早期版本中就没有提供视图，到了分布式数据库时代，在各厂的产品中视图也是明显滞后提供的特性。

• 物化视图（Materialized View）

虽然接触物化视图已经有十多年了，但直到本文落笔这一刻的时候，才第一次去考究它的字面含义。materialized是materialize的过去式，后者的含义是使具体化，成为现实。如果直译过来，就是“成为现实的视图”。这种翻译似乎还不得要领。用“物化”做修饰词，就高明太多了。物化，就是用来描述将抽象概念或想法转化为具体的实物或物质形式的过程。

代入文章开头我们对视图的说明，视图确实是抽象的，因为它依附于基表，是一种幻象而不是实体，基表消失则视图自然消失。而物化视图，它的功能就是将数据实际存储下来，不再依附于基表而存在，它存储数据的能力与基表没有区别。

优势

推敲完文字，我们再谈技术。物化视图继承了视图的优势，并在提升性能这点上更近一步。其背后的原理就不只是预编译了，而是物化视图会提前运行SQL将数据加工计算好，查询时直接读取结果数据即可，所以当视图逻辑比较复杂时，查询速度可能会快出很多倍。本质上和ETL就很类似了，都是预计算，都是用空间换时间来提升查询性能。

问题

物化视图和基表都存储数据，也就是意味着他们形成了两个副本，这就面临分布式系统的经典问题，如何保证多副本的一致性。保证一致性的策略可以是创建时强制同步或者定期刷新数据等。但总的来说，传统数据库没有形成高效的一致性保证机制，这也极大的限制了物化视图的使用场景。所以，即便经历了漫长的岁月，物化视图也并未为人所熟知。

• Doris物化视图

沉寂多年的物化视图，在大数据时代又被再次定义，很多新兴数据库都支持物化视图这一特性，其中Doris赋予了其新的意义，成为非常重要的特性。

新意义就是为物化视图和基表间的数据一致性设计了更好的保障机制。Doris内置了两者的异步同步机制，但也保证一致性。即在没有完成“物化”动作前，物化视图的查询会退化为类似普通视图，没有预计算结果，而是基于基表临时计算，所以性能降低但始终保证一致性。

还有一个有趣的设计是基于物化视图的查询改写功能。就是当用户提交查询语句后，系统会根据查询条件筛选出一个最优的物化视图，将查询的对象改为物化视图，利用物化视图的预计算结果数据提升查询性能。

从功能上看，Doris中的物化视图已经可以替代ETL处理过程，隐形完成了数据加工的过程。但是，物化视图主要是被动触发，完成单个独立的加工过程，完全胜任。但并不具备ETL任务所配套的强大调度工具，无法灵活对加工过程进行串接协同。所以，很可能还不否适合大范围使用。

最后，我们总结一下，物化视图是20多年的老物件，是具备实际数据存储的，依赖一定的同步机制保持与基表的数据一致性。Doris/StarRocks增强了一致性机制，物化视图可以始终保持与基表的数据一致，但性能上做了一定的妥协。