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

二粒砂
233 阅读11分钟

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

1.概述

①大数据与OLAP系统的演进

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

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

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

OLAP VS MapReduce

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

OLAP核心概念

  • 维度
  • 度量
  • 有了这两个概念，OLAP引擎在分析上变得更标准化来解决实际问题

常见的OLAP引擎

  • 预计算引擎（用空间换取时间：如预先进行聚合等操作，以备后续使用）：Kylin、Druid
  • 批式处理引擎（注重吞吐量）：Hive、Spark
  • 流式处理引擎（注重实时性：数据产出的实时性以及数据响应的实时性）：Flink
  • 交互式处理器引擎（用来解决查询时延的问题，对用户体验进行实时分析）：Presto、Clickhouse、Doris

②Presto设计思想

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

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

2.Presto基础原理和概念

①基础概念介绍

如图，黄色部分为数据源，绿色部分为Presto内部的服务，蓝色部分代表用户端

image.png

服务相关

  • Coordinator

    • 解析SQL语句
    • 生成执行计划
    • 分发执行任务给worker节点

  • Worker

    • 执行Task处理数据
    • 与其他worker交互传输数据

  • 最终把worker的结果汇总到Coordinator并展示给用户

数据源相关（Presto是如何支持多数据源的）

  • Connector：一个Connector代表一种数据源，可以认为Connector是由Presto提供的适配多数据源的统一接口，可以支持用户通过plugin的方式来实现不同的数据源适配进入Presto，Presto负责将多个Connector的数据进行转换映射，进行联邦查询（支持多数据源之间的Join、联合分析）
  • Catalog：管理元信息与实际数据的映射关系

Query相关

  • Query：基于SQL Parser后获得执行计划

  • Stage：根据是否需要Shuffle将Query拆分成不同的subplan，每个subplan都是一个stage

  • Fragment：基本等价于Stage，属于在不同阶段的称呼，本节课程可以认为两者等价

  • Task：单个Worker节点上的最小资源管理单元：在一个节点上，一个Stage只有一个Task，一个Query可能有多个Task

  • Pipeline：Stage按照LocalExchange（在stage内部进行类似于shuffle的操作，进行re哈希的操作，强行提升计算并行度）切分为若干Operator集合，每个Operator集合定义一个Pipeline

  • Driver：Pipeline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator

    Driver和task的区别：Presto通过Pipeline的形式，把数据进一步提高并行度，同时引入了并行处理的模型

  • Spilt：输入数据描述（数据实体是Page），数量上和Driver一一对应，不仅代表实际数据源Split，也戴白哦了不同stage间传输的数据

  • Operator：最小的物理算子

数据传输相关

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

  • LocalExchange：stage内的rehash操作，常用于提高并行处理数据的能力（Task在Presto中只是最小的容器，而不是最小的执行单元）task就相当于进程，而真正进行处理的是线程

    LocalExchange的默认数值是16，就是说每个task在presto的一个stage并行度至少提升16倍

多租户下的任务调度-数据传输相关

  • Q：如何衡量某个任务某个stage的真实并行度

    A：在不同Pipeline下Spilt（Driver）的数目之和

②核心组件架构的介绍

Presto架构图

image.png

Coordinator如何做服务发现？

  • （Discivery Service桥接了Coordinator和Worker之间的服务发现能力）
  • Worker配置文件配置Discovery Service地址
  • Worker节点启动后会向Discovery Service注册
  • Coordinator从Discovery Service获取Worker的地址，从而达到集群管理的作用

通信机制

  • Presto Clinet/JDBC Client与Server间通信：Http

  • Coordinator与Worker间通信：Thrift/Http

  • Worker与Worker间通信：Thrift/Http

  • Q：为什么已经支持Http了，还需要Thrift

    A：Thrift是一个常见的RPC框架，具有更好的数据编码能力，Http1.0做不到长连接，底层复用效率较差，1.1之后虽然可以做到长连接的保持，但http协议本身就是比较繁杂的协议，不支持头部信息的压缩，Thrift具有更好的数据压缩率，降低数据传输量，但是需要反解码和编码的开销

  • 节点状态：ACTIVE、INACTIVE、SHUTDOWN

    shutdown状态的作用：

    优雅的扩缩容：节点的shutdown状态表示节点想要关闭但是尚未关闭，因为如果节点上运行作业，直接关闭会导致作业被Kill，实际应用应该是：如果设置某个节点是shutdown状态，coordinator会不再向该节点发新的task，该节点会在超时时间内尽量完成节点上的task，超过超时时间，就算作业未处理完也会直接关闭

③小结

  1. 从服务、数据源、Query、数据传输四个角度，介绍了Presto相关的基础概念，以及如何衡量一个任务的并行度（Task不是最小的执行单元）
  2. 通过服务发现、通信机制、节点状态三方面介绍了Coordinator和Worker是如何协调和工作的

3.Presto重要机制

①多租户资源管理

Resource Group

