0 - 前言

Facebook的數(shù)據(jù)倉(cāng)庫(kù)存儲(chǔ)在少量大型Hadoop/HDFS集群。Hive是Facebook在幾年前專為Hadoop打造的一款數(shù)據(jù)倉(cāng)庫(kù)工具捌年。在以前采驻，F(xiàn)acebook的科學(xué)家和分析師一直依靠Hive來(lái)做數(shù)據(jù)分析墓毒。但Hive使用MapReduce作為底層計(jì)算框架动羽，是專為批處理設(shè)計(jì)的。但隨著數(shù)據(jù)越來(lái)越多镣典，使用Hive進(jìn)行一個(gè)簡(jiǎn)單的數(shù)據(jù)查詢可能要花費(fèi)幾分到幾小時(shí)兔毙，顯然不能滿足交互式查詢的需求。Facebook也調(diào)研了其他比Hive更快的工具兄春，但它們要么在功能有所限制要么就太簡(jiǎn)單澎剥，以至于無(wú)法操作Facebook龐大的數(shù)據(jù)倉(cāng)庫(kù)。

2012年開始試用的一些外部項(xiàng)目都不合適神郊，他們決定自己開發(fā)肴裙，這就是Presto。2012年秋季開始開發(fā)涌乳，目前該項(xiàng)目已經(jīng)在超過(guò) 1000名Facebook雇員中使用蜻懦，運(yùn)行超過(guò)30000個(gè)查詢，每日數(shù)據(jù)在1PB級(jí)別夕晓。Facebook稱Presto的性能比Hive要好上10倍多宛乃。2013年Facebook正式宣布開源Presto。

Presto的定位是開源分布式SQL查詢引擎，適用于交互式分析查詢征炼，數(shù)據(jù)量支持GB到PB字節(jié)析既。Presto本身并不存儲(chǔ)數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源谆奥，并且支持跨數(shù)據(jù)源的級(jí)聯(lián)查詢眼坏。

為何是SQL查詢引擎？而不是數(shù)據(jù)庫(kù)酸些？

和Oracle宰译、MySQL、Hive等數(shù)據(jù)庫(kù)相比魄懂，他們都具有存儲(chǔ)數(shù)據(jù)和計(jì)算分析的能力沿侈。如MySQL具有InnoDB存儲(chǔ)引擎和有SQL的執(zhí)行能力；如Hive有多種數(shù)據(jù)類型市栗、內(nèi)外表（且這么叫）的管理能力缀拭，且能利用MR、TEZ執(zhí)行HQL填帽。而Presto并不直接管理數(shù)據(jù)蛛淋，它只有計(jì)算的能力。

Presto 支持的數(shù)據(jù)源中篡腌，常見的RDBMS都支持铣鹏，如Oracle、MySQL哀蘑、PG等。NoSQL中支持MongoDB葵第、Redis绘迁、ElasticSearch等。大數(shù)據(jù)中支持Hive卒密、HBase（第三方）缀台、Kudu、Kafka等哮奇。

Presto 支持從多種數(shù)據(jù)源獲取數(shù)據(jù)來(lái)進(jìn)行運(yùn)算分析膛腐，一條SQL查詢可以將多個(gè)數(shù)據(jù)源的數(shù)據(jù)進(jìn)行合并分析。比如下面的SQL：a可以來(lái)源于MySQL鼎俘，b可以來(lái)源于Hive哲身。

select a.*,b.* from a join b on (a.id = b.id);

1 - Presto 優(yōu)勢(shì)&特點(diǎn)

