在过去的几个月里，我们一直忙于为我们喜爱的大数据开源软件的下一个主要版本做贡献：ApacheSpark2.0。自从两年前Spark 1.0问世以来，我们听到了赞扬和抱怨。Spark 2.0建立在社区过去两年所学的基础上，在用户喜爱的内容上加倍，并在用户的感叹上有所改进。虽然这篇博客总结了Spark 2.0的三大主旨和主题：更简单、更快、更智能，但这里强调的主题值得深入讨论，我们将在接下来的几周内继续深入讨论。在深入讨论之前，我们很高兴地宣布Databricks中提供了ApacheSpark2.0技术预览版。此预览包基于上游2.0.0预览版。使用预览包非常简单，只需在启动群集时选择"2.0（分支预览）"版本：尽管apachespark2.0的最终发布还有几周的时间，但是这个技术预览版旨在基于上游代码库提供对spark2.0中特性的早期访问。这样，你就可以满足你的好奇心去尝试这个闪亮的新玩具，同时我们会在最终发布之前得到反馈和bug报告。现在，让我们来看看新的发展。更简单：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应用程序使用的主要接口之一，这种扩展的SQL功能大大减少了传统应用程序移植到Spark的工作量。在编程API方面，我们简化了API：在Scala/Java中统一数据帧和数据集：从Spark 2.0开始，DataFrame只是行数据集的一个类型别名。类型化方法（例如map、filter、groupByKey）和非类型化方法（例如select、groupBy）在Dataset类上都可用。另外，这个新的组合数据集接口是用于结构化流的抽象。由于Python和R中的编译时类型安全不是一种语言特性，所以Dataset的概念不适用于这些语言的api。相反，数据帧仍然是主要的编程抽象，这类似于这些语言中的单节点数据帧概念。从数据集API笔记本中浏览一下。SparkSession：替换旧的SQLContext和HiveContext的新入口点。对于dataframeapi的用户来说，Spark的一个常见困惑是使用哪个"上下文"。现在您可以使用SparkSession，它将两者都包含在一起，作为一个入口点，如本笔记本所示。请注意，旧的SQLContext和HiveContext仍然保留下来，以便向后兼容。更简单、更具性能的累加器API：我们设计了一个新的累加器API，它具有更简单的类型层次结构，并支持基元类型的专门化。旧的累加器API已被弃用，但为了向后兼容而保留基于数据帧的机器学习API作为主要的ML API出现：在Spark 2.0中火花.ml包及其"管道"API将成为主要的机器学习API。而原来的火花.mllib包被保留了，未来的开发将集中在基于数据帧的API上。通过机器学习和管道学习，用户可以节省所有机器编程的管道。R中的分布式算法：增加了对广义线性模型（GLM）、朴素贝叶斯、生存回归和R中的K均值的支持。更快：Spark作为编译器根据我们2015年Spark调查，91%的用户认为性能是Spark最重要的方面。因此，性能优化一直是Spark开发中的一个重点。在我们开始计划对Spark 2.0的贡献之前，我们问了自己一个问题：Spark已经相当快了，但是我们是否可以突破界限，让Spark更快10倍？这个问题让我们从根本上重新思考构建Spark物理执行层的方式。当您查看现代数据引擎（例如Spark或其他MPP数据库）时，大部分CPU周期都花在无用的工作上，例如进行虚拟函数调用或将中间数据读/写到CPU缓存或内存中。通过减少在这些无用的工作中浪费的CPU周期来优化性能一直是现代编译器长期关注的焦点。Spark 2.0配备了第二代钨发动机。这个引擎建立在现代编译器和MPP数据库的基础上，并将它们应用于数据处理。其主要思想是在运行时发出优化的字节码，将整个查询压缩为一个函数，消除虚拟函数调用，并利用CPU寄存器作为中间数据。我们称这种技术为"全阶段代码生成"为了给你一个提示，我们测量了Spark 1.6和Spark 2.0中的一些操作员在一个内核上处理一行所需的时间（以纳秒为单位），下表是一个对比，展示了新的钨发动机的功率。spark1.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进行了一些初步分析：作为优化整体的3倍流优化算法的核心，也提高了新算法的性能。更智能：结构化流媒体Spark Streaming长期以来一直引领着大数据空间，是第一次尝试统一批处理和流计算。作为Spark 0.7中引入的第一个流式API DStream，它为开发人员提供了几个强大的特性：一次语义、规模容错和高吞吐量。然而，在处理了数百个Spark流的实际部署后，我们发现需要实时做出决策的应用程序通常需要的不仅仅是一个流引擎。它们需要批处理堆栈和流式堆栈的深度集成、与外部存储系统的集成以及处理业务逻辑变化的能力。因此，企业需要的不仅仅是一个流式引擎，而是需要一个完整的堆栈，使它们能够开发端到端的"连续应用程序"一个学派的想法是把所有的东西都当作一个流；也就是说，采用一个集成批处理和流数据的编程模型。这种单一模式存在许多问题。首先，在数据到达时对其进行操作是非常困难和限制性的。其次，不断变化的数据分布、不断变化的业务逻辑和延迟的数据都增加了独特的挑战。第三，大多数现有的系统，如MySQL或amazons3，表现得不像一个流，而且许多算法（包括大多数现成的机器学习）不能在流媒体环境下工作。Spark 2.0的结构化流媒体API是处理流媒体的一种新方法。它源于这样一个认识：在数据流上计算答案的最简单方法是不必对数据流是一个流这一事实进行推理。这个实现来自于我们与程序员的经验，他们已经知道如何使用Spark强大的DataFrame/Dataset API编程静态数据集（又称批处理）。结构化流的远景是利用Catalyst优化器来发现何时可以透明地将静态程序转换为对动态、无限数据（也称为流）执行的增量执行。通过这种结构化的数据透视图，可以简化流式处理。作为实现这一愿景的第一步，Spark 2.0附带了结构化流API的初始版本，a（非常小！）数据帧/数据集API的扩展。这种统一将使现有的Spark用户更容易采用，使他们能够利用他们对Spark批处理API的知识来实时回答新问题。这里的主要功能包括支持基于事件时间的处理、无序/延迟数据、会话以及与非流数据源和接收器的紧密集成。流媒体显然是一个相当宽泛的话题，所以请继续关注本博客，了解更多关于Spark 2.0中结构化流媒体的详细信息，包括本版本中可能实现的内容以及近期的路线图。结论Spark用户最初是因为它的易用性和性能而来Spark的。Spark 2.0在扩展它以支持更广泛的工作负载的同时，将其加倍。我们希望您会喜欢预览，并期待您的反馈。当然，在上游apachespark2.0版本最终确定之前，我们不建议将任何生产工作负载完全迁移到这个预览包中。这个技术预览版现在可以在Databricks上使用。要访问Databricks，请在这里注册。阅读更多如果您错过了ApacheSpark2.0：更简单、更快、更智能的网络研讨会，您可以下载幻灯片和附带的笔记本。您还可以导入以下笔记本并尝试您的Databricks commit