浪尖對blink開源的看法？
有微信羣友和星球球友問浪尖怎麼看待blink開源。
網上看到有祝兄跟浪尖一樣是spark支持者，不同的事情是浪尖對flink也比較熟悉，也挺喜歡用flink的。
浪尖前面有分享過flink 與 Spark對比
Spark Streaming VS Flink
Structured Streaming VS Flink
這都是功能性對比，浪尖沒有總結，浪尖個人覺得單純的從流處理來說，spark 確是比flink稍微弱了一點，尤其是，任務大，數據小的時候，這是由spark微批處理的特性決定的，每個批次都會產生task進行調度（序列化反序列化、jar傳輸等）引起性能開銷，而flink task是常駐的，數據在task之間流動，數據量小數據移動成本明顯會低於task調度成本。這不是說flink不能處理大數據，要知道實時處理數據不會落地，數據本地性可以用的地方少，數據一直在傳輸。
但是flink和spark 兩者我從功能上來說可以相互替代吧，尤其是窗口處理，大家都變成了批處理，這個點區別不大。但是flink狀態維護機制確實強於spark，比如統計一天從凌晨到當前時間的pv，uv這個用flink實時統計很簡單 ，spark需要藉助第三方存儲實現靈活的狀態管理。還有就是join操作等flink也是要優秀點。
但是一旦用第三方存儲維護狀態，故障恢復就會是個大難題。spark故障恢復機制相對弱於flink，前面浪尖也分享過了spark的checkpoint和flink checkpoint機制的區別，flink checkpoint確實是分散式快照機制，而spark主要是driver端的故障恢復。
flink超越Spark的Checkpoint機制必會:關於SparkStreaming checkpoint那些事兒
假如flink一直這麼堅持優化的話，流處理確是會搶spark的一杯羹，而批處理我覺得spark還是很贊的，尤其是假如你能充分利用數據本地性的情況下。
接著再來看看contributors數，spark碾壓flink，所以你用spark網上資料會是你強力的支持，用flink那麼你要學習和解決一些flink自身已有的bug。
blink開源我們應該持借鑒學習的態度，浪尖這邊也是內部維護了flink分支，可以借鑒學習blink特點融合進來。
至於要不要用blink。建議持觀望態度或者還是使用社區的然後邊融合blink特性，因為要想想jstorm的前車之鑒。
假如後期合併結束，然後驗證穩定，那麼再使用也不晚。
當然，星球裏急躁的小夥伴比較多，天天催著我上線flink教程，我這邊雖然再加緊整理。但是工作，學習，健身，寫文章都要時間，所以要點時間。
還有尤其是新手我覺得沒必要急於去學習flink，別因為最近blink在吹風就忘了自己有幾斤幾兩，尤其是年後跳槽的，別指望過年期間熟悉一下flink就會加分很多，其他技術底子薄弱，會點flink也不會給自己增光添彩。過年期間還是要刷java基礎，各種官網和權威指南，掃盲點，這樣自己完善了現有的體系，年後再擴展一下小小flink，就是如虎添翼，否則就是自己給自己埋坑了。
星球裏會陸續分享flink的技術文章及學習教程，歡迎加入～
500位好友了～～
推薦閱讀：
