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

HeteroCat
72 阅读5分钟

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

课堂内容

大数据与OLAP

  • 所谓大数据： image.png
  • 所谓Hodoop image.png
  • 所谓OLAP image.png 常见的OLAP引擎 image.png presto的设计线路和特点 image.png

presto基础

基础概念--架构

image.png

  • 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时便有了根据

基础概念--数据源

image.png

  • Connector

Presto通过Connector来支持多数据源，一个Connector代表一种数据源，如Hive Connector代表了对Hive数据源的支持。可以认为Connector是由Presto提供的适配多数据源的统一接口

  • Catalog

针对不同的数据源，Connector和Catalog是一一对应的关系，Catalog包含了schema和data source的映射关系。

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

最小的物理算子

Presto基础概念-数据传输部分

  • Exchange

表示不同 Stage 间的数据传输，大多数意义下等价于 Shuffle

  • LocalExchange

Stage内的 rehash 操作，常用于提高并行处理数据的能力（Task在presto中只是最小的容器，而不是最小的执行单元）。默认LocalExchange为16

  • 并行度=worker*16+pipeline的个数

通信机制

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

image.png

节点状态:ACTIVE,INACTIVE,SHUTDOWN

shutdown：延迟关闭的状态，就是你想关但是数据还在跑没跑完，所以等他一段时间，如果等太久了到一个规定时间直接关闭。

presto重要机制

  • 多租户资源管理
    Presto 通过Resource Group对不同的用户创建不同Group从而实现不同租户，不同场景的资源管理。优点：支持通配符的形式，对不同租户，不同提交场景下的用户进行限制。缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用。
    image.png

提交的SQL

image.png

  • 任务调度--stage
  1. AllAtOnceExecutionPolicy：同时调度，低延迟，存在任务空跑。（主要方式）
  2. PhasedExecutionPolicy：分阶段调度，有延迟，但是节省部分资源。典型有：JOIN查询（少） image.png
  • 任务调度--task

task数目的确定：由数据决定 image.png task节点的选择：由情况决定，有三种可选

image.png

  • 任务调度--splik
    一般服从FIFO，先进先出，但是我们是presto实时交互，所以我们要快速响应。因此我们有两个原则，做时间切片和优先级，有五个优先级level的划分。

image.png

  • 内存计算
    • pipeline化数据处理：更好的实现算子间的并行，语义上保证了每个task的数据流式处理
    • 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会进入阻塞状态
  • 多数据源联邦查询 image.png 局限性：元数据管理与映射，谓词下推，数据源分片

性能优化实战

  • 性能分析工具 Grafana image.png Java指令 image.png Flame Figure：火焰图 image.png Arthas
    watch：监控每个函数入参、返回参数、异常等信息 image.png trace：统计函数内每一步的执行时间 image.png presto UI image.png
  • 案例分析 image.png image.png 通过火焰图看到中间都有一个com/facebook/presto/hive...的过程，拖慢了进程，所以我们做出优化，直接去copy部分，对底层数据直接clone。
  • 字节内部优化
    多个Coordinator来优化稳定性 image.png 针对Presto UI的优化：History Server image.png

image.png

image.png

avatar
文章
阅读
粉丝