優(yōu)質(zhì)博文：IT-BLOG-CN

為什么選擇 Flink

【1】流數(shù)據(jù)更真實地反映了我們的生活方式（實時聊天）；
【2】傳統(tǒng)的數(shù)據(jù)架構(gòu)是基于有限數(shù)據(jù)集的（Spark 是基于微批次數(shù)據(jù)處理）；
【3】我們的目標(biāo)：低延遲、高吞吐（分布式架構(gòu)，可能會出現(xiàn)順序上的混亂，比如統(tǒng)計1個小時內(nèi)，可能在1小時的時候，可能有的數(shù)據(jù)還在處理，會延遲到達(dá)幾毫秒，這個可以通過設(shè)置來規(guī)避）、結(jié)果的準(zhǔn)確性和良好的容錯性；

哪些行業(yè)需要處理流數(shù)據(jù)（任選一個進(jìn)行創(chuàng)業(yè)吧）

【1】電商和市場營銷： 數(shù)據(jù)報表、廣告投放、業(yè)務(wù)流程需要。例如：實時智能推薦 利用Flink流計算幫助用戶構(gòu)建更加實時的智能推薦系統(tǒng)，幫助企業(yè)提升銷售額，創(chuàng)造更大的商業(yè)價值；
【2】物聯(lián)網(wǎng)（IOT）： 傳感器實時數(shù)據(jù)采集和顯示、實時報警，交通運輸業(yè) 復(fù)雜事件處理 對于復(fù)雜事件處理，比較常見的案例主要集中于工業(yè)領(lǐng)域，例如對車載傳感器、機(jī)械設(shè)備等實時故障檢測，這些業(yè)務(wù)類型通常數(shù)據(jù)量都非常大，且對數(shù)據(jù)處理的時效性要求非常高。通過利用Flink提供的CEP（復(fù)雜事件處理）進(jìn)行事件模式的抽取，同時應(yīng)用Flink的Sql進(jìn)行事件數(shù)據(jù)的轉(zhuǎn)換，在流式系統(tǒng)中構(gòu)建實時規(guī)則引擎，一旦事件觸發(fā)報警規(guī)則，便立即將告警結(jié)果傳輸至下游通知系統(tǒng)，從而實現(xiàn)對設(shè)備故障快速預(yù)警監(jiān)測，車輛狀態(tài)監(jiān)控等目的；
【3】電信業(yè)： 基站流量調(diào)配；
【4】銀行和金融業(yè)： 實時結(jié)算和通知推送，實時檢測異常行為（不用再到晚上進(jìn)行才進(jìn)行批處理計算）。實時欺詐檢測 在金融領(lǐng)域的業(yè)務(wù)中，常常出現(xiàn)各種類型的欺詐行為，例如信用卡欺詐、信貸申請欺詐等，而如何保證用戶和公司的資金安全，是來近年來許多金融公司及銀行共同面對的挑戰(zhàn)。隨著不法分子欺詐手段的不斷升級，傳統(tǒng)的反欺詐手段已經(jīng)不足以解決目前所面臨的問題。以往可能需要幾個小時才能通過交易數(shù)據(jù)計算出用戶的行為指標(biāo)，然后通過規(guī)則判別出具有欺詐行為嫌疑的用戶，再進(jìn)行案件調(diào)查處理，在這種情況下資金可能早已被不法分子轉(zhuǎn)移，從而給企業(yè)和用戶造成大量的經(jīng)濟(jì)損失。而運用Flink流式計算技術(shù)能夠在毫秒內(nèi)就完成對欺詐判斷行為指標(biāo)的計算，然后實時對交易流水進(jìn)行規(guī)則判斷或者模型預(yù)測，這樣一旦檢測出交易中存在欺詐嫌疑，則直接對交易進(jìn)行實時攔截，避免因為處理不及時而導(dǎo)致的經(jīng)濟(jì)損失；實時數(shù)倉與ETL
結(jié)合離線數(shù)倉，通過利用流計算諸多優(yōu)勢和SQL靈活的加工能力，對流式數(shù)據(jù)進(jìn)行實時清洗、歸并、結(jié)構(gòu)化處理，為離線數(shù)倉進(jìn)行補充和優(yōu)化。另一方面結(jié)合實時數(shù)據(jù)ETL處理能力，利用有狀態(tài)流式計算技術(shù)，可以盡可能降低企業(yè)由于在離線數(shù)據(jù)計算過程中調(diào)度邏輯的復(fù)雜度，高效快速地處理企業(yè)需要的統(tǒng)計結(jié)果，幫助企業(yè)更好地應(yīng)用實時數(shù)據(jù)所分析出來的結(jié)果。
【5】流數(shù)據(jù)分析： 實時計算各類數(shù)據(jù)指標(biāo)，并利用實時結(jié)果及時調(diào)整在線系統(tǒng)相關(guān)策略，在各類內(nèi)容投放、無線智能推送領(lǐng)域有大量的應(yīng)用。流式計算技術(shù)將數(shù)據(jù)分析場景實時化，幫助企業(yè)做到實時化分析Web應(yīng)用或者App應(yīng)用的各項指標(biāo)，包括App版本分布情況、Crash檢測和分布等，同時提供多維度用戶行為分析，支持日志自主分析，助力開發(fā)者實現(xiàn)基于大數(shù)據(jù)技術(shù)的精細(xì)化運營、提升產(chǎn)品質(zhì)量和體驗、增強用戶黏性。
【6】實時報表分析： 實時報表分析是近年來很多公司采用的報表統(tǒng)計方案之一，其中最主要的應(yīng)用便是實時大屏展示。利用流式計算實時得出的結(jié)果直接被推送到前端應(yīng)用，實時顯示出重要指標(biāo)的變換情況。最典型的案例便是淘寶的雙十一活動，每年雙十一購物節(jié)，除瘋狂購物外，最引人注目的就是天貓雙十一大屏不停跳躍的成交總額。在整個計算鏈路中包括從天貓交易下單購買到數(shù)據(jù)采集、數(shù)據(jù)計算、數(shù)據(jù)校驗，最終落到雙十一大屏上展現(xiàn)的全鏈路時間壓縮在5秒以內(nèi)，頂峰計算性能高達(dá)數(shù)三十萬筆訂單/秒，通過多條鏈路流計算備份確保萬無一失。而在其他行業(yè)，企業(yè)也在構(gòu)建自己的實時報表系統(tǒng)，讓企業(yè)能夠依托于自身的業(yè)務(wù)數(shù)據(jù)，快速提取出更多的數(shù)據(jù)價值，從而更好地服務(wù)于企業(yè)運行過程中。

