Spark Relational Cache实现亚秒级响应的交互式分析

本场视频连接：https://developer.aliyun.com/live/1548?spm=a2c6h.12873581.0.0.71671566Xloy3Z&groupCode=apachespark

本场PPT资料：https://www.slidestalk.com/AliSpark/SparkRelationalCache2019_57927

本次分享主要分为如下四个方面：

1. 项目介绍
2. 技术分析
3. 如何使用
4. 性能分析

1、项目介绍

项目背景

阿里云EMR是一个开源大数据解决方案，目前EMR上面已经集成了不少开源组件，而且组件数量也在不断的增长中。EMR下层能够访问各类各样的存储，好比对象存储OSS、集群内部自建的HDFS以及流式数据等。用户能够利用EMR处理海量数据和进行快速分析，也可以支持用户在上面作机器学习以及数据清洗等工做。EMR但愿可以支撑很是大的业务数据量，同时也但愿可以在数据量不断增加的时候，可以经过集群扩容实现快速数据分析。

云上Adhoc数据分析痛点

在云上作Adhoc数据分析的时候，很难实现随着数据量的增加使得查询的延迟不会大幅度增长。虽然目前各类引擎不断出现，而且某些引擎在一些场景下运行很快，可是数据量变大以后，查询响应速度不免有所降低，所以但愿在比较统一的平台之上得到较好的性能。与此同时，阿里云也但愿可以提供云原生的解决方案。Spark是目前工业界使用较多的计算引擎，应用很是普遍，可是在处理Adhoc上仍是存在不少不足之处，所以阿里云在Spark上作了大量优化，帮助用户知足Adhoc查询的需求。所以就会涉及到缓存方案，虽然Spark中很早就有了缓存机制，但想要知足云上Adhoc场景却存在不少不足之处，所以阿里云会在Spark上作大量优化，帮助用户优化Adhoc查询速度。可是若是把数据放到内存中，将全部数据所有用做缓存可能也不足够，所以就催生出了Spark Relational Cache。

Spark Relational Cache

用户的SQL请求过来以后，到了Spark上面，会须要比较长的时间在数据来源上进行处理，这里下层的存储包括集群的HDFS以及远端的JindoFS和阿里云OSS等。当有了Spark Relational Cache以后，查询过来以后会查询是否可以用到存储在Relational Cache中缓存的数据，若是不能用到则会转发到原生路径上，若是能用到则会用很是快的速度从缓存里面将数据读取出来并将结果返回给用户。由于Relational Cache构建在高效存储之上，经过用户的DDL将数据变成Relational Cache。

Spark Relational Cache特色

Spark Relational Cache但愿可以达到秒级响应或者亚秒级响应，可以在提交SQL以后很快地看到结果。而且也支持很大的数据量，将其存储在持久化的存储上面，同时经过一些匹配手段，增长了匹配的场景。此外，下层存储也使用了高效的存储格式，好比离线分析都会使用的列式存储，而且对于列式存储进行了大量优化。此外，Relational Cache也是用户透明的特性，用户上来进行查询不须要知道几个表之间的关系，这些都是已经有过缓存的，不须要根据已有的缓存重写Query，能够直接判断是否有可使用的Relational Cache，对于一个厂商而言只须要几个管理员进行维护便可。Spark Relational Cache支持自动更新，用户不须要担忧由于插入了新的数据就使得Cache过期致使查询到错误的数据，这里面为用户提供了一些设置的规则，帮助用户去进行更新。此外，Spark Relational Cache还在研发方面，好比智能推荐方面进行了大量探索，好比根据用户SQL的历史能够推荐用户基于怎样的关系去创建Relational Cache。

2、技术分析

阿里云EMR具备不少核心技术，如数据预计算、查询自动匹配以及数据预组织。

数据预计算

数据在不少状况下都有一个模型，雪花模型是传统数据库中很是常见的模型，阿里云EMR添加了Primary Key/Foreign Key的支持，容许用户经过Primary Key/Foreign Key明确表之间的关系，提升匹配成功率。在数据预计算方面，充分利用EMR Spark增强的计算能力。此外，还经过Data Cube数据立方来支持多维数据分析。

执行计划重写

这部分首先经过数据预计算生成预计算的结果，并将结果存储在外部存储上，好比OSS、HDFS以及其余第三方存储中，对于Spark DataSource等数据格式都支持，对于DataLake等热门的存储格式后续也会添加支持。在传统数据库中有相似的优化方案，好比物化视图方式，而在Spark中使用这样的方式就不合适了，将逻辑匹配放在了Catalyst逻辑优化器内部来重写逻辑执行计划，判断Query可否经过Relational Cache实现查询，并基于Relational Cache实现进一步的Join或者组合。将简化后的逻辑计划转化成为物理计划在物理引擎上执行。依托EMR Spark其余的优化方向能够实现很是快速的执行结果，而且经过开关控制执行计划的重写。

自动查询匹配

这里有一个简单的例子，将三个表简单地Join在一块儿，通过过滤条件得到最终的结果。当Query过来以后先判断Spark Relational Cache是否可以符合需求，进而实现对于预先计算好的结果进行过滤，进而获得最终想要的结果。

数据预组织

若是将数十T的数据存在存储里面，那么从这个关系中获取最终的结果还须要很多的时间，由于须要启动很多的Task节点，而这些Task的调度也须要很多的开销，经过文件索引的方式将时间开销压缩到秒级水平，能够在执行时过滤所须要读取的文件总量，这样大大减小了任务的数量，这样执行的速度就会快不少。由于须要让全局索引变得更加有效，所以最好让数据是排过序的，若是对于结构化数据进行排序就会知道只是对于排列在第一位的Key有一个很是好的优化效果，对于排列在后面的Key比较困难，所以引入了ZOrder排序，使得列举出来的每一个列都具备同等的效果。同时将数据存储在分区表里，使用GroupID做为分区列。

3、如何使用

DDL

对于简单的Query，能够指定自动更新的开关，并起一个名字方便后续管理。还能够规定数据Layout的形式，并最终经过SQL语句来描述关系，后续提供给用户WebUI同样的东西，方便用户管理Relational Cache。

数据更新

Relational Cache的数据更新主要有两种策略，一种是On Commit，好比当依赖的数据发生更新的时候，能够将全部须要添加的数据都追加写进去。还有一种默认的On Demand形式，用户经过Refresh命令手动触发更新，能够在建立的时候指定，也能够在建立以后手工调整。Relational Cache增量的更新是基于分区实现的，后续会考虑集成一些更加智能的存储格式，来支持行级别的更新。

4、性能分析

Cube构建

阿里巴巴的EMR Spark对于1T数据的构建时间只须要1小时。

查询性能

在查询性能方面，SSB平均查询耗时，无Cache时查询 时间按Scale成比例增长，Cache Cube后始终保持在亚秒级响应。

相关文章：EMR Spark Relational Cache 利用数据预组织加速查询

阿里云双11领亿元补贴，拼手气抽iPhone 11 Pro、卫衣等好礼，点此参与：http://t.cn/Ai1hLLJT

---

本文做者：开源大数据EMR

阅读原文

本文为云栖社区原创内容，未经容许不得转载。