这是我参与「第四届青训营 」笔记创作活动的第7天
1. 概述
1.1. 大数据与OLAP的演进
OALP 核心概念：
- 维度
- 度量
常见的OLAP引擎：
- 预计算引擎：Kylin，Druid
- 批示处理引擎：Hive，Spark
- 流式处理引擎：Flink
- 交互式处理引擎：Presto，ClickHouse，Doris
1.2. Presto 设计思想
特点：
- 多租户人物的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- Pipeline 式数据处理
很多公司也基于Presto 进行了二次开发：
- Prestodb：github.com/prestodb/pr…
- Trino: github.com/trinodb/tri…
- Openlookeng: github.com/openlookeng…
2. Presto 基础原理和概念
举出概念介绍 - 服务相关
- Coordinator
- 解析SQL语句
- 生成执行计划
- 分发执行任务给Workers节点
- 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
2.1. 基础概念介绍 - 数据传输相关
- Exchange & LocalExchange
- Exchange
- 表示不同Stage间的数据传输，大多数意义下等价于Shuffle
- LocalExchange：
- Stage内的rehash操作，常用于提高并行处理数据的能力
- 默认值为16
2.2. 核心组件架构介绍
2.2. 核心组件架构介绍 - 服务发现
Discovery Service
- Workers配置文件配置Discovery Service地址
- Worker节点启动后会向Discovery Service注册
- Coordinator 从Discovery Service获取Worker的地址
2.2. 核心组件架构介绍 - 通信机制
节点状态
- ACTIVE
- INACTIVE
- SHUTDOWN
3. Presto 重要机制
3.1. 多租户资源管理 - Case介绍
3.1. 多租户资源管理 - Resource Group
- 类似Yarn多级队列的资源管理方式
- 基于CPU、MEMORY、SQL执行数进行资源使用量限制
优点：
- 轻量的Query级别的多级队列资源管理模式
缺点： 2. 存在一定滞后性，只会对Group中正在运行的SQL进行判断
3.1. 多租户下的任务调度 - 物理计划生成
- Antlr4 解析生成AST
- 转换成Logical Plan
- 按照是否存在Shuffle（Exchange），切分成不同的Stage（Fragment）
3.2. 多租户下的任务调度 - Stage 调度
Stage的调度策略
- AllAtOnceExecutionPolicy：同时调度，延迟低，会存在任务空跑
- PhasedExecutionPolicy：分阶段调度，有一定延迟、节省部分资源
PhasedExecutionPolicy
- 不代表每个Stage都分开调度
典型的应用场景（join查询）
- Build端：右表构建用户join的hashtable
- Probe端口：对用户左表数据进行探查，需要等待build端完成
- Build端构建hashtable端时，probe端是一只在跑空的
3.2. 多租户下的任务调度 - Task调度
- 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
3.2. 多租户下的任务调度 - Split 调度
FIFO：顺序执行，绝对公平
优先级调度：快速响应
- 按照固定的时间片，轮训Split处理数据，处理1s，再重新选择一个Split执行
- Split间存在优先级
MultilevelSplitQueue
- 5个优先级leve理论上分配的实践占比为： 16：8：4：2：1
优势：
- 优先保证小Queue快速执行
- 保障大Query存在固定比例的时间片，不会被完全饿死
3.3. 内存计算
- Pipeline化的数据处理
- Back Pressure Mechanism
3.3. 内存计算 - Pipeline化数据处理
Pipeline（按LocalExchange拆分）：
- Pipeline的引入更好的实现算子间的并行
- 语义上保证了每个Task内的数据流式处理
