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

創(chuàng)新互聯(lián)建站不只是一家網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司；我們對(duì)營(yíng)銷、技術(shù)、服務(wù)都有自己獨(dú)特見解，公司采取“創(chuàng)意+綜合+營(yíng)銷”一體化的方式為您提供更專業(yè)的服務(wù)！我們經(jīng)歷的每一步也許不一定是最完美的，但每一步都有值得深思的意義。我們珍視每一份信任，關(guān)注我們的網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)質(zhì)量和服務(wù)品質(zhì)，在得到用戶滿意的同時(shí)，也能得到同行業(yè)的專業(yè)認(rèn)可，能夠?yàn)樾袠I(yè)創(chuàng)新發(fā)展助力。未來將繼續(xù)專注于技術(shù)創(chuàng)新，服務(wù)升級(jí)，滿足企業(yè)一站式網(wǎng)絡(luò)營(yíng)銷推廣需求，讓再小的高端網(wǎng)站設(shè)計(jì)也能產(chǎn)生價(jià)值！

開頭還是那句話，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è)問題：

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

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

是不是頗為麻煩。

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

還有就是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ā)來說，都掌握還是最好的，而且flink在流處理領(lǐng)域確實(shí)還是很優(yōu)秀的。

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