到底該使用哪一種大數(shù)據(jù)編程語言：R、Python、Scala和Java

說到處理大規(guī)模數(shù)據(jù)，R、Python、Scala和Java基本上都能滿足你的要求。

你有一個大數(shù)據(jù)項目，你知道問題領(lǐng)域（problem domain），也知道使用什么基礎(chǔ)設(shè)施，甚至可能已決定使用哪種框架來處理所有這些數(shù)據(jù)，但是有一個決定遲遲未能做出：我該選擇哪種語言？（或者可能更有針對性的問題是，我該迫使我的所有開發(fā)人員和數(shù)據(jù)科學(xué)家非要用哪種語言？）這個問題不會推遲太久，遲早要定奪。

當然，沒有什么阻止得了你使用其他機制（比如XSLT轉(zhuǎn)換）來處理大數(shù)據(jù)工作。但通常來說，如今大數(shù)據(jù)方面有三種語言可以選擇：R、Python和Scala，外加一直以來屹立于企業(yè)界的Java。那么，你該選擇哪種語言？為何要選擇它，或者說何時選擇它？

下面簡要介紹了每種語言，幫助你做出合理的決定。

R

R經(jīng)常被稱為是“統(tǒng)計人員為統(tǒng)計人員開發(fā)的一種語言”。如果你需要深奧的統(tǒng)計模型用于計算，可能會在CRAN上找到它――你知道，CRAN叫綜合R檔案網(wǎng)絡(luò)（Comprehensive R Archive Network）并非無緣無故。說到用于分析和標繪，沒有什么比得過ggplot2。而如果你想利用比你機器提供的功能還強大的功能，那可以使用SparkR綁定，在R上運行Spark。

然而，如果你不是數(shù)據(jù)科學(xué)家，之前也沒有用過Matlab、SAS或OCTAVE，可能需要一番調(diào)整，才能使用R來高效地處理。雖然R很適合分析數(shù)據(jù)，但是就一般用途而言不太擅長。你可以用R構(gòu)建模型，但是你需要考慮將模型轉(zhuǎn)換成Scala或Python，才能用于生產(chǎn)環(huán)境，你不太可能使用這種語言編寫一種集群控制系統(tǒng)（運氣好的話，你可以對它進行調(diào)試）。

Python

如果你的數(shù)據(jù)科學(xué)家不使用R，他們可能就會徹底了解Python。十多年來，Python在學(xué)術(shù)界當中一直很流行，尤其是在自然語言處理（NLP）等領(lǐng)域。因而，如果你有一個需要NLP處理的項目，就會面臨數(shù)量多得讓人眼花繚亂的選擇，包括經(jīng)典的NTLK、使用GenSim的主題建模，或者超快、準確的spaCy。同樣，說到神經(jīng)網(wǎng)絡(luò)，Python同樣游刃有余，有Theano和Tensorflow；隨后還有面向機器學(xué)習(xí)的scikit-learn，以及面向數(shù)據(jù)分析的NumPy和Pandas。

還有Juypter/iPython――這種基于Web的筆記本服務(wù)器框架讓你可以使用一種可共享的日志格式，將代碼、圖形以及幾乎任何對象混合起來。這一直是Python的殺手級功能之一，不過這年頭，這個概念證明大有用途，以至于出現(xiàn)在了奉行讀?。x?。敵觯h(huán)（REPL）概念的幾乎所有語言上，包括Scala和R。

Python往往在大數(shù)據(jù)處理框架中得到支持，但與此同時，它往往又不是“一等公民”。比如說，Spark中的新功能幾乎總是出現(xiàn)在Scala/Java綁定的首位，可能需要用PySpark編寫面向那些更新版的幾個次要版本（對Spark Streaming/MLLib方面的開發(fā)工具而言尤為如此）。

與R相反，Python是一種傳統(tǒng)的面向?qū)ο笳Z言，所以大多數(shù)開發(fā)人員用起來會相當?shù)眯膽?yīng)手，而初次接觸R或Scala會讓人心生畏懼。一個小問題就是你的代碼中需要留出正確的空白處。這將人員分成兩大陣營，一派覺得“這非常有助于確保可讀性”，另一派則認為，2016年，我們應(yīng)該不需要就因為一行代碼有個字符不在適當?shù)奈恢?，就要迫使解釋器讓程序運行起來。

Scala

現(xiàn)在說說Scala：在本文介紹的四種語言中，Scala是最輕松的語言，因為大家都欣賞其類型系統(tǒng)。Scala在JVM上運行，基本上成功地結(jié)合了函數(shù)范式和面向?qū)ο蠓妒?，目前它在金融界和需要處理海量?shù)據(jù)的公司企業(yè)中取得了巨大進展，常常采用一種大規(guī)模分布式方式來處理（比如Twitter和LinkedIn）。它還是驅(qū)動Spark和Kafka的一種語言。

