如何選擇大資料的程式設計語言

標籤：大資料   語言   編程   

前言

有一個大資料項目，你知道問題領域(problem domain)，也知道使用什麼基礎設施，甚至可能已決定使用哪種架構來處理所有這些資料，但是有一個決定遲遲未能做出：我該選擇哪種語言?(或者可能更有針對性的問題是，我該迫使我的所有開發人員和資料科學家非要用哪種語言?)這個問題不會延遲太久，遲早要定奪。

分享之前我還是要推薦下我自己建立的大資料學習交流Qun531629188無論是大牛還是想轉行想學習的大學生小編我都挺歡迎，今天的已經資訊上傳到群檔案，不定期分享乾貨，包括我自己整理的一份最新的適合2018年學習的大資料教程，歡迎初學和進階中的小夥伴。

當然，沒有什麼阻止得了你使用其他機制(比如XSLT轉換)來處理大資料工作。但通常來說，如今大資料方面有三種語言可以選擇：R、Python和Scala，外加一直以來屹立於企業界的Java。那麼，你該選擇哪種語言?為何要選擇它，或者說何時選擇它?

　　下面簡要介紹了每種語言，協助你做出旁徵博引的決定。

　R

　　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

　　最終，總是少不了Java――這種語言沒人愛，被遺棄，歸一家只有通過起訴Google才有錢可賺時才似乎關心它的公司(註：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要求。

　哪種語言勝出?

　　你該使用哪種語言用於大資料項目?恐怕這還得“視情況而定”。如果你對晦澀的統計運算進行繁重的資料分析工作，那麼你不青睞R才怪。如果你跨GPU進行NLP或密集的神經網路處理，那麼Python是很好的選擇。如果想要一種加固的、面向生產環境的資料流解決方案，又擁有所有重要的操作工具，Java或Scala絕對是出色的選擇。

　　當然，不一定非此即彼。比如說，如果使用Spark，你可以藉助待用資料，使用R或Python來訓練模型和機器學習管道(pipeline)，然後對該管道進行序列化處理，倒出到儲存系統，那裡它可以供你的生產Scala Spark Streaming應用程式使用。雖然你不應該過分迷戀某一種語言(不然你的團隊很快會產生語言疲勞)，使用一套發揮各自所長的異構語言也許會給大資料項目帶來成效。

有一句話叫做三人行必有我師，其實做為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的大資料交流學習群531629188不管你是小白還是大牛歡迎入駐，正在求職的也可以加入，大家一起交流學習，話糙理不糙，互相學習，共同進步，一起加油吧。

如何選擇大資料的程式設計語言