Presto原理与优化 | 青训营笔记

NonNull
398 阅读4分钟

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

Presto基础

Presto基础概念

服务相关

  • Coordinator：解析SQL语句，生成执行计划并分发给worker；管理meta
  • Worker：执行task处理数据，与其他worker交互传输数据
  • Connector:代表着一个数据源，适配多数据源的统一接口
  • Catalog:管理元信息与实际数据的映射关系

内存

Presto采用了逻辑的内存池来进行管理

  1. System Pool，系统使用，默认为40%
  2. Reserved Pool，最大的一个query使用，避免占用内存较大的query分配不到内存而被饿死
  3. General Pool，其他query使用

Query相关

  • Query：基于SQL parse后得到的实际执行计划
  • Stage：依据是否需要Shuffle划分的subplan
  • Fragment：基本与Stage等价
  • Task：单个worker节点上最小资源管理单位，一个节点上一个stage只有一个task
  • Pipeline：Stage按照LocalExchange划分为operator集合，每个operator集合定义一个pipeline
  • Driver：Pipeline的可执行实体，最小执行单元，按照火山迭代模型执行每个operator
  • Split：sections of a larger data set，输入数据描述(数据实体是Page),数量上和Driver一对应不仅代表实际数据源split，也代表了不同stage间传输的数据。
  • Operator：最小的物理算子

数据传输相关

  • Exchange：不同Stage间的数据传输，大多数意义上等于Shuffle
  • LocalExchange：Stage内的rehash，提高并行处理数据的能力

Presto数据存储：

  1. Page： 多行数据的集合，包含多个列的数据，内部仅提供逻辑行，实际以列式存储。
  2. Block：一列数据，根据不同类型的数据，通常采取不同的编码方式，了解这些编码方式，有助于自己的存储系统对接presto。

Presto架构

sdcsdc.png

服务发现
  1. Worker配置文件配置Discovery Service地址
  2. Worker节点启动后会向Discovery Service注册
  3. Coordiantor从Discovery Service获取Worker的地址
通信机制
  1. Presto Client/JDBC Client与Server间通信 Http
  2. Coordinator与Worker间的通信 Thrift / Http
  3. Worker与Worker间的通信 Thrift / Http

Thrift 具有更好的数据编码能力，数据压缩率更高

节点状态

  • ACTIVE
  • INACTIVE
  • SHUTDOWN

Presto重要机制

多租户任务的资源管理

Resource Group

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

多租户任务的调度

Stage调度

  • AllAtOnceExecutionPolicy同时调度（默认），延迟低，有任务空跑
  • PhasedExecutionPolicy分阶段调度（不代表每个stage都分开调度），有一定延时，节省部分资源

PhasedExecutionPolicy典型：join操作，先构建hashtable，再对另一个表进行探查

Task调度

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

HARD_AFFINITY：计算、存储Local模式，保障计算、存储在同一个节点，减少数据传输 SOFT_AFFINITY：基于某些特定的算法如一致性hash函数，常用于缓存场景，保障相似的task调度到同一个节点上 NO_PREFERENCE：随机选取，常用于纯计算的task

Split调度

FIFO：顺序执行，公平 v.s. 优先级调度：快速相应

MultilevelSplitQueue：5个优先级level理论上分配的时间占比为16:8:4:2:1

优势:

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

内存化计算

Pipeline化数据处理

数据不断流动，上游数据处理好后直接发送到下游

Back Pressure Mechanism反压机制

控制split生成流程

控制operator执行

定时检查若OutPutBuffer使用率低于0.5（生产慢了），并发度++

sink.max-buffer-size/exchange.max-buffer-size，buffer大小控制，满了之后operator阻塞

多数据源联邦查询

对多数据源进行统一抽象，有presto server进行统一的物理执行

局限性

  1. 元数据管理与映射
  2. 谓词下推
  3. 数据源分片

Presto性能优化

  • Java问题排查
    • Jstack
    • JMX
    • Jmap&GC
  • 线上问题排查
    • Arthas
      • watch
      • trace
  • 火焰图 分析热点代码占用大量CPU，导致服务性能下降的情况
  • 字节内部：
    • Multi Coordinator：单节点的coordinator稳定性较差，可能成为性能瓶颈
    • history server：提供了与Presto UI相同的体验和持久化数据存储
    • Support Remote UDF：统一的UDF抽象；多租户的内核与网络隔离
    • RaptorX的多级缓存：Metastore cache by version;List file cache;Fragament cache;Alluxio cache
avatar
文章
阅读
粉丝