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

狂野的拉布拉多哎
142 阅读10分钟

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

07 Presto 架构原理与优化介绍

在本节课中学习了Presto框架， Presto是大数据领域常见的交互式处理引擎，具有多数据源联邦查询、多租户任务的管理与调度、内存化计算和pipeline化处理数据等特点。重点在于Presto的核心架构和上述特点的原理，此外，如何利用一些性能分析工具对Presto集群进行优化也是一个值得思考的问题。

01 概述

1.1 大数据与OLAP系统的演进

大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

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核心概念∶

  1. 维度
  2. 度量

常见的OLAP引擎∶

  • 预计算引擎:Kylin, Druid（空间换时间 ）
  • 批式处理引擎:Hive, Spark
  • 流式处理引擎:Flink
  • 交互式处理引擎:Presto, Clickhouse, Doris

1.2 Presto设计思想

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

  • 多租户任务的管理与调度

  • 多数据源联邦查询

  • 支持内存化计算

  • Pipeline式数据处理

小结：

1．介绍了大数据与OLAP系统的演进 2.带大家初步认识了Presto，了解 Presto相关设计理念

02 Presto基础原理与概念

基础概念的介绍

  • 服务相关概念
  • 数据源相关概念
  • Query相关
  • 数据传输相关

2.1.1 服务相关

  • Coordinator（负责调度）
    • 解析SQL语句
    • 生成执行计划
    • 分发执行任务给Worker节点
  • Worker
    • 执行Task处理数据
    • 与其他Worker交互传输数据

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

2.1.2 数据源相关

  • Connector : Presto通过Connector来支持多数据源，一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。
  • Catalog :管理元信息与实际数据的映射关系。针对不同的数据源，Connector和Catalog是一一对应的关系，Catalog包含了schema和data source的映射关系。

2.1.3 uery相关

  • 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

    最小的物理算子。

