这是我参与「第四届青训营 」笔记创作活动的的第7天。
本节课程主要分为 4 个方面：
1.概述
2.Presto基础原理和概念
3.Presto重要机制
4.性能优化实战
一.概述
1.1.大数据与OLAP的演进
1).什么是大数据 在信息化时代背景下，由于信息交互，信息存储，信息处理能力大幅增加而产生的数据。
2).什么是OLAP OLAP (OnLine Analytical Processing)： 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力。
OLAP的核心概念：
1).维度 2).度量
1.2.Presto设计思想
Presto最初是由facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎。
特点：
1).多租户任务的管理与调度
2).多数据源联邦查询
3).支持内存化计算
二.Presto基础原理与概念
2.1.基础概念的介绍
1).服务相关
■ Coordinator
□ 解析SQL语句
□ 生成执行计划
□ 分发执行任务给Worker节点
■ Worker
□ 执行Task处理数据
□ 与其他Worker交互传输数据
2).数据源相关
■ Connector:
一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。
■ Catalog:
管理元信息与实际数据的映射关系。
3).Query相关
■ Query ■ Stage
■ Fragment ■ Task
■ pipeline ■ Driver
■ Split ■ Operator
4).数据传输相关
■ Exchange
✔ 表示不同Stage间的数据传输，大多数意义下等价于Shuffle
■ LocalExchange
✔ Stage内的Rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单位)
2.2.核心组件架构介绍
1).Presto架构图
2).服务发现
Discovery Service：
1).Worker配置文件配置 Discovery Service地址
2).Worker节点启动后会向 Discovery Service注册
3).Coordiantor从 Discovery Service获取Worker的地址
3).通信机制
○ 通信机制
◎ Presto Client/JDBC Client于Server间通信：Http
◎ Coordinator与Worker间的通信：Thrift/Http
◎ Worker与Worker间的通信：Thrift/Http
○ Http 1.1 vs Thrift
◎ Thrift具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率
○ 节点状态
◎ Active
◎ InActive
◎ Shutdown
三.Presto重要机制
3.1.多租户资源管理
● Case
● Resource Group
◆ 类似Yan多级队列的资源管理方式
◆ 基于CPU、MEMORTY、SQL执行数进行资源使用量限制
◆ 优点：支持通配符的形式，对不同租户，不同提交场景下的用户进行限制
◆ 缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用
3.2.多租户下的任务调度
◌ 物理计划生成
1).Antlr4解析生成AST
2).转换成Logical Plan
3).按照是否存在Shuffle(Exchange)，切分成不同的Stage(Feagment)
3.2.1.Stage调度
✔ AllAtOnceExecutionPolicy
□ 同时调度
✔ PhasedExecutionPolicy
□ 分阶段调度
✔ PhasedExecutionPolicy
□ 不代表每个stage都分开调度
3.2.2.Task调度
数量如何确定：
○ Source：根据数据meta决定分配多少个节点
○ Fixed：hash partition count确定，如集群节点数量
○ Sink：汇集结果，一台机器
○ Scaled：无分区限制，可拓展，如writer数据
○ Coordinator_Only：只需要connrdinator参与
选择什么样的节点：
○ HARD_AFFINITY：计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输。
○ SOFT_AFFINITY：基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证 相似的 Task 调度到同一个 Worker。
○ NO_PREFERENCE：随机选取，常用于普通的纯计算 Task。
3.2.3.Split调度
○ FIFO 顺序执行，绝对公平
○ MultilevelSplitQueue 5个优先级level理论上分配的时间占比为16:8:4:2:1(2-based)
3.3.内存计算
3.3.1.Pipeline化数据处理
1).Pipeline的引入更好的实现算子间的并行
2).语义上保证了每个Task内的数据流式处理
3.3.2.Back pressure mechanism
◉ 控制split生成流程
◉ 针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度+1
◉ 控制Operator执行速度
◉ "sink.max-buffer-size" 写入buffer的大小控制
◉ "exchange.max-buffer-size" 读取buffer的大小控制
◉ Buffer 达到最大值时Operator会进入阻塞状态
3.4.多数据源联邦查询
优点：支持多数据源的联邦查询
缺点：针对不同数据源，还存在许多问题需要解决
局限性：1).谓词下推
2).每个数据源都需要单独的一套catalog管理
3).如何针对数据源进行分片操作
四.性能优化实战
4.1.常用性能分析工具
✔ Grafana
埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示
✔ Java
◌ Jstack查看Java线程栈信息，排查是否有死锁，或者异常线程存在
◌ JMX是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集
◌ JMAP & GC日志等等内存分析工具
✔ Arthas
◌ Watch：监控每个函数入参、返回参数、异常等信息
◌ Trace：统计函数内每一步的执行时间
✔ Flame Figure/火焰图
用于分析热点代码占用大量cpu,从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽表示当前函数cpu耗时越久，我们关注最宽的函数调用。