• 多數(shù)據(jù)源、混合計(jì)算支持：支持眾多常見的數(shù)據(jù)源贸伐，并且可以進(jìn)行混合計(jì)算分析勘天；
• 大數(shù)據(jù)：完全的內(nèi)存計(jì)算，支持的數(shù)據(jù)量完全取決于集群內(nèi)存大小。它不像SparkSQL可以配置把溢出的數(shù)據(jù)持久化到磁盤脯丝，Presto是完完全全的內(nèi)存計(jì)算商膊；
• 高性能：低延遲高并發(fā)的內(nèi)存計(jì)算引擎，相比Hive（無(wú)論MR宠进、Tez晕拆、Spark執(zhí)行引擎）、Impala 執(zhí)行效率要高很多材蹬。根據(jù)Facebook的測(cè)試報(bào)告实幕，至少提升10倍以上；
• 支持ANSI SQL：這點(diǎn)不像Hive赚导、SparkSQL都是以HQL為基礎(chǔ)茬缩，Presto是標(biāo)準(zhǔn)的SQL。用戶可以使用標(biāo)準(zhǔn)SQL進(jìn)行數(shù)據(jù)查詢和分析計(jì)算吼旧；
• 擴(kuò)展性：有眾多SPI擴(kuò)展點(diǎn)支持凰锡，開發(fā)人員可編寫UDF、UDTF圈暗。甚至可以實(shí)現(xiàn)自定義的Connector掂为，實(shí)現(xiàn)索引下推，借助外置的索引能力员串，實(shí)現(xiàn)特殊場(chǎng)景下的MPP勇哗；
• 流水線：Presto是基于PipeLine進(jìn)行設(shè)計(jì)，在大量數(shù)據(jù)計(jì)算過(guò)程中寸齐，終端用戶（Driver）無(wú)需等到所有數(shù)據(jù)計(jì)算完成才能看到結(jié)果欲诺。一旦開始計(jì)算就可立即產(chǎn)生一部分結(jié)果返回，后續(xù)的計(jì)算結(jié)果會(huì)以多個(gè)Page返回給終端用戶（Driver）渺鹦。

2 - Presto應(yīng)用場(chǎng)景

實(shí)時(shí)計(jì)算
Presto 性能優(yōu)越扰法，實(shí)時(shí)查詢工具上的重要選擇。

Ad-Hoc查詢
數(shù)據(jù)分析應(yīng)用毅厚、Presto 根據(jù)特定條件的查詢返回結(jié)果和生成報(bào)表塞颁。

ETL
因支持的數(shù)據(jù)源廣泛、可用于不同數(shù)據(jù)庫(kù)之間遷移吸耿，轉(zhuǎn)換和完成ETL清洗的能力祠锣。

實(shí)時(shí)數(shù)據(jù)流分析
Presto-Kafka Connector 使用 SQL對(duì)Kafka的數(shù)據(jù)流進(jìn)行清洗、分析咽安。

MPP
Presto Connector有非常好的擴(kuò)展性伴网，可進(jìn)行擴(kuò)展開發(fā)，可支持其他異構(gòu)非SQL查詢引擎轉(zhuǎn)為SQL妆棒，支持索引下推是偷。

3 - 數(shù)據(jù)模型

Presto使用Catalog拳氢、Schema和Table這3層結(jié)構(gòu)來(lái)管理數(shù)據(jù)。如圖：

數(shù)據(jù)模型

Catalog：就是數(shù)據(jù)源蛋铆，每個(gè)數(shù)據(jù)源連接都有一個(gè)名字馋评，一個(gè)Catalog可以包含多個(gè)Schema，可以通過(guò)show catalogs命令看到Presto已連接的所有數(shù)據(jù)源刺啦。

Schema：相當(dāng)于一個(gè)數(shù)據(jù)庫(kù)實(shí)例留特，一個(gè)Schema包含多張數(shù)據(jù)表。通過(guò)以下方式可列出catalog_name下的所有Schema：

show schemas from'catalog_name'

Table：數(shù)據(jù)表玛瘸，與RDBMS上的數(shù)據(jù)庫(kù)表意義相同蜕青。通過(guò)以下方式可查看所有表：

show tables from 'catalog_name.schema_name'

