腾讯云基于Alluxio优化计算存储分离架构的最佳实践

|导语  随着企业大数据规模和应用的增长和发展，计算与存储分离的架构渐渐成为主流，它解决了计算量和存储量不匹配问题， 实现了算力的按需使用，但也引来了一些新的问题。腾讯云EMR团队与Alluxio社区合作，探索出了开箱即用的计算存储分离优化版本，大幅优化网络带宽，带宽削峰20%-50%，节省总带宽10%-50%，同时能在IO密集型场景提升性能5%-40%，下面就让我们来一探究竟。

一、当前大数据挑战    

近年来，随着大数据规模的增长，以及大数据应用的发展，大数据技术的架构也在持续演进。早期的技术架构是计算资源和存储资源高度融合，计算和存储资源一体化存在以下明显的挑战：

1. 数据孤岛

如今，企业拥有PB级数据已经成为常态，EB级数据时代也将很快到来。企业需要面向结构化数据、非结构化数据、实时数据等多种类型的数据提供高扩展且统一的数据管理和数据存储能力。

2. 刚性扩容

在数据空间持续增长的背景下，大数据应用场景不断增加，对企业算力的需求也在加剧提升。而同时，新品发布、热点事件等带来的业务浪涌，也需要企业大数据系统拥有极致的弹性能力。

3. 利用率低

大数据行业技术栈迭代迅速，企业自行构建IDC中心和自行部署软件，一次性投资大，且折旧成本高，运营运维负担沉重。

4. 作业拥塞

随着业务的发展，在数据量巨大的背景下，单次分析作业常需要读取TB-PB级的数据，多任务并发下，极易出现作业拥塞。

面对以上挑战，传统的以私有数据中心为基础的存算一体大数据架构，已无法满足企业海量数据分析的需求。业界知名分析机构IDC在最新的报告中明确指出：企业上云已成必然趋势。因此，在公有云上部署更灵活高效的大数据分析平台，将成为企业的必然选择。

二、腾讯云弹性MapReduce(EMR)

目前越来越多的企业开始选择使用计算和存储分离的架构，以应对更低成本的要求，和兼顾资源扩展的灵活性。

传统计算存储一体架构

计算存储分离架构

目前腾讯云弹性MapReduce(EMR)支持了三种存储系统：EMR-HDFS、EMR-COS、EMR-CHDFS，其中EMR-COS和EMR-CHDFS在EMR中都是开箱即用的原生支持计算存储分离的方案，其具体应用场景及特点如下：

元数据操作效率高，能够与HDFS相当，能够有效规避COS文件系统元数据操作耗时以及高频访问下可能引发不稳定的问题。但在实际使用场景中，因为可能存在多个数据存储源管理复杂，部分业务场景对数据源的IO访问密集造成网络压力大，访问不稳定等问题。所以我们基于Alluxio进一步优化计算和存储架构，更好的满足业务应用上的需求。

三、基于Alluxio优化计算存储分离架构

传统计算存储分离，解决了计算量和存储量不匹配问题， 实现了算力的按需使用，大幅节省了运维规划时间以及闲置的算力成本。但直接使用计算存储分离架构，也引入了新的问题：

• 在IO密集型的场景下，网络带宽会成为瓶颈, 可能导致计算 & 存储资源利用不充分；
• 数据本地化不够，导致很多shuffle过程的重复计算，造成部分浪费计算资源的浪费；
• 可能存在多种甚至异构的存储源，增加了管理难度。

为此，腾讯云EMR团队与Alluxio社区合作，引入最新alluxio2.3.0 Release版本进行深度优化，推出开箱即用的计算存储分离优化版本：EMR2.5.0/EMR3.1.0/EMR-TianQiong-1.0，解决上述问题。

1. 提供内存级 I/O能力

Alluxio能够用作分布式共享缓存服务，这样与Alluxio通信的计算应用程序可以透明地缓存频繁访问的数据（尤其是从远程位置），以提供内存级 I/O 吞吐率。此外，Alluxio的层次化存储机制能够充分利用内存、固态硬盘或者磁盘，降低具有弹性扩张特性的数据驱动型应用的成本开销。

2. 提高数据本地性

