网站安全检测可以检测哪些内容风险信息,网站后台关键词链接怎样做,seo短视频网页入口引流在线,北京的网站建设简介#xff1a; 随着越来越多的企业开始做数据湖分析#xff0c;数据量的持续增加#xff0c;数据分析需求也会越来越多#xff0c;在一个共享的数据湖分析引擎#xff0c;如何防止多租户之间的查询相互影响是一个很通用的问题#xff0c;本文以阿里云DLA Presto为例 随着越来越多的企业开始做数据湖分析数据量的持续增加数据分析需求也会越来越多在一个共享的数据湖分析引擎如何防止多租户之间的查询相互影响是一个很通用的问题本文以阿里云DLA Presto为例介绍了一种基于实时惩罚机制实现算力隔离的原理能有效使共享Presto集群解决多租户之间查询相互影响的问题。
一、背景介绍 根据MarketsandMarkets市场调研显示预计数据湖市场规模在2024年将从2019年的79亿美金增长到201亿美金。随着数据湖的规模增长基于交互式查询引擎Presto的数据湖分析负载也随着增加。在共享的Presto集群里大查询之间非常容易相互影响在此背景下对查询进行算力隔离也就迫在眉睫。本文主要介绍数据湖分析引擎Presto如何解决多租户算力隔离的技术。 二、数据湖分析Presto算力隔离遇到的挑战 1、数据湖分析Presto方案架构
Presto是一个定位大数据分析领域的分布式SQL查询引擎适合GB到PB级别的数据的交互式分析查询。与Hive、Spark等其他查询引擎不同它是一个全内存计算的MPP引擎能快速获取查询结果因此它特别适合进行adhoc查询、数据探索、BI报表、轻量ETL等多种业务场景。下图以阿里云数据湖分析简称DLA的Presto架构为例说明。 FrontNode整个架构的接入层FrontNode它通过MySQL协议提供服务只要兼容MySQL协议的客户端、BI工具可以直接连接并提交查询它接收到SQL后会对SQL做解析转换为Presto风格的SQL并调度到相应的Presto集群。Presto引擎中间的Presto计算引擎适合交互查询用户可以根据业务特点如果是频繁类型的查询适合选择独享集群若是偶发类型的查询适合Serverless类型的共享集群。元数据左侧是统一元数据相对Presto原生的元数据它能统一管理所有Connector的元数据并支持多租户的权限控制并提供了MySQL风格的GRANT/REVOKE机制便于租户内的子账户权限管理。存储层底层是存储层Presto并不自带存储但它支持许多的数据源并支持不同数据源之间的关联查询。2、数据湖分析Presto算力隔离遇到的挑战
社区原生的Presto在多租户隔离场景考虑的比较少主要通过ResourceGroup机制限制每个资源组的资源包括CPU和内存上限它最大的问题是只能限制新的查询即一个Group的资源用超后其新提交的查询会被排队直到其使用的资源降到上限之下对于正在执行的查询如果超过资源组的资源上限ResourceGroup不会做限制。因此在一个共享的Presto集群中一个大查询还是可以把整个集群的资源消耗完从而影响其他用户的查询。在DLA实际生产过程中上千用户共享的集群此问题尤为突出。 与Spark、Hive等其他查询引擎可以简单设置执行资源并发限制资源不同Presto首先需要预先启动所有Stage并且所有查询在Worker执行时共享线程和内存因此无法通过简单地设置执行的并发控制其资源的使用。 业界采用比较多的解决方案是基于Presto On Yarn实现资源隔离。为每个资源组启动一个独立的Presto On Yarn集群并通过Yarn的资源管理机制实现Presto集群之间的隔离。其优点是资源隔离比较好但需要预先为每个租户启动一个专属的集群即使没有查询在执行也需要维护该集群在数据湖分析Serverless服务场景租户较多且他们的查询很多都是间歇性的其资源消耗也不稳定无法预估。因此如果为每个用户都启动一个专属集群会导致严重的资源浪费。 三、基于实时惩罚机制实现DLA Presto的算力隔离技术解析 1、社区Presto的Query执行与调度原理
下面以一个聚合类型的查询为例简要介绍社区Presto的Query查询执行原理。 Select id, sum(money) from employ where id10000 group by id;
注*左右滑动阅览 一个查询会被解析为包含多个Stage的物理执行计划每个Stage包含若干TaskTask会被Coordinator调度到Worker上执行。在Worker上每个Task会包含多个Driver每个Driver对应一个Split数据切片每个Driver会包含若干操作算子Operator。 它在Presto上的调度逻辑如下图所示在主节点Coordinator和从节点Worker都有相应的调度逻辑。 在Coordinator上主要负责多租户Group之间和Group内的Query调度。若Group使用的资源未达到上限则Query会被解析并调度。Query解析后以Task为单位一次性把所有Stage的Task分配给Worker。 Worker会根据数据切片Split生成Driver并放到调度队列。Worker执行Split以时间片为单位一次最多只执行1秒未完成则继续放入排队队列。 2、基于实时惩罚机制的核心思想 数据切片Split的执行基于CPU时间片可以做进一步的限制实时统计每个Group消耗的CPU时间当Group累计每秒消耗的CPU时间超过其配置的资源上限则开始惩罚该Group即不再执行其Split直到其累计CPU消耗小于资源上限。 举例的描述GroupA的配置可使用的CPU核数上限为NCoordinator每秒为GroupA生成N秒的CPU时间片当GroupA的查询执行时实时统计GroupA的CPU消耗其每秒的CPU消耗为cpus累计消耗为Csum每秒都需要让Csum加上cpus然后做如下的判断逻辑 如果 Csum N下一秒不需要惩罚并重置Csum 0。如果 Csum 2N需要惩罚1秒下一秒GroupA的所有Split都不会被调度执行并设置Csum Csum - N。如果 N Csum 2N下一秒不会被惩罚但Csum-N的值会进入下一秒的判断逻辑下一秒被惩罚的概率会加大并设置Csum Csum - N。上图以N3为例举例说明 第一秒 cpus2Csum2下一秒不惩罚。第二秒 cpus5Csum5下一秒不惩罚。第三秒 cpus4Csum6下一秒惩罚。第四秒 cpus0Csum3下一秒不惩罚第五秒 cpus7Csum7下一秒惩罚。第六秒 cpus0Csum4下一秒不惩罚。第七秒 cpus5Csum6下一秒惩罚。第八秒 cpus0Csum3下一秒不惩罚。第九秒 cpus3Csum3下一秒不惩罚。3、基于实时惩罚机制实现DLA Presto的算力隔离的实现原理 鉴于DLA的Presto已经实现了Coordinator的高可用一个集群中包含至少两个Coordinator因此ResourceManager模块首先需要实时收集所有Coordinator上所有Group的资源消耗信息并在ResourceManager中汇总然后计算并判断每个Group是否需要被惩罚最终把每个Group是否需要被惩罚的信息同步给所有Worker。如下图所示 与社区Presto的Worker把所有Split放到一个waitingSplit队列不同DLA Presto首先在Worker上引入Group概念每个Group都会维护一个自己的队列。Worker在调度选择Split时首先会考虑Group是否被惩罚如果被惩罚则不会调度该Group的Split只有未被惩罚的Group的Split会被选中执行。之后Worker会统计所有查询的资源消耗并汇总到Coordinator并进入到下一个判断周期。最终达到控制Group算力的能力。 四、DLA Presto算力隔离上线效果
接下来以TPCH做测试验证租户算力隔离效果。测试场景
四台Worker每台配置是4C8G选用TPCH第20条SQL进行实验因为它包含5个JOIN个需要使用大量CPU实验场景四个租户资源上限相同都为8其中A、B、C各提交一条SQLD同时提交5条SQL。可以看到社区Presto版本由于租户D提交查询多相应的Split会更多因此他能分配更多的资源这对其他用户是不公平的。而在DLA版本中由于预先为租户D和其他用户配置了相同的资源上限因此租户D使用的资源和其他用户也是差不多的。 下图是8条查询的耗时对比 可以看到在开源Presto版本里面所有8条查询耗时几乎一样而在DLA的版本里面租户A、B、C的查询耗时较短而租户D由于使用过多资源被惩罚因此它的5条查询耗时较长。 在DLA的实际生产过程中为每个用户设置指定的资源上限并进行比较精准的控制杜绝了一条或多条查询占用大量的资源影响其他用户的查询。也不再出现少量查询就把Presto集群搞垮的情况。保证了用户查询时间的稳定性。另一方面对于那些查询量很大的用户DLA还提供了独享集群模式能让查询以更优的性能完成。 五、总结 随着越来越多的企业开始做数据湖分析数据量的持续增加数据分析需求也会越来越多在一个共享的数据湖分析引擎如何防止多租户之间的查询相互影响是一个很通用的问题本文以阿里云DLA Presto为例介绍了一种基于实时惩罚机制实现算力隔离的原理能有效使共享Presto集群解决多租户之间查询相互影响的问题。
原文链接
本文为阿里云原创内容未经允许不得转载。
