Scala 在大數據處理方面有何優勢？
Spark 以及最近聽聞的 Flink，都是用 Scala 開發的。想知道，除了 JVM 能夠與 YARN 較好集成，函數式語言並發模型優秀之外，Scala 還有適用於此場景的天然優勢嗎？
謝邀。
我想大部分應用開發程序員，最關鍵是看有什麼類庫合適的方便特定領域的應用開發。就像ruby有rails做web開發，你可以去論證ruby優缺點，但實際上應用開發效率提升很大程度上依靠類庫。現在Spark是大數據領域的殺手級應用框架，BAT，我們現在幾個領域巨頭的客戶(有保密協議不方便透露)都全面使用Spark了，這個時候再談Scala適不適合大數據開發其實意義不大。因為大家比的不只是編程語言，而是構建在這個編程語言之上的類庫、社區和生態圈(包括文檔和數據、衍生類庫、商業技術支持、成熟產品等等)。
那麼反過來問，為什麼Spark會選擇Scala可能更有意義一點。Spark主創Matei在不同場合回答兩次這個問題，思考的點稍微不一樣，但重點是一樣的，很適合回答題主的問題。總結來說最主要有三點：
1. API能做得優雅; 這是框架設計師第一個要考慮的問題，框架的用戶是應用開發程序員，API是否優雅直接影響用戶體驗。
2. 能融合到Hadoop生態圈，要用JVM語言; Hadoop現在是大數據事實標準，Spark並不是要取代Hadoop，而是要完善Hadoop生態。JVM語言大部分可能會想到Java，但Java做出來的API太丑，或者想實現一個優雅的API太費勁。3. 速度要快; Scala是靜態編譯的，所以和JRuby,Groovy比起來速度會快很多，非常接近Java。關於Scala性能的問題，主要分兩種情況，
1. Scala的基準性能很接近Java，但確實沒有Java好。但很多任務的單次執行的，性能損失在毫秒級不是什麼問題；2. 在大數據計算次數很多的情況下，我們全部寫成命令式，而且還要考慮GC，JIT等基於JVM特性的優化。Scala很難是個很含糊的問題，關鍵是要看你想達到什麼目的。
我們培訓客戶做Spark開發，基本上一兩個星期就可以獨立工作了。當然師傅領進門，修行靠個人，一兩個星期能獨立工作不代表能馬上成為Scala或Spark專家。這裡回答主要針對大數據產品應用開發，不是大數據分析。大數據分析是個更泛的話題，包括大數據分析實驗和大數據分析產品等。實驗關心建模和快速試不同方式，產品關心穩定、可拓展性。大數據分析實驗首選R（SAS），python和Matlab, 通常只拿真實數據的一小部分，在一個性能很好的單機上試各種想法。Scala目前在大數據分析實驗上沒有太多優勢，不過現在有人在做R語言的Scala實現，可以無縫和Spark等大數據平台做銜接。當然現在也已經有SparkR了，可能用R和Spark做交互。
從語言設計上看
Actor 更適合的場景是做伺服器而不是分析計算
更適應高性能計算分析的模型是 APL 或者 J 這種 Array based 和 Combinator based 的語言, 天生就是數據並行的可以很簡單的用上 SIMD 指令做優化, 而在 Scala 想要利用上很多硬體加速特性都很難, 比 Python 難. 摩根斯坦利, 瑞士銀行和深圳證券交易所都用的一個超高性能時序資料庫 kdb+ 就是 APL 的親戚 K 語言寫的
從庫功能上看
而 R, Wolfram, Matlab, SASS, ... 在數據處理方面都有很多成熟的的工具和庫, 商業軟體安裝完就文檔齊全了, 開源的 R 的包管理系統是設計得最好的, 使用非常方便, packge.install 以後就能打開 demo 看. 而 Scala 呢? 好多 maven repo 里恐怕找不到多少高質量的數據分析處理工具, 用 Scala 新造的也寥寥無幾, 更不用說找到好用的庫以後的學習成本了
從招人上看
有些 Java 程序員可能會願意做 Scala, 但你得先培訓他 3 個月, 而且一般沒人指望市面上的 Java/Scala 程序員懂統計分析...這是一個很好玩的問題。從某種程度而言，Scala是不善於處理大數據的。作為一個函數式語言，必須在內存消耗和性能消耗兩者之間徘徊，而普通的命令式語言就並不會有這種問題。舉個例子，從數據結構來看，函數式語言要求不能修改原有結構（如果修改了，就不再吻合Immutable這一黃金定律），對於普通的鏈表（鏈表List在函數式語言中比數組Array更常見），每當你做一次操作，比如增加元素，刪減元素等等，照理說會生成一個新的鏈表，而非像過程式語言，直接通過指針對鏈表本身進行修改。為了讓操作速度達到與過程式語言類似或者相匹配，函數式語言的天才們發明了很多種不同方法，比如用結構分享（Structural Sharing）的技巧來應付鏈表，每次操作只記錄下那一項特殊操作，而不毀壞或者替代原有鏈表。對更高級一些的結構，比如哈希圖（HashMap），普通命令式語言用哈希列表（HashTable）這種簡單的方式來執行，但悲壯的函數式語言就必須依賴於2-3拇指樹（2-3 Finger Trie）一類的高端結構來達到相同的操作效率。但雖然速度達到了，佔用空間就成了一個問題。當命令式語言通過不停對同一個對象進行修改的同時，函數式語言卻不停的生成新內容。所以雖然函數式語言在理論上（無限空間與無限時間），數學上，都是更高檔次的語言，但在殘酷的現實面前，卻有時趕不上命令式語言。離散數學（Discrete Mathematics）中對時間的定義，只把Polynomial（多項式時間）和Exponential（指數級時間）分開，認為多項式時間在宇宙尺度上就已經足夠快了，但在爭分奪秒的實際程序中，多項式還完全不夠，線性（Linear）時間都嫌長。
為了讓函數式語言達到函數式語言編程者們心目中「神」一樣的地位，無數的東西被發明了出來，全世界第一個編譯器就是為Lisp這個函數式語言發明的，這個編譯器還自帶全世界第一個垃圾處理器（Garbage Collection），第一個實現遞歸函數（1960年麥卡錫在ACM上發表了論文：《遞迴函數的符號表達式以及由機器運算的方式，第一部》），發明了樹結構，動態類型（Dynamic Typing）——如今JavaScript, Python, Ruby, PHP等都非常依賴的動態類型，甚至還有條件語句。準確而言，現代編程幾乎都是由函數式語言奠定的基礎，所有命令式語言的高級功能，比如Java的反射，泛型，Java8的Lambda方程，Ruby的宏，全部都是函數式語言的饋贈。所以你想，當在你心目中，這個世界上最牛逼的東西居然內存和效率都拼不過比它挫的語言模式時，函數式的程序員能不惱怒嗎？這惱怒帶來了兩點：1. 死不認賬。函數式程序員絕對不會承認它們的語言效率或內存佔用 比命令式語言糟糕；2. 拚命改進，最終又為計算機科學做出了無數貢獻。
所以說，如果Scala在內存和效率上似乎都不佔太多優勢（當然，越熟悉Scala，函數式編程能力越強的人，這兩點都將不是問題，通過聰明的設計演算法，選用正確的數據結構，速度和高效內存利用肯定和命令式語言的程序近似），為什麼人們會選擇Scala作為大數據的語言？這裡涉及到幾個原因：
1. Scala 具有很完整又很強大的集合處理能力，準確而言是現代語言中最有優勢的一個。Scala擁有龐大而完整的集合類庫，比如Set, List, Vector, Tuple, Map，而有效的泛型能讓你肆意組合這些類型得到新的類型，比如像這樣的類別：List[Map[String, (Int, List[String)]]]，這是一個鏈表，每個鏈表元素是一個映射，映射中用字元做key，另一個Tuple元組做value（值），這個元組的第一個元素是整數，第二個元素是一個鏈表，這樣的集合在其他語言中不是不可以做到，但很難，想想在Java中定義個三元數組有多麼令人噁心，並且讓人難以直觀理解：ArrayList&
2. 物以類聚，人以群分。函數式語言以吸引天才聞名，一直作為「學院派」語言延存至今，麻省理工至今還有一門課專門教Lisp，斯坦福每學期邀請業界的Haskell高手前去講課。四十年前，最火的研究項目是人工智慧，很多聰明人進入了這個領域，所以Lisp成為了人工智慧的程序語言首選。如今最火的領域就是大數據，以及數據處理，很多聰明人進入這個領域，他們都在一段時間內被Scala吸引，所以自然就選擇Scala作為他們的語言，這和Scala本身適不適合大數據其實並沒有太大關係，就跟函數式語言本不擅長從事IO開發（一句著名的諺語說，IO就像一個恐怖的黑盒子，總有一種方法讓函數式的美妙失靈），但還有人用Haskell開發伺服器一樣，對於這些天才而言，你給一袋麵粉他們都能造個原子彈，讓Scala作為大數據開發語言，完全不是問題。
3. 文章最前面我批評了函數式語言或者Scala的速度問題。但這其實不是問題。當C語言出來的時候，編譯器水平並不高，無數寫彙編的程序員紛紛斥責C語言速度緩慢，說C語言程序員不是真程序員。當年Java出來時，編譯後的程序運行速度也非常慢，一直到Java1.3這個問題才有所好轉。實際上，彙編語言的速度 &> C語言速度 &> Java速度。從這條線可以很明顯的看出，越高級的語言速度越慢，Scala作為明顯的比Java在進化樹上爬的更高的語言，似乎有效率損失或內存管理問題是完全可以被解釋的。並且在目前的所有測評中，Scala的速度並不比java慢，內存佔用也大致持平。
最後繞回題主的問題上。首先，Flink不是由Scala寫的，Flink是由Java寫的，只是提供了Scala介面（API）而已。Apache Spark確實是由Scala寫的，但Spark最先是由加州伯克利實驗室公布的，所以符合我所說的第二點。Scala的威力現在才要先開始顯現出來，一堆新的大學實驗室開始逐步普及Scala，很多高級庫已經開始用Scala寫就了，比如經典概率模型建立庫Figaro是由Scala寫的，由前哈佛大學工程與應用科學部門的副教授Avi Pfeffer發布，貝葉斯圖形模型建立庫Factorie由馬塞諸塞大學（UMass）的Andrew McCullen發布，高效數學計算庫Breeze由加州伯克利的David Hall（此人是斯坦福大學本科生）發布。可以看出，Scala必定會成為新一輪高端庫的主導語言。
同時，作為普通的大數據處理，誠然Akka Actor模型並不適合直接的文檔處理，但最新的Akka-Stream完全可以勝任，Akka-Stream預載入了叫做Backpressure（向後壓力）的機能，能有效防止數據過快流入產生的內存過載問題，可以專門來處理數據量大的文檔（我用它來處理過約4000萬行的文檔）。
（這段被諾鐵和qiqiqi提醒後修改）Spark也只是用akka做節點控制，數據傳輸還是實驗室的大神們自己寫的。
謝邀
回答你的問題之前，我查了下過去的問題，發現這個回答很全面。觀點整理自網友 @紫杉 版權歸他所有。
著作權歸作者所有。
商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。作者：紫杉
鏈接：Scala 是一門怎樣的語言，具有哪些優缺點？ - 紫杉的回答來源：知乎首先，Scala不把程序員當傻子。當馬丁·奧德斯基宣布Scala 2.12（http://www.scala-lang.org/news/roadmap-next）將要簡化語法，推出Scala "Don Giovanni"項目的時候，在視頻中說的很清楚：「Scala現在是為聰明人創造的，以後也是為聰明人服務的。」所以不同於Python讓程序員用一種方法做所有事情，Scala提供一整套工具，讓程序員自由選擇，無論是mutable數據結構，immutable數據結構，並行（parallel）數據結構。然後在這些選擇中，Scala再針對他們進行演算法層面的特殊優化。Scala相信程序員的聰明才智，讓程序員自行選擇合適的結構，以針對變化萬千的任務需求，這點是Scala做得極好的地方。
再者，有人會說immutable數據結構佔用內存，或者速度很慢。這是真的，但這不是Scala的錯，而是這些結構就是這樣定義的。可以看看這個視頻：Parleys.com | Courses 這裡講的是Scala集合的運行速度，是一個來自Goldman Sachs的程序員講他們為Java寫的集合庫（GSCollection）速度和內存消耗，但同時比較了gs-collection（goldmansachs/gs-collections · GitHub），Java，和Scala庫的速度。最後Scala的可變集合mutable原生庫完爆Java，和gs-collection基本持平。
Scala的第二個優勢，相較於Java而言，則是相信程序員的優化能力。在Scala with Style講話中（https://www.youtube.com/watch?v=kkTFx3-duc8），馬丁·奧德斯基說：「很多程序員會告訴我，他們一般會重構他們的Scala代碼兩三次，甚至三四次。」這聽起來似乎非常的沒有效率，但Scala就是這樣的語言，每一次重構，代碼的性能或者是可讀性都會有極高的提升。
之前就有人提到過，Scala新手和老手寫出來的代碼完全會呈現兩種不同的風格，甚至新人根本不能讀懂有經驗的Scala程序員所寫的代碼，有人於是戲稱：「太好了，這樣的話我們部門的實習生就不能亂碰我寫的代碼啦！」但其實不僅風格不同，執行效率差距也一定是巨大的。Scala提供一整套工具，但是要明白什麼時候用拿一種工具，哪些演算法能夠隨意調用，哪些演算法不能，這一定要依靠經驗、研究和學習以及對源代碼的理解才能得知。最簡單的例子，Scala的foreach()方法是高度優化過了的（尤其針對Range結構和Vector結構），但是fold()就不一定了。或者當受到誘惑想用zipWithIndex()的時候，一定要明白這是兩次循環，最好改用Vector(...).indices.foreach()的方法，或者用.view來推遲執行。
像這樣的地方還有很多。所以在這個層面上來講，簡直和C++非常的相似。從另外一個層面來講，不僅僅是要理解語言層面的優化，Scala作為一個社區而言，是非常追求運行速度的。Ruby社區就完全不同了，Ruby曾經是推特的主要語言。推特的團隊找到了Ruby團隊，說，你們能不能讓Ruby運行的快一點，我們有這個這個和這個建議。Ruby直接把這些建議拒絕了，因為它們會增加語言複雜度，讓Ruby不能繼續做一個「fun」（好玩）的語言。而Python直接就立志做一個「Simple」（簡單）的語言了。於是推特只好將後台換做Scala和Java的結合。有一位在推特工作的知乎友人在我的一個回答下留言說推特換用Scala後，TypeSafe（Scala的母公司）還送去了一個蛋糕。
為了追求速度，Scala社區是絕對不會管所謂的「簡單」或者是「好玩」，怎樣有效率就怎樣弄。與其專註於JVM的改進，Scala社區大部分在編譯器上下功夫，比如很著名的Miniboxing（Miniboxing），這是一個編譯器增進器。Miniboxing做的是什麼呢？只做一件事：防止auto-boxing和auto-unboxing。所有的泛型，尤其是原生類泛型（Primitive Types），諸如Int、Double等等，在進行各種操作的時候會自動取出和裝回它們所屬的類中去——這個我解釋的不太好，但是可以看這裡（Java 自動裝箱與拆箱(Autoboxing and unboxing)）。
Miniboxing這樣的插件可以讓所有的原生類泛型再也不用自動裝拆箱，從而將Scala的運行速度提升1.5倍到22倍（Miniboxing）。當然這樣的東西可不是白來的，這是馬丁·奧德斯基的PhD博士學生做的一個研究項目，然後為OOPSLA寫了一篇論文（Miniboxing），所以怪不得這玩意Scala可以有，但其他語言想要有都沒有。
另一個Scala的很大優勢就是所謂的Macro——宏。宏本身作為元編程而言，其實和運行速度是沒有什麼太大關係的，反而，因為對反射（Reflect）的利用，可能會影響到速度。但Scala社區對宏的理解顯然和最初的設計理念有偏差。因為Scala本身是沒有傳統意義的循環的（for-loop），所以很多時候循環必須利用while或者foreach。但是部分追求效率的Scala程序員們利用宏為Scala寫了一個傳統循環，叫做cfor，被收錄在Spire（non/spire · GitHub）數學計算庫中。cfor的寫法如下：
import spire.syntax.cfor._
// print numbers 1 through 10
cfor(0)(_ &< 10, _ + 1) { i =&>
println(i)
}
而這玩意運行效率如何呢？https://www.chrisstucchio.com/blog/2014/learning_spire_cfor.html 文章中做了一次測評，將cfor和zip寫的一個演算法作比較——在公布結果之前，我想說的是，zip並不是一個高度優化的方法，所以本身就慢很多，cfor用了26.1毫秒運行，zip方法用了7.4 秒運行，這幾乎是284倍的速度差距。
通過這兩點，Scala的一個優勢就很明顯了——多樣化。當需要寫簡單的代碼，像Python一樣當腳本語言使用時，Scala提供大量的原生方法和數據結構，可以很輕鬆的寫出比較複雜的操作。但當需要速度的時候，又可以通過重構來獲取數十倍或者上百倍的速度提升。通過Miniboxing一類的編譯器增強器，Scala在某些操作的速度是必定超過Java的。
Scala的第二個優勢就是——一幫勤勞勇敢的PhD博士生。二十一世紀的程序語言和二十世紀的程序語言已經不能比擬了。那個年代的普通人（甚至是學生）還能任意發明一下語言，稍微把編譯器優化幾次就能上得了廳堂（比如那一大堆Lisp方言），到了這個年代，編譯技術已經達到了很複雜的程度（虛擬機技術也是如此），優化和語義理解，程序語言的定義與延展，再也不是隨便任何人都能搞定的工作了。作為編程語言方面的教授，馬丁·奧德斯基不斷的將最前沿的學術界成果轉移到Scala這個語言中，還讓他的博士學生髮展出新的，讓語言運行得更快的方法，這些都是其他語言，尤其是Python、Ruby、甚至是Go都沒有的優勢。
當然，說了這麼多，總會有人說了，Scala如果像C++一樣難，又追求速度的話，為什麼不直接去學C++，原因很簡單——現在有很多在JVM上面寫成的軟體啊！大家又不是Haskell程序員，壓根不打算一切自己寫吶。
算是借花獻佛，關注大數據歡迎加我微信 idacker學了一個星期 寫了一個 spark+scala的程序 跑的 很順利
下面是個人查看一些資料的總結：
現在很多數據處理用的是python或R, 那麼現在我們對比下scala和python在大數據處理方面的優劣：
- scala與python對比
- scala 相對於c語言慢2-3倍，但是python一般比c語言慢50倍。（只是大概，實際會情況不同）
- scala 缺少python那樣豐富的數據處理,機器學習的包（Numpy, scipy, matplotlib，panda, scikit-learn)。當然scala也有自己的包(MLibBreeze, ScalaLab and BIDMach),只不過現對於python不夠成熟，豐富
- python不是為大數據設計的，scala可以說是大數據導向的, 例MLlib相對於scikit-learn的演算法數目較少，但是它是天生適合大數據並行計算的。
- scala,python都是面向對象語言。scala也支持函數式(functional programming)編程,而pyton不支持，python的編程風格也因人而異
- 更多細節對比Scala vs. Python comparison
下面單獨談談scala的一些優勢：
- scala的優勢
- 基於JVM與JAVA的生態系統, 可方便利用現有的基於JVM的成熟應用如：HADOOP,Flink,Kafka. 另外Spark也是基於scala寫的
- 強大的並發性（Concurrency）
- 支持函數式編程
- 更好支持分散式系統
以前用python比較多，初學SPARK,也跟著學了scala，文中觀點基本參考下面的文獻，後面學習如果有了新的心得，繼續補充
參考：
https://www.hakkalabs.co/articles/three-reasons-data-eng-learn-scalaWhy we love Scala at Coursera
Scala vs Python
轉自自己博客大數據工程師為什麼要學習scala
scala在大數據處理方面的優勢是spark
著作權歸作者所有。
商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
作者：李國冬
鏈接：為什麼選擇Scala，它在大數據處理方面有何優勢？ - 琴弦上、漫步 - CSDN博客
來源：CSDN博客
近年來，關於大數據討論已然是熱火朝天，雖不說是家喻戶曉，那至少對於業界來說也是引起了軒然大波。作為學生黨的我，最近也在研究關於大數據的東東。作為一個技術迷，總是會想嘗試一些新鮮的東西。前一段時間學習了Hadoop之後，又想看看Spark是什麼東東。那麼在這裡有必要八卦一下Spark了。
Spark是發源於美國加州大學伯克利分校AMPLab的集群計算平台。它立足於內存計算，從多迭代批量處理出發，兼收並蓄數據倉庫、流處理和圖計算等多種計算範式，是罕見的全能選手。就大數據集而言，對典型的迭代機器 學習、即席查詢（ad-hoc query）、圖計算等應用，Spark版本比基於MapReduce、Hive和Pregel的實現快上十倍到百倍。其中內存計算、數據本地性 （locality）和傳輸優化、調度優化等該居首功，也與設計伊始即秉持的輕量理念不無關係。那麼，天下武功，唯快不破，看到這裡當然是以一種很激動的心情想要去學習它了。那麼問題也來了，通過百度等各種小道消息打聽到，Spark是採用Scala語言設計的，要想學好Spark，Scala這一關必須是要過的，並且像Twitter、Linkedin等這些公司都在用。於是，還能怎麼辦，學唄。。。
於是，就愉快的開始了Scala之旅，嘿嘿，然後就沒有然後了。看了Scala前面的內容還好，看到後面真的是想吐血了，簡直是受不了這種編寫方式，不僅編譯速度慢，而且編寫代碼過於隨意、靈活，完全無法駕馭。於是，進行了內心的各種掙扎，並且還被實驗室的幾個研究生學長踏雪了一番，我也不能坐以待斃了，因此，我再一次選擇了強大的網路，打開搜索引擎，然後查看各種八卦與新聞。以下是搜索到的各種觀點。我想大部分應用開發程序員，最關鍵是看有什麼類庫合適的方便特定領域的應用開發。就像ruby有rails做web開發，你可以去論證ruby優缺點，但實際上應用開發效率提升很大程度上依靠類庫。 現在Spark是大數據領域的殺手級應用框架，BAT，我們現在幾個領域巨頭的客戶(有保密協議不方便透露)都全面使用Spark了，這個時候再談Scala適不適合大數據開發其實意義不大。因為大家比的不只是編程語言，而是構建在這個編程語言之上的類庫、社區和生態圈(包括文檔和數據、衍生類庫、商業技術支持、成熟產品等等)。 那麼反過來問，為什麼Spark會選擇Scala可能更有意義一點。Spark主創Matei在不同場合回答兩次這個問題，思考的點稍微不一樣，但重點是一樣的，很適合回答題主的問題。總結來說最主要有三點： 1. API能做得優雅; 這是框架設計師第一個要考慮的問題，框架的用戶是應用開發程序員，API是否優雅直接影響用戶體驗。 2. 能融合到Hadoop生態圈，要用JVM語言; Hadoop現在是大數據事實標準，Spark並不是要取代Hadoop，而是要完善Hadoop生態。JVM語言大部分可能會想到Java，但Java做出來的API太丑，或者想實現一個優雅的API太費勁。 3. 速度要快; Scala是靜態編譯的，所以和JRuby,Groovy比起來速度會快很多，非常接近Java。 關於Scala性能的問題，主要分兩種情況， 1. Scala的基準性能很接近Java，但確實沒有Java好。但很多任務的單次執行的，性能損失在毫秒級不是什麼問題； 2. 在大數據計算次數很多的情況下，我們全部寫成命令式，而且還要考慮GC，JIT等基於JVM特性的優化。 Scala很難是個很含糊的問題，關鍵是要看你想達到什麼目的。 我們培訓客戶做Spark開發，基本上一兩個星期就可以獨立工作了。 當然師傅領進門，修行靠個人，一兩個星期能獨立工作不代表能馬上成為Scala或Spark專家。 這裡回答主要針對大數據產品應用開發，不是大數據分析。大數據分析是個更泛的話題，包括大數據分析實驗和大數據分析產品等。實驗關心建模和快速試不同方式，產品關心穩定、可拓展性。大數據分析實驗首選R（SAS），python和Matlab, 通常只拿真實數據的一小部分，在一個性能很好的單機上試各種想法。Scala目前在大數據分析實驗上沒有太多優勢，不過現在有人在做R語言的Scala實現，可以無縫和Spark等大數據平台做銜接。當然現在也已經有SparkR了，可能用R和Spark做交互。Scala是一門現代的多範式編程語言，設計初衷是要集成面向對象編程和函數式編程的各種特性。Scala允許用戶使用命令和函數範式編寫代碼。Scala運行在Java虛擬機之上，可以直接調用Java類庫。對於新手來說，Scala相對比較複雜，其看起來靈活的語法並不容易掌握，但是對於熟悉Scala的用戶來說，Scala是一把利器，它提供了許多獨特的語言機制，可以以庫的形式輕易無縫添加新的語言結構。近日，Spotify的軟體工程師Neville Li發表了一篇題為《數據工程師應該學習Scala的三個理由》的文章，他認為現在的編程語言種類非常多，每種語言都各有優缺點，並且它們的適用的場景也不同，比如Scala就非常適合用於數據處理和機器學習。 在大數據和機器學習領域，很多開發者都有Python/R/Matlab語言的背景，相比與Java或者C++，Scala的語法更容易掌握。從以往的經驗來看，只要掌握基本的集合API以及lambda，一個沒有經驗的新員工就可以快速上手處理數據。像Breeze、ScalaLab和BIDMach這樣的類庫都通過操作符重寫模仿了一些流行工具的語法以及其它的一些語法糖，簡單並且容易使用。另外，Scala的性能比傳統的Python或者R語言更好。 由於Scala運行於Java平台（Java虛擬機），併兼容現有的Java程序，所以Scala可以和大數據相關的基於JVM的系統很好的集成，比如基於JVM類庫的框架Scalding（Cascading）、Summingbird（Scalding和Storm）、Scrunch（Crunch）、Flink（Java編寫並有Scala的API），本身使用Scale開發的系統Spark、Kafka。另外，很多數據存儲解決方案都支持JVM語言，比如Cassandra、HBase、Voldemort和Datomic。 函數編程範式更適合用於Map/Reduce和大數據模型，它摒棄了數據與狀態的計算模型，著眼於函數本身，而非執行的過程的數據和狀態的處理。函數範式邏輯清晰、簡單，非常適合用於處理基於不變數據的批量處理工作，這些工作基本都是通過map和reduce操作轉換數據後，生成新的數據副本，然後再進行處理。而大多數的Scala數據框架都能夠把Scala數據集合API和抽象數據類型相統一，比如Scalding中的TypedPipe與Spark中的RDD都有相同的方法，包括map、flatMap、filter、reduce、fold和groupBy，這樣使用Scala來處理就更為方便。開發者只需要學習標準集合就可以迅速上手其它工具包。另外，很多的類庫都參考了範疇論中的一些設計，它們通過使用semigroup、monoid、group標識來保證分散式操作的正確性。
1,處理集合很方便,節約代碼.2,能當腳本語言用.
能來歪下樓嗎？
對於純應用來說,Scala比起python對於正常程序員（非java背景）的優勢在哪些方面呢？推薦閱讀：
※如何看待類似Spark亞太研究院的王家林打著開源旗號賺錢的行為？
※如何評價spark的機器學習框架 和 tensorflow的機器學習系統？
※如何解釋spark mllib中ALS演算法的原理？
※關於Spark有哪些大牛們的博客?
※有什麼關於 Spark 的書推薦？