我覺得Spark有時(shí)候會(huì)傷害用戶镰禾。
之前Spark 2.0 剛發(fā)布不久后的第一個(gè)小版本所灸，Structured Streaming 終于支持Kafka了，但是只支持Kafka 1.0 而不支持Kafka 0.8。用Spark的開發(fā)可是沒辦法決定基礎(chǔ)設(shè)施Kafka的版本的，而且你知道在一個(gè)業(yè)務(wù)成熟的公司更換這種如此重要的基礎(chǔ)設(shè)置的版本的阻力和風(fēng)險(xiǎn)有多大么壹瘟？這簡直讓我們這些渴望能體驗(yàn)Spark新功能的痛心疾首。
接著為了推動(dòng)大家遷移到Scala 2.11 版本而不再提供基于scala 2.10預(yù)編譯的Assembly包鳄逾，要知道俐筋，這會(huì)給使用spark的公司會(huì)帶來的很大的困難。本來用Spark就是因?yàn)楸阌诰幊萄铣模δ軓?qiáng)大，但是有多少程序員有能力自己去編譯笆呆？ 公司累積了一堆的2.10的庫難道都因?yàn)闉榱梭w驗(yàn)下2.0版本而要重新編譯请琳？
我只是覺得Spark不是為我等歡快的工作而努力粱挡，而是為了他們的技術(shù)追求和審美的強(qiáng)迫癥而努力《砭或許這是技術(shù)人員難以逾越的坑吧
Spark 過于專注他所謂的架構(gòu)询筏，忽略了對用戶問題的解決。為了所謂的統(tǒng)一(DataFrame API)導(dǎo)致公司精力都放在了內(nèi)核的重構(gòu)上竖慧，這也直接讓Spark在很多方面慢了一大拍.
曾經(jīng)機(jī)器學(xué)習(xí)的新星嫌套，現(xiàn)在沒落了
原本對機(jī)器學(xué)習(xí)庫我是抱以厚望的，然而其算法和功能都相對來說很貧乏圾旨，并且一直沒有得到質(zhì)的提升踱讨。Spark 團(tuán)隊(duì)將其主要精力放在了API的簡化尤其是DataFrame的統(tǒng)一上，讓其錯(cuò)過了16年深度學(xué)習(xí)崛起的年代砍的，終于淪為一個(gè)普通的帶算法的計(jì)算框架上了痹筛。
曾經(jīng)的全平臺(tái)，現(xiàn)在只有批處理還有優(yōu)勢
對流式的支持也是磕磕盼盼廓鞠，要知道帚稠，流式已經(jīng)是大勢所趨。相對于原先的Spark Streaming, Structure Streaming 帶來了很多新概念床佳，但是本質(zhì)沒有什么變化滋早，只是強(qiáng)迫癥患者的一個(gè)強(qiáng)迫而已（要使用Dataframe）。Spark Streaming 足夠靈活砌们，就是問題比較多杆麸。你新的Structure Streaming 還把追加，寫入等各種拆分開了怨绣，學(xué)習(xí)曲線陡然上身角溃。因?yàn)閳?zhí)著于RDD概念，沒有勇氣打破Spark的基石篮撑，一直無法實(shí)現(xiàn)真正的流式减细，倒是給了Flink巨大的機(jī)會(huì)。同樣的赢笨，也讓Storm一直活得很瀟灑未蝌。新的Structure Streaming不行，但是他們似乎已然放棄Spark Streaming的努力茧妒，包括從Spark Streaming誕生就被廣受吐槽的checkpoint 問題萧吠，也從來沒有得到關(guān)注，也沒有得到改善桐筏。讓你帶著愛被虐著纸型，然后就眼睜睜的看著流式時(shí)代在自己的眼皮底下流過。
有望成為SQL的新標(biāo)準(zhǔn)，現(xiàn)在依然喪失
SQL的支持也是磕磕盼盼狰腌，到現(xiàn)在還還沒覆蓋Hive SQL的大部分功能,Hive 已然是大數(shù)據(jù)SQL的事實(shí)標(biāo)準(zhǔn)除破，又想擺脫Hive，我原先很贊賞Spark的做法琼腔，因?yàn)閔ive確實(shí)重啊瑰枫，結(jié)果 1.6 里一些基礎(chǔ)UADF都不支持。丹莲。光坝。。很多情況其實(shí)沒辦法用的甥材。而新的版本2.0對SQL支持好了很多盯另，結(jié)果前面各種問題限制你使用。
感想
我覺得一個(gè)開源產(chǎn)品擂达，用戶才是自己的最關(guān)鍵的土铺。用戶只關(guān)注了一個(gè)新的版本有什么新的功能，解決了老的什么痛點(diǎn)板鬓，并且提高了多少穩(wěn)定性和速度悲敷，如此而已。至于內(nèi)核的重構(gòu)俭令，API的統(tǒng)一后德，這不能成為自己全身心去投入的事情。