傳統(tǒng)數(shù)據(jù)處理架構(gòu)

企業(yè)剛開始主要進(jìn)行事務(wù)處理：CRM 產(chǎn)生事件——在 Order 中進(jìn)行邏輯處理——最終反饋給Click，數(shù)據(jù)都是通過關(guān)系型數(shù)據(jù)庫獲取，那么當(dāng)對數(shù)據(jù)進(jìn)行統(tǒng)計時，數(shù)據(jù)量大的時候就會遇到瓶頸。OLTP 特點是快速響應(yīng)。缺點是數(shù)據(jù)量大時不易擴(kuò)展。

微服務(wù)架構(gòu)： 微服務(wù)架構(gòu)將系統(tǒng)拆解成不同的獨立服務(wù)模塊，每個模塊分別使用各自獨立的數(shù)據(jù)庫，這種模式解決了業(yè)務(wù)系統(tǒng)拓展的問題，但是也帶來了新的問題，那就是業(yè)務(wù)交易數(shù)據(jù)過于分散在不同的系統(tǒng)中，很難將數(shù)據(jù)進(jìn)行集中化管理，對于企業(yè)內(nèi)部進(jìn)行數(shù)據(jù)分析或者數(shù)據(jù)挖掘之類的應(yīng)用，則需要通過從不同的數(shù)據(jù)庫中進(jìn)行數(shù)據(jù)抽取，將數(shù)據(jù)從數(shù)據(jù)庫或業(yè)務(wù)系統(tǒng)中周期性地同步到數(shù)據(jù)倉庫中，然后在數(shù)據(jù)倉庫中進(jìn)行數(shù)據(jù)的抽取、轉(zhuǎn)換、加載（ETL），從而構(gòu)建成不同的數(shù)據(jù)集市和應(yīng)用，提供給業(yè)務(wù)系統(tǒng)使用。但是對于一些時間要求比較高的應(yīng)用，例如實時報表統(tǒng)計，則必須有非常低的延時展示統(tǒng)計結(jié)果，為此業(yè)界提出一套 Lambda架構(gòu)方案來處理不同類型的數(shù)據(jù)。

分析處理： 將數(shù)據(jù)從業(yè)務(wù)數(shù)據(jù)庫復(fù)制到數(shù)倉，再進(jìn)行分析和查詢。OLAP 特點是對大數(shù)據(jù)的數(shù)據(jù)分析，缺點是離線分析。