2.1.4 数据传输相关

  • Exchange & LocalExchange :

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

    2.1多租户下的任务调度-数据传输相关 Q:如何衡量某个任务某个Stage的真实并行度? A:在不同Pipeline 下 Split (Driver）的数目之和。

2.2 核心组件架构介绍

  • 服务发现
  • 通信机制
  • 节点状态

2.2.1 服务发现

Discovery Service : 将coordinator和woker结合到一起的服务

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

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

2.2.2 通信机制

  1. Presto Client /JDBC Client与Server间通信
    • Http
  2. Coordinator 与Worker[间的通信
    • Thrift / Http
  3. Worker 与Worker间的通信
    • Thrift / Http
  • Http 1.1 VS Thrift

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

2.2.3 节点状态

  • ACTIVE
  • INACTIVE
  • SHUTDOWN

（为什么节点已经关闭了为啥还有SHUTDOWN状态）Graceful Shutdown(优雅的扩缩容） :

Presto基础原理与概念-小结

  1. 从服务、数据源、Query、数据传输四个角度，介绍了Presto相关的基础概念

    • 服务、数据源、Query、数据传输包含哪些基本概念?

    • 如何衡量一个任务的并行度(Task并不是最小的执行单元)

  2. 通过服务发现、通信机制、节点状态三方面介绍了Coordinator与 Worker是如何协调和工作的

03 Presto重要机制

  • 多租户资源管理
  • 多租户下的任务调度
  • 内存计算

3.1.1 多租户资源管理-Case介绍

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

提交方式: Presto-cli提交用户: zhangyanbing

提交SQL : select customer_type, avg(cost)as a from test_table group by

customer _type order by a limit 10;

3.1.2 多租户资源管理- Resource Group

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

优点︰ 1.轻量的Query级别的多级队列资源管理模式 缺点 2.存在一定滞后性，只会对Group中正在运行的SQL进行判断

3.2 多租户下的任务调度

3.2.1 物理计划生成

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

3.2.2 Stage调度

Stage的调度策略

  • AllAtOnceExecutionPolicy同时调度(数据流动性处理)
    • 延迟点，会存在任务空跑
  • PhasedExecutionPolicy分阶段调度
    • 有一定延迟、节省部分资源

PhasedExecutionPolicy :不代表每个stage都分开调度

典型的应用场景(join查询)

  • Build端:右表构建用户join的hashtable

  • Probe端:对用户左表数据进行探查，需要等待build端完成

  • Build端构建hashtable端时，probe端是一直在空跑的

  • Task 调度

  • Task的数量如何确定︰

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

  • 选择什么样的节点（调度方式有那些)

    • HARD_AFFINITY:计算、存储Local模式，保障计算与存储在同一个节点，减少数据传输

    • SOFT_AFFINITY:基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task 调度到同一个Worker

    • NO_PREFERENCE:随机选取，常用于普通的纯计算Task

3.2.3 Split调度

  • 场景案例：Query A大SQL 先提交Query B 小 SQL后提交是否应该等Query A执行完了再执行Query B ?

  • FIFO:顺序执行，绝对公平

  • 优先级调度︰快速响应

  1. 按照固定的时间片，轮训Split处理数据，处理1s ,再重新选择一个split执行
  2. Split间存在优先级
  3. 优势∶优先保证小Query快速执行；保障大Query存在固定比例的时间片，不会被完全饿死

3.3 内存计算

3.3.1 Pipeline 化的数据处理

  • 场景案例：Pipeline(按LocalExchange拆分)；stage调度中的AllAtOnce；
  • 流动的数据处理模式（不等于数据产生也是流式）；
  • Pipeline的引入 更好的实现算子间的并行、语义上保证了每个Task 内的数据流式处理

3.3.2 Back Pressure Mechanism

  1. 流式数据处理，如果无限制上游消费数据供给下游，内存会爆掉，如何平衡？
  2. 控制源头产生速度、消费速度；
  3. 控制split生成流程：针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度+1；
  4. 控制operator的执行："sink.max-buffer-size" 写入buffer的大小控制 + "exchange.max-buffer-size" 读取buffer的大小控制 + Buffer 达到最大值时Operator会进入阻塞状态。

3.4 多数据源联邦查询

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

局限性: 1.元数据管理与映射(每个connector管理一套元数据服务) 2.谓词下推 3.数据源分片

04 性能优化实战

4.1 常用性能分析工具

  • Grafana :埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示

  • Java相关指令

    • Jstack查看Java线程栈信息，排查是否有死锁，或者异常线程存在

    • JMX(Java Management Extensions)是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集

    • JMAP &GC日志等等内存分析工具

  • 线上问题排查工具:

    • Arthas（Watch、Trace ......)

4.2具体案例分析

Case 1:

github.com/prestodb/pr…: tpcds 1T Table: store_returns (about 2000 partitions)Sql: select count() from store_returnsQueryexecution time: about 3-4s 为什么不符合预期? count()只需要读取parquet的footer信息，为什么需要3-4s才需要完成一条sql

Case 2：

SQL执行缓慢，发现某几个节点CPU负载特别高 只能看到某些节点cpu负载很高，但是不知道导致的原因是什么，或者如何规避

1.正则表达式是完全由用户输入的，而与正则表达式匹配的实际数据也不可控，结果就是单条记录匹配的时间也可能需要数天时间。 2.正则表达式不可中断,阻塞了Split的优先级调度。

解决思路: 1.能否实现一个可中断的正则表达式? 2.除了正则表达式外遇到其他类似问题怎么处理?

4.3字节内部优化实践– Multi Coordinator

1.Coordinator单节点稳定性差 2.单节点会成为集群性能瓶颈

Multi Coordinator 1.不可用时间从几分钟-> 3s内 2.coordinator多活

4.4字节内部优化实践–History Server

原始的Presto UI存储在内存中，无法长时间报错 History Server提供与Presto UI相同体验&持久化的数据存储

4.5字节内部优化实践- Support Remote UDF

1.统一的UDF抽象，适配多引擎 2.多租户的内核与网络隔离

4.6字节内部优化实践– RaptorX的多级爱仔

  1. Metastore cache by version
  2. List file cache
  3. Fragament cache
  4. Alluxio cache

小结 1．介绍了常见的性能优化工具（Grafana、Java指令、Arthas、Flame Figure） 2．具体案例分析 3.字节内部优化实战分享

avatar
文章
阅读
粉丝