这是我参与「第四届青训营 」笔记创作活动的第10天
Presto架构原理与优化介绍
01.概述
Hadoop： 基于廉价机器的存算分离的大规模分布式处理系统
OLAP： 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。
OLAP核心概念：维度，度量
Presto设计思想：
Presto最初是由Facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎，具有以下特点：多租户任务的管理于调度、多数据源联邦查询、支持内存化计算、Pipeline式数据处理。
02.Presto基础原理和概念
服务相关：
- Coordinator（负责调度）：
解析SQL语句
⽣成执⾏计划
分发执⾏任务给Worker节点执⾏
- Worker ：
在一个presto集群中，存在一个coordinator节点和多个worker节点，coordinator节点是管理节点，而worker节点就是工作节点，在每个worker节点上都会存在一个worker服务进程，该服务进程主要进行数据的处理以及task的执行，worker服务进程每隔一定的时间都会向coordinator上的服务发送心跳，接受调度。当客户端提交一个查询的时候，coordinator则会从当前存活的worker列表中选择出适合的worker节点去运行task，而worker在执行每个task的时候又会进一步对当前task读入的每个split进行一系列的操作和处理
- Discovery Service（将coordinator和woker结合到一起的服务）:
Worker节点启动后向Discovery Server服务注册
Coordinator从Discovery Server获得Worker节点
所有的worker都把自己注册到Discovery Server上，Discovery Server是一个发现服务的service，Discovery Server发现服务之后，coordinator便知道在集群中有多少个worker能够工作，分配工作到worker时便有了根据
数据源相关：
Connector：
Presto通过Connector来支持多数据源，一个Connector代表一种数据源，如Hive Connector代表了对Hive数据源的支持。可以认为Connector是由Presto提供的适配多数据源的统一接口
Catalog：
针对不同的数据源，Connector和Catalog是一一对应的关系，Catalog包含了schema和data source的映射关系。
Query部分：
Queuy：基于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
Split：输入数据描述(数据实体是 Page), 数量上和 Driver 一一对应，不仅代表实际数据源split，也代表了不同stage间传输的数据
Operator：最小的物理算子
数据传输部分：
Exchange： 表示不同 Stage 间的数据传输，大多数意义下等价于 Shuffle
LocalExchange： Stage内的 rehash 操作，常用于提高并行处理数据的能力（Task在presto中只是最小的容器，而不是最小的执行单元）
Q：如何衡量某个任务某个stage的真实并行度？
A：在不同Pipeline下Split（Diver）的数目之和。
通信机制：
Q：Presto的通信方式有哪些，Thrift通信的优势？
A：Thrift具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率。
Presto架构图：
03.Presto重要机制
Q：Presto用户多租户隔离的手段是什么？
A：Presto 通过Resource Group对不同的用户创建不同Group从而实现不同租户，不同场景的资源管理
Q：Presto Resource Group的优缺点
A：优点：支持通配符的形式，对不同租户，不同提交场景下的用户进行限制
缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用
Q：Presto是从哪几个方面实现了多租户的任务调度
A：Stage调度策略
Task的节点选择策略
Split调度策略
Q：Presto Stage调度的方式有哪些？
A：AllAtOnceExecutionPolicy
PhasedExecutionPolicy
Q：Presto 进行 Task 调度时，有哪些调度方式？
A：HARD_AFFINITY： 计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输
SOFT_AFFINITY： 基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的 Task 调度到同一个 Worker
NO_PREFERENCE： 随机选取，常用于普通的纯计算 Task
Q：Presto是如何实现Back pressure mechanism的
A：控制split生成流程
针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度+1
控制Operator执行速度
"sink.max-buffer-size" 写入buffer的大小控制
"exchange.max-buffer-size" 读取buffer的大小控制
Buffer 达到最大值时Operator会进入阻塞状态
Q：Presto多数据源支持的优点与缺点
A：优点：支持多数据源的联邦查询
缺点：针对不同数据源，还存在许多问题需要解决
谓词下推
每个数据源都需要单独的一套catalog管理
如何针对数据源进行分片操作
