Apache Spark 3.0 预览版正式发布，多项重大功能发布

2019年11月08日 数砖的 Xingbo Jiang 大佬给社区发了一封邮件，宣布 Apache Spark 3.0 预览版正式发布，这个版本主要是为了对即将发布的 Apache Spark 3.0 版本进行大规模社区测试。不管是从 API 仍是从功能上来讲，这个预览版都不是一个稳定的版本，它的主要目的是为了让社区提早尝试 Apache Spark 3.0 的新特性。若是你们想测试这个版本，能够到 这里 下载。 Apache Spark 3.0 增长了不少使人兴奋的新特性，包括动态分区修剪（Dynamic Partition Pruning）、自适应查询执行（Adaptive Query Execution）、加速器感知调度（Accelerator-aware Scheduling）、支持 Catalog 的数据源API（Data Source API with Catalog Supports）、SparkR 中的向量化（Vectorization in SparkR）、支持 Hadoop 3/JDK 11/Scala 2.12 等等。Spark 3.0.0-preview 中主要特性和变化的完整列表请参阅这里。下面我将带领你们解析一些比较重要的新特性。 PS：仔细观察的同窗能够看出，Spark 3.0 好像没多少 Streaming/Structed Streaming 相关的 ISSUE，这可能有几个缘由： - 目前基于 Batch 模式的 Spark Streaming/Structed Streaming 可以知足企业大部分的需求，真正须要很是实时计算的应用仍是不多的，因此 Continuous Processing 模块还处于试验阶段，还不急着毕业； - 数砖应该在大量投人开发 Delta Lake 相关的东西，这个可以企业带来收入，目前这个才是他们的重点，因此天然开发 Streaming 的投入少了。 好了，废话不扯了，咱们来看看 Spark 3.0 的新特性吧。 ## 动态分区修剪（Dynamic Partition Pruning） 所谓的动态分区裁剪就是基于运行时（run time）推断出来的信息来进一步进行分区裁剪。举个例子，咱们有以下的查询： ``` SELECT * FROM dim_iteblog JOIN fact_iteblog ON (dim_iteblog.partcol = fact_iteblog.partcol) WHERE dim_iteblog.othercol > 10 ``` 假设 dim_iteblog 表的 dim_iteblog.othercol > 10 过滤出来的数据比较少，可是因为以前版本的 Spark 没法进行动态计算代价，因此可能会致使 fact_iteblog 表扫描出大量无效的数据。有了动态分区裁减，能够在运行的时候过滤掉 fact_iteblog 表无用的数据。通过这个优化，查询扫描的数据大大减小，性能提高了 33 倍。 这个特性对应的 ISSUE 能够参见 SPARK-11150 和 SPARK-28888。过往记忆大数据公众号也在前几天对这个特性进行了详细介绍，具体请参见 Apache Spark 3.0 动态分区裁剪（Dynamic Partition Pruning）介绍 和 Apache Spark 3.0 动态分区裁剪（Dynamic Partition Pruning）使用。 ## 自适应查询执行（Adaptive Query Execution） 自适应查询执行（又称 Adaptive Query Optimisation 或者 Adaptive Optimisation）是对查询执行计划的优化，容许 Spark Planner 在运行时执行可选的执行计划，这些计划将基于运行时统计数据进行优化。 早在2015年，Spark 社区就提出了自适应执行的基本想法，在 Spark 的 DAGScheduler 中增长了提交单个 map stage 的接口，而且在实现运行时调整 shuffle partition 数量上作了尝试。但目前该实现有必定的局限性，在某些场景下会引入更多的 shuffle，即更多的 stage，对于三表在同一个 stage 中作 join 等状况也没法很好的处理；并且使用当前框架很难灵活地在自适应执行中实现其余功能，例如更改执行计划或在运行时处理倾斜的 join。因此该功能一直处于实验阶段，配置参数也没有在官方文档中说起。这个想法主要来自英特尔以及百度的大牛，具体参见 SPARK-9850，对应的文章能够参见 Apache Spark SQL自适应执行实践。 而 Apache Spark 3.0 的 Adaptive Query Execution 是基于 SPARK-9850 的思想而实现的，具体参见 SPARK-23128。SPARK-23128 的目标是实现一个灵活的框架以在 Spark SQL 中执行自适应执行，并支持在运行时更改 reducer 的数量。新的实现解决了前面讨论的全部限制，其余功能（如更改 join 策略和处理倾斜 join）将做为单独的功能实现，并做为插件在后面版本提供。 ## 加速器感知调度（Accelerator-aware Scheduling） 现在大数据和机器学习已经有了很大的结合，在机器学习里面，由于计算迭代的时间可能会很长，开发人员通常会选择使用 GPU、FPGA 或 TPU 来加速计算。在 Apache Hadoop 3.1 版本里面已经开始内置原生支持 GPU 和 FPGA 了。做为通用计算引擎的 Spark 确定也不甘落后，来自 Databricks、NVIDIA、Google 以及阿里巴巴的工程师们正在为 Apache Spark 添加原生的 GPU 调度支持，该方案填补了 Spark 在 GPU 资源的任务调度方面的空白，有机地融合了大数据处理和 AI 应用，扩展了 Spark 在深度学习、信号处理和各大数据应用的应用场景。这项工做的 issue 能够在 SPARK-24615 里面查看，相关的 SPIP（Spark Project Improvement Proposals） 文档能够参见 SPIP: Accelerator-aware scheduling ## Apache Spark 3.0 将内置支持 GPU 调度  目前 Apache Spark 支持的资源管理器 YARN 和 Kubernetes 已经支持了 GPU。为了让 Spark 也支持 GPUs，在技术层面上须要作出两个主要改变： 在 cluster manager 层面上，须要升级 cluster managers 来支持 GPU。而且给用户提供相关 API，使得用户能够控制 GPU 资源的使用和分配。 在 Spark 内部，须要在 scheduler 层面作出修改，使得 scheduler 能够在用户 task 请求中识别 GPU 的需求，而后根据 executor 上的 GPU 供给来完成分配。 由于让 Apache Spark 支持 GPU 是一个比较大的特性，因此项目分为了几个阶段。在 Apache Spark 3.0 版本，将支持在 standalone、 YARN 以及 Kubernetes 资源管理器下支持 GPU，而且对现有正常的做业基本没影响。对于 TPU 的支持、Mesos 资源管理器中 GPU 的支持、以及 Windows 平台的 GPU 支持将不是这个版本的目标。并且对于一张 GPU 卡内的细粒度调度也不会在这个版本支持；Apache Spark 3.0 版本将把一张 GPU 卡和其内存做为不可分割的单元。详情请参见 过往记忆大数据公众号的《Apache Spark 3.0 将内置支持 GPU 调度》文章。 ## Apache Spark DataSource V2 Data Source API 定义如何从存储系统进行读写的相关 API 接口，好比 Hadoop 的 InputFormat/OutputFormat，Hive 的 Serde 等。这些 API 很是适合用户在 Spark 中使用 RDD 编程的时候使用。使用这些 API 进行编程虽然可以解决咱们的问题，可是对用户来讲使用成本仍是挺高的，并且 Spark 也不能对其进行优化。为了解决这些问题，Spark 1.3 版本开始引入了 Data Source API V1，经过这个 API 咱们能够很方便的读取各类来源的数据，并且 Spark 使用 SQL 组件的一些优化引擎对数据源的读取进行优化，好比列裁剪、过滤下推等等。  Data Source API V1 为咱们抽象了一系列的接口，使用这些接口能够实现大部分的场景。可是随着使用的用户增多，逐渐显现出一些问题： - 部分接口依赖 SQLContext 和 DataFrame - 扩展能力有限，难如下推其余算子 - 缺少对列式存储读取的支持 - 缺少分区和排序信息 - 写操做不支持事务 - 不支持流处理 为了解决 Data Source V1 的一些问题，从 Apache Spark 2.3.0 版本开始，社区引入了 Data Source API V2，在保留原有的功能以外，还解决了 Data Source API V1 存在的一些问题，好比再也不依赖上层 API，扩展能力加强。Data Source API V2 对应的 ISSUE 能够参见 SPARK-15689。虽然这个功能在 Apache Spark 2.x 版本就出现了，可是不是很稳定，因此社区对 Spark DataSource API V2 的稳定性工做以及新功能分别开了两个 ISSUE：SPARK-25186 以及 SPARK-22386。Spark DataSource API V2 最终稳定版以及新功能将会随着年末和 Apache Spark 3.0.0 版本一块儿发布，其也算是 Apache Spark 3.0.0 版本的一大新功能。 更多关于 Apache Spark DataSource V2 的详细介绍请参见过往记忆大数据公众号的 Apache Spark DataSource V2 介绍及入门编程指南（上） 和 Apache Spark DataSource V2 介绍及入门编程指南（下） 两篇文章的介绍。 ## 更好的 ANSI SQL 兼容 PostgreSQL 是最早进的开源数据库之一，其支持 SQL:2011 的大部分主要特性，彻底符合 SQL:2011 要求的 179 个功能中，PostgreSQL 至少符合 160 个。Spark 社区目前专门开了一个 ISSUE SPARK-27764 来解决 Spark SQL 和 PostgreSQL 之间的差别，包括功能特性补齐、Bug 修改等。功能补齐包括了支持 ANSI SQL 的一些函数、区分 SQL 保留关键字以及内置函数等。这个 ISSUE 下面对应了 231 个子 ISSUE，若是这部分的 ISSUE 都解决了，那么 Spark SQL 和 PostgreSQL 或者 ANSI SQL:2011 之间的差别更小了。 ## SparkR 向量化读写 Spark 是从 1.4 版本开始支持 R 语言的，可是那时候 Spark 和 R 进行交互的架构图以下：  每当咱们使用 R 语言和 Spark 集群进行交互，须要通过 JVM ，这也就没法避免数据的序列化和反序列化操做，这在数据量很大的状况下性能是十分低下的！ 并且 Apache Spark 已经在许多操做中进行了向量化优化（vectorization optimization），例如，内部列式格式（columnar format）、Parquet/ORC 向量化读取、Pandas UDFs 等。向量化能够大大提升性能。SparkR 向量化容许用户按原样使用现有代码，可是当他们执行 R 本地函数或将 Spark DataFrame 与 R DataFrame 互相转换时，能够将性能提升大约数千倍。这项工做能够看下 SPARK-26759。新的架构以下:  能够看出，SparkR 向量化是利用 Apache Arrow，其使得系统之间数据的交互变得很高效，并且避免了数据的序列化和反序列化的消耗，因此采用了这个以后，SparkR 和 Spark 交互的性能获得极大提高。