昨天，为了庆祝apachespark 5岁生日，我们回顾了这个项目的历史。今天，我们很高兴地宣布Spark开发的下一个重要章节：一个旨在使Spark在移动设备上运行的架构改革。移动计算正在迅速崛起，到2017年底，预计90%的CPU周期将用于移动硬件。只有当Spark为不断增长的移动用户高效运行时，Spark的项目目标才能实现。如今，Spark的100%用户都有手机。Spark为现代数据中心和大数据应用程序设计和优化，不幸的是，它并不适合今天的移动计算。在过去的几个月里，我们已经对mobileirstspark架构的可行性进行了原型设计，今天我们将与大家分享我们的发现。这篇文章概述了Spark移动支持的技术设计，并分享了几个早期原型的结果。另见SPARK-6646，了解有关该问题的社区讨论。要求必须具备：支持在Android和iOS上运行Spark促进SoLoMo（社交、本地、移动）应用程序的开发保持源代码向后兼容性在单个Spark集群中支持异构移动电话很高兴有：支持在Windows phones上运行Spark通过J2ME支持功能手机编译和运行时Android运行时（ART）已经支持使用Scala开发应用程序，这篇关于Android开发的scalaide文章就证明了这一点。然而，iOS没有内置的JVM支持。幸运的是，我们可以在这里利用多种社区努力：使用RoboVM，一个用于使用Java开发iOS应用程序的提前（AOT）编译器和库。使用Scala+LLVM将Spark的Scala代码编译成LLVM字节码。考虑到苹果在LLVM项目背后的坚定立场，我们相信这可以达到最高水平的性能。由于Swift看起来与Scala非常相似，我们可以创建一个项目来自动将Scala源代码转换为Swift，然后使用XCode构建iOS包。使用斯卡拉.js将Spark编译成JavaScript，并在Nitro JavaScript引擎（Safari）中执行Spark。选项4是首选，因为它不仅支持iOS，而且支持所有使用单个软件包的平台。在iOS和Android上，Spark可以由JavaScript引擎执行。在服务器上，Spark可以在节点.js.性能优化JavaScript引擎是最热门的创新领域之一，因此我们完全期待JavaScript引擎能够迅速提高其性能。然而，移动JavaScript引擎似乎落后于其桌面变体。特别是，似乎没有SIMD对移动JavaScript的支持。对于Spark中可能从SIMD中受益匪浅的部分，例如低级矩阵操作，我们可以有选择地重写这些部分来生成LLVM字节码。网络和有线协议Spark的网络传输建立在Netty上，而Netty又依赖于java.nio软件或Linux epoll。Android ART似乎支持java.nio软件开箱即用，但我们可能需要重写Netty以在iOS上使用kqueue。此外，还不清楚是否可以在JavaScript中公开诸如zero copy之类的低级网络原语。我们需要与苹果和谷歌更紧密地合作，以改善移动JavaScript的网络支持。一个可行的选择是利用grpc，一个由Google开发的开源高性能RPC库。grpc使用HTTP/2为所有通用平台（Java、Objective C等）提供开箱即用的支持。考虑到对可调试性的关注，JSON应该是首选的有线序列化协议，而不是任何现有的二进制格式。真局部调度与DAGScheduler为了更好地支持Spark的本地、社交和移动特性，我们将RDDs的locality字段更改为GPS坐标，并且可以重构局部性调度以支持服务器上永远不可能实现的真正的局部性。为了保持源代码的兼容性，我们保留了原来的接口，并引入了一个新的真正的局部性接口。RDD类{@不推荐（"2.0"，"使用getPreferredTrueLocations"）def getPreferredLocations（p:Partition）：Seq[String]/***返回在分区上执行任务的首选位置*RDD的具体实现可以使用它来实现*位置调度。*/def getPreferredTrueLocations（p:分区）：Seq[LatLong]}需要更新DAGScheduler来计算执行器的地理接近度。将TaskContext扩展到移动平台TaskContext提供Spark任务的上下文信息（例如，作业ID、尝试ID等）。虽然这对于在服务器上运行已经足够了，但移动平台有许多其他上下文信息，如GPS位置、正在进行的呼叫等。这些上下文信息可能有助于优化任务处理，而不会影响智能手机/平板电脑用户的用户体验。例如，如果电话呼叫处于活动状态，则新任务可能会暂停，直到通话结束，这样通话质量才不会受到影响。iPhone和Android上的基本引擎为了更好地理解移动平台的复杂性，我们已经用iphone构建了一些概念证明。以下是我们的原型截图。博客文章开头的截图显示了一个运行在iPhone上的Spark流式NetworkWordCount示例。它使用套接字从运行在amazonec2上的服务器接收数据。我们还在Android上做原型。以下是Android设备模拟器的一些早期屏幕截图。原型机器学习应用在实际的机器学习中，标签总是很难获得，而且成本很高。这不会成为Spark on Mobile的问题。在机器学习的管道API中，我们将提供一个生成人工标记的转换器。tagger=humantager（tags=["垃圾邮件"，"ham"]，重试次数=10）标记=标签。转换（图片）model=LogisticRegression（）.fit（带标签）在转换过程中，图像与可能的标记一起显示，用户为每个图像选择正确的标记。为了确保转换是容错的，我们将随机排序，并对每个记录重试10次。是的，RDD总是确定性的。当然，我们支持使用多个标签进行标记，即使是在可穿戴设备上：总之，本设计文档建议对Spark进行架构更改，以允许在移动平台上高效执行。无论是八核x86处理器还是四核ARM处理器，Spark都应该是一个统一的计算平台。我们期待着与社区合作实现这一努力，并听取您对JIRA罚单的反馈：SPARK-6646。[以防万一你没意识到-现在是4月1日！]免费试用Databricks。今天就开始吧