Presto|青训营笔记这是我参与「第四届青训营」笔记创作活动的第四天 Presto架构原理和优化 Presto概述、

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

Presto架构原理和优化

概述

大数据概念因为信息化的快速发展，信息交换、信息存储、信息处理三个方法能力的大幅增长而产生的数据。
OLAP与大数据

OLAP(OnLine Analytical Processing) 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商业智能(BI)应用程序背后的技术。
OLAP VS MapReduce MapReduce代表抽象的物理执行模型，使用门槛较高;
与Mapreduce Job相比，OLAP引擎常通过SQL的形式，为数据分析、数据开发人员统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化;

OLAP核心概念维度、度量
常见的OLAP引擎

预算计算引擎：Kylin,Druid
批式处理引擎：Hive,Spark
批式处理引擎：Flink
交互式处理引擎：Presto,Clickhouse,Doris

Presto 设计思想 Presto最初由Facebook研发的构建于Hadoop/HDFS系统上的PB级交互式分析引擎，具有如下特点：多租户任务的管理和调度
多数据源联邦查询
支持内存化计算
Pipline式数据处理
基于Presto二次开发

Prestdb: github.com/prestodb/pr…
Trino: github.com/trinodb/tri…
Openlookeng: github.com/openlookeng…

Presto基础原理与概念

基础概念

服务相关 Coordinator：解析SQL语句，生成执行计划，分发执行任务给Worker节点。
Worker：执行Task处理数据，与其他Worker交互传输数据。
数据源相关 Connector：一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。
Catalog:管理元信息与实际数据的映射关系。
Query相关 Query:基于SQL parser后获得的执行计划
Stage:根据是否需要Shuffle将Query拆分成不同的subplan,每个subplan便是一个stage
Fragment:基本等价于Stage,属于在不同阶段的称呼
Task:单个Worker节点上的最小资源管理单元：在一个节点上，一个Stage只有一个Task，一个Query可能由多个Task
Pipleline:Stage按照LocalExchange切分为若干Operator集合，每个Operator集合定义一个Pipeline
Driver:Pipleline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator
Split:输入数据描述(数据实体是Page),数量上和Driver一一对应,不仅代表实际数据源split,也代表了不同stage间传输的数据
Operator:最小的物理算子

4. 数据传输相关

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

核心组件架构

架构图
服务发现

Discovery Service

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

3. 通信机制

Presto Client /JDBC Client 与Server间通信- Http
Coordinator与Worker间的通信- Thrift/Http
Worker和Worker间的通信 - Thrift/Http Http1.1 VS Thrift
Thrift具有更好的数据编码能力,Http1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率

节点状态

ACTIVE
INACTIVE
SHUTDOWN

重要机制

多租户资源管理

Resource Group 介绍类似于Yarn多级队列的资源管理方式
基于CPU、MEMORY、SQL执行进行资源使用限制优点轻量化的Query级别的多级队列资源管理模式缺点存在一定滞后性，只会对Group中正在运行的SQL进行判断

多租户任务调度

物理计算生成 提交SQL

select customer_type, avg(cost) as a from
test_table group by customer_type order by a limit 10;

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

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

Split 调度 FIFO
顺序执行，绝对公平
按照固定的时间片，轮训Split处理数据，处理1s,在重新选择一个Split执行
Split间存在优先级

优先级调度
MultilevelSplitQueue:5个优先级level理论上分配的时间占比为16：8：4：2：1
优先保证小Query快速执行
保障大Query存在固定比例的时间片，不会被完全饿死

内存计算

Pipeline化的数据处理按LocalExchange拆分
pipeline的引入更好的实现算子间并行
语义保证了每个Task内的数据流式处理
Back Pressure Mechanism

控制split生成流程
控制operator的执行
targetConcurrency auto-scale-out:定时检查，如果OutPutBuffers使用率低于0.5(下游消费较快，需要提高生产速度),并发度+1
sink.max-buffer-size 写入buffer的大小控制
exchange.max-buffer-size读取buffer的大小控制达到最大值时Operator会进入堵塞状态