187
Spark之殤
我覺得Spark有時候會傷害用戶。之前Spark 2.0 剛發布不久後的第一個小版本，Structured Streaming 終於支持Kafka了，但是隻支持Kafka 1.0 而不支持Kafka 0.8。用Spark的開發可是沒辦法決定基礎設施Kafka的版本的，而且你知道在一個業務成熟的公司更換這種如此重要的基礎設置的版本的阻力和風險有多大麼？這簡直讓我們這些渴望能體驗Spark新功能的痛心疾首。
接著為了推動大家遷移到Scala 2.11 版本而不再提供基於scala 2.10預編譯的Assembly包，要知道，這會給使用spark的公司會帶來的很大的困難。本來用Spark就是因為便於編程，功能強大，但是有多少程序員有能力自己去編譯？ 公司累積了一堆的2.10的庫難道都因為為了體驗下2.0版本而要重新編譯？
我隻是覺得Spark不是為我等歡快的工作而努力，而是為了他們的技術追求和審美的強迫症而努力。或許這是技術人員難以逾越的坑吧
Spark 過於專注他所謂的架構，忽略了對用戶問題的解決。為了所謂的統一(DataFrame API)導致公司精力都放在了內核的重構上，這也直接讓Spark在很多方麵慢了一大拍.
原本對機器學習庫我是抱以厚望的，然而其算法和功能都相對來說很貧乏，並且一直沒有得到質的提升。Spark 團隊將其主要精力放在了API的簡化尤其是DataFrame的統一上，讓其錯過了16年深度學習崛起的年代，終於淪為一個普通的帶算法的計算框架上了。
對流式的支持也是磕磕盼盼，要知道，流式已經是大勢所趨。相對於原先的Spark Streaming, Structure Streaming 帶來了很多新概念，但是本質沒有什麼變化，隻是強迫症患者的一個強迫而已（要使用Dataframe）。Spark Streaming 足夠靈活，就是問題比較多。你新的Structure Streaming 還把追加，寫入等各種拆分開了，學習曲線陡然上身。因為執著於RDD概念，沒有勇氣打破Spark的基石，一直無法實現真正的流式，倒是給了Flink巨大的機會。同樣的，也讓Storm一直活得很瀟灑。新的Structure Streaming不行，但是他們似乎已然放棄Spark Streaming的努力，包括從Spark Streaming誕生就被廣受吐槽的checkpoint 問題，也從來沒有得到關注，也沒有得到改善。讓你帶著愛被虐著，然後就眼睜睜的看著流式時代在自己的眼皮底下流過。
SQL的支持也是磕磕盼盼，到現在還還沒覆蓋Hive SQL的大部分功能,Hive 已然是大數據SQL的事實標準，又想擺脫Hive，我原先很讚賞Spark的做法，因為hive確實重啊，結果 1.6 裏一些基礎UADF都不支持。。。。很多情況其實沒辦法用的。而新的版本2.0對SQL支持好了很多，結果前麵各種問題限製你使用。
我覺得一個開源產品，用戶才是自己的最關鍵的。用戶隻關注了一個新的版本有什麼新的功能，解決了老的什麼痛點，並且提高了多少穩定性和速度，如此而已。至於內核的重構，API的統一，這不能成為自己全身心去投入的事情。
最後更新：2017-04-01 17:13:52