在Presto中定位一張表，一般是catalog為根糊渊。例如：一張表的全稱為hive.test_data.test右核，標(biāo)識(shí)hive(catalog)下的 test_data(schema)庫(kù)中 test 表∶烊蓿可以簡(jiǎn)理解為：數(shù)據(jù)源的類別.數(shù)據(jù)庫(kù).數(shù)據(jù)表贺喝。

可使用：show catalogs查看數(shù)據(jù)源，show schemas from hive查看數(shù)據(jù)庫(kù)實(shí)例宗兼，show tables from default查看表躏鱼。

切換當(dāng)前使用的實(shí)例（在同一個(gè)數(shù)據(jù)源內(nèi)切換無(wú)需指定catalog 前綴）:

use hive.default

4 - Presto架構(gòu)

Presto的架構(gòu)圖如下：

Presto架構(gòu)

Presto查詢引擎是一個(gè)Master-Slave的架構(gòu)，由一個(gè)Coordinator節(jié)點(diǎn)殷绍，一個(gè)Discovery Server節(jié)點(diǎn)染苛，多個(gè)Worker節(jié)點(diǎn)組成，Discovery Server通常內(nèi)嵌于Coordinator節(jié)點(diǎn)中主到。Coordinator負(fù)責(zé)解析SQL語(yǔ)句茶行，生成執(zhí)行計(jì)劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點(diǎn)執(zhí)行登钥。Worker節(jié)點(diǎn)負(fù)責(zé)實(shí)際執(zhí)行查詢?nèi)蝿?wù)拢军。Worker節(jié)點(diǎn)啟動(dòng)后向Discovery Server服務(wù)注冊(cè)，Coordinator從Discovery Server獲得可以正常工作的Worker節(jié)點(diǎn)怔鳖。如果配置了Hive Connector，需要配置一個(gè)Hive MetaStore服務(wù)為Presto提供Hive元信息固蛾，Worker節(jié)點(diǎn)與HDFS交互讀取數(shù)據(jù)结执。

Presto執(zhí)行查詢過(guò)程
既然Presto是一個(gè)交互式的查詢引擎，其中最核心的就是Presto實(shí)現(xiàn)低延時(shí)查詢的原理艾凯，主要是下面幾個(gè)關(guān)鍵點(diǎn)：

1. 完全基于內(nèi)存的并行計(jì)算
2. 流水線
3. 本地化計(jì)算
4. 動(dòng)態(tài)編譯執(zhí)行計(jì)劃
5. 小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
6. 類BlinkDB的近似查詢
7. GC控制

為了介紹上述幾個(gè)要點(diǎn)献幔，這里先介紹一下Presto執(zhí)行查詢的過(guò)程：

提交查詢
用戶使用Presto Cli提交一個(gè)查詢語(yǔ)句后，Cli使用HTTP協(xié)議與Coordinator通信趾诗，Coordinator收到查詢請(qǐng)求后調(diào)用SqlParser解析SQL語(yǔ)句得到Statement對(duì)象蜡感，并將Statement封裝成一個(gè)QueryStarter對(duì)象放入線程池中等待執(zhí)行蹬蚁。

提交查詢

SQL編譯過(guò)程
Presto與Hive一樣，使用Antlr編寫SQL語(yǔ)法郑兴，語(yǔ)法規(guī)則定義在Statement.g和StatementBuilder.g兩個(gè)文件中犀斋。 如下圖中所示從SQL編譯為最終的物理執(zhí)行計(jì)劃大概分為5步，最終生成在每個(gè)Worker節(jié)點(diǎn)上運(yùn)行的LocalExecutionPlan情连，這里不詳細(xì)介紹SQL解析為邏輯執(zhí)行計(jì)劃的過(guò)程叽粹，通過(guò)一個(gè)SQL語(yǔ)句來(lái)理解查詢計(jì)劃生成之后的計(jì)算過(guò)程。

SQL解析過(guò)程

樣例SQL：

select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;

邏輯執(zhí)行計(jì)劃