利用Alluxio提供的分布式缓存服务，在部署Alluxio数据节点(Alluxio-Worker)时和计算节点部署在一起，可以直接从数据节点中以内存级IO速度检索读取数据，而不是从底层云存储或对象存储中检索读取，提高了数据本地性。

3. 简化云存储和对象存储接入

与传统文件系统相比，云存储系统和对象存储系统使用不同的语义，这些语义对性能的影响也不同于传统文件系统。在云存储和对象存储系统上进行常见的文件系统操作（如列出目录和重命名）通常会导致显著的性能开销。当访问云存储中的数据时，应用程序没有节点级数据本地性或跨应用程序缓存。

4. 简化数据管理

Alluxio 提供对多数据源的单点访问。除了连接不同类型的数据源之外，Alluxio还允许用户同时连接同一存储系统的不同版本，如多个版本的HDFS以及云上COS/CHDFS，只需基于EMR配套的简单配置下发和管理管理功能。

在引入Alluxio后，EMR基于Alluxio的存算分离的整体架构变成了：

这样，EMR的计算引擎(Spark，MapReduce，Presto等)就可以统一通过Alluxio来提升性能，降低网络峰值带宽，以及简化数据管理。

四、性能评估及调优

为了分析理解使用Alluxio存储在主流查询引擎Spark性能上差异，我们使用大数据压测工具TPC-DS进行了一些性能压测。我们使用的环境及配置如下：

• EMR版本：EMR-2.5.0；
• 选择组件：zookeeper-3.6.1,hadoop-2.8.5,hive-2.3.7,spark_hadoop2.8-3.0.0,tez-0.9.2,alluxio-2.3.0,knox-1.2.0；
• 压测配置，使用了1个EMR的Master节点和25个CORE节点，具体如下：

1. 带宽评估

从压测结果可以看到，能大幅优化计算存储分离网络带宽，节省峰值带宽(削峰)20%-50%，节省总带宽(10%-50%)。

2. 查询性能评估

从压测结果可以看到,在大部分场景下能优化性能，特别是IO密集型，优化性能5%-40%。

3. 性能调优及专项优化

为了更好满足计算存储分离场景，EMR团队针对Alluxio做了专项调优，具体包括：

（1）数据本地性

为了更好满足数据本地，EMR在部署Alluxio时，在core节点把alluxio-worker同计算节点部署在一起，这样yarn等计算服务节点可以在同一个节点中与alluxio-worker节点通信，大量提升了效率。

另一方面，结合alluxio已经提供的读写策略，结合存算分离场景优化了block.read.location.policy，writetype.default等策略，让alluxio的缓存能力更好满足本地性。

（2）元数据优化

Alluxio基于Presto实现了Catalog Service，并且实现了计算框架端的Connector，Alluxio可以感知并管理结构化数据的元数据，大大简化表级别的使用成本。同时，腾讯内部在大规模使用Alluxio时，我们发现Alluxio本身的inode元数据也面临着膨胀的风险。为此结合Alluxio提供的Catalog Service和Path缓存能力，优化了path.caching.thread和path.cache.capacity等策略。

更多meta具体优化可参考，社区meta优化及catalog介绍。

（3）Java GC的影响

Alluxio作为Java的进程，其GC的经常影响其性能表现，为此，EMR团队引入了 Tencent Kona，经过了内部大数据和AI等业务场景的验证，为JAVA生态提供专业持续的保障。Kona在GC线程调度优化，物理内存释放优化等方面有优秀表现，更多功能特性可见：Kona JDK。

上述的这些能力和优化，在存算分离场景下，腾讯云EMR产品针对这种场景都已经直接提供了开箱即用的能力，直接在腾讯云EMR产品购买页创建，或者在已有支持了alluxio的EMR版本上安装，即可达到性能评估中效果。

五、总结

从上述的压测结果看到，一方面有效的降低了带宽峰值和总带宽，从而降低带宽成本，加速访问；另一方面，IO密集型场景下的性能也有不少提升，能更好的支持IO密集型场景下的业务。此次基于Alluxio的优化，让腾讯云弹性MapReduce(EMR)产品更好的支持存储计算分离架构，为用户更好的满足业务需求的同时，降低成本，且保持资源扩展的灵活性。

近期热文

【To B管理端】图表设计指南

QQ浏览器大盘指标体系搭建与拆解

【前端技术】react渲染 - 流程概述

让我知道你在看