简介：在存储计算拆散的场景下，通过网络从远端存储读取数据是一个代价较大的操作，往往会带来性能的损耗。以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的提交策略是这样的：

通过split的hash值确定split的首选worker和备选worker。
如果首选worker闲暇，则提交到首选worker。
如果首选worker忙碌，则提交到备选worker。
如果备选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中，咱们是这样做的：

调大node-scheduler.max-splits-per-node的值，使更多的split能够命中缓存。
批改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密集型的，所以咱们只从中挑选出合乎如下两个规范的查问来做比拟：

查问中蕴含了对最大的表lineitem的扫描，这样扫描的数据量足够大，IO有可能成为瓶颈。
查问中不波及多个表的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时资源包，点击购买套餐
欢送大家关注咱们的钉钉群获取最新的信息:

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