spark和flink對(duì)比哪個(gè)好用

本篇內(nèi)容介紹了“spark和flink對(duì)比哪個(gè)好用”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

開(kāi)頭還是那句話，spark是以批處理起家，發(fā)展流處理，所以微批處理吞吐優(yōu)先，可以選用。

flink以實(shí)時(shí)處理起家，然后去做批處理，所以更適合實(shí)時(shí)性高的場(chǎng)景。

那么生產(chǎn)中真的都要求那么高的實(shí)時(shí)性嗎？

比如10wqps的數(shù)據(jù)，假如實(shí)時(shí)處理，采用flink，sink是mysql，實(shí)時(shí)性高，事件驅(qū)動(dòng)，每條都去插入或更新數(shù)據(jù)庫(kù)，明顯不靠譜，因?yàn)閿?shù)據(jù)庫(kù)扛不住。

假如此事你想在flink的sink處加上批處理，肯定是可以提高性能的，這就降低了實(shí)時(shí)性，而且也還有一個(gè)問(wèn)題：

假如此事業(yè)務(wù)進(jìn)行遷移，遷移到新的topic或者kafka集群，數(shù)據(jù)遷移之后，遷移flink任務(wù)。你會(huì)發(fā)現(xiàn)，假如最后一個(gè)批次沒(méi)有達(dá)到批大小閾值，數(shù)據(jù)就不會(huì)刷出進(jìn)而導(dǎo)致數(shù)據(jù)丟失了，因?yàn)闆](méi)有新數(shù)據(jù)寫(xiě)入，不會(huì)觸發(fā)sink往外刷新。

此種場(chǎng)景，還是要加一個(gè)超時(shí)檢測(cè)線程，超時(shí)一定時(shí)間，進(jìn)行刷出數(shù)據(jù)。

是不是頗為麻煩。

所以，其實(shí)，很多時(shí)候?qū)崟r(shí)性可能也沒(méi)那么重要。

還有就是spark streaming已然極其穩(wěn)定了，flink的bug比較多。

舉一個(gè)kafkajsontablesource的bug吧，就是數(shù)據(jù)格式是json的話，可以直接反序列化，解析注冊(cè)為row，但是假如有一條數(shù)據(jù)不是json，那么就會(huì)導(dǎo)致flink任務(wù)掛掉，因?yàn)閒link內(nèi)部算子實(shí)現(xiàn)的是僅一次處理，不處理了這條數(shù)據(jù)不罷休。spark就不會(huì)出現(xiàn)。

還有一些就不列舉了。

但是對(duì)于研發(fā)來(lái)說(shuō)，都掌握還是最好的，而且flink在流處理領(lǐng)域確實(shí)還是很優(yōu)秀的。

“spark和flink對(duì)比哪個(gè)好用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！