流處理的演變： Lambda 架構(gòu)，用兩套系統(tǒng)，同時保證低延遲和結(jié)果準(zhǔn)確。例如使用 Hadoop MapReduce進(jìn)行批量數(shù)據(jù)的處理，使用Apache Storm進(jìn)行實時數(shù)據(jù)的處理。這種架構(gòu)在一定程度上解決了不同計算類型的問題，但是帶來的問題是框架太多會導(dǎo)致平臺復(fù)雜度過高、運維成本高等。在一套資源管理平臺中管理不同類型的計算框架使用也是非常困難的事情?？偠灾?，Lambda 架構(gòu)是構(gòu)建大數(shù)據(jù)應(yīng)用程序的一種很有效的解決方案，但是還不是最完美的方案。后來隨著Apache Spark的分布式內(nèi)存處理框架的出現(xiàn)，提出了將數(shù)據(jù)切分成微批的處理模式進(jìn)行流式數(shù)據(jù)處理，從而能夠在一套計算框架內(nèi)完成批量計算和流式計算。但因為Spark本身是基于批處理模式的原因，并不能完美且高效地處理原生的數(shù)據(jù)流，因此對流式計算支持的相對較弱，可以說Spark的出現(xiàn)本質(zhì)上是在一定程度上對Hadoop架構(gòu)進(jìn)行了一定的升級和優(yōu)化。

有狀態(tài)的流式處理： 我們平常開發(fā)的Java應(yīng)用系統(tǒng)時沒有狀態(tài)的。數(shù)據(jù)產(chǎn)生的本質(zhì)，其實是一條條真實存在的事件，前面提到的不同的架構(gòu)其實都是在一定程度違背了這種本質(zhì)，需要通過在一定時延的情況下對業(yè)務(wù)數(shù)據(jù)進(jìn)行處理，然后得到基于業(yè)務(wù)數(shù)據(jù)統(tǒng)計的準(zhǔn)確結(jié)果。實際上，基于流式計算技術(shù)局限性，我們很難在數(shù)據(jù)產(chǎn)生的過程中進(jìn)行計算并直接產(chǎn)生統(tǒng)計結(jié)果，因為這不僅對系統(tǒng)有非常高的要求，還必須要滿足高性能、高吞吐、低延時等眾多目標(biāo)。而有狀態(tài)流計算架構(gòu)的提出，從一定程度上滿足了企業(yè)的這種需求，企業(yè)基于實時的流式數(shù)據(jù)，維護(hù)所有計算過程的狀態(tài)，所謂狀態(tài)就是計算過程中產(chǎn)生的中間計算結(jié)果，每次計算新的數(shù)據(jù)進(jìn)入到流式系統(tǒng)中都是基于中間狀態(tài)結(jié)果的基礎(chǔ)上進(jìn)行運算，最終產(chǎn)生正確的統(tǒng)計結(jié)果?；谟袪顟B(tài)計算的方式最大的優(yōu)勢是不需要將原始數(shù)據(jù)重新從外部存儲中拿出來，從而進(jìn)行全量計算，因為這種計算方式的代價可能是非常高的。從另一個角度講，用戶無須通過調(diào)度和協(xié)調(diào)各種批量計算工具，從數(shù)據(jù)倉庫中獲取數(shù)據(jù)統(tǒng)計結(jié)果，然后再落地存儲，這些操作全部都可以基于流式計算完成，可以極大地減輕系統(tǒng)對其他框架的依賴，減少數(shù)據(jù)計算過程中的時間損耗以及硬件存儲。將數(shù)據(jù)存儲在本地內(nèi)存，如果處理的過程中某個節(jié)點掛了，數(shù)據(jù)如何保存。就有了 RemoteStorage（內(nèi)存的一個快照）實現(xiàn)了毫秒級別的延遲。但是問題是分布式項目不能保證數(shù)據(jù)處理的順序，不能保證數(shù)據(jù)的準(zhǔn)確性，在并發(fā)性上和吞吐量上存在瓶頸。Stom的實現(xiàn)方式。

如果計算的結(jié)果能保持一致，實時計算在很短的時間內(nèi)統(tǒng)計出結(jié)果，批量計算則需要等待一定時間才能得出，相信大多數(shù)用戶會更加傾向于選擇使用有狀態(tài)流進(jìn)行大數(shù)據(jù)處理。

