这是我参与「第四届青训营」笔记创作活动的第8天。
知识点小记
Presto架构图
图源：青训营课堂
核心组件结构：
图源：青训营课堂
OLAP VS MapReduce
- MapReduce代表了抽象的物理执行模型，使用门槛较高
- 与Mapreduce Job相比，OLAP引擎常通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。
常见的OLAP引擎
- 预计算引擎：Kylin,Druid
- 批示处理引擎：Hive，Spark
- 流式处理引擎：Flink
- 交互式处理引擎：Presto、Clickhouse、Doris
Presto特点
- 多租户任务的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- Pipline式数据处理
基础服务介绍
Coordinator：解析SQL语句、生成执行计划、分发执行任务给Worker节点。
Worker：执行Task处理数据、与其他Worker交互传输数据。
Connector：一个Connector代表一种数据源，可以认为Connector是由Presto提供的适配多数据源的统一接口。
Catalog：管理元信息与实际数据的映射关系。
Query相关
Query：基于SQL parser后获得的执行计划
Stage：根据是否需要shuffle将Query拆分成不同的subpian，每一个subplan是一个stage。
Fragment：基本等价于Stage，属于在不同阶段的称呼。
Task：单个Worker节点上最小资源管理单元，在一个节点上，一个Stage只有一个Task，一个Query可能有多个Task。
Pipline：Stage按照LocalExchange切分为若干个Operator集合，每个Operator集合定义一个Pipline。
Driver：Pipline的可执行实体，Pipline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator、
Split：输入数据描述(数据实体是Page)，数量上和Drive一一对应，不仅代表实际数据源split，也代表了不同stage间传输的数据。
Operator：最小的物理算子。
数据传输相关
Exchange：表示不同Stage间的数据传输，大多数意义下等价于Shuffle
LocalExchange：Stage内的rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元)，默认数值是16
服务发现————Discovery Service
- worker配置文件配置Discovery Service地址
- worker节点启动后向Discovery Service注册
- Coordiantor从Discovery Service 获取 Worker的地址
通信机制
- Presto Client/JDBC Client与Server间通信：http
- Coordinator与Worker间通信：Thrift/Http
- Worker与Worker间通信：Thrift/Http
多租户资源管理 - Resource Group
类似Yarn多级队列的资源管理方式，基于CPU、MEMORY、SQL执行数进行资源使用量限制。优点：轻量的Query级别的多级队列资源管理模式。缺点：存在一定滞后性，只会对Group中在运行的SQL进行判断。
多租户下的任务调度
- Stage调度：
- AllAtOnceExecutionPolicy：同时调度，延迟低，会存在任务空跑
- PhasedExecutionPolicy：分阶段调度。有一定延迟，节省部分资源
- Task调度
- Split调度：按照固定的时间片，轮训Split处理数据，处理1s，再重新选择一个Split执行，Split之间存在优先级。这样做可以保证小Query快速执行，也可以保障大Query存在固定比例的时间片，不会被完全饿死。
内存计算
-
PipLine化的数据处理：语义上保证了每个Task内的数据流式处理，更好地实现算子间的并行。
-
Back Pressure Mechanism：控制split生成流程，控制operator的执行。
