資訊專欄INFORMATION COLUMN
Processing Time: 機(jī)器或者系統(tǒng)的時間，可理解為真實(shí)世界的時間。使用該時間模式有最好的性能和最低的延遲。
Event time: 數(shù)據(jù)上自帶的時間，可理解為數(shù)據(jù)世界的時間。實(shí)際場景中應(yīng)用較多，由于數(shù)據(jù)在傳輸過程有網(wǎng)絡(luò)、I/O以及消費(fèi)等因素，往往不能保證數(shù)據(jù)按順序到達(dá)，因此導(dǎo)致了時間的亂序等問題。
Ingestion time: 數(shù)據(jù)進(jìn)入程序時的時間，比如12點(diǎn)的一條數(shù)據(jù)與11點(diǎn)的一條數(shù)據(jù)同時進(jìn)入程序，這兩者會被認(rèn)為是同一時間的數(shù)據(jù)。與事件時間相比，攝入時間程序不能處理任何無序事件或者延遲事件，但是程序無需指定如何產(chǎn)生水印。
PS：對時間的理解，時間并不一定就一定是時間，只要數(shù)據(jù)是有序遞增的，都可以理解為時間來進(jìn)行處理。
在實(shí)際業(yè)務(wù)場景中的實(shí)時計(jì)算，往往都是使用的數(shù)據(jù)時間EventTime，這樣才能保證數(shù)據(jù)的真實(shí)性和準(zhǔn)確性。但是數(shù)據(jù)在傳輸過程有網(wǎng)絡(luò)、I/O以及消費(fèi)等因素，數(shù)據(jù)的時間可能會存在一定程度的亂序。
需要考慮對于整個序列進(jìn)行更大程度離散化。把數(shù)據(jù)按照一定的條數(shù)組成一些小批次，但這里的小批次并不是攢夠多少條就要去處理，而是為了對他們進(jìn)行時間上的劃分。
經(jīng)過這種更高層次的離散化之后，我們會發(fā)現(xiàn)最右邊方框里的時間就是一定會小于中間方框里的時間，中間框里的時間也一定會小于最左邊方框里的時間。
這個時候我們在整個時間序列里插入一些類似于標(biāo)志位的一些特殊的處理數(shù)據(jù)，這些特殊的處理數(shù)據(jù)叫做watermark。一個watermark 本質(zhì)上就代表了這個watermark 所包含的timestamp數(shù)值，表示以后到來的數(shù)據(jù)已經(jīng)再也沒有小于或等于這個時間的了。
watermark 會以廣播的形式在算子之間進(jìn)行傳播，下游所有算子共享watermark。
如果在程序里面收到了一個 Long.MAX_VALUE 這個數(shù)值的 watermark，就表示對應(yīng)的那一條流的一個部分不會再有數(shù)據(jù)發(fā)過來了，它相當(dāng)于就是一個終止的一個標(biāo)志。
對于單流而言，會選擇當(dāng)前最大的值timestamp作為watermark。對于多流而言，會選擇流中最小的watermark作為整個任務(wù)的watermark。即可看做一個由多個木塊組成的裝水的木桶，桶里面水多高取決于組成桶的那個最低的木塊。
Watermaker的生成有兩類。第一類是定期生成器，默認(rèn)50ms向下游發(fā)送一次；第二類是根據(jù)一些在流處理數(shù)據(jù)流中遇到的一些特殊記錄生成的，來一條數(shù)據(jù)獲取一次，發(fā)送一次。生產(chǎn)中的使用可根據(jù)業(yè)務(wù)考慮使用何種，已達(dá)到性能和業(yè)務(wù)的平衡。
關(guān)于數(shù)據(jù)的延遲亂序，生成Watermaker時是可以直接增加一個特定延遲時間的。這樣做的好處是，在水位到達(dá)時，仍然可以再等待一個延遲保證晚到的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，保證數(shù)據(jù)的準(zhǔn)確性，當(dāng)然這樣也使得數(shù)據(jù)實(shí)時性延遲，是保證實(shí)時性還是準(zhǔn)確性，需要生成進(jìn)行取舍，或者兩種之間采用一個平衡值。具體的延遲時長，需要觀察實(shí)際數(shù)據(jù)的延遲等進(jìn)行判斷及定義。
場景：
數(shù)據(jù)源一分鐘產(chǎn)生一條數(shù)據(jù)，每條數(shù)據(jù)中有9條左右的不同key的子數(shù)據(jù)，程序進(jìn)行Keyby處理后，開啟一分鐘的窗口進(jìn)行匯總統(tǒng)計(jì)數(shù)量。
問題：
程序啟動4個并行進(jìn)行處理，結(jié)果幾分鐘后都沒觸發(fā)匯總。什么原因？
原因：通過前臺對flink任務(wù)的監(jiān)控發(fā)現(xiàn)，4個并行后由于數(shù)據(jù)量太少，有一個并行沒有收到數(shù)據(jù)，因此沒有產(chǎn)生Watermaker，由Watermaker的特性的第三條可以理解，整個程序目前的watermarker取的是第4個并行的watermarker初始值Long.MIN_VALUE，所以導(dǎo)致整個程序沒有進(jìn)行觸發(fā)匯總。
不改并行的情況下，需要對程序Watermaker生成之前進(jìn)行數(shù)據(jù)負(fù)載均衡，最簡單直接的辦法是進(jìn)行一次keyby處理。
數(shù)據(jù)量較少的情況，直接改小并行度。
兩種方法的目的都是保證每個并行都能消費(fèi)到實(shí)時數(shù)據(jù)，這里我們采用第一個方案進(jìn)行修改驗(yàn)證，結(jié)果如圖時間小于1593572813000的數(shù)據(jù)都會及時進(jìn)行匯總生成指標(biāo)。
實(shí)際生產(chǎn)中關(guān)于數(shù)據(jù)負(fù)載均衡的問題往往也是需要注意的，往往數(shù)據(jù)的傾斜問題，如果比較嚴(yán)重會導(dǎo)致數(shù)據(jù)計(jì)算的準(zhǔn)確性以及整個任務(wù)的性能等一系列問題，關(guān)于數(shù)據(jù)傾斜問題這里不進(jìn)行深入探討，下期有機(jī)會給大家做進(jìn)一步的分享。
場景：業(yè)務(wù)鏈實(shí)時指標(biāo)計(jì)算延遲。
原因：重復(fù)注冊Watermaker導(dǎo)致任務(wù)吞吐量變低，影響計(jì)算效率。
如何解決：
業(yè)務(wù)鏈處理經(jīng)過算子處理之后m條數(shù)據(jù)會生成m*n條數(shù)據(jù)，然后進(jìn)行keyby匯總。之前水位注冊在匯總數(shù)據(jù)之前，因此需要對m*n條數(shù)據(jù)都進(jìn)行水位注冊，使得同一時間多次水位處理，程序效率也下來了，整個任務(wù)吞吐量變低。利用水位廣播傳遞的特點(diǎn)，將水位注冊放到數(shù)據(jù)源，只需要對m條數(shù)據(jù)進(jìn)行注冊，處理邏輯直接少了n倍，整個任務(wù)吞吐量也隨之上來了
建議生成Watermaker的工作越靠近DataSource越好。這樣會方便讓程序邏輯里面更多的operator去判斷某些數(shù)據(jù)是否亂序。Flink內(nèi)部提供了很好的機(jī)制去保證這些timestamp和watermark被正確地傳遞到下游的節(jié)點(diǎn)。
今天分享到此結(jié)束，后頭見。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/130211.html
摘要：基于流處理機(jī)制實(shí)現(xiàn)批流融合相對基于批處理機(jī)制實(shí)現(xiàn)批流融合的思想更自然，更合理，也更有優(yōu)勢，因此阿里巴巴在基于支持大量核心實(shí)時計(jì)算場景的同時，也在不斷改進(jìn)的架構(gòu)，使其朝著真正批流融合的統(tǒng)一計(jì)算引擎方向前進(jìn)。 阿里妹導(dǎo)讀：2018年12月下旬，由阿里巴巴集團(tuán)主辦的Flink Forward China在北京國家會議中心舉行。Flink Forward是由Apache軟件基金會授權(quán)的全球范圍...
摘要：通過狀態(tài)演變，可以在狀態(tài)模式中添加或刪除列，以便更改應(yīng)用程序部署后應(yīng)捕獲的業(yè)務(wù)功能。本地恢復(fù)通過擴(kuò)展的調(diào)度來完成本地恢復(fù)功能，以便在恢復(fù)時考慮先前的部署位置。此功能大大提高了恢復(fù)速度。問題導(dǎo)讀1．Flink1．7開始支持Scala哪個版本？2．Flink1．7狀態(tài)演變在實(shí)際生產(chǎn)中有什么好處？3．支持SQL／Table API中的富集連接可以做那些事情？4．Flink1．7新增了哪些連接器Ap...
摘要：默認(rèn)情況下，當(dāng)數(shù)據(jù)元到達(dá)時，分段接收器將按當(dāng)前系統(tǒng)時間拆分，并使用日期時間模式命名存儲區(qū)。如果需要，可以使用數(shù)據(jù)元或元組的屬性來確定目錄。這將調(diào)用傳入的數(shù)據(jù)元并將它們寫入部分文件，由換行符分隔。消費(fèi)者的消費(fèi)者被稱為或等。 1 概覽 1.1 預(yù)定義的源和接收器 Flink內(nèi)置了一些基本數(shù)據(jù)源和接收器，并且始終可用。該預(yù)定義的數(shù)據(jù)源包括文件，目錄和插socket，并從集合和迭代器攝取數(shù)據(jù)...
摘要：之前有了解到哥的一部分讀者們沒有充分搞清楚限流和熔斷的關(guān)系。后者表示系統(tǒng)在同一時刻能處理的最大請求數(shù)量，比如次的并發(fā)。后續(xù)限流策略需要設(shè)定的具體標(biāo)準(zhǔn)數(shù)值就是從這些指標(biāo)中來的。限流閾值不繼續(xù)處理請求。 如果這是第二次看到我的文章，歡迎掃描文末二維碼訂閱我喲~本文長度為2869字，建議閱讀8分鐘。 可能你在網(wǎng)上看過不少「限流」相關(guān)的文章，但是z哥的這篇可能是最全面，最深入淺出的一篇了（容我...
摘要：另外，將機(jī)制發(fā)揚(yáng)光大，對有著非常好的支持。系統(tǒng)也注意到并討論了和的問題?？偨Y(jié)本文分享了四本相關(guān)的書籍和一份領(lǐng)域相關(guān)的論文列表篇，涉及的設(shè)計(jì)，實(shí)現(xiàn)，故障恢復(fù)，彈性擴(kuò)展等各方面。 前言 之前也分享了不少自己的文章，但是對于 Flink 來說，還是有不少新入門的朋友，這里給大家分享點(diǎn) Flink 相關(guān)的資料（國外數(shù)據(jù) pdf 和流處理相關(guān)的 Paper），期望可以幫你更好的理解 Flink。...
摘要：基于在阿里巴巴搭建的平臺于年正式上線，并從阿里巴巴的搜索和推薦這兩大場景開始實(shí)現(xiàn)。在經(jīng)過一番調(diào)研之后，阿里巴巴實(shí)時計(jì)算認(rèn)為是一個非常適合的選擇。接下來，我們聊聊阿里巴巴在層對又大刀闊斧地進(jìn)行了哪些改進(jìn)。 Apache Flink 概述 Apache Flink（以下簡稱Flink）是誕生于歐洲的一個大數(shù)據(jù)研究項(xiàng)目，原名StratoSphere。該項(xiàng)目是柏林工業(yè)大學(xué)的一個研究性項(xiàng)目，早期...
閱讀 1459·2023-01-11 13:20
閱讀 1814·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2006·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1488·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
