解讀2015之Spark篇：新生態(tài)系統(tǒng)的形成
http://www.infoq.com/cn/articles/2015-Review-Spark
編者按：2015年匿值，整個IT技術(shù)領(lǐng)域發(fā)生了許多深刻而又復(fù)雜的變化烹卒，InfoQ策劃了“解讀2015”年終技術(shù)盤點系列文章，希望能夠給讀者清晰地梳理出技術(shù)領(lǐng)域在這一年的發(fā)展變化智嚷，回顧過去茄猫，繼續(xù)前行识椰。本文是大數(shù)據(jù)解讀2015之Spark篇赠潦，明略數(shù)據(jù)的梁堰波為大家解讀Spark在2015年的快速發(fā)展，后續(xù)InfoQ會有更多關(guān)于大數(shù)據(jù)生態(tài)技術(shù)的總結(jié)招驴。
2015年的Spark社區(qū)的進展實在是太快了篙程，我發(fā)現(xiàn)1月份出版的一本參考書到現(xiàn)在已經(jīng)有很多內(nèi)容是過時的了。社區(qū)大踏步前行的同時别厘，用戶和應(yīng)用案例也越來越多虱饿，應(yīng)用行業(yè)越來越廣泛。到年底了我們來梳理下Spark這快速發(fā)展的一年触趴。
先從全局有個認識郭厌，我嘗試用三句話來概括下Spark最主要的變化，然后在接下來的篇幅選取一些重點內(nèi)容展開雕蔽。
相關(guān)廠商內(nèi)容
攜程的推薦及智能化算法及架構(gòu)體系實踐
Autodesk基于Spark自建大數(shù)據(jù)平臺的實踐經(jīng)驗
大數(shù)據(jù)與電商四大核心要素
阿里巴巴數(shù)據(jù)研發(fā)體系的建立和管理之道
蘇寧云商數(shù)據(jù)平臺實時化實踐
Spark生態(tài)系統(tǒng)漸趨完善。支持的外部數(shù)據(jù)源越來越多华弓，支持的算子越來越豐富食零，自身的機器學(xué)習(xí)算法越來越完善。同時在API支持上也有很大進步寂屏，新增加的R語言API使得Spark能被更多的行業(yè)所接受贰谣。
Spark的應(yīng)用范圍和規(guī)模在不斷擴大娜搂。在互聯(lián)網(wǎng)和電子商務(wù)行業(yè)的應(yīng)用不斷增多、規(guī)模不斷擴大的基礎(chǔ)上吱抚，越來越多的金融百宇、電信、制造業(yè)等傳統(tǒng)行業(yè)也開始使用Spark解決他們遇到的大數(shù)據(jù)問題秘豹。
Spark自身的性能和穩(wěn)定性在不斷提升携御。Tungsten項目讓Spark跑的越來越快，越來越多的代碼貢獻者和使用經(jīng)驗讓Spark越來越穩(wěn)定既绕。相信明年發(fā)布的Spark 2.0將是一個里程碑式的版本啄刹。
轉(zhuǎn)向以DataFrame為核心
在傳統(tǒng)意義上Spark的核心是RDD和RDD之上的各種transformation和action，也就是各種算子凄贩，RDD可以認為是分布式的Java對象的集合誓军。2013年推出了DataFrame，可以看做分布式的Row對象的集合怎炊。DataFrame除了提供了比RDD更豐富的算子以外谭企，更重要的特點就是有執(zhí)行計劃的優(yōu)化器，這樣用戶只需要指定自己的操作邏輯评肆，DataFrame的優(yōu)化器會幫助用戶選擇一條效率最優(yōu)的執(zhí)行路徑债查。同時Tungsten優(yōu)化（下一章重點講）使得DataFrame的存儲和計算效率比RDD高很多。Spark的機器學(xué)習(xí)項目MLlib的ML pipeline就是完全基于DataFrame的瓜挽，而且未來Streaming也會以DataFrame為核心盹廷。
（圖片引自Databricks）
Tungsten讓Spark越來越快
那么為什么DataFrame比RDD在存儲和計算上的效率更高呢？這主要得益于Tungsten項目久橙。Tungsten做的優(yōu)化概括起來說就是由Spark自己來管理內(nèi)存而不是使用JVM俄占，這樣可以避免JVM GC帶來的性能損失；內(nèi)存中的Java對象被存儲成Spark自己的二進制格式淆衷，更加緊湊缸榄，節(jié)省內(nèi)存空間，而且能更好的估計數(shù)據(jù)量大小和內(nèi)存使用情況祝拯；計算直接發(fā)生在二進制格式上甚带，省去了序列化和反序列化時間。
像傳統(tǒng)的Hadoop/Hive系統(tǒng)佳头，磁盤IO是一個很大的瓶頸鹰贵。而對于像Spark這樣的計算框架，主要的瓶頸在于CPU和內(nèi)存康嘉。下面看看Tungsten主要做了哪些優(yōu)化：
1碉输，基于JVM的語言帶來的問題：GC問題和Java對象的內(nèi)存開銷。例如一個字符串”abcd”理論上只有4個bytes亭珍，但是用Java String類型來存儲卻需要48個bytes敷钾。Spark的改進就是自己管理內(nèi)存枝哄，不用JVM來管理了，使用的工具是sun.misc.Unsafe闰非。DataFrame的每一行就是一個UnsafeRow膘格，這塊內(nèi)存存的啥東西只有Spark自己能讀懂。有了這種特有的二進制存儲格式后财松，DataFrame的算子直接操控二進制數(shù)據(jù)瘪贱，同時又省去了很多序列化和反序列化的開銷。
2辆毡，Cache-aware的計算〔饲兀現(xiàn)在Spark已經(jīng)是內(nèi)存計算引擎了，但是能不能更進一步呢舶掖，能不能更好的利用CPU的L1/L2/L3緩存的優(yōu)勢呢球昨，因為CPU緩存的訪問效率更高。這個優(yōu)化點也不是意淫出來的眨攘，是在profile了很多Spark應(yīng)用之后得到的結(jié)論主慰，發(fā)現(xiàn)很多CPU的時間浪費在等待從內(nèi)存中取數(shù)據(jù)的過程。所以在Tungsten中就設(shè)計和實現(xiàn)了一系列的cache-friendly的算法和數(shù)據(jù)結(jié)構(gòu)來加速這個過程鲫售，例如aggregations, joins和shuffle操作中進行快速排序和hash操作共螺。
以sort為例，Spark已經(jīng)實現(xiàn)了cache-aware的sort算法情竹，比原來的性能提升至少有3倍藐不。在傳統(tǒng)的排序中是通過指針來索引數(shù)據(jù)的，但是缺點就是CPU cache命中率不夠高秦效，因為我們需要隨機訪問record做比較雏蛮。實際上quicksort算法是能夠非常好的利用cache的，主要是我們的record不是連續(xù)存儲的阱州。Spark的優(yōu)化就是存儲一個key prefix和指針在一起挑秉，那么就可以通過比較key prefix來直接實現(xiàn)排序，這樣CPU cache的命中率就會高很多苔货。例如如果我們需要排序的列是一個string類型衷模，那么我們可以拿這個string的UTF-8編碼的前8個字節(jié)來做key prefix，并進行排序蒲赂。
關(guān)于這個優(yōu)化可以參見SPARK-9457 和org.apache.spark.shuffle.sort下面的類，最重要的是ShuffleExternalSorter和ShuffleInMemorySorter兩個類刁憋。
3滥嘴，運行時代碼生成
運行時代碼生成能免去昂貴的虛函數(shù)調(diào)用，同時也省去了對Java基本類型裝箱之類的操作了至耻。Spark SQL將運行時代碼生成用于表達式的求值若皱，效果顯著镊叁。
除了這些優(yōu)化，我認為還有兩個很重要的變化：
1走触，Unified Memory Management
在以前Spark的內(nèi)存顯式的被分為三部分：execution晦譬，storage和其他。execution內(nèi)存用于shuffle, join, sort和aggregation等操作互广，而storage內(nèi)存主要用于cache數(shù)據(jù)敛腌。在1.6版本之前是通過spark.shuffle.memoryFraction和spark.storage.memoryFraction兩個參數(shù)來配置用于execution和storage的內(nèi)存份額。從1.6開始這兩部分內(nèi)存合在一起統(tǒng)一管理了惫皱，也就是說如果現(xiàn)在沒有execution的需要像樊，那么所有的內(nèi)存都可以給storage用，反過來也是一樣的旅敷。同時execution可以evict storage的部分內(nèi)存生棍，但是反過來不行。在新的內(nèi)存管理框架上使用兩個參數(shù)來控制spark.memory.fraction和spark.memory.storageFraction媳谁。
2涂滴，Adaptive query execution
這個特性說大了就是所有數(shù)據(jù)庫最核心的一個功能query execution optimization，可以做的東西非常多晴音。我們自己寫Spark程序中經(jīng)常會碰到一個job跑到最后每個分區(qū)的數(shù)據(jù)量很小的情況柔纵，這是因為以前的Spark不會估計下游RDD的每個分區(qū)的數(shù)據(jù)量大小，并根據(jù)數(shù)據(jù)量大小來調(diào)整分區(qū)個數(shù)段多。以前遇到這種問題就需要手工repartition首量，用戶自己要心里有數(shù)到哪個階段的RDD的partition數(shù)據(jù)變多了還是變少了，需要跟著調(diào)整分區(qū)的數(shù)目进苍，非常不靈活加缘。從1.6版本開始有了部分支持，主要是能夠估計在join和aggregate操作中Shuffle之后的分區(qū)的數(shù)目觉啊，動態(tài)調(diào)整下游task的數(shù)目拣宏，從而提高執(zhí)行效率。
DataFrame和SQL API
Spark從API的角度看杠人，可以分為兩大類：
類似于Python的Pandas和R語言的DataFrame API勋乾，用戶可以使用Scala/Java/Python/R四種語言調(diào)用這個API處理數(shù)據(jù)；
SQL語言API嗡善。又分為兩種：一個是普通的Spark SQL辑莫，一種是Hive SQL。
雖然API不同罩引，但是背后解析出來的算子是一樣的各吨，DataFrame的各種算子其實就是各種SQL的語法。Spark在SQL語法的支持越來越豐富的同時內(nèi)置的SQL函數(shù)得到了很大的增強袁铐，目前已經(jīng)有超過100個這樣的常用函數(shù)(string, math, date, time, type conversion, condition)揭蜒，可以說最常見的SQL內(nèi)置函數(shù)都有了横浑。
作為一個類SQL的分析工具，聚合函數(shù)是非常核心的屉更。Spark 1.5和1.6在聚合函數(shù)上都有很大改進：實現(xiàn)了一個新的聚合函數(shù)接口徙融，支持了一些build-in的聚合函數(shù)（例如max/min/count/sum/avg/first/corr/stddev/variance/skewness/kurtosis以及一些窗口函數(shù)等），同時基于新接口實現(xiàn)了相應(yīng)的UDAF接口瑰谜。新的聚合函數(shù)接口是AggregateFunction欺冀，有兩種具體的實現(xiàn)：ImperativeAggregate和DeclarativeAggregate。ImperativeAggregate類型的聚合操作就是通過用戶定義三個動作 initialize/update/merge的邏輯來實現(xiàn)聚合的似舵；而DeclarativeAggregate則是通過指定initialValues/updateExpressions/mergeExpressions這三個表達式然后通過代碼生成的方式來做聚合的操作脚猾。這兩種方式各有利弊，一般來說代碼生成效率更高砚哗，但是像variance/stddev/skewness/kurtosis這樣的多個表達式需要依賴同一個中間表達式的場景下龙助，代碼生成的執(zhí)行路徑由于不能共享中間的結(jié)果，從而導(dǎo)致其不如ImperativeAggregate效率更高蛛芥，所以在Spark內(nèi)部的實現(xiàn)中這幾個聚合函數(shù)也是通過ImperativeAggregate來實現(xiàn)的提鸟。
SQL API上另一個變化是可以直接在文件上進行SQL操作，不需要把這個文件注冊成一個table仅淑。例如支持”select a, b from json.path/to/json/files”這樣的語法称勋，這個應(yīng)該是從Apache Drill借鑒過來的。
另外一個里程碑式的特性就是Dataset API(SPARK-9999)涯竟。Dataset可以認為是DataFrame的一個特例赡鲜，主要區(qū)別是Dataset每一個record存儲的是一個強類型值而不是一個Row。這個強類型的值是以編碼的二進制形式被存儲的庐船，這種存儲格式可以不用反序列化就直接可以被上面的算子（例如sort银酬，Shuffle等）操作。所以在創(chuàng)建Dataset的時候需要指定用于這個編碼工作的Encoder筐钟。
這樣一些需要強類型的地方就可以使用Dataset API揩瞪，不失DataFrame的那些優(yōu)點，同時又可以幫我們做類型檢查篓冲。所以從某種角度上說這個Dataset API在將來是要替換掉RDD的李破。
外部數(shù)據(jù)源和Hive支持
這個feature可以說是建立起Spark生態(tài)系統(tǒng)的基礎(chǔ)，使得Spark與大數(shù)據(jù)生態(tài)圈的其他組件聯(lián)系起來了壹将∴凸ィ可以這么理解，你無論數(shù)據(jù)是在HDFS上诽俯，還是在Cassandra里面屯曹，抑或關(guān)系型數(shù)據(jù)庫里面，我Spark都可以拿過來做分析和處理，或者機器學(xué)習(xí)恶耽，我這邊處理完了你讓我寫到哪去我就可以寫出去。這個特性使得Spark成為了大數(shù)據(jù)處理的核心一環(huán)颜启。目前Spark支持的外部數(shù)據(jù)源有很多種偷俭，主流的像Parquet，JSON缰盏，JDBC涌萤，ORC，AVRO口猜，HBase负溪，Cassandra，AWS S3济炎，AWS Redshift等川抡。
在這些外部數(shù)據(jù)源中，Parquet是其中最核心的须尚，Spark的Parquet支持也有了很大的改進：修復(fù)了越來越多的bug崖堤，Parquet的版本升級到1.7；更快的metadata discovery和schema merging耐床；能夠讀取其他工具或者庫生成的非標準的parquet文件密幔；以及更快更魯棒的動態(tài)分區(qū)插入；對于flat schema的Parquet格式的數(shù)據(jù)的讀性能提升了大約1倍（SPARK-11787）撩轰。
另外在Hive支持方面胯甩，越來越多的Hive特有的SQL語法被加入到Spark中，例如DISTRIBUTE BY... SORT等堪嫂。支持連接Hive 1.2版本的metastore偎箫，同時支持metastore partition pruning（通過spark.sql.hive.metastorePartitionPruning=true開啟，默認為false）溉苛。因為很多公司的Hive集群都升級到了1.2以上镜廉，那么這個改進對于需要訪問Hive元數(shù)據(jù)的Spark集群來說非常重要。
機器學(xué)習(xí)算法
Spark在機器學(xué)習(xí)方面的發(fā)展很快愚战，目前已經(jīng)支持了主流的統(tǒng)計和機器學(xué)習(xí)算法娇唯。雖然和單機的機器學(xué)習(xí)庫相比MLlib還有一定的差距；但是縱觀所有基于分布式架構(gòu)的開源機器學(xué)習(xí)庫寂玲，MLlib是我認為的計算效率最高的塔插。下面列出了目前MLlib支持的主要的機器學(xué)習(xí)算法：
Discrete
Continous
Supervised
Classification
LogisticRegression(with Elastic-Net)
SVM
DecisionTree
RandomForest
GBT
NaiveBayes
MultilayerPerceptron
OneVsRest
Regression
LinearRegression(with Elastic-Net)
DecisionTree
RandomForest
GBT
AFTSurvivalRegression
IsotonicRegression
Unsupervised
Clustering
KMeans
GaussianMixture
LDA
PowerIterationClustering
BisectingKMeans
Dimensionality Reduction, matrix factorization
PCA
SVD
ALS
WLS
下面簡單說下其中一些亮點：
1，MLlib已經(jīng)有了對Generialized Linear Model(GLM)的初步支持：GLM是統(tǒng)計學(xué)里一系列應(yīng)用非常廣泛的模型拓哟，指定不同的family可以得到不同的模型想许。例如“Gaussian” family相當(dāng)于LinearRegression模型， “Bionomial” family相當(dāng)于LogisticRegression模型，“Poisson” family相當(dāng)于SurvivalRegression模型流纹。目前MLlib已經(jīng)提供了這三種模型的機器學(xué)習(xí)解法和LinearRegression的normal equation解法糜烹。
下面詳細說說這兩種解法：一種是利用WeightedLeastSquares(WLS)優(yōu)化方法；另一種是利用L-BFGS優(yōu)化方法漱凝。前者是通過解normal equation的思路求解疮蹦，只需要對所有的數(shù)據(jù)過一遍（不需要迭代）即可得到最后的模型（好像很神奇），同時可以算出像coefficients standard errors, p-value, t-value等統(tǒng)計指標幫助用戶理解模型茸炒，這種解法是目前LinearRegression的默認解法愕乎。不過有個限制就是樣本feature的維度不能超過4096，但對樣本數(shù)目沒有限制壁公。后者就是傳統(tǒng)機器學(xué)習(xí)的解法感论，是通過迭代尋找最優(yōu)解的方法。
而且目前MLlib也在進一步研究IterativelyReweightedLeastSquares(IRLS)算法紊册，然后結(jié)合WLS和IRLS就可以使Spark支持類似R GLM的大多數(shù)功能比肄。這樣對于前面所有的三種模型都將提供兩種解法，用戶可以根據(jù)實際情況選擇合適的解法湿硝。這個全部做完預(yù)計要在下一個版本Spark 2.0了薪前。
2，ALS算法可以說是目前MLlib被應(yīng)用最多的算法关斜，ALS的數(shù)學(xué)原理其實比較容易理解示括，但是如何在分布式系統(tǒng)中高效實現(xiàn)是一個比較復(fù)雜的問題。MLlib里使用分塊計算的思路痢畜，合理的設(shè)計數(shù)據(jù)分區(qū)和 RDD 緩存來減少數(shù)據(jù)交換垛膝，有效的降低了通信復(fù)雜度。這個算法的實現(xiàn)思路充分說明了一個問題：同樣的算法丁稀，在分布式系統(tǒng)上實現(xiàn)時吼拥，不同的選擇會帶來性能上巨大的差異。
3线衫，目前的主要的分類模型都支持使用predictRaw, predictProbability, predict分別可以得到原始預(yù)測凿可、概率預(yù)測和最后的分類預(yù)測。同時這些分類模型也支持通過設(shè)置thresholds指定各個類的閾值授账。不過目前這些預(yù)測函數(shù)還只支持批量預(yù)測枯跑，也就是對一個DataFrame進行預(yù)測，不支持對單個instance進行預(yù)測白热。不過單個instance的預(yù)測的支持也已經(jīng)在roadmap中了敛助。
4，RandomForestClassificationModel和RandomForestRegressionModel模型都支持輸出feature importance
5屋确，GMM EM算法實現(xiàn)了當(dāng)feature維度或者cluster數(shù)目比較大的時候的分布式矩陣求逆計算纳击。實驗表明當(dāng)feature維度>30续扔，cluster數(shù)目>10的時候，這個優(yōu)化性能提升明顯焕数。
6纱昧，在深度學(xué)習(xí)方面，MLlib已經(jīng)實現(xiàn)了神經(jīng)網(wǎng)絡(luò)算法MultilayerPerceptronClassifier(MLPC)堡赔。 這是一個基于前饋神經(jīng)網(wǎng)絡(luò)的分類器砌些，它是一種在輸入層與輸出層之間含有一層或多層隱含結(jié)點的具有正向傳播機制的神經(jīng)網(wǎng)絡(luò)模型，中間的節(jié)點使用sigmoid (logistic)函數(shù)加匈，輸出層的節(jié)點使用softmax函數(shù)。輸出層的節(jié)點的數(shù)目表示分類器有幾類仑荐。MLPC學(xué)習(xí)過程中使用BP算法雕拼，優(yōu)化問題抽象成logistic loss function并使用L-BFGS進行優(yōu)化。
7粘招，除了我們經(jīng)常說的機器學(xué)習(xí)和數(shù)據(jù)挖掘算法啥寇，MLlib在統(tǒng)計檢驗算法上也有很大的進步。例如A/B test, Kolmogorov–Smirnov 檢驗等洒扎。A/B測試可以說是很多大數(shù)據(jù)應(yīng)用的基礎(chǔ)辑甜，很多結(jié)論最終都是通過A/B測試得到的。
機器學(xué)習(xí)Pipeline
MLlib最大的變化就是從一個機器學(xué)習(xí)的library開始轉(zhuǎn)向構(gòu)建一個機器學(xué)習(xí)工作流的系統(tǒng)袍冷，這些變化發(fā)生在ML包里面磷醋。MLlib模塊下現(xiàn)在有兩個包：MLlib和ML。ML把整個機器學(xué)習(xí)的過程抽象成Pipeline胡诗，一個Pipeline是由多個Stage組成邓线，每個Stage是Transformer或者Estimator。
以前機器學(xué)習(xí)工程師要花費大量時間在training model之前的feature的抽取煌恢、轉(zhuǎn)換等準備工作骇陈。ML提供了多個Transformer，極大提高了這些工作的效率瑰抵。在1.6版本之后你雌，已經(jīng)有了30+個feature transformer，像OneHotEncoder, StringIndexer, PCA, VectorSlicer, VectorAssembler, SQLTransformer, HashingTF, IDF, Word2Vec等二汛。這些工具使得各種feature提取婿崭、轉(zhuǎn)換等準備工作。
原始數(shù)據(jù)經(jīng)過上面的各種feature transformer之后就可以丟到算法里去訓(xùn)練模型了习贫，這些算法叫Estimator逛球，得到的模型是Transformer。上一章節(jié)已經(jīng)提到了主流的算法支持苫昌，所以現(xiàn)在可以得到模型了颤绕。得到的模型怎么評價好壞呢幸海？MLlib提供了像BinaryClassificationEvaluator等一系列的evaluation工具，這些工具里面定義了像AUC等一系列的指標用于評價模型的好壞奥务。
這樣一個機器學(xué)習(xí)的pipeline就可以跑起來了物独，MLlib進一步提供了像CrossValidator這樣的工具幫助我們做模型和pipeline的調(diào)優(yōu)，選出最佳的模型參數(shù)等氯葬。另外一個重要特性就是pipeline的持久化〉猜ǎ現(xiàn)在的ML pipeline和大多數(shù)的Transformers/Estimators都支持了持久化，可以save/load帚称。這樣就可以把模型或者pipeline存儲官研、導(dǎo)出到其他應(yīng)用，掃除了MLlib在生產(chǎn)環(huán)境應(yīng)用的最后一個障礙闯睹。
另外一個顯著變化就是ML框架下所有的數(shù)據(jù)源都是基于DataFrame戏羽，所有的模型也盡量都基于Spark的數(shù)據(jù)類型(Vector, Matrix)表示。在ML里面的public API下基本上看不到對RDD的直接操作了楼吃，這也與前面講的Spark的未來變化是一致的始花。
Python是機器學(xué)習(xí)領(lǐng)域最流行的語言，ML/MLlib的Python API也在不斷加強孩锡，越來越多的算法和功能的Python API基本上與Scala API對等了酷宵。
SparkR
R語言在統(tǒng)計領(lǐng)域應(yīng)用非常廣泛，R語言本身的架構(gòu)可以比較容易支持其他執(zhí)行后端躬窜。SparkR就是把Spark作為R語言的執(zhí)行后端浇垦。目前SparkR提供的接口包括了DataFrame的絕大多數(shù)函數(shù)以及機器學(xué)習(xí)GLM函數(shù)，未來還會支持更多的功能斩披。SparkR既可以利用R接口的易用性以及在傳統(tǒng)行業(yè)的既有市場空間溜族，又可以利用Spark強大的分布式數(shù)據(jù)處理能力。SparkR在推出不久就獲得了很高的用戶關(guān)注度和使用率垦沉。筆者在和一些傳統(tǒng)行業(yè)的大數(shù)據(jù)從業(yè)者交流中經(jīng)常會被問到這樣的問題：我以前用R寫的程序煌抒，現(xiàn)在數(shù)據(jù)量大了，傳統(tǒng)R跑不動了厕倍，能不能直接放到Spark上跑寡壮。相信SparkR就是在朝著解決這個問題的方向努力。
在統(tǒng)計和機器學(xué)習(xí)方面一個重要的feature就是R formula的支持讹弯，R用戶可以用他們非常熟悉的formula來定義一個GLM模型况既。目前已經(jīng)支持最基本的'.', '~', ':', '+'和 '-'，未來還會增強這項功能组民。同時SparkR的GLM函數(shù)不只提供了訓(xùn)練一個GLM模型和預(yù)測的能力棒仍，也提供了對模型的R類似的統(tǒng)計指標輸出。目前SparkR跑出的GLM模型和傳統(tǒng)R跑出的模型的結(jié)果是一樣的臭胜，同時也會輸出coefficients standard errors, p-values, t-values等統(tǒng)計信息莫其。
Spark 2.0
Spark streaming等組件在這一年也有很大的變化癞尚，筆者由于精力有限，在此不一一列出乱陡。Spark 2.0預(yù)計三四月份發(fā)布浇揩，將會確立以DataFrame和Dataset為核心的體系架構(gòu)，RDD會慢慢退出歷史舞臺憨颠；同時在各方面的性能上會有很大的提升胳徽，當(dāng)然我們也期待著穩(wěn)定性方面的提升。從1.x到2.x還會放棄Hadoop 1.x的支持爽彤，RPC系統(tǒng)從Akka遷移到Netty等养盗。快速發(fā)展的社區(qū)适篙，越來越多的應(yīng)用爪瓜，性能和穩(wěn)定性方面的不斷提升使得Spark在未來的若干年內(nèi)還是大數(shù)據(jù)處理工具的首選。
作者介紹：
梁堰波匙瘪，明略數(shù)據(jù)技術(shù)合伙人，開源愛好者蝶缀，Apache Spark項目核心貢獻者丹喻。北京航空航天大學(xué)計算機碩士，曾就職于Yahoo!翁都、美團網(wǎng)碍论、法國電信從事機器學(xué)習(xí)和推薦系統(tǒng)相關(guān)的工作，在大數(shù)據(jù)柄慰、機器學(xué)習(xí)和分布式系統(tǒng)領(lǐng)域具備豐富的項目經(jīng)驗鳍悠。
