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