image.png

  • 类似Yarn多级队列的资源管理方式

    • rootGroups：根资源组（可以拆分成子资源组），包含资源组名称、内存限制、并行度限制以及提交的SQL的限制等信息
    • selectors：如何根据提交信息判断SQL属于哪个group(如:第一个大括号中,匹配source和queryType,若匹配成功,则返回正确的group)

  • 基于CPU、MEMORY、SQL执行数进行资源使用量限制，从而限制用户的提交

  • 优点:轻量的Query级别的多级队列资源管理模式(轻量:可以通过一些通配符或者session如user name信息自动创建队列,而不用提前创建,即从一个简单的起始文件生成一个复杂的资源管理模式)

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

物理计划生成

  • Antlr4解析生成AST

  • 转换成Logical Plan

  • 按照是否存在Shuffle(Exchange),切分成不同的stage(Fragment)

    生成的物理执行计划:

image.png

②多租户下的任务调度

Stage调度策略

  • 同时调度:AllAtOnceExecutionPolicy

    • presto的调度方式默认是同时调度,优点:契合presto流式数据处理的特点,一上来就会把所有的stage的task启动起来,那么上游stage可以一边分析数据,一边把处理好的数据传给下游,而不需等待上游处理完所有数据后再传给下游,这会让内存计算变得可行,因为如果每次都要等stage全部处理完成,这个数据量很难在内存中完全存储,往往需要落盘,落盘后还需另外启动stage读取磁盘的数据
    • 总结:延迟低,会存在任务空跑

  • 分阶段调度:PhasedExecutionPolicy

    • 不代表每个stage都分开调度

    • 典型的应用场景(Join查询)

      • Build端:右表构建用户Join的hashtable
      • Probe端:对用户左表数据进行探查,需要等待build端完成
      • Build端构建Hashtable端时,probe端是一直在空跑的

    • 总结:有一定延迟,节省部分资源

Task调度

  • Task的数量如何确定

    • Source：根据数据meta决定分配多少个节点（Fragment2）
    • Fixed：hash partition count确定，如集群节点数量（Fragment1，因为shuffle倾向更高的并行度）
    • SInk：汇聚结果，一台机器（Fragment0）
    • Scaled：无分区限制，可拓展，如write数据
    • Coordinator_Only：只需要coordinator参与（某些信息可以根据源数据直接判断出结果/常量折叠）

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

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

Split调度

  • 场景：Query A大 SQL先提交，Query B小 SQL后提交；是否应该等A执行完了再执行B？有两种模式：

    • FIFO：顺序执行，绝对公平
    • 优先级调度：快速响应

  • Presto采取的策略：

    • 按照固定的时间片，轮训Split处理数据，处理1s，再重新选择一个Split执行
    • Split间存在优先级：MutiLevelSplitQueue，5个优先级level理论上分配的时间占比为16:8:4:2:1（2-based）

  • 优势

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

③内存计算

Pipeline化的数据处理

  • presto中的pipeline分成两层：①task内部按照localExchange拆分成不同的并行度，设置成不同的pipeline②stage调度：部分stage是同时调度，保证了上游有一部分数据处理完，就可以产出给下游进行处理，保证了数据始终处于流动的状态（但是数据的生产并不是流动的，那就成流式引擎了）

    流式引擎和交互式引擎实时性的区别：流式引擎的实时性体现在生产端，而交互式引擎体现在消费端

  • stage内部地pipeline（按LocalExchange拆分）：

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

反压机制（Back Pressure Mechanism）

  • 一个流式数据处理模式，全内存化计算，如果无限制地在上游消费数据供给下游，内存迟早爆掉，如何balance：有效缓存一些数据，同时保证上游数据不会过多产生，给下游太大的压力

  • 策略

    • 控制split生成流程
    • 控制operator地执行

  • 具体

    • targetConcurrency auto-scale-out

      定时检查，如果OutputBuffers使用率低于0.5（下游消费较快，需要提高生产速度），并发度+1

    • “sink.max-buffer-size”写入buffer地大小控制

      “exchange.max-buffer-size”读取buffer的大小控制

      达到最大值时Operator会进入阻塞状态

    • 保证了整个的相对速度取决于消费端的速度

④多数据联邦查询

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

局限性

  • 元数据管理与映射（每个connector管理一套元数据服务）
  • 谓词下推
  • 数据源分片

4.性能优化实战

①常用性能分析工具

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

Java相关指令

  • Jstack查看Java线程栈信息，排查是否有死锁，或者异常线程存在
  • JMX（Java Management Extensions）是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集
  • JMAP&GC日志等内存分析工具

线上问题排查工具

  • Arthas

    • Watch
    • Trace

  • 火焰图

    • 用于分析热点代码占用大量CPU，从而导致服务性能下降的情况。自底向上为调用关系，上层宽度越宽表示当前函数CPU耗时越久，我们关注最宽的函数调用

Presto UI

  • Quey级别统计信息
  • Logical plan
  • Stage、Task信息
  • Worker状态信息

②字节内部优化实战

Multi Coordinator

  • 问题

    • Coordinator单节点稳定性差
    • 单节点会成为进群性能瓶颈

  • 解决

    • 不可用时间从几分钟->3s内
    • Coordinator多活

History Server

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

Support Remote UDF

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

RaptorX的多级缓存

  • 针对一些存算分离的系统，影响性能的主要是与之进行交互的系统，因此可以将一些数据进行多级缓存

  • Metastore cache by version

  • List file cache

  • Fragment cache

  • Alluxio cache

avatar
文章
阅读
粉丝