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

FlemingFan
263 阅读6分钟

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


0x00 概述

0.1 大数据与OLAP系统的演进

0.1.1 Hadoop简介

Hadoop:基于廉价机器的存算分离的大规模分布式处理系统

  1. 谷歌在2003、2004年发布Google File Systemi论文、MapReducei论文
  2. 2008年，Hadoop成为apache顶级项目

0.1.2 OLAP简介

OLAP(OnLine Analytical Processing)对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。

0.1.3 OLAP核心概念

  • 维度
  • 度量 6_OLA核心概念.png

0.1.4 常见的OLAP引擎

  • 预计算引擎：Kylin,Druid
  • 批式处理引擎：Hive,Spark
  • 流式处理擎：Flink
  • 交互式处理引擎：Presto,Clickhouse,Doris

0.2 Presto设计思想

Presto最初是由Facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎 6_Presto设计思想.png


0x01 Presto基础原理和概念

1.1 基础概念的介绍

1.1.1 服务相关

  1. Coordinator
    • 解析SQL语句
    • 生成执行计划
    • 分发执行任务给Worker节点执⾏
  2. Worker
    • 执行Task处理数据
    • 与其他Worker交互传输数据

    在一个presto集群中，存在一个coordinator节点和多个worker节点，coordinator节点是管理节点，而worker节点就是工作节点，在每个worker节点上都会存在一个worker服务进程，该服务进程主要进行数据的处理以及task的执行，worker服务进程每隔一定的时间都会向coordinator上的服务发送心跳，接受调度。当客户端提交一个查询的时候，coordinator则会从当前存活的worker列表中选择出适合的worker节点去运行task，而worker在执行每个task的时候又会进一步对当前task读入的每个split进行一系列的操作和处理。

6_基础概念.png

1.1.2 数据源相关

  1. Connector Presto通过Connector来支持多数据源，一个Connector代表一种数据源，如Hive Connector代表了对Hive数据源的支持。可以认为Connector是由Presto提供的适配多数据源的统一接口
  2. Catalog 针对不同的数据源，Connector和Catalog是一一对应的关系，Catalog包含了schema和data source的映射关系。

1.1.3 Query部分

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

6_Query.png

1.1.4 数据传输相关

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

6_数据传输.png

1.2 核心组件架构

6_核心组件.png

1.2.1 Discovery service

  • 将coordinator和woker结合到一起的服务
  • Worker节点启动后向Discovery Server服务注册
  • Coordinator从Discovery Server获得Worker节点

所有的worker都把自己注册到Discovery Server上，Discovery Server是一个发现服务的service，Discovery Server发现服务之后，coordinator便知道在集群中有多少个worker能够工作，分配工作到worker时便有了根据。

1.2.2 通信机制

  • Http 1.1 vs Thrift

Thrift具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率

1.2.3 Worker状态

  1. Active
  2. InActive
  3. Shutdown（优雅的扩容）

0x02 Presto重要机制

2.1 多租户资源管理

2.1.1 Resource Group

  • Presto 通过Resource Group对不同的用户创建不同Group从而实现不同租户，不同场景的资源管理

优点：支持通配符的形式，对不同租户，不同提交场景下的用户进行限制 缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用

2.2 多租户下的任务调度

2.2.1 物理计划生成

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

6_物理计划生成.png

2.2.2 Stage调度

  1. AllAtOnceExecutionPolicy（同时调度）—— 延迟点，会存在任务空跑
  2. PhasedExecutionPolicy（分阶段调度）—— 有一定延迟、节省部分资源

2.2.3 Task调度

  • Task数量确定
    • Source：根据数据meta决定分配多少个节点
    • Fixed：hash partition count确定，如集群节点数量
    • Sink：汇聚结果，一台机器
    • Scaled：无分区限制，可拓展，如write数据
    • Coordinator_Only：只需要coordinator参与

6_多租户.png

  • Task节点选择
    1. HARD_AFFINITY： 计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输
    2. SOFT_AFFINITY： 基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的 Task 调度到同一个 Worker
    3. NO_PREFERENCE： 随机选取，常用于普通的纯计算 Task

2.2.4 Split调度

  1. 优先保证小Query快速执行
  2. 保障大Query存在固定比例的时间片，不会被完全饿死

2.3 内存计算

2.3.1 Pipeline化数据处理

按LocalExchange拆分：

  • Pipeline的引入更好的实现算子间的并行
  • 语义上保证了每个Task内的数据流式处理

2.3.2 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会进入阻塞状态

2.4 多数据源联邦查询

  • 优点：支持多数据源的联邦查询
  • 缺点：针对不同数据源，还存在许多问题需要解决
    • 谓词下推
    • 每个数据源都需要单独的一套catalog管理
    • 如何针对数据源进行分片操作

6_联邦查询.png


0x03 性能优化

3.1 常用性能分析工具

  1. Grafana
  2. Arthas
  3. Flame Figure（火焰图）
  4. java指令：jstack等指令
avatar
文章
阅读
粉丝