Presto 架构原理与优化介绍
这是我参与「 第四届青训营 」笔记创作活动的的第七天
1.OLAP概述
1.OLAP定义
OLAP (OnLine Analytical Processing) 对业务数据执行多维分析,并提供复杂计算,趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力
2.OLAP VS Mapreduce
- Mapreduce代表了抽象的物理执行模型,使用门槛较高
- 与Mapreduce Job相比,OLAP引擎常通过SQL的形式,为数据分析、数据开发人员提供统一的逻辑描述语言,实际的物理执行由具体的引擎进行转换和优化
3.常见的OLAP引擎
- 预计算引擎: Kylin,Druid
- 批式处理引擎: Hive,Spark
- 流式处理引擎: Flink
- 交互式处理引擎: Presto,Clickhouse,Doris
2.Presto 基础原理与概念
1.Presto设计理念
Presto最初是由facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎,其具有如下的特点:
- 多租户任务的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- pipeline式数据处理
2.Presto基础概念
1.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时便有了根据
2.Presto基础概念-数据源
- Connector Presto通过Connector来支持多数据源,一个Connector代表一种数据源,如Hive Connector代表了对Hive数据源的支持。可以认为Connector是由Presto提供的适配多数据源的统一接口
- Catalog 针对不同的数据源,Connector和Catalog是一一对应的关系,Catalog包含了schema和data source的映射关系。
3.Presto基础概念-Query部分
- 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
- Split 输入数据描述(数据实体是 Page), 数量上和 Driver 一一对应,不仅代表实际数据源split,也代表了不同stage间传输的数据
- Operator 最小的物理算子
4.Presto基础概念-数据传输部分
- Exchange 表示不同 Stage 间的数据传输,大多数意义下等价于 Shuffle
- LocalExchange Stage内的 rehash 操作,常用于提高并行处理数据的能力(Task在presto中只是最小的容器,而不是最小的执行单元)
3.核心组件架构介绍
1.Discorery Service
- Worker配置文件配置Discorery Service地址
- Worker节点启动后会向Discorery Service注册
- Coordiantor从Discorery Service获取Worker的地址
2.通信机制
- Presto Client /JDBC Client与Server间通信
- Http
- Coordinator与Worker间的通信
- Thrift /Http
- Worker与Worker间的通信
- Thrift /Http
Http 1.1 vs Thrift
Thrift具有更好的数据编码能力,Http 1.1还不支持头部信息的压缩,Thrift具有更好的数据压缩率
3.Presto 重要机制
1.多租户资源管理——Resource Group
Presto 通过Resource Group对不同的用户创建不同Group从而实现不同租户,不同场景的资源管理
- 类似于Yarn多级队列的资源管理方式
- 基于CPU、MEMORY、SQL执行数进行资源使用量限制
优点:轻量的Query级别的多级队列资源管理模式
缺点:存在一定的滞后性,只会对Group中正在运行的SQL进行判断
2.多租户下的任务调度——物理计划生成
- Antlr4解析生成AST
- 转换成Logical Plan
- 按照是否存在Shuffle,切分成不同的Stage
从以下几个方面实现了多租户的任务调度
- Stage调度
- AllAtOnceExecutionPolicy
- PhasedExecutionPolicy
- Task调度
- HARD_AFFINITY:计算、存储 Local 模式,保障计算与存储在同一个节点,减少数据传输
- SOFT_AFFINITY:基于某些特定算法,如一致性HASH函数,常用于缓存场景,保证相似的 Task 调度到同一个 Worker
- NO_PREFERENCE:随机选取,常用于普通的纯计算 Task
- Split调度
- FIFO:顺序执行,绝对公平
- 优先级调度:快速响应
3.内存计算
- Pipeline化的数据处理:更好的实现算子间的并行,保证了每个Task内的数据流式处理
- Back pressure Mechanism:控制split生成流程与operator的执行
4.实现Back pressure mechanism的方式
- 控制split生成流程
- 针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度+1
- 控制Operator执行速度
- "sink.max-buffer-size" 写入buffer的大小控制
- "exchange.max-buffer-size" 读取buffer的大小控制
- Buffer 达到最大值时Operator会进入阻塞状态
5.Presto多数据源支持的优点与缺点
优点:支持多数据源的联邦查询
缺点:针对不同数据源,还存在许多问题需要解决
- 谓词下推
- 每个数据源都需要单独的一套catalog管理
- 如何针对数据源进行分片操作