流處理的演變： 整合 Spark Streaming 的高吞吐和正確性（使用的時候需要設(shè)置500ms之上延遲）和 Storm的低延遲。Flink通過實現(xiàn)Google Dataflow流式計算模型實現(xiàn)了高吞吐、低延遲、高性能兼具實時流式計算框架。同時Flink支持高度容錯的狀態(tài)管理，防止?fàn)顟B(tài)在計算過程中因為系統(tǒng)異常而出現(xiàn)丟失，F(xiàn)link周期性地通過分布式快照技術(shù) Checkpoints實現(xiàn)狀態(tài)的持久化維護(hù)，使得即使在系統(tǒng)停機(jī)或者異常的情況下都能計算出正確的結(jié)果。而 Flink也在每一次的 Release版本中，不斷推出新的特性，例如Queryable State功能的提出，容許用戶通過遠(yuǎn)程的方式直接獲取流式計算任務(wù)的狀態(tài)信息，數(shù)據(jù)不需要落地數(shù)據(jù)庫就能直接從Flink流式應(yīng)用中查詢。對于實時交互式的查詢業(yè)務(wù)可以直接從Flink的狀態(tài)中查詢最新的結(jié)果。在未來，F(xiàn)link將不僅作為實時流式處理的框架，更多的可能會成為一套實時的狀態(tài)存儲引擎，讓更多的用戶從有狀態(tài)計算的技術(shù)中獲益。

Flink 的主要特點

事件驅(qū)動（Event-driven）

基于流的世界觀： 在Flink 的世界觀中，一切都是由流組成的，離線數(shù)據(jù)是有界的流；實時數(shù)據(jù)是一個沒有界限的流：這就是所謂的有界流和無界流。

分成API 的設(shè)置： 越頂層越抽象，表達(dá)含義越簡明，使用越方便。越底層越具體，表達(dá)能力越豐富，使用越靈活。

Flink 的其他特點

