用于ETL的GPU？ 优化Apache Spark SQL操作的ETL架构
使用NVIDIA RAPIDS加速器进行大规模数据上运行的Apache Spark的ETL（抽取-转换-加载）操作可以实现成本节省和性能提升。我们在以前的文章中进行了演示，"ETL用于GPU？使用NVIDIA RAPIDS加速器为Apache Spark和Databricks运行更快、成本更低的工作负载"。在本文中，我们深入探讨了为给定的处理架构加速哪些Apache Spark SQL操作。
1、将ETL迁移到GPU
是否应将所有ETL迁移到GPU？还是有必要评估哪种处理架构最适合特定的Spark SQL操作？
CPU经过优化，适用于顺序处理，具有较少但更快的个体核心。在内存管理、处理I/O操作、运行操作系统等方面，CPU在计算上具有明显的优势。
GPU经过优化，适用于并行处理，具有更多但速度较慢的核心。GPU在图形渲染、训练机器学习和深度学习模型、执行矩阵计算以及其他受益于并行化的操作方面表现出色。
2、实验设计
我们创建了三个大型、复杂的数据集，模拟了真实客户零售销售数据，使用了计算成本较高的ETL操作：
聚合（SUM + GROUP BY）
CROSS JOIN
UNION
每个数据集都专门策划，以测试特定Spark SQL操作的极限和价值。这三个数据集都是基于全球零售商的交易销售数据集建模的。行大小、列数和类型的选择是为了在执行测试时平衡实验处理成本，以展示和评估在特定操作条件下CPU和GPU架构的优势。请参见表1以获取数据概况。
表1. 实验数据集摘要
本实验评估了以下计算配置：
工作节点和驱动节点类型
工作节点的最小和最大数量
RAPIDS或Photon部署
Databricks单位（DBUs）的最大每小时限制 — 这是Databricks计算成本的专有度量。
表2. 实验计算配置
2.1 其他实验考虑因素
除了构建代表行业的测试数据集外，以下是其他实验因素：
数据集是在按需实例上运行的，使用了多种不同的工作节点和驱动节点配置，而不是抢占式实例，因为它们的固有可用性确保了实验中的定价一致性。
对于GPU测试，我们利用了专为分析密集型负载优化的T4 GPU上的RAPIDS加速器，并具有较低的每个DBU成本。
CPU工作节点类型采用内存优化架构，使用英特尔Xeon Platinum 8370C（Ice Lake）CPU。
我们还利用了Databricks Photon，这是一种本机的CPU加速器解决方案，是他们传统的Java运行时的加速版本，重写为C++。
这些参数被选择以确保实验的可重复性和适用性于常见的用例。
2.2 结果
为了以一致的方式评估实验结果，我们开发了一个名为“每分钟调整的DBU（ADBUs）”的复合指标。ADBUs基于DBUs计算。
实验结果表明，在没有一个芯片组（GPU或CPU）在计算Spark SQL任务中占主导地位的情况下。如图1所示，数据集特征和集群配置的适用性对于选择用于特定任务的框架影响最大。尽管这并不令人意外，但问题仍然存在：哪些ETL流程应该迁移到GPU？
图1. 平均计算时间和平均成本比较
3、UNION操作
尽管在UNION操作中，T4 GPU上的RAPIDS加速器产生了成本更低和执行时间更短的结果，但与CPU相比，差异可以忽略不计。将现有的CPU到GPU的ETL流水线移植对于这种数据集和Spark SQL操作的组合似乎是不合理的。尽管本研究未经测试，但可能（尚未经本研究测试）较大的数据集可能产生需要迁移到GPU的结果。
4、CROSS JOIN操作
对于计算密集型的CROSS JOIN操作，我们观察到使用RAPIDS加速器（GPU）比使用Photon（CPU）节省了一个数量级的时间和成本。
这些性能提升的一个可能解释是CROSS JOIN是一个包括未结构化数据列与自身相乘的笛卡尔积，导致复杂度呈指数增长。GPU的性能提升非常适合这种大规模可并行化的操作。
成本差异的主要驱动因素是我们进行实验的CPU集群的DBU评级远高于选择的GPU集群。
5、SUM + GROUP BY操作
对于聚合操作（SUM + GROUP BY），我们观察到了不同的结果。Photon（CPU）提供了明显更快的计算时间，而RAPIDS加速器（GPU）提供了更低的总成本。从单独的实验运行来看，我们观察到Photon的较高成本导致更高的DBU，而与T4相关的成本明显更低。
这解释了在实验的这个部分中使用RAPIDS加速器的更低总成本。总之，如果速度是目标，Photon是明显的赢家。更注重价格的用户可能会更喜欢RAPIDS加速器的较长计算时间，以实现显著的成本节省。
6、选择使用哪种架构
在通常使用的聚合（SUM + GROUP BY）实验中，CPU集群在执行时间上获得了性能提升。然而，这是以更高的关联集群成本为代价的。对于交叉连接（CROSS JOIN）来说，这是一种不太常见但计算密集且高度可并行化的操作，GPU在速度和成本方面都占据主导地位。联合（UNION）在计算时间和成本上显示出可忽略的比较差异。
GPU（以及与之相关的RAPIDS加速器）的优越性很大程度上取决于数据结构、数据规模、执行的ETL操作以及用户的技术深度。
6.1 ETL中的GPU
总的来说，GPU非常适用于大型、复杂的数据集以及高度可并行化的Spark SQL操作。实验结果表明，在交叉连接（CROSS JOIN）情况下使用GPU是明智的，因为它们适合并行化，并且随着数据的增长，可以轻松扩展大小和复杂度。
值得注意的是，数据规模并不像数据的复杂性和所选操作那样重要，就像在SUM + GROUP BY实验中所示的那样。（这个实验涉及到更多的数据，但与交叉连接相比，计算复杂度较低。）您可以与NVIDIA免费合作，通过分析Spark日志文件来估算预期的GPU加速增益。
6.2 ETL中的CPU
根据实验结果，某些Spark SQL操作，如联合（UNION），在成本和计算时间上显示出可忽略的差异。在这种情况下，转向GPU可能并不合理。此外，对于聚合（SUM + GROUP BY），可以根据情景需求有意选择速度高于成本，其中CPU将执行更快，但成本更高。
在内存计算直接的情况下，保持已建立的CPU ETL架构可能是理想的选择。
7、讨论和未来考虑
本实验探讨了一步骤的Spark SQL操作。例如，一个单一的交叉连接或单一的联合，省略了涉及多个步骤的更复杂的ETL作业。一个有趣的未来实验可能包括在粒度级别优化ETL处理，将单独的SparkSQL操作发送到CPU或GPU中的单个作业或脚本，并优化时间和计算成本。
精明的Spark用户可能会尝试专注于实施脚本策略，以充分利用默认运行时，而不是实施更高效的范式。例如：
Spark SQL连接策略（广播连接、洗牌合并、哈希连接等）
高性能数据结构（将数据存储在与文本文件相比在云架构中性能更高的Parquet文件中）为重复使用而进行战略性的数据缓存
我们的实验结果表明，利用GPU进行ETL可以提供足够的性能，值得付出实施GPU架构的努力。
尽管受到支持，但Apache Spark的RAPIDS加速器在Azure Databricks上默认情况下不可用。这需要安装可能需要一些调试的.jar文件。随着对RAPIDS加速器的后续使用变得更加无缝和简单，这种技术债务在很大程度上已得到偿还。如果有必要，NVIDIA的支持始终可以提供帮助。
最后，我们选择保持所有创建的集群每小时不超过100 DBU，以管理实验成本。我们只尝试了一个大小的Photon集群。通过改变集群大小、工作节点数量和其他实验参数，实验结果可能会发生变化。我们认为这些结果对于在运行ETL作业的组织中的许多典型用例来说是足够健壮和相关的。
8、结论
专为分析工作负载设计的NVIDIA T4 GPU，在利用基于GPU的计算方面取得了性价比方面的巨大突破。特别是在NVIDIA T4 GPU上运行时，NVIDIA RAPIDS加速器对于某些常见的ETL SparkSQL操作，尤其是那些高度可并行化的操作，具有显著降低成本和执行时间的潜力。
要在您自己的Apache Spark工作负载中实施此解决方案而无需更改代码，请访问NVIDIA/spark-rapids-examples GitHub存储库或Apache Spark工具页面，获取演示了在数据处理或机器学习流程中使用RAPIDS加速器的性能和好处的示例代码和应用程序。