Apache Hadoop 3.1.0
2018年4月6日，Apache Hadoop 3.1.0 正式发布并原生支持GPU和FPGA。这个版本并不推荐在生产环境下使用，如果需要在正式环境下使用，请等待 3.1.1 或 3.1.2 版本。现在Hadoop已经发布到3.2.2。
- YARN 原生支持 GPU（详见 YARN-6223）
- YARN 原生支持 FPGA（详见 YARN-5983）
- 支持 docker container
Spark 3.0
YARN先行支持GPU可以说是兵马未动粮草先行。Spark 3.0 （2020年6月发布）开始支持了数据的列式处理，同时能够将 GPU 作为资源进行调度。在此基础上，Nvidia/Spark-Rapids 开源项目基于 Rapids 库, 以 plugin 的方式提供了一组 GPU 上实现的 ETL 处理，利用 GPU 强大的并发能力加速 Join , Sort , Aggregate 等常见的 ETL 操作。
RAPIDS 全称是Real-time Acceleration Platform for Integrated Data Science，是 NVIDIA 针对数据科学和机器学习推出的 GPU 加速库，更多信息请参见官网https://rapids.ai/。
英伟达提供 GPU 加速的Apache Spark,使用已有的代码，无需修改，GPU不支持的功能可以无缝地跑在CPU上。目前支持GPU加速的负载：
- Spark Data Frames
- Spark SQL
-
ML/DL training frameworks
使用 RAPIDS 加速 Apache Spark 3.0
加速原理
- 判断是否开启了GPU调度，如果开启就调用Rapids执行GPU处理。
- 自定义的Shuffle实现，使用RDMA和gpu-to-gpu直连来优化。
- 使用JNI来绑定到C++实现，底层是Rapids库和UCX库以及CUDA。
- 将CPU物理计划改编为GPU物理执行计划。
使用 UCF Consortium 的开源 UCX（Unified Communication X）框架,UCX库是抽象的通信接口，选择最佳的路径，如TCP、RDMA、共享内存或GPU。
适合 GPU 加速的场合
高散列度数据的 joins
高散列度数据的 aggregates
高散列度数据的 sort
Window operations (特别是大型 windows)
复杂计算
数据编码（创建 Parquet 和 ORC 文件 读取 CSV)
不适合数据规模小的计算，不适合高缓存一致性的操作，不是缓慢I/O如网络、磁盘等，不适合UDF等与CPU的不断交互，也不支持RDD应用，对shuffle操作支持不好。
数据规模特别的小，整个的数据的size可能会特别小，具体到每个partition的话，如果设的partition数也是比较多，其实可能partition的数据大小只有几百兆，不一定适合跑在GPU上。第二种场景就是说高缓存一致性的操作，这一类的操作如果在你的公司的业务的query里头包含的比例非常高的话，也不一定是GPU是十分合适的。第三类就是说包含特别多的数据移动，比如说我的整个的这些query有各种各样的shuffle，shuffle的比例非常的多，可能我的整个的操作是bound在IO层面，可能有网络、也可能有磁盘。还有一种可能就是UDFs目前的实现可能会经常串到CPU，就是说还是会牵扯到CPU与GPU之间，可能会产生不断的一些数据的搬运。在这种情况下，就是数据移动特别多的情况下，GPU也不一定是很合适的。最后一种场景就是说我的GPU的内存十分有限，主流的英伟达GPU的显存也都是看具体型号，最新的A100也都能支持到80G，但是可能对于特定的场景来说，可能内存还有可能不够，如果是这种比较极端的情况下，也有可能说处理不了，也有可能说在GPU上的加速效果并不一定是十分的明显。
其他技术-加速 GPU 处理
小文件读取时，采用多线程并行以及合并 ( coalesce ）
GPU 内存不够时， spill 到 Host 内存和磁盘
采用最新的 Gpu Direct Storage 技术，加快 GPU 内存到磁盘 NVMe 的 I/O
GPU可基于RDMA可实现零拷贝，但RDMA需要网卡支持才可以用。
数据：实测不同的负载可加速50%~2倍，最高的46倍。
价值观察
新开源RAPIDS加速器现在可以加速ETL（提取、转换、加载）和数据传输，在无需更改任何代码的情况下提高端到端分析性能。Spark性能的加速不仅意味着能够更快获得洞察，而且由于企业可以使用更少的基础设施来完成工作负载，因此还可以帮助企业降低成本。
GPU并行处理使计算机可以一次执行多项操作。随着运用AI和机器学习工具的企业机构日益增加，并行处理已成为加速海量数据分析和ETL管道，进而驱动这些工作负载的关键。
用于Apache Spark的全新RAPIDS加速器将Spark分布式计算框架与功能强大的RAPIDS cuDF库相连接，实现了GPU对Spark DataFrame和Spark SQL的运行提速。RAPIDS加速器还通过搜索在Spark节点之间移动数据的最快路径来加快Spark Shuffle的运行速度。
电信行业解决方案与实践
去年12月17日，中国电信发布白皮书《英伟达GPU加速中国电信Spark数据处理》。其建有统一的大数据处理平台。大数据平台包含数据接入、数据处理、数据输出、数据监测四个主要组成部分。如下图所示：
发布的测试结果显示
三台服务器，在404GB的模拟数据上，执行SQL数据查询操作(SQL算子主要包含sum、partition、max、left join、group by等运算)，CPU上的执行时间为11.33分钟，GPU为2.03分钟。CPU花费的时间为GPU的5.58倍。一台GPU服务器的处理能力相当于5台以上的CPU服务器。
Spark和Deep Learning框架结合
工业界一般针对大数据处理的需求，会去维护一套分布式的Spark集群；同时对深度学习的需求，同样会有单独的深度学习集群。两个集群间相互独立，只是有数据和模型的交互。如下图：
存在的问题是：1）集群交互会有比较大的延迟。2）还需要部署两套环境。所以目前有将Spark和Deep Learning 框架结合的解决方案，旨在打造统一的BigData+AI的平台。例如：Yahooh TensorflowOnSpark、Intel Analytics-Zoo，都是这种出发点。
Spark 3.0开始，通过Plugin的方式可以修改SparkSQL，DataFrame的后端执行引擎，因此NVIDIA开发出一套Spark-RAPIDS的Plugin，支持用户在GPU做大数据处理，构建全GPU的闭环处理流。对Spark而言无疑是利好的，增强了Spark对GPU的使用能力，当然具体效果如何，还是需要在业务实践中检验。
RAPIDS的推出其实是为了弥补GPU在大数据处理以及传统机器学习上的缺口，也反应出NVIDIA想要打通数据处理和深度学习模型（的梦想），构成统一的从raw data到result的pipeline全部都在GPU上运行的闭环。
参考文档：
Apache Hadoop 3.1.0 正式发布，原生支持GPU和FPGA
在 Spark 3.0 上实现 GPU 加速 ETL
GTC20 | 白皮书发布：NVIDIA GPU加速中国电信Spark数据处理
