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

92 阅读6分钟

Presto 架构原理与优化介绍

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

1.OLAP概述

1.OLAP定义

OLAP (OnLine Analytical Processing) 对业务数据执行多维分析,并提供复杂计算,趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力

2.OLAP VS Mapreduce

  1. Mapreduce代表了抽象的物理执行模型,使用门槛较高
  2. 与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.核心组件架构介绍

image.png

1.Discorery Service

  1. Worker配置文件配置Discorery Service地址
  2. Worker节点启动后会向Discorery Service注册
  3. Coordiantor从Discorery Service获取Worker的地址

2.通信机制

  1. Presto Client /JDBC Client与Server间通信
  • Http
  1. Coordinator与Worker间的通信
  • Thrift /Http
  1. 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.多租户下的任务调度——物理计划生成

  1. Antlr4解析生成AST
  2. 转换成Logical Plan
  3. 按照是否存在Shuffle,切分成不同的Stage image.png

从以下几个方面实现了多租户的任务调度

  • 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的方式

  1. 控制split生成流程
  2. 针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度+1
  3. 控制Operator执行速度
  4. "sink.max-buffer-size" 写入buffer的大小控制
  5. "exchange.max-buffer-size" 读取buffer的大小控制
  6. Buffer 达到最大值时Operator会进入阻塞状态

5.Presto多数据源支持的优点与缺点

优点:支持多数据源的联邦查询

缺点:针对不同数据源,还存在许多问题需要解决

  • 谓词下推
  • 每个数据源都需要单独的一套catalog管理
  • 如何针对数据源进行分片操作