王飞活的博客

当query被submit到resourceGroupManager后，query的状态变成WAITING_FOR_RESOURCES，WAITING_FOR_RESOURCES的状态主要为等待足够的worker个数，当worker的个数足够后，状态转为DISPATCHING状态。：QUEUED状态是query的初始状态，当CN收到查询的时候，会首先将该查询的状态置为QUEUED状态，QUEUED的查询会等待resource-group有可运行资源后进入到WAITING_FOR_RESOURCES阶段。

我们知道在Presto中有个叫Pipeline的概念，Pipeline其实就是一条包含各个算子的流水线，如下所示。本文主要介绍在Presto中，Pipeline是如何划分的。

在Presto的Stage Performace中，每个Operator中都会有Driver个数的显示，如下图所示。本文主要介绍Presto中是如何决定Driver的个数的。

在Presto中，Union的算子包括自动去重的Union操作和不去重的Union All操作。本文主要简述在Presto中Union All算子是如何实现和Union算子中是如何实现数据去重的。

在Presto中，ReorderJoins 的优化规则是指遍历Join表的各种顺序和类型的组合，在所有的组合中找到一个执行代价最小的执行计划来执行。ReorderJoins 是Join操作最重要的优化规则，本文主要介绍在Presto中，ReorderJoins 是如何实现的。

在Presto中，select xxx from xxx where xxx in (select xxx from xx) 这种形式的SQL会被转成成Semi Join执行，通过xxx与子查询Join并且保留xxx的值实现in的过滤功能。本文主要介绍Semi Join在Presto中是如何实现的。

在Presto 之GENERAL POOL & RESERVED POOL_王飞活的博客-优快云博客的文章中，我们介绍了在Presto中，内存分成了保留区和通用区两个内存池区进行管理。本文则主要介绍Presto是是如何实现内存池管理的。

我们知道，在Presto中，查询内存的分GENERAL内存池内存和RESERVED内存池内存。本文主要讲述在Presto中GENERAL POOL和RESERVED POOL的划分意义以及大小计算。

Cross Join是指无条件的join。因为Cross Join的代价为笛卡尔乘积，代价很大，因此在Presto的执行优化中，会尽量消除掉Cross Join。Presto Cross Join的消除原理主要是尽可能通过对Join表的重新排序实现将Cross Join转换为Inner Join。本文主要讲述在Presto中是如何实现Cross Join消除的。

其实在Presto中，hash_partition_count的意义是限制一个Stage最多可以在多少个worker节点上运行，hash_partition_count超过Worker的总数量时此参数不起作用。hash_partition_count也不是对所有类型的Stage都可以生效，只有对可拆分成多个Task运行 的Stage才生效，比如Partition Join， Order by等算子，对于TableScan，TaskOutput等不可拆分运行的Stage，此参数不起作用。

在Presto中，Join的类型主要分成Partitioned Join和Broadcast Join，在Presto 之Hash Join的Partition_王飞活的博客-优快云博客中已经介绍了Presto的Partitioned Join的实现过程，本文主要介绍Broadcast Join的实现。

反压（backoff）是指网络请求如果失败时，将适当削弱访问的请求流量，避免造成更大拥塞。在Presto中，支持Exchange和MetaStore两种请求的自动反压，本文主要介绍在Presto中，这两种反压是如何实现的。

在Presto的UI中，可以看到每一个查询的每一个算子的各种汇总的统计信息，比如输入输出数据量，端到端时间，阻塞时间等，如下所示：本文主要介绍在Presto中，Blocked Time的含义以及在Presto中Block Time是怎么实现的。

在Presto中，当两表Join为Hash Join并且join_distribution_type为PARTITIONED的时候，Presto会将Build表分区（Partition）后再进行Join操作。

我们知道，在Presto中，与inner join相比，left join会保留probe表（左表）的所有值，right join会保留build表（右表）的所有值。inner join的是实现在文章Presto之Hash Join 数据碰撞的实现过程_王飞活的博客-优快云博客中已经介绍，本文主要是介绍在Presto中，Left Join和Right Join的实现和它们Inner Join的实现过程的区别。

如果hive.hdfs.impersonation.enabled=false，则Presto将直接使用hive.hdfs.presto.principal设置的用户与hdfs进行交互，所以如果新建文件，文件的数组将为hive.hdfs.presto.principal用户。2. hive.hdfs.impersonation.enabled的实现原理是通过创建访问Hdfs的Ugi来控制的。

