关于存储:10倍性能提升解读DLA-SQL基于Alluxio的数据湖分析加速功能

28次阅读

共计 3938 个字符,预计需要花费 10 分钟才能阅读完成。

简介: 在存储计算拆散的场景下,通过网络从远端存储读取数据是一个代价较大的操作,往往会带来性能的损耗。以 OSS 为例,OSS 数据读取延时通常较本地磁盘大很多,同时 OSS 对单个用户应用的带宽下限做了限度,这都会对数据分析的延时造成影响。在云原生数据湖剖析(DLA)SQL 引擎中,咱们通过引入本地缓存机制,将热数据缓存在本地磁盘,拉近数据和计算的间隔,缩小从远端读取数据带来的延时和 IO 限度,实现更小的查问延时和更高的吞吐。

背景

在数据上云的大背景下,随着网络和存储硬件能力的晋升,存储计算拆散逐步成为了大数据处理的一大趋势。相比于存储和计算耦合的架构,存储计算拆散能够带来许多益处,例如容许独立扩大计算和存储、进步资源的利用率、进步业务的灵活性等等。特地是,借助云上的基础设施,存储能够抉择便宜的对象存储 OSS,计算资源能够按需付费和弹性扩缩容,这些都使得存储计算拆散架构能够很好的施展云计算的老本劣势和灵活性。

然而在存储计算拆散的场景下,通过网络从远端存储读取数据依然是一个代价较大的操作,往往会带来性能的损耗。以 OSS 为例,OSS 数据读取延时通常较本地磁盘大很多,同时 OSS 对单个用户应用的带宽下限做了限度,这都会对数据分析的延时造成影响。在云原生数据湖剖析(DLA)SQL 引擎中,咱们通过引入本地缓存机制,将热数据缓存在本地磁盘,拉近数据和计算的间隔,缩小从远端读取数据带来的延时和 IO 限度,实现更小的查问延时和更高的吞吐。

DLA SQL 引擎基于弹性的 Presto,采取计算与存储齐全拆散的架构,反对对用户存储在 OSS、HDFS 等介质上的各种文件格式进行 Adhoc 查问、BI 剖析、轻量级 ETL 等数据分析工作。此次推出数据湖剖析减速,DLA 与开源大规模数据编排零碎厂商 Alluxio 单干,借助 Alluxio 提供的缓存减速能力,解决存储计算拆散场景下从远端读取数据带来的性能损耗。将来单方将持续在数据湖技术畛域发展全方位单干,为客户提供一站式、高效的数据湖剖析与计算服务。

DLA SQL 数据湖剖析减速计划

基于 Alluxio 的缓存减速原理

架构

在 DLA SQL 引擎中,负责从远端数据源读取数据的角色是 Worker 节点。因而,一个天然的想法就是在 Worker 节点缓存热数据,来实现查问减速的成果。如下图所示:

这里次要的挑战是在大数据量场景上面如何进步缓存的效率,包含:如何疾速定位和读取缓存数据,如何进步缓存命中率,如何疾速从远端加载缓存数据等。为了解决这些问题,在单机层面,咱们应用 Alluxio 来实现对缓存的治理,借助 Alluxio 提供的能力,进步缓存的效率;而在零碎层面,应用 SOFT\_AFFINITY 提交策略在 worker 和数据之间建设对应关系,使得同一段数据(大概率)总是在同一个 worker 下面读取,从而进步缓存的命中率。

SOFT\_AFFINITY 提交策略

Presto 默认的 split 提交策略是 NO\_PREFERENCE,在这种策略上面,次要思考的因素是 worker 的负载,因而某个 split 会被分到哪个 worker 下面很大水平上是随机的。而在缓存的场景外面则须要思考“数据本地化”的因素,如果一个 split 总是被提交到同一个 worker 下面,对进步缓存效率会很有帮忙。
因而,在 DLA SQL 中,咱们应用 SOFT\_AFFINITY 提交策略。在提交 Hive 的 split 时,会通过计算 split 的 hash 值,尽可能将同一个 split 提交到同一个 worker 下面。如下图所示。

应用 \_SOFT_AFFINITY\_策略时,split 的提交策略是这样的:

  1. 通过 split 的 hash 值确定 split 的首选 worker 和备选 worker。
  2. 如果首选 worker 闲暇,则提交到首选 worker。
  3. 如果首选 worker 忙碌,则提交到备选 worker。
  4. 如果备选 worker 也忙碌,则提交到最不忙碌的 worker。

如下图:

这外面,“忙碌”的判断依据如下两个参数来确定:

  • node-scheduler.max-splits-per-node 参数用来管制每个 worker 下面最大能够提交多少个 split,默认是 100。超出这个值则断定这个 worker 忙碌。
  • node-scheduler.max-pending-splits-per-task 用来管制每个 worker 下面最多能够有多少个 split 处于 Pending 状态。超出这个值则断定这个 worker 忙碌。

通过这样的判断,能够兼顾数据本地化和 worker 的负载,防止因为 split 的 hash 不平均造成 worker 之间的负载不均衡,也不会因为某个 worker 特地慢而导致查问整体变慢。

Alluxio 缓存治理

