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

SEANJTX
386 阅读5分钟

这是我参与【第四届青训营】笔记创作活动的第5天.

01 概述

1.1 大数据与OLAP的演进

参考马丁·希尔伯特的总结，大数据就是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

image.png

Hadoop:基于廉价机器的存算分离的大规模分布式处理系统 1.谷歌在2003、2004年发布Google File System论文、MapReduce论文。2.2008年,Hadoop成为apache顶级项目

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

OLAP VS MapReduce 1.MapReduce代表了抽象的物理执行模型，使用门槛较高 2.与Mapreduce Job相比，OLAP引擎常通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。

OLAP核心概念：

  • 维度
  • 度量

image.png

常见的OLAP引擎:

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

1.2 Presto设计思想

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

  • 多租户任务的管理与调度
  • 多数据源联邦查询
  • 支持内存化计算
  • Pipeline式数据处理

image.png

有很多公司也基于Presto进行了二次开发:

  • Prestodb: https:/lgithub.com/prestodb/presto
  • Trino: https:/lgithub.com/trinodb/trino
  • Openlookeng: https:/lgithub.com/openlookeng/hetu-core

02 Presto基础原理和概念

2.1 基础概念介绍

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

image.png

  1. Query 相关
  • Query
    • 基于SQL parser后获得的执行计划
  • Stage
    • 根据是否需要shuffle将Query拆分成不同的subplan，每一个subplan便是一个stage
  • Fragment
    • 基本等价于 Stage，属于在不同阶段的称呼，在本门课程可以认为两者等价
  • Task
    • 单个Worker节点上的最小资源管理单元:在一个节点上,一个 Stage 只有一个Task,一个Query可能有多个Task

image.png

  1. 数据传输相关
  • Exchange & LocalExchange:
    • Exchange:
      • 表示不同Stage 间的数据传输，大多数意义下等价于Shuffle
  • LocalExchange:
    • Stage 内的rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元) LocalExchange的默认数值是16。

image.png

2.2 核心组件架构介绍

Presto架构图

image.png

服务发现（Discovery Service）:

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

image.png

通信机制

  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具有更好的数据压缩率

节点状态：

  • ACTIVE
  • INACTIVE
  • SHUTDOWN

Graceful Shutdown image.png

03 Presto重要机制

3.1 多租户资源管理

Case介绍

假设某个用户提交一个sql:

  • 提交方式:Presto-cli提交用户:zhangyanbing
  • 提交SQL: select customer_type, avg(cost) as afrom test_table group by customer_type order bya limit 10;

Resource Group

  • 类似Yarn多级队列的资源管理方式
  • 基于CPU、MEMORY、SQL执行数进行资源使用量限制

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

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

物理计划生成

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

image.png

image.png

3.2 多租户下的任务调度

  1. Stage调度
  • AllAtOnceExecutionPolicy 同时调度，延迟点，会存在任务空跑
  • PhasedExecutionPolicy 分阶段调度，有一定延迟，节省部分资源
  1. Task调度 Task的数量如何确定:
  • Source:根据数据meta决定分配多少个节点
  • Fixed: hash partition count确定，如集群节点数量
  • Sink:汇聚结果，一台机器
  • Scaled:无分区限制，可拓展，如write数据
  • Coordinator_Only:只需要coordinator参与

image.png

选择什么样的节点：

  • HARD_AFFINITY:计算、存储Local模式，保障计算与存储在同一个节点，减少数据传输
  • SOFT_AFFIN/TY:基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task调度到同一个Worker
  • NO_PREFERENCE:随机选取，常用于普通的纯计算Task
  1. Split调度 FIFO：顺序执行，绝对公平

优先级调度：快速响应

1．按照固定的时间片，轮训Split 处理数据，处理1s，再重新选择一个Split执行
2. Split间存在优先级

MultilevelSplitQueue

  • 5个优先级level理论上分配的时间占比为16:8:4:2:1 (2-based)

优势:

1．优先保证小Query快速执行

2．保障大Query存在固定比例的时间片，不会被完全饿死

3.3 内存计算

Pipeline（按LocalExchange拆分) :

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

image.png

  • Back Pressure Mechanism

    • 控制split生成流程

    • 控制operator的执行

    1. targetConcurrency auto-scale-out 定时检查,如果OutputBuffers使用率低于0.5(下游消费较快,需要提高生产速度)，并发度+1
    2. "sink.max-buffer-size"写入buffer的大小控制，"exchange.max-buffer-size”读取buffer的大小控制，达到最大值时Operator会进入阻塞状态

3.4 多数据源联邦查询

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

image.png

局限性:

  1. 元数据管理与映射（每个connector管理一套元数据服务）

  2. 谓词下推

  3. 数据源分片

参考文章

深入理解Presto - 知乎 (zhihu.com)

Presto入门介绍_帝都-小帅的博客-CSDN博客_presto入门

avatar
文章
阅读
粉丝