Scala和Java，到底该使用哪一种大数据编程语

scala底层用到的还是java,只是在java上套了一层壳

由于scala最终被编译为.class 所以其实本质上还是java 所以在scala中可以任意的调用java的api

.java –> .class –> jvm

.scala –> .class –> jvm如果你对晦涩的统计运算进行繁重的数据分析工作，那么你不青睐r才怪。如果你跨gpu进行nlp或密集的神经网络处理，那么python是很好的选择。如果想要一种加固的、面向生产环境的数据流解决方案，又拥有所有重要的操作工具，java或scala绝对是出色的选择。

有一个大数据项目，你知道问题领域(problem domain)，也知道使用什么基础设施，甚至可能已决定使用哪种框架来处理所有这些数据，但是有一个决定迟迟未能做出：我该选择哪种语言?(或者可能更有针对性的问题是，我该迫使我的所有开发人员和数据科学家非要用哪种语言?)这个问题不会推迟太久，迟早要定夺。

当然，没有什么阻止得了你使用其他机制(比如xslt转换)来处理大数据工作。但通常来说，如今大数据方面有三种语言可以选择：r、python和scala，外加一直以来屹立于企业界的java。那么，你该选择哪种语言?为何要选择它，或者说何时选择它?

下面简要介绍了每种语言，帮助你做出合理的决定。

r经常被称为是“统计人员为统计人员开发的一种语言”。如果你需要深奥的统计模型用于计算，可能会在cran上找到它――你知道，cran叫综合r档案网络(comprehensive r archive network)并非无缘无故。说到用于分析和标绘，没有什么比得过ggplot2。而如果你想利用比你机器提供的功能还强大的功能，那可以使用sparkr绑定，在r上运行spark。

然而，如果你不是数据科学家，之前也没有用过matlab、sas或octave，可能需要一番调整，才能使用r来高效地处理。虽然r很适合分析数据，但是就一般用途而言不太擅长。你可以用r构建模型，但是你需要考虑将模型转换成scala或python，才能用于生产环境，你不太可能使用这种语言编写一种集群控制系统(运气好的话，你可以对它进行调试)。

python

如果你的数据科学家不使用r，他们可能就会彻底了解python。十多年来，python在学术界当中一直很流行，尤其是在自然语言处理(nlp)等领域。因而，如果你有一个需要nlp处理的项目，就会面临数量多得让人眼花缭乱的选择，包括经典的ntlk、使用gensim的主题建模，或者超快、准确的spacy。同样，说到神经网络，python同样游刃有余，有theano和tensorflow;随后还有面向机器学习的scikit-learn，以及面向数据分析的numpy和pandas。

还有juypter/ipython――这种基于web的笔记本服务器框架让你可以使用一种可共享的日志格式，将代码、图形以及几乎任何对象混合起来。这一直是python的杀手级功能之一，不过这年头，这个概念证明大有用途，以至于出现在了奉行读取-读取-输出-循环(repl)概念的几乎所有语言上，包括scala和r。

python往往在大数据处理框架中得到支持，但与此同时，它往往又不是“一等公民”。比如说，spark中的新功能几乎总是出现在scala/java绑定的首位，可能需要用pyspark编写面向那些更新版的几个次要版本(对spark streaming/mllib方面的开发工具而言尤为如此)。

与r相反，python是一种传统的面向对象语言，所以大多数开发人员用起来会相当得心应手，而初次接触r或scala会让人心生畏惧。一个小问题就是你的代码中需要留出正确的空白处。这将人员分成两大阵营，一派觉得“这非常有助于确保可读性”，另一派则认为，2016年，我们应该不需要就因为一行代码有个字符不在适当的位置，就要迫使解释器让程序运行起来。

scala

现在说说scala：在本文介绍的四种语言中，scala是最轻松的语言，因为大家都欣赏其类型系统。scala在jvm上运行，基本上成功地结合了函数范式和面向对象范式，目前它在金融界和需要处理海量数据的公司企业中取得了巨大进展，常常采用一种大规模分布式方式来处理(比如twitter和linkedin)。它还是驱动spark和kafka的一种语言。