物理執(zhí)行計(jì)劃
邏輯執(zhí)行計(jì)劃圖中的虛線就是Presto對(duì)邏輯執(zhí)行計(jì)劃的切分點(diǎn)却舀，邏輯計(jì)劃Plan生成的SubPlan分為四個(gè)部分虫几，每一個(gè)SubPlan都會(huì)提交到一個(gè)或者多個(gè)Worker節(jié)點(diǎn)上執(zhí)行。

SubPlan有幾個(gè)重要的屬性planDistribution挽拔、outputPartitioning辆脸、partitionBy屬性。

1. PlanDistribution表示一個(gè)查詢Stage的分發(fā)方式螃诅，邏輯執(zhí)行計(jì)劃圖中的4個(gè)SubPlan共有3種不同的PlanDistribution方式：Source表示這個(gè)SubPlan是數(shù)據(jù)源啡氢，Source類型的任務(wù)會(huì)按照數(shù)據(jù)源大小確定分配多少個(gè)節(jié)點(diǎn)進(jìn)行執(zhí)行；Fixed表示這個(gè)SubPlan會(huì)分配固定的節(jié)點(diǎn)數(shù)進(jìn)行執(zhí)行（Config配置中的query.initial-hash-partitions參數(shù)配置州刽，默認(rèn)是8）空执；None表示這個(gè)SubPlan只分配到一個(gè)節(jié)點(diǎn)進(jìn)行執(zhí)行。在下面的執(zhí)行計(jì)劃中穗椅，SubPlan1和SubPlan0 PlanDistribution=Source辨绊，這兩個(gè)SubPlan都是提供數(shù)據(jù)源的節(jié)點(diǎn)，SubPlan1所有節(jié)點(diǎn)的讀取數(shù)據(jù)都會(huì)發(fā)向SubPlan0的每一個(gè)節(jié)點(diǎn)匹表；SubPlan2分配8個(gè)節(jié)點(diǎn)執(zhí)行最終的聚合操作门坷；SubPlan3只負(fù)責(zé)輸出最后計(jì)算完成的數(shù)據(jù)。
2. OutputPartitioning屬性只有兩個(gè)值HASH和NONE袍镀，表示這個(gè)SubPlan的輸出是否按照partitionBy的key值對(duì)數(shù)據(jù)進(jìn)行Shuffle默蚌。在下面的執(zhí)行計(jì)劃中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的數(shù)據(jù)是按照rank字段Partition后的數(shù)據(jù)苇羡。

物理執(zhí)行計(jì)劃

5 - 完全基于內(nèi)存的并行計(jì)算

查詢的并行執(zhí)行流程

Presto SQL的執(zhí)行流程如下圖所示：

1. Cli通過(guò)HTTP協(xié)議提交SQL查詢之后绸吸，查詢請(qǐng)求封裝成一個(gè)SqlQueryExecution對(duì)象交給Coordinator的SqlQueryManager#queryExecutor線程池去執(zhí)行；
2. 每個(gè)SqlQueryExecution線程（圖中Q-X線程）啟動(dòng)后對(duì)查詢請(qǐng)求的SQL進(jìn)行語(yǔ)法解析和優(yōu)化并最終生成多個(gè)Stage的SqlStageExecution任務(wù)设江，每個(gè)SqlStageExecution任務(wù)仍然交給同樣的線程池去執(zhí)行锦茁；
3. 每個(gè)SqlStageExecution線程（圖中S-X線程）啟動(dòng)后每個(gè)Stage的任務(wù)按PlanDistribution屬性構(gòu)造一個(gè)或者多個(gè)RemoteTask通過(guò)HTTP協(xié)議分配給遠(yuǎn)端的Worker節(jié)點(diǎn)執(zhí)行；
4. Worker節(jié)點(diǎn)接收到RemoteTask請(qǐng)求之后叉存，啟動(dòng)一個(gè)SqlTaskExecution線程（圖中T-X線程）將這個(gè)任務(wù)的每個(gè)Split包裝成一個(gè)PrioritizedSplitRunner任務(wù)（圖中SR-X）交給Worker節(jié)點(diǎn)的TaskExecutor#executor線程池去執(zhí)行码俩；

