Apache Hive 3.0之物化视图 Part1

“

说到物化视图的生产应用，一切的原动力来自于2001年Jonathan和Per-Ake 两位大神在微软发表的一篇论文

Optimizing Queries Using Materialized Views: A Practical, Scalable Solution.

有兴趣的同学可以读一下这篇Paper。

”

物化视图是在当今的SQL On Hadoop领域一个比较令人期待的重要特性，属于数据库的高级功能，在传统的数据库领域基本已经都实现了物化视图, 但是在SQL On Hadoop领域里支持这个特性的还不多。引入物化视图的目的是为了优化数据访问的效率，从数据组织层面优化数据访问效率最常见的有下面几个方向：

1. 改变数据的物理分布，例如分布和排序等等；

2. 数据模型的反范式化；

3. 数据预处理；

随之而来的产生的问题也有很多，例如需要手工创建新表，业务SQL迁移和新旧表，聚合表与基表之间的一致性维护等等。物化视图属于数据预处理，同时对上层业务透明，也就是不需要进行业务SQL迁移。

为了做到对上层业务透明，在SQL解析层面就需要解析器具备识别物化视图并且重写SQL的能力。Apache Hive 3.0 里的物化视图实际上是基于Apache Calcite 项目的实现。具体可从下面的官方页面获得具体描述：

http://calcite.apache.org/docs/materialized_views#rewriting-using-plan-structural-information

“

不得不提一下Julian Hyde 这位大神，Apache Calcite的主创人员，个人觉得他可以拿Hadoop领域的诺奖，如果有的话。可惜的是他离开了Hortonworks, 去了一家创业公司做C LEVEL去了。

”

01

物化视图建表的语法规范

在Apache Hive 3.0 里创建一个物化视图的语法规范如下：

从语法规范上，可以看到Apache Hive 3.0 目前不仅仅支持常见的ORC文件格式，同时还通过Storage Handler来支持其他数据存储，例如Druid. 这也是Apache Hive 3.0 的另一个特性，不过这并不在本文的讨论范围内，这里先略过。

02

视图，物化视图与SQL重写

在视图和物化视图的优化方向上，都存在SQL的后台重写工作。其区别是视图只是创建一个虚表，只有表结构，没有数据，实际查询的时候再去改写SQL去访问实际的数据表。

优点

上层的业务查询和底层数据表解耦，业务上可以查的一张表，但是底层可能映射的是三张或多张表的数据，修改底层数据模型只需要重建视图即可，不需要上层业务修改业务逻辑。

缺点

无法再对视图进行优化，而且并没有提升查询速度，只是使上层的业务逻辑变得更清晰简洁

物化视图，实际和视图是两个东西。它没有破坏上层的业务查询逻辑，而是从底层入手。由于物化视图里是一个物理表，因此SQL解析器对基于物化视图的SQL改写就非常重要了。

03

示例1： 简单Join

这个表是将员工表和部门表按部门ID join 的结果集。当有业务来查询的时候，比如查询2018年1月到3月的新入职人员和所在部门的信息：

虽然查询还是写的查询emps 和 depts 表按部门ID做Join 操作再过滤时间。但是因为Hive 知道有这个物化视图的存在，它会在后台把SQL改写成:

从业务的角度来看，他的查询是查两张表，但是在后台执行层面，实际是从物化视图表进行简单过滤操作得到的结果集。从而大大的提升了查询的响应时间，也省了很多计算资源。这就是物化视图的SQL重写。另外，不仅仅在查询范围全命中的情况下会改写SQL，部分命中的情况下也会改写SQL。

04

示例2： 星形模型

当业务需要查询

注意到这里mv的表是基于一个5张表的星型模型建立的，虽然在业务层面，查询的是lineorder和date 这两张表，但是，Hive会识别已有的物化视图，并且自动的把SQL改写成基于mv的查询。至于原理，就是Calcite这个项目和关系代数神教干的事。除了能在表级进行优化外，Apache Hive 3.0的物化视图还能判断数据粒度，更科学高效的利用已有数据来给出结果。

05

示例3：基于时间的单表聚合

业务查询的SQL为

而实际后台真正执行的SQL是

上面的三个例子基本展示了在Apache Hive 3.0 中物化视图的能力和使用方法，后续的篇章会在具体实现原理和运维管理上讲解。

BYE..