越来越多的数据处理应用NVIDIA 计算来实现大规模并行。减速计算的倒退意味着无论是在剖析、人工智能 (AI) 还是机器学习 (ML) 过程中，对存储的拜访也须要更快。
如果数据拜访很大水平影响执行工夫，那么GPU减速带来的益处将是无限的。基于GPU的解决与基于CPU 的集群相比，能够驱动更高的数据拜访吞吐量。随着用于剖析和人工智能的解决集群与数据存储系统的拆散，减速数据拜访将变得更加重要。
NVIDIA曾经和Alluxio社区发展单干，对大规模数据集缓存和GPU数据可用性进行高性能数据编排零碎测试。Apache Spark 3.0，RAPIDS Accelerator for Apache Spark和 Alluxio 可用于：(1) 数据分析和商业智能；(2) 数据迷信的数据预处理和特色工程。对于模型训练或推理，GPU 集群上的Spark 和分布式 TensorFlow 或PyTorch 都受害于应用分布式平台无关（distributed platform agnostic）的编排层所带来的 I/O 减速。
在本文中，咱们将探讨：
在数据工作流的各个阶段，包含从数据提取-转换-加载(ETL) 到剖析和人工智能/机器学习（AI/ML）阶段应用Alluxio数据编排平台的部署架构。
如何通过用于RAPIDS Accelerator for Apache Spark和Alluxio在无需批改任何代码的状况下减速Spark SQL/Dataframe。
应用Alluxio和RAPIDS Accelerator for Apache Spark的最佳实际。
GPU减速的Apache Spark，TensorFlow 或PyTorch在应用 Alluxio时的部署选项。
典型的剖析、机器学习或人工智能工作流是蕴含数据导入到数据筹备，再到剖析或人工智能的一系列步骤。为模型训练筹备数据波及数据预处理和特色工程，咱们将其称为 ETL（提取-转换-加载）。剖析工作流中的数据清理须要采纳相似的步骤。
数据分析和ETL多应用Spark SQL和Dataframe API，二者通常都是迭代程序。随着GPU 和大型数据集的应用越来越多，对数据源的间接解决将得益于分布式缓存起到的I/O减速作用。
Alluxio数据编排层可用作数据流多个步骤共享的多数据源分布式缓存。Alluxio不受平台影响，提供了与平台的解耦，无论平台是部署在本地还是云上托管的 Hadoop 或 Kubernetes上。如图 1 所示，该架构通常实用于多种环境，能够依据以后阶段和工作负载类型灵便抉择最适宜的数据处理技术和基础架构。
图 1：在NVIDIA GPU 集群上部署多阶段剖析或AI工作流用于计算减速并部署Alluxio用于减速数据拜访。
应用 RAPIDS Accelerator for Apache Spark的Apache Spark 3.0 可能在GPU减速的集群上对Spark SQL 或 DataFrame 作业进行并行计算。然而，此类作业的很大一部分是从近程数据源读取数据。如果数据访问速度迟缓，I/O 可能会影响端到端的应用程序执行工夫。
应用Spark SQL和DataFrames的解决作业能够在NVIDIA GPU上运行，无需批改任何代码，且解决作业也得益于Apache Spark的RAPIDS 加速器中蕴含的优化。同样，如果应用 Alluxio 作为 Spark 应用程序的数据源，在不批改代码的状况下，就能够从部署数据编排层所带来的 I/O 减速中获益。图2显示了可用于GPU反对实例的举荐软件堆栈，在这里Alluxio利用CPU 和本地存储介质（如 NVMe）来治理缓存数据，而Spark利用GPU资源进行计算。
图 2. NVIDIA GPU 上的 Apache Spark 用于基于 SQL 的剖析或用于ETL进行数据处理。
应用RAPIDS Accelerator for Apache Spark和Alluxio时无需批改应用程序。下文探讨了用户最后可能遇到的两种场景。
场景1：对于应用Alluxio架构读取数据的现有用户，在应用RAPIDS Accelerator for Apache Spark时无需进行任何批改。能够像以前一样将数据加载到 Spark DataFrame 中，无需批改代码。
val df = spark.read.parquet("alluxio://ALLUXIO_MASTER_IP:PORT/foo")
MASTER_IP:PORT/foo")
场景2：对于正在应用 Spark 应用程序但想要首次部署Alluxio和RAPIDS加速器的用户，将应用Spark配置参数把现有存储门路映射到Alluxio门路。
用户应应用RAPIDS Spark配置参数来配置此映射，如下所示：
--conf spark.rapids.alluxio.pathsToReplace="gs://foo->alluxio://ALLUXIO_MASTER_IP:PORT/foo"
应用配置参数集后，替换后的门路无需批改应用程序。例如，下述加载的Spark DataFrame 将依照门路 alluxio://ALLUXIO_MASTER_IP:PORT/foo 从Alluxio读取数据。
val df = spark.read.parquet("gs://foo")
此示例假如Bucket foo挂载在Alluxio FileSystem命名空间中的 /foo 地位。
本节对高性能数据编排零碎（应用 RAPIDS Accelerator for Apache Spark和 Alluxio）对于大型数据集的缓存和用于GPU解决的数据可用性的影响进行评估。咱们应用了近 90 个 NVIDIA 决策反对 (NDS) 查问以及来自支流数据分析基准套件的相应数据集。这些基准查问运行3 TB 数据集, 该数据集以Parquet 格局存储在 Google Cloud Storage bucket中。
下图显示，在将90个NDS查问的总运行工夫进行比拟后发现，部署 Alluxio的NVIDIA GPU集群的性能进步了近 2 倍，与CPU集群相比，投资回报率（ROI）进步了70%。Google Cloud Dataproc 用于在CPU和GPU 集群的计算实例上部署服务。应用的实例配置见下图。
这些晋升大多归功于Alluxio对于大型数据集的缓存能力，因而能够防止反复拜访云存储。数据处理能力的加强使得数据科学家在整个数据迷信生命周期中执行多项工作（例如数据导入、数据筹备和数据摸索）时都可获益，从而进步性能并降低成本。
图 3：CPU 硬件配置：Master：n1-standard-4，Slave：4 x n1-standard-32（128 核，480GB RAM），GPU 硬件配置：Master：n1-standard-4，Slave：4 x n1- standard-32（128 核，480GB RAM + 16 x T4），CPU 云老本：7.82 美元/小时（基于 4 x n1-standard-32 的规范定价 + Dataproc 定价），GPU 云老本：13.41 美元/小时（基于 4 x n1-standard-32 + 16 xT4 的规范定价+ DataProc 定价）
Alluxio和 RAPIDS Accelerator for Apache Spark在默认配置下就能实现显著的性能改良，进行额定调优可进一步提高ROI。本节提供了此类举荐列表。
- 将Alluxio工作节点与Spark工作节点部署在一起（co-locate）
Co-location使得应用程序可能对本地Alluxio worker执行短路读取和写入，比从Alluxio worker近程获取数据更高效。 - 依据工作集大小配置缓存
为 Alluxio 调配足够的空间来缓存工作集至关重要。实际上，咱们倡议为频繁拜访的数据的多个正本提供足够的缓存空间，以缩小单个worker 的过载。正本数可通过不同配置参数进行管制。 - 抉择正确的缓存介质
用户能够抉择内存和/或固态硬盘作为Alluxio worker的缓存介质。除非数据小到能够放入内存，并且每次查问所需的数据很小，否则宜部署更经济的固态硬盘作为缓存层，从而显著升高集群老本和总领有老本（TCO）。
4.在 RAPIDS Spark 中进行并发配置
Spark中工作执行的并发性由每个executor的工作数管制。如果应用 Spark RAPIDS，那么将会有一个名为 spark.rapids.sql.concurrentGpuTasks的附加参数, 来进一步管制 GPU 工作并发，从而防止内存不足（OOM）异样。
将该值设置为2到4之间时，一些查问可实现显著性能晋升，值设为2时通常性能晋升最大，而随着值升高性能效益递加。一般来说Executor中有多个工作时对资源的应用会更优化。例如，有4个工作（蕴含两个concurrentGpuTask），来均衡对I/O和CPU的应用。比方一个工作可能正在与分布式文件系统通信以读取输出缓存，而另一个工作正在对GPU 上的输出缓存进行解码。在 executor 上配置过多的工作可能会导致过多的 I/O 和主机内存过载。一般来说，executor中的工作数量如果是并发concurrentGpuTasks数量的两倍时，是一个较好的起始配置。
- 将CPU内存固定到GPU内存
设置 spark.rapids.memory.pinnedPool.size 可显著进步 GPU 和主机内存之间的数据传输性能，因为传输能够通过CPU 异步执行。在现实状况下，调配的固定内存（pinned memory）的输出分区足够包容Spark能为executor调度的并发工作数量。 - 限度shuffle分区的数量
分区对于 GPU 解决的增量老本高于CPU解决，因而倡议在不耗尽工作内存的状况下尽可能减少分区数量。
无关Alluxio，请查阅Alluxio tuning tips document 获取更多信息。无关RAPIDS Spark，请查阅 RAPIDS Spark tuning guide获取更多信息。
用户能够在任何云基础架构即服务 (IaaS) 产品（例如 Amazon EC2、Azure VM 或 Google Compute Engine）上部署装有NVIDIA GPU 和 Alluxio的Apache Spark集群。其余选项包含任何容器云平台 (CaaS) 产品，例如 Amazon EKS、Azure Kubernetes Service 或 Google Kubernetes Engine。
Apache Spark的RAPIDS加速器和Alluxio都能够与次要云数据托管服务进行集成。以下指南实用于Amazon EMR, Google Dataproc，并蕴含Alluxio应用阐明。
下一步：
想要理解更多无关RAPIDS 如何减速 Apache Spark 的 I/O 的信息，请注册GTC 2021大会演讲——“将RAPIDS加速器用于数据编排”。
想理解如何开始应用Alluxio和RAPIDS Accelerator for Apache Spark，请查阅此文档: https://nvidia.github.io/spar...
想获取RAPIDS Accelerator for Apache Spark 3.0相干信息和入门指南，请查阅GitHub repo：https://github.com/nvidia/spa...
无关如何在Kubernetes 中应用Alluxio减速基于GPU的深度学习I/O的更多信息，请浏览开发者博客: https://www.alluxio.io/blog/e...