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

今天是我参加青训营第六天

1.概述

大数据与OLAP系统的演进
Presto的基础

1.1大数据=大数据的数据量 否

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

1.1大数据与OLAP

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

1.谷歌在03，04年发布Google File System论文、Mapreduce论文。

2.2008年，Hadoop成为apache顶级项目

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

OLAP VS MapReduce

1.MapReduce代表了抽象的物理执行模型，使用门槛较高

2.与Mapreduce Job相比，OLAP常通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化

1.1大数据与OLAP的演进

OLAP核心概念： 维度 度量

常见的OLAP引擎
预计算引擎：Kylin，Druid （用空间换取时间，先换成一个月，这样计算每年交不需要计算365天）
批式处理引擎：Hive ，Spark（注重吞吐量）
流失处理引擎：Flink（注重实时性）
交互式处理引擎：Presto，Clickhouse，Doris（注重用户体验，用来解决查询时延的问题）

1.2Presto设计思想

Presto最初是由Facebook研发的构建于Hadoop/HDFS系统之上的PB交互式分析引擎，有以下特点
·多租户任务的管理与调度
·多数据源联邦查询
·支持内存化计算
·Pipeline式数据处理

1.2Presto设计思想

1小结

1.介绍了大数据与OLAP系统的演进 2.带大家初步认识了Presto了解Presto相关设计理念

2.Presto基础原理和概念
·基础概念的介绍
·核心组件架构介绍
基础概念介绍-服务相关

绿色：代表Presto的服务
黄色：代表数据源部分
蓝色：用户端

·Coordinator ·解析SQL语句 ·生产执行计划 ·分发执行任务给Worker节点 ·Worker ·执行Task处理数据 ·与其他Worker交互传输数据

2.1基础概念介绍-数据源相关

Connector： 一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。 Catalog：管理元信息与实际数据的映射关系

2.1基础概念介绍-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
最小的物理算子
Exchange&LocalExchange
Exchange:
表示不同Stage间的数据传输，大多数意义下等价与Shuffle
LocalExchange：
Stage内的rehash操作，常用于提高并行处理数据的能力（Task在Presto中只是最小的容器，而不是最小的执行单元）默认数值是16.

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

如果衡量某个任务某个Stage的真实并行度 在不同Pipeline下Split（Driver）的数目只和。

2.2核心组件架构介绍

Presto架构图

2.2核心组件架构介绍-服务发现

Discovery Service 1.Worker配置文件配置Discovery Service地址
2.Worker节点启动后会向Discovery Service注册
3.Coordiantor从Discovery Service获取Worker的地址
2.2核心组件架构介绍-通信机制 可以直接读取过来直接用，但是量大所有需要压缩

2.2核心组件架构介绍-通信机制

节点状态：

    ACTIVE
    INACTIVE
    SHUTDOWN

SHUTDOWN状态的作业是什么？ Graceful SHUTDOWN（优雅的扩缩荣） 代表了我想要关闭但是没有关闭，系统也不会调度资源，设置一个超时时间，尽可能处理完.

2.Presto基础原理与概念-小结

3.Presto重要机制

多租户资源管理
多租户下的任务调度
内存计算
多数据源联邦查询
假设某个用户提交一个sql：
提交方式：Presto-cli

3.1 多租户资源管理-Resource Group

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

优点：轻量的Query级别的多级队列资源管理模式
缺点：存在一定滞后性，只会对Group中正在运行的SQL进行判断

3.1多用户下的任务调度-物理计划生成

1.Antlrl解析生成AST
2.转换成Logical Plan
3.按照是否存在Shuffle（Exchange），切分成不同的Stage（Fragment）
绿色进行数据 局部聚会排序 一百条取前十，最终结果生成到的数据

3.2 多用户下的任务调度

Stage调度

Stage的调度策略

·ALLATOnceExecutionPolicy

·同时调度

·PhasedExecutionPolicy

·分阶段调度

3.2多用户下的任务调度-Stage调度

PhasedExecutionPolicy：

不代表每个Stage都分开调度

典型的应用场景（join查询）

·Bulid端：右表构建用户join的hashtable

·Probe端：对用户左表数据进行探查，需要等待build端完成

·Build端构建hashtable端时，probe端是一直在空跑的

运行做一个分阶段的调度，先完成一张表的调度

Stage的调度策略

AllatOnceExecutionPolicy

延迟点，会存在任务空跑

PhasedExecutionPolicy

能节省一定资源

Task调度 Task的数量如何确定

source：根据数据mete决定分配多少个节点

Fixed：Hash Partition count确定，如集群节点数量

Sink：汇聚结果，一台机器

Scaled：无分区限制，可扩展，如write数据

Coordinator_Only：只需要coordinate参与

选择什么样的节点（调度如何选择）

Hard_AFFINITY:计算、存储Local模式，保障计算与存储在同一个节点，减少数据传输

Soft_Affinity：基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的TASK调度到同一个WOrker

NO_PREFERENCE:随机选取，常用于普通的纯计算（百分之九十是这个）

Split调度

Query A大 SQL先提交

Query B小 SQL先提交

是否等Query A执行完了在执行Query B

FIFO：顺序执行，绝对公平

优先级调度：快速响应

1.按照固定的时间片，轮训Split处理数据，处理1s再重新选择一个Split执行

2.Split间存在优先级

本身对于每一个Split有时间一般有5秒，返回下一个执行，对于没有执行的的优先级会比较高，如果比较慢的化会降级

MultieveSplitQueue

·5个优先级level理论上分配的时间占比为16:8:4:2:1(2-based)

优势：

1.优先保证Query快速执行

2.保障大Query存在固定比例的时间片，不会被完全饿死

3.2内存计算

内存计算-Pipeline化的数据处理

Pipeline（按LocalExchange拆分）：

·pipeline的引入更好的实现算子间的并行

·语义上保证了每个Task内的数据流式处理

Back Pressure Mechanism

3.4多数据源联邦查询

局限性： 1.元数据管理与映射（每个connector管理一套元数据服务） 2.谓词下推 3.数据源分片

4.性能优化实战

4.1常用性能分析工具

Grafana：埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示 Java相关指令 ·jstack查看Java线程信息，排除是否有死锁，或者异常线程存在 ·JMX（Java Managenment Extensions）是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集 ·JMAP&GC日志等等内存分析工具

线上问题排查工具 ARthas ·Watch ·Trace 常用的命令 Watch Trace函数

需要一些其他的工具配合才好排查

·PRresto UI ·Query级别统计信息 ·Logical Plan ·Stage、Task信息 ·Worker状态信息

具体案例分析 Case 1：

元素COpy，大量的hashmap的rehash操作 对底层数据直接cash

时间减少3-4秒

Case 2:

SQL执行缓慢，发现某几个节点CPU负载特别高

之内看到某几个节点CPU负载很高，但是不知道是什么原因，或者如果规避

1.正则表达式是完全有用户输入的，而与政治表达式匹配的实际数据也不可控，结果就是单条记录匹配也可能需要几天时间。

.正则表达式不可中断，阻塞Split的优先级调度

解决思路：

1.能否实现一个可中断的正则表达式

2.除了正则表达式外遇到其他类似问题怎么处理？

4.3字节内部优化实战-Multi Coordinator

1.不可用时间从几分钟-》3s内 2.coordinator多活

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

4.4RaptorX的多级缓存