王志紅
摘要:在當前我國大數據時代的背景下人們對于信息的實時處理平臺愈發關注,早在2014年,對于數據的分析處理,Flink平臺便為其提供了新思路與新方法。筆者結合自身多年經驗,對Flink平臺理論進行分析,闡述生態系統等相關技術,除此之外,還分析了當前Flink平臺所面臨的挑戰。文章內容可供各位同行相互參考,希望能為Flink平臺未來的發展有所啟示。
關鍵詞:Flink平臺 大數據時代 生態系統
前言
在當前我國現代化信息時代,人們在日常生活工作中,會產生大量的數據信息,這便是大數據。結合當下我國Flink平臺的實際發展情況來看,有關數據分析、實時計算搜索等功能都能夠在Flink平臺上實現,但是Flink平臺在當前社會快速發展的背景下,在運用過程中面臨著諸多問題,基于此本文主要內容研究Flink平臺的運用具有十分重要的現實意義。
1 Flink平臺的工作機制與相關技術
Flink其本質以一個較為新型的流處理系統,在Flink中所蘊含的豐富的API接口能夠有效幫助相關工作人員,對流處理應用進行開發,除此之外,Flink自身還具有十分顯著的靈活性這一特征,與此同時,Flink還具有十分高效的流和數據容錯。在Flink中,流處理能夠有效以低延時的狀態對相關工作任務開展處理工作。一些新型的而應用在處理相關數據過程中,需要開展持續查詢工作,這些應用在一定程度上只能通過流架構實現。
在開展流架構處理工作時,首選需要從各種數據源中收集各種數據信息,主要數據源包含有機器業務平臺的生產業務操作日志、數據庫結構化數據、半結構化數據、文本數據等,在此過程中,需要對相關數據進行實時加工清洗計算后組織到一個中心。其次,在此中心中形成各種流,例如Apache Kafka這一典型工具,能夠在運行過程中提供broker功能,以自身較高的可靠性,以及較低的失敗容錯率,來對緩沖數據以及流日志開展收集工作,進而將相關數據信息結合受眾的喜好進行分發。再次,要對流開展真正的分析工作,在此工程中,Flink能夠提供分析工作所需的一步到位的高級編程。基于上述內容可知,Flink不僅能夠有效開展流處理,還能夠進行批處理。
結合Flink的實際運行情況來看,在其運行過程中主要依賴于Hadoop平臺來執行相關動作。Hadoop平臺最早起源于Nutch,Nutch的本質是一個搜索引擎,基于開源JAVA進行實現的。而Flink是Spark擴展而來的平臺,能夠對開展流式數據的處理工作以及批處理工作,基于此我們可知Flink對于Hadoop具有良好的兼容性。結合Hadoop與Flink的實際運行情況來看,Flink相較于Hadoop擁有較好的數據處理能力這是因為Flink在運行過程中,通過內存來開展相關計算活動。
2 Flink流處理的時間窗口
針對于流式處理平臺而言,在運行過程中,流入其中的信息為無限量,在信息流人之后,流處理系統自身需要開展聚合連接操作,在此過程中,對流入消息會進行分段處理,隨后根據系統在對不同階段的信息進行聚合連接處理。其中對消息進行分段則被稱為窗口,在流式處理系統中會支持各種各樣的窗口類型,時間窗口也在其中,時間窗口指代的是,根據時間間隔對流系統的流人信息進行分段處理。對于當前我國Flink流處理平臺的實際發展情況來看,通常情況下是根據系統內TASK所在節點的本地時間對相關消息進行切分處理,采用時間窗口模式,能夠促使流式處理系統在運行過程中不會阻塞消息,保持系統自身的流暢性,但是在此過程中可能會導致部分應用的要求無法滿足。例如,Flink流處理的信息本身帶有時間戳,因此,用戶自身希望能夠按照信息自身的時間戳來進行處理,此要求在Flink流處理的時間窗口中無法實現,除此之外,由于Flink流處理平臺中不同節點的時間不同,導致信息在被處理過程中,流經系統中各個節點的延遲不同,通常情況下表現為,在某節點,同屬于一個時間窗口的消息在流經系統中下一個節點時可能會被切分到不同的時間窗口中,最終會導致信息最終的處理結果不能符合預期的結果。
結合當前Flink流處理平臺的實際運行情況來看,現如今主要支持三種類型的時間窗口,能夠有效滿足用戶對Flink流處理平臺中時間窗口的要求。首先為Operator Time,它的使用導致Flink平臺在運行過程中能夠根據task所在節點的本地時鐘對時間窗口進行切分。其次為Event Time,當流入的消息自帶時間戳時,能夠促使Flink流處理平臺能夠根據時間戳對消息進行處理,確保統一時間戳內的消息能夠被正確處理。最后為Ingress Time,當消息自身并沒有攜帶時間戳時,但是用戶仍舊希望按照消息進行處理,而不是按照系統平臺中的節點時鐘進行劃分,此時利用Ingress Time能夠對消息進行有效處理。
3 未來發展所面臨的挑戰
結合當前我國Flink平臺的發展現狀來看,目前流式處理平臺類型眾多,其中主要平臺包含有Spark Streaming、Storm、Trident等,并且不同平臺在處理信息數據方面具有自身優勢,例如,如果僅僅只從模型建造方面對流處理平臺進行分析的化,Storm、Trident對于小批量處理方面優勢較為突出,并且在處理過程中其所占用的空間較小。如果要從流式處理平臺的延時方面考慮,Storm在此方面優勢較為突出,但是在處理過程中的吞吐率上,Flink具有十分明顯的優勢,但是結合流處理平臺的整體發展現狀來看,Flink平臺成熟度較低,其余三種主流平臺都相較于Flink平臺成熟。目前Flink平臺在運行過程中主要面臨的問題為工作負載的問題,因為在當前大數據時代,Flink平臺在處理數據信息等相關內容時,需要處理巨大數量的數據量,也要面臨著不斷動態變化的工作量。由于流應用在運行過程中自身特性導致相關外來數據信息能夠隨著時間的變化而變化,因此,Flink平臺在運行過程中不能針對自身工作量進行提前預估,因此,在運行過程中需要適應動態資源消耗這一特征,針對于此,Flink平臺在未來發展過程中,需要對其運行過程中的問題進行解決,促使自身適應數據處理的工作負載,只有這樣才能夠有效保障自身不斷發展。在Flink平臺的應用中,還需對Yarn進行合理整合,提升數據處理效率,但是就目前來看業務平臺在發展中數據的數量在不斷增加,Flink平臺一旦在應用中出現故障,就會對業務平臺生產環境中的數據處理造成極大阻礙,而這也是Flink平臺在日后需要解決的問題。
4 結語
綜上所述,Flink平臺在發展過程中,相較于其他主流流式處理平臺成熟度度較低,因此,在運行發展過程中,應該結合自身實際情況,增強自身工作負載能力,以便能夠在當前大數據時代,對相關數據信息進行處理,有效促使自身不斷發展。
參考文獻
[1]蔡鯤鵬.基于Flink平臺的應用研究[J].現代工業經濟和信息化,2017, 7(2):99-101.
[2]馬黎[1.Spark和Flink平臺大數據批量處理的性能分析[J],中國電子科學研究院學報,2018,13(2):81-85+103.
[3]倪政君,夏哲雷.Flink的并行Apriori算法設計與實現[J].中國計量學院學報,2018,29(2):175-180.