一、背景根据MarketsandMarkets市场调研，预计数据湖市场规模将从2019年的79亿增长到2024年的201亿。随着数据湖规模的增长，基于交互式查询引擎Presto的数据湖分析负载也随之增加。在共享的Presto集群中，大型查询很容易相互交互。在这种背景下，隔离查询的计算能力迫在眉睫。本文主要介绍数据湖分析引擎Presto是如何解决多租户算力隔离的技术。二、数据湖分析Presto算力隔离遇到的挑战1.数据湖分析Presto解决方案架构Presto是一款定位于大数据分析领域的分布式SQL查询引擎，适用于GB到PB级数据的交互分析和查询。不同于Hive、Spark等其他查询引擎，它是一个全内存计算的MPP引擎，可以快速获取查询结果，因此特别适用于即席查询、数据探索、BI报表、轻量级ETL等各种业务场景.下图以阿里云数据湖分析（简称DLA）的Presto架构为例。FrontNode：FrontNode，整个架构的接入层，通过MySQL协议提供服务。只要兼容MySQL协议的客户端和BI工具可以直接连接并提交查询，它会在收到SQLSQL后解析SQL并转换为Presto风格，并派发到对应的Presto集群。Presto引擎：中间的Presto计算引擎，适用于交互式查询。用户可以根据业务特点，针对频繁查询选择独享集群，针对零星查询选择Serverless共享集群。元数据：左边是统一的元数据。相比Presto原有的元数据，可以统一管理所有Connector的元数据，支持多租户权限控制；它还提供了MySQL风格的GRANT/REVOKE机制，方便租户使用。子账号权限管理。存储层：最底层是存储层。Presto没有自己的存储，但是支持很多数据源，支持不同数据源之间的关联查询。2.数据湖分析Presto算力隔离遇到的挑战社区原生的Presto在多租户隔离场景考虑的很少。它主要是利用ResourceGroup机制来限制每个资源组的资源（包括CPU和内存）的上限。它最大的问题是它只能限制新的查询，即当一个组的资源使用量超过后，它新提交的查询会被排队，直到它使用的资源低于上限；如果正在执行的查询超过资源组的资源上限，ResourceGroup不会限制。因此，在一个共享的Presto集群中，一个大的查询仍然会消耗整个集群的资源，从而影响其他用户的查询。在DLA的实际生产过程中，这个问题在上千用户共享的集群中尤为突出。不同于Spark、Hive等其他查询引擎可以简单设置执行资源并发数和限制资源，Presto首先需要提前启动所有stage，worker执行时所有查询共享线程和内存，所以无法简单设置执行并发来控制它的资源使用。业界广泛采用的方案是基于PrestoOnYarn实现资源隔离。为每个资源组启动一个独立的PrestoOnYarn集群，通过Yarn的资源管理机制实现Presto集群之间的隔离。优点是资源隔离比较好；但是需要提前为每个租户启动一个专用集群，即使不执行查询也需要维护集群。在数据湖分析serverless服务场景中，租户很多，他们的很多查询是断断续续的，其资源消耗也是飘忽不定，不可预测的。因此，如果为每个用户启动一个专用的集群，会导致资源的严重浪费。三、基于实时惩罚机制的DLAPresto算力隔离技术分析1、社区Presto的查询执行及调度原理下面以聚合查询为例，简单介绍一下社区Presto的Query（查询）执行原理。selectid,sum(money)fromemploywhereid>10000groupbyid;注：*左右滑动阅读一个query会被解析成包含多个Stage的物理执行计划，每个Stage包含若干Task，Task会被Coordinator调度到Worker上执行。在Worker上，每个Task包含多个Driver，每个Driver对应一个Split（数据切片）；每个Driver包含几个操作符。它在Presto上的调度逻辑如下图所示。主节点Coordinator和从节点Worker都有对应的调度逻辑。在Coordinator上，主要负责多租户组间和组内的查询调度。如果Group使用的资源没有达到上限，Query就会被解析调度。Query解析完成后，所有StageTask以Task为单位一次性分配给Worker。Worker会根据数据切片Split生成Driver，放入调度队列中。Worker以时间片为单位执行Split，每次最多只执行1秒。如果没有完成，则继续放入排队队列。2、基于实时惩罚机制的核心思想。数据片Split的执行还可以根据CPU时间片进一步限制：实时统计每组消耗的CPU时间。当该组每秒累计消耗的CPU时间超过其配置的资源上限时，则开始对该组进行惩罚，即不再执行其分裂，直至其累计CPU消耗小于资源上限。示例说明：GroupA的配置可以使用的CPU核数上限为N，Coordinator每秒为GroupA生成N秒的CPU时间片。当执行GroupA的查询时，会实时统计GroupA的CPU消耗，其每秒的CPU消耗为cpus，累计消耗为Csum。需要每秒给Csum加上cpus，然后做如下判断逻辑：如果Csum<=N：下一秒不需要惩罚；并重置Csum=0，如果Csum>=2N，则需要惩罚1秒，下一秒不会安排GroupA的所有Splits执行；并设Csum=Csum-N，如果N
