深度 | 数据湖分析算力隔离技术剖析-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

深度 | 数据湖分析算力隔离技术剖析

简介: 随着越来越多的企业开始做数据湖分析,数据量的持续增加,数据分析需求也会越来越多,在一个共享的数据湖分析引擎,如何防止多租户之间的查询相互影响是一个很通用的问题,本文以阿里云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架构为例说明。


image.png

  • 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 id>10000 group by id;

注:*左右滑动阅览


image.png

一个查询会被解析为包含多个Stage的物理执行计划,每个Stage包含若干Task,Task会被Coordinator调度到Worker上执行。在Worker上,每个Task会包含多个Driver,每个Driver对应一个Split(数据切片);每个Driver会包含若干操作算子Operator。


它在Presto上的调度逻辑如下图所示,在主节点Coordinator和从节点Worker都有相应的调度逻辑。

image.png

在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核数上限为N,Coordinator每秒为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。

image.png

上图以N=3为例举例说明:


  • 第一秒 cpus=2,Csum=2;下一秒不惩罚。
  • 第二秒 cpus=5,Csum=5;下一秒不惩罚。
  • 第三秒 cpus=4,Csum=6;下一秒惩罚。
  • 第四秒 cpus=0,Csum=3;下一秒不惩罚
  • 第五秒 cpus=7,Csum=7;下一秒惩罚。
  • 第六秒 cpus=0,Csum=4;下一秒不惩罚。
  • 第七秒 cpus=5,Csum=6;下一秒惩罚。
  • 第八秒 cpus=0,Csum=3;下一秒不惩罚。
  • 第九秒 cpus=3,Csum=3;下一秒不惩罚。


3、基于实时惩罚机制实现DLA Presto的算力隔离的实现原理


鉴于DLA的Presto已经实现了Coordinator的高可用,一个集群中包含至少两个Coordinator,因此ResourceManager模块首先需要实时收集所有Coordinator上所有Group的资源消耗信息,并在ResourceManager中汇总,然后计算并判断每个Group是否需要被惩罚,最终把每个Group是否需要被惩罚的信息同步给所有Worker。如下图所示:

image.png

与社区Presto的Worker把所有Split放到一个waitingSplit队列不同,DLA Presto首先在Worker上引入Group概念,每个Group都会维护一个自己的队列。Worker在调度选择Split时,首先会考虑Group是否被惩罚,如果被惩罚,则不会调度该Group的Split;只有未被惩罚的Group的Split会被选中执行。之后Worker会统计所有查询的资源消耗并汇总到Coordinator,并进入到下一个判断周期。最终达到控制Group算力的能力。


四、DLA Presto算力隔离上线效果

接下来以TPCH做测试,验证租户算力隔离效果。测试场景:

  1. 四台Worker,每台配置是4C8G;
  2. 选用TPCH第20条SQL进行实验,因为它包含5个JOIN个,需要使用大量CPU;
  3. 实验场景:四个租户资源上限相同都为8,其中A、B、C各提交一条SQL,D同时提交5条SQL。

image.png

可以看到社区Presto版本由于租户D提交查询多,相应的Split会更多,因此他能分配更多的资源,这对其他用户是不公平的。而在DLA版本中,由于预先为租户D和其他用户配置了相同的资源上限,因此租户D使用的资源和其他用户也是差不多的。


下图是8条查询的耗时对比:

image.png

可以看到在开源Presto版本里面,所有8条查询耗时几乎一样;而在DLA的版本里面租户A、B、C的查询耗时较短,而租户D由于使用过多资源被惩罚,因此它的5条查询耗时较长。


在DLA的实际生产过程中,为每个用户设置指定的资源上限,并进行比较精准的控制,杜绝了一条或多条查询占用大量的资源,影响其他用户的查询。也不再出现少量查询就把Presto集群搞垮的情况。保证了用户查询时间的稳定性。另一方面,对于那些查询量很大的用户,DLA还提供了独享集群模式,能让查询以更优的性能完成。



五、总结


随着越来越多的企业开始做数据湖分析,数据量的持续增加,数据分析需求也会越来越多,在一个共享的数据湖分析引擎,如何防止多租户之间的查询相互影响是一个很通用的问题,本文以阿里云DLA Presto为例,介绍了一种基于实时惩罚机制实现算力隔离的原理,能有效使共享Presto集群解决多租户之间查询相互影响的问题。



关于我们


DLA致力于帮助客户构建低成本、简单易用、弹性的数据平台,比传统Hadoop至少节约50%的成本。其中DLA Meta支持云上15+种数据数据源(OSS、HDFS、DB、DW)的统一视图,引入多租户、元数据发现,追求边际成本为0,免费提供使用。DLA Lakehouse基于Apache Hudi实现,主要目标是提供高效的湖仓,支持CDC及消息的增量写入,目前这块在加紧产品化中。DLA Serverless Presto是基于Apache PrestoDB研发的,主要是做联邦交互式查询与轻量级ETL。DLA支持Spark主要是为在湖上做大规模的ETL,并支持流计算、机器学习;比传统自建Spark有着300%的性价比提升,从ECS自建Spark或者Hive批处理迁移到DLA Spark可以节约50%的成本。基于DLA的一体化数据处理方案,可以支持BI报表、数据大屏、数据挖掘、机器学习、IOT分析、数据科学等多种业务场景。




欢迎加入数据湖分析DLA技术交流钉钉群进行交流~


image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: