簡(jiǎn)介 反壓（backpressure）是實(shí)時(shí)計算應用開(kāi)發(fā)中，特別是流式計算中，十分常見(jiàn)的問(wèn)題。反壓意味著(zhù)數據管道中某個(gè)節點(diǎn)成為 瓶頸，處理速率跟不上上游發(fā)送數據的速率，而需要對上游進(jìn)行限速。由于實(shí)時(shí)計算應用通常使用消息隊列來(lái)進(jìn)行生產(chǎn)端和 消費端的解耦，消費端數據源是 pull-based 的，所以反壓通常是從某個(gè)節點(diǎn)傳導至數據源并降低數據源（比如 Kafka consumer）的攝入速率。 簡(jiǎn)單來(lái)說(shuō)，Flink 拓撲中每個(gè)節點(diǎn)（Task）間的數據都以阻塞隊列的方式傳輸，下游來(lái)不及消費導致隊列被占滿(mǎn)后，上游的 生產(chǎn)也會(huì )被阻塞，最終導致數據源的攝入被阻塞。 TCP-based 反壓的弊端 單個(gè)Task導致的反壓，會(huì )阻斷整個(gè)TM-TM之間的socket，連checkpoint barries也無(wú)法發(fā)出。 反壓傳播路徑長(cháng)，導致生效時(shí)延較大。 Credit-based 反壓 反壓過(guò)程簡(jiǎn)介 如圖所示在 Flink 層面實(shí)現反壓機制，就是每一次 ResultSubPartition 向 InputChannel 發(fā)送消息的時(shí)候都會(huì )發(fā)送一個(gè) backlog size 告訴下游準備發(fā)送多少消息，下....

數據傾斜原理 數據傾斜就是數據的分布嚴重不均，流入部分算子的數據明顯多余其他算子，造成這部分算子壓力過(guò)大。 影響 單點(diǎn)問(wèn)題 數據集中在某些分區上（Subtask），導致數據嚴重不平衡。 GC 頻繁 過(guò)多的數據集中在某些 JVM（TaskManager），使得JVM 的內存資源短缺，導致頻繁 GC。 吞吐下降、延遲增大 數據單點(diǎn)和頻繁 GC 導致吞吐下降、延遲增大。 系統崩潰 嚴重情況下，過(guò)長(cháng)的 GC 導致 TaskManager 失聯(lián)，系統崩潰。 Flink數據傾斜問(wèn)題定位 定位反壓 定位反壓有2種方式：Flink Web UI 自帶的反壓監控（直接方式）、Flink Task Metrics（間接方式）。通過(guò)監控反壓的信息 ，可以獲取到數據處理瓶頸的 Subtask。 確定數據傾斜 Flink Web UI 自帶Subtask 接收和發(fā)送的數據量。當 Subtasks 之間處理的數據量有較大的差距，則該 Subtask 出現數據傾斜。 Flink 如何處理常見(jiàn)數據傾斜 數據源 source 消費不均勻 解決思路：通過(guò)調整并發(fā)度，解決數據源消費不均勻或者數據源反壓的情況。 例如kaf....

設置空閑狀態(tài)保留時(shí)間 不設置空閑狀態(tài)保留時(shí)間會(huì )導致?tīng)顟B(tài)爆炸。 FlinkSQL 的 regular join inner 、 left 、 right ），左右表的數據都會(huì )一直保存在狀態(tài)里，不會(huì )清理！要么設置 TTL ，要么使用 Flink SQL 的 interval join 。 使用 Top N 語(yǔ)法進(jìn)行去重，重復數據的出現一般都位于特定區間內（例如一小時(shí)或一天內），過(guò)了這段時(shí)間之后，對應的 狀態(tài)就不再需要了。 Flink SQL可以指定空閑狀態(tài)（即未更新的狀態(tài)）被保留的最小時(shí)間 當狀態(tài)中某個(gè) key對應的 狀態(tài)未更新的時(shí)間達到閾值時(shí)， 該條狀態(tài)被自動(dòng)清理。 API 設置： tableEnv.getConfig().setIdleStateRetention(Duration.ofHours(1)); 配置參數設置： Configuration configuration = tableEnv.getConfig().getConfiguration(); configuration.setString("table.exec.state.ttl", " 1 h" ); ....