查詢執(zhí)行流程

上面的執(zhí)行計(jì)劃實(shí)際執(zhí)行效果如下圖所示。

1. Coordinator通過(guò)HTTP協(xié)議調(diào)用Worker節(jié)點(diǎn)的 /v1/task 接口將執(zhí)行計(jì)劃分配給所有Worker節(jié)點(diǎn)（圖中藍(lán)色箭頭）
2. SubPlan1的每個(gè)節(jié)點(diǎn)讀取一個(gè)Split的數(shù)據(jù)并過(guò)濾后將數(shù)據(jù)分發(fā)給每個(gè)SubPlan0節(jié)點(diǎn)進(jìn)行Join操作和Partial Aggr操作
3. SubPlan1的每個(gè)節(jié)點(diǎn)計(jì)算完成后按GroupBy Key的Hash值將數(shù)據(jù)分發(fā)到不同的SubPlan2節(jié)點(diǎn)
4. 所有SubPlan2節(jié)點(diǎn)計(jì)算完成后將數(shù)據(jù)分發(fā)到SubPlan3節(jié)點(diǎn)
5. SubPlan3節(jié)點(diǎn)計(jì)算完成后通知Coordinator結(jié)束查詢歼捏，并將數(shù)據(jù)發(fā)送給Coordinator

執(zhí)行計(jì)劃計(jì)算流程

源數(shù)據(jù)的并行讀取

在上面的執(zhí)行計(jì)劃中SubPlan1和SubPlan0都是Source節(jié)點(diǎn)稿存，其實(shí)它們讀取HDFS文件數(shù)據(jù)的方式就是調(diào)用的HDFS InputSplit API笨篷，然后每個(gè)InputSplit分配一個(gè)Worker節(jié)點(diǎn)去執(zhí)行，每個(gè)Worker節(jié)點(diǎn)分配的InputSplit數(shù)目上限是參數(shù)可配置的瓣履，Config中的query.max-pending-splits-per-node參數(shù)配置率翅，默認(rèn)是100。

分布式的Hash聚合

上面的執(zhí)行計(jì)劃在SubPlan0中會(huì)進(jìn)行一次Partial的聚合計(jì)算拂苹，計(jì)算每個(gè)Worker節(jié)點(diǎn)讀取的部分?jǐn)?shù)據(jù)的部分聚合結(jié)果安聘，然后SubPlan0的輸出會(huì)按照group by字段的Hash值分配不同的計(jì)算節(jié)點(diǎn)，最后SubPlan3合并所有結(jié)果并輸出瓢棒。

6 - 流水線

數(shù)據(jù)模型
Presto中處理的最小數(shù)據(jù)單元是一個(gè)Page對(duì)象浴韭，Page對(duì)象的數(shù)據(jù)結(jié)構(gòu)如下圖所示。一個(gè)Page對(duì)象包含多個(gè)Block對(duì)象脯宿，每個(gè)Block對(duì)象是一個(gè)字節(jié)數(shù)組念颈，存儲(chǔ)一個(gè)字段的若干行。多個(gè)Block橫切的一行是真實(shí)的一行數(shù)據(jù)连霉。一個(gè)Page最大1MB榴芳，最多16*1024行數(shù)據(jù)。

數(shù)據(jù)模型

