大數(shù)據(jù)產(chǎn)業(yè)興盛期,說(shuō)到大數(shù)據(jù)分析引擎,不少人第一時(shí)間會(huì)想起Spark、Impala等,然而,作為Apache頂級(jí)項(xiàng)目的Flink也是不少企業(yè)的選擇.它到底有什么優(yōu)勢(shì)呢?和Spark相比擬,它有什么更可取之處呢?且聽(tīng)大圣眾包威客平臺(tái)一一道來(lái).

一、寶劍露鋒芒——Apache Flink

作為Apache的頂級(jí)項(xiàng)目,Flink固然集眾多優(yōu)點(diǎn)于一身,包含快速、可靠可擴(kuò)展、完全兼容Hadoop、使用簡(jiǎn)便、表現(xiàn)卓越.

1.快速

快,是Flink的主要特點(diǎn).利用基于內(nèi)存的數(shù)據(jù)流,并將迭代處置算法深度集成到系統(tǒng)的運(yùn)行時(shí)中,這樣,Flink使得系統(tǒng)能夠以極快的速度處置數(shù)據(jù)密集型和迭代任務(wù).

2.可靠、可擴(kuò)展

得益于Flink包括自己的內(nèi)存管理組件、序列化框架和類(lèi)型推理引擎,所以,即使服務(wù)器內(nèi)存被耗盡,Flink也能夠很好地運(yùn)行.

3.完全兼容Hadoop

為什么開(kāi)發(fā)者無(wú)需做任何修改,就能利用Flink運(yùn)行歷史遺留的MapReduce操作?這是因?yàn)镕link支持所有Hadoop的所有輸入/輸出格式和數(shù)據(jù)類(lèi)型.另外,Flink包含基于Java和Scala的用于批量和基于流數(shù)據(jù)分析的API、優(yōu)化器和具有自定義內(nèi)存管理功能的分布式運(yùn)行時(shí)等,這也是它能夠完全兼容Hadoop的原因之一.

4.易用

讓人感到驚喜的是,在無(wú)需進(jìn)行任何配置的情況下,Flink內(nèi)置的優(yōu)化器就能夠以最高效的方式在各種環(huán)境中執(zhí)行程序.只必要三個(gè)命令,Flink就可以運(yùn)行在Hadoop的新MapReduce框架Yarn上.

5.表示卓越

作為一款優(yōu)秀的大數(shù)據(jù)分析引擎,Flink能夠利用Java或者Scala語(yǔ)言編寫(xiě)出漂亮、類(lèi)型平安和可為核心的代碼,并能夠在集群上運(yùn)行所寫(xiě)程序.這樣,使得開(kāi)發(fā)者可以在無(wú)需額外處理的情況下使用Java和Scala數(shù)據(jù)類(lèi)型.

一言以蔽之,ApacheFlink具有分布式MapReduce一類(lèi)平臺(tái)的高效性、靈活性和擴(kuò)展性,以及并行數(shù)據(jù)庫(kù)查詢(xún)優(yōu)化方案,同時(shí),它還支持批量和基于流的數(shù)據(jù)分析,并且提供了基于Java和Scala的API.總的來(lái)說(shuō),Flink是一個(gè)高效的、分布式的、基于Java實(shí)現(xiàn)的通用大數(shù)據(jù)分析引擎.

二、雙鋒互切磋——Apache Spark與Apache Flink

同樣作為流處理引擎,盡管ApacheSpark在大數(shù)據(jù)處理運(yùn)用中已經(jīng)十分著名,然而,沒(méi)有一款工具能夠處理所有問(wèn)題.在一些特殊的情況下,ApacheFlink可能很好地彌補(bǔ)了ApacheSpark所未能涵蓋的地方.那么,應(yīng)該選哪一款作為企業(yè)的大數(shù)據(jù)分析引擎呢?我們可以通過(guò)兩者的異同比擬,做出最優(yōu)選擇.

相同之處：

1.兩者都能提供恰好一次的保證,即每條記錄都僅處置一次；

2.與其他處理系統(tǒng)(好比Storm)相比,它們都能提供一個(gè)非常高的吞吐量；

3.兩者都能夠提供自動(dòng)內(nèi)存管理；

4.它們的容錯(cuò)開(kāi)銷(xiāo)都非常低.

分歧之處：

事實(shí)上,ApacheSpark和ApacheFlink的主要差別,就在于計(jì)算模型不同.所以,對(duì)于選擇ApacheSpark,還是ApacheFlink的問(wèn)題上,實(shí)際上就釀成了計(jì)算模型的選擇.

要了解ApacheSpark與ApacheFlink的相異之處,首先要對(duì)如下三種計(jì)算模型有一個(gè)初步的理解：

批處置——基本上處置靜態(tài)數(shù)據(jù),一次讀入大量數(shù)據(jù)進(jìn)行處置并生成輸出.

微批處理——結(jié)合了批處理和持續(xù)流操作符,將輸入分成多個(gè)微批次進(jìn)行處理,從根本上講,微批處理是一個(gè)“收集然后處理”的計(jì)算模型.

持續(xù)流操作符——在數(shù)據(jù)到達(dá)時(shí)進(jìn)行處理,沒(méi)有任何數(shù)據(jù)收集或處理延遲.

實(shí)際中,Spark采用的是微批處理模型,而Flink采用的是基于操作符的連續(xù)流模型.隨著數(shù)據(jù)處理能力的提高,企業(yè)開(kāi)始認(rèn)識(shí)到,信息的價(jià)值在數(shù)據(jù)產(chǎn)生的時(shí)候最高,他們希望在數(shù)據(jù)產(chǎn)生時(shí)處理數(shù)據(jù),這就是說(shuō)需要一個(gè)實(shí)時(shí)處理系統(tǒng).當(dāng)需要實(shí)時(shí)處理時(shí),可以?xún)?yōu)先選擇ApacheFlink.但也不是所有情況都需要實(shí)時(shí)系統(tǒng),這時(shí),ApacheSpark則是更優(yōu)的選擇.好比,在電信行業(yè),統(tǒng)計(jì)特定用戶(hù)使用的帶寬,微批處理可能是一個(gè)更高效的方案.

至于具體應(yīng)該怎么選,必要企業(yè)在延遲、吞吐量和可靠性等多個(gè)方面上去進(jìn)行權(quán)衡.

縱使科技日新月異,然而,適合的,才是最好的.

(更多年夜數(shù)據(jù)與商業(yè)智能領(lǐng)域干貨、或電子書(shū),可添加個(gè)人微信號(hào)(dashenghuaer))