这是我参与「第四届青训营 」笔记创作活动的第11天，这次笔记记录了OLAP引擎的发展历程和Presto的架构、执行流程、多租户资源管理。
Presto介绍
Presto是大数据场景中常用的查询引擎，其采用master- slave架构，支持跨数据源类型查询，支持动态横向扩展，采用了内存并行处理、跨集群节点管线执行、多线程执行模型、高效的扁平内存数据结构、Java字节码生成等技术，来完成分布式数据查询和处理。现已广泛应用于OLAP场景。
OLAP介绍
OLAP(OnLine Analytical Processing)对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力
大数据与OLAP的演进
Hadoop：基于廉价机器的存算分离的大规模分布式处理系统。
常见的OLAP引擎
Presto最初是由facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎，其具有如下的特点：
- 多租户任务的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- pipeline式数据处理
presto是完全基于内存计算的，其生来就是用来处理大数据量的，并带来极大的性能提升，在Facebook和京东的测试中，Presto的查询性能比hive提高5-10倍，尤其适合OLAP场景，期望快速返回结果的实时分析。
Presto的架构
Presto是master- slave架构的，由一个Coordinator节点，一个Discovery 节点，和多个Worker节点组成
Presto对于worker资源的管理采用双向通信机制，首先由worker向coordinator注册服务，coordinator收集到可服务的worker节点后，再反向探测worker的状态，最终按照worker的状态分类存储，只有处于active状态的worker才可以被正常调度。
Coordinator通过定期收集worker节点的内存状况，从而汇总得到整个集群中当前Total以及Free的内存大小；另一方面Coordinator还通过不断检查集群中所有正在运行Query的内存使用情况，判断如果出现内存不足，会从所有Running的Query中挑选当前内存占用最多的query，并将其强制终止执行（有开关控制）。
在Worker层面，Presto又将本地内存分成三部分，分别为：
- General Memory
- System Memory
- Reserved Memory
Presto对于资源管控另一个维度是CPU，这也是在Presto中为了在用户态解决多租户问题而非常有特色的一点。
Coordinator(协调器): 负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。
Discovery(发现服务): 通常内嵌于Coordinator节点中。
Worker(工作节点): 负责实际执行查询任务，从对应数据库中读取数据；Worker启动后向；
Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。
master- slave客户端、协调器和工作节点之间的通信和数据传输完全通过http/https的Restful Api调用。
协调器是整个presto集群的大脑，用户可以通过Presto CLI、JDBC或者ODBC驱动连接协调器，进行sql的交互。
Connector
Presto可以通过不同类型的Connector访问多种数据源，目前（以trino-380为例）支持的Connector有：Accumulo、Blackhole、Cassandra、Clickhouse、Delta-Lake、Druid、Elasticsearch、Geospatial、Google-Sheets、Hive、Iceberg、Jmx、Kafka、Kinesis、Kudu、Mariadb、Memory、ML、Mongodb、Mysql、Oracle、Phoenix、Point、Postgresql、Prometheus、Raptor、Redis、Redshift、Singlestore、Sqlserver、Teradata、Tpc-Ds、Tpch。
可以将Connector当作Presto访问不同数据源的驱动程序，每种Connector都实现了Presto中标准的SPI接口，也即只要实现了Presto中标准的SPI接口，就可以轻易实现适合自己需求的Connector。
Catalog
Presto中的Catalog，相当于数据库的一个实例。在Presto的配置文件中，以.properties结尾，每个properties就对应了Presto中的一个Catalog。
Schema
Presto中的Schema，类似于mysql中的Database，一个Catalog中可以有多个Schema。
Table
Presto表，与数据库中的表的含义一致，都指向具体的物理存在的表。
Presto执行过程
和其他数据处理框架类似，SQL通过Client提交给Coordinator后便产生了对应的Query，经过Analyzer，Planner等模块处理，Query被拆分成Stage，Stage再被拆分成Task，即在Presto中查询按照Query -> Stage -> Task三级进行管理，Query/Stage/Task分别由各自的StateMachine驱动，并通过向下监听的方式感知下级状态变更，同时驱动本级状态的改变，最终驱动Query的状态从QUEUED -> FINISHED。
Presto之所以相对更快的原因之一是并行数据加载以及流水线计算，Page可以理解为一张Table的一个数据子集，Page是由多个Block组成，每个Block为单一类型，例如Int Block, Long Block, Varchar Block等，其代表了Table中的某一列中的部分数据，因此Presto也被称为列式存储，Presto在Task之间的数据传输采用Pull的模式，即上游Task计算输出的数据会存储在Task的临时空间中，等待下游Task来消费，这里涉及到一些关键的设计，例如计算/存储分离，内存管理，反压，数据分区等。
通信机制
Http 1.1 vs Thrift
Thrift具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率
Presto用户多租户隔离的手段是什么？
- Presto 通过Resource Group对不同的用户创建不同Group从而实现不同租户，不同场景的资源管理
Presto Resource Group的优缺点
- 优点：支持通配符的形式，对不同租户，不同提交场景下的用户进行限制
- 缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用
Presto是从哪几个方面实现了多租户的任务调度
- Stage调度策略
- Task的节点选择策略
- Split调度策略
Presto Stage调度的方式有哪些？
- AllAtOnceExecutionPolicy
- PhasedExecutionPolicy
Presto 进行 Task 调度时，有哪些调度方式？
- HARD_AFFINITY ： 计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输
- SOFT_AFFINITY ： 基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的 Task 调度到同一个 Worker
- NO_PREFERENCE ： 随机选取，常用于普通的纯计算 Task
Presto是如何实现Back pressure mechanism的
- 控制split生成流程
- 针对每个Task定时检查, 如果 OutputBuffers 使用率低于 0.5 (下游消费较快, 需要提高生产速度), Split 并发度 + 1
- 控制Operator执行速度
- "sink.max-buffer-size" 写入buffer的大小控制
- "exchange.max-buffer-size" 读取buffer的大小控制
- Buffer 达到最大值时Operator会进入阻塞状态
Presto多数据源支持的优点与缺点
- 优点：支持多数据源的联邦查询
- 缺点：针对不同数据源，还存在许多问题需要解决
- 谓词下推
- 每个数据源都需要单独的一套catalog管理
- 如何针对数据源进行分片操作
参考文章
【大数据专场 学习资料三】第四届字节跳动青训营 - 掘金 (juejin.cn)