在Presto中，Operator是真正具备计算能力的算子。本文主要通过代码走读来理解在Presto中如何将SQL语句一步一步转换到Operator执行算子的。在Presto中，整体的转换过程为SQL语句 -> Statement -> RelationPaln -> LogicalPlanner -> fragmentedPlan -> Operator。如下为其实现过程的代码走读。

在Presto中通过数据源的Connector读取数据的时候，返回来的是Page，一个Page中包含每列数据Block，Block中会包含多行数据。本文主要是通过Presto源码走读了解在Presto的Hive Connector中是如何通过Batch Read实现到Hive数据源取Page的时候进行多行数据读取功能的实现过程。

本文主要介绍在Presto（OpenLookeng）中的BTree索引的代码实现。关于BTree索引原理的介绍可以参考官网资料。

本文承接Presto（OpenLookeng）之BloomFilter索引优化代码走读_王飞活的博客-优快云博客一文继续通过走读代码介绍Presto（其实是OpenLookeng）中的另外一种索引:Bitmap索引的实现过程。在Presto中，Bitmap索引的官网介绍可以参考。

本文计划通过走读代码来理解Presto（其实是OpenLookeng）中BloomFilter索引的建立以及Presto中利用BloomFilter索引对查询进行优化的执行流程。。

本文主要探索在Presto中Explain功能是如何实现的。在Presto中，Explain用法有两种，一种是单纯的explain，此场景只会显示经过RBO优化后的执行计划，但是查询并不会真正地执行。第二种是explain analyze，此场景会真正执行查询，而且打印出来的执行计划是真正运行的执行计划。不仅如此，explain analyze还包含各个stage的时间等，信息比单独的explain丰富。

本文只要探索在Presto中groupby是怎么实现的。在Preso中，groupby的分组主要通过对数据Hash的数值比较进行分组，其中有2种情况，一直是仅有一个groupby字段而且字段是Bigint类型的，此场景下会使用BigintGroupByHash来实现分组，其他的情况则使用MultiChannelGroupByHash实现多列分组。

1. Presto的内存模型 presto涉及到的内存分为堆内和堆外内存，堆内内存大小有jvm.config的Xmx参数指定，堆外内存由jvm.config的MaxDirectMemorySize参数指定。presto在lzo等数据源压缩文件的解压过中会使用到。官方建议是将堆内内存的Xmx和Xms设置为系统总内存的80%，剩余的留给堆外内存使用。 在堆内分成两大块，一块是预留/缓存区的内存，大小由memory.heap-headroom-per-node参数指定指定，这...

一. 前言presto中，RBO的规则有两种写法，一种是implements Rule（比如PushLimitThroughUnion等），一种是implements PlanOptimizer（比如LimitPushDown等），本文通过走读LimitPushDown代码来了解implements PlanOptimizer的规则是怎么调用的。二. LimitPushDown调用关系LimitPushDown::optimize SimplePlanRewriter.rewrite

虽然presto是基于标准的sql语法进行开发使用，但是在实际使用中，有时候标准的sql不一定能满足的了各个业务场景的需要，需要做一些定制化的sql语法增强或者修改等。 本文假设以实现一个刷新缓存的命令refresh cache作为样例探索如何进行presto的sql语法的适配开发。 首先需要适配SqlBase.g4的语法树关键词声明： sqlBase.g4中声明关键词： ..... | VACUUM TABLE qualifiedN...

一. 引言 RBO是SQL引擎中基于规则对用户输出的sql进行等价优化，是所有SQL引擎中性能优化中最为重要的一环。本文将浅述Presto的RBO优化代码中作者对算子输出进行列裁剪部分的理解。二. 部分的算子列裁剪规则1. PruneAggregationColumns 根据output裁掉Aggregation的无用的输出列，比如select 1 from (select count(id) from pquent_test2) 中count(id)的不会向下游输出任何...

一. 前言：prestodb是通过on spark的方式对批查询进行支持的。prestodb on spark的参考文档可以参考：https://docs.google.com/document/d/1aURQWDY1NJZ7xPS6jnsFcQY7pOIqHGkHzJrcPu-42Tk/本文主要对prestodb on spark 功能进行实践测试。二. 准备步骤 启动hadoop 执行hadoop-3.1.3/sbin/start-all.sh 启动即可。...

一. 概论 Presto对ORC和Parquet格式存储的Hive表的处理很为友好，Presto访问这两种格式表时进行了大量的优化，以致得到很为优越的性能。 Presto在读取文件上和Spark等其他数据处理引擎组件最为与众不同是Presto读取ORC/Parquet格式表并没有采用传统的MR方式，而是采用了自己读取和切分和转换文件的方式。这样很容易实现自己控制多worker多并发读取，多pipeline同时加工，也能很容易进行列裁剪分区裁剪等读取优化，可以有效避免读取数据成为数据...

