也還是繼續昨天的話題說吧。
純手機手打，感覺有用麻煩點個贊。
開頭還是那句話，spark是以批處理起家，發展流處理，所以微批處理吞吐優先，可以選用。
flink以實時處理起家，然后去做批處理，所以更適合實時性高的場景。
那么生產中真的都要求那么高的實時性嗎？
比如10wqps的數據，假如實時處理，采用flink，sink是mysql，實時性高，事件驅動，每條都去插入或更新數據庫，明顯不靠譜，因為數據庫扛不住。
假如此事你想在flink的sink處加上批處理，肯定是可以提高性能的，這就降低了實時性，而且也還有一個問題：
假如此事業務進行遷移，遷移到新的topic或者kafka集群，數據遷移之后，遷移flink任務。你會發現，假如最后一個批次沒有達到批大小閾值，數據就不會刷出進而導致數據丟失了，因為沒有新數據寫入，不會觸發sink往外刷新。
此種場景，還是要加一個超時檢測線程，超時一定時間，進行刷出數據。
是不是頗為麻煩。
所以，其實，很多時候實時性可能也沒那么重要。
還有就是spark streaming已然極其穩定了，flink的bug比較多。
舉一個kafkajsontablesource的bug吧，就是數據格式是json的話，可以直接反序列化，解析注冊為row，但是假如有一條數據不是json，那么就會導致flink任務掛掉，因為flink內部算子實現的是僅一次處理，不處理了這條數據不罷休。spark就不會出現。
還有一些就不列舉了。
但是對於研發來說，都掌握還是最好的，而且flink在流處理領域確實還是很優秀的。