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

自由向量
266 阅读6分钟

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

今天是我参加青训营笔记的第7天。

今天的笔记主要分为以下四部分：

概述

大数据与OLAP系统的演进

大数据 != 大规模的数据量

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

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

OLAP(Online Analytical Processing)：是对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。

OLAP和MapReduce的对比：

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

OLAP核心概念：

  • 维度
  • 度量

常见的OLAP引擎：

预计算引擎（空间换时间）：Kylin,Druid

批式处理引擎（注重IO吞吐量）: Hive,Spark

流式处理引擎（注重实时性）:Flink

交互式处理引擎:Presto

Presto设计思想

特点：

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

Presto基础原理和概念

基础概念

服务相关概念

  1. Coordinator
  • 解析SQL语句
  • 生成执行计划
  • 分发执行任务给Worker节点
  1. Worker
  • 执行Task处理数据
  • 与其他Worker交互传输数据
  1. Connector
  • 一个connector代表一种数据源，可以认为Connector是由Presto提供的适配多数据源的统一接口
  1. Catalog
  • 管理元信息与实际数据的映射关系

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一一对应，不仅代表实际数据源spilt,也代表了不同stage间传输的数据
  • Operator:最小的物理算子

数据传输相关

  • Exchange:表示不同Stage间的数据传输，大多数意义下等价于Shuffle
  • LocalExannge:Stage内的rehash操作，常用于提高并行处理数据的能力（Task在Presto中只是最小的容器，而不是最小的执行单元）默认数值是16
  • 如何衡量某个任务某个Stage的真实并行度？

答：在不同Pipeline下Split(Driver)的数目之和

核心组件架构

Presto架构图

服务发现

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

通信机制

Presto Clinent / JDBC Client 与Service间通信Http
Coordinator 与 Worker间的通信Thrift / Http
Worker与Worker间的通信Thrift / Http

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

节点状态

  • ACTIVE:活跃
  • INACTIVE：不活跃
  • SHUTDOWN：代表想要关闭但是还可以处理作业的状态

Presto重要机制

多租户资源管理

Rescource Group

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

优点：轻量级（根据配置文件可以自动生成队列，不需要提前创建队列）

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

物理计划生成

  1. Antlr4解析生成AST
  1. 转换成Logical Plan
  1. 按照是否存在Shuffle,切分成不同的Stage

多租户下的任务调度

Stage调度

PhasedExecutionPolicy（分阶段调度）

不代表每个Stage都分开调度

应用场景（join查询）

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

AllAtOnceExecutionPolicy(同时调度)（默认）

延迟低，会存在任务空跑

Task调度

Task的数量如何确定？

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

选择节点的调度策略

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

Split调度

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

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

MultilevelSpiltQueue

  • 5个优先级level理论上分配的实践占比为16：8：4：2：1（2-based）

优势：

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

内存计算

Pipeline化的数据处理

Pipeline(按LocalExchange拆分)：

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

Back Pressure Mechanism（反压机制）

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

多数据源联邦查询

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

局限性：

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

性能优化实战

常用性能分析工具

  • Grafana
  • Jstack
  • JMX
  • JMAP & GC
  • Arthas:线上问题排查工具
  • Flame Figure
  • Presto UI

具体案例分析

case1

问题：

发现：

case2

问题：

发现：

解决思路：

  • 实现一个可中断的正则表达式

字节内部优化实战

Multi Coordinaor

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

History Service

原始的Presto UI存储再内存中，无法长时间报错

Histry Service提供与Presto UI相同体验&持久化的数据存储

Support Remort UDF

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

avatar
文章
阅读
粉丝