Holden Karau是IBM首席软件工程师,负责改进Apache Spark并协助开发者向Spark贡献代码。Holden曾是Databricks的软件开发工程师,负责Spark和Databricks Cloud的后端开发。她曾在Google和亚马逊从事软件开发工作,分别负责Google+的后端开发和亚马逊的智能分类系统。她在大数据和搜索领域有着丰富的经验,精通Scala, Scheme, Java, Perl, C, C++, Ruby等语言。Holden著有《Spark快速数据处理》,与人合著有 《Spark快速大数据分析》 。
《Spark快速数据处理》是第一本关于Apache Spark的书,所以这本书的重点是告诉人们如何开始。 《Spark快速大数据分析》 则是在一段时间之后写的,那时Spark SQL和其他重要组件已经加入了Spark,这本书更加专注于细节,但是仍然适合那些对Spark不甚了解的人。
在这两本书之间,我的写作实践发生了很大的变化,原因有几个。 《Spark快速大数据分析》 是一本合作完成的书,从早期开始,在技术审校的帮助下我们就提前发布了几个版本,所以我们可以轻松地做出改动,并且我们收到的反馈对于完成这本书来说非常有效。在写作 《Spark快速大数据分析》 时,我还在Databricks工作,所以从程序委员会那里进行事实核查或获得反馈都是非常容易的,因为他们中的很多人就在我的办公室里。
对于日常工作来说,我在IBM的最大改变可能就是:我有更多时间专注地从事关于Spark的工作了。当我在Databricks时,我必须得花很多时间从事Databricks Cloud(商业产品)的相关工作。还有其他的一些变化,比如Databricks拥有Spark的大部分代码提交者,所以在那里我的问题会更快得到回答,代码评审的速度也更快。当然,还会有小公司和大公司之间的差别,但是我们的小组做起事来却出乎意料地灵活。
这件事已经发生了!SparkR项目现在正式成为Spark的一部分,同时Spark也开始提供R API。但是作为最新的组件,SparkR还有很长的路要走,要想和Scala做到功能对等还需要一段时间。
我认为从传统关系型数据库向分布式系统转型的过程中会涉及到很多关于开发者的改变。Spark SQL可以弥补一些分析方面的差距——但是我认为很重要的一点在于:开发者必须增进对分布式系统在实践中的工作方式的理解。与其上来就重写现有的复杂系统,还不如在开始时重新搭建一个新项目(也许换一个新数据源),这会帮助开发者们建立起具有指导性的知识系统。
随着时间推移,很难预测大数据系统在未来将会发生什么,尤其在数量如此多的人都在参与开源社区的情况下。我相信久而久之,Spark会取代很多Map/Reduce系统和定制化系统,而其他系统则会把Spark作为执行引擎。但是仍然会有更适合定制化系统来完成的用例。
通常来说,我使用命令行会更加得心应手,但是对于调试工作之外的探索性工作来说,使用notebooks这样的工具确实很有帮助。当然,你也可以用Databricks Cloud,但是我使用Jupyter和Zeppelin的体验也很不错。然而对于生产环境下的工作来说,我认为notebooks很有局限性,难以测试,所以在我渡过探索阶段之后,我会使用更加传统的jar包。
Spark SQL是Spark的一个重要组件——通过引入Datasets,Spark在已有的关系型API的基础上把函数式编程带入到了Spark SQL中。我对Spark SQL的未来充满期待。
我的观点可能有些不客观,我认为 《Spark快速大数据分析》 会是一本进入这个领域的好书——但是在Spark shell里做一些探索性的工作也是快速进入状态的好办法。对于Spark现在所处的时期来说,如果你想成为Spark开发者,阅读源码是很有帮助的,但是对于终端使用者来说,阅读源码通常是没有必要的,除非你想要使用最新的特性。
我认为阅读Spark源码对于想要向Spark贡献代码的人来说是一项绝佳的活动。因为我是一位Emacs使用者,所以我喜欢用Magit,但是我也用过Ensime。很多其他开发者也觉得IntelliJ很好用。
我希望我能给出更好的建议,但是显然我的建议都从我的个人经历出发,而每个人情况都是不同的。话虽如此,但是我发现加入Women Who Code和Double Union(旧金山本地的女性黑客空间)这样的团体真的很有帮助,无论对于学习还是建立网络来说。
我认为在起步时参与开源软件开发是一种积累经验、增加资历的好方法,同时也能帮助你面试。话虽如此,但是对于某些开源项目来说,社区里会有很多明争暗斗,所以我总是尽可能地寻找友善的人,或者和我的朋友们一起工作。另外,我认为做分享是一种展示你的工作和结交领域内有趣的人的有效方法。