技术预览版的Apache火花2.0砖
在过去的几个月里,我们一直在忙着为大数据的下一个主要版本的开源软件我们爱:Apache 2.0火花。bob下载地址两年前因为火花1.0出来,我们听见赞美和投诉。火花2.0基于社区已经学到的东西在过去的两年里,加倍的用户喜欢什么和改进用户抱怨。虽然这篇文章总结了三大宗旨和themes-easier,更快,2.0和聪明组成火花,这里值得强调的主题做深度的讨论,我们将跟进深入博客在未来几周内。
在我们深入研究之前,我们很高兴地宣布Apache火花2.0技术预览版的可用性砖。这个预览包是基于上游2.0.0-preview释放。使用预览的包很简单,选择“2.0(分支预览)”版本当启动一个集群:
而最后Apache火花2.0版本仍然是几周的时间,这技术预览版旨在提供早期访问特性引发2.0基于上游代码库。通过这种方式,您可以满足你的好奇心尝试闪亮的新玩具,当我们得到反馈和bug报告最终版本之前。
现在,让我们看一看新的发展。
简单:SQL和流线型的api
我们很自豪的一件事在火花是创建简单的api,直观的表达。火花2.0继续这一传统,关注两个方面:(1)标准SQL支持和(2)统一DataFrame /数据API。
在SQL方面,我们已经显著扩大了火花的SQL功能,通过引入一个新的ANSI SQL解析器和支持子查询。火花2.0可以运行所有的99 TPC-DS查询,需要许多SQL: 2003的特性。因为SQL的一个主要接口应用程序使用,这个扩展SQL功能大大减少遗留应用程序的移植到火花。
在编程API方面,我们有流线型的API:
- Scala中的统一DataFrames和数据集/ Java:在火花2.0开始,DataFrame只是一个类型别名数据集的行。类型的方法(如。
地图,过滤器,groupByKey(如)和无类型的方法。选择,groupBy)数据集类上都是可用的。同样,这一新的数据接口是抽象相结合用于结构化流。自编译时类型安全在Python和R不是一个语言功能,数据集的概念并不适用于这些语言的api。相反,DataFrame仍然主要编程抽象,这类似于这些语言的单节点数据帧的概念。 - SparkSession:一个新的切入点,取代了旧SQLContext和HiveContext。DataFrame API,用户的一个共同的源引发的混乱的“上下文”。注意,老SQLContext和HiveContext仍保持向后兼容性。
- 更简单、更高性能蓄电池API:我们设计一个新的累加器API,有一个简单的类型层次结构和支持基本类型的专门化。旧蓄电池API已经弃用,但保留向后兼容性
- DataFrame-based机器学习API中作为主要毫升API:2.0与火花,火花。毫升包,“管道”API,将成为主要的机器学习API。原来的火花。mllib包保存下来,未来的发展重点是DataFrame-based API。
- 分布式算法R:增加了对广义线性模型的支持(GLM),朴素贝叶斯、生存回归,和k - means R。
快:火花作为编译器
根据我们的2015年引发调查,91%的用户认为火花的性能是最重要的方面。因此,性能优化一直专注在我们的火花的发展。在我们开始计划贡献2.0火花,我们问自己一个问题:火花已经很快,但我们能把它的边界,使火花快10倍?
这个问题让我们从根本上重新思考我们构建的方式引发的物理执行层。当你看到在现代数据引擎(例如火花或其他MPP数据库),大多数CPU周期花在无用的工作,如制作虚拟函数调用或读/写中间数据CPU缓存或内存。通过减少CPU周期的数量优化性能浪费在这些无用的工作已经很长一段时间的重点现代编译器。
火花2.0附带第二代钨引擎。这个引擎构建在思想与现代编译器和MPP数据库和应用数据处理。主要的思想是在运行时排放优化字节码,瓦解整个查询到一个单一的功能,消除虚拟函数调用和中间数据利用CPU寄存器。我们称这种技术“舞台代码生成”。
给你一个急转弯,我们测量的时间(纳秒)需要处理一行在一个核心的一些运营商1.6 vs 2.0火花,火花,下表是一个比较新的钨引擎的力量。火花1.6包含表达式代码生成技术,也在今天使用一些先进的商业数据库。正如你所看到的,许多核心运营商越来越快一个数量级与舞台代码生成。
| 原始的 | 火花1.6 | 火花2.0 |
|---|---|---|
| 过滤器 | 15 ns | 1.1 ns |
| 和w / o组 | 14 ns | 0.9 ns |
| 和w /组 | 79纳秒 | 10.7 ns |
| 散列连接 | 115纳秒 | 4.0 ns |
| 排序熵(8位) | 620纳秒 | 5.3 ns |
| 排序熵(64位) | 620纳秒 | 40 ns |
| 分类合并加入 | 750纳秒 | 700纳秒 |
端到端查询这个新引擎是如何工作的?我们做了一些初步分析使用TPC-DS查询比较1.6火花,火花2.0:
舞台之外的代码生成来提高性能,很多工作也进入改善催化剂优化器等通用查询优化nullability传播,以及一个新的矢量化铺解码器铺扫描吞吐量提高了3倍。
聪明:结构化流
火花流一直带领大数据空间的第一个尝试统一批处理和流计算。作为第一流API调用DStream在火花0.7中引入的,它提供了开发人员和几个强大的属性:只有一次语义,在规模、容错和高吞吐量。
然而,在处理数以百计的实际部署的火花,我们发现,应用程序需要在实时做出决策往往需要的不仅仅是一个流引擎。他们需要批堆栈深度集成和流栈,与外部存储系统的集成,以及处理业务逻辑的变化的能力。因此,企业不仅仅要流引擎;相反,他们需要一个完整的堆栈,使他们能够开发端到端“连续应用。”
一所学校的思想是把一切都像一个流;也就是说,采用单个编程模型集成这两个批处理和流数据。
这种单一模式,存在许多问题。首先,操作数据到达可以是非常困难和限制。第二,不同的数据分布,变化的业务逻辑,和延迟数据添加独特的挑战。第三,大多数现有的系统,比如MySQL或Amazon S3,不要表现得像一个流和许多算法(包括最现成的机器学习)不工作在一个流媒体设置。
火花2.0的结构化流api是一种新型的方法流。它源于意识到最简单的方法来计算数据流,是答案不需要原因,这是一个流。这个实现来自我们的经验已经知道如何编程的程序员静态数据集(又名批)API使用引发强大的DataFrame /数据集。结构化流的愿景是利用催化剂优化器时发现可以透明地将静态程序变成增量执行工作动态,无限的数据(即流)。当通过结构化角度看数据离散表或无限的表简化流。
认识到,实现这一目标的第一步,火花2.0附带一个结构化流的初始版本API,(小得惊人!)扩展DataFrame /数据API。这应统一采用简单为现有火花用户,允许他们利用他们的知识的火花批API实时回答的新问题。关键特性将包括支持基于事件时间处理,无序/延迟数据,sessionization与非紧密集成,数据来源和下沉。
流媒体显然是一个非常广泛的主题,所以请继续关注这个博客的更多细节在结构化流火花2.0,包括什么是可能的细节在此版本中,什么是在不久的将来的路线图。
结论
引发用户最初来激发其易用性和性能。2.0双打在这些火花,同时支持一个更广泛的扩展它的工作负载。我们希望你能喜欢预览,期待你的反馈。
当然,上游Apache火花2.0版本完成之前,我们不建议完全任何生产工作负载迁移到这个预览包。这个技术预览版本现在可以在砖上。获得数据砖,签约在这里。
阅读更多
如果你错过了我们的网络研讨会Apache 2.0:火花更容易,更快,更聪明,你可以下载幻灯片和笔记本。