底層原理簡(jiǎn)介 LState:存儲左邊數據流中的數據。 RState：存儲右邊數據流中的數據。 當左邊數據流數據到達的時(shí)候會(huì )保存到LState，并且到RState中進(jìn)行Join。將Join生成的結果數據發(fā)送到下游。 右邊數據流中數據到達的時(shí)候，會(huì )保存到RState當中，并且到LState中進(jìn)行Join，然后將Join之嚄胡的結果數據發(fā)送到下游。 為了保障左右兩邊流中需要Join的數據出現在相同節點(diǎn)，Flink SQL會(huì )利用Join中的on的關(guān)聯(lián)條件進(jìn)行分區，把相同關(guān)聯(lián)條件 的數據分發(fā)到同一個(gè)分區里面。 普通雙流Join 現有訂單表A和支付表B進(jìn)行關(guān)聯(lián)得到匯總表C。訂單表和支付表初始數據如下： 表A：訂單表數據 order_id timestamp 1001 2023-02-04 10:00:00 1002 2023-01-04 10:01:02 表B：支付表數據 order_id pay_money order_id pay_money 1001 80 1002 100 inner join 當A表中每一條數據到達時(shí)，都會(huì )和B表中....

Flink大數據常見(jiàn)問(wèn)題總結。

Neovim是一個(gè)社區驅動(dòng)的開(kāi)源項目，是Vim文本編輯器的一個(gè)分叉版本，它的構建使Vim更容易為核心開(kāi)發(fā)人員維護。是對vim的一個(gè)增強，相比與vim性能更好，速度更快。

常見(jiàn)工具安裝，包括: 軟件備注 m4autoconf依賴(lài) autoconfautoconf依賴(lài) automakeautoconf依賴(lài) libtoolsautoconf依賴(lài) gmpgcc安裝依賴(lài) mpfrgcc安裝依賴(lài) mpcgcc安裝依賴(lài) islgcc安裝依賴(lài) gccgcc安裝依賴(lài)

今天同事找我幫忙看一個(gè)Flink的問(wèn)題，現象是前幾天還能提交的客戶(hù)端，就在今天突然提交不了作業(yè)了，報錯提示大概如下（公司的東西涉密）， Caused by: org.apache.flink.api.common.InvalidProgramException: The LocalStreamEnvironment cannot be used when submitting a program through a client, or running in a TestEnvironment context. at org.apache.flink.streaming.api.environment.LocalStreamEnvironment.(LocalStreamEnvironment.java:68) at org.apache.flink.streaming.api.environment.LocalStreamEnvironment.(LocalStreamEnvironment.java:58) at org.apache.flink.streaming.api.env....

本文只適合沒(méi)錢(qián)買(mǎi)新電腦又想用老電腦寫(xiě)代碼的人，其他人請繞行。 本文適合比較想學(xué)習Linux的人，不想感興趣的請繞行。

由于本人使用的自建代碼倉Gitea在docker 19版本存在bug，導致一個(gè)MR只能提交一個(gè)commit，提交第二個(gè)的時(shí)候MR就沒(méi)辦法merge了。 當然想要解決這個(gè)問(wèn)題有兩個(gè)辦法： 在Debian 9上面安裝Docker 20以后的版本，但是apt源里面沒(méi)有，可以考慮安裝Debian 10對應的Docker。 將Debian 9升級到Debian 10，順便安裝最新版本的Docker，目前版本是23。也能解決我當前的問(wèn)題。 經(jīng)過(guò)我個(gè)人的考慮，Debian 9也已經(jīng)出了好多年了，Debian 12都快出了，索性借著(zhù)這個(gè)機會(huì )先升級到Debian 10。