据估计,到2017年底,90%的CPU cycles 将会致力于移动硬件,移动计算正在迅速上升到主导地位。Spark为此重新设计了Spark体系结构,允许Spark在移动设备上运行Spark。 Spark为现代化数据中心和大数据应用进行设计和优化,但是它目前不适合移动计算。在过去的几个月中,Spark社区正在调研第一个可以在移动设备上运行架构的可行性,这篇文章将会和大家分享Spark社区的研究结果。 这个结构设计需要满足以下条件: 编译和运行目前Android Runtime (ART) 目前支持用Scala编写的应用程序,可以看这篇文章Scala IDE article on Android development。 性能优化JavaScript引擎是最具有创造性的领域之一,所以我们完全有理由相信,JavaScript引擎可以迅速地提高自己的表现性能。然而,移动设备上的JavaScript引擎看起来比台式机上的要落后,比如,移动设备上的JavaScript引擎不支持SIMD。我们可以将Spark对SIMD依赖的部分,我们可以进行选择性的重写,然后产生LLVM字节码。 网络和线协议Spark的网络传输是基于Netty的,而这个又依赖于 java.nio或者Linux epoll。虽然Android ART 内置就支持java.nio,但是我们需要重写Netty,使得我们可以在iOS上使用kqueue。除此之外,目前社区还不清楚是否低级别的网络原语(比如zero-copy)是否可以在JavaScript中使用,我们需要更密切地与苹果和谷歌合作,以改善JavaScript对移动网络的更好支持。 一个可行的选择是使用grpc(它是Google开发的开源高性能RPC库),grpc内置就支持在所有通用平台上(Java, Objective C等等)使用HTTP/2。 在调试方面,JSON应该是超过任何现有的二进制格式的首选线串行协议。 真正的本地调度和DAGScheduler为了更好地支持Spark的 local,social和mobile特性,社区将RDD本地性域用GPS坐标代替。本地调度可重构来真正的支持本地性,这是在服务器上永远与不可能实现的。 为了保证源码的兼容性,社区保留了旧的接口,并引入了新的本地性接口:
为移动平台扩展TaskContextTaskContext为Spark tasks提供了上下文信息(比如 job IDs, attempt IDs),这些在服务器上运行的Job就已经足够了。但是在移动设备上,还有其他的信息,比如GPS位置,ongoing calls等,这些上下文信息对优化taks的处理很有用,而且不会影响到 smartphone/tablet用户的用户体验。比如来了一个电话,一个新的task可能会被暂停,直到这个电话结束,这样用户的通话质量就不会受到影响。 iPhone和Android的基本引擎社区已经使用iPhone创建了几个proof-of-concepts,来更好地了解手机平台的复杂性。下面就是原型的截图。 本文翻译自:https://databricks.com/blog/2015/04/01/spark-2-rearchitecting-spark-for-mobile.html.最后一节(Prototyping Machine Learning Application)本文未翻译,感兴趣的同学可以到里面去看看。 |
|广告服务|关于我们|Archiver|手机版|小黑屋|大数据人 ( 鄂ICP备14012176号-2 )
GMT+8, 2024-10-22 09:38 , Processed in 0.185314 second(s), 22 queries .
Powered by 小雄! X3.2
© 2014-2020 bigdataer Inc.