溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“spark和flink對比哪個好用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
開頭還是那句話，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在流處理領域確實還是很優秀的。
“spark和flink對比哪個好用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