由于scala在jvm里面运行，它可以立即随意访问java生态系统，不过它也有一系列广泛的“原生”库，用于处理大规模数据(尤其是twitter的algebird和summingbird)。它还包括一个使用非常方便的repl，用于交互式开发和分析，就像使用python和r那样。

我个人非常喜欢scala，因为它包括许多实用的编程功能，比如模式匹配，而且被认为比标准的java简洁得多。然而，用scala来开发不止一种方法，这种语言将此作为一项特色来宣传。这是好事!不过考虑到它拥有图灵完备(turing-complete)的类型系统和各种弯弯曲曲的运算符(“/:”代表foldleft，“:\”代表foldright)，很容易打开scala文件，以为你看到的是某段讨厌的perl代码。这就需要在编写scala时遵循一套好的实践和准则(databricks的就很合理)。

另一个缺点是，scala编译器运行起来有点慢，以至于让人想起以前“编译!”的日子。不过，它有repl、支持大数据，还有采用jupyter和zeppelin这一形式的基于web的笔记本框架，所以我觉得它的许多小问题还是情有可原。

最终，总是少不了java――这种语言没人爱，被遗弃，归一家只有通过起诉谷歌才有钱可赚时才似乎关心它的公司(注：oracle)所有，完全不时髦。只有企业界的无人机才使用java!不过，java可能很适合你的大数据项目。想一想hadoop mapreduce，它用java编写。hdfs呢?也用java来编写。连storm、kafka和spark都可以在jvm上运行(使用clojure和scala)，这意味着java是这些项目中的“一等公民”。另外还有像google cloud dataflow(现在是apache beam)这些新技术，直到最近它们还只支持java。

java也许不是摇滚明星般备受喜爱的首选语言。但是由于研发人员在竭力理清node.js应用程序中的一套回调，使用java让你可以访问一个庞大的生态系统(包括分析器、调试器、监控工具以及确保企业安全和互操作性的库)，以及除此之外的更多内容，大多数内容在过去二十年已久经考验(很遗憾，java今年迎来21岁，我们都老矣)。

炮轰java的一个主要理由是，非常繁琐冗长，而且缺少交互式开发所需的repl(r、python和scala都有)。我见过10行基于scala的spark代码迅速变成用java编写的变态的200行代码，还有庞大的类型语句，它们占据了屏幕的大部分空间。然而，java 8中新的lambda支持功能对于改善这种情况大有帮助。java从来不会像scala那么紧凑，但是java 8确确实实使得用java进行开发不那么痛苦。

至于repl?好吧，目前还没有。明年推出的java 9会包括jshell，有望满足你的所有repl要求。

Java加REPL等于jshell吗？

不能这么简单的相加。

1、在Java 8(以及jjs REPL)中引入的Nashorn Javascript实现打开了更广泛地考虑REPL并将交互式开发成为可能的大门。

2、一项努力将现代REPL引入Java 9的工作，以JEP 222作为开始，收录在OpenJDK的Kulla项目中。Kulla这个名字来自古巴比伦神话，是建造之神。

3、该项目的主旨是提供最近距离的“完整Java”体验。该项目没有引入新的非Java语义，并禁用了Java语言中对交互式开发没有用处的语义(比如上层的访问控制修改或同步的语义)。

与所有REPL一样，JShell提供了命令行，而不是类似IDE的体验。语句和表达式能够在执行状态上下文中，被立即求值，而不是非得打包到类中。

4、方法也是自由浮动的，而不必属于某个特定的类。

5、相反，JShell使用代码片断“snippets”来提供上层执行环境。

6、与HTTP/2 API相似，JShell已经在独立的项目开发，以免在快速发展的时期影响主干构建的稳定性。JShell预计在2015年8月期间合并到主干。是的。之前怀疑Kulla项目是否会在Java9中准时发布，但现在已得到了官方确认。等到新版本发布的Java将会有称为jshell的新命令行工具，它会添加本地支持和以Java方式对REPL(交互式解释器)进行推广。意思是说，如果想只运行几行Java代码，不必把它包装进一个单独的工程或者方法。

再看看别人怎么说的。