由于Scala在JVM里面運行，它可以立即隨意訪問Java生態(tài)系統(tǒng)，不過它也有一系列廣泛的“原生”庫，用于處理大規(guī)模數(shù)據(jù)（尤其是Twitter的Algebird和Summingbird）。它還包括一個使用非常方便的REPL，用于交互式開發(fā)和分析，就像使用Python和R那樣。

我個人非常喜歡Scala，因為它包括許多實用的編程功能，比如模式匹配，而且被認為比標準的Java簡潔得多。然而，用Scala來開發(fā)不止一種方法，這種語言將此作為一項特色來宣傳。這是好事！不過考慮到它擁有圖靈完備（Turing-complete）的類型系統(tǒng)和各種彎彎曲曲的運算符（“/:”代表foldLeft，“:\”代表foldRight），很容易打開Scala文件，以為你看到的是某段討厭的Perl代碼。這就需要在編寫Scala時遵循一套好的實踐和準則（Databricks的就很合理）。

另一個缺點是，Scala編譯器運行起來有點慢，以至于讓人想起以前“編譯！”的日子。不過，它有REPL、支持大數(shù)據(jù)，還有采用Jupyter和Zeppelin這一形式的基于Web的筆記本框架，所以我覺得它的許多小問題還是情有可原。

Java

最終，總是少不了Java――這種語言沒人愛，被遺棄，歸一家只有通過起訴谷歌才有錢可賺時才似乎關(guān)心它的公司（注：Oracle）所有，完全不時髦。只有企業(yè)界的無人機才使用Java！不過，Java可能很適合你的大數(shù)據(jù)項目。想一想Hadoop MapReduce，它用Java編寫。HDFS呢？也用Java來編寫。連Storm、Kafka和Spark都可以在JVM上運行（使用Clojure和Scala），這意味著Java是這些項目中的“一等公民”。另外還有像Google Cloud Dataflow（現(xiàn)在是Apache Beam）這些新技術(shù)，直到最近它們還只支持Java。

Java也許不是搖滾明星般備受喜愛的首選語言。但是由于研發(fā)人員在竭力理清Node.js應(yīng)用程序中的一套回調(diào)，使用Java讓你可以訪問一個龐大的生態(tài)系統(tǒng)（包括分析器、調(diào)試器、監(jiān)控工具以及確保企業(yè)安全和互操作性的庫），以及除此之外的更多內(nèi)容，大多數(shù)內(nèi)容在過去二十年已久經(jīng)考驗（很遺憾，Java今年迎來21歲，我們都老矣）。

炮轟Java的一個主要理由是，非常繁瑣冗長，而且缺少交互式開發(fā)所需的REPL（R、Python和Scala都有）。我見過10行基于Scala的Spark代碼迅速變成用Java編寫的變態(tài)的200行代碼，還有龐大的類型語句，它們占據(jù)了屏幕的大部分空間。然而，Java 8中新的Lambda支持功能對于改善這種情況大有幫助。Java從來不會像Scala那么緊湊，但是Java 8確確實實使得用Java進行開發(fā)不那么痛苦。

至于REPL？好吧，目前還沒有。明年推出的Java 9會包括JShell，有望滿足你的所有REPL要求。

哪種語言勝出？

你該使用哪種語言用于大數(shù)據(jù)項目？恐怕這還得“視情況而定”。如果你對晦澀的統(tǒng)計運算進行繁重的數(shù)據(jù)分析工作，那么你不青睞R才怪。如果你跨GPU進行NLP或密集的神經(jīng)網(wǎng)絡(luò)處理，那么Python是很好的選擇。如果想要一種加固的、面向生產(chǎn)環(huán)境的數(shù)據(jù)流解決方案，又擁有所有重要的操作工具，Java或Scala絕對是出色的選擇。

當然，不一定非此即彼。比如說，如果使用Spark，你可以借助靜態(tài)數(shù)據(jù)，使用R或Python來訓(xùn)練模型和機器學(xué)習(xí)管道（pipeline），然后對該管道進行序列化處理，倒出到存儲系統(tǒng)，那里它可以供你的生產(chǎn)Scala Spark Streaming應(yīng)用程序使用。雖然你不應(yīng)該過分迷戀某一種語言（不然你的團隊很快會產(chǎn)生語言疲勞），使用一套發(fā)揮各自所長的異構(gòu)語言也許會給大數(shù)據(jù)項目帶來成效。