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

一、背景介绍

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

注 *左右滑动阅览

一个查询会被解析为包含多个Stage的物理执行计划 每个Stage包含若干Task Task会被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核数上限为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。

上图以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。如下图所示

与社区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各提交一条SQL D同时提交5条SQL。

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

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

可以看到在开源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技术交流钉钉群进行交流~

本文转自网络，原文链接：https://developer.aliyun.com/article/783953
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！