今天，我们很高兴地宣布Databricks上的ApacheSpark2.0正式可用。这个版本建立在社区在过去两年中所学的基础上，在用户喜欢的内容上加倍，并解决了难点。这篇文章总结了Spark 2.0的三大主题：更简单、更快和更智能。我们还将在我们的Spark 2.0内容选集中更详细地探讨其中的许多。两个月前，我们在Databricks上发布了apachespark2.0的预览版。正如您在下面的图表中看到的，10%的集群已经在使用这个版本，因为客户正在试验新功能并向我们提供反馈。由于这次经历，我们很高兴成为第一个支持Spark 2.0的商业供应商。Apache Spark随时间的使用情况（按版本） 现在，让我们深入了解ApacheSpark2.0的新特性。更简单：ANSI SQL和流线型API在Spark中，我们引以为傲的一件事是API，它简单、直观、富有表现力。Spark 2.0延续了这一传统，专注于两个领域：（1）标准SQL支持和（2）统一数据帧/数据集API。在SQL方面，通过引入新的ansisql解析器和子查询，我们大大扩展了Spark的SQL支持。Spark 2.0可以运行所有99个TPC-DS查询，这需要许多SQL:2003特性。因为SQL一直是Spark的主要接口之一，所以这些扩展功能大大减少了移植遗留应用程序的工作量。在编程API方面，我们简化了Spark的API：在Scala/Java中统一数据帧和数据集：从Spark 2.0开始，DataFrame只是行数据集的一个类型别名。类型化方法（例如map、filter、groupByKey）和非类型化方法（例如select、groupBy）在Dataset类上都可用。另外，这个新的组合数据集接口是用于结构化流的抽象。由于编译时类型安全不是Python和R中的一个特性，所以Dataset的概念不适用于这些语言api。相反，DataFrame仍然是那里的主要接口，并且类似于这些语言中的单节点数据帧概念。从这个笔记本和这个博客中可以窥见这些API背后的故事。SparkSession：取代SQLContext和HiveContext的新入口点。对于dataframeapi的用户来说，Spark的一个常见困惑是使用哪个"上下文"。现在您可以使用SparkSession，它将两者都包含在一起，作为一个入口点，如本笔记本所示。请注意，旧的SQLContext和HiveContext类仍然保持向后兼容性。更简单、更具性能的累加器API：我们设计了一个新的累加器API，它具有更简单的类型层次结构，并支持基元类型的专门化。旧的累加器API已被弃用，但为了向后兼容而保留基于数据帧的机器学习API作为主要的ML API出现：在Spark 2.0中火花.ml包及其"管道"API将成为主要的机器学习API。而原来的火花.mllib包被保留了，未来的开发将集中在基于数据帧的API上。机器学习管道持久性：用户现在可以跨Spark支持的所有编程语言保存和加载机器学习管道和模型。更多细节请参阅此博客文章，示例请参见本笔记本。R中的分布式算法：增加了对广义线性模型（GLM）、朴素贝叶斯、生存回归和R中的K均值的支持。R中的用户定义函数（udf）：增加了对运行分区级udf（dapply和gapply）和超参数调优（lapply）的支持。更快：apachespark作为编译器根据我们2015年的Spark调查，91%的用户认为性能是Apache Spark最重要的方面。因此，性能优化一直是Spark开发中的一个重点。在我们开始计划对Spark 2.0的贡献之前，我们问了自己一个问题：Spark已经相当快了，但是我们是否可以突破界限，让Spark更快10倍？这个问题让我们从根本上重新思考构建Spark物理执行层的方式。当您查看现代数据引擎（例如Spark或其他MPP数据库）时，大部分CPU周期都花在无用的工作上，例如进行虚拟函数调用或将中间数据读/写到CPU缓存或内存中。通过减少在这些无用的工作中浪费的CPU周期来优化性能一直是现代编译器长期关注的焦点。Spark 2.0配备了第二代钨发动机。这个引擎基于现代编译器和MPP数据库的思想，并将它们应用于Spark工作负载。其主要思想是在运行时发出优化的代码，将整个查询压缩为一个函数，消除虚拟函数调用，并利用CPU寄存器作为中间数据。我们称这种技术为"全阶段代码生成"为了给你一个提示，我们测量了spark1.6和spark2.0中的一些操作符在一个内核上处理一行所需的时间（以纳秒为单位）。下表显示了Spark 2.0的改进。Spark 1.6还包含了一种表达式代码生成技术，该技术用于一些最先进的商业数据库中，但是正如您所看到的，随着整个阶段代码生成，许多运算符的速度提高了一个数量级。在这本笔记本中，您可以看到整个阶段代码生成的强大功能，我们在一台计算机上对10亿条记录执行聚合和联接。每行成本（单线程）原始的火花1.6火花2.0滤波器15纳秒1.1纳秒汇总组w/o14纳秒0.9纳秒总和w/组79纳秒10.7纳秒哈希联接115纳秒4.0纳秒排序（8位熵）620纳秒5.3牛排序（64位熵）620纳秒40纳秒排序合并连接750纳秒700纳秒这个新引擎如何处理端到端查询？我们使用TPC-DS查询对Spark 1.6和Spark 2.0进行了一些初步分析：除了整个阶段的代码生成以提高性能外，还进行了大量工作来改进Catalyst优化器，以实现一般查询优化，如可空性传播，以及一个新的矢量化拼花解码器，它将拼花地板扫描吞吐量提高了3倍。更智能：结构化流媒体Spark Streaming作为第一批将批处理和流计算相结合的系统之一，一直引领着大数据空间。当Spark 0.7引入名为DStreams的流式API时，它为开发人员提供了几个强大的特性：精确一次语义、大规模容错、强一致性保证和高吞吐量。然而，在处理了数百个Spark流的实际部署后，我们发现需要实时做出决策的应用程序通常需要的不仅仅是一个流引擎。它们需要批处理堆栈和流式堆栈的深度集成、与外部存储系统的交互以及处理业务逻辑变化的能力。因此，企业需要的不仅仅是一个流式引擎，而是需要一个完整的堆栈，使它们能够开发端到端的"连续应用程序"Spark 2.0通过一个叫做结构化流的新API来处理这些用例。与现有流媒体系统相比，结构化流媒体有三个关键改进：集成了API和批处理作业。为了运行流计算，开发人员只需针对DataFrame/Dataset API编写一个批处理计算，Spark会自动递增计算以流式方式运行（即，在数据进来时更新结果）。这种强大的设计意味着开发人员不必手动管理状态、故障或使应用程序与批处理作业保持同步，相反，流作业总是给出与相同数据上的批处理作业相同的答案。与存储系统的事务性交互。结构化流式处理整个引擎和存储系统的容错性和一致性，使编写更新用于服务的实时数据库、加入静态数据或在存储系统之间可靠地移动数据的应用程序变得容易。与Spark的其他部分进行了丰富的集成。结构化流支持通过sparksql对流数据进行交互式查询、针对静态数据的连接以及许多已经使用数据帧的库，使开发人员能够构建完整的应用程序，而不仅仅是流式管道。在将来，期望与MLlib和其他库进行更多的集成。Spark 2.0提供了结构化流的初始alpha版本，作为（出人意料的小！）数据帧/数据集API的扩展。这使得现有的Spark用户很容易接受，他们希望实时回答新问题。其他关键特性包括支持基于事件时间的处理、无序/延迟数据、交互式查询以及与非流式数据源和接收器的交互。我们还更新了Databricks工作区以支持结构化流。例如，启动流式查询时，notebook UI将自动显示其状态。流媒体显然是一个广泛的主题，所以请关注一系列关于ApacheSpark2.0中结构化流的详细信息的博客文章。结论Spark用户最初是因为ApacheSpark的易用性和性能而来的。Spark 2.0在扩展它以支持更广泛的工作负载的同时，将其加倍。享受Databricks的新版本。阅读更多您还可以导入以下笔记本，并在带有Spark 2.0的Databricks Community Edition上试用它们。SparkSession：一个新的切入点数据集：一个更精简的API全阶段代码生成的性能机器学习管道持久性免费试用Databricks。今天就开始吧