Presto中谓词不会被下推的情形

1、 Presto中的task 在Presto中，coordinator对worker的任务分发和调度是以task的形式进行的。一个分布式计划的Stage包含1个或者多个Task，每个Task包含1个或者多个Split。了解Presto中的Task管理机制有助于了解Presto中的Coordinator与Worker之间的调度机制。 在Presto中，每个task有单独的ID，TasK ID的构成格式为queryID.stageID.Task顺序号，比如：比如：202111...

1. 引言：本文讨论在presto中，数据在上下游加工传递的时候，到时是下游主动向上游拉数据，还是上游主动向下游推数据的问题。下述会分成split与split之间传递，task与task之间传递，stage与stage之间传递分开讨论。2. split <--> split在presto之间，split之间传递数据不需要经过网络，是在同一个进程内进行，因此presto将数据传递的方式设计为上游的split直接通过下游split的addInput接口推给下游。代码在Driver::

presto本身虽然是支持在计算时内存不足溢出到硬盘功能的，但presto更偏向于打造一个快短的纯内存计算的交互式计算引擎，因此在此功能没有下太多功夫，仅实现了个别算子支持spill功能，实现程度上也比不上Hive，Spark等mr类型的组件完善。因此使用presto执行厚重的SQL时候常常会有内存不足的错误。 presto的溢出硬盘是在worker的operator计算阶段处理的，支持溢出到硬盘的Operator有： 1. HashAggregationOpe...

一.概述schema演进一般用于表的列变换（如增加/删除/调整列位置）和修改列类型的场景下查询能正常使用。本文主要介绍Presto中是如何支持Parquet文件的Schema演进的。要在presto中支持schema演进，需要开启parquet_use_column_names。在presto中，存在着三种shcema：分别是：表schema：表的schema指的就是create table时候指定的schema结构。partition schema：partition schema指的

一. 引言理论上讲，limit下推到越底层，上游吐出的数据就越少，计算效率就越高。因为，带有limit的计划执行树，在Presto中的RBO优化中，都尽可能将其推到底下执行。本文主要讲几个Presto RBO优化规则中与Limit下推相关的优化。二. PushLimitThroughOffset 实现效果： PushLimitThroughOffset用于将limit下推到Offset算子的底下执行，如下图所示： 2. 实现原理 public Resu...

一. 引言count是presto中支持的聚合算子的一种，本文走读presto中是如何实现select count(*) from xxx来探讨presto中是如何实现数据聚合操作的。了解presto中的聚合操作的实现对于了解presto在读文件方面的优化和了解presto的数据传递全貌方面甚至动态算子代码生成方面有较大的帮助意义。本文以扫描一个parquent表的行数为例进行代码走读和探讨。 presto中聚合操作的流程大体如下：二. 数据源扫描代码走读在presto中...

prestosql与prestodb的支持程度 在hudi的官网上，并没有介绍prestosql与hudi的集成对接，其实只要将hudi的jar包放到prestosql的connector的目录下，prestosql也是能正常对接的，但是 prestosql对hudi的对接不如prestodb完善，两者的对接情况如下： COW的实时视图 COW的增量查询 MOR的实时视图 MOR的增量查询 MOR的读优化视图 prestosql Y N ...

一. 引言支持谓词下推是Presto中一个重要的性能优化能力，本文将通过代码走读来探索Presto在Hive数据源中是如何实现filter下推的以及以parquet格式的Hive表为例探索在数据源tableScan的时候如何应用filter信息进行优化的。本文以带过滤条件查询“select id from t1 where id < 5 and id > 1 and name = '22'”为例进行代码走读。二. 下推条件推给TableScan上边的filter算子“wher

presto中生成split的基本原理是： 1. presto先扫描所有所有需要访问的hdfs的数据文件，如果hdfs文件比hive.max-split-size(默认64M) 大，则一个文件生成一个split.其代码实现在于BackgroundHiveSplitLoader::loadSplits中，loadSplits会扫描分区的所有文件，每个文件创建一个InternalHiveSplit，提交到HiveSplitSource中异步生成真正的HiveSplit。 2. 在Hi...

presto的split 在presto中，coordinator会将state切分成多个task提交到各个worker上并行执行。每个task的输入数据是一个或者多个split，split是表的表的一部分数据，比如Hive表是hdfs上边的一个文件。 因为worker读取split数据需要读取hdfs文件，因为如果split能恰好分配到数据所在的worker节点进行读取和计算，能节省很多的网络传输消耗，有利于加速查询性能。 presto中提供了两...