在 Worker 下面,咱们基于 Alluxio Local Cache 来对缓存进行治理。Local Cache 是一个嵌入在 Presto 过程中的库,通过接口调用的形式和 Presto 通信。和应用 Alluxio 集群相比,Local Cache 模式下 Presto 调用 Alluxio 带来的老本更小,同时 Local Cache 具备残缺的缓存治理的性能,包含缓存的加载、淘汰、元数据管理和监控。此外,Alluxio 反对缓存的并发异步写入,反对缓存的并发读取,这些都对进步缓存效率有很好的帮忙。
Alluxio 对外裸露的是一个规范的 HDFS 接口,因而 Cache 的治理对 Presto 是通明的。在这个接口外部,当用户查问须要拜访 OSS 数据源时,如果数据存在于本地缓存中,就会间接从缓存读取数据,减速查问;如果没有命中缓存,就会间接从 OSS 读取数据(并异步写入到本地磁盘)。

DLA 中的进一步优化

进步缓存命中率

为了实现更高的缓存命中率,咱们次要做了两方面的工作:

  • 在老本容许的范畴内尽量调大用于缓存减速的磁盘空间。
  • 进步数据“本地化”的比例。

前者很好了解,这里重点介绍后者。

咱们剖析后面讲的 SOFT\_AFFINITY 提交策略就会发现,如果查问进入“忙碌”的状态,split 就会回退到和 NO\_PREFERENCE 一样的随机提交,这种状况下数据“本地化”的比例必定会升高,因而要害是要尽量避免“忙碌”。然而如果简略调大“忙碌”的阈值,又可能造成 worker 负载不平均,cache 带来的性能晋升被长尾效应吃掉了。
在 DLA 中,咱们是这样做的:

  1. 调大 node-scheduler.max-splits-per-node 的值,使更多的 split 能够命中缓存。
  2. 批改 HiveSplit 的 hash 算法,在计算 hash 值时不仅应用文件名,也应用 split 在文件中的地位,这样就能够防止大文件被 hash 到一个 worker 下面,split 的 hash 值人造就会有比拟平均的散布。

进步磁盘吞吐

除了缓存命中率,进步缓存效率的另一个关键点是缓存的读写速度。在基于磁盘的缓存计划外面,实现这个指标的一个重要局部就是进步磁盘的吞吐性能。
在 DLA 中,咱们应用高效云盘来作为缓存的数据盘。背地的思考是咱们把缓存减速个性作为 CU 版的内置产品能力,不额定收取费用,这就要求缓存引入的老本在 CU 的总成本中占比要足够小,所以咱们不能应用价格昂贵的 SSD 盘。从老本登程,应用高效云盘是必然的抉择,然而这样就须要解决高效云盘单盘吞吐低的问题。
咱们通过应用多块盘并在缓存写入时打散来实现更高的吞吐,这样就补救了云盘吞吐有余的问题。目前 DLA 中的配置,实测单机读写吞吐均可达到靠近 600MB/s,在降低成本的同时依然提供了很好的读写性能。

性能测试

咱们针对社区版本 prestodb 和 DLA 做了性能比照测试。社区版本咱们抉择了 prestodb 0.228 版本,并通过复制 jar 包以及批改配置的形式减少对 oss 数据源的反对。咱们别离对 DLA-SQL CU 版 256 核 1024GB、512 核 2048GB、768 核 3072GB 三种规格与等同算力的社区版本集群进行了比照。

测试的查问咱们抉择 TPC-H 1TB 数据测试集。因为 TPC- H 的大部分查问并不是 IO 密集型的,所以咱们只从中挑选出合乎如下两个规范的查问来做比拟:

  1. 查问中蕴含了对最大的表 lineitem 的扫描,这样扫描的数据量足够大,IO 有可能成为瓶颈。
  2. 查问中不波及多个表的 join 操作,这样就不会有大数据量参加计算,因此计算不会先于 IO 而成为瓶颈。

依照这两个规范,咱们抉择了对 lineitem 单个表进行查问的 Q1 和 Q6,以及 lineitem 和另一个表进行 join 操作的 Q4、Q12、Q14、Q15、Q17、Q19 和 Q20。

测试后果如下:


如何应用

目前缓存个性只在 CU 版提供,新购买的集群主动开明对 oss、hdfs 数据源的缓存能力。已有集群能够分割咱们降级到最新版本。对于 CU 的开明和应用能够参考咱们的帮忙文档。
咱们当初还有一元 1000CU 时的优惠套餐,欢送试用。点击购买套餐

总结与瞻望

缓存减速个性通过将热数据缓存在本地磁盘,提供更小的查问延时和更高的吞吐,对 IO 密集的查问有很好的减速成果。在云上广泛计算和存储拆散的场景中,缓存肯定还具备更广大的利用场景。将来咱们会进一步摸索缓存在 Maxcompute 等其余数据源和场景的应用,为更多类型的数据读取和计算做减速,提供更好的查问性能。

用户福利

当初流动期间,用户 1 元首购原价 315 元的 DLA 1000CU 时资源包,点击购买套餐
欢送大家关注咱们的钉钉群获取最新的信息:

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

正文完
 0