【1】同時支持高吞吐、每秒處理數(shù)百萬個事件，毫秒級延遲、高性能： Flink是目前開源社區(qū)中唯一集高吞吐、低延遲、高性能三者于一身的分布式流式數(shù)據(jù)處理框架。像Apache Spark也只能兼顧高吞吐和高性能特性，主要因為在Spark Streaming流式計算中無法做到低延遲保障；而流式計算框架Apache Storm只能支持低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個目標(biāo)對分布式流式計算框架來說是非常重要的。
【2】支持事件時間（event-time）和處理時間（processing-time）語義： 在流式計算領(lǐng)域中，窗口計算的地位舉足輕重，但目前大多數(shù)框架窗口計算采用的都是系統(tǒng)時間（Process Time），也是事件傳輸?shù)接嬎憧蚣芴幚頃r，系統(tǒng)主機(jī)的當(dāng)前時間。Flink能夠支持基于事件時間（Event Time）語義進(jìn)行窗口計算，也就是使用事件產(chǎn)生的時間，這種基于事件驅(qū)動的機(jī)制使得事件即使亂序到達(dá)，流系統(tǒng)也能夠計算出精確的結(jié)果，保持了事件原本產(chǎn)生時的時序性，盡可能避免網(wǎng)絡(luò)傳輸或硬件系統(tǒng)的影響。
【3】精確一次（exactly-once）的狀態(tài)一致性保證： 所謂狀態(tài)就是在流式計算過程中將算子的中間結(jié)果數(shù)據(jù)保存在內(nèi)存或者文件系統(tǒng)中，等下一個事件進(jìn)入算子后可以從之前的狀態(tài)中獲取中間結(jié)果中計算當(dāng)前的結(jié)果，從而無須每次都基于全部的原始數(shù)據(jù)來統(tǒng)計結(jié)果，這種方式極大地提升了系統(tǒng)的性能，并降低了數(shù)據(jù)計算過程的資源消耗。對于數(shù)據(jù)量大且運算邏輯非常復(fù)雜的流式計算場景，有狀態(tài)計算發(fā)揮了非常重要的作用。
【4】支持高度靈活的窗口（Window）操作： 在流處理應(yīng)用中，數(shù)據(jù)是連續(xù)不斷的，需要通過窗口的方式對流數(shù)據(jù)進(jìn)行一定范圍的聚合計算，例如統(tǒng)計在過去的1分鐘內(nèi)有多少用戶點擊某一網(wǎng)頁，在這種情況下，我們必須定義一個窗口，用來收集最近一分鐘內(nèi)的數(shù)據(jù)，并對這個窗口內(nèi)的數(shù)據(jù)進(jìn)行再計算。Flink將窗口劃分為基于Time、Count、Session，以及Data-driven等類型的窗口操作，窗口可以用靈活的觸發(fā)條件定制化來達(dá)到對復(fù)雜的流傳輸模式的支持，用戶可以定義不同的窗口觸發(fā)機(jī)制來滿足不同的需求。
【5】基于輕量級分布式快照（Snapshot）實現(xiàn)的容錯： Flink能夠分布式運行在上千個節(jié)點上，將一個大型計算任務(wù)的流程拆解成小的計算過程，然后將tesk分布到并行節(jié)點上進(jìn)行處理。在任務(wù)執(zhí)行過程中，能夠自動發(fā)現(xiàn)事件處理過程中的錯誤而導(dǎo)致數(shù)據(jù)不一致的問題，比如：節(jié)點宕機(jī)、網(wǎng)路傳輸問題，或是由于用戶因為升級或修復(fù)問題而導(dǎo)致計算服務(wù)重啟等。在這些情況下，通過基于分布式快照技術(shù)的Checkpoints，將執(zhí)行過程中的狀態(tài)信息進(jìn)行持久化存儲，一旦任務(wù)出現(xiàn)異常停止，F(xiàn)link就能夠從Checkpoints中進(jìn)行任務(wù)的自動恢復(fù)，以確保數(shù)據(jù)在處理過程中的一致性。
【5】與眾多常用存儲系統(tǒng)的鏈接： kafka、redis、hive、dfs等服務(wù)器進(jìn)行鏈接
【6】Save Points（保存點）： 高可用，動態(tài)擴(kuò)展，實現(xiàn)724小時全天候運行，對于724小時運行的流式應(yīng)用，數(shù)據(jù)源源不斷地接入，在一段時間內(nèi)應(yīng)用的終止有可能導(dǎo)致數(shù)據(jù)的丟失或者計算結(jié)果的不準(zhǔn)確，例如進(jìn)行集群版本的升級、停機(jī)運維操作等操作。值得一提的是，F(xiàn)link通過Save Points技術(shù)將任務(wù)執(zhí)行的快照保存在存儲介質(zhì)上，當(dāng)任務(wù)重啟的時候可以直接從事先保存的Save Points恢復(fù)原有的計算狀態(tài)，使得任務(wù)繼續(xù)按照停機(jī)之前的狀態(tài)運行，Save Points技術(shù)可以讓用戶更好地管理和運維實時流式應(yīng)用。
【7】基于JVM實現(xiàn)獨立的內(nèi)存管理： 內(nèi)存管理是所有計算框架需要重點考慮的部分，尤其對于計算量比較大的計算場景，數(shù)據(jù)在內(nèi)存中該如何進(jìn)行管理顯得至關(guān)重要。針對內(nèi)存管理，F(xiàn)link實現(xiàn)了自身管理內(nèi)存的機(jī)制，盡可能減少JVM GC對系統(tǒng)的影響。另外，F(xiàn)link通過序列化/反序列化方法將所有的數(shù)據(jù)對象轉(zhuǎn)換成二進(jìn)制在內(nèi)存中存儲，降低數(shù)據(jù)存儲的大小的同時，能夠更加有效地對內(nèi)存空間進(jìn)行利用，降低GC帶來的性能下降或任務(wù)異常的風(fēng)險，因此Flink較其他分布式處理的框架會顯得更加穩(wěn)定，不會因為JVM GC等問題而影響整個應(yīng)用的運行。

Flink vs Spark Streaming

流（Stream）和微批（micro-batching）

數(shù)據(jù)模型： spark 采用RDD模型，spark streaming 的 DStream 實際上也就是一組小批數(shù)據(jù) RDD 的集合。Flink 基本數(shù)據(jù)模型是數(shù)據(jù)流，以及事件（Event）序列。
運行時架構(gòu)： spark 是批計算，將 DAG 劃分為不同的 stage，一個完成后才可以計算下一個。Flink 是標(biāo)準(zhǔn)的流執(zhí)行模式，一個事件在一個節(jié)點處理完后可以直接發(fā)往下一個節(jié)點進(jìn)行處理。

學(xué)習(xí)建議

【1】先實踐再理論： 先學(xué)習(xí)應(yīng)用，嘗試構(gòu)建復(fù)雜的 Flink Application
【2】橫向擴(kuò)展： 在構(gòu)建復(fù)雜 Flink 生產(chǎn)業(yè)務(wù)后，橫向使用學(xué)習(xí) Storm、Spark、DataFlow 等系統(tǒng)，知識是演化過來的，必有前置和鋪墊。多橫向看看，打開視野。
【3】關(guān)注 Apache Flink 以及 Flink China 社區(qū)： 多交流，多提問，多輸出。文章來源地址http://www.zghlxwxcb.cn/news/detail-838510.html

到了這里，關(guān)于為什么選擇 Flink 做實時處理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！