Presto架构原理与优化介绍 | 青训营笔记

这是我参与「第四届青训营」笔记创作活动的的第9天

上节课我们学习了Shuffle原理，明白了Shuffle的架构和发展历程，今天我们来学Presto架构

概述

大数据的概念大家想必都已经非常熟悉了，这里再强调一下，关于大数据这里我们参考马丁·希尔伯特的总结：

大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据

再来介绍一下Hadoop，Hadoop是基于廉价机器的存算分离的大规模分布式处理系统

再来介绍一下OLAP，OLAP是对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术

与Mapreduce Job想必，OLAP引擎常通过SQL的形势，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化

常见的OLAP引擎

Presto 最初是由Facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎，其具有如下的特点：

先来介绍一下下图的各种作用

Query:基于SQL parser后获得的执行计划
Stage：根据是否需要shuffle将Query拆分成不同的subplan，每一个subplan便是一个stage
Fragment:基本等价于Stage，属于在不同阶段的称呼，在本门课程可以认为两者等价
Task:单个Worker节点上的最小资源管理单元：在一个节点上，一个Stage只有一个Task,一个Query可能由多个Task
Pipeline:Stage按照LocalExchange切分成若干Operator集合，每个Operator集合定义一个Pipeline
Driver:Pipeline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator
Spilt：输入数据描述，数量上和Driver一一对应，不仅代表实际数据源spilt,也代表了不同stage传输的数据
Operator：最小的物理算子

Exchange:表示不同Stage间的数据传输，大多数意义下等价于Shuffle
LocalExchange:Stage内的rehash操作，常用于提高并行处理数据的能力（Task在Presto中只是最小的容器，而不是最小的执行单元）

Presto架构图如下

优点：轻量的Query级别的多级队列资源管理模式

缺点：存在一定滞后性，只会对Group中正在运行的SQL进行判断

AllAtOnceExecutionPolicy:延迟点，会存在任务空跑

PhasedExecutionPolicy：有一定延迟、节省部分资源

Task的数量如何确定：

将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行

局限性：