節(jié)點(diǎn)內(nèi)部流水線計(jì)算
下圖是一個(gè)Worker節(jié)點(diǎn)內(nèi)部的計(jì)算流程圖跺撼，左側(cè)是任務(wù)的執(zhí)行流程圖窟感。Worker節(jié)點(diǎn)將最細(xì)粒度的任務(wù)封裝成一個(gè)PrioritizedSplitRunner對(duì)象，放入pending split優(yōu)先級(jí)隊(duì)列中歉井。每個(gè)Worker節(jié)點(diǎn)啟動(dòng)一定數(shù)目的線程進(jìn)行計(jì)算柿祈，線程數(shù)task.shard.max-threads=availableProcessors() * 4，在config中配置哩至。每個(gè)空閑的線程從隊(duì)列中取出一個(gè)PrioritizedSplitRunner對(duì)象執(zhí)行躏嚎，如果執(zhí)行完成一個(gè)周期，超過(guò)最大執(zhí)行時(shí)間1秒鐘菩貌，判斷任務(wù)是否執(zhí)行完成卢佣，如果完成，從allSplits隊(duì)列中刪除箭阶，如果沒(méi)有虚茶，則放回pendingSplits隊(duì)列中。每個(gè)任務(wù)的執(zhí)行流程如下圖右側(cè)仇参，依次遍歷所有Operator嘹叫，嘗試從上一個(gè)Operator取一個(gè)Page對(duì)象，如果取得的Page不為空冈敛，交給下一個(gè)Operator執(zhí)行。

節(jié)點(diǎn)內(nèi)部流水線計(jì)算

節(jié)點(diǎn)間流水線計(jì)算
下圖是ExchangeOperator的執(zhí)行流程圖鸣皂，ExchangeOperator為每一個(gè)Split啟動(dòng)一個(gè)HttpPageBufferClient對(duì)象抓谴，主動(dòng)向上一個(gè)Stage的Worker節(jié)點(diǎn)拉數(shù)據(jù)暮蹂，數(shù)據(jù)的最小單位也是一個(gè)Page對(duì)象，取到數(shù)據(jù)后放入Pages隊(duì)列中癌压。

節(jié)點(diǎn)間流水線計(jì)算

7 - 本地化計(jì)算

Presto在選擇Source任務(wù)計(jì)算節(jié)點(diǎn)的時(shí)候仰泻，對(duì)于每一個(gè)Split，按下面的策略選擇一些minCandidates滩届。

1. 優(yōu)先選擇與Split同一個(gè)Host的Worker節(jié)點(diǎn)
2. 如果節(jié)點(diǎn)不夠優(yōu)先選擇與Split同一個(gè)Rack的Worker節(jié)點(diǎn)
3. 如果節(jié)點(diǎn)還不夠隨機(jī)選擇其他Rack的節(jié)點(diǎn)

對(duì)于所有Candidate節(jié)點(diǎn)集侯，選擇assignedSplits最少的節(jié)點(diǎn)。

8 - 動(dòng)態(tài)編譯執(zhí)行計(jì)劃

Presto會(huì)將執(zhí)行計(jì)劃中的ScanFilterAndProjectOperator和FilterAndProjectOperator動(dòng)態(tài)編譯為Byte Code帜消，并交給JIT去編譯為native代碼棠枉。Presto也使用了Google Guava提供的LoadingCache緩存生成的Byte Code。

動(dòng)態(tài)編譯執(zhí)行計(jì)劃

動(dòng)態(tài)編譯執(zhí)行計(jì)劃

上面的兩段代碼片段中泡挺，第一段為沒(méi)有動(dòng)態(tài)編譯前的代碼辈讶，第二段代碼為動(dòng)態(tài)編譯生成的Byte Code反編譯之后還原的優(yōu)化代 碼，我們看到這里采用了循環(huán)展開的優(yōu)化方法娄猫。

循環(huán)展開最常用來(lái)降低循環(huán)開銷贱除，為具有多個(gè)功能單元的處理器提供指令級(jí)并行。也有利于指令流水線的調(diào)度媳溺。

9 - GC控制

Presto團(tuán)隊(duì)在使用hotspot java7時(shí)發(fā)現(xiàn)了一個(gè)JIT的BUG月幌，當(dāng)代碼緩存快要達(dá)到上限時(shí)，JIT可能會(huì)停止工作悬蔽，從而無(wú)法將使用頻率高的代碼動(dòng)態(tài)編譯為native代碼扯躺。

Presto團(tuán)隊(duì)使用了一個(gè)比較Hack的方法去解決這個(gè)問(wèn)題，增加一個(gè)線程在代碼緩存達(dá)到70%以上時(shí)進(jìn)行顯式GC屯阀，使得已經(jīng)加載的Class從perm中移除缅帘，避免JIT無(wú)法正常工作的BUG。

10 - Presto TPCH benchmark測(cè)試

介紹了上述這么多點(diǎn)难衰，我們最關(guān)心的還是Presto性能測(cè)試钦无，Presto中實(shí)現(xiàn)了TPCH的標(biāo)準(zhǔn)測(cè)試，下面的表格給出了Presto 0.60 TPCH的測(cè)試結(jié)果盖袭。直接運(yùn)行presto-main/src/test/java/com/facebook/presto/benchmark/BenchmarkSuite.java失暂。

benchmarkName cpuNanos(MILLISECONDS) inputRows inputBytes inputRows/s inputBytes/s outputRows outputBytes outputRows/s outputBytes/s
                      count_agg     2.055ms   1.5M  12.9MB    730M/s  6.12GB/s      1      9B     486/s  4.28KB/s
                 double_sum_agg    14.792ms   1.5M  12.9MB    101M/s   870MB/s      1      9B      67/s    608B/s
                       hash_agg   174.576ms   1.5M  21.5MB   8.59M/s   123MB/s      3     45B      17/s    257B/s
               predicate_filter    68.387ms   1.5M  12.9MB   21.9M/s   188MB/s  1.29M  11.1MB   18.8M/s   162MB/s
                     raw_stream     1.899ms   1.5M  12.9MB    790M/s  6.62GB/s   1.5M  12.9MB    790M/s  6.62GB/s
                         top100    58.735ms   1.5M  12.9MB   25.5M/s   219MB/s    100    900B    1.7K/s    15KB/s
         in_memory_orderby_1.5M  1909.524ms   1.5M  41.5MB    786K/s  21.7MB/s   1.5M  28.6MB    786K/s    15MB/s
                     hash_build   588.471ms   1.5M  25.7MB   2.55M/s  43.8MB/s   1.5M  25.7MB   2.55M/s  43.8MB/s
                      hash_join  2400.006ms     6M   103MB    2.5M/s  42.9MB/s     6M   206MB    2.5M/s  85.8MB/s
            hash_build_and_join  2996.489ms   7.5M   129MB    2.5M/s    43MB/s     6M   206MB      2M/s  68.8MB/s
              hand_tpch_query_1  3146.931ms     6M   361MB   1.91M/s   115MB/s      4    300B       1/s     95B/s
              hand_tpch_query_6   345.960ms     6M   240MB   17.3M/s   695MB/s      1      9B       2/s     26B/s
sql_groupby_agg_with_arithmetic  1211.444ms     6M   137MB   4.95M/s   113MB/s      2     30B       1/s     24B/s
                  sql_count_agg     3.635ms   1.5M  12.9MB    413M/s  3.46GB/s      1      9B     275/s  2.42KB/s
             sql_double_sum_agg    16.960ms   1.5M  12.9MB   88.4M/s   759MB/s      1      9B      58/s    530B/s
          sql_count_with_filter    81.641ms   1.5M  8.58MB   18.4M/s   105MB/s      1      9B      12/s    110B/s
                sql_groupby_agg   169.748ms   1.5M  21.5MB   8.84M/s   126MB/s      3     45B      17/s    265B/s
           sql_predicate_filter    46.540ms   1.5M  12.9MB   32.2M/s   277MB/s  1.29M  11.1MB   27.7M/s   238MB/s
                 sql_raw_stream     3.374ms   1.5M  12.9MB    445M/s  3.73GB/s   1.5M  12.9MB    445M/s  3.73GB/s
                    sql_top_100    60.663ms   1.5M  12.9MB   24.7M/s   212MB/s    100    900B   1.65K/s  14.5KB/s
                  sql_hash_join  4421.159ms   7.5M   129MB    1.7M/s  29.1MB/s     6M   206MB   1.36M/s  46.6MB/s
        sql_join_with_predicate  1008.909ms   7.5M   116MB   7.43M/s   115MB/s      1      9B       0/s      8B/s
              sql_varbinary_max   224.510ms     6M  97.3MB   26.7M/s   433MB/s      1     21B       4/s     93B/s
             sql_distinct_multi   257.958ms   1.5M    32MB   5.81M/s   124MB/s      5    112B      19/s    434B/s
            sql_distinct_single   112.849ms   1.5M  12.9MB   13.3M/s   114MB/s      1      9B       8/s     79B/s
               sql_tpch_query_1  3168.782ms     6M   361MB   1.89M/s   114MB/s      4    336B       1/s    106B/s
               sql_tpch_query_6   286.281ms     6M   240MB     21M/s   840MB/s      1      9B       3/s     31B/s
                       sql_like  3497.154ms     6M   232MB   1.72M/s  66.3MB/s  1.15M  9.84MB    328K/s  2.81MB/s
                         sql_in    80.267ms     6M  51.5MB   74.8M/s   642MB/s     25    225B     311/s  2.74KB/s
                sql_semijoin_in  1945.074ms   7.5M  64.4MB   3.86M/s  33.1MB/s     3M  25.8MB   1.54M/s  13.2MB/s
                sql_regexp_like  2233.004ms   1.5M  76.6MB    672K/s  34.3MB/s      1      9B       0/s      4B/s
     sql_approx_percentile_long   587.748ms   1.5M  12.9MB   2.55M/s  21.9MB/s      1      9B       1/s     15B/s
               sql_between_long    53.433ms   1.5M  12.9MB   28.1M/s   241MB/s      1      9B      18/s    168B/s
sampled_sql_groupby_agg_with_arithmetic  1369.485ms    6M   189MB   4.38M/s   138MB/s      2     30B       1/s     21B/s
          sampled_sql_count_agg    11.367ms   1.5M  12.9MB    132M/s  1.11GB/s      1      9B      87/s    791B/s
sampled_sql_join_with_predicate  1338.238ms   7.5M   180MB   5.61M/s   135MB/s      1      9B       0/s      6B/s
     sampled_sql_double_sum_agg    24.638ms   1.5M  25.7MB   60.9M/s  1.02GB/s      1      9B      40/s    365B/s
             stat_long_variance    26.390ms   1.5M  12.9MB   56.8M/s   488MB/s      1      9B      37/s    341B/s
         stat_long_variance_pop    26.583ms   1.5M  12.9MB   56.4M/s   484MB/s      1      9B      37/s    338B/s
           stat_double_variance    26.601ms   1.5M  12.9MB   56.4M/s   484MB/s      1      9B      37/s    338B/s
       stat_double_variance_pop    26.371ms   1.5M  12.9MB   56.9M/s   488MB/s      1      9B      37/s    341B/s
               stat_long_stddev    26.266ms   1.5M  12.9MB   57.1M/s   490MB/s      1      9B      38/s    342B/s
           stat_long_stddev_pop    26.350ms   1.5M  12.9MB   56.9M/s   489MB/s      1      9B      37/s    341B/s
             stat_double_stddev    26.316ms   1.5M  12.9MB     57M/s   489MB/s      1      9B      38/s    342B/s
         stat_double_stddev_pop    26.360ms   1.5M  12.9MB   56.9M/s   488MB/s      1      9B      37/s    341B/s
 sql_approx_count_distinct_long    35.763ms   1.5M  12.9MB   41.9M/s   360MB/s      1      9B      27/s    251B/s
sql_approx_count_distinct_double    37.198ms   1.5M  12.9MB   40.3M/s   346MB/s      1      9B      26/s    241B/s